JP6922835B2 - サービス連携装置および通知方法 - Google Patents

Description

本発明は、サービス連携装置および通知方法に関する。

非特許文献１には、「複数事業者のネットワーク及びクラウド，アプリを組合せ，連携させたサービスを一括で構築する際に新たなサービスやAPIへの追従を柔軟に実現するための方式」について開示されている。ＡＰＩは、Application Programmable Interfaceの略である。

高橋謙輔、他３名、"複数事業者間サービス連携を柔軟にするアーキテクチャ"、電子情報通信学会大会講演論文集 CD-ROM、日本、2017年08月19日、巻：2017、号：ソサイエティ大会、ページ：ROMBUNNO.B‐14‐8

複数種類のサービスが連携した連携サービスに関するサービスオーダが、サービス事業者から各サービスの卸サービス事業者へ発行された場合、卸サービス事業者ごとのサービスオーダ応答がサービス事業者へ通知されていた。しかし、各卸サービス事業者からの通知がすべてなされたとしても、サービスオーダ全体が完了したと判断することはできない。従来では、サービスオーダ全体の完了は、連携サービスが提供されるシステムの運用者が個別確認していた。このため、サービスオーダ全体の完了の把握に時間を要してしまい、サービス事業者にとっての連携サービスの利便性を損ねていたという問題がある。非特許文献１には、このような問題への対策について記載も示唆もない。

本発明は、このような事情に鑑みて、サービス事業者にとっての連携サービスの利便性を向上させることを課題とする。

前記課題を解決するために、請求項１に記載の発明は、複数種類のサービスが連携した連携サービスを実行するサービス連携装置であって、前記連携サービスのサービスオーダを含む要求をサービス事業者から受領する受領部と、前記連携サービスを構成するサービスごとに用意されおり、対応の前記サービスのＡＰＩを実行して、前記サービスオーダのうち、対応の前記サービスのサービスオーダ部分を処理する複数のアダプタと、前記サービスオーダ部分の処理がすべて完了した場合、前記サービス事業者に前記サービスオーダの完了通知をする通知部と、前記サービスおよび前記連携サービスの実行に関するリソースを記憶して管理する業務リソース管理部とを備え、前記通知部は、前記リソースの再取得が必要となる所定の場合に、前記業務リソース管理部に対し、前記リソースの再取得を要求し、前記通知部は、前記連携サービスのシナリオ実行状況が管理されるステータスと、要求元の属性情報と、前記要求元への通知契機とに基づき、情報をフィルタリングして前記サービス事業者に前記完了通知をし、前記フィルタリングにおいて、一部オーダ処理が失敗した場合に、通知不要とする、または、前記属性情報に示す条件を満たす部分のみを通知することを特徴とする。

また、請求項２に記載の発明は、複数種類のサービスが連携した連携サービスを実行するサービス連携装置における通知方法であって、前記サービス連携装置は、前記サービスおよび前記連携サービスの実行に関するリソースを記憶して管理する業務リソース管理部を備えており、前記連携サービスのサービスオーダを含む要求をサービス事業者から受領するステップと、前記連携サービスを構成するサービスごとに用意されるアダプタの各々が、対応の前記サービスのＡＰＩを実行して、前記サービスオーダのうち、対応の前記サービスのサービスオーダ部分を処理するステップと、前記サービスオーダ部分の処理がすべて完了した場合、前記サービス事業者に前記サービスオーダの完了通知をするステップと、前記リソースの再取得が必要となる所定の場合に、前記業務リソース管理部に対し、前記リソースの再取得を要求するステップと、前記連携サービスのシナリオ実行状況が管理されるステータスと、要求元の属性情報と、前記要求元への通知契機とに基づき、情報をフィルタリングして前記サービス事業者に前記完了通知をするステップと、前記フィルタリングにおいて、一部オーダ処理が失敗した場合に、通知不要とする、または、前記属性情報に示す条件を満たす部分のみを通知するステップとを実行する、ことを特徴とする。

