JP2021157345A

JP2021157345A - データ連携システムおよびａｐｉプラットフォーム

Info

Publication number: JP2021157345A
Application number: JP2020055182A
Authority: JP
Inventors: 孝記中島; Takanori Nakajima
Original assignee: Kyocera Document Solutions Inc
Current assignee: Kyocera Document Solutions Inc
Priority date: 2020-03-25
Filing date: 2020-03-25
Publication date: 2021-10-07
Anticipated expiration: 2040-03-25
Also published as: JP7473870B2

Abstract

【課題】障害が発生した場合の振る舞いを実行することができるデータ連携システムおよびＡＰＩプラットフォームを提供する。【解決手段】データ連携システムは、データ収集システムによって収集された、情報システムが保持しているデータを蓄積するデータ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩを提供するＡＰＩプラットフォームを備え、ＡＰＩプラットフォームは、ＡＰＩの利用の要求に応じた、データ蓄積システムからデータを取得する処理の要求を保持するキューと、データ蓄積システムからデータを取得する処理を、キューによって保持されている要求に応じて実行するバックエンドとを備え、バックエンドは、データ蓄積システムに障害が発生している場合に、データ蓄積システムからデータを取得する処理を停止する（Ｓ１４９）ことを特徴とする。【選択図】図８

Description

本発明は、複数の情報システムが保持しているデータを収集して蓄積するデータ連携システムおよびＡＰＩプラットフォームに関する。

従来、ＳａａＳ（ＳｏｆｔｗａｒｅａｓａＳｅｒｖｉｃｅ）間でのデータ連携処理に対応した所定アルゴリズムの実行結果を取得するＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を提供するシステムが知られている（例えば、特許文献１参照。）。

特開２０１６−２２４５７８号公報

しかしながら、特許文献１には、障害が発生した場合の振る舞いについては記載されていない。

そこで、本発明は、障害が発生した場合の振る舞いを実行することができるデータ連携システムおよびＡＰＩプラットフォームを提供することを目的とする。

本発明のデータ連携システムは、情報システムが保持しているデータを収集するデータ収集システムと、前記データ収集システムによって収集されたデータを蓄積するデータ蓄積システムと、前記データ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォームとを備え、前記ＡＰＩプラットフォームは、前記ＡＰＩの利用の要求に応じた、前記データ蓄積システムからデータを取得する処理の要求を保持する処理要求保持部と、前記データ蓄積システムからデータを取得する処理を、前記処理要求保持部によって保持されている要求に応じて実行する処理実行部とを備え、前記処理実行部は、前記データ蓄積システムに障害が発生している場合に、前記データ蓄積システムからデータを取得する処理を停止することを特徴とする。

この構成により、本発明のデータ連携システムは、データ蓄積システムに障害が発生している場合に、データ蓄積システムからデータを取得する処理を停止するので、障害が発生した場合の振る舞いを実行することができる。

本発明のデータ連携システムにおいて、前記ＡＰＩプラットフォームは、前記ＡＰＩの利用の要求に応じた、前記データ蓄積システムからデータを取得する処理の要求を、前記処理要求保持部に保持させる保持処理部を備え、前記保持処理部は、前記データ蓄積システムに障害が発生している場合に、前記データ蓄積システムに障害が発生しているという情報を、前記処理要求保持部に保持させる要求に含めて、この要求を前記処理要求保持部に保持させ、前記処理実行部は、前記データ蓄積システムからデータを取得する処理を、前記処理要求保持部によって保持されている要求に応じて実行する場合に、前記データ蓄積システムに障害が発生しているという情報が、この要求に含まれていないとき、前記データ蓄積システムからデータを取得する処理を実行し、前記処理実行部は、前記データ蓄積システムからデータを取得する処理を、前記処理要求保持部によって保持されている要求に応じて実行する場合に、前記データ蓄積システムに障害が発生しているという情報が、この要求に含まれるとき、前記データ蓄積システムに障害が発生しているか否かを問い合わせても良い。

この構成により、本発明のデータ連携システムは、データ蓄積システムに障害が発生している場合に、データ蓄積システムに障害が発生しているという情報を、処理要求保持部に保持させる要求に含めて、この要求を保持処理部が処理要求保持部に保持させ、データ蓄積システムからデータを取得する処理を、処理要求保持部によって保持されている要求に応じて処理実行部が実行する場合に、データ蓄積システムに障害が発生しているという情報が、この要求に含まれていないとき、データ蓄積システムからデータを取得する処理を処理実行部が実行し、データ蓄積システムに障害が発生しているという情報が、この要求に含まれるとき、データ蓄積システムに障害が発生しているか否かを処理実行部が問い合わせるので、データ蓄積システムに障害が発生しているか否かを処理実行部が問い合わせる負担を軽減することができ、その結果、データ蓄積システムからデータを取得する処理を実行する処理実行部の負担を軽減することができる。

本発明のデータ連携システムにおいて、前記ＡＰＩプラットフォームは、前記ＡＰＩの利用の要求を受け付ける要求受付部を備え、前記要求受付部は、前記処理要求保持部によって保持されている要求の数が特定の数以上になった場合に、前記ＡＰＩの利用の要求の受け付けを停止しても良い。

この構成により、本発明のデータ連携システムは、処理要求保持部によって保持されている要求の数が特定の数以上になった場合に、ＡＰＩの利用の要求の受け付けを要求受付部が停止するので、データ連携システム全体がダウンする可能性を低減することができ、その結果、データ連携システム全体を安定稼働させることができる。

本発明のデータ連携システムにおいて、前記要求受付部は、前記ＡＰＩの利用の要求の受け付けを停止している場合に、前記データ蓄積システムにおける障害が解消しているとき、前記ＡＰＩの利用の要求の受け付けを開始しても良い。

この構成により、本発明のデータ連携システムは、ＡＰＩの利用の要求の受け付けを停止している場合に、データ蓄積システムにおける障害が解消しているとき、ＡＰＩの利用の要求の受け付けを要求受付部が開始するので、ＡＰＩの利用の要求に応じた、データ蓄積システムからデータを取得する処理を効率的に実行することができる。

本発明のＡＰＩプラットフォームは、情報システムが保持しているデータを収集するデータ収集システムによって収集されたデータを蓄積するデータ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォームであって、前記ＡＰＩの利用の要求に応じた、前記データ蓄積システムからデータを取得する処理の要求を保持する処理要求保持部と、前記データ蓄積システムからデータを取得する処理を、前記処理要求保持部によって保持されている要求に応じて実行する処理実行部とを備え、前記処理実行部は、前記データ蓄積システムに障害が発生している場合に、前記データ蓄積システムからデータを取得する処理を停止することを特徴とする。

