特許 6943336 連携処理再開装置、および、連携処理再開方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6943336

(24)【登録日】2021年9月13日

(45)【発行日】2021年9月29日

(54)【発明の名称】連携処理再開装置、および、連携処理再開方法

(51)【国際特許分類】

   G06F 11/14 20060101AFI20210916BHJP

   G06F 9/48 20060101ALI20210916BHJP

【ＦＩ】

   G06F11/14 602A

   G06F9/48 370

【請求項の数】3

【全頁数】15

(21)【出願番号】特願2020-516142(P2020-516142)

(86)(22)【出願日】2019年3月28日

(86)【国際出願番号】JP2019013806

(87)【国際公開番号】WO2019208098

(87)【国際公開日】20191031

【審査請求日】2020年3月31日

(31)【優先権主張番号】特願2018-81960(P2018-81960)

(32)【優先日】2018年4月23日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110001807

【氏名又は名称】特許業務法人磯野国際特許商標事務所

(72)【発明者】

【氏名】田中 宏幸

(72)【発明者】

【氏名】高橋 謙輔

(72)【発明者】

【氏名】丹治 直幸

(72)【発明者】

【氏名】武 直樹

(72)【発明者】

【氏名】小内 伸夫

(72)【発明者】

【氏名】加藤 浩

(72)【発明者】

【氏名】矢崎 啓之

【審査官】 田中 幸雄

(56)【参考文献】

【文献】 特開２００５−６３１６０（ＪＰ，Ａ）

【文献】 特開２０１８−３２８９７（ＪＰ，Ａ）

【文献】 国際公開第２０１６／１５０５２４（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／１４

Ｇ０６Ｆ ９／４８

(57)【特許請求の範囲】

【請求項1】

複数の卸サービスを連携させるための指示である連携オーダの要求を受け付ける要求受付部と、
前記連携オーダを実行することにより呼び出される卸サービスの個別の命令ごとに、その実行成否を記録するリソース管理部と、
前記実行成否が実行否であることで中断された前記連携オーダを再開するときに、前記リソース管理部から既に実行された前記卸サービスの個別の命令の前記実行成否を参照し、実行に成功した前記個別の命令の再実行をスキップしつつ、実行否または未実行である前記個別の命令を実行するオーダ再開部とを有しており、
前記リソース管理部は、さらに、前記連携オーダを実行することにより呼び出される卸サービスの個別の命令ごとに、その実行結果を再開情報として記録し、
前記オーダ再開部は、再実行をスキップした前記個別の命令について、前記個別の命令が変数の取得処理であるときは、前回取得した変数を前記再開情報から読み出すことを特徴とする
連携処理再開装置。

【請求項2】

前記オーダ再開部は、前記要求受付部が前記連携オーダの再開要求を受け付けるのを待ってから、中断された前記連携オーダを再開することを特徴とする
請求項１に記載の連携処理再開装置。

【請求項3】

連携処理再開装置は、要求受付部と、リソース管理部と、オーダ再開部とを有しており、
前記要求受付部は、複数の卸サービスを連携させるための指示である連携オーダの要求を受け付け、
前記リソース管理部は、前記連携オーダを実行することにより呼び出される卸サービスの個別の命令ごとに、その実行成否を記録し、さらに、前記連携オーダを実行することにより呼び出される卸サービスの個別の命令ごとに、その実行結果を再開情報として記録し、
前記オーダ再開部は、前記実行成否が実行否であることで中断された前記連携オーダを再開するときに、前記リソース管理部から既に実行された前記卸サービスの個別の命令の前記実行成否を参照し、実行に成功した前記個別の命令の再実行をスキップしつつ、実行否または未実行である前記個別の命令を実行し、再実行をスキップした前記個別の命令について、前記個別の命令が変数の取得処理であるときは、前回取得した変数を前記再開情報から読み出すことを特徴とする
連携処理再開方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、連携処理再開装置、および、連携処理再開方法に関する。

【背景技術】

【0002】

各サービス事業者がそれぞれ提供する卸サービスを連携させて、１つの統合したサービスを提供する連携サービスが提案されている。それぞれの卸サービスは提供される品質や安定性などが異なるため、卸サービスの利用者である連携サービスの側で、卸サービスが提供するサービス内容を管理する必要がある。

【0003】

例えば、特許文献１には、ネットワークサービスの予約時の使用可能性の低いリソースの占有やＮＷ事業者のオペレーションシステムの処理負荷の増大を回避して、サービスリソースの予約を可能とするサービス予約装置が記載されている。これにより、卸サービスのリソースを過剰に予約しなくなり、リソースの利用効率が高まる。

【0004】

また、非特許文献１には、提案されているサービスの仕様をカタログとして記述し、そのカタログを解釈して実行するサービス非依存部と、サービスごとのAPI（Application Programming Interface）を呼び出して実行するサービス依存部と、を疎結合とするシステムが記載されている。これにより、連携サービスに対して、新たな卸サービスやAPIへの柔軟な対応が可能になる。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１７−１４３４２６号公報