請求項１，２によれば、サービス事業者は、自身がしたサービスオーダ全体が完了したことを確実かつ即座に把握することができるとともに、サービスオーダ全体の完了に関し、連携サービスが提供されるシステムの運用者の個別確認を不要とすることができる。
したがって、サービス事業者にとっての連携サービスの利便性を向上させることができる。

本発明によれば、サービス事業者にとっての連携サービスの利便性を向上させることができる。

本実施形態のサービス連携装置の機能構成図の例である。 連携サービス構築処理のフローチャートである。

続いて、本発明の実施形態について、図面を参照して説明する。

≪構成≫
図１に示す本実施形態のサービス連携装置１は、複数種類のサービスを連携させた連携サービスを実行する装置である。サービス連携装置１は、例えば、サービスの仕様を記述したカタログを用いて動作するカタログドリブンアーキテクチャを有する。サービス連携装置１は、入出力用のＩ／Ｆ（インターフェイス）などで構成される入出力部（図示略）、ハードディスク、フラッシュメモリ、ＲＡＭ（Random Access Memory）などで構成される記憶部（図示略）、ＣＰＵ（Central Processing Unit）などで構成される制御部（図示略）といったハードウェアを備えるコンピュータである。制御部は、例えば、記憶部に記憶されているプログラムを記憶部の記憶領域に展開し実行することにより、上記の処理が実行される。本実施形態のサービス連携装置１は、このようなソフトウェアとハードウェアの協働を実現することができる。

図１には、複数種類のサービスとして、Ｘ社ネットワークサービス２−１、ＩａａＳ（Infrastructure as a Service）またはＰａａＳ（Platform as a Service）のＹ社クラウド２−２、および、アプリＺ２−３（「アプリ」はアプリケーション（ＡＰＬ）の略）が示されている。Ｘ社ネットワークサービス２−１は、卸サービス事業者であるＸ社が提供するサービス（ＮＷサービスＡ）である。Ｙ社クラウド２−２は、卸サービス事業者であるＹ社が提供するサービス（クラウドサービスＢ）である。アプリＺ２−３は、卸サービス事業者であるＺ社が提供するサービス（ＡＰＬサービスＣ）である。しかし、本発明で取り扱うサービスの種類はこれらに限定されない。本実施形態では、Ｘ社ネットワーク２−１、Ｙ社クラウド２−２、および、アプリＺ２−３のうち２つ以上が連携して１つの連携サービスを構成することができる。

サービス連携装置１は、業務ＡＰＩ部１０（受領部）と、実行シナリオ管理部２０と、ＡＰＩアダプタ部３０と、業務リソース管理部４０とを備える。

業務ＡＰＩ部１０は、サービス事業者からのサービスオーダを受け付ける。サービス事業者は、サービス連携装置１と通信可能に接続するサービス事業者端末（図示せず）を有し、サービス連携装置１に所定のサービスオーダを含む要求（リクエスト）を送信することができる。説明の便宜上、サービス事業者端末による処理（要求の送信、情報の受信等）は、サービス事業者による処理として説明する。また、業務ＡＰＩ部１０は、通知情報生成部１１（通知部）を有する。通知情報生成部１１は、後記する、サービスオーダの完了を示す応答に対して、所定の通知情報を生成してサービス事業者に送信する。

実行シナリオ管理部２０は、サービスオーダを処理するときの処理手順が記述されている各種シナリオを管理し、前述サービスオーダに該当したシナリオを実行する。前述のシナリオには、例えば、サービス事業者のサービスを一括構築するシナリオや卸サービス事業者を監視するための設定を行うシナリオなどが含まれるが、これらに限定されない。

ＡＰＩアダプタ部３０は、卸サービス事業者のサービスのＡＰＩを実行して、サービスオーダを処理する。ＡＰＩアダプタ部３０は、アダプタ３１〜３３を含むがこれらに限定されない。アダプタ３１は、ＮＷサービスＡ用のアダプタであり、Ｘ社ネットワーク２−１のＡＰＩを実行して、Ｘ社宛のサービスオーダを処理する。アダプタ３２は、クラウドサービスＢ用のアダプタであり、Ｙ社クラウド２−２のＡＰＩを実行して、Ｙ社宛のサービスオーダを処理する。アダプタ３３は、ＡＰＬサービスＣ用のアダプタであり、アプリＺ２−３のＡＰＩを実行して、Ｚ社宛のサービスオーダを処理する。