この構成により、本発明のＡＰＩプラットフォームは、データ蓄積システムに障害が発生している場合に、データ蓄積システムからデータを取得する処理を停止するので、障害が発生した場合の振る舞いを実行することができる。

本発明のデータ連携システムおよびＡＰＩプラットフォームは、障害が発生した場合の振る舞いを実行することができる。

本発明の一実施の形態に係るシステムのブロック図である。図１に示すＡＰＩプラットフォームのブロック図である。図２に示す処理困難性情報の一例を示す図である。図２に示すＡＰＩコントローラーによって取得される予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンの一例を示す図である。図２に示すキューの識別情報であるキューＩＤと、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンとの対応関係の一例を示す図である。外部システムからのＡＰＩの利用の要求を示す処理要求メッセージをキューに格納する場合の図１に示すシステムの概略の動作のシーケンス図である。処理要求メッセージを格納するキューを特定する場合の図１に示すシステムの動作のシーケンス図である。処理要求メッセージをキューから取り出す場合の図１に示すシステムの概略の動作のシーケンス図である。図８に示す「応答」シーケンス図である。外部システムから利用が要求されたＡＰＩに応じた処理の実行の困難性をフロントエンドコントローラーに通知する場合の図２に示すＡＰＩコントローラーの動作のフローチャートである。外部システムから利用が要求されたＡＰＩに応じた処理をデータ作成部インスタンスが実行することが困難であるか否かを、いずれかのＡＰＩコントローラーから通知された場合の図２に示すフロントエンドコントローラーの動作のフローチャートである。フロントエンド部に備えられる全てのフロントエンドＰｒｏｘｙに新規の接続の受け付けを停止させている場合の図２に示すフロントエンドコントローラーの動作のフローチャートである。外部システムからＡＰＩプラットフォームへのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習する場合の図１に示すシステムの動作のシーケンス図である。

以下、本発明の実施の形態について、図面を用いて説明する。

まず、本発明の一実施の形態に係るシステムの構成について説明する。

図１は、本実施の形態に係るシステム１０のブロック図である。

図１に示すように、システム１０は、データを生み出すデータソース部２０と、データソース部２０によって生み出されたデータを連携するデータ連携システム３０とを備えている。

データソース部２０は、データを生み出す情報システム２１を備えている。情報システム２１は、情報システム２１の構成や設定を保存する構成管理サーバー２１ａを備えている。データソース部２０は、情報システム２１以外にも、少なくとも１つの情報システムを備えていても良い。情報システムの例としては、ＭＦＰ（ＭｕｌｔｉｆｕｎｃｔｉｏｎＰｅｒｉｐｈｅｒａｌ）、プリンター専用機などの画像形成装置を遠隔で管理する遠隔管理システムなどのＩｏＴ（ＩｎｔｅｒｎｅｔｏｆＴｈｉｎｇｓ）システムと、ＥＲＰ（ＥｎｔｅｒｐｒｉｓｅＲｅｓｏｕｒｃｅＰｌａｎｎｉｎｇ）、生産管理システムなどの社内システムとが存在する。情報システムのそれぞれは、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。情報システムのそれぞれは、パブリック・クラウド上に構築されても良い。情報システムは、構造化データのファイルを保持しても良い。情報システムは、非構造化データのファイルを保持しても良い。情報システムは、構造化データのデータベースを保持しても良い。

データソース部２０は、情報システムが保持している、構造化データまたは非構造化データのファイルを取得して、取得したファイルをデータ連携システム３０の後述のパイプラインに送信するデータ収集システムとしてのＰＯＳＴコネクター２２を備えている。データソース部２０は、ＰＯＳＴコネクター２２と同様の構成のＰＯＳＴコネクターをＰＯＳＴコネクター２２以外に少なくとも１つ備えても良い。ＰＯＳＴコネクターは、ＰＯＳＴコネクター自身がファイルを取得する情報システムを構成するコンピューターによって構成されても良い。なお、ＰＯＳＴコネクターは、データ連携システム３０の構成でもある。

データソース部２０は、情報システムが保持している構造化データのデータベースから構造化データを取得して、取得した構造化データをデータ連携システム３０の後述のパイプラインに送信するデータ収集システムとしてのＰＯＳＴエージェント２３を備えている。データソース部２０は、ＰＯＳＴエージェント２３と同様の構成のＰＯＳＴエージェントをＰＯＳＴエージェント２３以外に少なくとも１つ備えても良い。ＰＯＳＴエージェントは、ＰＯＳＴエージェント自身が構造化データを取得する情報システムを構成するコンピューターによって構成されても良い。なお、ＰＯＳＴエージェントは、データ連携システム３０の構成でもある。

データソース部２０は、情報システムが保持しているデータに基づいて連携用の構造化データを生成するデータ収集システムとしてのＧＥＴ用エージェント２４を備えている。データソース部２０は、ＧＥＴ用エージェント２４と同様の構成のＧＥＴ用エージェントをＧＥＴ用エージェント２４以外に少なくとも１つ備えても良い。ＧＥＴ用エージェントは、連携用の構造化データの生成の元になったデータを保持している情報システムを構成するコンピューターによって構成されても良い。なお、ＧＥＴ用エージェントは、データ連携システム３０の構成でもある。

データ連携システム３０は、データソース部２０によって生み出されたデータを蓄積するデータ蓄積システム４０と、データ蓄積システム４０に蓄積されているデータを利用するアプリケーション部５０と、データ蓄積システム４０およびアプリケーション部５０に対する各種の制御を実行する制御サービス部６０とを備えている。

データ蓄積システム４０は、データソース部２０によって生み出されたデータを蓄積するパイプライン４１を備えている。データ蓄積システム４０は、パイプライン４１以外にも、少なくとも１つのパイプラインを備えていても良い。情報システムにおけるデータの構成が情報システム毎に異なる可能性があるので、データ蓄積システム４０は、基本的に、情報システム毎にパイプラインを備えている。パイプラインのそれぞれは、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。

データ蓄積システム４０は、情報システムが保持している、構造化データまたは非構造化データのファイルを取得して、取得したファイルをパイプラインに連携するデータ収集システムとしてのＧＥＴコネクター４２を備えている。データ蓄積システム４０は、ＧＥＴコネクター４２と同様の構成のＧＥＴコネクターをＧＥＴコネクター４２以外に少なくとも１つ備えても良い。ＧＥＴコネクターは、ＧＥＴコネクター自身がファイルを連携するパイプラインを構成するコンピューターによって構成されても良い。

