JP2019101541A - Ａｐｉ管理システムおよびａｐｉ管理方法 - Google Patents

Abstract

【課題】マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを踏まえ、マッシュアップ全体の処理効率を好適なものとする。【解決手段】ＡＰＩ管理システム１において、ＡＰＩの各ユーザに関する流量制御状態の情報を格納した記憶部１０３と、ＡＰＩのマッシュアップに関するユーザからのリクエストを所定装置より受け付けて、前記リクエストが含む当該マッシュアップの定義と、前記ユーザの該当ＡＰＩに関する前記流量制御状態の情報とを所定アルゴリズムに適用し、前記定義におけるＡＰＩ間の依存関係を制約条件とし、前記流量制御状態の情報における流量制御解除までの待機時間を最小化する、ＡＰＩの処理スケジュールを生成する演算部１０２を含む構成とする。【選択図】図１

Description

本発明は、ＡＰＩ管理システムおよびＡＰＩ管理方法に関するものであり、具体的には、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを踏まえ、マッシュアップ全体の処理効率を好適なものとする技術に関する。

あるソフトウェアの機能やデータを、他のソフトウェアから呼び出して利用するための規約をＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）と呼ぶ。ソフトウェア開発者は、そうしたＡＰＩを利用する簡易なプログラムを、開発対象のソフトウェアに記述するだけで、当該ＡＰＩに対応した機能やデータを利用したソフトウェアの開発が可能である。

一方、近年では、自社の情報サービスがもつ機能やデータを、ネットワーク経由で呼び出せるＡＰＩ（ＷｅｂＡＰＩとも呼ばれる）を公開する企業が増えている。そのため、それらＡＰＩを他社から利用してもらうことで、自社サービスの価値向上を図るビジネスモデルが広まりを見せている。

上述のごとき技術背景を踏まえたソフトウェア開発者は、様々な新ビジネスのアイデアを迅速にソフトウェアとして実現すべくＡＰＩを適宜利用することになる。そのため、ＡＰＩへのニーズは多様であり、そのニーズへの迅速な対応が求められる。

しかしながら、ＡＰＩの公開企業では、上述のニーズに対応したＡＰＩの改修や追加に時間を要することが多い。よって、ＡＰＩの公開側と利用側とで、そのスピード感がずれてしまうケースも多くなる。

そのようなケースに対し、複数個の公開済みＡＰＩを組合せて新しいＡＰＩを構成するという、ＡＰＩマッシュアップ技術が注目されている。この技術により、ＡＰＩ公開側での追加開発無しで、ＡＰＩ利用側のニーズに対応する新しいＡＰＩを迅速に公開できる。また、ＡＰＩ利用側にとっては、従来であれば複数回のリクエストが必要であった機能を、１回のリクエストで利用可能となる。これに付随して、通信効率向上の効果も期待できる。

こうしたＡＰＩマッシュアップに関する従来技術としては、例えば、所定の目的を少なくとも通信を行って実現するイネーブラに繋がるＡＰＩを複数組合せたアプリケーションが、所望の情報を取得するためのリクエスト情報を前記ＡＰＩを介して前記イネーブラへ送信し、当該送信されたリクエスト情報を受信した前記イネーブラが前記リクエスト情報に応じたレスポンス情報を、前記ＡＰＩを介して前記アプリケーションへ返信する通信システムにおいて、前記アプリケーションと前記イネーブラとの間に少なくとも前記ＡＰＩを介して接続されたＡＰＩ集約装置であって、前記ＡＰＩが前記イネーブラに対して行う前記リクエスト情報及び前記レスポンス情報の送受信中継の実行回数を計数し、この計数された実行回数から、前記ＡＰＩが独立で実行した独立実行回数と、前記ＡＰＩが組合されて実行した組合せ実行回数を求め、前記独立実行回数が予め定められた第１回数より小さく、且つ前記組合せ実行回数が予め定められた第２回数より大きい条件に当て嵌まるＡＰＩを、マッシュアップするＡＰＩ処理機能部を備えることを特徴とするＡＰＩ集約装置（特許文献１参照）などが提案されている。
また、複数個のＡＰＩリクエストを１回のリクエストで処理可能とする、バッチ処理の技術（非特許文献１）も開示されている。

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

「Ｇｒａｐｈ ＡＰＩ， Ｍａｋｉｎｇ Ｂａｔｃｈ Ｒｅｑｕｅｓｔｓ−Ｆａｃｅｂｏｏｋ ｆｏｒ Ｄｅｖｅｌｏｐｅｒｓ」、ｏｎｌｉｎｅ、Ｆａｃｅｂｏｏｋ、平成２９年６月３０日検索、インターネット＜ＵＲＬ： ｈｔｔｐｓ：／／ｄｅｖｅｌｏｐｅｒｓ．ｆａｃｅｂｏｏｋ．ｃｏｍ／ｄｏｃｓ／ｇｒａｐｈ−ａｐｉ／ｍａｋｉｎｇ−ｍｕｌｔｉｐｌｅ−ｒｅｑｕｅｓｔｓ＞

ところで、ＡＰＩ公開時には、ＡＰＩ公開側のシステムに過負荷が掛からぬよう、所定の管理システムにて流量制御を行うことが一般的である。この流量制御は、指定時間あたりのＡＰＩリクエスト数を制限する制御となる。例えば、ＡＰＩ利用ソフトウェアごとに１０回／分のリクエスト数を上限とし、それ以上のリクエストに対しては対応せず、当該ＡＰＩ利用ソフトウェアへエラーを返す。

マッシュアップが含むＡＰＩに関し、このような流量制御が実施された場合、マッシュアップ全体としてはエラーとなり、該当リクエストに関して処理を終了する事態となる。

このような問題に対して、いずれの従来技術も適宜に対処する構成を備えていない。例えば、非特許文献１に記載の技術では、複数のＡＰＩリクエストの中で、成功したものはそのレスポンスが、失敗したものはエラーが、列挙された形で得られるが、最終的なレスポンスとしてはエラーとなってしまう。

また、そのようなバッチ処理にかかる時間に対して、タイムアウトは考慮されているが、そのタイムアウト内にバッチ処理が完了するような工夫はなされていない。また、マッシュアップ全体の処理時間に関しては、「追加費用がかかっても早く処理を完了したい」、逆に、「遅くても構わないが安く処理をしたい」、といったＡＰＩ利用ソフトウェアのエンドユーザ毎のニーズに応えることもできていない。

そこで本発明の目的は、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを踏まえ、マッシュアップ全体の処理効率を好適なものとする技術を提供することにある。

上記課題を解決する本発明のＡＰＩ管理システムは、ＡＰＩの各ユーザに関する流量制御状態の情報を格納した記憶部と、ＡＰＩのマッシュアップに関するユーザからのリクエストを所定装置より受け付けて、前記リクエストが含む当該マッシュアップの定義と、前記ユーザの該当ＡＰＩに関する前記流量制御状態の情報とを所定アルゴリズムに適用し、前記定義におけるＡＰＩ間の依存関係を制約条件とし、前記流量制御状態の情報における流量制御解除までの待機時間を最小化する、ＡＰＩの処理スケジュールを生成する演算部と、を備えることを特徴とする。

また、本発明のＡＰＩ管理方法は、ＡＰＩの各ユーザに関する流量制御状態の情報を格納した記憶部を備えた情報処理システムが、ＡＰＩのマッシュアップに関するユーザからのリクエストを所定装置より受け付けて、前記リクエストが含む当該マッシュアップの定
義と、前記ユーザの該当ＡＰＩに関する前記流量制御状態の情報とを所定アルゴリズムに適用し、前記定義におけるＡＰＩ間の依存関係を制約条件とし、前記流量制御状態の情報における流量制御解除までの待機時間を最小化する、ＡＰＩの処理スケジュールを生成する、ことを特徴とする。

