知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-03-05
(45)【発行日】2024-03-13
(54)【発明の名称】データ連携システムおよびＡＰＩプラットフォーム
(51)【国際特許分類】
G06F 9/50 20060101AFI20240306BHJP
【ＦＩ】
G06F9/50 120A
【請求項の数】
3
(21)【出願番号】P 2020055178
(22)【出願日】2020-03-25
(65)【公開番号】P2021157341
(43)【公開日】2021-10-07
【審査請求日】2023-02-24
(73)【特許権者】
【識別番号】000006150
【氏名又は名称】京セラドキュメントソリューションズ株式会社
(74)【代理人】
【識別番号】100140796
【弁理士】
【氏名又は名称】原口 貴志
(72)【発明者】
【氏名】中島 孝記
【審査官】漆原 孝治
(56)【参考文献】
【文献】特開２０１７－１８２５９６（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１９／０１０８０６８（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ９／５０
(57)【特許請求の範囲】
【請求項1】
情報システムが保持しているデータを収集するデータ収集システムと、前記データ収集システムによって収集されたデータを蓄積するデータ蓄積システムと、
前記データ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォームと
を備え、
前記ＡＰＩプラットフォームは、前記ＡＰＩの利用の要求に応じて前記データ蓄積システムからデータを取得する処理の未実行分の数が、前記処理の能力を増加させる特定の条件を満たす場合に、前記能力を増加させ、
前記ＡＰＩプラットフォームは、前記処理にかかると予測される時間である予測処理時間の程度を示す予測処理時間レベルと、前記要求に対して応答することが予測されるデータの量である予測応答データ量の程度を示す予測応答データ量レベルとの少なくとも１つに基づいた前記処理の分類毎に前記能力を変更させることを特徴とするデータ連携システム。
【請求項2】
前記ＡＰＩプラットフォームは、前記数が、前記能力を減少させる特定の条件を満たす場合に、前記能力を減少させることを特徴とする請求項１に記載のデータ連携システム。
【請求項3】
情報システムが保持しているデータを収集するデータ収集システムによって収集されたデータを蓄積するデータ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォームであって、
前記ＡＰＩの利用の要求に応じて前記データ蓄積システムからデータを取得する処理の未実行分の数が、前記処理の能力を増加させる特定の条件を満たす場合に、前記能力を増加させ、
前記処理にかかると予測される時間である予測処理時間の程度を示す予測処理時間レベルと、前記要求に対して応答することが予測されるデータの量である予測応答データ量の程度を示す予測応答データ量レベルとの少なくとも１つに基づいた前記処理の分類毎に前記能力を変更させることを特徴とするＡＰＩプラットフォーム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数の情報システムが保持しているデータを収集して蓄積するデータ連携システムおよびＡＰＩプラットフォームに関する。
【背景技術】
【0002】
従来、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）間でのデータ連携処理に対応した所定アルゴリズムの実行結果を取得するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供するシステムが知られている（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１６－２２４５７８号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、特許文献１には、ＡＰＩの利用の要求に応じて実行する処理の負担に応じた振る舞いについては記載されていない。
【0005】
そこで、本発明は、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができるデータ連携システムおよびＡＰＩプラットフォームを提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明のデータ連携システムは、情報システムが保持しているデータを収集するデータ収集システムと、前記データ収集システムによって収集されたデータを蓄積するデータ蓄積システムと、前記データ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォームとを備え、前記ＡＰＩプラットフォームは、前記ＡＰＩの利用の要求に応じて前記データ蓄積システムからデータを取得する処理の未実行分の数が、前記処理の能力を増加させる特定の条件を満たす場合に、前記能力を増加させることを特徴とする。
【0007】
この構成により、本発明のデータ連携システムは、ＡＰＩの利用の要求に応じてデータ蓄積システムからデータを取得する処理の未実行分の数が、この処理の能力を増加させる特定の条件を満たす場合に、この処理の能力を増加させるので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【0008】
本発明のデータ連携システムにおいて、前記ＡＰＩプラットフォームは、前記数が、前記能力を減少させる特定の条件を満たす場合に、前記能力を減少させても良い。
【0009】
この構成により、本発明のデータ連携システムは、ＡＰＩの利用の要求に応じてデータ蓄積システムからデータを取得する処理の未実行分の数が、この処理の能力を減少させる特定の条件を満たす場合に、この処理の能力を減少させるので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【0010】
本発明のデータ連携システムにおいて、前記ＡＰＩプラットフォームは、前記処理にかかると予測される時間である予測処理時間の程度を示す予測処理時間レベルと、前記要求に対して応答することが予測されるデータの量である予測応答データ量の程度を示す予測応答データ量レベルとの少なくとも１つに基づいた前記処理の分類毎に前記能力を変更させても良い。
【0011】
この構成により、本発明のデータ連携システムは、ＡＰＩの利用の要求に応じてデータ蓄積システムからデータを取得する処理の、予測処理時間レベルおよび予測応答データ量レベルの少なくとも１つに基づいた分類毎に、この処理の能力を変更させるので、この処理を、この処理の予測処理時間レベルおよび予測応答データ量レベルの少なくとも１つに応じた適切なサーバーによって実行することができる。したがって、本発明のデータ連携システムは、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【0012】
本発明のＡＰＩプラットフォームは、情報システムが保持しているデータを収集するデータ収集システムによって収集されたデータを蓄積するデータ蓄積システムによって蓄積されているデータに基づいたデータを前記データ蓄積システムから取得するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォームであって、前記ＡＰＩの利用の要求に応じて前記データ蓄積システムからデータを取得する処理の未実行分の数が、前記処理の能力を増加させる特定の条件を満たす場合に、前記能力を増加させることを特徴とする。
【0013】
この構成により、本発明のＡＰＩプラットフォームは、ＡＰＩの利用の要求に応じてデータ蓄積システムからデータを取得する処理の未実行分の数が、この処理の能力を増加させる特定の条件を満たす場合に、この処理の能力を増加させるので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【発明の効果】
【0014】
本発明のデータ連携システムおよびＡＰＩプラットフォームは、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【図面の簡単な説明】
【0015】
【図1】本発明の一実施の形態に係るシステムのブロック図である。
【発明を実施するための形態】
【0016】
以下、本発明の実施の形態について、図面を用いて説明する。
【0017】
まず、本発明の一実施の形態に係るシステムの構成について説明する。
【0018】
図１は、本実施の形態に係るシステム１０のブロック図である。
【0019】
図１に示すように、システム１０は、データを生み出すデータソース部２０と、データソース部２０によって生み出されたデータを連携するデータ連携システム３０とを備えている。
【0020】
データソース部２０は、データを生み出す情報システム２１を備えている。情報システム２１は、情報システム２１の構成や設定を保存する構成管理サーバー２１ａを備えている。データソース部２０は、情報システム２１以外にも、少なくとも１つの情報システムを備えていても良い。情報システムの例としては、ＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）、プリンター専用機などの画像形成装置を遠隔で管理する遠隔管理システムなどのＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）システムと、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）、生産管理システムなどの社内システムとが存在する。情報システムのそれぞれは、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。情報システムのそれぞれは、パブリック・クラウド上に構築されても良い。情報システムは、構造化データのファイルを保持しても良い。情報システムは、非構造化データのファイルを保持しても良い。情報システムは、構造化データのデータベースを保持しても良い。
【0021】
データソース部２０は、情報システムが保持している、構造化データまたは非構造化データのファイルを取得して、取得したファイルをデータ連携システム３０の後述のパイプラインに送信するデータ収集システムとしてのＰＯＳＴコネクター２２を備えている。データソース部２０は、ＰＯＳＴコネクター２２と同様の構成のＰＯＳＴコネクターをＰＯＳＴコネクター２２以外に少なくとも１つ備えても良い。ＰＯＳＴコネクターは、ＰＯＳＴコネクター自身がファイルを取得する情報システムを構成するコンピューターによって構成されても良い。なお、ＰＯＳＴコネクターは、データ連携システム３０の構成でもある。
【0022】
データソース部２０は、情報システムが保持している構造化データのデータベースから構造化データを取得して、取得した構造化データをデータ連携システム３０の後述のパイプラインに送信するデータ収集システムとしてのＰＯＳＴエージェント２３を備えている。データソース部２０は、ＰＯＳＴエージェント２３と同様の構成のＰＯＳＴエージェントをＰＯＳＴエージェント２３以外に少なくとも１つ備えても良い。ＰＯＳＴエージェントは、ＰＯＳＴエージェント自身が構造化データを取得する情報システムを構成するコンピューターによって構成されても良い。なお、ＰＯＳＴエージェントは、データ連携システム３０の構成でもある。
【0023】
データソース部２０は、情報システムが保持しているデータに基づいて連携用の構造化データを生成するデータ収集システムとしてのＧＥＴ用エージェント２４を備えている。データソース部２０は、ＧＥＴ用エージェント２４と同様の構成のＧＥＴ用エージェントをＧＥＴ用エージェント２４以外に少なくとも１つ備えても良い。ＧＥＴ用エージェントは、連携用の構造化データの生成の元になったデータを保持している情報システムを構成するコンピューターによって構成されても良い。なお、ＧＥＴ用エージェントは、データ連携システム３０の構成でもある。
【0024】
データ連携システム３０は、データソース部２０によって生み出されたデータを蓄積するデータ蓄積システム４０と、データ蓄積システム４０に蓄積されているデータを利用するアプリケーション部５０と、データ蓄積システム４０およびアプリケーション部５０に対する各種の制御を実行する制御サービス部６０とを備えている。
【0025】
データ蓄積システム４０は、データソース部２０によって生み出されたデータを蓄積するパイプライン４１を備えている。データ蓄積システム４０は、パイプライン４１以外にも、少なくとも１つのパイプラインを備えていても良い。情報システムにおけるデータの構成が情報システム毎に異なる可能性があるので、データ蓄積システム４０は、基本的に、情報システム毎にパイプラインを備えている。パイプラインのそれぞれは、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。
【0026】
データ蓄積システム４０は、情報システムが保持している、構造化データまたは非構造化データのファイルを取得して、取得したファイルをパイプラインに連携するデータ収集システムとしてのＧＥＴコネクター４２を備えている。データ蓄積システム４０は、ＧＥＴコネクター４２と同様の構成のＧＥＴコネクターをＧＥＴコネクター４２以外に少なくとも１つ備えても良い。ＧＥＴコネクターは、ＧＥＴコネクター自身がファイルを連携するパイプラインを構成するコンピューターによって構成されても良い。
【0027】
なお、システム１０は、構造化データまたは非構造化データのファイルがデータ蓄積システム４０側から取得されることに対応していない情報システムに対しては、データソース部２０にＰＯＳＴコネクターを備える。一方、システム１０は、構造化データまたは非構造化データのファイルがデータ蓄積システム４０側から取得されることに対応している情報システムに対しては、データ蓄積システム４０にＧＥＴコネクターを備える。
【0028】
データ蓄積システム４０は、ＧＥＴ用エージェントによって生成された構造化データを取得して、取得した構造化データをパイプラインに連携するデータ収集システムとしてのＧＥＴエージェント４３を備えている。データ蓄積システム４０は、ＧＥＴエージェント４３と同様の構成のＧＥＴエージェントをＧＥＴエージェント４３以外に少なくとも１つ備えても良い。ＧＥＴエージェントは、ＧＥＴエージェント自身が構造化データを連携するパイプラインを構成するコンピューターによって構成されても良い。
【0029】
なお、システム１０は、構造化データがデータ蓄積システム４０側から取得されることに対応していない情報システムに対しては、データソース部２０にＰＯＳＴエージェントを備える。一方、システム１０は、構造化データがデータ蓄積システム４０側から取得されることに対応している情報システムに対しては、データソース部２０にＧＥＴ用エージェントを備えるとともに、データ蓄積システム４０にＧＥＴエージェントを備える。
【0030】
データ蓄積システム４０は、複数のパイプラインによって蓄積されたデータを、例えばＳＱＬなどのデータベース言語などのクエリー言語で検索や集計が可能な形態に変換するデータ変換処理として最終変換処理を実行するデータ変換システムとしてのビッグデータ解析部４４を備えている。ビッグデータ解析部４４は、最終変換処理を実行したデータに対して、アプリケーション部５０側からの検索要求や集計要求に応じて検索や集計を実行することも可能である。ビッグデータ解析部４４は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。
【0031】
最終変換処理は、複数の情報システムのデータを統合するデータ統合処理をデータ変換処理として含んでいても良い。アジアに配置されている多数の画像形成装置を遠隔で管理するためにアジアに配置されている遠隔管理システムと、ヨーロッパに配置されている多数の画像形成装置を遠隔で管理するためにヨーロッパに配置されている遠隔管理システムと、アメリカに配置されている多数の画像形成装置を遠隔で管理するためにアメリカに配置されている遠隔管理システムとをシステム１０が情報システムとして備えている場合、これら３つの遠隔管理システムは、それぞれ、遠隔管理システム自身が管理している画像形成装置を管理するデバイス管理テーブルを備えている。デバイス管理テーブルは、画像形成装置毎に付与したＩＤに対応付けて、画像形成装置の各種の情報を示す情報である。ここで、３つの遠隔管理システムがそれぞれ独自にデバイス管理テーブルを備えているので、３つの遠隔管理システムのデバイス管理テーブル間においては、別々の画像形成装置に同一のＩＤが付与されている可能性がある。そこで、ビッグデータ解析部４４は、３つの遠隔管理システムのデバイス管理テーブルを統合して１つのデバイス管理テーブルを生成する場合に、画像形成装置のＩＤを重複が生じないように付与し直す。
【0032】
アプリケーション部５０は、ビッグデータ解析部４４によって管理されているデータを利用して、例えばデータの表示や、データの分析など、利用者によって指示された特定の動作を実行するアプリケーションサービス５１を備えている。アプリケーション部５０は、アプリケーションサービス５１以外にも、少なくとも１つのアプリケーションサービスを備えていても良い。アプリケーションサービスのそれぞれは、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。アプリケーションサービスは、例えば、ＢＩ（Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ）ツール、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）サーバーなどである。
【0033】
アプリケーション部５０は、ビッグデータ解析部４４によって管理されているデータを利用して特定の動作を実行するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供するＡＰＩプラットフォーム５２を備えている。ＡＰＩプラットフォーム５２は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。ＡＰＩプラットフォーム５２によって提供されるＡＰＩは、システム１０の外部の、例えば、ＢＩツール、ＳａａＳサーバーなどのシステムから呼び出されても良いし、アプリケーション部５０のアプリケーションサービスから呼び出されても良い。ＡＰＩプラットフォーム５２によって提供されるＡＰＩは、データ蓄積システム４０によって蓄積されているデータに基づいたデータをデータ蓄積システム４０から取得するためのＡＰＩである。例えば、ＡＰＩプラットフォーム５２によって提供されるＡＰＩとしては、画像形成装置のトナーなどの消耗品の残量が特定の量以下である場合に消耗品を発注する、システム１０の外部の消耗品発注システムに、遠隔管理システムによって画像形成装置から収集された消耗品の残量のデータを送信するＡＰＩと、画像形成装置の故障を予測する、システム１０の外部の故障予測システムに、遠隔管理システムによって画像形成装置から収集された各種のデータを送信するＡＰＩと、遠隔管理システムによって画像形成装置から収集された、印刷枚数を示すカウンター情報を、システム１０の外部のシステムに送信するＡＰＩと、システム１０の利用者の利用状況を示すデータをシステム１０の外部のシステムに送信するＡＰＩと、システム１０が管理しているデータに基づいた任意のデータを取得するための検索クエリーを受け付けるためのＡＰＩとが存在する。
【0034】
以下、ＡＰＩプラットフォーム５２の外部のシステムを単に外部システムという。外部システムには、システム１０の外部のシステムや、アプリケーション部５０のアプリケーションサービスが含まれる。
【0035】
図２は、ＡＰＩプラットフォーム５２のブロック図である。
【0036】
図２に示すように、ＡＰＩプラットフォーム５２は、外部システムからのＡＰＩの利用の要求を受け付けるフロントエンド部７０と、フロントエンド部７０が受け付けた要求に応じた応答データを作成するデータ作成部８０とを備えている。
【0037】
フロントエンド部７０は、外部システムに公開されるエンドポイントであるＬＢ（Ｌｏａｄ Ｂａｌａｎｃｅｒ）７１と、外部システムとの接続を確立するフロントエンドＰｒｏｘｙ７２とを備えている。フロントエンド部７０は、フロントエンドＰｒｏｘｙ７２以外にも、フロントエンドＰｒｏｘｙ７２と同様の構成のフロントエンドＰｒｏｘｙを少なくとも１つ備えていても良い。
【0038】
ＬＢ７１は、外部システムからのＡＰＩの利用の要求をラウンドロビン方式によっていずれかのフロントエンドＰｒｏｘｙに通知する。
【0039】
フロントエンドＰｒｏｘｙ７２は、ＬＢ７１から通知された、ＡＰＩの利用の要求をラウンドロビン方式によって、後述の、いずれかのＡＰＩサーバーに通知する。
【0040】
データ作成部８０は、データ作成部インスタンス８１を備えている。データ作成部８０は、データ作成部インスタンス８１以外にも、データ作成部インスタンス８１と同様の構成のデータ作成部インスタンスを少なくとも１つ備えていても良い。
【0041】
データ作成部インスタンス８１は、ビッグデータ解析部４４（図１参照。）によって管理されているデータを利用して特定の動作を実行するＡＰＩを提供するＡＰＩサーバー８２を備えている。データ作成部インスタンス８１は、ＡＰＩサーバー８２以外にも、ＡＰＩサーバー８２と同様の構成のＡＰＩサーバーを少なくとも１つ備えていても良い。
【0042】
データ作成部インスタンス８１は、外部システムからのＡＰＩの利用の要求に対して応答するデータの取得の処理にかかると予測される時間（以下「予測処理時間」という。）の程度を示す予測処理時間レベルと、外部システムからのＡＰＩの利用の要求に対して応答することが予測されるデータの量（以下「予測応答データ量」という。）の程度を示す予測応答データ量レベルとを制御サービス部６０（図１参照。）から取得するＡＰＩコントローラー８３を備えている。
【0043】
図３は、ＡＰＩコントローラー８３によって取得される予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンの一例を示す図である。
【0044】
図３に示す例において、予測処理時間レベルは、予測処理時間が特定の範囲内であることを示す「普通」と、予測処理時間が特定の範囲の上限より長いことを示す「長」と、予測処理時間が特定の範囲の下限より短いことを示す「短」とを含んでいる。予測応答データ量レベルは、予測応答データ量が特定の範囲内であることを示す「普通」と、予測応答データ量が特定の範囲の上限より多いことを示す「多」と、予測応答データ量が特定の範囲の下限より少ないことを示す「少」とを含んでいる。図３に示す例において、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンは、パターンＡ～パターンＩの９パターンである。
【0045】
図２に示すように、データ作成部インスタンス８１は、外部システムから利用が要求されたＡＰＩに応じた処理の要求を示す処理要求メッセージを格納するキュー８４を備えている。データ作成部インスタンス８１は、キュー８４以外にも、キュー８４と同様の構成のキューを少なくとも１つ備えていても良い。キューは、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに基づいた分類毎に設けられている。
【0046】
図４は、キューの識別情報であるキューＩＤと、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンとの対応関係の一例を示す図である。
【0047】
図４に示すように、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに基づいた分類は、例えば、パターンＡおよびパターンＤが同一の分類でも良いし、パターンＨおよびパターンＩが同一の分類でも良い。なお、図４は、一部のキューについての情報が省略されて描かれている。
【0048】
図２に示すように、データ作成部インスタンス８１は、キュー８４に格納されている処理要求メッセージが示す、処理の要求をビッグデータ解析部４４（図１参照。）に送信するサーバーインスタンスであるバックエンド８５を備えている。データ作成部インスタンス８１は、バックエンド８５以外にも、バックエンド８５と同様の構成のバックエンドを少なくとも１つ備えていても良い。バックエンドは、キュー毎に設けられている。バックエンドは、１つのキューに対して複数備えても良い。キューに格納された処理要求メッセージは、このキューに対応付けられているバックエンドのうち、処理要求メッセージを処理可能な状態のバックエンドによって、このキューから順番に取り出される。
【0049】
図１に示すように、制御サービス部６０は、データソース部２０、データ蓄積システム４０およびアプリケーション部５０におけるデータに対する各段階の処理を監視する処理監視システムとしてのパイプライン・オーケストレーター６１を備えている。パイプライン・オーケストレーター６１は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。
【0050】
パイプライン・オーケストレーター６１は、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求毎に、この要求に対して応答するデータの取得の処理にかかった時間（以下「処理時間」という。）と、この要求に対して応答したデータの量（以下「応答データ量」という。）とを履歴として記憶する。そして、パイプライン・オーケストレーター６１は、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習することによって、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容に対して、予測処理時間レベルおよび予測応答データ量レベルを判定することが可能である。
【0051】
制御サービス部６０は、データ蓄積システム４０の構成や設定を保存し、必要に応じて自動的にデプロイを実行する構成管理サーバー６２を備えている。構成管理サーバー６２は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。構成管理サーバー６２は、データ連携システム３０の構成を変更する構成変更システムを構成している。
【0052】
制御サービス部６０は、情報システムの構成管理サーバーに接続し、情報システムにおけるデータベースや非構造化データに関する構成の変更、すなわち、情報システムにおけるデータの構成の変更を検出するための情報を収集する構成管理ゲートウェイ６３を備えている。構成管理ゲートウェイ６３は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。
【0053】
制御サービス部６０は、情報システムなどの各システム間を連携するために必要な鍵情報や接続文字列などのセキュリティー情報を暗号化して保管するＫｅｙ管理サービス６４を備えている。Ｋｅｙ管理サービス６４は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。
【0054】
制御サービス部６０は、データ蓄積システム４０やアプリケーション部５０からの要求を受け付ける管理ＡＰＩ６５を備えている。管理ＡＰＩ６５は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。
【0055】
制御サービス部６０は、アプリケーション部５０のアプリケーションサービスの認証認可を実行する認証認可サービス６６を備えている。認証認可サービス６６は、１台のコンピューターによって構成されても良いし、複数台のコンピューターによって構成されても良い。認証認可サービス６６は、例えば、データ蓄積システム４０に蓄積されている情報システムのデータの最新化を要求することをアプリケーションサービスが許可されているか否かを確認することができる。
【0056】
次に、外部システムからのＡＰＩの利用の要求に対して応答する場合のシステム１０の動作について説明する。
【0057】
図５は、外部システム９０からのＡＰＩの利用の要求に対して応答する場合のシステム１０の概略の動作のシーケンス図である。
【0058】
図５に示すように、外部システム９０は、特定のＡＰＩの利用の要求を実行する場合、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）接続の確立をフロントエンド部７０のＬＢ７１に要求する（Ｓ１０１）。ここで、特定のＡＰＩの利用の要求は、例えば、ＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）で実行される。ＬＢ７１は、Ｓ１０１における要求を受けると、Ｓ１０１における要求を通知するフロントエンドＰｒｏｘｙをラウンドロビン方式によって特定し、特定したフロントエンドＰｒｏｘｙにＳ１０１における要求を通知する。以下においては、説明を簡略化するために、Ｓ１０１における要求がＬＢ７１から通知されたフロントエンドＰｒｏｘｙがフロントエンドＰｒｏｘｙ７２であるものとする。
【0059】
フロントエンドＰｒｏｘｙ７２は、Ｓ１０１における要求がＬＢ７１から通知されると、外部システム９０との間でＴＣＰ／ＩＰ接続を確立する（Ｓ１０２）。
【0060】
外部システム９０は、システム１０とのＴＣＰ／ＩＰ接続が確立されると、確立されたＴＣＰ／ＩＰ接続を介して特定のＡＰＩの利用の要求をフロントエンドＰｒｏｘｙ７２に通知する（Ｓ１０３）。
【0061】
フロントエンドＰｒｏｘｙ７２は、Ｓ１０３においてＬＢ７１を介して外部システム９０から通知された、ＡＰＩの利用の要求をラウンドロビン方式によって、いずれかのＡＰＩサーバーに通知する（Ｓ１０４）。以下においては、説明を簡略化するために、Ｓ１０４において要求がフロントエンドＰｒｏｘｙ７２から通知されたＡＰＩサーバーがＡＰＩサーバー８２であるものとする。
【0062】
ＡＰＩサーバー８２は、Ｓ１０４における通知を受けると、Ｓ１０４において通知された要求を解釈する（Ｓ１０５）。
【0063】
図６は、処理要求メッセージを格納するキューを特定する場合のシステム１０の動作のシーケンス図である。
【0064】
ＡＰＩサーバー８２は、Ｓ１０５における解釈を実行すると、図６に示すように、Ｓ１０５において解釈した要求の予測処理時間レベルおよび予測応答データ量レベルをＡＰＩコントローラー８３に問い合わせる（Ｓ１２１）。
【0065】
ＡＰＩコントローラー８３は、Ｓ１２１における問い合わせを受けると、Ｓ１２１における問い合わせを制御サービス部６０の管理ＡＰＩ６５に通知する（Ｓ１２２）。
【0066】
管理ＡＰＩ６５は、Ｓ１２２における通知を受けると、Ｓ１２２において通知された問い合わせをパイプライン・オーケストレーター６１に通知する（Ｓ１２３）。
【0067】
パイプライン・オーケストレーター６１は、Ｓ１２３における通知を受けると、Ｓ１２３において通知された問い合わせの対象の要求、すなわち、Ｓ１０５においてＡＰＩサーバー８２によって解釈された要求の内容に対して、予測処理時間レベルおよび予測応答データ量レベルを判定する（Ｓ１２４）。
【0068】
次いで、パイプライン・オーケストレーター６１は、Ｓ１２４における判定の結果、すなわち、Ｓ１２４において判定した予測処理時間レベルおよび予測応答データ量レベルを管理ＡＰＩ６５に通知する（Ｓ１２５）。
【0069】
次いで、管理ＡＰＩ６５は、Ｓ１２５においてパイプライン・オーケストレーター６１から通知された、判定の結果をＡＰＩコントローラー８３に通知する（Ｓ１２６）。
【0070】
次いで、ＡＰＩコントローラー８３は、Ｓ１２６において管理ＡＰＩ６５から通知された、判定の結果、すなわち、予測処理時間レベルおよび予測応答データ量レベルをＡＰＩサーバー８２に返答する（Ｓ１２７）。
【0071】
ＡＰＩサーバー８２は、Ｓ１２７における返答を受けると、Ｓ１２７において返答された予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに対応付けられているキューを特定する（Ｓ１２８）。
【0072】
以下、説明を簡略化するために、Ｓ１２８において特定されたキューがキュー８４であるものとする。
【0073】
図５に示すように、ＡＰＩサーバー８２は、Ｓ１０５における解釈を実行した後、Ｓ１０５において解釈した要求を示す処理要求メッセージを、図６に示す動作によって特定したキュー８４に格納する（Ｓ１０６）。ここで、ＡＰＩサーバー８２は、キュー８４に格納する処理要求メッセージをキュー８４に格納したＡＰＩサーバーとして、ＡＰＩサーバー８２自身の識別情報を、キュー８４に格納する処理要求メッセージに含める。
【0074】
Ｓ１０６においてキュー８４に格納された処理要求メッセージは、キュー８４に対応付けられている、いずれかのバックエンドによって、キュー８４から取り出される（Ｓ１０７）。以下、説明を簡略化するために、Ｓ１０７においてキュー８４から処理要求メッセージを取り出したバックエンドがバックエンド８５であるものとする。
【0075】
バックエンド８５は、Ｓ１０７においてキュー８４から処理要求メッセージを取り出すと、この処理要求メッセージが示す、処理の要求をビッグデータ解析部４４に送信する（Ｓ１０８）。
【0076】
ビッグデータ解析部４４は、処理の要求がＳ１０８において送信されてくると、Ｓ１０８において送信されてきた要求に応じた処理を実行することによって、この処理に応じたデータを取得する（Ｓ１０９）。
【0077】
次いで、ビッグデータ解析部４４は、Ｓ１０９において取得したデータをバックエンド８５に通知する（Ｓ１１０）。
【0078】
バックエンド８５は、Ｓ１１０においてデータが通知されると、Ｓ１０７においてキュー８４から取り出した処理要求メッセージをキュー８４に格納したＡＰＩサーバー８２に、Ｓ１１０において通知されたデータを通知する（Ｓ１１１）。なお、Ｓ１０７においてキュー８４から取り出された処理要求メッセージには、この処理要求メッセージをキュー８４に格納したＡＰＩサーバー８２の識別情報が含まれている。
【0079】
ＡＰＩサーバー８２は、Ｓ１１１においてデータが通知されると、このデータをフロントエンドＰｒｏｘｙ７２に通知する（Ｓ１１２）。
【0080】
したがって、フロントエンドＰｒｏｘｙ７２は、Ｓ１１２において通知されたデータを、ＬＢ７１経由で外部システム９０に応答する（Ｓ１１３）。なお、フロントエンドＰｒｏｘｙ７２は、Ｓ１０２において確立したＴＣＰ／ＩＰ接続を、Ｓ１１３における応答の終了後に終了する。
【0081】
次に、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習する場合のシステム１０の動作について説明する。
【0082】
図７は、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習する場合のシステム１０の動作のシーケンス図である。
【0083】
バックエンド８５は、Ｓ１０８においてビッグデータ解析部４４への処理の要求の送信を開始すると、図７に示すように、外部システムからのＡＰＩの利用の要求に対して応答するデータの取得の処理の開始をＡＰＩコントローラー８３に通知する（Ｓ１４１）。
【0084】
次いで、バックエンド８５は、Ｓ１１０においてビッグデータ解析部４４からのデータの通知が終了すると、外部システムからのＡＰＩの利用の要求に対して応答するデータの取得の処理の終了と、Ｓ１１０においてビッグデータ解析部４４から通知されたデータの量とをＡＰＩコントローラー８３に通知する（Ｓ１４２）。
【0085】
ＡＰＩコントローラー８３は、Ｓ１４２の通知を受けると、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、この要求に対する処理時間および応答データ量とをパイプライン・オーケストレーター６１に通知する（Ｓ１４３）。ここで、ＡＰＩコントローラー８３は、Ｓ１４１において処理の開始が通知された時間から、Ｓ１４２において処理の終了が通知された時間までの時間を処理時間として算出する。また、ＡＰＩコントローラー８３は、Ｓ１４２において通知された、データの量を、応答データ量とする。
【0086】
パイプライン・オーケストレーター６１は、Ｓ１４３の通知を受けると、ＡＰＩコントローラー８３からこれまでに通知された、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容と、処理時間および応答データ量との相関関係を機械学習する（Ｓ１４４）。したがって、パイプライン・オーケストレーター６１は、外部システムからＡＰＩプラットフォーム５２へのＡＰＩの利用の要求の内容に対して、予測処理時間レベルおよび予測応答データ量レベルを判定することが可能になる。
【0087】
次に、バックエンドの数を増加させる場合のＡＰＩコントローラー８３の動作について説明する。
【0088】
図８は、バックエンドの数を増加させる場合のＡＰＩコントローラー８３の動作のフローチャートである。
【0089】
ＡＰＩコントローラー８３は、データ作成部インスタンス８１に所属するキュー毎に図８に示す動作を実行する。以下、キュー８４について代表して説明する。
【0090】
図８に示すように、ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が、キュー８４に対して備えられているバックエンドの数を増加させる処理における処理要求メッセージの数用の閾値である増加処理用数閾値超であると判断するまで、キュー８４に格納されている処理要求メッセージの数が増加処理用数閾値超であるか否かを判断する（Ｓ１６１）。ここで、増加処理用数閾値は、例えば３００個である。
【0091】
ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が増加処理用数閾値超であるとＳ１６１において判断すると、キュー８４に対して備えられているバックエンドの数を増加させる処理において計測した時間を示す増加処理用時間を０にして（Ｓ１６２）、増加処理用時間の計測を開始する（Ｓ１６３）。
【0092】
ＡＰＩコントローラー８３は、Ｓ１６３の処理の後、増加処理用時間が、キュー８４に対して備えられているバックエンドの数を増加させる処理における増加処理用時間用の閾値である増加処理用時間閾値以上であるか否かを判断する（Ｓ１６４）。ここで、増加処理用時間閾値は、例えば５分である。
【0093】
ＡＰＩコントローラー８３は、増加処理用時間が増加処理用時間閾値以上ではないとＳ１６４において判断すると、キュー８４に格納されている処理要求メッセージの数が増加処理用数閾値超であるか否かを判断する（Ｓ１６５）。
【0094】
ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が増加処理用数閾値超であるとＳ１６５において判断すると、Ｓ１６４の処理を実行する。
【0095】
ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が増加処理用数閾値超ではないとＳ１６５において判断すると、Ｓ１６１の処理を実行する。
【0096】
ＡＰＩコントローラー８３は、増加処理用時間が増加処理用時間閾値以上であるとＳ１６４において判断すると、キュー８４に対して備えられるバックエンドの数を特定の数だけ増加させて（Ｓ１６６）、Ｓ１６１の処理を実行する。
【0097】
ＡＰＩコントローラー８３は、図８に示す動作によって、キュー８４に格納されている処理要求メッセージの数が増加処理用数閾値超である状態（Ｓ１６１でＹＥＳおよびＳ１６５でＹＥＳ）が増加処理用時間閾値以上の時間継続した場合（Ｓ１６４でＹＥＳ）に、キュー８４に対して備えられるバックエンドの数を特定の数だけ増加させる（Ｓ１６６）。例えば、ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が３００個超である状態が５分以上の時間継続した場合に、キュー８４に対して備えられるバックエンドの数を特定の数だけ増加させる。
【0098】
次に、バックエンドの数を減少させる場合のＡＰＩコントローラー８３の動作について説明する。
【0099】
図９は、バックエンドの数を減少させる場合のＡＰＩコントローラー８３の動作のフローチャートである。
【0100】
ＡＰＩコントローラー８３は、データ作成部インスタンス８１に所属するキュー毎に図９に示す動作を実行する。以下、キュー８４について代表して説明する。
【0101】
図９に示すように、ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が、キュー８４に対して備えられているバックエンドの数を減少させる処理における処理要求メッセージの数用の閾値である減少処理用数閾値以下であると判断するまで、キュー８４に格納されている処理要求メッセージの数が減少処理用数閾値以下であるか否かを判断する（Ｓ１８１）。ここで、減少処理用数閾値は、例えば２００個である。
【0102】
ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が減少処理用数閾値以下であるとＳ１８１において判断すると、キュー８４に対して備えられているバックエンドの数を減少させる処理において計測した時間を示す減少処理用時間を０にして（Ｓ１８２）、減少処理用時間の計測を開始する（Ｓ１８３）。
【0103】
ＡＰＩコントローラー８３は、Ｓ１８３の処理の後、減少処理用時間が、キュー８４に対して備えられているバックエンドの数を減少させる処理における減少処理用時間用の閾値である減少処理用時間閾値以上であるか否かを判断する（Ｓ１８４）。ここで、減少処理用時間閾値は、例えば３０分である。
【0104】
ＡＰＩコントローラー８３は、減少処理用時間が減少処理用時間閾値以上ではないとＳ１８４において判断すると、キュー８４に格納されている処理要求メッセージの数が減少処理用数閾値以下であるか否かを判断する（Ｓ１８５）。
【0105】
ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が減少処理用数閾値以下であるとＳ１８５において判断すると、Ｓ１８４の処理を実行する。
【0106】
ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が減少処理用数閾値以下ではないとＳ１８５において判断すると、Ｓ１８１の処理を実行する。
【0107】
ＡＰＩコントローラー８３は、減少処理用時間が減少処理用時間閾値以上であるとＳ１８４において判断すると、キュー８４に対して備えられるバックエンドの数を特定の数だけ減少させて（Ｓ１８６）、Ｓ１８１の処理を実行する。
【0108】
ＡＰＩコントローラー８３は、図９に示す動作によって、キュー８４に格納されている処理要求メッセージの数が減少処理用数閾値以下である状態（Ｓ１８１でＹＥＳおよびＳ１８５でＹＥＳ）が減少処理用時間閾値以上の時間継続した場合（Ｓ１８４でＹＥＳ）に、キュー８４に対して備えられるバックエンドの数を特定の数だけ減少させる（Ｓ１８６）。例えば、ＡＰＩコントローラー８３は、キュー８４に格納されている処理要求メッセージの数が２００個以下である状態が３０分以上の時間継続した場合に、キュー８４に対して備えられるバックエンドの数を特定の数だけ減少させる。
【0109】
以上に説明したように、データ連携システム３０は、ＡＰＩの利用の要求に応じてデータ蓄積システム４０からデータを取得する処理（Ｓ１０８およびＳ１１０）の未実行分の数が、この処理の能力を増加させる特定の条件を満たす場合に（Ｓ１６１でＹＥＳ、Ｓ１６４でＹＥＳおよびＳ１６５でＹＥＳ）、この処理の能力を増加させる（Ｓ１６６）ので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【0110】
データ連携システム３０は、ＡＰＩの利用の要求に応じてデータ蓄積システム４０からデータを取得する処理の未実行分の数が、この処理の能力を減少させる特定の条件を満たす場合に（Ｓ１８１でＹＥＳ、Ｓ１８４でＹＥＳおよびＳ１８５でＹＥＳ）、この処理の能力を減少させる（Ｓ１８６）ので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【0111】
データ連携システム３０は、ＡＰＩの利用の要求に応じてデータ蓄積システム４０からデータを取得する処理の、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに基づいた分類毎に、この処理の能力を変更させるので、この処理を、この処理の予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに応じた適切なバックエンドによって実行することができる。したがって、データ連携システム３０は、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【0112】
特定の予測処理時間レベルに基づいた分類のバックエンドとしての特定処理時間バックエンドと、特定の予測処理時間レベルより予測処理時間が長い予測処理時間レベルに基づいた分類のバックエンドとしての処理時間長バックエンドとをＡＰＩプラットフォーム５２が備える場合に、処理時間長バックエンドは、メモリーの容量と、ネットワークの帯域との少なくとも１つが特定処理時間バックエンドより多くても良い。この構成により、データ連携システム３０は、データ蓄積システムからデータを取得する処理を、この処理の予測処理時間が長い場合に、この処理の予測処理時間が短い場合よりも、メモリーの容量と、ネットワークの帯域との少なくとも１つが多いバックエンドによって実行することができるので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【0113】
特定の予測応答データ量レベルに基づいた分類のバックエンドとしての特定応答データ量バックエンドと、特定の予測応答データ量レベルより予測応答データ量が多い予測応答データ量レベルに基づいた分類のバックエンドとしての応答データ量多バックエンドとをＡＰＩプラットフォーム５２が備える場合に、応答データ量多バックエンドは、メモリーの容量と、ネットワークの帯域との少なくとも１つが特定応答データ量バックエンドより多くても良い。この構成により、データ連携システム３０は、データ蓄積システムからデータを取得する処理を、この処理の予測応答データ量が多い場合に、この処理の予測応答データ量が少ない場合よりも、メモリーの容量と、ネットワークの帯域との少なくとも１つが多いバックエンドによって実行することができるので、ＡＰＩの利用の要求に応じて実行する処理の負担に応じて振る舞うことができる。
【0114】
データ連携システム３０は、予測処理時間レベルおよび予測応答データ量レベルの組み合わせのパターンに基づいた分類毎にキューおよびバックエンドを備えている。しかしながら、データ連携システム３０は、予測処理時間レベルおよび予測応答データ量レベルのいずれか１つに基づいた分類毎にキューおよびバックエンドを備えても良い。
【符号の説明】
【0115】
２１ 情報システム
２２ ＰＯＳＴコネクター（データ収集システム）
２３ ＰＯＳＴエージェント（データ収集システム）
２４ ＧＥＴ用エージェント（データ収集システム）
３０ データ連携システム
４０ データ蓄積システム
４２ ＧＥＴコネクター（データ収集システム）
４３ ＧＥＴエージェント（データ収集システム）
５２ ＡＰＩプラットフォーム
２２ ＰＯＳＴコネクター（データ収集システム）
２３ ＰＯＳＴエージェント（データ収集システム）
２４ ＧＥＴ用エージェント（データ収集システム）
３０ データ連携システム
４０ データ蓄積システム
４２ ＧＥＴコネクター（データ収集システム）
４３ ＧＥＴエージェント（データ収集システム）
５２ ＡＰＩプラットフォーム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】