【非特許文献】

【0006】

【非特許文献1】高橋謙輔、他著「複数事業者間サービス連携を柔軟にするアーキテクチャ」、2017年 電子情報通信学会通信ソサイエティ大会、2017年9月12日、B-14-8

【発明の概要】

【発明が解決しようとする課題】

【0007】

連携サービスを構成する複数の卸サービスのうち、１つの卸サービスでも停止してしまうと、連携サービス全体としてサービスを提供できなくなってしまう。なお、連携オーダとして複数の卸サービスへそれぞれサービスオーダを実行させており、途中までの連携オーダが成功していたときに障害が発生したとする。その場合でも、ロールバックをするために、途中までの連携オーダを一旦全て削除した後に、最初から連携オーダをやり直す必要がある。よって、ロールバック処理に伴い、リソースコストの増大や、処理時間の増大が発生していた。

【0008】

なお、前記した特許文献１や、非特許文献１などの従来の手法は、連携オーダについて、そのオーダ実行処理が正常に完了する場合を想定しており、連携オーダ実行中の不具合発生に起因したオーダ実行処理停止時の対処方法については言及されていない。

【0009】

そこで、本発明は、複数のサービスオーダを連携させた連携オーダについて、中断状態から効率的に再開させることを、主な課題とする。

【課題を解決するための手段】

【0010】

前記課題を解決するために、本発明の連携処理再開装置は、以下の特徴を有する。
本発明は、複数の卸サービスを連携させるための指示である連携オーダの要求を受け付ける要求受付部と、
前記連携オーダを実行することにより呼び出される卸サービスの個別の命令ごとに、その実行成否を記録するリソース管理部と、
前記実行成否が実行否であることで中断された前記連携オーダを再開するときに、前記リソース管理部から既に実行された前記卸サービスの個別の命令の前記実行成否を参照し、実行に成功した前記個別の命令の再実行をスキップしつつ、実行否または未実行である前記個別の命令を実行するオーダ再開部とを有することを特徴とする。
前記リソース管理部が、さらに、前記連携オーダを実行することにより呼び出される卸サービスの個別の命令ごとに、その実行結果を再開情報として記録し、
前記オーダ再開部が、再実行をスキップした前記個別の命令について、前記個別の命令が変数の取得処理であるときは、前回取得した変数を前記再開情報から読み出すことを特徴とする。

【0011】

これにより、複数の卸サービスを連携させた連携オーダについて、個別の命令単位で管理した実行成否をもとに、前回の実行に成功した個別の命令が適切にスキップされるので、中断状態から効率的に再開させることができる。
さらに、変数の取得処理に続いて取得した変数の利用処理が行われるような連携オーダについて、変数の取得処理の後に中断した場合でも、変数の取得処理を再実行するような無駄を削減できる。

【0014】

本発明は、前記オーダ再開部が、前記要求受付部が前記連携オーダの再開要求を受け付けるのを待ってから、中断された前記連携オーダを再開することを特徴とする。

【0015】

これにより、要求受付部に投入される連携オーダの入力値誤りなどの連携オーダの中断原因を適切に取り除いてから、連携オーダが再開することができる。よって、何度も同じ中断原因により連携オーダが中断してしまうような無駄を削減できる。

【発明の効果】

【0016】

本発明によれば、複数のサービスオーダを連携させた連携オーダについて、中断状態から効率的に再開させることができる。

【図面の簡単な説明】

【0017】

【図1】本実施形態に係わる通信システムの構成図である。

【図2】本実施形態に係わる通信システムの処理概要を示すフローチャートである。

【図3】本実施形態に係わる連携オーダが実行中断するまでのリソース管理部が保持する情報の一例を示すテーブルである。

【図4】本実施形態に係わる連携オーダが実行中断した後から再開するまでのリソース管理部が保持する情報の一例を示すテーブルである。

【図5】本実施形態に係わるアダプタ共通部によるAPI処理の失敗時の動作を示すシーケンス図である。

【図6】本実施形態に係わる図５の処理に続き、要求受付部が上位装置からの再開信号を受信し、ワークフロー部に通知する動作を示すシーケンス図である。

【図7】本実施形態に係わる図６の処理に続き、ワークフロー部が受信した再開信号を、アダプタ共通部に通知する動作を示すシーケンス図である。

【図8】本実施形態に係わる図７の処理に続き、通知された再開信号をもとに、アダプタ共通部が卸サービスを再開する動作を示すシーケンス図である。

【図9】本実施形態に係わる図８の処理に続き、アダプタ共通部が卸サービスを再開する動作を示すシーケンス図である。

【発明を実施するための形態】

【0018】

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

【0019】