また、ＡＰＩアダプタ部３０は、実行シナリオ管理部２０からの該当卸サービスのアダプタ（アダプタ３１〜３３）のＡＰＩを実行するオーダに対して、処理を実行し、その処理結果を実行シナリオ管理部２０に応答する。特定した複数のアダプタの各々は、連携サービスのサービスオーダのうち、自身のアダプタが対応するサービスオーダ部分を処理する。例えば、ＮＷサービスＡとクラウドサービスＢを連携させた連携サービスのサービスオーダに対しては、アダプタ３１が、連携サービスのサービスオーダのうち、ＮＷサービスＡ部分を処理し、アダプタ３２が、連携サービスのサービスオーダのうち、クラウドサービスＢ部分を処理する。

業務リソース管理部４０は、（単独の）サービスおよび連携サービスの実行に関する各種リソースを記憶して管理する。業務リソース管理部４０は、カタログ管理部４１と、連携ルール管理部４２と、構成情報管理部４３とを備える。

カタログ管理部４１は、サービスの仕様を定義したカタログを管理する。カタログは、例えば、サービス連携装置１の記憶部に記憶されている。カタログ管理部４１が管理するカタログは、ソースカタログおよび連携カタログに分類することができる。説明の便宜上、ソースカタログは、単に、「カタログ」と呼ぶ場合がある。

カタログ管理部４１が管理するソースカタログは、サービス連携装置１の対象となるサービスの仕様を定義したカタログであり、卸サービス事業者単位で用意されている。カタログ管理部４１が管理するソースカタログ（群）には、ＮＷサービスＡカタログ４１１ａ、クラウドサービスＢカタログ４１１ｂ、および、ＡＰＬサービスＣカタログ４１１ｃが含まれているが、これらに限定されない。ＮＷサービスＡカタログ４１１ａは、ＮＷサービスＡの仕様を定義したカタログである。クラウドサービスＢカタログ４１１ｂは、クラウドサービスＢの仕様を定義したカタログである。ＡＰＬサービスＣカタログ４１１ｃは、ＡＰＬサービスＣの仕様を定義したカタログである。

また、カタログ管理部４１が管理する連携カタログ（群）は、サービス連携装置１の対象となる連携サービスの仕様を定義したカタログである。連携カタログは、連携サービスを構成するサービスのカタログを複数組み合わせることで作成することができる。カタログ管理部４１が管理する連携カタログには、連携カタログ４１２ａ，４１２ｂが含まれるが、これらに限定されない。連携カタログ４１２ａは、ＮＷサービスＡおよびクラウドサービスＢを連携した連携サービスの仕様を定義したカタログであり、ＮＷサービスＡカタログ４１１ａおよびクラウドサービスＢカタログ４１１ｂを組み合わせて作成される。連携カタログ４１２ｂは、ＡＰＬサービスＣおよびクラウドサービスＢを連携した連携サービスの仕様を定義したカタログであり、ＡＰＬサービスＣカタログ４１１ｃおよびクラウドサービスＢカタログ４１１ｂを組み合わせて作成される。

連携ルール管理部４２は、連携サービスを構成する各サービス間の連携動作に関する規定となる連携ルールを管理する。連携ルールは、連携カタログごとに１または複数用意することができる。連携ルール管理部４２が管理する連携ルールには、連携ルール４２１，４２２が含まれるが、これらに限定されない。連携ルール４２１は、連携サービスを構成する、ＮＷサービスＡおよびクラウドサービスＢの間の連携動作に関する規定である。連携ルール４２２は、連携サービスを構成する、ＡＰＬサービスＣおよびクラウドサービスＢの間の連携動作に関する規定である。

