特開 2024-131497 ＡＰＩ提供システムおよびＡＰＩ提供方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024131497

(43)【公開日】2024-09-30

(54)【発明の名称】ＡＰＩ提供システムおよびＡＰＩ提供方法

(51)【国際特許分類】

   G06F 9/445 20180101AFI20240920BHJP

   G06F 16/908 20190101ALI20240920BHJP

【ＦＩ】

G06F9/445 130

G06F16/908

【審査請求】未請求

【請求項の数】13

【出願形態】ＯＬ

(21)【出願番号】P 2023041789

(22)【出願日】2023-03-16

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】000233295

【氏名又は名称】株式会社日立情報通信エンジニアリング

(74)【代理人】

【識別番号】110000198

【氏名又は名称】弁理士法人湘洋特許事務所

(72)【発明者】

【氏名】森 久斗

【テーマコード（参考）】

5B175

5B376

【Ｆターム（参考）】

5B175FA01

5B376AC01

5B376AC21

(57)【要約】

【課題】 ＡＰＩが設けられていないＷｅｂアプリケーションについて、簡便にエラー制御が可能なＡＰＩを提供する。
【解決手段】
ＡＰＩ提供システムであって、プロセッサと、記憶装置と、を備える情報処理装置を含み、ＡＰＩ化対象のＷｅｂアプリケーションのエントリポイントの指定と、当該Ｗｅｂアプリケーションの運用手順書の指定と、を受け付けて該エントリポイントへの操作要求を受け付けるためのＡＰＩを生成するＡＰＩ生成部と、前記ＡＰＩ生成部により生成されたＡＰＩへのアクセスを受け付けると、前記Ｗｅｂアプリケーションに対する操作へ変換を行って前記Ｗｅｂアプリケーションを実行させるＡＰＩ実行部と、前記ＡＰＩ実行部による前記Ｗｅｂアプリケーションの実行結果に応じて結果情報をアクセス元へ出力するＡＰＩ結果報告部と、を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

プロセッサと、記憶装置と、を備える情報処理装置を含み、
ＡＰＩ化対象のＷｅｂアプリケーションのエントリポイントの指定と、当該Ｗｅｂアプリケーションの運用手順書の指定と、を受け付けて該エントリポイントへの操作要求を受け付けるためのＡＰＩを生成するＡＰＩ生成部と、
前記ＡＰＩ生成部により生成されたＡＰＩへのアクセスを受け付けると、前記Ｗｅｂアプリケーションに対する操作へ変換を行って前記Ｗｅｂアプリケーションを実行させるＡＰＩ実行部と、
前記ＡＰＩ実行部による前記Ｗｅｂアプリケーションの実行結果に応じて結果情報をアクセス元へ出力するＡＰＩ結果報告部と、
を備えるＡＰＩ提供システム。

【請求項2】

請求項１に記載のＡＰＩ提供システムであって、
前記ＡＰＩ実行部または前記ＡＰＩ結果報告部において得られるＧＵＩを記録するエビデンス記録部、
を備えることを特徴とするＡＰＩ提供システム。

【請求項3】

請求項２に記載のＡＰＩ提供システムであって、
前記ＡＰＩ生成部は、ＡＰＩのパラメータと、アクションと、結果表示と、を含む確認画面を提示してＡＰＩ生成の指示を受け付ける、
ことを特徴とするＡＰＩ提供システム。

【請求項4】

請求項３に記載のＡＰＩ提供システムであって、
前記ＡＰＩ生成部は、前記確認画面において、前記ＡＰＩのパラメータおよび前記アクションのそれぞれのＸｐａｔｈを前記エントリポイントへのアクセスにより取得されるＧＵＩから取得する、
ことを特徴とするＡＰＩ提供システム。

【請求項5】

請求項４に記載のＡＰＩ提供システムであって、
前記ＡＰＩ生成部は、前記確認画面において、前記運用手順書において必要と示されているパラメータを明示する、
ことを特徴とするＡＰＩ提供システム。

【請求項6】

請求項５に記載のＡＰＩ提供システムであって、
前記運用手順書は、表計算形式のファイルである、
ことを特徴とするＡＰＩ提供システム。

【請求項7】

請求項６に記載のＡＰＩ提供システムであって、
前記ＡＰＩ実行部は、前記Ｗｅｂアプリケーションに対する操作をＲＰＡ（Ｒｏｂｏｔｉｃ Ｐｒｏｃｅｓｓ Ａｕｔｏｍａｔｉｏｎ）を用いて行う、
ことを特徴とするＡＰＩ提供システム。

【請求項8】

請求項７に記載のＡＰＩ提供システムであって、
前記ＡＰＩ結果報告部は、前記Ｗｅｂアプリケーションの実行結果画面に含まれる文字列を用いて結果を判定する、
ことを特徴とするＡＰＩ提供システム。

【請求項9】

請求項８に記載のＡＰＩ提供システムであって、
前記エビデンス記録部は、スクリーンショットにより前記ＧＵＩを記録する、
ことを特徴とするＡＰＩ提供システム。