なお、システム１０は、構造化データまたは非構造化データのファイルがデータ蓄積システム４０側から取得されることに対応していない情報システムに対しては、データソース部２０にＰＯＳＴコネクターを備える。一方、システム１０は、構造化データまたは非構造化データのファイルがデータ蓄積システム４０側から取得されることに対応している情報システムに対しては、データ蓄積システム４０にＧＥＴコネクターを備える。

データ蓄積システム４０は、ＧＥＴ用エージェントによって生成された構造化データを取得して、取得した構造化データをパイプラインに連携するデータ収集システムとしてのＧＥＴエージェント４３を備えている。データ蓄積システム４０は、ＧＥＴエージェント４３と同様の構成のＧＥＴエージェントをＧＥＴエージェント４３以外に少なくとも１つ備えても良い。ＧＥＴエージェントは、ＧＥＴエージェント自身が構造化データを連携するパイプラインを構成するコンピューターによって構成されても良い。

なお、システム１０は、構造化データがデータ蓄積システム４０側から取得されることに対応していない情報システムに対しては、データソース部２０にＰＯＳＴエージェントを備える。一方、システム１０は、構造化データがデータ蓄積システム４０側から取得されることに対応している情報システムに対しては、データソース部２０にＧＥＴ用エージェントを備えるとともに、データ蓄積システム４０にＧＥＴエージェントを備える。

データ蓄積システム４０は、複数のパイプラインによって蓄積されたデータを、例えばＳＱＬなどのデータベース言語などのクエリー言語で検索や集計が可能な形態に変換するデータ変換処理として最終変換処理を実行するデータ変換システムとしてのビッグデータ解析部４４を備えている。ビッグデータ解析部４４は、最終変換処理を実行したデータに対して、アプリケーション部５０側からの検索要求や集計要求に応じて検索や集計を実行することも可能である。ビッグデータ解析部４４は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。

最終変換処理は、複数の情報システムのデータを統合するデータ統合処理をデータ変換処理として含んでいても良い。アジアに配置されている多数の画像形成装置を遠隔で管理するためにアジアに配置されている遠隔管理システムと、ヨーロッパに配置されている多数の画像形成装置を遠隔で管理するためにヨーロッパに配置されている遠隔管理システムと、アメリカに配置されている多数の画像形成装置を遠隔で管理するためにアメリカに配置されている遠隔管理システムとをシステム１０が情報システムとして備えている場合、これら３つの遠隔管理システムは、それぞれ、遠隔管理システム自身が管理している画像形成装置を管理するデバイス管理テーブルを備えている。デバイス管理テーブルは、画像形成装置毎に付与したＩＤに対応付けて、画像形成装置の各種の情報を示す情報である。ここで、３つの遠隔管理システムがそれぞれ独自にデバイス管理テーブルを備えているので、３つの遠隔管理システムのデバイス管理テーブル間においては、別々の画像形成装置に同一のＩＤが付与されている可能性がある。そこで、ビッグデータ解析部４４は、３つの遠隔管理システムのデバイス管理テーブルを統合して１つのデバイス管理テーブルを生成する場合に、画像形成装置のＩＤを重複が生じないように付与し直す。

アプリケーション部５０は、ビッグデータ解析部４４によって管理されているデータを利用して、例えばデータの表示や、データの分析など、利用者によって指示された特定の動作を実行するアプリケーションサービス５１を備えている。アプリケーション部５０は、アプリケーションサービス５１以外にも、少なくとも１つのアプリケーションサービスを備えていても良い。アプリケーションサービスのそれぞれは、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。アプリケーションサービスは、例えば、ＢＩ（ＢｕｓｉｎｅｓｓＩｎｔｅｌｌｉｇｅｎｃｅ）ツール、ＳａａＳ（ＳｏｆｔｗａｒｅａｓａＳｅｒｖｉｃｅ）サーバーなどである。

アプリケーション部５０は、ビッグデータ解析部４４によって管理されているデータを利用して特定の動作を実行するＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォーム５２を備えている。ＡＰＩプラットフォーム５２は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。ＡＰＩプラットフォーム５２によって提供されるＡＰＩは、システム１０の外部の、例えば、ＢＩツール、ＳａａＳサーバーなどのシステムから呼び出されても良いし、アプリケーション部５０のアプリケーションサービスから呼び出されても良い。ＡＰＩプラットフォーム５２によって提供されるＡＰＩは、データ蓄積システム４０によって蓄積されているデータに基づいたデータをデータ蓄積システム４０から取得するためのＡＰＩである。例えば、ＡＰＩプラットフォーム５２によって提供されるＡＰＩとしては、画像形成装置のトナーなどの消耗品の残量が特定の量以下である場合に消耗品を発注する、システム１０の外部の消耗品発注システムに、遠隔管理システムによって画像形成装置から収集された消耗品の残量のデータを送信するＡＰＩと、画像形成装置の故障を予測する、システム１０の外部の故障予測システムに、遠隔管理システムによって画像形成装置から収集された各種のデータを送信するＡＰＩと、遠隔管理システムによって画像形成装置から収集された、印刷枚数を示すカウンター情報を、システム１０の外部のシステムに送信するＡＰＩと、システム１０の利用者の利用状況を示すデータをシステム１０の外部のシステムに送信するＡＰＩと、システム１０が管理しているデータに基づいた任意のデータを取得するための検索クエリーを受け付けるためのＡＰＩとが存在する。

以下、ＡＰＩプラットフォーム５２の外部のシステムを単に外部システムという。外部システムには、システム１０の外部のシステムや、アプリケーション部５０のアプリケーションサービスが含まれる。

図２は、ＡＰＩプラットフォーム５２のブロック図である。

図２に示すように、ＡＰＩプラットフォーム５２は、外部システムからのＡＰＩの利用の要求を受け付けるフロントエンド部７０と、フロントエンド部７０が受け付けた要求に応じた応答データを作成するデータ作成部８０とを備えている。

フロントエンド部７０は、外部システムに公開されるエンドポイントであるＬＢ（ＬｏａｄＢａｌａｎｃｅｒ）７１と、外部システムとの接続を確立するフロントエンドＰｒｏｘｙ７２とを備えている。フロントエンド部７０は、フロントエンドＰｒｏｘｙ７２以外にも、フロントエンドＰｒｏｘｙ７２と同様の構成のフロントエンドＰｒｏｘｙを少なくとも１つ備えていても良い。フロントエンド部７０は、フロントエンドＰｒｏｘｙの状態監視を行うフロントエンドコントローラー７３を備えている。

ＬＢ７１は、外部システムからのＡＰＩの利用の要求をラウンドロビン方式によっていずれかのフロントエンドＰｒｏｘｙに通知する。フロントエンドＰｒｏｘｙは、ＡＰＩの利用の要求を受け付けるものであり、本発明の要求受付部を構成している。