構成情報管理部４３は、通知情報生成部１１が通知情報を生成するための情報を構成情報として管理する。構成情報には、サービスオーダを含む要求を送信するサービス事業者を示す要求元情報（後記）が含まれるが、これに限定されない。構成情報管理部４３は、連携サービスのサービスオーダを構成する、卸サービス事業者単位のサービスオーダ部分の完了応答に基づいて、サービスオーダの完了通知をするように、実行シナリオ管理部２０を介して通知情報生成部１１に要求することができる。

なお、業務リソース管理部４０が管理するリソースは、カタログ管理部４１が管理するカタログ、連携ルール管理部４２が管理する連携ルール、および、構成情報管理部４３が管理する構成情報に限らず、さまざまな情報を含む。

〔連携サービス構築処理による連携サービスのサービスオーダの完了通知〕
図２を参照して、本実施形態のサービス連携装置１の連携サービス構築処理について説明する。この処理は、サービス事業者から連携サービスを構築するサービスオーダを含む要求があった場合に開始する。

まず、業務ＡＰＩ部１０は、連携サービスを構築するサービスオーダを含む要求を受領し受け付ける（ステップＳ１）。次に、実行シナリオ管理部２０は、サービスオーダに対し、連携サービスの構築のためのシナリオを実行する（ステップＳ２）。シナリオ実行の際は、業務リソース管理部４０のカタログ管理部４１および連携ルール管理部４２が参照され、サービス連携装置１は、対象の連携サービスの連携カタログ、および、対象の連携サービスを構成する複数種類のサービス間の連携ルールに従って動作する。また、シナリオ実行の結果、連携サービスを構成するサービスの種類が決定する。実行シナリオ管理部２０は、業務リソース管理部４０の構成情報管理部４３に対し、決定したサービスの種類を通知する。

次に、ＡＰＩアダプタ部３０は、実行シナリオ管理部２０からの連携サービスのシナリオによって、処理されるアダプタが特定される。特定されたアダプタは、対応するサービスのＡＰＩを実行して、連携サービスのサービスオーダのうち、対応するサービスオーダ部分を処理する（ステップＳ３）。各アダプタによるサービスオーダ部分の処理が完了すると、ＡＰＩアダプタ部３０は、対応する卸サービス事業者（の端末）の各々から、サービスオーダ部分の処理が完了したことを示すオーダ完了応答を受信する。

次に、業務リソース管理部４０の構成情報管理部４３は、ＡＰＩアダプタ部３０からサービスオーダ部分のオーダ完了応答をすべて取得する（ステップＳ４）。各オーダ完了応答の取得は非同期で行われる。構成情報管理部４３は、連携サービスを構築するサービスオーダに対して、実行シナリオ管理部２０から事前に通知されたサービスの種類（ステップＳ２）を踏まえ、サービスオーダ部分のオーダ完了応答をすべて取得することができた場合、連携サービスを構築するサービスオーダ全体が完了したと判定する。なお、業務リソース管理部４０は、取得したオーダ完了応答に応じて、業務リソース管理部４０が管理する各種リソースのデータベース更新をする。構成情報管理部４３は、サービスオーダの完了通知をするように、実行シナリオ管理部２０を介して通知情報生成部１１に要求する。また、構成情報管理部４３は、構築した連携サービスの構成を構成情報として登録する。連携サービスの構成とは、例えば、当該連携サービスが提供されるネットワークに配置されているネットワーク装置やサーバに関する情報をいう。

業務ＡＰＩ部１０の通知情報生成部１１は、構成情報管理部４３の要求を受信すると、連携サービスを構築するサービスオーダを含む要求をしたサービス事業者に対する通知情報を生成し、サービス事業者に当該サービスオーダの完了通知をする（ステップＳ５）。よって、サービス事業者は、自身がしたサービスオーダ全体が完了したことを確実かつ即座に把握することができるとともに、サービスオーダ全体の完了に関し、連携サービスが提供されるシステムの運用者（サービス連携装置１のオペレータ等）の個別確認を不要とすることができる。その結果、サービス事業者にとっての連携サービスの利便性を向上させることができる。

上記説明は、連携サービスを構築するサービスオーダに関するものであったが、構築に限らず、連携サービスの管理等に関してもあてはまる。