図１は、通信システムの構成図である。
通信システムは、上位装置５０と、サービス連携装置１０と、卸サービス３０とがネットワークで接続されて構成される。サービス連携装置１０と卸サービス３０とは連携サービスシステムを形成し、上位装置５０は、その連携サービスシステムを呼び出すための装置である。
サービス連携装置１０は、ＣＰＵ（Central Processing Unit）と、メモリと、ハードディスクなどの記憶手段（記憶部）と、ネットワークインタフェースとを有するコンピュータとして構成される。
このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラム（アプリケーションや、その略のアプリとも呼ばれる）を実行することにより、各処理部により構成される制御部（制御手段）を動作させる。

【0020】

NWサービス３０ａ、Cloudサービス３０ｂ、および、APLサービス３０ｃは、各卸サービス事業者からそれぞれ自身で管理する設備を用いて提供される。以下では、これらのNWサービス３０ａ、Cloudサービス３０ｂ、および、APLサービス３０ｃを、「卸サービス３０」と総称する。
サービス連携装置１０は、複数の卸サービス３０を連携させて、１つの統合した連携サービスを上位装置５０に提供する。つまり、サービス連携装置１０は、卸サービス事業者間を連携させて、サービス連携装置１０にとってのエンドユーザが利用する上位装置５０に対して、連携サービスを提供する。
サービス連携装置１０から卸サービス３０を利用するときには、連携サービスを実行するための連携オーダから、卸サービス３０が公開するサービスオーダ（卸オーダ）のAPI（個別の命令）が呼び出されて実行される。

【0021】

以下、３種類の連携オーダを例示する。これらの３種類の連携オーダはいずれも本実施形態の連携サービスシステムが扱う対象となる。
（１）新設時オーダ(add)は、各卸サービスリソースを組合わせた連携サービスをAPI連携によりインスタンス化する連携オーダである。例えば、NWサービス３０ａ、Cloudサービス３０ｂ、APLサービス３０ｃという３種類の卸サービス３０それぞれに対して、新設の卸オーダを順番に指示するような新設時オーダが例示される。
（２）更新オーダ(modify)は、新設時オーダによりインスタンス化された連携サービスに対して、APIを介して変更を行う連携オーダである。変更内容は、例えば、NWサービス３０ａの帯域変更や、APLサービス３０ｃが動作するサーバスペックの変更などである。
（３）削除オーダ(delete)は、新設時オーダによりインスタンス化された連携サービスを卸サービス３０から削除する連携オーダである。

【0022】

サービス連携装置１０は、卸サービス３０の種類や数に依存せずに、複数の卸サービス３０にまたがる連携オーダを管理する。そのために、サービス連携装置１０は、要求受付部１１と、ワークフロー部１２と、オーダ再開部１３と、リソース管理部１４と、APIアダプタ部２０とを有する。
要求受付部１１は、上位装置５０から受け付けた連携オーダの初回実行要求および中断後の再開要求を受け、それぞれワークフロー部１２に実行させる。
ワークフロー部１２は、卸サービス３０の種類に応じたAPIアダプタ部２０の各アダプタを介して、APIを実行する。各アダプタとは、NWサービス３０ａの場合はNWサービスアダプタ２０ａ、Cloudサービス３０ｂの場合はCloudサービスアダプタ２０ｂ、APLサービス３０ｃの場合はAPLサービスアダプタ２０ｃである。
APIアダプタ部２０の各アダプタは、アダプタの種類に特化したアダプタ個別部２３（２３ａ，２３ｂ，２３ｃ）に加え、アダプタの種類に依存せずに共通処理を行うためのアダプタ共通部２２（２２ａ，２２ｂ，２２ｃ）を備えている。

【0023】

オーダ再開部１３は、ワークフロー部１２の実行結果をリソース管理部１４に反映させる。リソース管理部１４は、卸サービス３０ごとに用意するAPIアダプタ部２０のアダプタ単位、および、各アダプタ内部で実行するAPI単位で、連携オーダの状態（state）を自身の記憶部にて管理する。
これにより、サービス連携装置１０を用いるサービス提供事業者は、連携オーダを構成するサービス個々の進捗状況を確認し、その中断サービスや、中断APIを調査する煩雑さがなくなる。
さらに、リソース管理部１４には、卸サービス３０のAPIを実行した結果が再開情報１４ａ（resumeInfo）として記憶される。

【0024】

図２は、通信システムの処理概要を示すフローチャートである。
Ｓ１１は、ワークフロー部１２が連携オーダを実行することで、各APIアダプタ部２０が卸サービス３０のAPIを実行する処理である。

【0025】

Ｓ１２は、リソース管理部１４内の再開情報１４ａの更新処理である。各APIアダプタ部２０のアダプタ共通部２２は、実行されたAPIごとに卸サービス３０からの実行結果をリソース管理部１４に通知して、再開情報１４ａとして記録させる。これにより、API実行ごとの履歴管理を行うことで、この後において連携オーダが停止したときに、その原因を追跡することができる。なお、再開情報１４ａは、APIの実行履歴がリストで保存されており、API実行ごとにリストの末尾に履歴が追加されていく。