【請求項10】

請求項９に記載のＡＰＩ提供システムであって、
前記ＷｅｂアプリケーションのＧＵＩの更新有無を判定するＧＵＩ更新チェック部、
を備えることを特徴とするＡＰＩ提供システム。

【請求項11】

請求項１０に記載のＡＰＩ提供システムであって、
前記ＧＵＩ更新チェック部は、前記ＧＵＩの更新により追加されたパラメータについて通知を行う、
ことを特徴とするＡＰＩ提供システム。

【請求項12】

請求項１１に記載のＡＰＩ提供システムであって、
前記ＧＵＩ更新チェック部は、前記追加されたパラメータに対応するＡＰＩの生成を前記ＡＰＩ生成部に行わせる、
ことを特徴とするＡＰＩ提供システム。

【請求項13】

プロセッサと、記憶装置と、を備える情報処理装置が、
ＡＰＩ化対象のＷｅｂアプリケーションのエントリポイントの指定と、当該Ｗｅｂアプリケーションの運用手順書の指定と、を受け付けて該エントリポイントへの操作要求を受け付けるためのＡＰＩを生成するＡＰＩ生成ステップと、
前記ＡＰＩ生成ステップにより生成されたＡＰＩへのアクセスを受け付けると、前記Ｗｅｂアプリケーションに対する操作へ変換を行って前記Ｗｅｂアプリケーションを実行させるＡＰＩ実行ステップと、
前記ＡＰＩ実行ステップによる前記Ｗｅｂアプリケーションの実行結果に応じて結果情報をアクセス元へ出力するＡＰＩ結果報告ステップと、
を実施するＡＰＩ提供方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ＡＰＩ提供システムおよびＡＰＩ提供方法に関する。

【背景技術】

【0002】

特許文献１には、プロセッサと記憶装置とを有する情報処理装置を用いて構成され、ＡＰＩ化しようとするＷｅｂアプリケーションに対してＷｅｂブラウザを介して行われる一連の操作をアクセス手順として取得するアクセス手順取得部と、取得した前記アクセス手順の内容をユーザーに提示しつつ、前記ＡＰＩ化において必要となるＡＰＩ仕様の設定をユーザーから受け付けることによりＡＰＩ仕様を生成するＡＰＩ仕様設定部と、を備えるＡＰＩ化支援システムの開示がある。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２２－０３５１２６号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記特許文献１に記載された技術は、人手によるＧＵＩ操作（アクセス手順）およびパラメータ情報の入力を元にＷｅｂアプリケーションのＡＰＩを生成している。しかし、生成されるＡＰＩでは、Ｗｅｂアプリケーションの実行エラーが発生した場合を想定していないため、Ｗｅｂアプリケーションの呼び出し側にてエラー制御を適切に行うことは難しい場合がある。

【0005】

本発明の目的は、ＡＰＩが設けられていないＷｅｂアプリケーションについて、簡便にエラー制御が可能なＡＰＩを提供する技術を提供することにある。

【課題を解決するための手段】

【0006】

本願は、上記課題の少なくとも一部を解決する手段を複数含んでいるが、その例を挙げるならば、以下のとおりである。上記課題を解決すべく、本発明の一態様に係るＡＰＩ提供システムは、プロセッサと、記憶装置と、を備える情報処理装置を含み、ＡＰＩ化対象のＷｅｂアプリケーションのエントリポイントの指定と、当該Ｗｅｂアプリケーションの運用手順書の指定と、を受け付けて該エントリポイントへの操作要求を受け付けるためのＡＰＩを生成するＡＰＩ生成部と、前記ＡＰＩ生成部により生成されたＡＰＩへのアクセスを受け付けると、前記Ｗｅｂアプリケーションに対する操作へ変換を行って前記Ｗｅｂアプリケーションを実行させるＡＰＩ実行部と、前記ＡＰＩ実行部による前記Ｗｅｂアプリケーションの実行結果に応じて結果情報をアクセス元へ出力するＡＰＩ結果報告部と、を備える。

【0007】

また、上記のＡＰＩ提供システムにおいて、前記ＡＰＩ実行部または前記ＡＰＩ結果報告部において得られるＧＵＩを記録するエビデンス記録部、を備えるものであってもよい。

【0008】

また、上記のＡＰＩ提供システムにおいて、前記ＡＰＩ生成部は、ＡＰＩのパラメータと、アクションと、結果表示と、を含む確認画面を提示してＡＰＩ生成の指示を受け付けるようにしてもよい。

【0009】

また、上記のＡＰＩ提供システムにおいて、前記ＡＰＩ生成部は、前記確認画面において、前記ＡＰＩのパラメータおよび前記アクションのそれぞれのＸｐａｔｈを前記エントリポイントへのアクセスにより取得されるＧＵＩから取得するようにしてもよい。

【0010】

