JP2019046015A - アプリケーション稼働監視装置および監視方法 - Google Patents

Abstract

【課題】アプリケーションプログラムの稼働状態の監視に適したアプリケーションプログラミングインタフェースを選択する。
【解決手段】監視対象となるＡＰ１０２が呼び出すＡＰＩの中から、リクエストの実行に情報の変更を伴わないＡＰＩを監視用ＡＰＩとして選択し、監視用ＡＰＩに対して擬似的なリクエストを送信して該リクエストに対する応答を受信することで、当該監視用ＡＰＩが正常に稼働しているか否か判断する監視ノード１０６を作成してＡＰ１０６に包含させる。
【選択図】図１

Description

本発明は、アプリケーションプログラムの稼働状態を監視するアプリケーション稼動監視装置および監視方法に関する。

あるソフトウェアが、機能やデータを提供するためのインタフェースを持ち、他のソフトウェアが、そのソフトウェアのインタフェースを利用して所望の機能やデータの提供を受けることで、必要な機能やデータを組み込んだソフトウェアを容易に開発できる仕組みが知られている。このように、インタフェースを持ち、機能やデータを提供するソフトウェアをサービスと呼ぶ。

また、ソフトウェア開発環境として、視覚的な機能オブジェクトの組み合わせによるプログラミングを可能とするビジュアルプログラミング言語が知られている。開発者は、所定の機能を提供する機能オブジェクトを作成、編集、登録、利用することができ、所望の機能オブジェクト同士を結び付けることでビジュアル的にデータ入出力を定義して、アプリケーションプログラムを開発することができる。機能オブジェクトは、上述したサービスのインタフェースを呼び出す処理を行うものであってもよい。

ここで、開発されたアプリケーションプログラム（以下、ＡＰと称する）が稼動する際、正常稼動を継続できるよう、その稼働状態を監視することが望まれる。ＡＰの稼動状態を監視する方法として、監視サーバが、アプリケーションで順番に実施される各Ｗｅｂサービスに対して擬似リクエストを発行し、その擬似リクエストに対する応答を確認することでＷｅｂサービスの稼動を監視する方法が知られており、特許文献１に開示されている。

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

ＡＰが、１つ以上の機能オブジェクトを順番（例えばオブジェクト１、オブジェクト２、オブジェクト３の順）に使用し、各機能オブジェクトでは、サービスが提供するインタフェースを呼び出して複数のサービスを使用する構成になることが想定される。そのような構成においては、ＡＰは、途中の機能オブジェクト２にて呼び出し先のサービスから正常な応答が返されない場合、最初の機能オブジェクト１からリトライする必要があり、機能オブジェクト１についての処理時間や課金等の無駄が発生する。

そのため、ＡＰが使用するサービスの中に正常に稼動しないものが存在する場合は、全てのサービスが正常に稼動するまで待つことが望ましい。そのためには、ＡＰの稼動開始時に、ＡＰが使用しているサービスに対して、ＡＰが使用する条件でサービスが使用可能かどうかを確認することが望まれる。

ここで、機能オブジェクトとサービスとの対応付けは１対１とは限らない。１つの機能オブジェクトが呼び出す複数のアプリケーションプログラミングインタフェース（Application Programming Interface、以下、ＡＰＩと称する）が、互いに異なるサービスから提供されるものである可能性がある。また、互いに異なる機能オブジェクトが同一のサービスのＡＰＩを呼び出す可能性もある。そのため、多数の機能オブジェクトを使用してＡＰを作成する場合、ＡＰが使用するサービスの状況を把握するのが難しい。また、サービスから提供されるＡＰＩは様々であり、情報を参照するだけのものと、情報の変更を伴うものとが混在する。

ところで、上述したように、サービスに対して擬似リクエストを発行し、その擬似リクエストに対する応答を確認することでサービスの稼動を監視する方法が特許文献１に開示されている。しかしながら、ＡＰの稼働状態を監視するために、サービス内で処理が行われてデータ等サービスの情報を変更するようなＡＰＩに対して、擬似リクエストのような擬似的な呼び出しを行った場合、擬似リクエストによってサービス側の情報が変更されてしまう可能性があり、好ましくない。特許文献１に開示されたものにおいては、入手したワークフローに従って処理を実行するものであるため、情報の変更を伴うリクエストかどうかは考慮されていない。そのため、ＡＰが使用する各サービスに対して提供される複数のＡＰＩの中から、ＡＰの稼働状態の監視に適したＡＰＩを判断することは難しい。

本発明は、アプリケーションプログラムの稼働状態の監視に際し、アプリケーションプログラムが使用するサービスに対して提供される複数のアプリケーションプログラミングインタフェースの中から、アプリケーションプログラムの稼働状態の監視に適したアプリケーションプログラミングインタフェースを選択することを目的とする。