【0026】

再開情報１４ａは、例えば、以下に列挙した各項目（Attribute）を含む。
・String型の「API名」
・Boolean型の「APIの実行結果」は、成功時Trueまたは失敗時Falseという実行成否である。
・Integer型の「失敗分類」は、APIの実行結果がTrueの場合は記載不要。Falseの場合はエラー分類として、「0:（レスポンスなし）」または「1:（ユーザ入力値誤り）」または「2:（外部サービス障害）」または「3:（その他）」となる。
・String型の「その他失敗理由」は、失敗分類で「3:（その他）」の選択時に失敗原因を記載し、それ以外は記載不要である。
・String型の「API実行時のレスポンス」
・String型の「API実行時のパラメータ」
・String型の「アダプタ拡張領域」は、アダプタ毎に必要に応じて再開に必要な情報を書き込む。
・String型の「APIの実行日時」は、再開情報１４ａ（resumeInfo）への更新日時をyyyy-MM-ddHH:mm:ss:SSS形式で記載する。

【0027】

Ｓ１３は、アダプタ共通部２２が卸サービス３０からの障害通知などにより、連携サービスシステムに障害が発生したか否かを判定する処理である。Ｓ１３でＮｏなら（つまり、障害が発生していないなら）Ｓ１１に進み、ＹｅｓならＳ１４に進む。
この障害の発生により、連携オーダを構成する複数の卸オーダのうちの１つの卸オーダだけでなく、連携オーダ全体が中断してしまい、エンドユーザへの連携サービスの提供が一時的にできなくなってしまう。

【0028】

なお、以下に３種類の障害原因を例示する。
（原因１）上位装置５０からサービス連携装置１０に投入される連携オーダの入力値誤り。
（原因２）APIアダプタ部２０から卸サービス３０にデータを送受信するためのネットワーク上の障害などの、卸サービス３０との接続不可による処理中断。
（原因３）卸サービス３０内での処理中断といった外部事業者によるサービス障害。なお、卸サービス３０内でタイムアウトなどの処理遅延によるエラーが発生したとしてもリトライにより回復可能な場合もある。その場合には、卸サービス３０内でリトライを実行させることで（つまり、卸サービス３０内で自己解決させることで）、サービス連携装置１０が認識する障害を減らしてもよい。

【0029】

このような障害発生により、連携オーダの失敗結果を受けたアダプタ共通部２２は、失敗結果をワークフロー部１２に通知することで、リソース管理部１４で管理している連携オーダの状態を中断状態（Held）に変更する（詳細は図４）。
なお、アダプタ共通部２２は、Ｓ１１の成功の実行結果と同様に、前記した「失敗分類」、「その他失敗理由」についても再開情報１４ａに記録する。

【0030】

「その他失敗理由」は、例えば、Cloudサービス３０ｂとして、クラウドサービスでVMを構築するオーダの場合、「get server details」などの管理コマンドを実施したが、同じ管理コマンドを複数回発行しても応答が無く、その発行回数が上限の超過により失敗した旨の失敗理由が挙げられる。
また、「0:（レスポンスなし）」という失敗分類は、サービス連携装置１０からみて、卸サービス３０からのレスポンスが到着しない原因として、（原因２）のネットワーク障害か、（原因３）のサービス障害かを特定できないときに記録される。
一方、サービス連携装置１０側での処理中断は、ワークフロー部１２のアプリケーション不具合や、リソース管理部１４のデータベース障害などが想定され、正常な状態管理が保証されていないことから、連携オーダの再開処理の対象外とする。

【0031】

Ｓ１４は、障害により中断していた連携サービスシステムの再開契機かを判定する処理である。Ｓ１４でＹｅｓになるまで待ち、ＹｅｓになったらＳ１５に進む。再開契機は、例えば、システム管理者が原因となる障害の解消を確認した旨の入力をサービス連携装置１０の要求受付部１１が受け付け、かつ、要求受付部１１が上位装置５０から連携オーダの再開要求を受信したときである。

【0032】

Ｓ１５は、連携オーダの再開処理である。オーダ再開部１３は、再開対象となる連携オーダを中断状態から実行状態に更新し、途中停止した各APIアダプタ部２０へAPI実行の再開処理を指示する。一方、実行完了済みのAPIは、再度実行されずスキップされる。
また、前回失敗したAPIを再実行する場合は、アダプタ共通部２２は、前回の実行結果の再開情報１４ａを、今回の再実行した結果で上書き更新する。なお、再開情報１４ａには、実行履歴がログとして記録されており、そのログ内容である各属性（Attribute）に関して、何をどこまで記載するかはアダプタやAPI(SDK)などに依存する。

【0033】