本発明によれば、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを踏まえ、マッシュアップ全体の処理効率を好適なものとできる。

第１実施形態におけるＡＰＩ管理システムを含むネットワーク構成例を示す図である。 第１実施形態におけるＡＰＩ定義テーブルのデータ構造例を示す図である。 第１実施形態におけるＡＰＩ流量制御設定テーブルのデータ構造例を示す図である。 第１実施形態におけるマッシュアップ定義テーブルのデータ構造例を示す図である。 第１実施形態の推定処理時間テーブルのデータ構造例を示す図である。 第１実施形態の流量制御状態テーブルのデータ構造例１を示す図である。 第１実施形態の流量制御状態テーブルデータ構造例２を示す図である。 第１実施形態における仮想流量制御状態テーブルのデータ構造例を示す図である。 第１実施形態のスケジュールテーブルのデータ構造例１を示す図である。 第１実施形態のスケジュールテーブルのデータ構造例２を示す図である。 第１実施形態のＡＰＩ管理方法のフロー例１を示す図である。 第１実施形態のＡＰＩ管理方法のフロー例２を示す図である。 第１実施形態のＡＰＩ管理方法のフロー例３を示す図である。 第１実施形態のＡＰＩ実行スケジュールの作成処理フローの具体例を示す図である。 第２実施形態におけるＡＰＩ管理システムを含むネットワーク構成例を示す図である。 第２実施形態のユーザ条件テーブルのデータ構造例を示す図である。 第２実施形態における画面例を示す図である。 第２実施形態のＡＰＩ管理方法のフロー例を示す図である。

−−−第１実施形態−−−

以下に本発明の第１実施形態について図面を用いて詳細に説明する。図１は、第１実施形態におけるＡＰＩ管理システム１を含むネットワーク構成図である。図１に示すＡＰＩ管理システム１は、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを踏まえ、マッシュアップ全体の処理効率を好適なものとするコンピュータシステムである。

なお、本実施形態においてＡＰＩは、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）の規約に従うＷｅｂＡＰＩであるとして説明を行う。

図１にて例示するネットワーク構成において、ＡＰＩ管理システム１は、アプリケーションサーバ２、エンドユーザ端末３、ＡＰＩサーバ４、および、管理者端末５、と接続されている。
このうちアプリケーションサーバ２は、ＡＰＩ管理システム１が公開するＡＰＩを利用
するクライアントアプリケーションを提供するサーバ装置である。
また、エンドユーザ端末３は、エンドユーザが上述のアプリケーションサーバ２におけるクライアントアプリケーションを利用するユーザの端末である。
また、ＡＰＩサーバ４は、ＡＰＩ管理システム１を介してアプリケーションサーバ２にＡＰＩを提供するサーバ装置である。
また、管理者端末５は、ＡＰＩ管理システム１の管理者がＡＰＩ管理システム１を利用する端末である。
上述のアプリケーションサーバ２は、インターネットなどの適宜なネットワーク１０を通じてＡＰＩ管理システム１と通信可能に接続されている。
同様に、エンドユーザ端末３は、企業内ネットワークなど適宜なネットワーク１１を介してアプリケーションサーバ２と通信可能に接続されている。

また、ＡＰＩサーバ４は、企業内ネットワークなど適宜なネットワーク１１を介して、ＡＰＩ管理システム１と通信可能に接続されている。同様に、管理者端末５は、企業内ネットワークなど適宜なネットワーク１１を介して、ＡＰＩ管理システム１と通信可能に接続されている。

なお、上述のアプリケーションサーバ２、エンドユーザ端末３、および、ＡＰＩサーバ４は、それぞれ複数でも構わないが、本実施形態では説明の簡便化のため、それぞれ１つ配置した構成としている。

続いて、こうしたネットワーク構成に含まれる各機器の詳細について説明する。まず、アプリケーションサーバ２は、ネットワークインターフェイスなど適宜な通信装置で構成される通信部２０１と、ＣＰＵなど演算装置がプログラムを実行して実装される、画面生成部２０２およびＡＰＩリクエスト生成部２０３とを備えた、一般的なＷｅｂアプリケーションサーバである。

このうち通信部２０１は、ＡＰＩ管理システム１に対し、ＡＰＩを利用するためのリクエストを送信し、そのレスポンスを受信したり、エンドユーザ端末３に画面を送信し、エンドユーザの入力操作を受信したりする。

また、画面生成部２０２は、クライアントアプリケーションの画面を生成する機能部である。また、ＡＰＩリクエスト生成部２０３は、ＡＰＩ管理システム１が公開するＡＰＩを利用するためのリクエストを生成する機能部である。

また、エンドユーザ端末３は、上述のアプリケーションサーバ２にエンドユーザの入力操作を送信し、クライアントアプリケーションの画面を受信する通信部３０１と、クライアントアプリケーションの画面を表示する表示部３０２と、エンドユーザの入力操作を行う入力部３０３とからなる。これらは、例えばスマートフォンのような通信部を備えたデバイスや、インターネットに接続されたＰＣで構成する。

なお、本実施形態において、上述のクライアントアプリケーションは、サーバサイドアプリケーションとしている。ただし、例えばスマートフォンにインストールしたネイティブアプリケーションや、ＰＣにインストールしたＷｅｂブラウザで動作するアプリケーションのような、クライアントサイドアプリケーションとしても構わない。その場合、アプリケーションサーバ２とエンドユーザ端末３をひとまとめにしてクライアントアプリケーションと考えればよい。

また、ＡＰＩサーバ４は、複数のＡＰＩを公開しているサーバであり、各ＡＰＩへのリクエストを受信し、そのレスポンスを送信する通信部４０１と、各ＡＰＩへのリクエスト
に応じた処理を行い、レスポンスを生成するＡＰＩレスポンス生成部４０２とからなる。これらは一般的なＷｅｂアプリケーションサーバで構成する。

また、管理者端末５は、上述のＡＰＩ管理システム１に対して管理者の入力操作を送信し、ＡＰＩ管理システム１の管理画面を受信する通信部５０１と、ＡＰＩ管理システム１の管理画面を表示する表示部５０２と、管理者の入力操作を行う入力部５０３とからなる。これらは、例えばスマートフォンのような通信部を備えたデバイスや、インターネットに接続されたＰＣで構成する。

一方、ＡＰＩ管理システム１は、ネットワークインターフェイスなどで実装された通信部１０１、ＣＰＵなどの適宜な演算装置でプログラムを実行することで実装される演算部１０２、および、適宜な記憶装置で実装される記憶部１０３から構成されている。

このうち通信部１０１は、上述のアプリケーションサーバ２から受信したＡＰＩリクエストをＡＰＩリクエスト処理部１０２１に転送する機能、ＡＰＩリクエスト処理部１０２１から受信したＡＰＩリクエストをＡＰＩサーバ４に転送するとともにその時刻をＡＰＩリクエスト処理部１０２１に送信する機能、ＡＰＩサーバ４から受信したＡＰＩレスポンスをアプリケーションサーバ２に転送するとともにその時刻をＡＰＩリクエスト処理部１０２１に送信する機能、管理者端末５から受信した処理内容をＡＰＩ設定部１０２５やマッシュアップ設定部１０２６に転送する機能、および、画面生成部１０２７から受信した管理画面を管理者端末５に転送する機能、をそれぞれ実装するプログラムと、通信モジュールで構成されている。

また、演算部１０２は、ＡＰＩリクエスト処理部１０２１、流量制御部１０２２、スケジュール部１０２３、処理時間推定部１０２４、ＡＰＩ設定部１０２５、マッシュアップ設定部１０２６、および、画面生成部１０２７を備えている。