上記目的を達成するために本発明の一態様によるアプリケーション稼働監視装置は、サービスから提供されたアプリケーションプログラミングインタフェースを呼び出して稼働するアプリケーションプログラムの稼働状況を監視するアプリケーション稼働監視装置であって、監視対象となるアプリケーションプログラムのソースコードに含まれているアプリケーションプログラミングインタフェースを抽出する抽出部と、公開されたアプリケーションプログラミングインタフェースが前記サービス単位のグループ毎に登録されたグループ情報に基づいて、前記抽出されたアプリケーションプログラミングインタフェースが属するグループを特定するグループ特定処理部と、前記特定されたグループに属するアプリケーションプログラミングインタフェースの中から、リクエストの実行に情報の変更を伴わないアプリケーションプログラミングインタフェースを監視用アプリケーションプログラミングインタフェースとして選択する選択部と、前記監視用アプリケーションプログラミングインタフェースに対して擬似的なリクエストを送信して該リクエストに対する応答を受信することで、当該監視用アプリケーションプログラミングインタフェースが正常に稼働しているか否か判断する監視ノードを作成する監視ノード作成部と、前記監視ノードを前記アプリケーションプログラムに包含させるノード登録部と、を有する。

本発明によれば、アプリケーションプログラムの稼働状態の監視に際し、アプリケーションプログラムが使用するサービスに対して提供される複数のアプリケーションプログラミングインタフェースの中から、アプリケーションプログラムの稼働状態の監視に適したアプリケーションプログラミングインタフェースを選択することができる。

第１の実施形態によるアプリケーション稼働監視装置を採用したコンピュータシステムの一例を示す概念図である。 図１に示した稼動監視設定プログラムを実行するサーバのハードウェア構成の一例を示す図である。 図１に示した稼動監視設定プログラムの機能モジュール構成の一例を示す図である。 図１〜図３に示した稼動監視設定プログラムの全体の処理を説明するためのフローチャートである。 図１〜図３に示した稼動監視設定プログラムにおける監視ノード作成処理を説明するためのフローチャートである。 図３に示したノード管理テーブルの構成例を示す図である。 図１〜図３に示した稼動監視設定プログラムにおけるＡＰＩのサービス特定処理を説明するためのフローチャートである。 図１〜図３に示した稼動監視設定プログラムにおけるＡＰＩを選択する処理を説明するためのフローチャートである。 図３に示したＡＰＩグループ管理テーブルの構成例を示す図である。 図１〜図３に示した稼動監視設定プログラムによって表示出力される画面例を示す図である。 図１に示した稼動監視設定プログラムの機能モジュール構成の他の例を示す図である。 図１１に示した稼動監視設定プログラムにおける監視実行処理を説明するためのフローチャートである。 図１２に示したノード管理テーブルの構成例を示す図である。

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

（第１の実施の形態）
図１は、第１の実施形態のアプリケーション稼働監視装置を採用したコンピュータシステムの一例を示す概念図である。

本例におけるコンピュータシステムは図１に示すように、稼動監視設定プログラム１０１と、アプリケーションプログラム（ＡＰ）１０２と、サービス１０４と、ＡＰＩゲートウェイ１０５とを有している。

ＡＰ１０２は、ＡＰ開発に使用される入出力が既定されたモジュールである機能オブジェクトとなる複数のノード１０３と、監視用の機能オブジェクトである監視ノード１０６とを含んでいる。ＡＰ１０２は、後述するＡＰＩを利用してサービス１０４に要求を送信し、応答を受信する。各ソフトウェアが実行されるサーバやネットワークは図示しないが、ＡＰ１０２とサービス１０４とは同一のサーバ上で実行されてもよい。ＡＰ１０２とサービス１０４とが、別々のサーバで実行される場合はネットワーク経由で要求および応答を送受信する。

サービス１０４は、ＡＰの実行環境の外部で稼動して、機能やデータを提供するソフトウェアである。サービス１０４が他のソフトウェアに機能やデータを提供するインタフェースが上述したＡＰＩである。サービス１０４はクラウドプラットフォーム１０７上で稼動し、ＡＰ−１，ＡＰ−２といった複数のＡＰ１０２から利用される形態となっている。

ＡＰＩゲートウェイ１０５は、ＡＰＩを管理する管理装置として、機能やデータの提供側であるサービス１０４と利用側であるＡＰ１０２との間に介在し、サービス１０４の提供するＡＰＩを管理するソフトウェアあるいはそのソフトウェアを実行する計算機である。具体的には、公開されたＡＰＩについて、サービス１０４単位でグループを構成し、そのグループ毎のグループ情報として、サービス１０４から提供されるＡＰＩが、リクエストの実行に情報の変更を伴うものであるか否かを示す属性情報を登録、管理している。また、ＡＰＩゲートウェイ１０５は、ＡＰＩを使用するための認証機能や、サービスが利用者側に公開するＡＰＩを内部用ＡＰＩとは別に提供したい場合に、その管理を行って変換する機能などを持つ。