フロントエンドＰｒｏｘｙ７２は、ＬＢ７１から通知された、ＡＰＩの利用の要求をラウンドロビン方式によって、後述の、いずれかのＡＰＩサーバーに通知する。

フロントエンドコントローラー７３は、外部システムから利用が要求されたＡＰＩに応じた処理の実行の困難性を示す処理困難性情報７３ａ（図３参照。）を管理している。

図３は、処理困難性情報７３ａの一例を示す図である。

図３に示す処理困難性情報７３ａは、外部システムから利用が要求されたＡＰＩに応じた処理の実行の困難性を、後述のデータ作成部インスタンスの識別情報であるデータ作成部インスタンスＩＤ毎に示す情報である。外部システムから利用が要求されたＡＰＩに応じた処理の実行の困難性には、外部システムから利用が要求されたＡＰＩに応じた処理の実行が困難である状態と、外部システムから利用が要求されたＡＰＩに応じた処理の実行が困難ではない状態との２種類の状態が存在する。

図２に示すように、データ作成部８０は、データ作成部インスタンス８１を備えている。データ作成部８０は、データ作成部インスタンス８１以外にも、データ作成部インスタンス８１と同様の構成のデータ作成部インスタンスを少なくとも１つ備えていても良い。

データ作成部インスタンス８１は、ビッグデータ解析部４４（図１参照。）によって管理されているデータを利用して特定の動作を実行するＡＰＩを提供するＡＰＩサーバー８２を備えている。ＡＰＩサーバー８２は、ＡＰＩの利用の要求に応じた、データ蓄積システム４０からデータを取得する処理の要求を、後述のキューに保持させるものであり、本発明の保持処理部を構成している。データ作成部インスタンス８１は、ＡＰＩサーバー８２以外にも、ＡＰＩサーバー８２と同様の構成のＡＰＩサーバーを少なくとも１つ備えていても良い。

データ作成部インスタンス８１は、外部システムからのＡＰＩの利用の要求に対して応答するデータの取得の処理にかかると予測される時間（以下「予測処理時間」という。）の程度を示す予測処理時間レベルと、外部システムからのＡＰＩの利用の要求に対して応答することが予測されるデータの量（以下「予測応答データ量」という。）の程度を示す予測応答データ量レベルとを制御サービス部６０（図１参照。）から取得するＡＰＩコントローラー８３を備えている。

図４は、ＡＰＩコントローラー８３によって取得される予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンの一例を示す図である。

図４に示す例において、予測処理時間レベルは、予測処理時間が特定の範囲内であることを示す「普通」と、予測処理時間が特定の範囲の上限より長いことを示す「長」と、予測処理時間が特定の範囲の下限より短いことを示す「短」とを含んでいる。予測応答データ量レベルは、予測応答データ量が特定の範囲内であることを示す「普通」と、予測応答データ量が特定の範囲の上限より多いことを示す「多」と、予測応答データ量が特定の範囲の下限より少ないことを示す「少」とを含んでいる。図４に示す例において、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンは、パターンＡ〜パターンＩの９パターンである。

図２に示すように、データ作成部インスタンス８１は、外部システムから利用が要求されたＡＰＩに応じた処理の要求を示す処理要求メッセージを格納する処理要求保持部としてのキュー８４を備えている。データ作成部インスタンス８１は、キュー８４以外にも、キュー８４と同様の構成のキューを少なくとも１つ備えていても良い。キューは、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに基づいた分類毎に設けられている。

図５は、キューの識別情報であるキューＩＤと、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンとの対応関係の一例を示す図である。

図５に示すように、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに基づいた分類は、例えば、パターンＡおよびパターンＤが同一の分類でも良いし、パターンＨおよびパターンＩが同一の分類でも良い。なお、図５は、一部のキューについての情報が省略されて描かれている。

図２に示すように、データ作成部インスタンス８１は、キュー８４に格納されている処理要求メッセージが示す、処理の要求をビッグデータ解析部４４（図１参照。）に送信するサーバーであるバックエンド８５を備えている。バックエンド８５は、データ蓄積システム４０からデータを取得する処理を、キュー８４によって保持されている処理要求メッセージに応じて実行するものであり、本発明の処理実行部を構成している。データ作成部インスタンス８１は、バックエンド８５以外にも、バックエンド８５と同様の構成のバックエンドを少なくとも１つ備えていても良い。バックエンドは、キュー毎に設けられている。バックエンドは、１つのキューに対して複数備えても良い。キューに格納された処理要求メッセージは、このキューに対応付けられているバックエンドのうち、処理要求メッセージを処理可能な状態のバックエンドによって、このキューから順番に取り出される。

図１に示すように、制御サービス部６０は、データソース部２０、データ蓄積システム４０およびアプリケーション部５０におけるデータに対する各段階の処理を監視する処理監視システムとしてのパイプライン・オーケストレーター６１を備えている。パイプライン・オーケストレーター６１は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。

パイプライン・オーケストレーター６１は、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求毎に、この要求に対して応答するデータの取得の処理にかかった時間（以下「処理時間」という。）と、この要求に対して応答したデータの量（以下「応答データ量」という。）とを履歴として記憶する。そして、パイプライン・オーケストレーター６１は、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習することによって、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容に対して、予測処理時間レベルおよび予測応答データ量レベルを判定することが可能である。

制御サービス部６０は、データ蓄積システム４０の構成や設定を保存し、必要に応じて自動的にデプロイを実行する構成管理サーバー６２を備えている。構成管理サーバー６２は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。構成管理サーバー６２は、データ連携システム３０の構成を変更する構成変更システムを構成している。

制御サービス部６０は、情報システムの構成管理サーバーに接続し、情報システムにおけるデータベースや非構造化データに関する構成の変更、すなわち、情報システムにおけるデータの構成の変更を検出するための情報を収集する構成管理ゲートウェイ６３を備えている。構成管理ゲートウェイ６３は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。

制御サービス部６０は、情報システムなどの各システム間を連携するために必要な鍵情報や接続文字列などのセキュリティー情報を暗号化して保管するＫｅｙ管理サービス６４を備えている。Ｋｅｙ管理サービス６４は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。

制御サービス部６０は、データ蓄積システム４０やアプリケーション部５０からの要求を受け付ける管理ＡＰＩ６５を備えている。管理ＡＰＩ６５は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。

制御サービス部６０は、アプリケーション部５０のアプリケーションサービスの認証認可を実行する認証認可サービス６６を備えている。認証認可サービス６６は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。認証認可サービス６６は、例えば、データ蓄積システム４０に蓄積されている情報システムのデータの最新化を要求することをアプリケーションサービスが許可されているか否かを確認することができる。