このうち、ＡＰＩリクエスト処理部１０２１は、上述の通信部１０１からＡＰＩリクエストを受信した際に記憶部１０３のＡＰＩ定義テーブル１０３１を参照し、単体のＡＰＩへのリクエストであれば、これを流量制御部１０２２に転送し、当該流量制御部１０２２からの流量制御結果が制御不要である場合、適切な転送先に振分けて通信部１０１へ返送する機能、一方、上述の流量制御結果が制御要である場合、エラーレスポンスを通信部１０１へ返送する機能、通信部１０１からＡＰＩリクエストのＡＰＩサーバ４への送信時刻とＡＰＩレスポンスのＡＰＩサーバからの受信時刻とを受信し、これを処理時間推定部１０２４に転送する機能、上述の通信部１０１から受信したＡＰＩリクエストがマッシュアップであれば、これをスケジュール部１０２３に転送する機能、および、スケジュール部１０２３からのスケジューリング完了通知を受けて、記憶部１０３のスケジュールテーブル１０３６を参照し、スケジュール内容に応じてマッシュアップを構成する単体のＡＰＩリクエスト処理や待機を行う機能、をそれぞれ実装するプログラムで構成されている。

また、流量制御部１０２２は、上述のＡＰＩリクエスト処理部１０２１からＡＰＩリクエストを受信した場合にＡＰＩ流量制御設定テーブル１０３２を参照し、当該ＡＰＩに流量制御設定がなければ、当該リクエストをＡＰＩリクエスト処理部１０２１に返送する機能、一方、当該ＡＰＩに流量制御設定があれば、リクエスト元のクライアントアプリケーションに対応する流量制御状態テーブル１０３５の当該ＡＰＩの１回目の時刻を参照し、現在時刻からＡＰＩ流量制御設定テーブルに規定された時間が経過していたらカウンタ値を１に上書きし、１回目の時刻も現在時刻に上書きした後に、当該リクエストをＡＰＩリクエスト処理部１０２１に返送し、現在時刻からＡＰＩ流量制御設定テーブルに規定された時間が経過しておらず、カウンタ値がＡＰＩ流量制御設定テーブルの上限値であればエラーをＡＰＩリクエスト処理部１０２１に返送し、カウンタ値が前記上限値未満であれば
カウンタ値に１を加算し、当該リクエストをＡＰＩリクエスト処理部１０２１に返送する機能、をそれぞれ実装するプログラムで構成されている。

また、スケジュール部１０２３は、上述のＡＰＩリクエスト処理部１０２１からマッシュアップのリクエストを受信した場合に、マッシュアップ定義テーブル１０３３、ＡＰＩ流量制御設定テーブル１０３２、推定処理時間テーブル１０３４、流量制御状態テーブル１０３５、および、スケジュールテーブル１０３６を参照し、マッシュアップを構成する複数のＡＰＩの実行順序のスケジューリングを行い、スケジュールテーブル１０３６を更新し、スケジューリング完了の通知をＡＰＩリクエスト処理部１０２１に送信する機能、を実装するプログラムで構成されている。こうしたスケジューリングの詳細は後述する。

また、処理時間推定部１０２４は、上述の通信部１０１からＡＰＩリクエスト処理部１０２１経由で各ＡＰＩリクエストのＡＰＩサーバ４への送信時刻および対応するレスポンスの受信時刻を受信した場合、受信時刻と送信時刻の差分時間を当該ＡＰＩの処理時間の実績値とし、例えばそれまでの実績値との平均値を当該ＡＰＩの時間帯毎の推定処理時間とし、推定処理時間テーブル１０３４を生成および更新するプログラムで構成する。尚、そのような処理時間推定に関する技術は、例えば特開２０１６−１５１７８０公報に開示されている。

なお、こうした処理時間の考え方は同期ＡＰＩと非同期ＡＰＩとで異なるが、以下の理由により、本実施形態では区別しないものとする。まず、同期ＡＰＩでは、上述のような送受信時刻の差（受信時刻−送信時刻）を処理時間とすればよい。次に、非同期ＡＰＩでは、送信時間は同期ＡＰＩと同様でよいが、ＡＰＩサーバ４からはリクエストを受け付けたことのレスポンスのみが返ってくるため、その時刻を実際の処理が完了したことに対応するレスポンス受信時刻とすることはできない。但し、非同期ＡＰＩでは通常、上記リクエスト受付のレスポンスに含まれる受付番号等をパラメタにして、ＡＰＩサーバ４の処理状態を問い合わせることができる。そのため、例えば通信部１０１からその問合せを定期的に行うことで非同期ＡＰＩに対応する処理の完了を確認し、完了時の時刻をレスポンス受信時刻とすればよい。

また、ＡＰＩ設定部１０２５は、上述のＡＰＩ管理システム１の管理者（例えば、ＡＰＩサーバ４の管理者と同じでもよい）による管理者端末５の入力内容を通信部１０１より受信し、ＡＰＩ定義テーブル１０３１およびＡＰＩ流量制御設定テーブル１０３２を生成および更新するプログラムで構成する。

また、マッシュアップ設定部１０２６は、上述のＡＰＩ管理システム１の管理者による管理者端末５の入力内容を通信部１０１より受信し、マッシュアップ定義テーブル１０３３を生成および更新するプログラムで構成する。

また、画面生成部１０２７は、上述のＡＰＩ管理システム１の管理者による管理者端末５の入力内容を通信部１０１より受信して、管理画面を生成し、通信部１０１に返送するプログラムで構成する。

他方、記憶部１０３は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの記憶装置で実装され、詳細後述するＡＰＩ定義テーブル１０３１、ＡＰＩ流量制御設定テーブル１０３２、マッシュアップ定義テーブル１０３３、推定処理時間テーブル１０３４、流量制御状態テーブル１０３５、および、マッシュアップを構成する複数のＡＰＩの実行スケジュールたるスケジュールテーブル１０３６を格納している。

なお、上述の各テーブルを概説すると、管理者による管理者端末５からの入力を通じてＡＰＩ設定部１０２５が生成するのがＡＰＩ定義テーブル１０３１およびＡＰＩ流量制御設定テーブル１０３２である。また、管理者による管理者端末５からの入力を通じてマッシュアップ設定部１０２６が生成するのがマッシュアップ定義テーブル１０３３である。また、処理時間推定部１０２４がＡＰＩリクエストの処理時間の実績値を元にして生成および更新するのが推定処理時間テーブル１０３４である。また、ＡＰＩリクエスト毎に流量制御部１０２２が更新するのが流量制御状態テーブル１０３５である。また、スケジュール部１０２３がマッシュアップを構成する複数のＡＰＩの実行順序のスケジューリングによって生成し、各ＡＰＩの処理完了時にＡＰＩリクエスト処理部１０２１が進行状況を更新するのがスケジュールテーブル１０３６である。
また、記憶部１０３にて蓄積するデータは、電子ファイルの形態でもよいし、データベースシステムで管理してもよい。

続いて、本実施形態のＡＰＩ管理システム１が用いるテーブル類について説明する。図２に、本実施形態におけるＡＰＩ定義テーブル１０３１のデータ構成例を示す。

このＡＰＩ定義テーブル１０３１は、ＡＰＩ毎に、ＡＰＩ利用者（アプリケーションサーバ２）への公開仕様と、それに対応したＡＰＩ提供者（ＡＰＩサーバ４）の内部仕様と、ヘッダやペイロードの仕様をまとめたリストである。

本実施形態では、ＡＰＩ提供者の提供するＡＰＩとして、「ＡＰＩ−Ａ」〜「ＡＰＩ−Ｅ」が定義されている。条件登録ＡＰＩおよび料金照会ＡＰＩについては第２実施形態で説明する。