なお、図１では、ＡＰ１０２に含まれるノード１０３間の矢印はＡＰ１０２内におけるデータフローを示し、ノード１０３からサービス１０４に対する矢印は、ＡＰＩゲートウェイ１０５を介して、ノード１０３がサービス１０４の提供するＡＰＩを呼び出すことを示している。

図２は、図１に示した稼動監視設定プログラム１０１を実行するサーバのハードウェア構成の一例を示す図である。

本例におけるハードウェアは、図２に示すように、１つ以上の中央処理装置（ＣＰＵ）２０１と、メモリ２０２と、ハードディスク等の二次記憶装置２０３と、キーボードやマウスからの入力とディスプレイへの出力情報を制御する入出力インタフェース２０４と、ネットワークに接続するネットワークインタフェース２０５とから構成される。

上記のように構成されたハードウェアにおいては、サーバのメモリ２０２上に稼動監視設定プログラム１０１がロードされ、ＣＰＵ２０１により実行される。また、二次記憶装置２０３には、稼動監視設定プログラム１０１が使用するテーブル２０６のデータが保存される。

なお、ＡＰ１０２やサービス１０４、ＡＰＩゲートウェイ１０５を実行するサーバのハードウェア構成も同様である。なお、各サーバは物理マシンでなく仮想マシンとして実装されてもよい。

図３は、図１に示した稼動監視設定プログラム１０１の機能モジュール構成の一例を示す図である。

本例における稼動監視設定プログラム１０１の機能モジュールとして、図３に示すように、コード取得部３０１と、ＡＰＩ抽出部３０２と、ＡＰＩ登録確認部３０３と、ＡＰＩゲートウェイ通信部３０４と、グループ特定処理部３０５と、ＡＰＩ属性確認部３０６と、ＡＰＩ選択部３０７と、監視ノード作成部３０８と、ノード登録部３０９とがある。稼働監視設定プログラム１０１は、アプリケーション稼働監視装置の第１の実施の形態を構成する。また、図１に示した稼動監視設定プログラム１０１の機能モジュール構成は、各処理が使用するテーブルとして、ノード管理テーブル３１０と、ＡＰＩグループ管理テーブル３１１とを有している。

コード取得部３０１は、監視対象となるＡＰのソースコードをＡＰ開発環境３１２から取得する。

ＡＰＩ抽出部３０２は、コード取得部３０１が取得したソースコードを解析し、ソースコードに含まれているＡＰＩを抽出する。

ＡＰＩ登録確認部３０３は、ＡＰＩ抽出部３０２が抽出したＡＰＩがＡＰＩゲートウェイ１０５に登録されているかを、ＡＰＩゲートウェイ通信部３０４を介して確認する。ＡＰＩゲートウェイ１０５には、ＡＰ１０２がサービス１０４を利用することができるようにするために、ＡＰＩが、そのサービス１０４単位でグループを構成して登録、公開されている。

ＡＰＩゲートウェイ通信部３０４は、ＡＰＩゲートウェイ１０５から情報を取得するためのものである。

グループ特定処理部３０５は、ＡＰＩとサービス毎のグループとをマッピングすることで、ＡＰＩ抽出部３０２が抽出したＡＰＩが属するグループを特定する。この際、グループ特定処理部３０５は、ＡＰＩ抽出部３０２が抽出したＡＰＩがＡＰＩ登録確認部３０３にてグループ情報に登録されていることが確認された場合に、上記処理を行う構成とすることが考えられる。

ＡＰＩ属性確認部３０６は、ＡＰＩゲートウェイ１０５に登録されたＡＰＩの属性情報を確認する。ＡＰＩゲートウェイ１０５には、上述したように、公開されたＡＰＩについて、サービス１０４単位で構成されたグループ毎のグループ情報として、サービス１０４から提供されるＡＰＩが、リクエストの実行に情報の変更を伴うものであるか否かを示す属性情報が登録されているため、ＡＰＩ属性確認部３０６は、この属性情報を確認することになる。

ＡＰＩ選択部３０７は、グループ特定処理部３０５が特定したグループに属するＡＰＩの中から、リクエストの実行に情報の変更を伴わないＡＰＩを、ＡＰの稼働状態の監視に適した監視用ＡＰＩとして選択する。

監視ノード作成部３０８は、ＡＰＩ選択部３０７が選択した監視用ＡＰＩに対して擬似的なリクエストを送信して該リクエストに対する応答を受信することで監視用ＡＰＩが正常に稼働しているか否か判断する監視用の機能モジュールである監視ノードを作成する。

ノード登録部３０９は、監視ノード作成部３０８が作成した監視ノードを、ＡＰ開発環境３１２に登録することで、ＡＰに包含させる。

以下に、上記のように構成されたコンピュータシステムにおけるＡＰの稼働監視方法について説明する。

図４は、図１〜図３に示した稼動監視設定プログラム１０１の全体の処理を説明するためのフローチャートである。