図３は、連携オーダが実行中断するまで（Ｓ１２）のリソース管理部１４が保持する情報の一例を示すテーブルである。リソース管理部１４には、連携オーダから順番に実行されるAPIごとに、そのAPIの内容である連携内容と、そのAPIごとの状態（State）とが対応付けられている。図３では説明をわかりやすくするために、APIごとの状態を、実行前状態と、実行結果と、実行後状態とに分けて記載したが、実際は現在の状態だけリソース管理部１４で管理すればよい。

【0034】

第１順番のAPI1は、変数Aの取得処理であり、例えば、連携オーダ（ProductOrder）からカタログ（ProductOffering）を取得する処理である。第１順番のAPI1の実行は成功したため、API1の状態が「受付状態」から「実行完了状態」に遷移する。
第３順番のAPI3は、変数Xの取得処理であり、例えば、カタログ（ProductOffering）からカタログ仕様（ProductSpecification ID）を抽出する処理である。第３順番のAPI3の実行は失敗したため、API1の状態が「受付状態」から「中断状態」に遷移する。

【0035】

なお、リソース管理部１４で管理される状態として取り得る値は、以下の通りである。
・受付状態（Acknowledged）は、連携オーダの発行を受け付けた状態である。
・実行状態（InProgress）は、受付状態の連携オーダの実行を開始した状態である。
・中断状態（Held）は、実行状態の連携オーダに対して障害が発生することにより、処理が中断されてしまった状態である。そして、問題が解決したら、中断状態から実行状態に復帰する。
・実行完了状態（Completed）は、実行状態の連携オーダについて、その連携オーダの処理内容が完了した状態（正常終了の状態）である。

【0036】

図４は、連携オーダが実行中断した後から再開するまで（Ｓ１５）のリソース管理部１４が保持する情報の一例を示すテーブルである。
オーダ再開部１３は、リソース管理部１４のAPIごとの状態を参照することで、中断した箇所から連携オーダを再開する。つまり、以下の各処理により、再開処理が実行される。
オーダ再開部１３は、リソース管理部１４の順番の先頭から再開処理を開始する。そして、オーダ再開部１３は、第１順番、第２順番という前回成功したAPIはスキップしつつ、スキップしたAPIが変数の取得処理であるときは、前回の実行結果を再開情報１４ａから代わりに取得する。
そして、第３順番である失敗したAPIについては、前回の実行結果を破棄して再度実行する。今回の第３順番は成功したため、オーダ再開部１３は、後続の第４順番、第５順番などの前回失敗したAPI以降の全ての処理（前回未実行の処理も）を実行する。

【0037】

このように、オーダ再開部１３は、前回実行した実行結果をリソース管理部１４の状態情報から読み取り、前回実行した実行内容を再開情報１４ａから読み取ることで、連携オーダを再開するときに、前回成功したAPIを重複して実行することなく、中断した箇所から円滑に再開することができる。

【0038】

以上、図１〜図４を参照して、本実施形態の通信システムの概要について説明した。以下、図５〜図９の各シーケンス図を順に参照し、通信システムの装置間でやりとりされるメッセージに着目して、処理の詳細を説明する。この詳細の説明では、上位装置５０とサービス連携装置１０とのやりとりにREST（REpresentational State Transfer） APIが使用される。REST APIでは、データの処理要求として、登録要求（POST）、取得要求（GET）、更新要求（PUT）、削除要求（DELETE）が用いられる。

【0039】

また、これらの要求メッセージへの応答としては、以下に示すHTTP（Hypertext Transfer Protocol）ステータスコードが用いられる。
・「200 OK（成功応答）」は、要求が正常に処理されたことを示す。
・「201 Created（作成応答）」は、要求が正常に処理され、新規リソースが作成されたことを示す。
・「400 Bad Request（無効応答）」は、サーバが理解できない無効な要求であることを示す。
・「404 Not Found（存在なし応答）」は、要求されたリソースはサーバに存在しないことを示す。

【0040】

また、各シーケンス図の説明では、リソース管理部１４内で進捗状況を管理するための情報であるCOS（Complement Order State）として、以下に列挙する各項目（Attribute）を適宜参照する。
・String型の「id」は、本リソースの識別子である。
・String型の「href」は、本リソースのURLである。
・String型の「type」は、連携サービスを示す「fp：FederateProduct」、卸サービスを示す「sp：SourceProduct」、APIアダプタ部２０が生成したものを示す「med」のいずれかである。
・String型の「sourceStateChangeId」には、StateChange通知受信契機で本リソースを生成した場合の契機となったProductOrderに対応するComplementOrderStateのidを設定する。
・String型の「productOrderId」は、type=fp,spの場合、分解前のProductOrderリソースのidを設定する。type=medの場合、設定しない。
・String型の「parentId」は、type=spの場合、親ProductOrderを格納するComplementOrderStateリソースのidを設定する。type=fp,medの場合、設定しない。

【0041】