続いて図３に、ＡＰＩ流量制御設定テーブル１０３２のデータ構成例を示す。ここで、本実施形態におけるＡＰＩの流量制御とは、規定単位時間内に規定回数より多くのＡＰＩリクエストを受けた場合、規定単位時間が過ぎるまでは規定回数を超えた分のＡＰＩリクエストはエラーとする制御である。

この流量制御の対象はＡＰＩ単位、クライアントアプリケーション単位、エンドユーザ単位等、様々な単位が考えられるが、本実施形態では、設定はＡＰＩ単位、回数のカウントはクライアントアプリケーション単位とする。図３にて示す例では、例えば「ＡＰＩ−Ａ」の流量制御は１分間にリクエスト１０回を上限とすることを示している。また、「ＡＰＩ−Ｂ」には流量制御は設定されていないことを示している。

続いて図４は、マッシュアップ定義テーブル１０３３のデータ構成例を示す図である。マッシュアップは通常、複数のＡＰＩのレスポンスを演算して組み合わせる等、ワークフローのような一連の処理を行った結果を全体としてのレスポンスとするものである。しかしながら本実施形態では、演算は割愛し、どのＡＰＩをどのような依存関係で実施するかという定義のみとする。

図４に示す例では、ＡＰＩ同士の依存関係を次の記号で表現している。まず、「Ａ，Ｂ」という記号は、「ＡＰＩ−Ａ」と「ＡＰＩ−Ｂ」を実行するが、その実行順序は任意であることを表現している。例えば、何らかのデータを取得するＡＰＩは、実行順序に制限がないことが多い。

また、「Ａ→Ｂ」という記号は、「ＡＰＩ−Ａ」の後に「ＡＰＩ−Ｂ」を実行するという順序の依存関係を表現しているが、「ＡＰＩ−Ａ」と「ＡＰＩ−Ｂ」の間に別のＡＰＩを実行することを許すものとする。例えば、何らかのデータの更新を行うＡＰＩを実行し、その更新後のデータを取得するＡＰＩを実行する、という時には順序の依存関係が発生
する。定義中の（）は、（）内の依存関係を満たしたまま、（）外の依存関係を満たす、ということを表現している。例えば、「（Ａ，Ｂ）→Ｃ」は、「ＡＰＩ−Ａ」と「ＡＰＩ−Ｂ」の実行順序は任意であるが、どちらも「ＡＰＩ−Ｃ」よりは先に実行完了とすることを表現している。

このように実行順序に関して任意の部分がある場合に、流量制御の対象となっているＡＰＩを先に実行しようとしてしまうと、マッシュアップ全体としてエラーで終了してしまったり、マッシュアップ全体としての処理時間が長くなってしまうという課題がある。そこで、そのような課題を解決するためのＡＰＩの実行順序のスケジューリングを行うことが本実施形態の目的である。

続いて図５は、推定処理時間テーブル１０３４のデータ構成例を示す図である。この推定処理時間テーブル１０３４は、ＡＰＩ毎、時間帯毎に、当該ＡＰＩの平均処理時間を対応付けたリストであり、数字の単位は秒としている。

また、図６Ａは、流量制御状態テーブル１０３５のデータ構成例を示す図である。この流量制御状態テーブル１０３５は、クライアントアプリケーション毎、ＡＰＩ毎に、流量制御の規定回数に対するカウント数と、１回目の時刻とを対応付けたリストである。ＡＰＩリクエストを受信する毎に流量制御部１０２２に更新されるものである。なお、図６Ｂにも同様の流量制御状態テーブル１０３５Ａを例示しているが、図６Ｃには、進行中のマッシュアップに関して生成した流量制御状態テーブル１０３５Ｂを例示している。これらについては後述する。

また図７は、スケジュールテーブル１０３６のデータ構成例を示す図である。このスケジュールテーブル１０３６は、マッシュアップに含まれるＡＰＩを直列処理する場合のスケジュールとなる。

スケジュールテーブル１０３６は、マッシュアップのリクエスト毎の、当該マッシュアップを構成する各ＡＰＩの処理順序と、リクエスト送信時刻と、現在時刻におけるマッシュアップ全体の進行状態のリストである。このうちリクエスト送信時刻は、現在時刻において未実行のＡＰＩでは、リクエスト送信予定時刻に相当する。

ここで、複数のＡＰＩの実行順序に関して、直列処理と並列処理とについて説明する。このうち直列処理は、複数のＡＰＩにおいて、前のＡＰＩの処理が完了してから次のＡＰＩを実行する、という処理方式である。つまり、ＡＰＩ管理システム１とＡＰＩサーバ４との通信は、マッシュアップを構成する複数のＡＰＩの処理を１つのスレッドを用いて行うことになる。

通常、同時に送信できるＨＴＴＰのリクエスト数には上限（例えば一般的なＷｅｂブラウザであれば「６」）があり、リクエストを受信するサーバ側にも、負荷分散の観点で、比較的大きな数字ではあるが、同時に受信できる数には上限が設けられることが多い。従って、スレッド数を抑えるという観点で直列処理の必要性があると考えられる。

これに対して並列処理は、複数のＡＰＩにおいて、実行順序に依存関係がないＡＰＩ同士は、同時にリクエストを送信する、つまり複数のスレッドを用いて行う処理方式である。 こうした並列処理は通常、スレッド数に余裕がある場合に、マッシュアップ全体の完了までの時間を抑えることができるため、利用可能なスレッド数を管理することで直列処理と並列処理を使い分けることができるとよい。
続いて、図８は、マッシュアップに含まれているＡＰＩを並列処理する場合のスケジュールテーブル１０３６のデータ構成例を示す図である。

この場合のスケジュールテーブル１０３６は、上述の図７にて直列処理の場合のスケジュールテーブルと同様であるが、同じリクエストＩＤ「２０１７０６３０−１」に対して直列処理のスケジュールは「Ｃ⇒Ｂ⇒Ａ」という１スレッドであるが、並列処理のスケジュールでは「Ｂ⇒Ａ」と「Ｃ」の２スレッドとなっている。

以下、本実施形態におけるＡＰＩ管理方法の実際手順について図に基づき説明する。以下で説明するＡＰＩ管理方法に対応する各種動作は、ＡＰＩ管理システム１が実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図９は、本実施形態におけるＡＰＩ管理方法のフロー例１を示す図である。ここでは、マッシュアップを構成する複数のＡＰＩの実行スケジューリング処理の概略フローについて説明する。なお、以降の説明においては、マッシュアップに含まれているＡＰＩを直列処理する場合を前提としてスケジューリングするケースについて示すものとする。

この場合、ＡＰＩ管理システム１のスケジュール部１０２３は、ＡＰＩリクエスト処理部１０２１からマッシュアップのリクエストを受信した場合、スケジュールテーブル１０３６、流量制御状態テーブル１０３５、および、ＡＰＩ流量制御設定テーブル１０３２を参照し、その時点で既に計画されているスケジューリングを考慮した仮想流量制御状態テーブルを作成する（Ｓ９０１）。この詳細は図１０で説明する。

次に、ＡＰＩ管理システム１のスケジュール部１０２３は、マッシュアップ定義テーブル１０３３、ＡＰＩ流量制御設定テーブル１０３２、仮想流量制御状態テーブル１０３５Ｂ（図６Ｃ）、および、推定処理時間テーブル１０３４を参照し、ＡＰＩ実行スケジュール（本発明においてＡＰＩの処理スケジュール）を作成し、スケジュールテーブル１０３６を更新し（Ｓ９０２）、処理を終了する。この詳細は図１１で説明する。

図１０は、仮想流量制御状態テーブルの作成フローを示す図である。この場合、ＡＰＩ管理システム１のスケジュール部１０２３は、スケジュールテーブル１０３６を参照し、リクエスト元のクライアントアプリケーションの、状態が「進行中」であるスケジュールに含まれる「未実行」のＡＰＩと、その実行予定時刻と、その実行予定回数を取得する（Ｓ１００１）。