まず、ＡＰ開発者が、ＡＰ開発環境３１２を使用してＡＰのフローを作成し、登録を実行した際に、そのフロー登録を検知する（ステップ４０１）。検知方法としては、ＡＰ開発環境３１２上に稼動監視設定プログラム１０１を呼び出すためのボタンを表示して、ＡＰ開発者がボタンを押す操作を検知する方法や、ＡＰ開発環境３１２での処理をフックする方法等がある。

次に、登録されたフローについて、コード取得部３０１が、ＡＰ開発環境３１２からソースコードのエクスポートを実行することにより、ソースコードを取得する（ステップ４０２）。

次に、稼動監視設定プログラム１０１では、コード取得部３１２が取得したソースコードに基づいて、後述する監視ノード作成処理を行う（ステップ４０３）。

次に、稼動監視設定プログラム１０１では、作成された監視ノードのソースコードを、取得したフローのソースコードに追加し（ステップ４０４）、該フローをＡＰ開発環境３１２にインポートすることで、監視ノードをＡＰに包含させる（ステップ４０５）。ＡＰ開発者は、監視ノードが追加された当該フローをＡＰ開発環境３１２のＧＵＩで確認することができる。

なお、ステップ４０３における監視ノード作成処理によって作成されたＡＰ用の監視ノードをＡＰ開発環境３１２にインポートしてもよい。その場合は、インポートされたノードをＡＰ開発者がＡＰのフローに追加する処理を行うことになる。

図５は、図１〜図３に示した稼動監視設定プログラム１０１における監視ノード作成処理を説明するためのフローチャートであり、図４に示したステップ４０３における監視ノード作成処理の詳細を説明するためのものである。

稼動監視設定プログラム１０１における監視ノード作成処理においては、まず、ＡＰＩ抽出部３０２が、コード取得部３０１が取得したＡＰのソースコードを解析することで、ＡＰ内で呼び出しているＡＰＩを抽出し（ステップ５０１）、ＡＰのノード毎にノード管理テーブル３１０に登録する。

図６は、図３に示したノード管理テーブル３１０の構成例を示す図である。

図３に示したノード管理テーブル３１０は、例えば図６に示すように、ＡＰ１０２を識別するＡＰＩＤフィールド８０１と、ノード１０３を識別するノードＩＤフィールド８０２と、ノード１０３が呼び出しているＡＰＩを示すＡＰＩフィールド８０３とから構成され、ノードと、ＡＰＩ抽出部３０２が抽出したＡＰＩとが、ＡＰ１０２単位で管理されている。

次に、稼動監視設定プログラム１０１では、ＡＰＩ抽出部３０２が抽出したＡＰＩがどのサービスのものかを特定するサービス特定処理を行い（ステップ５０２）、サービスグループ毎に監視のためのＡＰＩを選択するＡＰＩ選択処理を行う（ステップ５０３）。

次に、監視ノード作成部３０８が、ＡＰＩ選択処理にて選択されたＡＰＩに対して擬似的なリクエストを送信して該リクエストに対する応答を受信して選択されたＡＰＩを呼び出すことでそのＡＰＩが正常に稼働しているか否か判断するソースコードを作成し（ステップ５０４）、監視ノードとして出力する（ステップ５０５）。

図７は、図１〜図３に示した稼動監視設定プログラム１０１におけるＡＰＩのサービス特定処理を説明するためのフローチャートであり、図５に示したステップ５０２における処理の詳細を説明するためのものである。

稼動監視設定プログラム１０１におけるサービス特定処理においては、まず、ＡＰゲートウェイ通信部３０４がＡＰゲートウェイ１０５と通信して、ＡＰＩゲートウェイ１０５の管理する公開ＡＰＩの一覧を取得するとともに（ステップ６０１）、ＡＰＩゲートウェイ１０５にて管理されるＡＰＩグループ情報をＡＰＩゲートウェイ１０５から取得する（ステップ６０２）。ＡＰＩゲートウェイ１０５には、上述したように、ＡＰ１０２がサービス１０４を利用することができるようにするために、ＡＰＩが、そのサービス１０４単位でグループを構成して登録、公開されており、また、公開されたＡＰＩについて、サービス１０４単位で構成されたグループ毎のグループ情報が登録されているため、ＡＰゲートウェイ通信部３０４は、これらの情報をＡＰＩゲートウェイ１０５から取得することができる。

次に、稼動監視設定プログラム１０１においては、ＡＰゲートウェイ通信部３０４が取得した情報を使用して、ノード管理テーブル３１０に登録されているＡＰＩについて、ノード管理テーブル３１０から順に読み出し（ステップ６０３）、以下の処理を行う。

まず、ＡＰＩ登録確認部３０３が、ノード管理テーブル３１０から読み出したＡＰＩについて、ＡＰゲートウェイ通信部３０４がＡＰゲートウェイ１０５から取得した公開ＡＰＩ一覧に該当するものがあるかを確認する（ステップ６０４）。この際、ノード管理テーブル３１０から読み出したＡＰＩについては、パラメータの設定値部分を除いた形式で該当するものがあるかを確認する。該当するものがない場合は、ステップ６０３に戻り、次のＡＰＩについて同様に確認を行う。