〔要求元情報の登録〕
サービス連携装置１は、サービスオーダを含む要求をするサービス事業者を示す要求元情報を登録することができる。要求元情報は、要求元としてのサービス事業者を識別するＩＤ情報を含む。サービス事業者は、サービス連携装置１に送信する要求に、サービス事業者に関する属性を示す属性情報を含めることができる。属性情報には、サービスオーダを含む要求に対し通知情報生成部１１が生成する通知情報に示すイベントの重要度を示す重要度情報、通知情報に示す通知内容を制限する通知フィルタ情報、通知情報の通知先ＵＲＬを示す通知先情報が含まれるがこれらに限定されない。属性情報は、通知情報生成部１１によるサービスオーダの完了通知を制限するためのフィルタリング条件を構成する。上記の重要度情報、通知フィルタ情報、通知先情報もフィルタリング条件の一種である。

サービス連携装置１は、連携サービスのサービスオーダを処理するために、シナリオ実行状況のステータスを管理している。シナリオ実行状況のステータスは、例えば、イベントタイプおよびイベントを用いて表現することができる。「イベントタイプ」とは、連携サービスを構成するサービスのＡＰＩを実行するときの処理の種類である。イベントタイプの具体例としては、例えば、トラブルチケットのＡＰＩにおける「TicketStatusChangeNotification」がある。「イベント」とは、連携サービスを構成するサービスのＡＰＩを実行するときの処理の内容であり、イベントタイプごとに決められている。イベントタイプが「TicketStatusChangeNotification」である場合、イベントの具体例としては、例えば、「Acknowledge（承認）」、「InProgress（進行中）」がある。属性情報の重要度情報では、イベントごとに重要度が設定される。

通知先情報が示す通知先ＵＲＬは、例えば、サービスオーダを含む要求をするサービス事業者が開示するサイトのＵＲＬとすることができるが、これに限定されない。また、通知先ＵＲＬは、１つに限らず２以上であってもよい。

サービス連携装置１の業務ＡＰＩ部１０は、サービス事業者から受領した要求（サービスオーダを含むか否かは問わない）を解析して要求元情報を生成し、業務リソース管理部４０へ登録することができる。業務リソース管理部４０は、要求元情報を管理する要求元テーブル（図示せず）を備えており、業務ＡＰＩ部１０から取得した要求元情報を要求元テーブルに登録する。業務ＡＰＩ部１０は、要求元情報に属性情報を付加させることができ、業務リソース管理部４０は、要求元テーブルに属性情報を要求元情報に関連付けて登録することができる。業務リソース管理部４０は、要求元情報の登録完了を、業務ＡＰＩ部１０を介してサービス事業者に通知する。要求元テーブルは、サービス連携装置１の記憶部に記憶されている。

サービス連携装置１は、要求元情報に付加する属性情報に示すフィルタリング条件によって、サービス連携装置の利用者ごとに要望の異なる、サービスオーダの完了通知を実現することができる。

〔通知先の振り分け〕
サービス連携装置１は、連携サービスのサービスオーダの完了通知を含む通知情報の通知先を決定することができる。例えば、新規のサービスオーダ完了時に、業務リソース管理部４０が要求元情報を登録した際、業務リソース管理部４０は、登録した要求元情報に付加されている属性情報のうち通知先情報に示す通知先ＵＲＬ宛に通知情報を送信するように通知情報生成部１１に要求する。通知情報生成部１１は、該当のサービスオーダの完了通知を、通知先情報に示す通知先ＵＲＬ宛に送信する。結果的に、所望の通知先にサービスオーダの完了通知をすることができる。

〔通知内容の制限〕
サービス連携装置１は、連携サービスのサービスオーダの完了通知を含む通知情報の通知内容を制限（フィルタリング）することができる。例えば、新規のサービスオーダ完了時に、業務リソース管理部４０が要求元情報を登録した際、業務リソース管理部４０は、登録した要求元情報に付加されている属性情報のうち通知フィルタ情報にしたがって通知情報を送信するように通知情報生成部１１に要求する。通知情報生成部１１は、該当のサービスオーダの完了通知を通知先へ通知する際、通知内容を制限する。