図７に示すスケジュールテーブル１０３６の、クライアントアプリケーション「Ｃｌｉｅｎｔ−１」の場合、リクエストＩＤ「２０１７０６３０−３」の「Ｄ（１６：２１：５２）」、「Ｃ（１６：２１：５９）」、「Ａ（１６：２２：１９）」、およびリクエストＩＤ「２０１７０６３０−５」の「Ａ（１６：２１：５４）」、「Ｃ（１６：２１：５７）」が該当し、実行予定回数は「Ａ」が２回、「Ｃ」が２回、「Ｄ」が１回となる。

次に、スケジュール部１０２３は、流量制御状態テーブル１０３５を参照し、リクエスト元のクライアントアプリケーションに対する、各ＡＰＩのカウンタ値と１回目の時刻を取得する（Ｓ１００２）。ここでは、図６Ｂに示す流量制御状態テーブル１０３５Ａを例に取って説明する。

続いて、スケジュール部１０２３は、上述のＳ１００２で取得した各ＡＰＩのカウンタ値に、Ｓ１００１で取得した未実行ＡＰＩの実行予定回数を加算し、その値を各ＡＰＩの仮想カウンタ値とする（Ｓ１００３）。但し、上述の加算を行った結果、カウンタ値が流量制御の上限を超えたら、１からカウントを継続する。

図６Ｂの流量制御状態テーブル１０３５Ａにおいては、「ＡＰＩ−Ａ」はカウンタ「９」に２を加算して１１になるが流量制御の上限が「１０」（図３：ＡＰＩ流量制御設定テーブル１０３２）であるため、仮想カウンタ値は「１」となる。一方、「ＡＰＩ−Ｃ」はカウンタが１０から１２に、「ＡＰＩ−Ｄ」はカウンタが４から５になる。

次に、スケジュール部１０２３は、上述のＳ１００３において、カウンタ値が流量制御の上限を超えたＡＰＩについて、仮想カウンタにおける１回目の実行予定時刻を、１回目の仮想時刻とする（Ｓ１００４）。

図６Ｂの流量制御状態テーブル１０３５Ａにおいては、上述のＳ１００１で取得したリクエストＩＤ「２０１７０６３０−３」の「Ａ（１６：２２：１９）」が該当するため、「ＡＰＩ−Ａ」の１回目の仮想時刻は「１６：２２：１９」となる。

続いて、スケジュール部１０２３は、未実行ＡＰＩ毎に、最後に実行される予定の時刻を、最後の仮想時刻とする（Ｓ１００５）。上述のＳ１００１で取得したスケジュールテーブル１０３６では、「ＡＰＩ−Ａ」は「１６：２２：１９」、「ＡＰＩ−Ｃ」は「１６：２１：５９」、「ＡＰＩ−Ｄ」は「１６：２１：５２」となる。

次に、スケジュール部１０２３は、ＡＰＩ流量制御設定テーブル１０３２を参照し、各ＡＰＩの制御単位時間を取得する。そして、仮想カウンタ値が制御状態ではないＡＰＩに対して、「最後の仮想時刻−現在時刻」を算出し、その算出値を当該ＡＰＩの待機時間とする（Ｓ１００６）。図６Ｂの流量制御状態テーブル１０３５Ａにおいては、「ＡＰＩ−Ａ」、「ＡＰＩ−Ｃ」が該当し、「ＡＰＩ−Ａ」は３３秒、「ＡＰＩ−Ｃ」は１３秒となる。

この待機時間は、各ＡＰＩに対して、スケジュールテーブル１０３６で予定されている分が実行されるまでの時間であり、予定されている分が実行される前に、当該ＡＰＩへの新しいリクエストを割り込ませてしまい、それによって流量制御が発生してしまうことで、先に予定されていた分が実行できなくなる問題を回避するための時間と言える。

なお、「ＡＰＩ−Ｃ」のように、当該ＡＰＩの仮想カウンタ値が、上限値を超えなかった場合の値であり、なおかつ上限値未満であれば、割り込みがあっても上記の問題は発生せず、その場合は待機時間を０秒としても構わないが、本実施形態では、簡単のため、この場合は考慮しないものとする。

また、スケジュール部１０２３は、仮想カウンタ値が制御状態であるＡＰＩに対しては、「制御単位時間−（現在時刻−１回目の仮想時刻）」を算出し、その算出値をＡＰＩの待機時間とする。図６Ｂの流量制御状態テーブル１０３５Ａにおいては、「ＡＰＩ−Ｄ」、「ＡＰＩ−Ｅ」が該当し、「ＡＰＩ−Ｄ」は３４秒、「ＡＰＩ−Ｅ」は１５秒となる。この待機時間は、各ＡＰＩの流量制御が解除される時間である。

また、スケジュール部１０２３は、流量制御が設定されていないＡＰＩや、設定されていても制御状態ではなく、スケジュールテーブル１０３６で未実行でもないＡＰＩは、待機時間は０秒とする。

次に、スケジュール部１０２３は、ここまでで算出した仮想値や待機時間を流量制御状態テーブルに追記および上書きし、仮想流量制御状態テーブル１０３５Ｂを生成する（Ｓ１００７）。図６Ｂの流量制御状態テーブル１０３５Ａに対して、図６Ｃの流量制御状態テーブル１０３５Ｃが生成されることになる。

以上の手順により、スケジューリングを行う時点の流量制御状態に加えて、その後に実行されるスケジュールも考慮した仮想流量制御状態テーブルを生成できる。そのため、スケジューリング済みのＡＰＩ群の処理が実行できなくなることを回避することができるようになる。なお、マッシュアップのリクエスト時について説明したが、単体のＡＰＩのリクエスト時に対しても、スケジュールに割り込まないように、同様の処理を行うべきである。

続いて、ＡＰＩの実行スケジュール（すなわち処理スケジュール）の生成フローについて説明する。図１１は、直列処理の場合の、ＡＰＩ実行スケジュール作成の処理フロー図である。

この場合、ＡＰＩ管理システム１のスケジュール部１０２３は、マッシュアップ定義テーブル１０３３を参照し、リクエストされたマッシュアップの定義を取得する。（Ｓ１１０１）
次に、スケジュール部１０２３は、上述のＳ１００７で作成した仮想流量制御状態テーブル１０３５Ｃを参照し、各ＡＰＩの待機時間を取得する（Ｓ１１０２）
次に、スケジュール部１０２３は、上述のＳ１１０１で取得したマッシュアップ定義に対して、Ｓ１１０３〜Ｓ１１０６を行う。

具体的には、スケジュール部１０２３は、Ｓ１１０１で得たマッシュアップ定義の一番内側の（）内において、実行順序が任意であるＡＰＩ群に対して、Ｓ１１０４に従って実行順序を決定し、同様の処理をマッシュアップ定義の一番外側まで繰り返す。（Ｓ１１０３、Ｓ１１０４〜Ｓ１１０６）

Ｓ１１０４〜Ｓ１１０６におけるスケジュール部１０２３は、マッシュアップ定義の一番内側の（）内において、実行順序に依存関係のあるＡＰＩ群を１単位とし、各単位の先頭のＡＰＩの中で、待機時間が一番短いＡＰＩを１番目とする。以降、そのＡＰＩを除いて同様の判定を繰返し、２番目以降を決定する。

スケジュール部１０２３は、上述のＳ１１０３〜Ｓ１１０６を通じてマッシュアップを構成する複数のＡＰＩの実行順序を決定したら、推定処理時間テーブル１０３４を参照し、各ＡＰＩの実行予定時刻を付記し、スケジュールテーブル１０３６を更新する（Ｓ１１０７）。１つ前のＡＰＩ完了後、次のＡＰＩ開始までに待機時間が含まれることもある。

