(57)【要約】【課題】  Webシステムを連携させる際、連携元、連携先のインターフェイスが完全に一致していないと連携が困難であった。不足している連携用パラメータを検知し、不足パラメータの補完を受け付ける機能、パラメータの個人毎のカスタマイズ機能などを具備する連携支援機能を新たに設け、パラメータが完全に一致していないWebシステムの連携を可能とする。【解決手段】  Webシステム連携システムについて、不足している連携用パラメータを検知しユーザからの入力を受け付ける機能や、パラメータの個人毎のカスタマイズ機能を具備する連携支援機能を新たに設けることで、パラメータが不足しているなど、完全に一致していないWebシステムとの連携の実現や、より、ユーザのコンテクストに適合した連携を実現する。【選択図】  図１
2008293152.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続される、Webブラウザが動作するクライアント端末と、連携元となる一つ以上のWebシステムと、連携先となる一つ以上のWebシステムと、連携先を管理するWebAPIリポジトリから構成され、
連携元となるWebシステムのコンテンツには、連携用メタ情報として、一つ以上のデータ型とデータ値、および、Webシステム連携のためのWebシステム連携用GUI(Graphical User Interface)が埋め込まれており、
前記WebAPIリポジトリは、連携先Webシステムの名称、および、連携先Webシステムを呼び出すために必要なパラメータである一つ以上のデータ型を管理しているWebシステムの連携方法であって
前記Webシステム連携用GUIが、前記Webブラウザ上でのWebシステム連携のためのユーザ操作イベントにより起動し、イベント発火元に埋め込まれている連携用メタ情報から、一つ以上のデータ型を抽出し、前記WebAPIリポジトリに対して、抽出したデータ型を含む連携先Webシステム検索の要求を行う第１のステップと、
WebAPIリポジトリが、前記連携先Webシステムの検索の要求を受け付け、該要求に含まれる一つ以上のデータ型を抽出し、前記WebAPIリポジトリで管理されている連携先Webシステムを呼び出すために必要なパラメータである一つ以上のデータ型と部分一致による検索を行い、その検索結果を要求元に応答する第２のステップと、
要求元のWebシステム連携用GUIが、前記WebAPIリポジトリによる検索結果を一覧表示し、ユーザから連携先Webシステムの選択を受け付ける第３のステップと、
前記Webシステム連携用GUIが、受け付けた連携先Webシステムを呼び出すためのパラメータが、該コンテンツに埋め込まれているパラメータでは足りない場合に、パラメータ入力受け付け画面を生成し、ユーザからデータ値の入力を受け付ける第４のステップと、
前記Webシステム連携用GUIが、埋め込まれていたデータ値、および、入力を受け付けたデータ値があればそのデータ値を含む要求を連携先Webシステムに送信する第５のステップ、を備えることを特徴とするWebシステムの連携方法。
【請求項２】
請求項１記載のWebシステムの連携方法において、前記WebAPIリポジトリは、ユーザを識別するユーザ識別機能、ユーザのカスタマイズ情報を保持可能なカスタマイズ機能を更に具備し、
Webシステムの連携に先立って、ユーザを識別するステップを更に有し、
前記第４のステップで受け付けたユーザの入力をカスタマイズ情報に保存し、次回以降のWebシステム連携操作時に、該保存情報を入力値の候補として予め入力エリアに埋め込んでおくことを特徴とするWebシステムの連携方法。
【請求項３】
請求項２記載のWebシステムの連携方法において、
前記WebAPIリポジトリは、一般ユーザとして識別を受けたブラウザからのカスタマイズ情報編集の要求を受け付け、カスタマイズ情報編集の画面を生成・応答し、次いで、該ユーザのカスタマイズ情報編集結果を受け付け、該ユーザのカスタマイズ情報に編集結果を反映することを特徴とするWebシステムの連携技術。
【請求項４】
請求項２記載のWebシステムの連携方法において、
前記WebAPIリポジトリは、管理者ユーザとして識別を受けたブラウザからのカスタマイズ情報編集の要求を受け付け、カスタマイズ情報編集の画面を生成・応答し、次いで、カスタマイズ情報編集結果を受け付け、一人以上の一般ユーザのカスタマイズ情報に編集結果を反映することを特徴とするWebシステムの連携技術。
【請求項５】
請求項１記載のWebシステムの連携方法において、
前記Webシステム連携のためのユーザ操作イベントの延長で、連携可能なWebシステムを検索する前記第１のステップが実行されるのではなく、それに代えて連携元WebシステムでのWebシステム連携用GUIを埋め込む時点で、予め検索結果を含むWebシステム連携用GUIを埋め込んでおくことを特徴とするWebシステムの連携方法。
【請求項６】
請求項１記載のWebシステムの連携方法において、
連携元WebシステムとWebシステム連携用GUI起動イベント種別を管理するイベント管理機能を更に具備し、
連携元Webシステム毎に、Webシステム連携用GUI起動イベント種別を定義可能とすることを特徴とするWebシステムの連携方法。
【請求項７】
請求項１記載のWebシステムの連携方法において、
WebAPIサービスの選択を受け付ける前記第３のステップは、複数のWebAPIサービスの選択を受け付け、選択を受け付けた複数のWebAPIサービスについてそれぞれ前記第４のステップ以降を実施することを特徴とするWebシステムの連携方法。
【請求項８】
ネットワークを介して接続される、Webブラウザが動作するクライアント端末と、連携元となる一つ以上のWebシステムと、連携先となる一つ以上のWebシステムと、連携用情報を埋め込むメタ情報埋め込みサーバと、連携先となる該WebシステムをWebAPIサービスとして管理・実行するWebAPI実行部から構成され、
連携元となるWebシステムの応答結果には、連携用メタ情報として、一つ以上のデータ型とデータ値が埋め込まれており、
前記WebAPI実行部は、管理するWebAPIサービスについて、WebAPIサービスの名称、WebAPIサービスを呼び出すために必要なパラメータである一つ以上のデータ型、WebAPIサービスの実行方法を管理するWebAPIリポジトリを具備し、
前記メタ情報埋め込みサーバは、前記Webブラウザと連携元Webシステムの通信を仲介するよう構成されるWebシステムの連携方法であって、
前記メタ情報埋め込みサーバが、前記Webブラウザの通信要求に従って、前記連携元Webシステムに通信要求を出し、前記連携元Webシステムの応答結果に対して、Webシステム連携を支援するWebシステム連携用GUI(Graphical User Interface)を埋め込む第１のステップと、
前記Webシステム連携用GUIが、該Webブラウザ上でのWebシステム連携のためのユーザ操作イベントにより起動し、イベント発火元に埋め込まれている連携用メタ情報から、一つ以上のデータ型を抽出し、前記WebAPIリポジトリ実行部に対して、抽出した該データ型を含むWebAPIサービス検索の要求を行う第２のステップと、
前記WebAPI実行部が、前記Webシステム連携用GUIからの該要求を受け付け、該要求に含まれる一つ以上のデータ型を抽出し、前記WebAPIリポジトリで管理されているWebAPIサービスを呼び出すために必要なパラメータである一つ以上のデータ型と部分一致による検索を行い、検索結果をWebシステム連携用GUIに応答する第３のステップと、
前記Webシステム連携用GUIが、前記WebAPI実行部の検索結果を、Webブラウザ内で一覧表示し、ユーザから連携先とするWebAPIサービスの選択を受け付ける第４のステップと、
前記Webシステム連携用GUIが、受け付けたWebAPIサービスを呼び出すためのパラメータが、該コンテンツに埋め込まれているパラメータでは足りない場合に、パラメータ入力受け付け画面を生成し、ユーザからデータ値の入力を受け付ける第５のステップと、
前記Webシステム連携用GUIが、埋め込まれていたデータ値、WebAPIサービスの識別子、および、入力を受け付けたデータ値があればそのデータ値、を含むWebAPIサービス実行の要求を前記WebAPI実行部に送る第６のステップと、
前記WebAPI実行部が、Webシステム連携用GUIから受け付けたWebAPIサービス実行の要求を元に、前記WebAPIリポジトリに格納されているWebAPIサービスの実行方法に基づき連携先Webシステムを実行し、実行結果画面を最終的に該Webブラウザに表示させる第７のステップを備えることを特徴とするWebシステムの連携方法。
【請求項９】
請求項８記載のWebシステムの連携方法において、
前記WebAPI実行部は、ユーザを識別するユーザ識別機能、及びユーザのカスタマイズ情報を保持可能なカスタマイズ機能を更に具備し、
Webシステムの連携に先立って、ユーザを識別するステップを更に有し、
前記第５のステップで受け付けたユーザの入力をカスタマイズ情報に保存し、次回以降のWebシステム連携操作時に、該保存情報を入力値の候補として予め入力エリアに埋め込んでおくことを特徴とするWebシステムの連携方法。
【請求項１０】
請求項９記載のWebシステムの連携方法において、
前記WebAPI実行部は、一般ユーザとして識別を受けたブラウザからのカスタマイズ情報編集の要求を受け付け、カスタマイズ情報編集の画面を生成・応答し、次いで、該ユーザのカスタマイズ情報編集結果を受け付け、該ユーザのカスタマイズ情報に編集結果を反映することを特徴とするWebシステムの連携方法。
【請求項１１】
請求項９記載のWebシステムの連携方法において、
前記WebAPI実行部は、管理者ユーザとして識別を受けたブラウザからのカスタマイズ情報編集の要求を受け付け、カスタマイズ情報編集の画面を生成・応答し、次いで、カスタマイズ情報編集結果を受け付け、一人以上の一般ユーザのカスタマイズ情報に編集結果を反映することを特徴とするWebシステム連携方法。
【請求項１２】
請求項８記載のWebシステムの連携方法において、
前記Webシステム連携のためのユーザ操作イベントの延長で、連携可能なWebAPIサービスを検索する前記第３のステップが実行されるのではなく、それに代えてWebシステム連携用GUIを埋め込む第１のステップで、予め検索結果を含むWebシステム連携用GUIを埋め込んでおくことを特徴とするWebシステムの連携方法。
【請求項１３】
請求項８記載のWebシステムの連携方法において、
前記メタ情報埋め込みサーバは、連携元WebシステムとWebシステム連携用GUI起動イベント種別を管理するイベント管理部を更に具備し、
連携元Webシステム毎に、Webシステム連携用GUI起動イベント種別を定義可能とすることを特徴とするWebシステムの連携方法。
【請求項１４】
請求項８記載のWebシステムの連携方法において、
前記WebAPIサービスの選択を受け付ける第４のステップは、複数のWebAPIサービスの選択を受け付け、選択を受け付けた複数のWebAPIサービスについてぞれぞれ第５のステップ以降を実施することを特徴とするWebシステムの連携方法。
【請求項１５】
ネットワークを介して接続される、Webブラウザが動作するクライアント端末と、連携元となる一つ以上のWebシステムと、連携先となる一つ以上のWebシステムと、ポータルサーバから構成され、
前記ポータルサーバは、ポートレットとして統合した該連携元となるWebシステムに連携用情報を埋め込む連携用メタ情報埋め込みフィルタと、
連携先Webシステムを管理するWebAPIリポジトリ管理を具備することを特徴とする請求項１から請求項１４のいずれかに記載の方法を実現するWebシステム連携装置
【請求項１６】
ネットワークを介して接続される、Webブラウザが動作するクライアント端末と、連携元となる一つ以上のWebシステムと、連携先となる一つ以上のWebシステムと、連携先を管理するWebAPIリポジトリから構成され、
連携元となるWebシステムのコンテンツには、連携用メタ情報として、一つ以上のデータ型とデータ値、および、Webシステム連携のためのWebシステム連携用GUI(Graphical User Interface)が埋め込まれており、
前記WebAPIリポジトリは、連携先Webシステムの名称、および、連携先Webシステムを呼び出すために必要なパラメータである一つ以上のデータ型を管理しており、
前記Webシステム連携用GUIが、前記Webブラウザ上でのWebシステム連携のためのユーザ操作イベントにより起動し、イベント発火元に埋め込まれている連携用メタ情報から、一つ以上のデータ型を抽出し、前記WebAPIリポジトリに対して、抽出したデータ型を含む連携先Webシステム検索の要求を行う機能と、前記WebAPIリポジトリによる検索結果を一覧表示し、ユーザから連携先Webシステムの選択を受け付け、受け付けた連携先Webシステムを呼び出すためのパラメータが、該コンテンツに埋め込まれているパラメータでは足りない場合に、パラメータ入力受け付け画面を生成し、ユーザからデータ値の入力を受け付け、埋め込まれていたデータ値、WebAPIサービスの識別子、および、入力を受け付けたデータ値があればそのデータ値を前記WebAPI実行部に送る機能を備えることを特徴とするWebシステム連携装置。
【請求項１７】
ネットワークを介して接続される、Webブラウザが動作するクライアント端末と、連携元となる一つ以上のWebシステムと、連携先となる一つ以上のWebシステムと、連携用情報を埋め込むメタ情報埋め込みサーバと、連携先となる該WebシステムをWebAPIサービスとして管理・実行するWebAPI実行部から構成され、
連携元となるWebシステムの応答結果には、連携用メタ情報として、一つ以上のデータ型とデータ値が埋め込まれており、
前記WebAPI実行部は、管理するWebAPIサービスについて、WebAPIサービスの名称、WebAPIサービスを呼び出すために必要なパラメータである一つ以上のデータ型、WebAPIサービスの実行方法を管理するWebAPIリポジトリを具備し、
前記メタ情報埋め込みサーバは、前記Webブラウザと連携元Webシステムの通信を仲介するよう構成されるWebシステム連携装置であって、
前記メタ情報埋め込みサーバが、前記Webブラウザの通信要求に従って、前記連携元Webシステムに通信要求を出し、前記連携元Webシステムの応答結果に対して、Webシステム連携を支援するWebシステム連携用GUI(Graphical User Interface)を埋め込む機能を有し、
前記Webシステム連携用GUIが、該Webブラウザ上でのWebシステム連携のためのユーザ操作イベントにより起動し、イベント発火元に埋め込まれている連携用メタ情報から、一つ以上のデータ型を抽出し、前記WebAPIリポジトリ実行部に対して、抽出した該データ型を含むWebAPIサービス検索の要求を行う機能と、前記WebAPI実行部の検索結果を、Webブラウザ内で一覧表示し、ユーザから連携先とするWebAPIサービスの選択を受け付け、受け付けたWebAPIサービスを呼び出すためのパラメータが、該コンテンツに埋め込まれているパラメータでは足りない場合に、パラメータ入力受け付け画面を生成し、ユーザからデータ値の入力を受け付け、埋め込まれていたデータ値、WebAPIサービスの識別子、および、入力を受け付けたデータ値があればそのデータ値、を含むWebAPIサービス実行の要求を前記WebAPI実行部に送る機能を備えることを特徴とするWebシステム連携装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Webシステムのユーザーインターフェイスレベルでの連携を実現するための方法および装置に関する。
【背景技術】
【０００２】
複数システムにまたがる業務を行う場合、各システムに同じデータを入力する必要があるなど、使い勝手が悪いという問題がある。そこで、様々な形でのシステムの連携が行われている。
【０００３】
Webシステムの連携を実現したい場合、SOAP技術やCORBA技術を用いたバックエンドでのシステム連携が良く利用されている。ここでは、このようなAPIを用いた連携をAPI型連携と呼ぶこととする。API型連携では、ITシステムにおいて、APIの実装、公開が必要であったり、連携のためのプログラミングが必要であったりするが、かなり高度な連携が実現できる。
【０００４】
API型連携とは別に、Webシステムが提供するGUI（HTTP/HTML）を活用した連携も行われつつある。これをGUI型連携と呼ぶ。
【０００５】
例えば、「特許文献１」、「特許文献２」、「特許文献３」では、連携のための専用のアプリをクライアントにインストールすることで、連携を実現する。
【０００６】
上記に対して、中継サーバを介すことで連携を実現するアプローチがある。例えば、「特許文献４」では、ポータルにおいて、アプリケーション（ポートレット）間のドラッグ＆ドロップによる連携を実現している。ドラッグ＆ドロップを行う際に、データの属性名が異なる点が課題となるが、中継サーバを設置し、属性名をマッピングすることで、その課題を解決している。中継継サーバやポータルサーバにより連携を実現する場合、従来技術１〜３で必要となるクライアントに連携用ツールを導入、管理するコストが要らないというメリットがある。
【０００７】
また、「特許文献５」では、パラメータマッピングではなく、データ表現形式変換機能を持つ中継サーバにより、連携元、連携先Webシステムのデータ表現形式が異なる場合（例えば、日付を和暦→西暦に変換）にも連携可能とする発明が開示されている。
「非特許文献１」に示すZimbra社のコラボレーションスイートであるZimbra(登録商標) Collaboration Suite(ZCS)では、メールやスケジュールなど、ZCS上のコンテンツと外部システムをZimletと呼ぶミニアプリで連携する機能を提供している。連携用のミニアプリはプログラミングが可能であるので、ZCS上に表示されるコンテンツとユーザーインターフェイスの観点でシームレスな連携が可能となっている。
【０００８】
また、最近のWebブラウザでは、システム連携用のプラグインを導入することで、Webシステムを連携が実現可能となっている。本連携では、Webページの任意の箇所をユーザがマウスで選択し、選択した文字列を検索サイトや翻訳サイトに渡すといった、ちょっとした連携が実現できる。
【０００９】
上記は連携システム全体についての従来技術について例示したが、以下では、連携先サービスとして呼び出される側について、もう少し詳しく従来技術を示す。
【００１０】
Webシステムでは、様々な機能を提供しているが、特定の機能を直接呼び出されることは、あまり想定されていない。例えば、資材発注システムの発注機能を利用しようとする場合、資材発注システムにログインし、発注品を選択し、選択した品を発注するといった、一連の処理を行う必要がある。このように、Webアプリケーションではステートを持つことが多く、特定の機能に対応するURI（Uniform Resource Identifiers）を呼び出しても、その機能を利用できるとは限らない。
【００１１】
これに対して、REST（Representational State Transfer）（非特許文献２）と呼ばれるWebアプリケーションのためのアーキテクチャスタイルがある。RESTアーキテクチャには幾つかの設計原則があり、例えば「ステートレスなクライアント/サーバープロトコル」、「すべてのリソースは URIで表されるユニークなアドレスを持つ」といった原則がある。例えば前者の原則は、HTTPリクエストを受け取ったサーバが、HTTPリクエストに、そのリクエストを処理するために必要な情報が全て含まれていなければならないと言うことを意味する。この原則を考慮すると、前節で例示した資材発注システムは、発注を行う機能に関しては、RESTの設計原則に従っていないことになる。RESTの原則に従っているシステムの例としては、Yahoo!（登録商標） やGoogle（登録商標）などの検索エンジンがある。例えば、「日立製作所」をYahoo! JAPAN（登録商標）で検索する場合のURIは、「http://search.yahoo.co.jp/search?ei=UTF-8&fr=sfp&p=%E6%97%A5%E7%AB%8B%E8%A3%BD%E4%BD%9C%E6%89%80&meta=vc%3D」となる。このURIは日立製作所の検索結果というリソースに割り当ててある一意のURIであり、また、サーバは本URIから処理に必要な情報を取得し、結果を応答することができる。RESTの考え方は、近年注目されているWebを介したAPI (Application Programming Interface)であるWebAPIによく用いられている。
【００１２】
【特許文献１】特開2004-302790号公報
【特許文献２】特開2006-190008号公報
【特許文献３】特開2006-178887号公報
【特許文献４】特開2005-250781号公報
【特許文献５】特開2005-285009号公報
【非特許文献１】Zimlets(tm) - A Mechanism for Integrating Disparate Information Systems and Content with the Zimbra Collaboration Suite, http://www.zimbra.com/pdf/Zimbra%20Zimlets%20Whitepaper.pdf
【非特許文献２】Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures, Chapter 5  http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上記従来方法では、マッピングやデータ変換を行う際に必要となるデータそのものが無い場合は、言うまでも連携できない。仮に連携を実現しようとすると、システム間のインターフェイスを合わせる何かしらのため開発が必要となり現実的ではない。
【００１４】
例えば、連携元Webシステムとして就業管理システムであり、連携のための情報として、"日付"と"場所"(出張先)を持っているものとする。
【００１５】
この場合、連携先Webシステムが同じく、"日付"と"場所"を引数にとるWebシステムであれば、連携は比較的容易に実現できるかもしれない。また、2つの情報のうち、一方のみ、すなわち、"場所"を引数に取るWebシステムや、"日付"を引数にとるWebシステムについては、必要な情報はあるので、同様に連携できる可能性は高い。
【００１６】
しかしながら、"日付"、"場所"(出張先)に加えて"金額"(旅費)を引数にとるWebシステムがあった場合には、"金額"データが足りないため、単純には連携が実現出来ない。データベースを用いて"場所"情報から"金額"情報を算出することも可能であるが、汎用性も無く開発コストもかかり現実的ではない。また、本例のように、微妙にインターフェイスが異なるために、従来技術では連携できない連携シナリオは多数存在すると考えられる。
【００１７】
そこで、本発明では、連携のためのデータが十分で無い場合でも連携を可能とする連携システムを提供する。これにより、開発コストを増大させることなく連携の範囲、柔軟性を大幅に拡大する。
【課題を解決するための手段】
【００１８】
不足している連携用パラメータについて、ユーザからの補完受付やパラメータの個人毎のカスタマイズなどの機能を持つ連携支援機能を設けることで、パラメータが完全に一致していないWebシステムとの連携の実現や、より、ユーザのコンテクストに適合した連携を実現する。
【発明の効果】
【００１９】
本発明によれば、これまで連携が事実上困難であった、微妙にパラメータが不足している連携シナリオにおいても、個別開発無しで連携が可能となる。これにより、操作の誘導や入力支援の適用範囲を大幅に拡大し、ユーザのシステム利用効率を向上する。
【実施例１】
【００２０】
第１の実施例について図面を用いて説明する。本実施例では、本発明の特徴を最も現す必要最小限の構成要素による例を示す。本例では、連携元となるWebシステムは、本発明におけるシステム連携の方法に沿った形で連携用のメタ情報が埋め込まれている。
【００２１】
図1は最も基本的なWebシステム連携システムの全体構成を示す図である。これは、本発明で想定する最も基本的なWebシステム連携システムにおける全体構成図の一例である。
【００２２】
この図において、符号101および符号102は連携元Webシステム、符号103および符号104は連携先Webシステムである。本発明では図に示すように一つ以上のWebシステム同士の連携を実現する。
【００２３】
符号108はユーザがWebシステムの操作や連携の操作を行うクライアントであり、符号109で示すWebブラウザが動作するものである。Webブラウザ109には、符号110に示す連携元WebシステムWebページが表示され、ユーザの連携操作を、連携元システムWebページ110に埋め込まれている、符号111で示すWebシステム連携用GUIが検知し、本発明によるWebシステム連携が動作し、最終的に符号112で示す連携先WebシステムWebページがWebブラウザ109で表示される。
【００２４】
符号106はWebAPIリポジトリ管理、符号107はWebAPIリポジトリである。WebAPIリポジトリ管理106およびWebAPIリポジトリ107は、連携先Webシステム103、104を管理し、Webシステム連携用GUI111と連携し、ユーザに連携可能なWebシステムを提示したり、連携先Webシステムを呼び出したりする。
【００２５】
連携元Webシステム101、102、連携先Webシステム103、104、クライアント108、WebAPIリポジトリ管理106は、符号105で示すネットワークにより相互に接続される。
【００２６】
図2は計算機装置の構成図を示す図である。これは、本発明で想定する計算機装置の一例であり、一般的な計算機の構成と同一のものである。
【００２７】
この図において、符号201は計算機、符号203は通信装置、符号204は外部記憶装置、符号205は主記憶メモリ、符号206は出力装置、符号207は入力装置、符号208はCPU、符号209はデータバスである。
【００２８】
計算機201は通信装置203、外部記憶装置204、主記憶メモリ205、出力装置206、入力装置207、CPU208、データバス209から構成されている。通信装置203はネットワーク105を介してデータを通信するための装置である。主記憶メモリ205はプログラムやデータを一時的に記録するためのものである。出力装置206はディスプレイやプリンタなどデータを出力するための装置である。入力装置207はキーボードやマウスなどデータを入力するための装置である。CPU208は中央演算装置(Central Processing Unit)であり、主記憶メモリ205に記録されている、または、あらかじめ外部記憶装置204から主記憶メモリに転送されたプログラムを実行することができる装置である。データバス209はCPU208や主記憶装置など、計算機の各構成要素を接続するものである。
【００２９】
以下の実施例に登場する全てのプログラムは、本図に示す一般的な計算機の上で動作する。
【００３０】
図3は連携用メタ情報が埋め込まれていないコンテンツを示す図である。これは、本発明で想定する連携用メタ情報が埋め込まれていないコンテンツの一例である。
【００３１】
この図において、符号301は連携元Webシステム101,102が出力するコンテンツを示している。本例ではHTML(Hypertext markup Language)形式のコンテンツを例に取り上げる。本発明はコンテンツの形式の詳細には左右されないので、XHTML(Extensible Hypertext markup Language)など、他の表現形式によるコンテンツでも良い。符号302は、符号301で示すコンテンツのブラウザでの表示例を示している。
【００３２】
図4は連携用メタ情報が埋め込み済みのコンテンツを示す図である。これは、本発明で想定する連携用メタ情報が予め埋め込まれているコンテンツの一例である。
【００３３】
この図において、符号110はメタ情報埋め込み済みのコンテンツ、符号402、符号403、符号404は、連携用メタ情報が埋め込まれている箇所を示している。本実施例では、連携用メタ情報の埋め込み方法として、HTMLの構造付与要素であるspan要素を利用している。本実施例における連携用メタ情報埋め込みは、連携用メタ情報を埋め込みたい箇所をspan要素で囲い、メタ情報をspan開始タグの属性情報を利用して埋め込むという方法で行っている。
【００３４】
本実施例では、連携用メタ情報として、連携先Webシステムに渡したいデータの、データ型およびデータ値を、それぞれclass属性、title属性に設定している。例えば、符号402で示す箇所では、コンテンツ”２００７／０４／１２”について、データ型として”ｄａｔｅ”、データ値として”２００７／０４／１２”をそれぞれ設定している。また、本発明で利用する連携用メタ情報が埋め込まれているか容易に判定可能とするために、”ｈｐｔｌ＿ａｐｉｎｔｅｇ”という値をclass属性に合わせて設定している。データ型、データ値さえ埋め込まれていればさえ良く、当該属性値の設定は必須ではない。
【００３５】
符号403、符号404は複数のデータ値を埋め込んでいる例を示している。本例ではdate型とplace型の連携用メタ情報を埋め込んでいる。符号403では、日付として”２００７／０４／１１”、場所として”日立中研”を埋め込んでいる。符号404では、日付として“２００７／０４／１２”、場所として空文字を埋め込んでいる。本例では複数のデータ値の埋め込みについて、縦棒を区切り文字として利用している。前述した一つのデータのケース、当該複数のデータのケースともに、任意のエンコード、デコード方式を利用して埋め込んでよい。また、class属性が空白区切りで複数の値を列挙できる仕様であるため、データ型については、その仕様に沿って複数の値を列挙している。
【００３６】
尚、本実施例では、dateは日付型、placeは場所型を意味している。本発明では、データ値とデータ型が対になっていることが重要であり、ボキャブラリ定義など、データ型の管理方法については、どのような方法を用いても良い。また、本実施例では、連携用メタ情報の埋め込み方法として、span要素、class属性、title属性を用いているが、連携用メタ情報を付与したいコンテンツに対して、データ型、データ値を埋め込めれば、どのような方法を用いても良い。
【００３７】
連携用のメタ情報として、上述したデータの埋め込みと共に、Webシステム連携のユーザ操作を支援するWebシステム連携用GUI111を合わせて埋め込む。ここでは、JavaScriptとして符号111に示す箇所に埋め込んでいる。また、ページ読み込み完了後にWebシステム連携用GUI111が起動するよう符号401で示すよう、コンテンツのbodyタグのonload属性にWebシステム連携用GUI111を登録している。ここでは、onload属性を用いているが、ユーザの連携操作に先立って、Webシステム連携用GUI111が起動すれば、どのようなタイミング、方法を用いても良い。
【００３８】
符号302は、メタ情報埋め込み済みのコンテンツ111のWebブラウザ109での表示例を示している。符号402で示す埋め込み箇所は、符号405、符号403および符号404で示す埋め込み箇所は、それぞれ、符号406、符号407に該当する。また、符号408、符号409、符号410についても、符号406、符号407と同様な連携用メタ情報が埋め込まれているものとする。本例では、連携用メタ情報埋め込み箇所が、ユーザにブラウザで表示される画面上はっきりと分かるように特に例示していないが、CSS(Cascading Style Sheets)を利用して、文字の表示スタイルを変更したり、アイコン画像を付与したり、などすることも可能である。
【００３９】
図5はWebシステム連携用GUIの構成を示す図である。これは、本発明で想定するWebシステム連携用GUIの機能構成の一例である。この図において、符号111はWebシステム連携用GUI、符号501は初期化処理、符号502はWebシステム連携用メニュー生成部、符号503は連携先Webシステム呼び出し処理部である。
【００４０】
Webシステム連携用GUI111は、主に、初期化処理501、Webシステム連携用メニュー生成部502、連携先Webシステム呼び出し処理部503から構成されている。
Webシステム連携用GUI111は、JavaScriptやVBScriptなどブラウザで動作する処理系であれば、どのような実装方法を用いても良い。以下の実施例では、JavaScriptによる実装の例を示す。
【００４１】
図6はWebAPIリポジトリ管理の構成を示す図である。これは、本発明で想定するWebAPIリポジトリ管理の機能構成の一例である。
【００４２】
この図において、符号106はWebAPIリポジトリ管理、符号107はWebAPIリポジトリ、符号601はWebAPIリポジトリ検索部、符号602はWebAPI実行部である。WebAPIリポジトリ管理106はWebAPIリポジトリ検索601、WebAPI実行部602から構成されている。
【００４３】
WebAPIリポジトリ107には、連携先Webシステムについて、連携用の情報が格納されている。WebAPIリポジトリ検索部601は、Webシステム連携用GUI111から、連携可能な連携先Webシステムの検索要求を受け付け、WebAPIリポジトリ107を検索し、Webシステム連携用GUI111に、必要な情報を応答する。WebAPI実行部602は、Webシステム連携用GUI111から、連携先Webシステムの実行要求を受け付け、WebAPIリポジトリ107に格納されている連携方法に従って、連携先Webシステムを呼び出す。
【００４４】
図7はWebAPIリポジトリのテーブル構成を示す図である。これは、本発明で想定するWebAPIリポジトリのテーブル構成の一例である。
【００４５】
この図において、一つのレコードが一つの連携先Webシステムの定義を示している。符号701は、連携先Webシステムを管理、識別するためのID、符号702は、連携先Webシステムを呼び出すのに必要なパラメータ、符号703は、連携先Webシステムとの連携シナリオの名称、符号704は、連携先Webシステムを呼び出すための連携方法を示すWebAPIシナリオを示す。
【００４６】
符号705で示すレコードは、“検索する”という連携シナリオが登録されており、WebAPIの呼出パラメータとしてstring型を持つ。同様に、符号706で示すレコードは、“地図を表示する”という連携シナリオが登録されており、呼出パラメータとしてplace型を持つ。符号707で示すレコードは、“スケジュールを表示する”という連携シナリオが登録されており、呼出パラメータとして、date型を持つ。符号708で示すレコードは、“東京の天気を表示する”という連携シナリオが登録されており、呼出パラメータとして、date型を持つ。符号709で示すレコードは、“国内旅費清算申請を行う”という連携シナリオが登録されており、呼出パラメータとして、date型、place型、money型の複数のデータ型を持つ。ここで、string型は文字列、money型は金額を示す。連携シナリオの具体的な手順を示すWebAPIシナリオの内容に関しては、以下に示す。
【００４７】
図8は"東京の天気を表示する"連携シナリオのWebAPIシナリオを示す図である。これは、本発明で想定するWebAPIシナリオの一例である。
【００４８】
本例では、WebAPIシナリオをXML(eXtensible Markup Language)形式で格納している。WebAPIシナリオは、基本的には、連携先Webシステムに対するHTTP(HyperText Transfer Protocol)要求を列挙する。一つのrequest要素で一つのHTTP要求を定義する。uri属性にHTTP要求のURL(Uniform Resource Locator)、method属性にHTTPのメソッド種別を定義する。更にparameters要素により該HTTP要求のリクエストパラメータを定義する。リクエストパラメータの定義は、parameters要素の子要素であるparameter要素で定義する。name属性でリクエストパラメータの名称、value属性でリクエストパラメータの値を定義する。Value属性には、ドルマークで始まる名称を指定できる。ドルマークで始まる名称は、Webシステム連携の際に、WebAPIの呼出パラメータ702の定義に従って、WebAPIリポジトリ管理に送られてくるWebシステム連携の要求に含まれる、パラメータの値と置換される。
【００４９】
”東京の天気を表示する”連携シナリオのWebAPIシナリオ定義801は、http://weather.example.com/display.plにGET要求、リクエストパラメータとして、p、dを持ち、pは”ｔｏｋｙｏ”、dは、WebAPIの呼出パラメータであるdateを用いる、という定義となる。
【００５０】
次いで、Webシステム連携の処理の流れについて説明する。
【００５１】
図9はWebシステム連携用GUIの初期化処理を示す図である。これは、本発明で想定するWebシステム連携用GUIの初期化処理の一例である。
【００５２】
本初期化処理は、連携元Webページの読み込み完了後のonloadイベントの延長で呼び出される。本初期化処理は、Webシステム連携用GUIを起動するためのイベントハンドラの登録が目的なので、onloadのタイミング以外、連携元Webページ読み込み開始から実際のWebシステム連携操作の処理前までの任意の時点で本初期化処理が済んでいればよい。
【００５３】
ステップ901はbodyタグオブジェクトを取得する処理である。ステップ902はbodyタグオブジェクトのマウス右クリックイベントのイベントハンドラにWebシステム連携用メニュー生成部を登録する処理である。Webシステム連携用メニュー生成部は、Webシステム連携用GUI111の処理の一部であり、Webシステム連携のためのメニューを生成する。なお、本実施例では、コンテクストメニューと同様に、マウスの右クリックを契機に、Webシステム連携用メニューを起動する。ここでは、マウスの右クリックイベントを利用しているが、コントロールを押しながらマウスカーソルを重ねるなど、任意のイベントを、Webシステム連携用メニュー生成起動の契機として良い。
【００５４】
図10はWebシステム連携用メニュー生成部のメイン処理を示す図である。これは、本発明で想定するWebシステム連携用メニュー生成部におけるメイン処理の一例である。本処理は、図９のステップ902において、登録したイベントハンドラである。
【００５５】
ステップ1001は本イベントハンドラの引数より、イベントの引き金となったHTML要素オブジェクトを取得する処理である。ステップ1002は該HTML要素オブジェクトのclass属性を取得する処理である。ステップ1003は該class属性が"hptl_apinteg"を持つかどうか調べる処理である。もし該class属性が"hptl_apinteg"を持つであれば、ステップ1004へ進む。もし該class属性が"hptl_apinteg"を持つでなければ、連携用メタ情報は埋め込まれていないので、Webシステム連携用メニューは表示せずに終了する。本実施例では、処理を容易にするために、連携用メタ情報埋め込み時に、"hptl_apinteg"class属性値をマーカとして埋め込んでいる。
【００５６】
ステップ1004は、連携用メタ情報が埋め込まれている場合に通る処理であり、該class属性から該HTML要素オブジェクトに埋め込まれているデータ型を全て取得する処理である。ステップ1005は取得した該データ型と連携可能な連携先Webシステムの検索をWebAPIリポジトリ管理106のWebAPIリポジトリ検索部601に要求する処理である。ステップ1006は該検索結果から、後述する連携先Webシステム選択用画面を生成する処理である。
【００５７】
図11はWebAPIリポジトリ検索部601の処理を示す図である。これは、本発明で想定するWebAPIリポジトリ検索部601の検索処理の一例である。本処理は、図１０のステップ1005から呼び出される。
【００５８】
ステップ1101は連携先Webシステム検索のリクエストパラメータに埋め込まれているデータ型を全て取得する処理である。ステップ1102はWebAPIリポジトリ107からWebAPIの呼出パラメータ702が取得した該データ型と一致する連携先サービスを検索する処理である。ステップ1103は一致した連携先WebシステムのID、連携先サービス名をWebシステム連携用メニュー生成部に応答する処理である。
【００５９】
図12は、図11に示すWebAPIリポジトリ検索部601に対する連携先Webシステム検索の要求および応答を示す図である。これは、本発明で想定する連携先Webシステム検索の要求および応答の一例である。以降、図４に示す連携元Webシステム中の符号405で示す日付の部分で、ユーザがWebシステム連携のためにマウス右クリックボタンを押したものとする。
【００６０】
1201は連携先Webシステムの要求の一例である。要求には、連携対象となるデータ型がリクエストパラメータとして含まれる。本例の場合、日付の箇所で連携用操作を行っており、date型がパラメータとして含まれる。
【００６１】
1202は検索結果の応答の一例である。本例では検索結果をXML形式で応答している。検索結果の内容は、連携先Webシステムの識別子701、連携サービス名称703である。本例では、図７に示すWebAPIリポジトリ107において、date型を呼出パラメータ702に取る連携先Webシステムである、"スケジュールを表示する"連携シナリオ707、"東京の天気を表示する"連携シナリオ708が検索結果として、応答される。
【００６２】
本実施例では、XML形式でデータを返却しているが、識別子701、連携サービス名称703が最低限含まれていれば良く、CSV形式など他のフォーマットを用いても良い。また、同じく必要な情報のやりとりが出来れば良いので、HTTP以外の通信プロトコルを用いてもよい。
【００６３】
図13は連携先Webシステム選択用画面生成処理を示す図である。これは、本発明で想定する連携先Webシステム選択用画面生成処理の一例である。本処理は、図10のステップ1006に対応する。
【００６４】
本実施例では、連携先Webシステム選択画面の一例としてコンテクストメニューによる選択方法を示す。コンテクストメニューの生成は、HTML、CSS、JavaScriptなどの技術の組み合わせにより生成できる。また、一般的に良く利用されるメニュー方式ということもあり、製品やオープンソースなど幾つかのライブラリが公開されているので、このようなライブラリを利用しても良い。コンテクストメニュー部品自体、本発明の本質ではないので、擬似コードによる連携先Webシステム選択画面の生成例を示す。
【００６５】
ステップ1301は連携先Webシステムの検索結果1202をパースし、連携先Webシステム候補のid、titleを全て取得する処理である。ステップ1302はコンテクストメニューオブジェクト生成する処理である。ステップ1303は取得した全てのid内の各idを取り出す処理である。もし、要素があれば、ステップ1304へ進む。各要素に対する処理完了後、ステップ1308へ進む。ステップ1304はコンテクストメニューのメニューアイテム生成する処理である。ステップ1305はメニューアイテムの表示タイトルをtitleに設定する処理である。ステップ1306はメニューアイテムのリンク先を連携先Webシステム呼び出し処理部に設定する処理である。呼び出しの引数としてidを設定する。ステップ1307はコンテクストメニューにメニューアイテムを追加する処理である。ステップ1308はコンテクストメニューを表示する処理である。本処理により、連携可能なWebシステム一覧をコンテクストメニューとして一覧表示する。
【００６６】
図14は図13の処理によって生成されたWebシステム連携用メニューを示す図である。これは、本発明で想定するWebシステム連携用メニューの表示の一例であり、コンテクストメニューとして表示している。
【００６７】
この図において、符号1401は図13に示す処理で生成されたWebシステム連携用メニューである。図12のWebAPIリポジトリの検索結果1202で列挙されている連携先Webシステムがコンテクストメニューのアイテムとして列挙される。具体的には、"スケジュールを表示する"連携シナリオ1402、"東京の天気を表示する"連携シナリオ1403が列挙される。
【００６８】
ついで、ユーザが連携先Webシステムを該Webシステム連携メニュー1401から選択した後の処理について示す。
【００６９】
図15は連携先Webシステム呼び出し処理部を示す図である。これは、本発明で想定する連携先Webシステム呼び出し処理部の処理の一例である。
【００７０】
ステップ1501はイベント発火元のHTML要素オブジェクトのclass属性の値を取得する処理である。ステップ1502は該class属性値をパースし、データ型を全て取得する処理である。ステップ1503はイベント発火元のHTML要素オブジェクトのtitle属性の値を取得する処理である。ステップ1504は該title属性値をパースし、データ値を全て取得する処理である。本例では、図14の符号405中に埋め込まれている連携用メタ情報が処理対象となっているので、ステップ1502でデータ型として日付を表すdate、ステップ1504でデータ値として"2007/04/12"が処理結果となる。
【００７１】
ステップ1505は、ユーザが選択したメニューアイテムより取得した連携先Webシステムのid、および、データ値一式をリクエストパラメータに含むWebAPI実行部に対するURLを作成する処理である。ステップ1506はWebAPI実行部に対するURLを引数に新規ウインドウを開く処理である。
【００７２】
図16は図15のステップ1505で生成したWebAPI実行部へのリクエストを示す図である。これは、本発明で想定するWebAPI実行部への連携先Webシステム実行の要求の一例である。
【００７３】
図17はWebAPI実行部の処理を示す図である。これは、本発明で想定するWebAPI実行部の処理の一例である。
【００７４】
ステップ1701は連携先Webシステム実行のリクエストパラメータから連携先Webシステムのid、データ型、データ値を取得する処理である。本例では、idとして4、データ型としてdate、データ値として2007/04/12を取得する。ステップ1702はidをキーにWebAPIリポジトリ107からWebAPIシナリオ704を取得する処理である。本例では、idが4であるレコード708のWebAPIシナリオを取得する。ステップ1703は、図18に示すWebAPIシナリオ処理ルーチンにて連携先Webシステムを呼び出しする処理である。
【００７５】
図18はWebAPIシナリオ処理ルーチンを示す図である。これは、本発明で想定するWebAPIシナリオ処理ルーチンの処理の一例である。本処理ルーチンでは、WebAPIシナリオを元に連携先Webシステムを呼び出すための要求を生成し、ブラウザ109に連携先Webシステムの連携後の画面を表示させる。
【００７６】
WebAPIシナリオ処理ルーチンの処理手順を説明する。本例における連携シナリオ例である"東京の天気を表示する"連携シナリオ（図８）を用いて具体例も合わせて示す。
【００７７】
ステップ1801はscenario要素からrequest子要素を取得する処理である。ステップ1802はuri属性とmethod属性を取得する処理である。本例では、uri属性は、"http://weather.example.com/display.pl"、method属性は、"GET"となる。
【００７８】
ステップ1803から1807はリクエストパラメータを生成する処理である。ステップ1803はparameters要素からparameter子要素を全て取得する処理である。ステップ1804は取得したparameter要素一覧内の各parameter要素を取り出す処理である。もし、要素があれば、ステップ1805へ進む。各要素に対する処理の後、ステップ1808へ進む。ステップ1805はname属性とvalue属性を取得する処理である。ステップ1806はvalue属性が$で始まっているかどうか調べる処理である。もしvalue属性が$で始まっている場合は、ステップ1807へ進む。もしvalue属性が$で始まっていない場合は、ステップ1804へ戻る。ステップ1807は$以降の文字列をデータ型の名称とみなし、WebAPI実行部のリクエストパラメータに含まれるデータ型の値（データ値）と置換する処理である。本例では、上記の処理結果として、"p=tokyo"と"d=2007/04/12"の2つのリクエストパラメータが得られる。後者のリクエストパラメータは、図16の符号1601で示す、WebAPI実行のための要求から得られたリクエストパラメータである。
【００７９】
上記で連携先Webシステム呼び出し用の情報が得られる。ステップ1808から1811で、実際に連携先Webシステムを呼び出す。
【００８０】
ステップ1808はメソッドがGETかどうか調べる処理である。もしメソッドがGETであれば、ステップ1809へ進む。もしメソッドがGETでなければ、ステップ1811へ進む。本実施例では、メソッドとしてGETおよびPOSTの場合について処理方法を例示する。従って、ステップ1811はメソッドがPOSTの場合となる。GET、POST以外のメソッドについても、同様な考え方で連携先Webシステムを呼び出せばよい。
【００８１】
ステップ1809はステップ1803〜1807で取得したnameとvalueをuriのクエリパラメータとして設定する処理である。本例の場合、"p=tokyo&d=2007/04/12"となる。ステップ1810は要求元ブラウザに対し、uriにリダイレクトするよう応答する処理である。以上がGETの場合の処理方法である。応答例を図19に示す。
【００８２】
ステップ1811はPOSTの場合の連携先Webシステムの呼び出し方法である。POSTの場合は、HTTPのリダイレクトが利用できないので、リクエストパラメータを含むForm、かつ、ブラウザがページ読み込み完了直後に、そのFormをサブミット処理するスクリプトを含むコンテンツをブラウザに応答する。処理1811としては、まず、ステップ1803〜1807で取得したnameとvalueをそれぞれinput要素に設定したformを持つHTMLを応答として生成する。formのmethodはPOST、actionはuriを設定する。該formをページ読み込み後に自動サブミットするスクリプトを更に埋め込み、要求元ブラウザに応答することとなる。応答例を図19に示す。
【００８３】
図19は、図18の処理で生成されたWebシステム連携要求元ブラウザへの連携処理指示を示す図である。これは、本発明で想定するWebシステム連携要求元ブラウザへの連携処理のための指示応答の一例である。
【００８４】
符号1901はGETの場合の応答例である。GETの場合は、HTTPリダイレクトを用いることで実現する。HTTP応答コードとして302を応答し、Locationヘッダに連携先Webシステム呼び出し用のURLを設定する。URLのクエリパラメータには、シナリオに列挙されていた値の他、連携元Webシステムの画面に埋め込まれていたデータが含まれる。
【００８５】
本実施例では、WebAPIリポジトリにてリクエストパラメータの処理などを行ったが、連携用メニュー生成時に予めブラウザ側に、本リクエスト生成のための情報をシナリオから抽出、転送していても良い。この場合、図18で示したパラメータの設定処理をJavaScriptなどブラウザ上で動作する処理系で実装することとなる。
【００８６】
符号1902はPOSTの場合の応答例である。POSTの場合は、HTTPリダイレクトなどでは実現できないので、HTML中にPOSTすべき情報を埋め込んだFORM（符号1905）を要求元ブラウザ応答し、そのFORMをページ読み込み後（符号1904）に自動的にサブミット（符号1903）させることで実現する。
【００８７】
本実施例ではGETの処理を符号1901のようにHTTPリダイレクトにより実現していたが、POSTの場合と同様にForm自動サブミット形式で実現することも可能である。また、本実施例では、WebAPIリポジトリにてリクエストパラメータの処理などを行ったが、連携用メニュー生成時に予めブラウザ側に、本リクエスト生成のための情報をシナリオから抽出、転送していても良い。この場合、図18で示したパラメータの設定処理をJavaScriptなどブラウザ上で動作する処理系で実装する。また、ここでは、Formの自動サブミットにて実現しているが、XMLHttpRequestを用いたり、document.href.location変数の利用したりなど、HTTP要求を自動的に実現できる手段ならばどんな方法を用いても良い。
【００８８】
図20は連携先Webシステム呼び出し結果を示す図である。これは、本発明で想定する連携先Webシステムの呼び出し結果の一例である。
【００８９】
基本的には別ウインドウにて連携先Webシステムの画面を表示した方がよいが、タブブラウザの場合は、別のタブに表示したり、また、別のウインドウに表示するのではなく、連携元Webブラウザの画面に上書き表示したりするのももちろん可能である。また、ウインドウのサイズを指定可能にしてもよい。更に上記様々な設定は、連携先Webシステム毎に変更できても良い。
【００９０】
上記実施例では、図14の符号1401に示す連携用メニューで、ユーザが連携先Webシステムを一つ選択し、連携先Webシステムを呼び出したが、複数の連携先Webシステムを選択できる連携用メニューを生成し、ユーザから複数の選択を受け付け、更に、上記、連携先Webシステム呼び出しの処理ステップを逐次実行することで、複数の連携先Webシステムを呼び出せるようにしても良い。
【００９１】
次いで、第２の実施例について図面を用いて説明する。第１の実施例では、WebAPIリポジトリ検索において、単純な完全一致による検索に基づいていた。この場合、連携のための情報が完全に一致している必要があり、連携できるケースが限られてしまう。そこで、第２の実施例では、連携できる範囲を更に広げるている。その第２の実施例の基本的な考え方を示す。まず、連携可能対象を検索する際には、呼出パラメータについて、完全一致による検索を行うのではなく、条件を緩和した部分一致による検索を行う。例えば、dateとplaceを取る連携先Webシステムとの連携を考える。第１の実施例では、dateとplaceが連携元Webシステムの画面にメタ情報として埋め込まれている必要がある。第２の実施例では、部分一致を行うので、dateもしくはplaceの何れか一つの場合でも連携可能とする。ここで、呼び出しする際に不足するパラメータがあるが、それについては、不足分をユーザから受け付ける画面を自動生成し、データを受け取ることで、対応する。以下、処理の詳細を示す。
【００９２】
図21は実施例２におけるWebAPIリポジトリのテーブル構成を示す図である。これは、実施例１で例示したWebAPIリポジトリに対して、符号2101に示す呼出パラメータの表示名を追加したものである。上記概要説明で示した、不足している呼出パラメータを受け付ける画面を自動生成するために利用する。
【００９３】
図22は実施例２におけるWebAPIリポジトリ検索部の処理を示す図である。これは、本発明で想定する部部分一致に基づくWebAPIリポジトリ検索部の検索処理の一例である。
【００９４】
ステップ1101は、図11で示したステップ1101と同様であり、連携先Webシステム検索のリクエストパラメータに埋め込まれているデータ型を全て取得する処理である。ステップ1102は、図11で示したステップ1102と同様であり、WebAPIリポジトリからWebAPIの呼出パラメータが取得した該データ型と一部でも一致する連携先サービスを検索する処理である。
【００９５】
ステップ2201は部分一致した連携先WebシステムのID、呼出パラメータ、呼出パラメータ名称、連携先サービス名をWebシステム連携用メニュー生成部に応答する処理である。部分一致については、検索要求に含まれるデータ型全てを最低限含むという条件でも良いし、検索要求に含まれるデータ型を一つ以上含むといった条件でも良い。完全一致を問わないというのがポイントである。本実施例では、検索要求に含まれるデータ型全てを最低限含むという部分一致条件とする。
【００９６】
図23および図24に実施例２における就業管理システムについての検索結果および連携用メニューの表示結果を示す。ここでは、日付が埋め込まれている符号405、日付と場所が埋め込まれている符号406を、右クリックした場合の例を示す。
【００９７】
図23は連携先Webシステム検索の応答を示す図である。これは、本発明で想定する連携先Webシステム検索の応答の一例である。
【００９８】
応答結果2301は、日付405を右クリックした場合の応答例を示す。この例の場合、date型を少なくとも呼出パラメータに持つWebAPIが連携可能なWebシステムとして応答される。つまり、"スケジュールを表示する"連携シナリオ707、"東京の天気を表示する"連携シナリオ708、"国内旅費清算申請を行う"連携シナリオ709が候補として応答される。
【００９９】
応答結果2302は、日付と場所が含まれる符号406を右クリックした場合の応答例を示す。この例の場合、date型およびplace型を少なくとも呼出パラメータに持つWebAPIが連携可能なWebシステムとして応答される。つまり、このケースの場合は、"国内旅費清算申請を行う"連携シナリオ709が候補として応答される。
【０１００】
実施例１でも述べたが、必要なデータを渡すことができれば、どのようなデータ形式を用いても良いし、どのような通信プロトコルを用いてもよい。
【０１０１】
図24はWebシステム連携用メニューを示す図である。これは、本発明で想定するWebシステム連携用メニューの表示の一例である。
【０１０２】
図23で示した応答結果を元に、図13で示した連携先Webシステム選択用画面生成処理によってWebシステム連携用メニューを生成したものである。符号2401で示す連携用メニューは、図23の符号2301で示す応答結果を元に生成、符号2405で示す連携用メニューは、図23の符号2302で示す応答結果を元に生成したものである。連携用メニューの生成に関しては、検索処理部の検索ロジックには左右されない。
【０１０３】
以降、符号2406で示す"国内旅費清算申請を行う"連携シナリオ709が選択されたケースを元に本実施例を説明する。
【０１０４】
図25は連携先Webシステム呼び出し処理部を示す図である。これは、図15で示した呼び出し処理部に必要な処理を追加したものである。
【０１０５】
ステップ1501は、図15で示したステップ1501と同様であり、イベント発火元のHTML要素オブジェクトのclass属性の値を取得する処理である。ステップ1502は、図15で示したステップ1502と同様であり、該class属性値をパースし、データ型を全て取得する処理である。ステップ1503は、図15で示したステップ1503と同様であり、イベント発火元のHTML要素オブジェクトのtitle属性の値を取得する処理である。ステップ2501は該title属性値をパースし、データ値を全てを取得する処理である。
【０１０６】
ステップ2502は連携先Webシステムのパラメータ内の各parameter要素を取り出す処理である。もし、要素があれば、ステップ2503へ進む。各要素に対する処理の後、ステップ1504へ進む
ステップ2503およびステップ2504にて、不足しているメタ情報があるか調べ、不足している場合、入力受付画面を自動生成する。ステップ2503はdatatype属性で指定されたデータ型が埋め込まれていないかどうか調べる処理である。もしdatatype属性で指定されたデータ型が埋め込まれていない場合は、ステップ2504へ進む。もしdatatype属性で指定されたデータ型が埋め込まれている場合は、ステップ2502へ戻る。ステップ2504は入力受付画面を生成し、データ値を取得する処理である。
【０１０７】
ステップ1504は、図15で示したステップ1504と同様であり、連携先Webシステムのid、データ値一式をリクエストパラメータに含むWebAPI実行部に対するURLを作成する処理である。ステップ1505は、図15で示したステップ1505と同様であり、WebAPI実行部に対するURLを引数に新規ウインドウを開く処理である。
【０１０８】
図26は入力受付画面を示す図である。これは、本発明で想定する入力受付画面の一例である。
【０１０９】
入力受付画面2601は、上段のメッセージ、入力エリア2603、入力確定ボタン2604からなる。上段のメッセージに含まれる、入力すべき内容については、図23に示すWebAPIリポジトリの検索結果中に含まれるデータ型の表示名から生成する。"国内旅費清算申請を行う"連携シナリオ709においては、図25で示す処理により、money型について、入力受付画面が生成される。また、表示名は符号2302に示す応答結果より"旅費"である。この内容が上段メッセージに符号2602として含まれた形で表示される。ここで、ユーザからのデータを受け付け、図17、図18に示す連携先Webシステム呼び出し処理を経て、Webシステムの連携を実現する。
【０１１０】
本実施例では、不足パラメータについて、それぞれ、図26に示す入力受付画面を生成しているが、一つ以上の不足パラメータをまとめて一つの画面で入力受付するインターフェイスでもよい。
【０１１１】
図27は連携先Webシステム呼び出し結果を示す図である。これは、本発明で想定する"国内旅費清算申請を行う"連携シナリオ709の結果を示す図である。
【０１１２】
上記実施例に登場する旅費清算申請システムであるが、このようなシステムは、ユーザ識別もしくは認証が必要不可欠である。また、一般的に、連携元Webページ中に認証情報を埋め込んでおくことは、セキュリティの観点から好ましくないと言える。
【０１１３】
本発明では、認証情報をWebAPIの呼出パラメータに追加定義しておけば、入力受付画面経由で情報を取得可能となる。また、認証情報に関しては、特別なパラメータとして取り扱うこともできる。
【０１１４】
図28に両者の例を示す。本図は、認証情報を含めた国内旅費清算申請を行う連携先Webシステムのシナリオを示す図である。符号2801で示すWebAPIシナリオは前者の他のパラメータと同様に扱う場合、符号2803で示すWebAPIシナリオは後者の特別に取り扱う場合を示している。
【０１１５】
同様に扱う場合では、符号2802に示すように他のパラメータと同様な定義を用いればよい。加えて、符号2802で示す認証情報を受け付けるためにWebAPIリポジトリテーブルの呼出パラメータ702の情報を追加する。実行時においては、本実施例では、該認証情報の連携用メタ情報が埋め込まれていないので、上記説明と同様に、WebAPIリポジトリの部分一致検索でヒット、入力補助画面の生成が行われる。
【０１１６】
認証情報を特別なパラメータとして扱う場合には、例えば、データ値の定義に$USER_ID、$PASSWORDといった予約語（例えば、大文字表記の変数名を予約語として扱う）を使う方法がある。本方式においても、呼出パラメータ702に同様に追加しても良いが、予約している特別なパラメータに関しては、呼出パラメータ702への追加を必要とせず、WebAPIリポジトリがWebAPIシナリオの情報などから自動的に検出し、入力補助画面を自動的に出すようにしても良い。本実施例では、認証情報について例示したが、認証情報以外の任意のデータを取り扱ってよい。本定義例の場合、$USER_ID、$PASSWORDについて、入力補助画面が必要と検出することとなる。
【０１１７】
図29に、図28で示した両方のケースについての入力補助画面の例を示す。
【０１１８】
符号2601で示す入力補助画面は、認証情報についても他のパラメータと同様に取り扱った場合の例を示している。ここでは、複数の不足パラメータを一つの画面で入力受付する画面を元に例を示している。
【０１１９】
符号2907で示す入力補助画面は、特別なパラメータとして定義した場合の入力補助画面の例を示している。この場合、認証情報の入力を受け付ける画面2907を別途生成し、ユーザにとって利用しやすいインターフェイスを提供することが可能となる。
【０１２０】
以上が第２の実施例の説明である。本実施例によれば、従来連携が不可能だったパラメータ不一致のWebシステム同士についても連携が可能となり、連携適用範囲が広がる。
【０１２１】
次いで、第３の実施例について図面を用いて説明する。本実施例では、第２の実施例で入力を受け付けた情報を保存、編集する方法について説明する。データを保存する場合には、誰が入力したデータなのか識別する機構を別途設ける必要がある。また、保存エリアを確保する必要もある。以下、処理の詳細を示す。
【０１２２】
図30は受付情報の保存、編集を可能とする実施例３のWebシステム連携システムの全体構成を示す図である。これは、本発明で想定する受付情報の保存、編集を可能とするWebシステム連携システムの全体構成の一例である。
【０１２３】
実施例２に対する新規の構成要素は、符号3001で示すユーザ情報管理部、符号3002で示すユーザアカウントを管理するテーブル、符号3003で示すカスタマイズ情報を管理するテーブルである。
【０１２４】
図31はユーザアカウントテーブルとカスタマイズ情報テーブルを示す図である。これは、本発明で想定するユーザアカウントテーブルとカスタマイズ情報テーブルの構成の一例である。
【０１２５】
この図において、符号3101はユーザアカウントテーブル、符号3102はユーザID、符号3103はパスワードを示す。ユーザアカウントテーブルでは、ユーザ認証に必要な情報を管理する。本実施例では、ユーザID、パスワードによるユーザ認証を行うものとする。
【０１２６】
符号3104はカスタマイズ情報テーブル、符号3105はユーザID、符号3106はカスタマイズ情報の実体へのリンクを示す。符号3107はカスタマイズ情報の実体管理テーブル、符号3108は連携先WebシステムID、符号3109はデータ型、符号3110はカスタマイズ情報である。ユーザ毎に、連携先Webシステムのデータ型毎に受け付けたデータ値を保持する。本実施例では、カンマ区切りで複数の受け付けたデータ値を保持する。
【０１２７】
なお、ユーザの認証は、Webシステム連携前の任意のタイミングで行う。予め認証しておいても良いし、Webシステム連携用要求の直前で認証しても良い。また、認証事態は必須ではなく、基本的にはユーザを特定できれば良い。もちろん、任意のユーザ認証技術と組み合わせても良い。
【０１２８】
図32は入力値保存機能付きの入力受付画面の一例を示す図である。これは、本発明で想定する入力値保存機能つきの入力受付画面の一例を示す。
【０１２９】
ここでは、ユーザのあるデータ型に対する入力値を一つ以上保存できる場合について例示する。もちろん、常に上書き保存するよう本機能を提供することも可能である。実施例２で示した入力受付画面2601に、データの保存を行うか否かを指定するインターフェイス、および、過去に受け付けたデータを、再利用するためのインターフェイスを更に備える。本実施例では、符号3201、3202、3203で示すチェックボックスで保存の指定、符号3204、3205、3206で示すドロップダウンリストで過去受付値の選択のインターフェイスを提供する例を示している。保存指定、過去入力値の選択さえ実現できれば、どのようなインターフェイスを用いても良い。
【０１３０】
符号2907は、認証情報を特別に取り扱うケースの受付画面の例を示している。本例では、認証情報に関しては、一つの情報のみ保存するよう処理している。
【０１３１】
以降、保存指示の処理、過去受付値の提示について処理方法を示す。
【０１３２】
図33は入力保存のオプション付きWebAPI実行部へのリクエストを示す図である。これは、本発明で想定する入力保存のオプションが付いたWebAPI実行部への連携先Webシステム実行の要求の一例である。
【０１３３】
実施例１、２に示した要求に、保存指示のチェックボックスの状態を示すリクエストパラメータが追加される形となる。チェックボックスの名称については、処理を容易にするために、"save_"という文字列をデータ型に加えた名称としている。例えば、date型の場合は、"save_date"という変数名で保存の有無の指示が渡される。
【０１３４】
図34は入力保存オプション付きのWebAPI実行部の処理を示す図、である。これは、本発明で想定する入力保存オプション付きのWebAPI実行部の処理の一例である。
【０１３５】
ステップ1701は、図17で示したステップ1701と同様であり、連携先Webシステム実行のリクエストパラメータから連携先Webシステムのid、データ型、データ値を取得する処理である。
【０１３６】
ステップ3401から3403が受付値保存のための処理である。ステップ3401は保存指示パラメータを全て取得し、パラメータ名称からsave_を除く処理である。ステップ3402は取得した保存支持パラメータ内の各保存指示パラメータを取り出す処理である。もし、要素があれば、ステップ3403へ進む。各要素に対する処理の後、ステップ1702へ進む。ステップ3403は連携先WebシステムIDがid、データ型が保存指示パラメータと一致するカスタマイズ情報に該データ値を追記する処理である。追記の際、同一のデータ値が有った場合には、追記処理をスキップしても良い。
【０１３７】
ステップ1702は、図17で示したステップ1702と同様であり、idをキーにWebAPIリポジトリからWebAPIシナリオを取得する処理である。ステップ1703は、図17で示したステップ1703と同様であり、WebAPIシナリオ処理ルーチンにて連携先Webシステムを呼び出しする処理である。
【０１３８】
次いで、受付情報の編集方法について図を用いて説明する。
【０１３９】
図35は保存されたWebシステム連携用パラメータ取得のための要求および応答を示す図である。これは、本発明で想定する保存されたWebシステム連携用パラメータ取得のための要求および応答の一例である。
【０１４０】
この図において、符号3501は要求例、符号3502は応答例を示す。要求としては、編集対象連携先Webシステムのidを含む要求をWebAPIリポジトリ管理に送信する。WebAPIリポジトリ管理の連携先Webシステムカスタマイズ情報取得処理部によりカスタマイズ情報を取得し、符号3502に示すカスタマイズ情報をブラウザに応答する。情報が全て含まれていれば、応答のフォーマットはどのような形式でも良い。本実施例では、XML形式での応答例を示す。呼出パラメータのデータ型ごとにparameter要素により受付値を列挙する。
【０１４１】
図36は連携先Webシステムカスタマイズ情報取得処理を示す図である。これは、本発明で想定する連携先Webシステムカスタマイズ情報取得処理の一例である。
【０１４２】
ステップ3601はWebシステム連携用パラメータ取得のリクエストパラメータから連携先Webシステムのidを取得する処理である。ステップ3602はログインユーザIDおよび連携先WebシステムIDと一致するデータ型およびカスタマイズ情報を取得する処理である。本処理の結果として図35の符合3502の応答がブラウザに送信される。
【０１４３】
図37はカスタマイズ情報の編集画面を示す図である。これは、本発明で想定するカスタマイズ情報の編集画面の一例である。
【０１４４】
本編集画面は図35の符号3502で示す応答を元に生成する。ユーザ受付情報の編集が出来ればどのような画面構成を用いても良い。編集結果は、カスタマイズ情報テーブルに反映する。反映処理に関しては、図36で示したカスタマイズ情報取得処理とほぼ逆の処理で実現する。
【０１４５】
上記では、個人ごとのカスタマイズのインターフェイスを説明したが、管理者が予めデフォルトの選択肢を設定することも可能である。図38に設定画面例を示す。画面事態は、メッセージの差異がある程度で、ほぼ共通の画面で構成可能である。カスタマイズ情報テーブルへの反映については、全てのユーザのカスタマイズ情報テーブルに反映しても良いし、管理者用に別途デフォルト値用のカスタマイズ情報テーブルを設け、図32に示す入力受付画面を生成する際に、該デフォルト値用のカスタマイズ情報テーブルを参照することでも実現しても良い。
【０１４６】
以上が第3の実施例である。本実施例によれば、受付値の保存、編集を可能とし、ユーザのデータ繰り返し入力の手間を省くことが可能となる。
【０１４７】
次いで、第4の実施例について図面を用いて説明する。本実施例では、上記実施例では、連携用メタ情報が予め連携元Webシステムに埋め込まれているケースを例示している。本実施例では、連携用メタ情報が埋め込まれていないWebシステムに対して、メタ情報を埋め込む機構を別途提供する例を示す。また、連携先Webシステムについて、複数の要求が必要な複雑なケースの処理方法についても例示する。これにより、連携の適用範囲を更に拡大させることが可能となる。以下、処理の詳細を示す。
【０１４８】
図39はWebシステム連携システムの全体構成を示す図である。これは、本発明で想定するWebシステム連携システムにおける全体構成を示す図の一例である。
【０１４９】
ここで、符号3901で示す連携用メタ情報埋め込みサーバが上記実施例に更に追加される機構である。
【０１５０】
連携用メタ情報埋め込みサーバ3901はWebブラウザ109と連携元Webシステムとの間に介在し、連携元Webシステムの応答結果に対し、メタ情報埋め込み定義3904に従って、システム連携用のメタ情報を埋め込む機能であり、リバースプロキシ3902、連携用メタ情報埋め込みフィルタ3903、および、メタ情報埋め込み定義3904から構成されている。
【０１５１】
リバースプロキシ3902はWebブラウザ109と連携元Webシステム101の通信を取り持ち、連携元Webシステム101の応答を、連携用メタ情報埋め込みフィルタ3903に渡す。その後、連携用メタ情報埋め込みフィルタ3903の処理結果を受け取り、Webブラウザ109に応答する機能である。
【０１５２】
図40はリバースプロキシ3902を示す図である。これは、本発明で想定するリバースプロキシの処理方法の一例である。
【０１５３】
ステップ4001からステップ4004およびステップ4006が一般的なリバースプロキシと同様の処理である。中継中のリクエストが連携用メタ情報埋め込み対象のリクエストであれば、ステップ4007から4009の処理で連携用メタ情報を埋め込む。以下処理の詳細を示す。
【０１５４】
ステップ4001はブラウザからのHTTPリクエスト受付する処理である。ステップ4002はHTTPリクエストからリクエスト先ホスト、ポート番号を取得する処理である。ステップ4003はリクエスト先ホスト、ポート番号に対して受け付けたHTTPリクエストを送信する処理である。ステップ4004はリクエスト先からHTTPレスポンスを受信する処理である。ステップ4005はリクエストがフィルタ適用対象かかどうか調べる処理である。もしリクエストがフィルタ適用対象であれば、ステップ4007へ進む。もしリクエストがフィルタ適用対象でなければ、ステップ4006へ進む。ステップ4006はリクエスト先からのHTTPレスポンスをそのままブラウザに応答する処理である。ステップ4007は連携用メタ情報埋め込みフィルタを呼び出しする処理である。ステップ4008は連携用メタ情報埋め込みフィルタの処理結果をブラウザに応答する処理である。ステップ4009はWebシステム連携用GUIを埋め込みする処理である。
【０１５５】
図41は連携用メタ情報埋め込みフィルタの処理を示す図である。これは、本発明で想定する正規表現に基づいた連携用メタ情報埋め込みフィルタの処理方法の一例である。図4に示す連携用メタ情報が埋め込めれば、どのようなフィルタを用いても良い。
【０１５６】
ステップ4101はメタ情報埋め込み定義リポジトリ3904から正規表現形式の埋め込み定義を読み込む処理である。ステップ4102は埋め込み定義一覧内の各埋め込み定義を取り出す処理である。もし、要素があれば、ステップ4103へ進む。各要素に対する処理の後、終了する。ステップ4103は埋め込み定義に従って埋め込み対象箇所の検索する処理である。ステップ4104は書き換え定義に従って対象箇所にメタ情報を埋め込みする処理である。
【０１５７】
図42はメタ情報埋め込み定義を示す図である。これは、本発明で想定するメタ情報埋め込み定義の一例である。
【０１５８】
この図において、符号4201はメタ情報埋め込み定義、符号4206はメタ情報埋め込み処理適用定義を示す。
【０１５９】
メタ情報埋め込み定義4201は正規表現形式でメタ情報を埋め込む。本例では、bindByRegex要素が一つのメタ情報の埋め込みの定義を意味する。bindByRegex要素は、子要素として、search要素とreplace要素を持つ。また、メタ情報埋め込み処理適用定義4206から参照するために、name属性で埋め込みルールに名称を設定する。
【０１６０】
search要素で、埋め込み箇所を検索する正規表現式を定義する。そして、replace要素で、search要素で検索した箇所に対し、置換する形でメタ情報を埋め込む。replace要素の置換用正規表現式には、search要素で括弧を用いて定義した後方参照を利用する。埋め込む情報としては、データ型、データ値であり、図４に示したフォーマットに沿って埋め込む。また、本実施では、連携可能箇所の判定を容易にするためのマーク"hptl_apinteg"も同時に埋め込む。
【０１６１】
本定義ファイルは手動で作成しても良いし、定義ツールなどにより自動で作成してもよい。また、連携に必要なメタ情報が最低限埋め込めれば良く、どのような手段を用いても良い。
【０１６２】
メタ情報埋め込み処理適用定義4206では、メタ情報埋め込み定義4201で定義したメタ情報埋め込み定義について、埋め込み処理を適用する連携元Webシステムを定義する。
【０１６３】
例えば、符号4207では、http://workmgr.example.com/のURLを持つWebシステムに対して、メタ情報埋め込み定義4201で定義した埋め込みルールrule1およびrule2を適用する場合の定義例である。この定義は、図40のステップ4005のフィルタ適用の判定ステップで参照される。また、eventType属性では、Webシステム連携を起動するイベントの種別も定義している。本例では、マウスの右クリックを契機にWebシステム連携のための処理が起動される。イベント種別を管理、変更可能とすることで、連携元Webシステムが備えているユーザーインターフェイスに干渉することなく、Webシステム連携用GUIを組み込むことが可能である。
【０１６４】
ついで、複数の要求からなる複雑な連携シナリオの対応方法について示す。
【０１６５】
図43は複数の要求からなる国内旅費清算申請を行う連携先Webシステムのシナリオを示す図である。これは、本発明で想定する複数の要求からなる連携先Webシステムのシナリオの一例である。
【０１６６】
本例では、符号4302で示すログイン要求、および、符号4303で示す申請要求の2つの要求からなる例を用いる。WebAPIシナリオの構成要素に関しては、図8で示したWebAPIシナリオと、基本的に同様で、違いは、request要素を複数列挙している点のみである。
【０１６７】
複数要求を持つWebAPIシナリオについて、処理が異なる点は、図18に示したWebAPIシナリオ処理ルーチンのみである。図18について、複数の要求に対応するよう変更した処理方法を図44および図45に示す。
【０１６８】
図44は、サーバサイドで複数要求に対応するWebAPIシナリオ処理ルーチンを示す図である。これは、本発明で想定するサーバサイドで複数要求に対応するWebAPIシナリオ処理ルーチンの処理の一例である。
【０１６９】
ステップ4401はscenario要素からrequest子要素を全て取得する処理である。ステップ4402は取得したrequest要素一覧内の各request要素を取り出す処理である。もし、要素があれば、ステップ1803へ進む。各要素に対する処理の後、終了する。
【０１７０】
ステップ1802は、図18で示したステップ1802と同様であり、uri属性とmethod属性を取得する処理である。ステップ1803は、図18で示したステップ1803と同様であり、parameters要素からparameter子要素を全て取得する処理である。ステップ1804は取得したparameter要素一覧内の各parameter要素を取り出す処理である。もし、要素があれば、ステップ1805へ進む。各要素に対する処理の後、ステップ4409へ進む。
【０１７１】
ステップ1805は、図18で示したステップ1805と同様であり、name属性とvalue属性を取得する処理である。ステップ1806はvalue属性が$で始まっているかどうか調べる処理である。もしvalue属性が$で始まっている場合は、ステップ1807へ進む。もしvalue属性が$で始まっていない場合は、ステップ1804へ戻る。ステップ1807は、図18で示したステップ1807と同様であり、$以降の文字列をデータ型の名称とみなし、WebAPI実行部のリクエストパラメータに含まれるデータ型の値（データ値）と置換する処理である。
【０１７２】
ステップ4403は最後のrequest要素以外かどうか調べる処理である。もし最後のrequest要素以外であれば、ステップ4404へ進む。もし最後のrequest要素以外でなければ、ステップ1808へ進む。ステップ4404はステップ1803〜1807で取得したnameとvalueをリクエストパラメータとしてuriにmethodに従い要求を送信する処理である。ステップ4405は、uriからの応答を受信する処理である。ここで、Cookie設定の応答があれば、以降のステップ4404の処理で、本ステップで受信したCookieの送信も合わせて行う。
【０１７３】
ステップ1808はメソッドがGETかどうか調べる処理である。もしメソッドがGETであれば、ステップ1809へ進む。もしメソッドがGETでなければ、ステップ1811へ進む。ステップ1809は、図18で示したステップ1809と同様であり、ステップ1803〜1807で取得したnameとvalueをuriのクエリパラメータとして設定する処理である。ステップ1810は、図18で示したステップ1810と同様であり、要求元ブラウザに対し、uriにリダイレクトするよう応答する処理である。ただし、ステップ4405にてSet-Cookie応答によりCookieの設定を行っている場合には、リダイレクトの応答に、該Cookieをブラウザに設定するようヘッダを追加する。その際には、WebAPIリポジトリ管理が稼動するマシンと連携先Webシステムが稼動するマシンが、同一のドメイン、もしくは、親ドメインを持つ必要があり、Set-Cookieヘッダのdomain属性に親ドメインを指定し、ステップ4405で受け取ったCookieがブラウザから連携先Webシステムへの要求に含まれる必要がある。同一の親ドメインを持てない場合には、図45に示す方法にて、連携先Webシステムを呼び出す。
【０１７４】
ステップ1808は、図18で示したステップ1808と同様であり、ステップ1803〜1807で取得したnameとvalueをそれぞれinput要素に設定したformを持つHTMLを応答として生成。formのmethodはPOST、actionはuriを設定。該formをページ読み込み後に自動サブミットするスクリプトを更に埋め込み、要求元ブラウザに応答する処理である。POSTのケースにおいても、上記GETのケースと同様にCookieの処理を行う。
【０１７５】
図45は、クライアントサイドで複数要求に対応するWebAPIシナリオ処理方法を示す図である。これは、本発明で想定するクライアントサイドで複数要求に対応するWebAPIシナリオ処理方法の一例である。図44で示したサーバサイドでのWebAPIシナリオ実行方法では、クッキーのdomain属性を利用してシングルサインオンを行うので、WebAPI実行部602と連携先サーバが同一の親ドメインを持つ必要がある。また、WebAPI実行の要求が多数行われると、WebAPI実行部602が動作するサーバのリソースが枯渇するという課題もある。
【０１７６】
上記に対し、以下で示す、クライアントサイドでのWebAPIシナリオ実行方法では、ドメインの制約を受けず、連携先サーバの適用範囲を拡大することが可能である。また、主にクライアントサイドでWebAPIシナリオの実行処理を行うので、WebAPI実行部602が動作するサーバのリソースも少なくて済む。
【０１７７】
本処理方法は、図19で示した一つのGETまたはPOSTリクエストのクライアントサイドでの自動処理方法を、複数のGETまたはPOSTリクエストに拡張したものである。
【０１７８】
本処理方法では、二種類のForm自動サブミット応答からなる。一つは、符号4501で示すリクエスト処理用応答、もう一つは、符号4507で示す最終リクエスト処理用応答である。本情報は、図19と同様にWebAPI実行部602が生成、応答する。WebAPIシナリオが複数の要求を持つ場合、最後の一つ前まで、応答4501で処理し、最後の要求は応答4507で処理する。応答4501は応答4507が持つインラインフレーム4511の延長で動作する。インラインフレーム4511の延長で、応答4501がブラウザに読み込まれると、符号4504に示す指示に従い、符号4502の処理が走り、符合4506のFormに埋め込まれている要求の情報が自動的に連携先Webシステムに送信される。送信が完了すると、符号4505の指示に従い、符号4503で示す処理が起動される。本処理では、応答4507の符号4509で示す処理が起動する。4509では、何番目のリクエストを処理しているか管理しており、最後のリクエスト以外の場合、インラインフレーム4511に応答4501に対応するページを読み込ませる。URL中にリクエストの番号を示すパラメータを付加することで、適切な応答4501をブラウザに処理させることができる。最後のリクエストの場合は、符号4512で示すFormがサブミットされる。
【０１７９】
シナリオの処理を制御するシナリオ実行制御部4507、シナリオ実行制御部4507とは別のウインドウにて連携先Webシステムに順次リクエストを要求するクロスサイトアクセス部4501の二つのウインドウを用いることで、クライアントサイドでの複数リクエストからなるWebAPIシナリオの実行を可能としている。
【０１８０】
上記では、クロスサイトアクセス部4501の実現方法として、インラインフレームを用いているが、インラインフレームの代わりに別のウインドウを生成し、連携先に要求を行うことでも実現可能である。図47に別ウインドウ方式での実現例を示す。図45で示すインラインフレーム方式との差分は、図45の符号4509、符号4512で示すインラインフレームを用いた逐次要求部分が、図47の符号4703に示すwindow.openを利用したウインドウの生成処理に置き換わったことである。また、図45の符号4503で示すシナリオ実行制御部4507への要求完了通知が、図47の符号4701で示すwindow.openerを用いた式に変更される。
【０１８１】
これ以外にも、スクリプトから通信が可能な通信ライブラリを用いて実現することも可能である。図48にXMLHttpRequestを用いた例を示す。通信ライブラリを用いる場合には、上記二つの方式とは異なり、一つのウインドウでWebAPIシナリオの実行を行うことも可能である。符号4802、符号4803で示す箇所がXMLHttpRequestを用いた要求の処理例である。本例では、符号4801に示すように、予め要求の情報をスクリプトに埋め込んでいる。本例には、XMLHttpRequestを用いた例を示しているが、連携先サーバ（クロスサイト）にアクセス可能な、ブラウザ上で動作する任意の処理系の任意の通信ライブラリを用いて良い。
図45および図47で示した、インラインフレーム方式、別ウインドウ方式のクロスサイトアクセス部4501では、WebAPIシナリオの要求ごとにWebAPI実行部602に問い合わせ、ページを生成しているが、図48のように、全ての要求をシナリオ実行制御部4507に埋め込んでいても良い。逆に図48に示す、通信ライブラリ利用方式では、符号4801に示す箇所に情報を埋め込み済みであるが、WebAPIシナリオの要求ごとにWebAPI実行部602に問い合わせても良い。
【０１８２】
以上が第4の実施例の説明である。第4の実施例によれば、連携用メタ情報を埋め込んでいない連携先Webシステムについても、連携元Webシステムとなることが可能である。また、複数個のリクエストのハンドリングを可能とし、連携先Webシステムの適用範囲を広げることが可能となる。第4の実施例で示した、連携用メタ情報の埋め込みや、複数個のリクエストのハンドリング方法は、独立に他の実施例と組み合わせても良い。
【０１８３】
ついで、第5の実施例について図を用いて説明する。Webシステムを統合し、一元的にアクセス可能とするポータル機能がある。本実施例では、ポータルと本発明を組み合わせて、ポータル画面を連携元とする、Webシステム連携について説明する。
【０１８４】
図46はポータルサーバでのWebシステム連携システムの全体構成を示す図である。これは、本発明で想定するポータルサーバにWebシステム連携システムを組み合わせた場合の全体構成の一例である。
【０１８５】
この図において、符号4601はポータルサーバである。ポータルサーバ4601は、符号4603、4604で示すポートレットにより、Webシステムやメインフレーム上で動作するシステムなど様々なITシステムを、ポータル上で組み合わせ可能なミニアプリケーションとして、ラッピングする。ポートレットが出力するコンテンツは、符号4602で示す画面統合機能により統合される。符号4609に統合されたポータル画面の例を示す。本例では、就業管理ポートレットと業務システムシングルサインオンポートレットの2つのポートレットを統合したポータル画面を示している。
【０１８６】
このような一般的な構成のポータルシステムに、連携用メタ情報埋め込み機能である連携用メタ情報埋め込みフィルタ3903、および、WebAPIリポジトリ管理106を追加する。連携用メタ情報埋め込みフィルタ3903に関しては、リバースプロキシ3902と同様な処理を実現するポートレットフィルタ4605により呼び出す。また、ユーザの承認やユーザカスタマイズ情報に関しては、ポータルサーバが持つ同等の機能（符号4606、符号4607、符号4608）をそのまま利用することができる。
【０１８７】
以上が実施例5の説明である。このような構成によりポータルサーバでITシステムを統合しつつ、ポータル画面を軸に様々なWebシステムと連携することが可能となる。
【０１８８】
実施例5ではポータルサーバに両機能を組み込んだ例を例示したが、一方のみ組み込んだりすることも可能である。また、それ以外の実施例についても、メタ情報の埋め込み機能とWebAPIの管理部分をそれぞれ独立のサーバで動作する例を示したが、同一のサーバで動作することも可能である。
【産業上の利用可能性】
【０１８９】
本発明を用いることにより、これまで、連携が困難であった、微妙にインターフェイスが異なるWebシステム同士でも連携が可能となる。これにより、複数のシステムに跨った業務の効率が改善することが可能となる。また、様々インターフェイスを持つ外部のWebシステムとの柔軟な連携も実現可能となり、ユーザの生産性が向上する。
【図面の簡単な説明】
【０１９０】
【図１】本発明で想定する最も基本的なWebシステム連携システムにおける全体構成図の一例である。
【図２】本発明で想定する計算機装置の一例であり、一般的な計算機の構成と同一のものである。
【図３】本発明で想定する連携用メタ情報が埋め込まれていないコンテンツの一例である。
【図４】本発明で想定する連携用メタ情報が埋め込まれているコンテンツの一例である。
【図５】本発明で想定するWebシステム連携用GUIの機能構成の一例である。
【図６】本発明で想定するWebAPIリポジトリ管理の機能構成の一例である。
【図７】本発明で想定するWebAPIリポジトリのテーブル構成の一例である。
【図８】本発明で想定する"東京の天気を表示する"連携シナリオのWebAPIシナリオ定義の一例である。
【図９】本発明で想定するWebシステム連携用GUIの初期化処理の一例である。
【図１０】本発明で想定するWebシステム連携用メニュー生成部におけるメイン処理の一例である。
【図１１】本発明で想定するWebAPIリポジトリ検索部の検索処理の一例である。
【図１２】本発明で想定する連携先Webシステム検索の要求および応答の一例である。
【図１３】本発明で想定する連携先Webシステム選択用画面生成処理の一例である。
【図１４】本発明で想定するWebシステム連携用メニューの表示の一例である。
【図１５】本発明で想定する連携先Webシステム呼び出し処理部の処理の一例である。
【図１６】本発明で想定するWebAPI実行部への連携先Webシステム実行の要求の一例である。
【図１７】本発明で想定するWebAPI実行部の処理の一例である。
【図１８】本発明で想定するWebAPIシナリオ処理ルーチンの処理の一例である。
【図１９】本発明で想定するWebシステム連携要求元ブラウザへの連携処理のための指示応答の一例である。
【図２０】本発明で想定する連携先Webシステムの呼び出し結果の一例である。
【図２１】本発明で想定するWebAPIリポジトリのテーブル構成の一例である。
【図２２】本発明で想定する部部分一致に基づくWebAPIリポジトリ検索部の検索処理の一例である。
【図２３】本発明で想定する連携先Webシステム検索の応答の一例である。
【図２４】本発明で想定するWebシステム連携用メニューの表示の一例である。
【図２５】本発明で想定する連携先Webシステム呼び出し処理部の処理の一例である。
【図２６】本発明で想定する入力補助画面の一例である。
【図２７】本発明で想定する"国内旅費清算申請を行う"連携シナリオの結果の一例である。
【図２８】本発明で想定する認証情報を含む連携先Webシステムのシナリオの一例である。
【図２９】本発明で想定する入力補助画面の一例である。
【図３０】本発明で想定する受付情報の保存、編集を可能とするWebシステム連携システムの全体構成の一例である。
【図３１】本発明で想定するユーザアカウントテーブルとカスタマイズ情報テーブルの構成の一例である。
【図３２】本発明で想定する入力値保存機能つきの入力受付画面の一例である。
【図３３】本発明で想定する入力保存のオプションが付いたWebAPI実行部への連携先Webシステム実行の要求の一例である。
【図３４】本発明で想定する入力保存オプション付きのWebAPI実行部の処理の一例である。
【図３５】本発明で想定する保存されたWebシステム連携用パラメータ取得のための要求および応答の一例である。
【図３６】本発明で想定する連携先Webシステムカスタマイズ情報取得処理の一例である。
【図３７】本発明で想定する一般ユーザの場合のカスタマイズ情報の編集画面の一例である。
【図３８】本発明で想定する管理者ユーザの場合のカスタマイズ情報の編集画面の一例である。
【図３９】本発明で想定するWebシステム連携システムにおける全体構成を示す図の一例である。
【図４０】本発明で想定するリバースプロキシの処理方法の一例である。
【図４１】本発明で想定する正規表現に基づいた連携用メタ情報埋め込みフィルタの処理方法の一例である。
【図４２】本発明で想定するメタ情報埋め込み定義の一例である。
【図４３】本発明で想定する複数の要求からなる連携先Webシステムのシナリオの一例である。
【図４４】本発明で想定するサーバサイドで複数要求に対応するWebAPIシナリオ処理ルーチンの処理の一例である。
【図４５】本発明で想定するクライアントサイドで複数要求に対応するWebAPIシナリオ処理方法（インラインフレーム方式）の一例である。
【図４６】本発明で想定するポータルサーバにWebシステム連携システムを組み合わせた場合の全体構成の一例である。
【図４７】本発明で想定するクライアントサイドで複数要求に対応するWebAPIシナリオ処理方法（別ウインドウ方式）の一例である。
【図４８】本発明で想定するクライアントサイドで複数要求に対応するWebAPIシナリオ処理方法（通信ライブラリ利用方式）の一例である。
【符号の説明】
【０１９１】
101、102…連携元Webシステム
103、104…連携先Webシステム
106…WebAPIリポジトリ管理
107…WebAPIリポジトリ
108…クライアント
109…Webブラウザ
110…連携元WebシステムWebページ
111…Webシステム連携用GUI
112…連携先WebシステムWebページ。
【図１】
2008293152.tif 000003
【図２】
2008293152.tif 000004
【図３】
2008293152.tif 000005
【図４】
2008293152.tif 000006
【図５】
2008293152.tif 000007
【図６】
2008293152.tif 000008
【図７】
2008293152.tif 000009
【図８】
2008293152.tif 000010
【図９】
2008293152.tif 000011
【図１０】
2008293152.tif 000012
【図１１】
2008293152.tif 000013
【図１２】
2008293152.tif 000014
【図１３】
2008293152.tif 000015
【図１４】
2008293152.tif 000016
【図１５】
2008293152.tif 000017
【図１６】
2008293152.tif 000018
【図１７】
2008293152.tif 000019
【図１８】
2008293152.tif 000020
【図１９】
2008293152.tif 000021
【図２０】
2008293152.tif 000022
【図２１】
2008293152.tif 000023
【図２２】
2008293152.tif 000024
【図２３】
2008293152.tif 000025
【図２４】
2008293152.tif 000026
【図２５】
2008293152.tif 000027
【図２６】
2008293152.tif 000028
【図２７】
2008293152.tif 000029
【図２８】
2008293152.tif 000030
【図２９】
2008293152.tif 000031
【図３０】
2008293152.tif 000032
【図３１】
2008293152.tif 000033
【図３２】
2008293152.tif 000034
【図３３】
2008293152.tif 000035
【図３４】
2008293152.tif 000036
【図３５】
2008293152.tif 000037
【図３６】
2008293152.tif 000038
【図３７】
2008293152.tif 000039
【図３８】
2008293152.tif 000040
【図３９】
2008293152.tif 000041
【図４０】
2008293152.tif 000042
【図４１】
2008293152.tif 000043
【図４２】
2008293152.tif 000044
【図４３】
2008293152.tif 000045
【図４４】
2008293152.tif 000046
【図４５】
2008293152.tif 000047
【図４６】
2008293152.tif 000048
【図４７】
2008293152.tif 000049
【図４８】
2008293152.tif 000050