ノード管理テーブル３１０から読み出したＡＰＩが公開ＡＰＩに該当する場合、サービスを呼び出すＡＰＩであるとして、次に、ステップ６０２にて取得したＡＰＩグループ情報に基づいて、ＡＰＩがどのサービスに属するＡＰＩかを確認する（ステップ６０５）。

そして、ノード管理テーブル３１０から読み出したＡＰＩが属するグループがあれば、ＡＰＩグループ管理テーブル３１１に登録する（ステップ６０６）。

ＡＰ１０２が呼び出しているノード管理テーブル３１０に登録された全てのＡＰＩを確認した時点（ステップ６０７のYｅｓ）で本処理を終了する。

図８は、図１〜図３に示した稼動監視設定プログラム１０１におけるＡＰＩを選択する処理を説明するためのフローチャートであり、図５に示したステップ５０３におけるＡＰＩ選択処理の詳細を説明するためのものである。

稼動監視設定プログラム１０１におけるＡＰＩ選択処理においては、まず、ＡＰゲートウェイ通信部３０４がＡＰゲートウェイ１０５と通信して、ＡＰＩゲートウェイ１０５からＡＰＩの属性情報を取得し、ＡＰＩグループ管理テーブル３１１に登録された各ＡＰＩについて、リクエストの実行に対してサービスの情報の変更を伴わずに情報を参照する参照系のＡＰＩであるか、リクエストの実行に対して情報の変更を伴う更新系のＡＰＩかをＡＰＩ管理テーブルの属性フィールドに登録する（ステップ７０１）。

図９は、図３に示したＡＰＩグループ管理テーブル３１１の構成例を示す図である。

図３に示したＡＰＩグループ管理テーブル３１１は、例えば図８に示すように、グループを識別するグループＩＤフィールド９０１と、グループに対応したサービスを識別するサービスＩＤフィールド９０２と、サービスが提供するＡＰＩからなるＡＰＩフィールド９０３と、ＡＰＩが、リクエストの実行に対してサービスの情報の変更を伴わずに情報を参照する処理を行う参照系のＡＰＩであるか、リクエストの実行に対して情報の変更を伴う更新系のＡＰＩであるかを示す属性フィールド９０４とから構成され、サービス単位でのＡＰＩを管理する。このように、稼動監視設定プログラム１０１においては、各ＡＰＩの属性として、ＡＰＩが、サービスの情報を参照する処理を行う参照系のものか、更新処理を行う更新系のものかを識別する情報を、ＡＰＩゲートウェイ１０５から取得して設定する。

次に、ＡＰＩ選択部３０７が、ＡＰＩグループ管理テーブル３１１に登録されたサービスを順番に選択し（ステップ７０２）、監視に使用するＡＰＩを選択する。

ＡＰＩ選択部３０７においてはまず、ＡＰＩグループ管理テーブル３１１にてサービスに含まれるＡＰＩのうち、属性が参照系であるＡＰＩを抽出する（ステップ７０３）。

抽出した参照系のＡＰＩが複数ある場合は（ステップ７０４のＹｅｓ）、いずれかのＡＰＩを選択する。ここでは、ＡＰにおいて、フローに従ってノードをフローの上流からソートする（ステップ７０５）。最も上流のノードが呼び出すＡＰＩを特定し（ステップ７０６）、監視用ＡＰＩとして決定する（ステップ７０７）。ノード内に複数のＡＰＩがある場合は、例えば、取得したソースコードの解析で最初に抽出したものを選択する。ＡＰＩを選択する方法としては、ランダムに１つ選択する方法でもよいし、１つに限らず、条件に一致するＡＰＩであれば複数選択してもよい。

このように、参照系のＡＰＩが複数存在する場合に、監視対象となるＡＰに含まれるノードのうち上流側のノードが呼び出すＡＰＩを監視用ＡＰＩとして選択することにより、ＡＰの実行時に効率的にＡＰＩの稼働状態を確認することができる。

ステップ７０３で抽出したＡＰＩが１つであった場合は、そのＡＰＩを監視用ＡＰＩとして決定する（ステップ７０７）。

その後、全てのサービスについてＡＰＩを選択できた場合（ステップ７０８）、処理を終了する。

このように、ＡＰＩゲートウェイ１０５が有するグループ情報から、監視対象となるＡＰＩの属するグループを特定し、そのグループから監視用ＡＰＩを選択するので、監視対象となるＡＰＩと同じグループの監視用ＡＰＩを確実に選択することができる。なお、ステップ７０３にて属性が参照系であるＡＰＩが１つもない場合は、そのＡＰを監視対象としないことが考えられる。

図１０は、図１〜図３に示した稼動監視設定プログラム１０１によって表示出力される画面例を示す図である。