次に、外部システムからのＡＰＩの利用の要求を示す処理要求メッセージをキューに格納する場合のシステム１０の動作について説明する。

図６は、外部システム９０からのＡＰＩの利用の要求を示す処理要求メッセージをキューに格納する場合のシステム１０の概略の動作のシーケンス図である。

図６に示すように、外部システム９０は、特定のＡＰＩの利用の要求を実行する場合、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）／ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）接続の確立をフロントエンド部７０のＬＢ７１に要求する（Ｓ１０１）。ここで、特定のＡＰＩの利用の要求は、例えば、ＨＴＴＰＳ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌＳｅｃｕｒｅ）で実行される。ＬＢ７１は、Ｓ１０１における要求を受けると、Ｓ１０１における要求を通知するフロントエンドＰｒｏｘｙをラウンドロビン方式によって特定し、特定したフロントエンドＰｒｏｘｙにＳ１０１における要求を通知する。以下においては、説明を簡略化するために、Ｓ１０１における要求がＬＢ７１から通知されたフロントエンドＰｒｏｘｙがフロントエンドＰｒｏｘｙ７２であるものとする。

フロントエンドＰｒｏｘｙ７２は、Ｓ１０１における要求がＬＢ７１から通知されると、外部システム９０との間でＴＣＰ／ＩＰ接続を確立する（Ｓ１０２）。

外部システム９０は、システム１０とのＴＣＰ／ＩＰ接続が確立されると、確立されたＴＣＰ／ＩＰ接続を介して特定のＡＰＩの利用の要求をフロントエンドＰｒｏｘｙ７２に通知する（Ｓ１０３）。

フロントエンドＰｒｏｘｙ７２は、Ｓ１０３においてＬＢ７１を介して外部システム９０から通知された、ＡＰＩの利用の要求をラウンドロビン方式によって、いずれかのＡＰＩサーバーに通知する（Ｓ１０４）。以下においては、説明を簡略化するために、Ｓ１０４において要求がフロントエンドＰｒｏｘｙ７２から通知されたＡＰＩサーバーがＡＰＩサーバー８２であるものとする。

ＡＰＩサーバー８２は、Ｓ１０４における通知を受けると、Ｓ１０４において通知された要求を解釈する（Ｓ１０５）。

図７は、処理要求メッセージを格納するキューを特定する場合のシステム１０の動作のシーケンス図である。

ＡＰＩサーバー８２は、Ｓ１０５における解釈を実行すると、図７に示すように、Ｓ１０５において解釈した要求の予測処理時間レベルおよび予測応答データ量レベルと、この要求に関連するパイプラインの状況とをＡＰＩコントローラー８３に問い合わせる（Ｓ１２１）。

ＡＰＩコントローラー８３は、Ｓ１２１における問い合わせを受けると、Ｓ１２１における問い合わせを制御サービス部６０の管理ＡＰＩ６５に通知する（Ｓ１２２）。

管理ＡＰＩ６５は、Ｓ１２２における通知を受けると、Ｓ１２２において通知された問い合わせをパイプライン・オーケストレーター６１に通知する（Ｓ１２３）。

パイプライン・オーケストレーター６１は、Ｓ１２３における通知を受けると、Ｓ１２３において通知された問い合わせの対象の要求、すなわち、Ｓ１０５においてＡＰＩサーバー８２によって解釈された要求の内容に対して、予測処理時間レベルおよび予測応答データ量レベルを判定する（Ｓ１２４）。

次いで、パイプライン・オーケストレーター６１は、Ｓ１２３において通知された問い合わせの対象の要求、すなわち、Ｓ１０５においてＡＰＩサーバー８２によって解釈された要求に関連するパイプラインの状況を判定する（Ｓ１２５）。ここで、パイプライン・オーケストレーター６１は、パイプラインがメンテナンス中である場合に、メンテナンス中であることが、このパイプラインから通知されている。したがって、パイプライン・オーケストレーター６１は、パイプラインがメンテナンス中である場合に、このパイプラインがメンテナンス中であるという状況を判定することができる。

パイプライン・オーケストレーター６１は、Ｓ１２５の処理の後、Ｓ１２４およびＳ１２５における判定の結果、すなわち、Ｓ１２４において判定した予測処理時間レベルおよび予測応答データ量レベルと、Ｓ１２５において判定したパイプラインの状況とを管理ＡＰＩ６５に通知する（Ｓ１２６）。

次いで、管理ＡＰＩ６５は、Ｓ１２６においてパイプライン・オーケストレーター６１から通知された、判定の結果をＡＰＩコントローラー８３に通知する（Ｓ１２７）。

次いで、ＡＰＩコントローラー８３は、Ｓ１２７において管理ＡＰＩ６５から通知された、判定の結果、すなわち、予測処理時間レベルおよび予測応答データ量レベルと、パイプラインの状況とをＡＰＩサーバー８２に返答する（Ｓ１２８）。

ＡＰＩサーバー８２は、Ｓ１２８における返答を受けると、Ｓ１２８において返答された予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに対応付けられているキューを特定する（Ｓ１２９）。

以下、説明を簡略化するために、Ｓ１２９において特定されたキューがキュー８４であるものとする。

図６に示すように、ＡＰＩサーバー８２は、Ｓ１０５における解釈を実行した後、Ｓ１２８における返答に含まれるパイプラインの状況がメンテナンス中である場合、Ｓ１０５において解釈した要求を示す処理要求メッセージを、パイプラインがメンテナンス中であることを示す情報（以下「メンテナンス中情報」という。）をメッセージヘッダーに入れて生成する（Ｓ１０６）。

一方、ＡＰＩサーバー８２は、Ｓ１２８における返答に含まれるパイプラインの状況がメンテナンス中ではない場合、Ｓ１０５において解釈した要求を示す処理要求メッセージを、メンテナンス中情報をメッセージヘッダーに入れずに生成する（Ｓ１０７）。

ＡＰＩサーバー８２は、Ｓ１０６またはＳ１０７の処理の後、Ｓ１０６またはＳ１０７において生成した処理要求メッセージを、図７に示す動作によって特定したキュー８４に格納する（Ｓ１０８）。ここで、ＡＰＩサーバー８２は、キュー８４に格納する処理要求メッセージをキュー８４に格納したＡＰＩサーバーとして、ＡＰＩサーバー８２自身の識別情報を、キュー８４に格納する処理要求メッセージに含める。

次に、処理要求メッセージをキューから取り出す場合のシステム１０の動作について説明する。