・String型の「productId」は、type=fp,spの場合、本ProductOrderリソースの実行で生成するカタログ/リソース管理部（TMF APIsリソース）のProductリソースのidを設定する。type=medの場合、設定しないcomplementOrderJsonへの、Productリソースのidの挿入は不要である。
・String型の「mediatorProductId」は、type=medの場合、本ProductOrderリソースの実行で生成する共通リソース管理部のMediatorProductリソースのidを設定する。Type=fp,spの場合、設定しない。complementOrderJsonへの、Productリソースのidの挿入は不要である。
・String型の「state」は、ProductOrderの実行状態である。
・String型の「execSourceOffering」は、Bundle Ruleにより、子ProductOrder処理を順次実行している場合、処理中のsourceOfferingの情報である。
・Json型の「complementOrderJson」は、このProductのProductOrderリソース情報である。
・String型の「externalProductOrderId」は、type=fp,spの場合に、APIアダプタ部やSB-IFで生成されたProductOrderのidを設定する。type=medの場合、設定しない。
・String型の「productOfferingHref」は、type=fp,spの場合に、ProductOfferingのhrefを設定する。type=med,tmfの場合、設定しない。
・ResumeInfo[]型の「resumeInfo」は、再開情報１４ａである。type=medの場合、ProductOrderの再開に必要な情報を格納する。type=fp,spの場合、設定しない。

【0042】

図５は、アダプタ共通部２２によるAPI処理の失敗時の動作を示すシーケンス図である。
ワークフロー部１２は、各APIアダプタ部２０の卸サービスのインスタンス化を指示(add)する旨の登録要求（POST）をアダプタ共通部２２に送信する（Ｓ１０１）。アダプタ共通部２２は、Ｓ１０１に対する作成応答をワークフロー部１２に返信する（Ｓ１０２）。
アダプタ共通部２２は、Ｓ１０１で指示された内容に従い、各卸サービス３０のAPIを起動する（Ｓ１０３）処理を非同期処理として起動する（Ｓ１０２ｂ）。なお、非同期処理とは、第１処理、第２処理、第３処理…と続けて処理を実行するときに、第１処理の応答を待たずに第２処理や第３処理を起動してもよいことを示す。

【0043】

ここで、図３の順番３のように、ある卸サービス３０でAPI処理が失敗したとする（Ｓ１０３ｂ）。アダプタ共通部２２は、その失敗を検知する（Ｓ１０４）。
そして、アダプタ共通部２２は、APIごとの状態を実行状態（InProgress）から中断状態（Held）に更新するように、更新要求（PUT）をリソース管理部１４に通知する（Ｓ１０５）。この更新要求には、実行に失敗したAPIの再開情報１４ａが含まれる。リソース管理部１４は、Ｓ１０５に対する作成応答をアダプタ共通部２２に返信する（Ｓ１０６）。
アダプタ共通部２２は、連携オーダの実行が中断（Failed）されたことをワークフロー部１２に通知する（Ｓ１０７）。ワークフロー部１２は、連携オーダ全体を中断状態（Held）として上位装置５０などに通知し、Ｓ１０７に対する作成応答をアダプタ共通部２２に返信する（Ｓ１０８）。
以上説明した図５のシーケンスは、図２ではＳ１１〜Ｓ１３に該当する。

【0044】

図６は、図５の処理に続き、要求受付部１１が上位装置５０からの再開信号を受信し、ワークフロー部１２に通知する動作を示すシーケンス図である。
上位装置５０は、要求受付部１１に、連携オーダの再開信号を通知する（Ｓ２１１）。この再開信号は、例えば「PUT /orderManagement/v1/productOrder/XXX」であり、XXXは連携オーダ（ProductOrder）のIDを意味する。
要求受付部１１は、Ｓ２１１の再開信号で指定されたIDが存在するか否かを判定する（Ｓ２１２ａ）。要求受付部１１は、Ｓ２１２ａでＮｏなら無効応答を上位装置５０に返答して（Ｓ２１２）処理を終了し、ＹｅｓならＳ２１３に進む。

【0045】

要求受付部１１は、Ｓ２１１の再開信号をリソース管理部１４に転送する（Ｓ２１３）。リソース管理部１４は、Ｓ２１３の再開信号で指定されたIDの連携オーダが存在するか否かを判定する（Ｓ２１４ａ）。リソース管理部１４は、Ｓ２１４ａでＮｏなら存在なし応答を、要求受付部１１を介して上位装置５０に返答して（Ｓ２１４ｄ，Ｓ２１４ｅ）処理を終了し、ＹｅｓならＳ２１５ａに進む。

【0046】

リソース管理部１４は、再開信号で指定された連携オーダの状態が中断状態（Held）かつ、再開信号の更新要求（PUT）に含まれるパラメータが連携オーダのIDだけであるか否かを判定する（Ｓ２１５ａ）。
Ｓ２１５ａでＹｅｓなら、リソース管理部１４は成功応答を要求受付部１１に送信し（Ｓ２１５ｄ）、要求受付部１１は作成応答を上位装置５０に送信する（Ｓ２１５ｅ）。
Ｓ２１５ａでＮｏなら、リソース管理部１４は、無効応答を要求受付部１１経由で上位装置５０に送信する（Ｓ２２１ｄ，Ｓ２２１ｅ）。なお、Ｓ２１５ａでＮｏとは、例えば、Id=XXXに該当する連携オーダは存在し、state=中断状態（Held）で、actionが指定されていた場合である。