図１〜図３に示した稼動監視設定プログラム１０１においては、図１０に示すような画面を入出力インタフェース２０４を介して表示出力する。上段１００１には、稼動監視設定プログラム１０１の出力結果をインポートした監視ノードが追加されたフローが表示される。監視ノードを追加する前の変更前フローも出力すれば比較が可能である。

下段１００２には、サービスの稼動状態が表示出力される。例えばサービスとＡＰＩの状態、最終確認時刻が表形式（１００３）で表示出力される。なお、稼動監視はＡＰ実行時だけでなく、定期的に実行してもよい。その場合、監視が実行された最終確認時刻が表示出力される。

上述した実施の形態では、稼動監視設定プログラム１０１において、ＡＰＩゲートウェイ１０５からＡＰＩが参照系か更新系かの属性を取得し、その属性に基づいて監視用ＡＰＩを選択しているが、監視用ＡＰＩを選択するためにＡＰＩを参照系であると判別する他の方法としては、種別が情報取得を示すＧＥＴのＵＲＬであり、かつ、ＵＲＬ以外にパラメータを含まない、または、種別が情報取得を示すＧＥＴのＵＲＬであり、かつ、ＵＲＬに「ｉｍｇ」が含まれ画像読み込み用である場合に、参照系であると判別する判別方法が考えられる。これらの判別方法は、ＡＰＩゲートウェイ１０５から取得したグループ情報に、リクエストの実行に情報の変更を伴うか否かを示す属性情報が含まれていない場合に用いることができる。このように、ＡＰＩゲートウェイ１０５にて管理されているグループ情報から属性情報が得られればその属性情報を用いて監視用ＡＰＩを選択し、グループ情報から属性情報が得られなければ、ＡＰＩの内容に基づいて監視用ＡＰＩを選択することで、グループ情報に基づいて参照系のＡＰＩを監視用ＡＰＩとして確実に選択可能であるとともに、グループ情報から属性情報が得られない場合にも監視用ＡＰＩを選択することができる。

さらに、監視用ＡＰＩの選択手段として、課金情報を使用する方法がある。ＡＰＩによっては、呼び出すサービスで課金されるものと課金されないものがある場合がある。こうしたＡＰＩの課金情報をＡＰＩゲートウェイまたは、ＡＰＩゲートウェイとは別の課金サーバがシステムに存在する場合、本プログラムではＡＰＩの課金属性をＡＰＩゲートウェイまたは課金サーバから取得する。複数のＡＰＩから選択する手段において、複数のＡＰＩの中から課金されないＡＰＩを選択する方法もある。

また、ソースコードから抽出されたＡＰＩが更新系の場合に、同じグループに属する参照系のＡＰＩを監視用ＡＰＩとする構成とすることも考えられる。その場合、抽出されたＡＰＩが参照系でも更新系でも適切に監視用ＡＰＩを設定することができる。

上述したように本形態においては、ＡＰのソースコードから抽出したＡＰＩと同じグループに属するＡＰＩのうち、リクエストの実行に情報の変更を伴わない参照用のＡＰＩを監視用ＡＰＩとして選択し、この監視用ＡＰＩの正常な稼働を確認することにより対象ＡＰＩの正常な稼働を推定するので、情報が変化してサービスの状態に影響を与えることなくＡＰの稼働を確認することができる。

なお、本実施形態では、稼動監視設定プログラム１０１をＡＰ開発環境３１２とは別のプログラムとして実行する場合を示したが、稼動監視設定プログラム１０１をＡＰ開発環境３１２の一部のモジュールとして実装してもよい。

また、本実施形態は、開発環境におけるフロー作成のタイミングで実行されるものであるが、フロー登録は、新規作成時のみでなく、フローの更新のタイミングも同様である。

（第２の実施の形態）
図１１は、図１に示した稼動監視設定プログラム１０１の機能モジュール構成の他の例を示す図である。

本例における稼動監視設定プログラム１０１の機能モジュール構成は、図１１に示すように、図３に示したものに対して、監視実行部１２０１を有する点が異なるものである。

監視実行部１２０１は、上記のようにしてＡＰ１０２に包含された監視ノード１０６が実行されると、ＡＰに含まれるノード１０３のそれぞれについて、ノード１０３が呼び出す全てのＡＰＩに対応する監視用ＡＰＩが正常に稼働していればそのノード１０３が正常状態であると判断し、そのノードが呼び出す１つ以上のＡＰＩに対応する監視用ＡＰＩが正常に稼働していなければそのノードが異常状態であると判断する。そして、ＡＰに含まれる全てのノードが正常状態であればそのＡＰを実行可能とし、ＡＰに含まれる１つ以上のノードが異常状態であればそのＡＰを実行待ちとする。

図１２は、図１１に示した稼動監視設定プログラム１０１における監視実行処理を説明するためのフローチャートである。図１１に示した稼動監視設定プログラム１０１は、図３に示したものと同様にＡＰに包含された監視ノードを実行して、ＡＰのノードの状態を判断する処理と、ＡＰの実行待ちを判断する処理とを行うプログラムである。