なお、こうした、マッシュアップにおける各ＡＰＩの実行順序の決定アルゴリズムの具体的なパターン例を図１２に示している。この図１２で示す例では、マッシュアップ定義におけるＡＰＩ実行の制約（すなわち依存関係）に応じて、どのような方針で実行順序の決定を行うか示している。基本的には、待機時間の短い順にＡＰＩを実行するよう順序決定することとなる。

また、並列処理の場合は、実行順序が任意であるＡＰＩ同士を別スレッドで実行するだけでも直列処理よりも高速化を実現できるが、更に、例えば待機時間が無く、推定処理時間の１番長いＡＰＩを１つのスレッド、残りを直列処理でスケジューリングをする等、組合せることで、高速化とスレッド数の抑制を行うことも可能である。

また、本実施形態ではマッシュアップを構成する複数のＡＰＩは全て異なるものであったが、同じＡＰＩを複数回実行するマッシュアップであっても、当該ＡＰＩの実行順序が決まる毎に仮想流量制御テーブルを更新しながら同様の処理を行えばよい。

なお、上述の例では、仮想流量制御状態テーブルを生成したことを契機にＡＰＩの実行
スケジュールを生成する例を示したが、そうした仮想流量制御状態テーブルではなく、当初の流量制御状態テーブル１０３５（図６Ａや図６Ｂ）に基づいて、ＡＰＩの実行スケジュールを生成するとしてもよい。

例えば、図６Ａの流量制御状態テーブル１０３５Ａを利用するとした場合、スケジュール部１０２３は、カウンタがいずれも流量制御設定の回数に到達済みで、流量制御対象となっている「ＡＰＩ−Ａ」、「ＡＰＩ−Ｄ」、「ＡＰＩ−Ｅ」、について、「現在時刻−１回目の時刻」の計算を行ってそれぞれの待機時間を算定する。その上で、図１１のフローと同様の処理を実行することで、マッシュアップにおけるＡＰＩの実行スケジュールを生成することとなる。
−−−第２実施形態−−−

本発明の第２実施形態として、ＡＰＩ管理システム１が、複数個の既存ＡＰＩのマッシュアップ全体としての処理時間について、エンドユーザの志向を条件に加えて、最適化する方式について説明する。以降、第１実施形態と異なる部分のみを説明する。

なお、上述のエンドユーザの条件とは、マッシュアップの遂行に関して当該エンドユーザが望む、マッシュアップ処理時間の下限や、当該エンドユーザの課金条件といった条件である。以後、こうした条件をユーザ条件と称する。

図１３は、第２実施形態におけるＡＰＩ管理システム１を含むネットワーク構成図である。第２実施形態におけるＡＰＩ管理システム１には、第１実施形態のＡＰＩ管理システム１に対して、演算部１０２におけるユーザ条件設定部１０２８と、記憶部１０３におけるユーザ条件テーブル１０３７が追加されている。
また、第２実施形態におけるアプリケーションサーバ２には、第１実施形態のアプリケーションサーバ２に対して、ユーザ条件蓄積部２０４が追加されている。
また、ＡＰＩ管理システム１は、図２のＡＰＩ定義テーブル１０３１に示した条件登録ＡＰＩと料金照会ＡＰＩを公開する。

このうち条件登録ＡＰＩは、ユーザ条件を記憶部１０３のユーザ条件テーブル１０３７に設定する機能を提供する。また、料金照会ＡＰＩは、後述する流量制御の解除時に発生する料金等、ＡＰＩ管理システム１の利用に伴って発生する料金を照会する機能を提供する。

本実施形態では、あるＡＰＩが流量制御のためにエラーとなる時に、エンドユーザがその意思によって追加料金を支払うことで、一時的に該当制御を回避できる機能をＡＰＩ管理システム１が有していることを前提とする。そのような機能は、例えば特開２０１５−１３００７３号公報に記載されている。

本実施形態において追加された構成のうち、ＡＰＩ管理システム１のユーザ条件設定部１０２８は、上述のエンドユーザによるエンドユーザ端末３の操作に応じてアプリケーションサーバ７から送信される条件登録ＡＰＩのリクエストを通信部１０１経由で受信し、記憶部１０３のユーザ条件テーブル１０３７（図１４）の生成や更新を行うプログラムで構成する。

また、アプリケーションサーバ２のユーザ条件蓄積部２０４は、画面生成部２０２が生成する業務処理方式設定画面１４０（図１５）に対する、エンドユーザによるエンドユーザ端末３を通じた操作に応じて設定されたユーザ条件のデータを蓄積するプログラムと記憶装置で構成する。ここで蓄積されたユーザ条件のデータは、業務処理方式設定画面１４０の再表示時に画面生成部２０２から参照されたり、ＡＰＩ管理システム１への条件登録
ＡＰＩのリクエスト時に参照されたりする。

図１４は、第２実施形態におけるユーザ条件テーブル１０３７のデータ構成例を示す図である。このユーザ条件テーブル１０３７は、エンドユーザ毎に、ＡＰＩ管理システム１の有償機能の利用方針を列挙したリストであり、本実施形態では特に、上述の流量制御の一時的な解除に対するユーザ毎の志向を示している。

例えば、エンドユーザ「Ｕｓｅｒ０１」は、流量制御の有償解除は利用するが、その料金は月に累計「３０００円」までとし、更に、有償解除を利用するのは、解除した場合のマッシュアップ全体の処理時間が「４５秒」以内である場合に限定する、ということを示している。また、有償解除を利用しなくても４５秒以内に収まる場合には、有償解除は利用しないことも示している。

ＡＰＩ管理システム１は、このようなユーザ条件を考慮することで、エンドユーザやタイミングやＡＰＩによって様々である、費用優先または時間優先に関するエンドユーザの志向を、マッシュアップにおけるＡＰＩのスケジューリングに取り込むことが可能である。これによりＡＰＩ管理システム１は、エンドユーザにとってより好適なＡＰＩ利用環境を提供することができる。

図１５は、業務処理方式設定画面１４０の例である。ユーザ条件テーブル１０３７は、エンドユーザの志向を取り込んだものである。そのため、ＡＰＩ管理システム１は、何らかの形で、エンドユーザからユーザ条件に関して入力を受け付けておく必要がある。

そこで、例えば、アプリケーションサーバ２は、そのようなユーザ条件の入力用の画面として、業務処理方式設定画面１４０をエンドユーザ端末３に配信し、その業務処理方式設定画面１４０での入力内容を、条件登録ＡＰＩを用いてＡＰＩ管理システム１に送信する、といった構成を採用すれば好適である。

この時、例えば現在および過去の料金を当該画面に表示しておくことで、エンドユーザの判断の補助とすることができる。そのような料金に関するデータは、ＡＰＩ管理システム１が保持しており、クライアントアプリケーション７が、料金照会ＡＰＩを用いて取得すればよい。

続いて、第２実施形態におけるＡＰＩ管理方法のフロー例について説明する。図１６は、第２実施形態におけるＡＰＩ管理方法のフロー例を示す図であり、具体的には、エンドユーザの志向、すなわちユーザ条件を踏まえた、マッシュアップを構成する複数のＡＰＩの実行スケジューリング処理を示す概略フロー図である。なお、本フローにおいて、Ｓ９０１およびＳ９０２は第１実施形態と同様であり、その説明は省略し、Ｓ９０３に関して説明する。

このＳ９０３において、ＡＰＩ管理システム１のスケジュール部１０２３は、今回の処理対象、すなわちＡＰＩの実行スケジュール生成対象としたエンドユーザに関して、ユーザ条件テーブル１０３７の「有料制御解除」欄の値を参照し、有料での流量制御解除サービスの利用可否を判定する（Ｓ９０３１）。