例えば、連携サービスを構成する各サービスの卸サービス事業者の一部ではオーダ処理が成功しオーダ完了応答があったが、卸サービス事業者の残りではオーダ処理が失敗し、オーダ失敗応答があったとする。この場合、サービス連携装置１は、オーダ完了応答およびオーダ失敗応答の両方をサービス事業者に通知してもよいが、オーダ完了応答の通知は不要と判断し、オーダ処理失敗の原因特定箇所のみをサービス事業者に通知してもよい。このような通知制限を通知フィルタ情報に記述することができる。また、通知フィルタ情報には、所定条件を満たした場合に通知不要となる情報を、当該所定条件との組み合わせで記述することができる。

また、要求元情報の登録後、サービス事業者から受領した、連携サービスのサービスオーダを含む要求内に、イベントタイプの条件が記述されている場合、通知情報生成部１１は、サービス事業者に通知する通知情報として当該イベントタイプに該当する情報のみを通知することができる。また、連携サービスのサービスオーダを含む要求内に、イベントタイプの条件だけでなく、属性情報で示す条件も記述されている場合、通知情報生成部１１は、サービス事業者に通知する通知情報として当該イベントタイプに該当する情報のうち、属性情報に示す条件を満たす部分のみを通知することができる。

要求元情報の登録後、サービス事業者から受領した、連携サービスのサービスオーダを含む要求内に、何ら条件が記述されていない場合、または、“条件なし”が指定されている場合、サービス事業者に通知する通知情報は、何ら制限のかからないすべての情報となる。
結果的に、所望の通知内容でサービスオーダの完了通知をすることができる。

〔通知情報の通知契機〕
サービス連携装置１は、通知情報生成部１１が通知情報をサービス事業者に通知する際の通知契機を決定することができる。例えば、業務リソース管理部４０が要求元情報を登録した際、業務リソース管理部４０は、登録した要求元情報に付加されている属性情報に示される通知契機に従って通知情報を送信するように通知情報生成部１１に要求する。結果的に、所望の通知契機で、サービスオーダの完了通知をすることができる。

例えば、先述したように、業務リソース管理部４０の構成情報管理部４３が、連携サービスを構築するサービスオーダに対して、サービスオーダ部分のオーダ完了応答をすべて取得し、サービスオーダの完了通知をするように、通知情報生成部１１に要求したとする。この場合、業務ＡＰＩ部１０は、当該要求を受信したことを契機にして、業務リソース管理部４０に対し、サービスオーダ部分のオーダ完了応答に応じた、各種リソースのデータベース更新の完了確認をする。各種リソースのデータベース更新の完了確認ができた後、通知情報生成部１１は通知情報をサービス事業者に通知する。このように、複数のサービスを連携させる際に、連携サービスのすべての構築の完了を確認した後に情報通知を行うとよい。

また、最終的にサービスオーダ部分のオーダ完了応答がすべてなされるのであれば、サービスオーダ部分のオーダが処理中であっても、通知情報生成部１１は通知情報をサービス事業者に通知してもよい。つまり、複数のサービスを連携させる際に、連携サービスの一部の構築が未完了であっても情報通知を行ってもよい。例えば、卸サービス事業者側のインターフェースに通知機能が備わっていない場合は、このような通知の方式を採用するとよい。

連携サービスの実行に伴う、設備構築や課金などの業務においても、サービス事業者へ所定の通知情報を通知すること（情報通知）は必要である。情報通知の契機は数多く存在しており、例えば、連携サービスのサービスオーダの処理が特定の進捗段階に到達した時、トラブルチケットの処理が特定の進捗段階に到達した時、ＳＬＡ違反判定を行う時、製品やサービスの利用量を算出した時、課金時、カタログ更新時、などがある。これらのタイミングを通知契機として属性情報に記述することができる。