図１１に示した稼動監視設定プログラム１０１においては、図３に示したものと同様のＡＰＩを呼び出す処理だけでなく、フローに追加した監視ノードを実行する（ステップ１１０１）。そして、各サービスの稼動状態をノード管理テーブル３１０の状態フィールドに登録する。

図１３は、図１２に示したノード管理テーブル３１０の構成例を示す図である。

図１２に示したノード管理テーブル３１０は、図１３に示すように、ＡＰ１０２を識別するＡＰＩＤフィールド１３０１と、ノード１０３を識別するノードＩＤフィールド１３０２と、ノード１０３が呼び出しているＡＰＩを示すＡＰＩフィールド１３０３の他に、ＡＰＩの状態を示す状態フィールド１３０４を有している。

監視実行部１２０１は、監視ノード１０６によって監視用ＡＰＩを実行した結果を受信し（ステップ１１０２）、各ノードの状態を判断する（ステップ１１０１）。ここで、監視実行部１２０１の判断方法としては、ノードが呼び出している全サービスが正常稼動状態であればノード状態を正常とし、１つ以上のサービスが正常でなければノード状態を異常とする。これにより、各サービスが提供するＡＰＩの稼働状態を自動的に監視することができ、ＡＰに含まれる機能オブジェクト毎にその稼働状態が正常か異常かを知ることができる。

次に、監視実行部１２０１は、ＡＰ１０２のフローに含まれる全てのノードが正常状態かを判断する（ステップ１１０４）。そして、全てのノードが正常であれば、本ＡＰを実行可能と判断し（ステップ１１０５）、ＡＰに含まれる１つ以上のノードが異常状態であればそのＡＰを実行待ちとする（ステップ１１０６）。これにより、各ノードの状態からＡＰが正常に実行可能か否かを知ることができる。

そして、上述した監視実行プログラムの結果をＡＰデプロイ制御処理に通知して、実行待ち判断の場合は、デプロイを実施しないようにするか、デプロイ済みのＡＰに対しては、ユーザからのＡＰへのリクエストを送信しないように制御する。

その後、定期的に監視実行プログラムを実行し、全てのノードが正常状態と判断された場合に、ＡＰデプロイ制御部に通知して、ＡＰのデプロイを行い、ＡＰが実行可能になるように制御する。

なお、本形態にて判断された状態を、図１０に示した上段のノードの出力において、各ノードについて色付けや網掛けなどで可視化することが考えられる。

以上により、ＡＰが使用するサービスについて、適切なＡＰＩを用いて稼動状態を確認し、正常でないサービスがある場合にはＡＰの実行を制御することで、ＡＰの無駄なリトライ処理を防ぐことが可能となる。

以上、本発明の実施形態について説明したが、本発明の実施形態は例示したものに限るものではなく、発明の主旨を逸脱しない範囲で種々の変更が可能である。

１０１…稼働監視設定プログラム、１０２…アプリケーションプログラム、１０３…ノード、１０４…サービス、１０５…ＡＰＩゲートウェイ、１０６…監視ノード、１０７…クラウドプラットフォーム、２０１…中央処理装置、２０２…メモリ、２０３…二次記憶装置、２０４…入出力インタフェース、２０５…ネットワークインタフェース、２０６…テーブル、３０１…コード取得部、３０２…ＡＰＩ抽出部、３０３…ＡＰＩ登録確認部、３０４…ＡＰＩゲートウェイ通信部、３０５…グループ特定処理部、３０６…ＡＰＩ属性確認部、３０７…ＡＰＩ選択部、３０８…監視ノード作成部、３０９…ノード登録部、３１０…ノード管理テーブル、３１１…ＡＰＩグループ管理テーブル、３１２…ＡＰ開発環境、１２０１…監視実行部

Claims (8)

1. サービスから提供されたアプリケーションプログラミングインタフェースを呼び出して稼働するアプリケーションプログラムの稼働状況を監視するアプリケーション稼働監視装置であって、
   監視対象となるアプリケーションプログラムのソースコードに含まれているアプリケーションプログラミングインタフェースを抽出する抽出部と、
   公開されたアプリケーションプログラミングインタフェースが前記サービス単位のグループ毎に登録されたグループ情報に基づいて、前記抽出されたアプリケーションプログラミングインタフェースが属するグループを特定するグループ特定処理部と、
   前記特定されたグループに属するアプリケーションプログラミングインタフェースの中から、リクエストの実行に情報の変更を伴わないアプリケーションプログラミングインタフェースを監視用アプリケーションプログラミングインタフェースとして選択する選択部と、
   前記監視用アプリケーションプログラミングインタフェースに対して擬似的なリクエストを送信して該リクエストに対する応答を受信することで、当該監視用アプリケーションプログラミングインタフェースが正常に稼働しているか否か判断する監視ノードを作成する監視ノード作成部と、
   前記監視ノードを前記アプリケーションプログラムに包含させるノード登録部と、
   を有するアプリケーション稼働監視装置。