以下、説明を簡略化するために、処理要求メッセージを取り出すキューがキュー８４であり、キュー８４から処理要求メッセージを取り出すバックエンドがバックエンド８５であるものとする。

図８は、処理要求メッセージをキューから取り出す場合のシステム１０の概略の動作のシーケンス図である。図９は、図８に示す「応答」シーケンス図である。

図８および図９に示すように、バックエンド８５は、キュー８４に格納された処理要求メッセージの１つを、キュー８４から取り出す（Ｓ１４１）。

バックエンド８５は、Ｓ１４１においてキュー８４から取り出した処理要求メッセージのメッセージヘッダーにメンテナンス中情報が含まれている場合、処理要求メッセージが示す処理に関連するパイプラインの状況をＡＰＩコントローラー８３に問い合わせる（Ｓ１４２）。

ＡＰＩコントローラー８３は、Ｓ１４２における問い合わせを受けると、Ｓ１４２における問い合わせを制御サービス部６０の管理ＡＰＩ６５に通知する（Ｓ１４３）。

管理ＡＰＩ６５は、Ｓ１４３における通知を受けると、Ｓ１４３において通知された問い合わせをパイプライン・オーケストレーター６１に通知する（Ｓ１４４）。

パイプライン・オーケストレーター６１は、Ｓ１４４における通知を受けると、Ｓ１４４において通知された問い合わせの対象のパイプラインの状況を判定する（Ｓ１４５）。

パイプライン・オーケストレーター６１は、Ｓ１４５の処理の後、Ｓ１４５における判定の結果、すなわち、Ｓ１４５において判定したパイプラインの状況を管理ＡＰＩ６５に通知する（Ｓ１４６）。

次いで、管理ＡＰＩ６５は、Ｓ１４６においてパイプライン・オーケストレーター６１から通知された、判定の結果をＡＰＩコントローラー８３に通知する（Ｓ１４７）。

次いで、ＡＰＩコントローラー８３は、Ｓ１４７において管理ＡＰＩ６５から通知された、判定の結果、すなわち、パイプラインの状況をバックエンド８５に返答する（Ｓ１４８）。

バックエンド８５は、Ｓ１４８の返答を受けると、Ｓ１４８における返答に含まれるパイプラインの状況がメンテナンス中である場合、Ｓ１４１においてキュー８４から取り出した処理要求メッセージを、キュー８４に戻す（Ｓ１４９）。

一方、バックエンド８５は、Ｓ１４８における返答に含まれるパイプラインの状況がメンテナンス中ではない場合、Ｓ１４１においてキュー８４から取り出した処理要求メッセージが示す、処理の要求をビッグデータ解析部４４に送信する（Ｓ１６１）。

ビッグデータ解析部４４は、処理の要求がＳ１６１において送信されてくると、Ｓ１６１において送信されてきた要求に応じた処理を実行することによって、この処理に応じたデータを取得する（Ｓ１６２）。

次いで、ビッグデータ解析部４４は、Ｓ１６２において取得したデータをバックエンド８５に通知する（Ｓ１６３）。

バックエンド８５は、Ｓ１６３においてデータが通知されると、Ｓ１４１においてキュー８４から取り出した処理要求メッセージをキュー８４に格納したＡＰＩサーバー８２に、Ｓ１６３において通知されたデータを通知する（Ｓ１６４）。なお、Ｓ１４１においてキュー８４から取り出された処理要求メッセージには、この処理要求メッセージをキュー８４に格納したＡＰＩサーバー８２の識別情報が含まれている。

ＡＰＩサーバー８２は、Ｓ１６４においてデータが通知されると、このデータをフロントエンドＰｒｏｘｙ７２に通知する（Ｓ１６５）。

したがって、フロントエンドＰｒｏｘｙ７２は、Ｓ１６５において通知されたデータを、ＬＢ７１経由で外部システム９０に応答する（Ｓ１６６）。なお、フロントエンドＰｒｏｘｙ７２は、Ｓ１０２において確立したＴＣＰ／ＩＰ接続を、Ｓ１６６における応答の終了後に終了する。

システム１０は、バックエンド８５がＳ１４１においてキュー８４から取り出した処理要求メッセージのメッセージヘッダーにメンテナンス中情報が含まれていない場合、Ｓ１６１〜Ｓ１６６の処理を実行する。

次に、外部システムから利用が要求されたＡＰＩに応じた処理の実行の困難性をフロントエンドコントローラー７３に通知する場合のＡＰＩコントローラーの動作について説明する。

以下においては、説明を簡略化するために、ＡＰＩコントローラーを代表して、ＡＰＩコントローラー８３について説明する。

図１０は、外部システムから利用が要求されたＡＰＩに応じた処理の実行の困難性をフロントエンドコントローラー７３に通知する場合のＡＰＩコントローラー８３の動作のフローチャートである。

図１０に示すように、ＡＰＩコントローラー８３は、ＡＰＩコントローラー８３自身を備えるデータ作成部インスタンス８１に備えられる全てのキューのそれぞれに格納されている処理要求メッセージの数が特定の個数以上になったと判断するまで、ＡＰＩコントローラー８３自身を備えるデータ作成部インスタンス８１に備えられる全てのキューのそれぞれに格納されている処理要求メッセージの数が特定の個数以上になったか否かを判断する（Ｓ１８１）。

ＡＰＩコントローラー８３は、ＡＰＩコントローラー８３自身を備えるデータ作成部インスタンス８１に備えられる全てのキューのそれぞれに格納されている処理要求メッセージの数が特定の個数以上になったとＳ１８１において判断すると、外部システムから利用が要求されたＡＰＩに応じた処理を、ＡＰＩコントローラー８３自身を備えるデータ作成部インスタンス８１が実行することが困難であることをフロントエンドコントローラー７３に通知する（Ｓ１８２）。

ＡＰＩコントローラー８３は、Ｓ１８２の処理の後、ＡＰＩコントローラー８３自身を備えるデータ作成部インスタンス８１に備えられるいずれかのキューに格納されている処理要求メッセージの数が特定の個数未満になったと判断するまで、ＡＰＩコントローラー８３自身を備えるデータ作成部インスタンス８１に備えられるいずれかのキューに格納されている処理要求メッセージの数が特定の個数未満になったか否かを判断する（Ｓ１８３）。

ＡＰＩコントローラー８３は、ＡＰＩコントローラー８３自身を備えるデータ作成部インスタンス８１に備えられるいずれかのキューに格納されている処理要求メッセージの数が特定の個数未満になったとＳ１８３において判断すると、外部システムから利用が要求されたＡＰＩに応じた処理を、ＡＰＩコントローラー８３自身を備えるデータ作成部インスタンス８１が実行することが困難ではないことをフロントエンドコントローラー７３に通知する（Ｓ１８４）。