【0047】

図７は、図６の処理に続き、ワークフロー部１２が受信した再開信号を、アダプタ共通部２２に通知する動作を示すシーケンス図である。
上位装置５０は、連携オーダのIDが指定された更新要求（PUT）である再開オーダ申込みを、ワークフロー部１２に通知する（Ｓ３１１）。
ワークフロー部１２は、Ｓ３１１のIDで指定された中断状態（Held）の連携オーダの取得要求（GET）を、リソース管理部１４に通知する（Ｓ３１２）。
リソース管理部１４は、Ｓ３１２で指定された条件に合致する連携オーダが存在するか否かを判定する（Ｓ３１３ａ）。
Ｓ３１３ａでＮｏなら、リソース管理部１４は、ワークフロー部１２、要求受付部１１を経由して、上位装置５０に、存在なし応答を通知して（Ｓ３１３ｄ，Ｓ３１３ｅ，Ｓ３１３ｆ）、処理を終了する。
Ｓ３１３ａでＹｅｓなら、リソース管理部１４は、ワークフロー部１２、要求受付部１１を経由して、上位装置５０に、成功応答を通知する（Ｓ３１４ｄ，Ｓ３１４ｅ，Ｓ３１４ｆ）。

【0048】

ワークフロー部１２は、Ｓ３１３ａで該当する連携オーダを実行状態（InProgress）に更新する更新要求（PUT）を、リソース管理部１４に通知する処理（Ｓ３２１）を、非同期処理として起動する（Ｓ３１５）。リソース管理部１４は、作成応答をワークフロー部１２に返答する（Ｓ３２２）。
リソース管理部１４は、要求受付部１１を経由して、上位装置５０にリソース変更（連携オーダの状態変更）を通知する（Ｓ３２３ｄ，Ｓ３２３ｅ）。

【0049】

ワークフロー部１２は、Ｓ３１１のIDで指定された中断状態（Held）の連携オーダの取得要求（GET）を、リソース管理部１４に通知する（Ｓ３２４）。この取得要求は、例えば「GET /commonResourceMng/orderManagement/v1/complementOrderState」である。リソース管理部１４は、成功応答をワークフロー部１２に通知する（Ｓ３２５）。
ワークフロー部１２は、Ｓ３２４の取得要求（GET）への成功応答（Ｓ３２５）として取得した連携オーダのCOSのIDを用いて、そのCOSを実行状態（InProgress）に更新するための更新要求（PUT）を、リソース管理部１４に通知する（Ｓ３３１）。この更新要求は、例えば「PUT /commonResourceMng/orderManagement/v1/complementOrderState」である。リソース管理部１４は、作成応答をワークフロー部１２に通知する（Ｓ３３２）。
なお、Ｓ３２１の状態更新処理は、Ｓ３１１で指定された連携オーダ（ProductOrder）のオーダ状態の更新処理である。一方、Ｓ３３１の状態更新処理は、Ｓ３２１の連携オーダを基に内部で補完した情報であるCOSの状態の更新処理である。

【0050】

図８は、図７の処理に続き、通知された再開信号をもとに、アダプタ共通部２２が卸サービス３０を再開する動作を示すシーケンス図である。ワークフロー部１２は、COSの項目であるid(externalProductOrderId)のみ指定した再開処理をアダプタ共通部２２に通知する（Ｓ４１１）。この再開処理は、例えば「PUT /mediation/xxx/orderManagement/v1/productOrder」である。
なお、「externalProductOrderId」は、上位装置５０から連携オーダ（ProductOrder）をリクエストされた時にリソース管理部１４で生成するProductOrderIDと、APIアダプタ部２０にProductOrderをリクエストした時に生成されるProductOrderIDを紐付けるために用いられる。
アダプタ共通部２２は、Ｓ４１１の該当IDについてのCOS上の状態の取得要求（GET）をリソース管理部１４に通知する（Ｓ４１２）。この取得要求は、例えば「GET /commonResourceMng/orderManagement/v1/complementOrderState」である。リソース管理部１４は、成功応答をアダプタ共通部２２に通知する（Ｓ４１３）。

【0051】

アダプタ共通部２２は、Ｓ４１２のGETで取得した状態が中断状態（Held）であるか否かを判定する（Ｓ４１４ａ）。
Ｓ４１４ａでＮｏなら、アダプタ共通部２２は、無効応答をワークフロー部１２に通知する（Ｓ４１４）。なお、Ｓ４１４以降の処理はAPIアダプタ部２０内でのエラー処理という既存処理であるので、説明を省略する。既存処理は、例えば、該当COSの状態を中断状態（Held）にしてリソース管理部１４に通知する処理である。
Ｓ４１４ａでＹｅｓなら、アダプタ共通部２２は、作成応答をワークフロー部１２に通知する（Ｓ４１５）。