2. 公開されたアプリケーションプログラミングインタフェースを管理する管理装置から前記グループ情報を取得し、前記抽出されたアプリケーションプログラミングインタフェースが前記グループ情報に登録されていることを確認する登録確認部を更に有し、
   前記グループ特定処理部は、前記抽出されたアプリケーションプログラミングインタフェースが前記登録確認部にて前記グループ情報に登録されていることが確認された場合に、該抽出されたアプリケーションプログラミングインタフェースについて処理を行う、
   請求項１に記載のアプリケーション稼働監視装置。
3. 前記選択部は、
   前記特定されたグループに属するアプリケーションプログラミングインタフェースについて、リクエストの実行に情報の変更を伴うか否かを示す属性情報が前記グループ情報から得られた場合は、前記特定されたグループに属するアプリケーションプログラミングインタフェースの中から、前記属性情報に基づいて前記監視用アプリケーションプログラミングインタフェースを選択し、
   前記特定されたグループに属するアプリケーションプログラミングインタフェースについて、リクエストの実行に情報の変更を伴うか否かを示す属性情報が前記グループ情報から得られない場合は、前記特定されたグループに属するアプリケーションプログラミングインタフェースの中から、種別が情報取得でありかつアドレス以外にパラメータを含まないアプリケーションプログラミングインタフェース、または、種別が情報取得でありかつ画像読み込み用のアプリケーションプログラミングインタフェースを、前記監視用アプリケーションプログラミングインタフェースとして選択する、
   請求項１に記載のアプリケーション稼働監視装置。
4. 前記選択部は、
   前記抽出されたアプリケーションプログラミングインタフェースが、リクエストの実行に情報の変更を伴わない場合は、該抽出されたアプリケーションプログラミングインタフェースを前記監視用アプリケーションプログラミングインタフェースとし、
   前記抽出されたアプリケーションプログラミングインタフェースが、リクエストの実行に情報の変更を伴う場合は、前記特定されたグループに属するアプリケーションプログラミングインタフェースの中から、リクエストの実行に情報の変更を伴わないアプリケーションプログラミングインタフェースを監視用アプリケーションプログラミングインタフェースとして選択する、
   請求項１に記載のアプリケーション稼働監視装置。
5. 前記選択部は、リクエストの実行に情報の変更を伴わないアプリケーションプログラミングインタフェースが複数存在する場合、監視対象となるアプリケーションプログラムに含まれる機能オブジェクトであるノードのうち上流側のノードが呼び出すアプリケーションプログラミングインタフェースを、監視用アプリケーションプログラミングインタフェースとして選択する、
   請求項１に記載のアプリケーション稼働監視装置。
6. 前記監視ノードが実行されると、前記アプリケーションプログラムに含まれる機能オブジェクトであるノードのそれぞれについて、当該ノードが呼び出す全てのアプリケーションプログラミングインタフェースに対応する監視用アプリケーションプログラミングインタフェースが正常に稼働していれば当該ノードが正常状態であると判断し、当該ノードが呼び出す１つ以上のアプリケーションプログラミングインタフェースに対応する監視用アプリケーションプログラミングインタフェースが正常に稼働していなければ当該ノードが異常状態であると判断する、監視実行部を更に有する、
   請求項１に記載のアプリケーション稼働監視装置。
7. 前記監視実行部は、前記アプリケーションプログラムに含まれる全てのノードが正常状態であれば当該アプリケーションプログラムを実行可能とし、前記アプリケーションプログラムに含まれる１つ以上のノードが異常状態であれば当該アプリケーションプログラムを実行待ちとする、請求項５に記載のアプリケーション稼働監視装置。
8. サービスから提供されたアプリケーションプログラミングインタフェースを呼び出して稼働するアプリケーションプログラムの稼働状況を監視するアプリケーション稼働監視方法であって、
   抽出手段が、監視対象となるアプリケーションプログラムのソースコードに含まれているアプリケーションプログラミングインタフェースを抽出し、
   グループ特定処理手段が、公開されたアプリケーションプログラミングインタフェースが前記サービス単位のグループ毎に登録されたグループ情報に基づいて、前記抽出されたアプリケーションプログラミングインタフェースが属するグループを特定し、
   選択手段が、前記特定されたグループに属するアプリケーションプログラミングインタフェースの中から、リクエストの実行に情報の変更を伴わないアプリケーションプログラミングインタフェースを監視用アプリケーションプログラミングインタフェースとして選択し、
   監視ノード作成手段が、前記監視用アプリケーションプログラミングインタフェースに対して擬似的なリクエストを送信して該リクエストに対する応答を受信することで、当該監視用アプリケーションプログラミングインタフェースが正常に稼働しているか否か判断する監視ノードを作成し、
   ノード登録手段が、前記監視ノードを前記アプリケーションプログラムに包含させる、
   アプリケーション稼働監視方法。

Images