ＡＰＩコントローラー８３は、Ｓ１８４の処理の後、Ｓ１８１の処理を実行する。

次に、外部システムから利用が要求されたＡＰＩに応じた処理をデータ作成部インスタンスが実行することが困難であるか否かを、いずれかのＡＰＩコントローラーから通知された場合のフロントエンドコントローラー７３の動作について説明する。

図１１は、外部システムから利用が要求されたＡＰＩに応じた処理をデータ作成部インスタンスが実行することが困難であるか否かを、いずれかのＡＰＩコントローラーから通知された場合のフロントエンドコントローラー７３の動作のフローチャートである。

フロントエンドコントローラー７３は、外部システムから利用が要求されたＡＰＩに応じた処理をデータ作成部インスタンスが実行することが困難であるか否かを、いずれかのＡＰＩコントローラーから通知される度に図１１に示す動作を実行する。

図１１に示すように、フロントエンドコントローラー７３は、ＡＰＩコントローラーから通知された内容で処理困難性情報７３ａを更新する（Ｓ２０１）。

次いで、フロントエンドコントローラー７３は、データ作成部８０に備えられる全てのデータ作成部インスタンスが、外部システムから利用が要求されたＡＰＩに応じた処理の実行が困難であるか否かを処理困難性情報７３ａに基づいて判断する（Ｓ２０２）。

フロントエンドコントローラー７３は、データ作成部８０に備えられるいずれかのデータ作成部インスタンスが、外部システムから利用が要求されたＡＰＩに応じた処理の実行が困難ではないとＳ２０２において判断すると、図１１に示す動作を終了する。

フロントエンドコントローラー７３は、データ作成部８０に備えられる全てのデータ作成部インスタンスが、外部システムから利用が要求されたＡＰＩに応じた処理の実行が困難であるとＳ２０２において判断すると、フロントエンド部７０に備えられる全てのフロントエンドＰｒｏｘｙに新規の接続の受け付けを停止させて（Ｓ２０３）、図１１に示す動作を終了する。

次に、フロントエンド部７０に備えられる全てのフロントエンドＰｒｏｘｙに新規の接続の受け付けを停止させている場合のフロントエンドコントローラー７３の動作について説明する。

図１２は、フロントエンド部７０に備えられる全てのフロントエンドＰｒｏｘｙに新規の接続の受け付けを停止させている場合のフロントエンドコントローラー７３の動作のフローチャートである。

フロントエンドコントローラー７３は、フロントエンド部７０に備えられる全てのフロントエンドＰｒｏｘｙに新規の接続の受け付けを停止させている場合に、図１２に示す動作を実行する。

図１２に示すように、フロントエンドコントローラー７３は、特定のタイミングになったと判断するまで、特定のタイミングになったか否かを判断する（Ｓ２２１）。ここで、特定のタイミングは、例えば、定期的なタイミングである。

フロントエンドコントローラー７３は、特定のタイミングになったとＳ２２１において判断すると、管理ＡＰＩ６５を介してパイプライン・オーケストレーター６１にパイプラインの状況を問い合わせる（Ｓ２２２）。

フロントエンドコントローラー７３は、Ｓ２２２の処理の後、メンテナンス中のパイプラインが存在するか否かをＳ２２２における問い合わせの結果に基づいて判断する（Ｓ２２３）。

フロントエンドコントローラー７３は、メンテナンス中のパイプラインが存在するとＳ２２３において判断すると、Ｓ２２１の処理を実行する。

フロントエンドコントローラー７３は、メンテナンス中のパイプラインが存在しないとＳ２２３において判断すると、フロントエンド部７０に備えられる全てのフロントエンドＰｒｏｘｙに新規の接続の受け付けを開始させて（Ｓ２２４）、図１２に示す動作を終了する。

次に、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習する場合のシステム１０の動作について説明する。

図１３は、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習する場合のシステム１０の動作のシーケンス図である。

バックエンド８５は、Ｓ１６１においてビッグデータ解析部４４への処理の要求の送信を開始すると、図１３に示すように、外部システムからのＡＰＩの利用の要求に対して応答するデータの取得の処理の開始をＡＰＩコントローラー８３に通知する（Ｓ２４１）。

次いで、バックエンド８５は、Ｓ１６３においてビッグデータ解析部４４からのデータの通知が終了すると、外部システムからのＡＰＩの利用の要求に対して応答するデータの取得の処理の終了と、Ｓ１６３においてビッグデータ解析部４４から通知されたデータの量とをＡＰＩコントローラー８３に通知する（Ｓ２４２）。

ＡＰＩコントローラー８３は、Ｓ２４２の通知を受けると、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、この要求に対する処理時間および応答データ量とをパイプライン・オーケストレーター６１に通知する（Ｓ２４３）。ここで、ＡＰＩコントローラー８３は、Ｓ２４１において処理の開始が通知された時間から、Ｓ２４２において処理の終了が通知された時間までの時間を処理時間として算出する。また、ＡＰＩコントローラー８３は、Ｓ２４２において通知された、データの量を、応答データ量とする。

パイプライン・オーケストレーター６１は、Ｓ２４３の通知を受けると、ＡＰＩコントローラー８３からこれまでに通知された、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習する（Ｓ２４４）。したがって、パイプライン・オーケストレーター６１は、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容に対して、予測処理時間レベルおよび予測応答データ量レベルを判定することが可能になる。

以上に説明したように、データ連携システム３０は、パイプラインがメンテナンス中である場合、すなわち、データ蓄積システム４０に障害が発生している場合に、データ蓄積システム４０からデータを取得する処理を停止する（Ｓ１４９）ので、障害が発生した場合の振る舞いを実行することができる。

データ連携システム３０は、データ蓄積システム４０に障害が発生している場合に、データ蓄積システム４０に障害が発生しているという情報、すなわち、メンテナンス中情報を、キューに保持させる要求に含めて（Ｓ１０６）、この要求をＡＰＩサーバーがキューに保持させ（Ｓ１０８）、データ蓄積システム４０からデータを取得する処理を、キューによって保持されている要求に応じてバックエンドが実行する（Ｓ１６１およびＳ１６３）場合に、メンテナンス中情報が、この要求に含まれていないとき、データ蓄積システム４０からデータを取得する処理をバックエンドが実行し、メンテナンス中情報が、この要求に含まれるとき、データ蓄積システム４０に障害が発生しているか否かをバックエンドが問い合わせる（Ｓ１４２）ので、データ蓄積システム４０に障害が発生しているか否かをバックエンドが問い合わせる負担を軽減することができ、その結果、データ蓄積システム４０からデータを取得する処理を実行するバックエンドの負担を軽減することができる。