【0052】

リソース管理部１４は、COSの状態を実行状態（InProgress）にする更新要求（PUT）をアダプタ共通部２２に通知する（Ｓ４２１）処理を、非同期処理として起動する（Ｓ４１６）。更新要求は、例えば「PUT /commonResourceMng/orderManagement/v1/complementOrderState state=InProgress」である。アダプタ共通部２２は、作成応答をリソース管理部１４に通知する（Ｓ４２２）。
アダプタ共通部２２は、実行状態（InProgress）を通知する登録要求（POST）を、ワークフロー部１２に通知する（Ｓ４２３）。この登録要求は、例えば、「POST /client/listenreventType=orderStateChangeNotification」である。ワークフロー部１２は、作成応答をアダプタ共通部２２に通知する（Ｓ４２４）。

【0053】

図９は、図８の処理に続き、アダプタ共通部２２が卸サービス３０を再開する動作を示すシーケンス図である。
Ｓ４３１〜Ｓ４３６は、アダプタ共通部２２がリソース管理部１４から、サービスの再開に必要な情報（再開情報）を取得する処理である。
Ｓ４３１では、連携オーダ（ProductOrder）からの情報を取得する取得要求（GET）として、「GET /commonResourceMng/orderManagement/v1/complementOrderState/productOrder」が送信される。Ｓ４３２は、Ｓ４３１への成功応答である。
Ｓ４３３では、mediatorProductからの情報を取得する取得要求（GET）として、「GET /commonResourceMng/productInventoryManagement/v1/mediatorProduct」が送信される。Ｓ４３４は、Ｓ４３３への成功応答である。
Ｓ４３５では、再開情報１４ａ（resumeInfo）からの情報を取得する取得要求（GET）として、「GET /commonResourceMng/orderManagement/v1/complementOrderState/resumeInfo」が送信される。Ｓ４３６は、Ｓ４３５への成功応答である。

【0054】

アダプタ共通部２２は、Ｓ４３１〜Ｓ４３６で取得した情報を元に、障害が発生したAPIを起動する指示を卸サービス３０に通知する（Ｓ４４１）。
卸サービス３０は、障害が発生したAPI以降の全てのAPIが成功したか否かを判定する（Ｓ４４２ａ）。
Ｓ４４２ａでＹｅｓなら、卸サービス３０は、成功応答をアダプタ共通部２２に送信し（Ｓ４４２）、再開情報１４ａ（resumeInfo）を空に更新する旨の指示をリソース管理部１４に通知する（Ｓ４４３）。この指示は、例えば「PUT /commonResourceMng/orderManagement/v1/complementOrderState/resumeInfo」である。Ｓ４４４は、Ｓ４４３への成功応答である。
Ｓ４４２ａでＮｏなら、失敗したAPI（Ｓ４４５）について、卸サービス３０からアダプタ共通部２２に通知され（Ｓ４４６）、以降の処理は既存のAPIアダプタ実行処理と共通のため省略する。

【0055】

以上説明した本実施形態では、連携オーダから実行される個々のAPI単位での状態管理をリソース管理部１４にて実行しておく。そして、所定のAPIが失敗したことで、連携オーダ全体が中断してしまったときには、所定のAPIより前のAPIについては、前回成功した結果を流用することで、再度の実行をスキップする。
これにより、円滑なロールフォワードで連携オーダを再開させることができるため、ロールバックが不要となる。つまり、ロールバックでは、中断前の実行結果を全部削除して、連携オーダを最初からやり直ししていたのだが、それでは卸サービス３０に対してインスタンスを一旦削除してから再作成するなどの無駄なコストを発生させてしまう。一方、本実施形態のロールフォワードでは、そのような無駄なコストを抑制できる。

【0056】

なお、本実施形態においては、本発明に係るサービス連携装置１０の構成として、図１に示すように、３種類の卸サービス３０（NWサービス３０ａ、Cloudサービス３０ｂ、APLサービス３０ｃ）を扱う装置としたが、これらの個数や構成に限定されない。また、本発明では、一般的なコンピュータのハードウェア資源を、サービス連携装置１０の各手段として動作させるプログラムによって実現することができる。そして、このプログラムは、通信回線を介して配布したり、ＣＤ−ＲＯＭ等の記録媒体に記録して配布したりすることも可能である。

【符号の説明】

【0057】

１０ サービス連携装置
１１ 要求受付部
１２ ワークフロー部
１３ オーダ再開部
１４ リソース管理部
１４ａ 再開情報
２０ APIアダプタ部（アダプタ部）
２２ アダプタ共通部
２３ アダプタ個別部
３０ 卸サービス
３０ａ NWサービス
３０ｂ Cloudサービス
３０ｃ APLサービス
５０ 上位装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】