また、上記のＡＰＩ提供システムにおいて、前記ＡＰＩ生成部は、前記確認画面において、前記運用手順書において必要と示されているパラメータを明示するようにしてもよい。

【0011】

また、上記のＡＰＩ提供システムにおいて、前記運用手順書は、表計算形式のファイルであってもよい。

【0012】

また、上記のＡＰＩ提供システムにおいて、前記ＡＰＩ実行部は、前記Ｗｅｂアプリケーションに対する操作をＲＰＡ（Ｒｏｂｏｔｉｃ Ｐｒｏｃｅｓｓ Ａｕｔｏｍａｔｉｏｎ）を用いて行うものであってもよい。

【0013】

また、上記のＡＰＩ提供システムにおいて、前記ＡＰＩ結果報告部は、前記Ｗｅｂアプリケーションの実行結果画面に含まれる文字列を用いて結果を判定するものであってもよい。

【0014】

また、上記のＡＰＩ提供システムにおいて、前記エビデンス記録部は、スクリーンショットにより前記ＧＵＩを記録するものであってもよい。

【0015】

また、上記のＡＰＩ提供システムにおいて、前記ＷｅｂアプリケーションのＧＵＩの更新有無を判定するＧＵＩ更新チェック部、を備えるものであってもよい。

【0016】

また、上記のＡＰＩ提供システムにおいて、前記ＧＵＩ更新チェック部は、前記ＧＵＩの更新により追加されたパラメータについて通知を行うものであってもよい。

【0017】

また、上記のＡＰＩ提供システムにおいて、前記ＧＵＩ更新チェック部は、前記追加されたパラメータに対応するＡＰＩの生成を前記ＡＰＩ生成部に行わせるものであってもよい。

【0018】

また、本発明の別の態様に係るＡＰＩ提供方法は、プロセッサと、記憶装置と、を備える情報処理装置が、ＡＰＩ化対象のＷｅｂアプリケーションのエントリポイントの指定と、当該Ｗｅｂアプリケーションの運用手順書の指定と、を受け付けて該エントリポイントへの操作要求を受け付けるためのＡＰＩを生成するＡＰＩ生成ステップと、前記ＡＰＩ生成ステップにより生成されたＡＰＩへのアクセスを受け付けると、前記Ｗｅｂアプリケーションに対する操作へ変換を行って前記Ｗｅｂアプリケーションを実行させるＡＰＩ実行ステップと、前記ＡＰＩ実行ステップによる前記Ｗｅｂアプリケーションの実行結果に応じて結果情報をアクセス元へ出力するＡＰＩ結果報告ステップと、を実施する。

【発明の効果】

【0019】

本発明によれば、ＡＰＩが設けられていないＷｅｂアプリケーションについて、簡便にエラー制御が可能なＡＰＩを提供することができる。上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

【図面の簡単な説明】

【0020】

【図1】ＡＰＩ提供システムの利用例を示す図である。

【図2】ＡＰＩ提供システムの構成例を示す図である。

【図3】ＡＰＩパラメータ情報のデータ構造の例を示す図である。

【図4】ＡＰＩアクション情報のデータ構造の例を示す図である。

【図5】ＡＰＩ実行結果情報のデータ構造の例を示す図である。

【図6】ＡＰＩ提供装置のハードウェア構成例を示す図である。

【図7】ＡＰＩ生成処理のフロー例を示す図である。

【図8】ＡＰＩ呼出処理のフロー例を示す図である。

【図9】ＡＰＩ生成処理の出力画面例を示す図である。

【図10】運用手順書の書式の例を示す図である。

【図11】ＷｅｂアプリケーションのＧＵＩの例を示す図である。

【図12】ＡＰＩ更新処理の出力画面例を示す図である。

【発明を実施するための形態】

【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】

１・・・ＡＰＩ提供システム、１００・・・ＡＰＩ提供装置、１１０・・・記憶部、１１１・・・ＡＰＩパラメータ情報、１１２・・・ＡＰＩアクション情報、１１３・・・ＡＰＩ実行結果情報、１２０・・・処理部、１２１・・・ＷｅｂＡＰＩ、１２２・・・ＡＰＩ実行部、１２３・・・ＷｅｂＧＵＩ操作部、１２４・・・ＡＰＩ結果報告部、１２５・・・エビデンス記録部、２００・・・ＡＰＩ生成装置、２１０・・・記憶部、２１１・・・ＡＰＩパラメータ情報、２１２・・・ＡＰＩアクション情報、２１３・・・ＡＰＩ実行結果情報、２２０・・・処理部、２２１・・・ＷｅｂＧＵＩ解析部、２２２・・・運用手順書解析部、２２３・・・ＡＰＩ生成部、２２４・・・ＧＵＩ更新チェック部、３００・・・サードパーティ製品／サービス、３０１・・・Ｗｅｂアプリ、３０２・・・機能提供部、４００・・・ＡＰＩ利用装置、４０１・・・ＷｅｂＡＰＩ利用アプリ。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】