データ連携システム３０は、キューによって保持されている要求の数が特定の数以上になった場合（Ｓ１８１でＹＥＳ）に、ＡＰＩの利用の要求の受け付けをフロントエンドＰｒｏｘｙが停止する（Ｓ２０３）ので、データ連携システム３０全体がダウンする可能性を低減することができ、その結果、データ連携システム３０全体を安定稼働させることができる。

データ連携システム３０は、ＡＰＩの利用の要求の受け付けを停止している場合に、データ蓄積システム４０における障害が解消しているとき（Ｓ２２３でＮＯ）、ＡＰＩの利用の要求の受け付けをフロントエンドＰｒｏｘｙが開始する（Ｓ２２４）ので、ＡＰＩの利用の要求に応じた、データ蓄積システム４０からデータを取得する処理を効率的に実行することができる。

データ連携システム３０は、データ蓄積システム４０からデータを取得する処理（Ｓ１６１およびＳ１６３）をＡＰＩの利用の要求に応じて実行するバックエンドを、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに基づいた分類毎に備えるので、データ蓄積システム４０からデータを取得する処理を、この処理の予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに応じた適切なバックエンドによって実行することができる。したがって、データ連携システム３０は、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。

特定の予測処理時間レベルに基づいた分類のバックエンドとしての特定処理時間バックエンドと、特定の予測処理時間レベルより予測処理時間が長い予測処理時間レベルに基づいた分類のバックエンドとしての処理時間長バックエンドとをＡＰＩプラットフォーム５２が備える場合に、処理時間長バックエンドは、メモリーの容量と、ネットワークの帯域との少なくとも１つが特定処理時間バックエンドより多くても良い。この構成により、データ連携システム３０は、データ蓄積システムからデータを取得する処理を、この処理の予測処理時間が長い場合に、この処理の予測処理時間が短い場合よりも、メモリーの容量と、ネットワークの帯域との少なくとも１つが多いバックエンドによって実行することができるので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。

特定の予測応答データ量レベルに基づいた分類のバックエンドとしての特定応答データ量バックエンドと、特定の予測応答データ量レベルより予測応答データ量が多い予測応答データ量レベルに基づいた分類のバックエンドとしての応答データ量多バックエンドとをＡＰＩプラットフォーム５２が備える場合に、応答データ量多バックエンドは、メモリーの容量と、ネットワークの帯域との少なくとも１つが特定応答データ量バックエンドより多くても良い。この構成により、データ連携システム３０は、データ蓄積システムからデータを取得する処理を、この処理の予測応答データ量が多い場合に、この処理の予測応答データ量が少ない場合よりも、メモリーの容量と、ネットワークの帯域との少なくとも１つが多いバックエンドによって実行することができるので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。

データ連携システム３０は、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに基づいた分類毎にキューおよびバックエンドを備えている。しかしながら、データ連携システム３０は、予測処理時間レベルおよび予測応答データ量レベルのいずれか１つに基づいた分類毎にキューおよびバックエンドを備えても良い。

２１情報システム
２２ＰＯＳＴコネクター（データ収集システム）
２３ＰＯＳＴエージェント（データ収集システム）
２４ＧＥＴ用エージェント（データ収集システム）
３０データ連携システム
４０データ蓄積システム
４２ＧＥＴコネクター（データ収集システム）
４３ＧＥＴエージェント（データ収集システム）
５２ＡＰＩプラットフォーム
７２フロントエンドＰｒｏｘｙ（要求受付部）
８２ＡＰＩサーバー（保持処理部）
８４キュー（処理要求保持部）
８５バックエンド（処理実行部）

Claims

情報システムが保持しているデータを収集するデータ収集システムと、
前記データ収集システムによって収集されたデータを蓄積するデータ蓄積システムと、
前記データ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォームと
を備え、
前記ＡＰＩプラットフォームは、
前記ＡＰＩの利用の要求に応じた、前記データ蓄積システムからデータを取得する処理の要求を保持する処理要求保持部と、
前記データ蓄積システムからデータを取得する処理を、前記処理要求保持部によって保持されている要求に応じて実行する処理実行部と
を備え、
前記処理実行部は、前記データ蓄積システムに障害が発生している場合に、前記データ蓄積システムからデータを取得する処理を停止することを特徴とするデータ連携システム。
前記ＡＰＩプラットフォームは、前記ＡＰＩの利用の要求に応じた、前記データ蓄積システムからデータを取得する処理の要求を、前記処理要求保持部に保持させる保持処理部を備え、
前記保持処理部は、前記データ蓄積システムに障害が発生している場合に、前記データ蓄積システムに障害が発生しているという情報を、前記処理要求保持部に保持させる要求に含めて、この要求を前記処理要求保持部に保持させ、
前記処理実行部は、前記データ蓄積システムからデータを取得する処理を、前記処理要求保持部によって保持されている要求に応じて実行する場合に、前記データ蓄積システムに障害が発生しているという情報が、この要求に含まれていないとき、前記データ蓄積システムからデータを取得する処理を実行し、
前記処理実行部は、前記データ蓄積システムからデータを取得する処理を、前記処理要求保持部によって保持されている要求に応じて実行する場合に、前記データ蓄積システムに障害が発生しているという情報が、この要求に含まれるとき、前記データ蓄積システムに障害が発生しているか否かを問い合わせることを特徴とする請求項１に記載のデータ連携システム。
前記ＡＰＩプラットフォームは、前記ＡＰＩの利用の要求を受け付ける要求受付部を備え、
前記要求受付部は、前記処理要求保持部によって保持されている要求の数が特定の数以上になった場合に、前記ＡＰＩの利用の要求の受け付けを停止することを特徴とする請求項１または請求項２に記載のデータ連携システム。
前記要求受付部は、前記ＡＰＩの利用の要求の受け付けを停止している場合に、前記データ蓄積システムにおける障害が解消しているとき、前記ＡＰＩの利用の要求の受け付けを開始することを特徴とする請求項３に記載のデータ連携システム。
情報システムが保持しているデータを収集するデータ収集システムによって収集されたデータを蓄積するデータ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォームであって、
前記ＡＰＩの利用の要求に応じた、前記データ蓄積システムからデータを取得する処理の要求を保持する処理要求保持部と、
前記データ蓄積システムからデータを取得する処理を、前記処理要求保持部によって保持されている要求に応じて実行する処理実行部と
を備え、
前記処理実行部は、前記データ蓄積システムに障害が発生している場合に、前記データ蓄積システムからデータを取得する処理を停止することを特徴とするＡＰＩプラットフォーム。