サービス連携装置１は、サービス事業者に通知する通知情報ごとに、通知要否、通知先（個人または組織）、重要度を設定することができる。その際、各情報通知の制御について、サービス連携装置１の利用者ごとに要望が異なることが想定されるため、所定の外部ルールを用いた定義を行うことで、細かな設定を実現する。外部ルールは、例えば、サービス連携装置１と通信可能に接続しており、サービス連携装置１に対して情報入力可能な外部装置に記憶されており、外部装置から編集することができる。外部ルールによる情報通知の制御は、例えば、イベントタイプごとに決められているイベントごとに、重要度、通知要否、通知先を定義することで実現することができる。

≪その他≫
以上、本発明の実施形態について説明したが、本発明は前記実施形態に限定されず、本発明の要旨を逸脱しない範囲で適宜変更可能である。例えば、通知情報生成部１１が通知情報を生成する際、必要な情報の再取得処理が必要な場合には、通知情報生成部１１が業務リソース管理部４０に情報の再取得を要求することができる。また、通常は、サービス連携装置１の利用者（サービス事業者、卸サービス事業者を含む）ごとに、業務リソース管理部４０が管理するリソースへのアクセス許可が異なっている。このため、業務リソース管理部４０は、サービス連携装置１の各利用者のアクセス権に応じた、リソース情報の編集をすることができる。

本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１ サービス連携装置
１０ 業務ＡＰＩ部（受領部）
１１ 通知情報生成部（通知部）
２０ 実行シナリオ管理部
３０ ＡＰＩアダプタ部
４０ 業務リソース管理部
４１ カタログ管理部
４２ 連携ルール管理部
４３ 構成情報管理部

Claims (2)

1. 複数種類のサービスが連携した連携サービスを実行するサービス連携装置であって、
   前記連携サービスのサービスオーダを含む要求をサービス事業者から受領する受領部と、
   前記連携サービスを構成するサービスごとに用意されおり、対応の前記サービスのＡＰＩを実行して、前記サービスオーダのうち、対応の前記サービスのサービスオーダ部分を処理する複数のアダプタと、
   前記サービスオーダ部分の処理がすべて完了した場合、前記サービス事業者に前記サービスオーダの完了通知をする通知部と、
   前記サービスおよび前記連携サービスの実行に関するリソースを記憶して管理する業務リソース管理部とを備え、
   前記通知部は、前記リソースの再取得が必要となる所定の場合に、前記業務リソース管理部に対し、前記リソースの再取得を要求し、
   前記通知部は、前記連携サービスのシナリオ実行状況が管理されるステータスと、要求元の属性情報と、前記要求元への通知契機とに基づき、情報をフィルタリングして前記サービス事業者に前記完了通知をし、
   前記フィルタリングにおいて、一部オーダ処理が失敗した場合に、通知不要とする、または、前記属性情報に示す条件を満たす部分のみを通知する
   ことを特徴とするサービス連携装置。
2. 複数種類のサービスが連携した連携サービスを実行するサービス連携装置における通知方法であって、
   前記サービス連携装置は、
   前記サービスおよび前記連携サービスの実行に関するリソースを記憶して管理する業務リソース管理部を備えており、
   前記連携サービスのサービスオーダを含む要求をサービス事業者から受領するステップと、
   前記連携サービスを構成するサービスごとに用意されるアダプタの各々が、対応の前記サービスのＡＰＩを実行して、前記サービスオーダのうち、対応の前記サービスのサービスオーダ部分を処理するステップと、
   前記サービスオーダ部分の処理がすべて完了した場合、前記サービス事業者に前記サービスオーダの完了通知をするステップと、
   前記リソースの再取得が必要となる所定の場合に、前記業務リソース管理部に対し、前記リソースの再取得を要求するステップと、
   前記連携サービスのシナリオ実行状況が管理されるステータスと、要求元の属性情報と、前記要求元への通知契機とに基づき、情報をフィルタリングして前記サービス事業者に前記完了通知をするステップと、
   前記フィルタリングにおいて、一部オーダ処理が失敗した場合に、通知不要とする、または、前記属性情報に示す条件を満たす部分のみを通知するステップとを実行する、
   ことを特徴とする通知方法。

Images