上述の判定の結果、有料での流量制御解除サービスを利用可能であることが判明した場合（Ｓ９０３２：ｙ）、スケジュール部１０２３は、上述のＳ９０２で作成した実行スケジュール内で流量制御の解除対象、すなわち待機時間が０ではないＡＰＩに対して流量制御の解除処理（ＡＰＩ管理システム１で予め規定した処理で、既存のもの）を実行する（Ｓ９０３３）。

他方、上述の判定の結果、有料での流量制御解除サービスを利用不可であることが判明した場合（Ｓ９０３２：ｎ）、スケジュール部１０２３は、処理を終了する。

続いて、スケジュール部１０２３は、上述のＳ９０３２にて、所定のＡＰＩに関して待機時間を０とした上で、Ｓ９０２と同様にＡＰＩの実行スケジュールを生成し、すなわち実行スケジュールを書き換え、スケジュールテーブル１０３６を更新し（Ｓ９０３４）、処理を終了する。

この時、スケジューリング前に上述の流量制御の解除を行うよりも、Ｓ９０２によるスケジューリング後のスケジュールに対して流量制御の解除を行った方が、待機時間が抑制されていることから、料金を抑制することができる。

なお、流量制御の解除に対する待機時間を単純に０にすると、既存スケジュールのＡＰＩ実行に割り込む可能性もある。その場合は、上述の流量制御の解除を伴うマッシュアップを構成するＡＰＩの実行は、カウンタの対象外にする等の例外を設けてもよい。

また、本実施形態において、ユーザ条件は、ＡＰＩ管理システム１に登録されたユーザ条件テーブル１０３７を参照するとした。しかしながら、例えば、エンドユーザ端末３でにおける所定のクライアントアプリケーションの操作を通じて、その１回のマッシュアップリクエストのみ、有料での流量制御解除を有効にするような方式としてもよい。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
こうした本実施形態によれば、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを踏まえ、マッシュアップ全体の処理効率を好適なものとできる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のＡＰＩ管理システムにおいて、前記演算部は、所定の処理スケジュールに基づき進行中のマッシュアップに関して、当該処理スケジュールと、該当ユーザの該当ＡＰＩに関する流量制御状態の情報とに基づき、当該マッシュアップにおける未実行のＡＰＩによって以後生じる流量制御状態を、仮想流量制御状態として特定し、当該仮想流量制御状態の情報と前記進行中のマッシュアップの定義とを前記所定アルゴリズムに適用して、前記所定の処理スケジュールを更新する処理を更に実行するものである、としてもよい。

これによれば、進行中のマッシュアップにおける状況を踏まえた将来的な流量制御状態を特定した上で、ＡＰＩの処理スケジュールを生成することが可能となる。ひいては、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを踏まえ、マッシュアップ全体の処理効率を更に好適なものとできる。

また、本実施形態のＡＰＩ管理システムにおいて、前記記憶部は、前記流量制御状態の情報として、各ユーザにおける各ＡＰＩに関して、その１回目の実行から所定時間までに実行された実行回数、および、前記１回目の実行時刻、の各情報を格納するものであり、前記演算部は、前記仮想流量制御状態の情報を特定するに際し、前記所定の処理スケジュールに含まれる未実行のＡＰＩの実行予定回数および実行予定時刻に基づいて、前記流量制御状態の情報に含まれる前記ＡＰＩの実行回数と前記１回目の実行時刻を更新して、前記ＡＰＩの仮想実行回数と前記１回目の仮想実行時刻を特定する処理と、前記未実行のＡＰＩが最後に実行される予定時刻を特定する処理と、前記１回目の仮想実行時刻と、前記最後の実行時刻と、現在時刻とに基づいて該当ＡＰＩの待機時間を算定する処理と、を実行するものである、としてもよい。

これによれば、進行中のマッシュアップにおける状況を踏まえた将来的な流量制御状態を効率的に特定した上で、ＡＰＩの処理スケジュールを生成することが可能となる。ひいては、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを踏まえ、マッシュアップ全体の処理効率を更に好適なものとできる。

また、本実施形態のＡＰＩ管理システムにおいて、前記記憶部は、前記マッシュアップの遂行に関してユーザが望む条件であるユーザ条件の情報を更に格納するものであり、前記演算部は、前記処理スケジュールの生成に際し、当該生成した処理スケジュールに沿って遂行した場合の前記マッシュアップの処理時間が、前記ユーザ条件で示す下限を上回るものであった場合、当該処理スケジュールに含まれる所定ＡＰＩに関する待機時間を、当該ユーザへの所定の課金処理によって低減ないし解消し、前記処理スケジュールを更新する処理を更に実行するものである、としてもよい。

これによれば、ユーザごとのニーズに応える形で、マッシュアップの処理速度やユーザのコスト負担とのバランスをとったスケジューリング処理を行って、ＡＰＩの処理スケジュールを生成することが可能となる。ひいては、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズを的確に踏まえ、マッシュアップ全体の処理効率を更に好適なものとできる。

また、本実施形態のＡＰＩ管理システムにおいて、前記演算部は、前記ユーザの端末に、前記ユーザ条件の入力画面を配信し、当該入力画面を介して入力された情報をユーザ条件の情報として格納する処理を更に実行するものである、としてもよい。

これによれば、ユーザごとのニーズを直接受け付けて取得し、これに的確に応える形で、マッシュアップの処理速度やユーザのコスト負担とのバランスをとったスケジューリング処理を行って、ＡＰＩの処理スケジュールを生成することが可能となる。ひいては、マッシュアップの含む各ＡＰＩの属性やエンドユーザのニーズをさらに的確に踏まえ、マッシュアップ全体の処理効率を更に好適なものとできる。

また、本実施形態のＡＰＩ管理方法において、前記情報処理システムが、所定の処理スケジュールに基づき進行中のマッシュアップに関して、当該処理スケジュールと、該当ユーザの該当ＡＰＩに関する流量制御状態の情報とに基づき、当該マッシュアップにおける未実行のＡＰＩによって以後生じる流量制御状態を、仮想流量制御状態として特定し、当該仮想流量制御状態の情報と前記進行中のマッシュアップの定義とを前記所定アルゴリズムに適用して、前記所定の処理スケジュールを更新する処理を更に実行する、としてもよい。

また、本実施形態のＡＰＩ管理方法において、前記情報処理システムが、前記記憶部において、前記流量制御状態の情報として、各ユーザにおける各ＡＰＩに関して、その１回目の実行から所定時間までに実行された実行回数、および、前記１回目の実行時刻、の各情報を格納し、前記仮想流量制御状態の情報を特定するに際し、前記所定の処理スケジュールに含まれる未実行のＡＰＩの実行予定回数および実行予定時刻に基づいて、前記流量制御状態の情報に含まれる前記ＡＰＩの実行回数と前記１回目の実行時刻を更新して、前記ＡＰＩの仮想実行回数と前記１回目の仮想実行時刻を特定する処理と、前記未実行のＡＰＩが最後に実行される予定時刻を特定する処理と、前記１回目の仮想実行時刻と、前記最後の実行時刻と、現在時刻とに基づいて該当ＡＰＩの待機時間を算定する処理と、を実行する、としてもよい。

また、本実施形態のＡＰＩ管理方法において、前記情報処理システムが、前記記憶部に
おいて、前記マッシュアップの遂行に関してユーザが望む条件であるユーザ条件の情報を更に格納し、前記処理スケジュールの生成に際し、当該生成した処理スケジュールに沿って遂行した場合の前記マッシュアップの処理時間が、前記ユーザ条件で示す下限を上回るものであった場合、当該処理スケジュールに含まれる所定ＡＰＩに関する待機時間を、当該ユーザへの所定の課金処理によって低減ないし解消し、前記処理スケジュールを更新する処理を更に実行する、としてもよい。

また、本実施形態のＡＰＩ管理方法において、前記情報処理システムが、前記ユーザの端末に、前記ユーザ条件の入力画面を配信し、当該入力画面を介して入力された情報をユーザ条件の情報として格納する処理を更に実行する、としてもよい。

１０〜１２ ネットワーク
１ ＡＰＩ管理システム
１０１ 通信部
１０２ 演算部
１０２１ ＡＰＩリクエスト処理部
１０２２ 流量制御部
１０２３ スケジュール部
１０２４ 処理時間推定部
１０２５ ＡＰＩ設定部
１０２６ マッシュアップ設定部
１０２７ 画面生成部
１０２８ ユーザ条件設定部
１０３ 記憶部
１０３１ ＡＰＩ定義テーブル
１０３２ ＡＰＩ流量制御設定テーブル
１０３３ マッシュアップ定義テーブル
１０３４ 推定処理時間テーブル
１０３５ 流量制御状態テーブル
１０３６ スケジュールテーブル
１０３７ ユーザ条件テーブル
２ アプリケーションサーバ
２０１ 通信部
２０２ 画面生成部
２０３ ＡＰＩリクエスト生成部
３ エンドユーザ端末
３０１ 通信部
３０２ 表示部
３０３ 入力部
４ ＡＰＩサーバ
４０１ 通信部
４０２ ＡＰＩレスポンス生成部
５ 管理者端末
５０１ 通信部
５０２ 表示部
５０３ 入力部

Claims (10)

1. ＡＰＩの各ユーザに関する流量制御状態の情報を格納した記憶部と、
   ＡＰＩのマッシュアップに関するユーザからのリクエストを所定装置より受け付けて、前記リクエストが含む当該マッシュアップの定義と、前記ユーザの該当ＡＰＩに関する前記流量制御状態の情報とを所定アルゴリズムに適用し、前記定義におけるＡＰＩ間の依存関係を制約条件とし、前記流量制御状態の情報における流量制御解除までの待機時間を最小化する、ＡＰＩの処理スケジュールを生成する演算部と、
   を備えることを特徴とするＡＰＩ管理システム。
2. 前記演算部は、
   所定の処理スケジュールに基づき進行中のマッシュアップに関して、当該処理スケジュールと、該当ユーザの該当ＡＰＩに関する流量制御状態の情報とに基づき、当該マッシュアップにおける未実行のＡＰＩによって以後生じる流量制御状態を、仮想流量制御状態として特定し、当該仮想流量制御状態の情報と前記進行中のマッシュアップの定義とを前記所定アルゴリズムに適用して、前記所定の処理スケジュールを更新する処理を更に実行するものである、
   ことを特徴とする請求項１に記載のＡＰＩ管理システム。
3. 前記記憶部は、
   前記流量制御状態の情報として、各ユーザにおける各ＡＰＩに関して、その１回目の実行から所定時間までに実行された実行回数、および、前記１回目の実行時刻、の各情報を格納するものであり、
   前記演算部は、
   前記仮想流量制御状態の情報を特定するに際し、前記所定の処理スケジュールに含まれる未実行のＡＰＩの実行予定回数および実行予定時刻に基づいて、前記流量制御状態の情報に含まれる前記ＡＰＩの実行回数と前記１回目の実行時刻を更新して、前記ＡＰＩの仮想実行回数と前記１回目の仮想実行時刻を特定する処理と、前記未実行のＡＰＩが最後に実行される予定時刻を特定する処理と、前記１回目の仮想実行時刻と、前記最後の実行時刻と、現在時刻とに基づいて該当ＡＰＩの待機時間を算定する処理と、を実行するものである、
   ことを特徴とする請求項２に記載のＡＰＩ管理システム。
4. 前記記憶部は、
   前記マッシュアップの遂行に関してユーザが望む条件であるユーザ条件の情報を更に格納するものであり、
   前記演算部は、
   前記処理スケジュールの生成に際し、当該生成した処理スケジュールに沿って遂行した場合の前記マッシュアップの処理時間が、前記ユーザ条件で示す下限を上回るものであった場合、当該処理スケジュールに含まれる所定ＡＰＩに関する待機時間を、当該ユーザへの所定の課金処理によって低減ないし解消し、前記処理スケジュールを更新する処理を更に実行するものである、
   ことを特徴とする請求項１に記載のＡＰＩ管理システム。
5. 前記演算部は、
   前記ユーザの端末に、前記ユーザ条件の入力画面を配信し、当該入力画面を介して入力された情報をユーザ条件の情報として格納する処理を更に実行するものである、
   ことを特徴とする請求項４に記載のＡＰＩ管理システム。
6. ＡＰＩの各ユーザに関する流量制御状態の情報を格納した記憶部を備えた情報処理シス
   テムが、
   ＡＰＩのマッシュアップに関するユーザからのリクエストを所定装置より受け付けて、前記リクエストが含む当該マッシュアップの定義と、前記ユーザの該当ＡＰＩに関する前記流量制御状態の情報とを所定アルゴリズムに適用し、前記定義におけるＡＰＩ間の依存関係を制約条件とし、前記流量制御状態の情報における流量制御解除までの待機時間を最小化する、ＡＰＩの処理スケジュールを生成する、
   ことを特徴とするＡＰＩ管理方法。
7. 前記情報処理システムが、
   所定の処理スケジュールに基づき進行中のマッシュアップに関して、当該処理スケジュールと、該当ユーザの該当ＡＰＩに関する流量制御状態の情報とに基づき、当該マッシュアップにおける未実行のＡＰＩによって以後生じる流量制御状態を、仮想流量制御状態として特定し、当該仮想流量制御状態の情報と前記進行中のマッシュアップの定義とを前記所定アルゴリズムに適用して、前記所定の処理スケジュールを更新する処理を更に実行する、
   ことを特徴とする請求項６に記載のＡＰＩ管理方法。
8. 前記情報処理システムが、
   前記記憶部において、前記流量制御状態の情報として、各ユーザにおける各ＡＰＩに関して、その１回目の実行から所定時間までに実行された実行回数、および、前記１回目の実行時刻、の各情報を格納し、
   前記仮想流量制御状態の情報を特定するに際し、前記所定の処理スケジュールに含まれる未実行のＡＰＩの実行予定回数および実行予定時刻に基づいて、前記流量制御状態の情報に含まれる前記ＡＰＩの実行回数と前記１回目の実行時刻を更新して、前記ＡＰＩの仮想実行回数と前記１回目の仮想実行時刻を特定する処理と、前記未実行のＡＰＩが最後に実行される予定時刻を特定する処理と、前記１回目の仮想実行時刻と、前記最後の実行時刻と、現在時刻とに基づいて該当ＡＰＩの待機時間を算定する処理と、を実行する、
   ことを特徴とする請求項７に記載のＡＰＩ管理方法。
9. 前記情報処理システムが、
   前記記憶部において、前記マッシュアップの遂行に関してユーザが望む条件であるユーザ条件の情報を更に格納し、
   前記処理スケジュールの生成に際し、当該生成した処理スケジュールに沿って遂行した場合の前記マッシュアップの処理時間が、前記ユーザ条件で示す下限を上回るものであった場合、当該処理スケジュールに含まれる所定ＡＰＩに関する待機時間を、当該ユーザへの所定の課金処理によって低減ないし解消し、前記処理スケジュールを更新する処理を更に実行する、
   ことを特徴とする請求項６に記載のＡＰＩ管理方法。
10. 前記情報処理システムが、
    前記ユーザの端末に、前記ユーザ条件の入力画面を配信し、当該入力画面を介して入力された情報をユーザ条件の情報として格納する処理を更に実行する、
    ことを特徴とする請求項９に記載のＡＰＩ管理方法。

Images