(57)【要約】【課題】情報処理システムへの処理要求からその応答までの一連の処理における電文の所在を検出する【解決手段】電文所在検索プログラムは、クライアント端末またはサーバ装置に、処理要求に応じて処理を行う情報処理システムを構築する要素を示す複数のコンポーネントのそれぞれが保持している電文に付与されている電文を識別する識別情報を含む管理情報を、コンポーネント毎に格納部に保持し、複数のコンポーネントに対する問い合わせに応じて、格納部に保持されている管理情報のうち、問い合わせに含まれる条件に一致する管理情報に対応するコンポーネントを特定する特定情報を問い合わせ元に応答する処理を実行させることにより、上記課題の解決を図る。【選択図】図１
2016143317.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末またはサーバ装置に、
処理要求に応じて処理を行う情報処理システムを構築する要素を示す複数のコンポーネントのそれぞれが保持している電文に付与されている該電文を識別する識別情報を含む管理情報を、コンポーネント毎に格納部に保持し、
前記複数のコンポーネントに対する問い合わせに応じて、前記格納部に保持されている前記管理情報のうち、該問い合わせに含まれる条件に一致する前記管理情報に対応するコンポーネントを特定する特定情報を問い合わせ元に応答する
処理を実行させる電文所在検索プログラム。
【請求項２】
前記応答において、前記格納部から前記条件にて指定されている該識別情報に一致する前記管理情報が検索された場合、検索された該管理情報に対応するコンポーネントの特定情報を前記問い合わせ元に応答する
ことを特徴とする請求項１に記載の電文所在検索プログラム。
【請求項３】
前記管理情報は、さらに、前記電文の属性情報を含み、
前記応答において、前記条件に前記電文の属性情報が指定されている場合、前記格納部から該属性情報に一致する前記管理情報を検索が検索された場合、検索された該管理情報に対応する前記コンポーネントの特定情報を問い合わせ元に応答する
ことを特徴とする請求項１に記載の電文所在検索プログラム。
【請求項４】
処理要求に応じて処理を行う情報処理システムを構築する要素を示す複数のコンポーネントのそれぞれが保持している電文に付与されている該電文を識別する識別情報を含む管理情報を、コンポーネント毎に保持する格納部と、
前記複数のコンポーネントに対する問い合わせに応じて、前記格納部に保持されている前記管理情報のうち、該問い合わせに含まれる条件に一致する前記管理情報に対応するコンポーネントを特定する特定情報を問い合わせ元に応答する応答部と、
を備えることを特徴とする電文所在検索システム。
【請求項５】
クライアント端末またはサーバ装置が、
処理要求に応じて処理を行う情報処理システムを構築する要素を示す複数のコンポーネントのそれぞれが保持している電文に付与されている該電文を識別する識別情報を含む管理情報を、コンポーネント毎に格納部に保持し、
前記複数のコンポーネントに対する問い合わせに応じて、前記格納部に保持されている前記管理情報のうち、該問い合わせに含まれる条件に一致する前記管理情報に対応するコンポーネントを特定する特定情報を問い合わせ元に応答する
を処理を実行する電文所在検索方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、電文所在検索プログラム、電文所在検索システム、及び電文所在検索方法に関する。
【背景技術】
【０００２】
近年、クラウドコンピューティング技術の発達により、サーバシステムが普及し、クライアント端末からの処理要求に応じてサービスを提供する業務システムにおいて処理される電文の量が増加している。そのため、サーバシステムを構築する要素としてのコンポーネントのいずれかの処理が遅延すると、その遅延している処理がボトルネックとなり、サーバシステム全体の処理性能が低下する。そのようなサーバシステムの障害に対して対処する技術がある。
【０００３】
例えば、第１技術として、任意の時間に障害診断を行なう技術がある（例えば、特許文献１）。第１技術では、クライアントシステムから送信される診断電文をサーバシステムの業務電文処理部で受信し、業務電文処理部から診断電文管理部に引き渡す。診断電文管理部が自己の診断電文に該当しない場合には、後段に送信し、自己の診断電文に該当する場合には、クライアントシステムに応答電文を送信する。任意の時間応答電文が送信されない場合と、送信されても応答電文の内容が期待値と異なる場合にサーバシステムに異常が発生しているとクライアントシステムで診断する。
【０００４】
また、第２技術として、通信障害の発生に伴い、中継サーバが処理要求を再送信した場合であっても、連携先サーバにおける同一処理の重複を排除する技術がある（例えば、特許文献２）。第２技術では、連携元サーバは、処理要求を中継サーバに送信する。中継サーバは、各処理要求を一意に識別するための電文識別子を処理要求に付加し、連携先サーバに送信する。連携先サーバは、処理要求に付加された電文識別子に対応する応答電文がデータベースに保持されているか否かを確認する。連携先サーバは、応答電文が保持されていなければ、要求された処理を実行し、応答電文を中継サーバに送信する。また、連携先サーバは、応答電文を電文識別子に対応させて、データベースに登録する。連携先サーバは、応答電文が保持されていれば、その応答電文を中継サーバに送信する。中継サーバは、連携先サーバから正常な応答がなければ、処理要求を再送信する。
【０００５】
また、第３技術としては、サーバシステムは受付登録報告の電文のなかに固有の受け付けコードを記録して端末に返送し、端末はその受付コードを督促電文に含め返信し、処理状況の回答を得る。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１１−２４９９２４号公報
【特許文献２】特開２００３−８５０６０号公報
【特許文献３】特開２００３−１６０４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
サーバシステムの障害が発生した場合、サーバシステムの各コンポーネントが逐次出力する電文ログを解析することが考えられる。この場合、コンポーネント毎の電文ログの解析になるため、サーバシステムへの処理要求からその応答までの一トランザクションにおけるどのコンポーネントの障害であるかを把握することが容易ではないため、サーバシステムのどのような運用にて障害が発生したのかを把握が困難である。
【０００８】
例えば、第１技術では、クライアントからの診断要求に応じて、各診断電文管理部が自身の診断を行うが、業務システムへの処理要求からその応答までの一トランザクションにおける電文の所在を検出することはできない。
【０００９】
また、第２技術及び第３技術では、サーバは、処理要求に付加された電文識別子に対応する応答電文がデータベースに保持されている場合、応答電文を送信する。しかしながら、第２技術及び第３技術でも、業務システムへの処理要求からその応答までの一トランザクションにおける電文の所在を検出することはできない。
【００１０】
本発明は、一側面として、情報処理システムへの処理要求からその応答までの一連の処理における電文の所在を検出する技術を提供する。
【課題を解決するための手段】
【００１１】
本発明の一側面に係る電文所在検索プログラムは、クライアント端末またはサーバ装置に次の処理を実行させる。すなわち、クライアント端末またはサーバ装置は、処理要求に応じて処理を行う情報処理システムを構築する要素を示す複数のコンポーネントのそれぞれが保持している電文に付与されている電文を識別する識別情報を含む管理情報を、コンポーネント毎に格納部に保持する。クライアント端末またはサーバ装置は、複数のコンポーネントに対する問い合わせに応じて、格納部に保持されている管理情報のうち、問い合わせに含まれる条件に一致する管理情報に対応するコンポーネントを特定する特定情報を問い合わせ元に応答する。
【発明の効果】
【００１２】
本発明の一側面によれば、情報処理システムへの処理要求からその応答までの一連の処理における電文の所在を検出することができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態における電文所在検索システムの一例を示す。
【図２】本実施形態における業務システムの一例を示す。
【図３】本実施形態に係る電文に付加される電文管理情報の一例を示す。
【図４】本実施形態における電文管理情報が付加された電文が処理されている位置を特定する方法を説明するための図である。
【図５】本実施形態におけるコンポーネント単位で行われる処理を説明するための図である。
【図６】本実施形態における管理簿の一例を示す。
【図７】本実施形態における電文の発生に応じて行われる電文管理情報の管理簿への登録処理を説明するための図である。
【図８】本実施形態における電文の削除に応じて行われる管理簿からの電文管理情報の削除処理を説明するための図である。
【図９】本実施形態におけるトークンの引継ぎ処理を説明するための図である。
【図１０】本実施形態における位置検索モジュールの処理フローを示す。
【図１１】本実施形態における、情報提供要求に応じて問い合わせ元に応答された位置情報の可視化の一例（その１）を示す。
【図１２】本実施形態における、情報提供要求に応じて問い合わせ元に応答された位置情報の可視化の一例（その２）を示す。
【図１３】本実施形態における、情報提供要求に応じて問い合わせ元に応答された位置情報の可視化の一例（その３）を示す。
【図１４】本実施形態における、サーバ単位での管理簿３３及び位置検索モジュール３４の設置例を説明するための図である。
【図１５】本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。
【発明を実施するための形態】
【００１４】
ホストまたはサーバにて端末から送信された処理要求（電文）に対する処理（電文処理）を行うシステムにおいて、処理の遅延が発生した場合、次のことが考えられる。すなわち、電文処理経路上におけるシステムを構築するコンポーネント（以下、「コンポーネント」と称する）の電文ログまたはトレース（以下、「電文ログ」と称する）を解析して、性能のボトルネック（隘路）となる部分を調査することが考えられる。しかしながら、電文処理経路上において、リアルタイムにボトルネックとなる箇所を特定する場合、以下の問題がある。
【００１５】
通信量に比例して電文ログ出力量が増えるため、大量の電文が処理されるシステムでは大量の電文ログを解析することが求められる。近年のコンピュータ処理能力の増加、データ通信回線の高速化に伴い、電文処理量は増大しており、解析対象となる電文ログも増大している。また、ログの形式はコンポーネント毎に異なるため、コンポーネント毎に電文ログ解析の知識が求められる。
【００１６】
また、近年、負荷分散のため複数のサーバにセッションを配分して処理されることが多いが、電文の処理位置の確認のためには複数のサーバの電文ログを調査する必要がある。電文の処理位置を特定するためには、電文を処理するコンポーネントが出力するログを解析する場合、大量の電文ログ／複数の電文ログフォーマットを解析・集計処理する必要がある。しかしながら、リアルタイムで電文の処理位置を特定、すなわち、電文が処理されている位置と、その処理しているコンポーネントとの関係付けを行うことは難しい。
【００１７】
また、コンポーネントの電文ログの出力中はログ出力ファイルが排他的に占有されている場合があり、ログ出力ファイルが開放されるまで電文ログを参照できない場合がある。
【００１８】
また、電文処理待ち行列（キュー）の大きさを量るコマンドが提供されている場合があり、そのコマンドを用いて、キュー長が容量の何パーセントになっているかを確認することができる。しかしながら、調査対象の電文がキューに含まれているかを調べる事は出来ない事が多い。
【００１９】
さらに、金融・交通・通信・行政などの社会基盤システムでは、システムの停止や処理遅延による影響が大きい。社会基盤システムではトラブルが発生した場合の調査を短時間で行い速やかな回復を求められる。このため、リアルタイムでボトルネック箇所を特定する方法が必要となっている。
【００２０】
そこで、本実施形態では、電文処理経路上におけるシステムを構成するコンポーネントまたはサーバに調査対象の電文の位置を問い合わせ、その問い合わせに対する応答を受け取るようにする。これにより、コンポーネントが出力する電文ログの解析を行う事なく、電文の位置を特定することができる。
【００２１】
また、複数の業務電文が交錯するシステムにおいてもボトルネック箇所の特定が容易となるように、指定した条件での電文調査を可能とする。
【００２２】
電文をメモリ上の電文管理簿で管理することにより、ボトルネック箇所の確認を高速で行うことができる。
【００２３】
図１は、本実施形態における電文所在検索システムの一例を示す。電文所在検索システム１は、格納部２、応答部３を含む。格納部２は、処理要求に応じて処理を行う情報処理システムを構築する要素を示す複数のコンポーネントのそれぞれが保持している電文に付与されている電文を識別する識別情報を含む管理情報を、コンポーネント毎に保持する。
【００２４】
応答部３は、複数のコンポーネントに対する問い合わせに応じて、格納部２に保持されている管理情報のうち、問い合わせに含まれる条件に一致する管理情報に対応するコンポーネントを特定する特定情報を問い合わせ元に応答する。より具合的には、応答部３は、格納部２から条件にて指定されている識別情報に一致する管理情報が検索された場合、検索された管理情報に対応するコンポーネントの特定情報を問い合わせ元に応答する。
【００２５】
このように構成することにより、情報処理システムへの処理要求からその応答までの一連の処理における電文の所在を検出することができる。
【００２６】
管理情報は、さらに、電文の属性情報を含む。このとき、応答において、条件に電文の属性情報が指定されている場合、格納部２から属性情報に一致する管理情報を検索が検索された場合、検索された管理情報に対応するコンポーネントの特定情報を問い合わせ元に応答する。
【００２７】
このように構成することにより、電文の属性毎に情報処理システム内での電文の滞留状況を検出することができる。
【００２８】
図２は、本実施形態における業務システムの一例を示す。業務システム１１は、クライアント端末１２、中継サーバ１３、業務サーバ１４、データベース管理システム（ＤＢＭＳ）１５、通信ネットワーク１７を含む。クライアント端末１２と中継サーバ１３は、通信ネットワーク１７を介して接続されている。業務サーバ１４は、中継サーバ１３を介して、通信ネットワーク１７と接続されている。本実施形態において、図１の電文所在検索システム１は、業務システム１１に組み込まれているシステムである。具体的には、電文所在検索システム１は、クライアント端末１２、中継サーバ１３、業務サーバ１４のそれぞれに構築される。
【００２９】
クライアント端末１２は、ユーザから入力された業務サーバ１４に対する指示を受け付け、その指示に基づいて、業務サーバ１４に対する処理要求（電文）を発行するコンピュータである。
【００３０】
中継サーバ１３は、クライアント端末１２から発行された処理要求を業務サーバ１４へ転送するサーバ装置である。
【００３１】
業務サーバ１４は、中継サーバ１３を介してクライアント端末１２から送信された処理要求を受信すると、その要求に対する処理を実行し、処理結果をクライアント端末１２に応答する。
【００３２】
業務サーバ１４は、通信制御部２１、トランザクション制御部２２、オペレーティングシステム（ＯＳ）２３、業務プログラム２４を搭載する。ＯＳ２３は、業務サーバ１４を動作させるための基本プログラムである。
【００３３】
通信制御部２１は、ＯＳ２３上で動作するプログラムであり、情報の送受信の制御を行う。トランザクション制御部２２は、ＯＳ２３上で動作するプログラムであり、端末１２から送信される処理要求に対応する一連の処理（トランザクション）の管理を行う。
【００３４】
業務プログラム２４は、ＯＳ２３上で動作する業務用アプリケーションプログラムであり、処理要求に応じてＤＢＭＳ１５に問い合わせを行う。
【００３５】
ＤＢＭＳ１５は、業務用データが格納されたデータベース（ＤＢ）を管理する。ＤＢＭＳ１５は、業務プログラム２４からの問い合わせに応じて、ＤＢへアクセスし、問い合わせに対する結果を業務プログラム２４へ提供する。ＤＢＭＳ１５は、業務サーバ１４にインストールされていてもよいし、不図示のＤＢサーバにインストールされていてもよい。
【００３６】
検索端末１６は、通信ネットワーク１７に接続されており、業務システム１１を構築する中継サーバ１３、業務サーバ１４、及びクライアント端末１２と通信することができるコンピュータである。なお、検索端末１６は、問い合わせ元の一例である。
【００３７】
次に、業務システム１１の全体の動作について説明する。クライアント端末１２は、ユーザから入力された業務サーバ１４に対する指示を受け付け、その指示に基づいて、業務サーバ１４に対する処理要求（電文）を発行する。このとき、クライアント端末１２は、電文を識別するため、送信する電文に識別情報（トークン）を含む電文管理情報を付与する。
【００３８】
電文管理情報が付与された電文は、中継サーバ１３を介して業務サーバ１４に送信される。業務サーバ１３は、電文管理情報が付与された電文を受信する。すると、電文管理情報が付与された電文は、通信制御部２１、トランザクション制御部２２を介して業務プログラム２４へ送られる。
【００３９】
業務プログラム２４は、電文管理情報が付与された電文を受け取ると、その電文に対応する処理を行い、処理結果を示す電文（トークンを含む）を端末に応答する。
【００４０】
図３は、本実施形態に係る電文に付加される電文管理情報の一例を示す。電文管理情報は、所定のビット列、トークンＩＤ、属性１〜ｎ、付加情報１〜ｎを含む。
【００４１】
所定のビット列は、当該情報がトークンであることを示す。トークンＩＤは、トークンを識別する識別情報であって、業務システム１１内で一意に設定される。属性は、例えば、業務毎の電文の種類を示す。付加情報は、そのトークンＩＤが設定された電文管理情報が付加された電文を処理したコンポーネントの履歴情報を示す。
【００４２】
次に、電文管理情報の利用方法について説明する。
図４は、本実施形態における電文管理情報が付加された電文が処理されている位置を特定する方法を説明するための図である。電文が業務システム１１内のどこにあるかを知りたい場合には、オペレータは、検索端末１６を用いて、業務システム１１を構築する各コンポーネントに対して、電文の位置についての問い合わせ（情報提供要求）を行う（Ｓ１）。ここで、業務システム１１を構築する各コンポーネントとは、業務システムにおける、端末１２から送信される処理要求を受け付けてから応答するまでの一連の処理（トランザクション）に含まれる処理群、機能群または部品群の総称である。コンポーネントの一例としては、業務プログラムが有する各機能を実現するためのプログラムモジュール、通信制御部２１、トランザクション制御部２２等が挙げられる。更に、コンポーネントの一例としては、クライアント端末１２、中継サーバ１３が挙げられる。
【００４３】
情報提供要求では、トークンに保持されている情報及び／または属性を指定することができる。したがって、情報提供要求にて問い合わせ条件を指定することにより、例えば、指定したトークンＩＤを持つまたは持たない電文、指定した属性を持つまたは持たない電文、トークンを持つ全ての電文等、選択的な電文位置検索が可能となる。図４の例では、検索端末１６は、業務システム１１を構成する各コンポーネントに対して、問い合わせ条件としてトークンＩＤ＝００１が指定された情報提供要求を行っている。
【００４４】
問い合わせ条件（指定したトークンＩＤを持つ／持たない。指定した属性を持つ／持たない。または全ての電文）に合致した場合、そのコンポーネントは、情報提供要求元である検索端末１６に対して、電文位置情報を返却する（Ｓ２）。返却される電文位置情報には、付加情報として電文を処理しているコンポーネントのプログラム実行位置情報や電文転送経路等が付加される。これにより、電文の処理位置や転送経路を調査することが可能となる。
【００４５】
図４の例では、クライアント端末１２から送信された、トークンＩＤ＝００１を有する電文管理情報が付与された電文は、コンポーネントである通信制御部２１にある。この場合、通信制御部２１において、問い合わせ条件に合致するので（指定されたトークンＩＤを持つので）、検索端末１６に対して、電文の位置情報（例えば、コンポーネントＩＤ等）を返却する。
【００４６】
なお、検索端末１６からコンポーネントへ送信される情報提供要求と、コンポーネントから検索端末１６への位置情報の返却は、端末１２−業務サーバ１４間の業務電文の伝送への影響を回避するため、業務電文伝送ルートとは別のルートで伝送する。
【００４７】
次に、各コンポーネントにおける処理について説明する。
図５は、本実施形態におけるコンポーネント単位で行われる処理を説明するための図である。コンポーネント３１毎に、書込みモジュール３２、管理簿３３、位置検索モジュール３４が存在する。
【００４８】
コンポーネント３１は、電文処理経路上におけるシステムを構築するプログラムモジュールであり、例えば、通信制御モジュール、トランザクション制御モジュール、業務アプリケーションモジュール等である。
【００４９】
コンポーネント１において、電文の受信、生成、または消滅により電文の状態が変化すると、書込みモジュール３２は、その電文の状態の変化を検知し、管理簿３３にその電文の電文管理情報を登録する。
【００５０】
位置検索モジュール３４は、検索端末１６から情報提供要求を受信すると、管理簿３３から、情報提供要求に含まれる問い合わせ条件に一致する電文管理情報を検索する。検索の結果、問い合わせ条件に一致する電文管理情報が見つかると、位置検索モジュール３４は、コンポーネント識別情報および付加情報１〜ｎを電文位置情報として問い合わせ元に返却する。
【００５１】
図６は、本実施形態における管理簿の一例を示す。管理簿２３は、トークンＩＤ毎に、電文管理情報を管理する格納部であり、当該管理簿２３と対応するコンポーネントに到達した電文に付加されている電文管理情報が格納されている。管理簿２３にて管理される各電文管理情報には、電文削除情報が追加されている。電文削除情報は、対応する電文が削除または消滅したことを示す情報である。格納部は、クライアント端末１２と中継サーバ１３と業務サーバ１４とにそれぞれ存在する。
【００５２】
図７は、本実施形態における電文の発生に応じて行われる電文管理情報の管理簿への登録処理を説明するための図である。
【００５３】
電文が発生（電文の生成または他コンポーネントからの電文受信）すると（Ｓ１１）、書込みモジュール２１は、電文の発生を検知する（Ｓ１２）。書込みモジュール２１は、その検知した電文に付与されている電文管理情報を管理簿３３に登録する（Ｓ１３）。
【００５４】
図８は、本実施形態における電文の削除に応じて行われる管理簿からの電文管理情報の削除処理を説明するための図である。コンポーネント３１において電文が消滅した場合（Ｓ２１）、書込みモジュール３２は、その電文の消滅を検知する（Ｓ２２）。ここで、電文の消滅の例としては、読み込みセッションがクローズされた場合、電文が読み込まれた領域または管理ブロック（例：ファイルディスクリプタ／データコントロールブロック（ＤＣＢ））が消滅（ＯＳに返却された）場合、または後続電文が生成された場合である。
【００５５】
書込みモジュール３２は、その電文の消滅を検知すると、管理簿３３に、その電文に対応する電文管理情報に電文削除情報を登録する（Ｓ２３）。
【００５６】
書込みモジュール３２は、一定時間経過後または管理簿３３の空き容量が不足した場合は、管理簿３３からログファイル３５に、電文削除情報を有する電文管理情報を出力する（Ｓ２４）。さらに、書込みモジュール３２は、ログファイル３５に出力した電文管理情報を管理簿３３から消去する（Ｓ２４）。これにより、管理簿３３の肥大を防止することができる。
【００５７】
図９は、本実施形態におけるトークンの引継ぎ処理を説明するための図である。電文の受信を受けて、次のシステムまたはコンポーネントに電文を送信する場合、コンポーネント３１は、受信した電文と同一のトークンＩＤを後続電文に付与し、送信する。
【００５８】
トークンを後続電文に渡す場合、コンポーネント３１は、電文生成時に継承元となるトークンを指定することにより行う。トークンを隠蔽する場合（意識させない場合）、コンポーネント３１は、元の電文が記録されている領域のアドレスを後続電文生成時に指定するか、元電文の管理ブロックを後続電文生成時に指定する。
【００５９】
次に、位置検索モジュール３４の処理について説明する。
図１０は、本実施形態における位置検索モジュールの処理フローを示す。位置検索モジュール３４は、情報提供要求を取得すると（Ｓ３１）、その情報提供要求から問い合わせ条件を抽出する（Ｓ３２）。
【００６０】
位置検索モジュール３４は、管理簿３３から、問い合わせ条件に一致する電文管理情報（電文削除情報を有さない）を検索する（Ｓ３３）。管理簿３３に、問い合わせ条件に一致する電文管理情報（電文削除情報を有さない）が登録されていない場合（Ｓ３４で「ＮＯ」）、本フローは終了する。
【００６１】
管理簿３３に、問い合わせ条件に一致する電文管理情報（電文削除情報を有さない）が登録されている場合（Ｓ３４で「ＹＥＳ」）、位置検索モジュール３４は、次の処理を行う。すなわち、位置検索モジュール３４は、自身が担当するコンポーネントのコンポーネント識別情報と、検索された電文管理情報に含まれる付加情報を、問い合わせ元に応答する（Ｓ３５）。
【００６２】
次に、位置検索結果の取得例について説明する。
図１１は、本実施形態における、情報提供要求に応じて問い合わせ元に応答された位置情報の可視化の一例（その１）を示す。図１１では、問い合わせ条件として特定の属性を指定して情報提供を要求し、位置情報が返却された場合の電文の軌跡例を示す。例えば、問い合わせ条件として「オンライン業務Ａを表す属性」が指定されているとする。すると、その情報提供要求を受信したときにその条件に一致する電文を保持しているコンポーネントから、位置情報が返信される。図１１では、そのようにして返信のあったコンポーネントをプロットすることにより、可視化処理がされている。
【００６３】
これにより特定の条件に絞り込んで、電文の滞留状況などを調査／確認することができる。この場合、可視化処理を施すことにより、システムを構成するどのコンポーネントに電文が多く滞留しているかを容易に判断することができる。
【００６４】
図１２は、本実施形態における、情報提供要求に応じて問い合わせ元に応答された位置情報の可視化の一例（その２）を示す。図１２では、全ての電文に対して位置情報を要求し位置情報が返却された場合の電文の軌跡例を示す。この場合も可視化処理を施すことにより、システムを構成するどのコンポーネントに電文が多く滞留しているかを容易に判断できる。
【００６５】
図１３は、本実施形態における、情報提供要求に応じて問い合わせ元に応答された位置情報の可視化の一例（その３）を示す。図１３は、所定時間経過の度に、問い合わせ条件として特定の属性を指定して情報提供を要求し、位置情報が返却された場合の電文の軌跡例を示す。
【００６６】
上記実施形態では、書込みモジュール３２、管理簿３３、及び位置検索モジュール３４の組は、コンポーネント単位で設置したが、これに限定されず、例えば管理簿３３、位置検索モジュール３４についてはサーバ単位で設置してもよい。これについて、図１４を用いて説明する。
【００６７】
図１４は、本実施形態における、サーバ単位での管理簿３３及び位置検索モジュール３４の設置例を説明するための図である。書込みモジュール３２については、コンポーネント毎に設置され、管理簿３３及び位置検索モジュール３４については、サーバ単位で設置されている。
【００６８】
コンポーネント３１と書込みモジュール３２の対は、他の対から独立したメモリ領域に展開されている。それに対して、管理簿３３及び位置検索モジュール３４については、全ての書込みモジュール３２からアクセス可能なように共有メモリに展開されている。
【００６９】
書込みモジュール３２は、対応するコンポーネントの電文の保持状況を監視する。あるコンポーネントにおいて電文が発生した場合、書込みモジュール３２は、そのコンポーネントのコンポーネント識別情報とその電文に付与されているトークンＩＤとの組み合わせを複合キーとし、その電文管理情報を管理簿３３に登録する。
【００７０】
位置検索モジュール３４は、検索端末１６から情報提供要求を受信すると、管理簿３３から、情報提供要求に含まれる問い合わせ条件に一致する電文管理情報を検索する。検索の結果、問い合わせ条件に一致する電文管理情報が見つかると、位置検索モジュール３４は、コンポーネント識別情報および付加情報１〜ｎを電文位置情報として問い合わせ元に返却する。
【００７１】
ここで、管理簿３３及び位置検索モジュール３４の組をコンポーネント単位で設置する場合を、「コンポーネント単位での設置形態」と称する。また、管理簿３３、位置検索モジュール３４の組をサーバ単位で設置する場合を、「サーバ単位での設置形態」と称する。以下では、コンポーネント単位での設置形態とサーバ単位での設置形態とを比較する。
【００７２】
コンポーネントから管理簿への書込処理について、コンポーネント単位での設置形態の場合、負荷が小さい。それに対して、サーバ単位での設置形態の場合、共有メモリ等を使用するための負荷が発生し、コンポーネント単位の設置形態よりも、コンポーネントから管理簿への書込処理の負荷が大きくなる。
【００７３】
電文検索モジュールによる検索処理について、コンポーネント単位での設置形態の場合、コンポーネント毎に位置検索モジュールが位置検索処理を実行するため、負荷はサーバ単位より大きい。また、情報提供要求または回答の通信がコンポーネント毎に発生するので、サーバ単位より通信量が多い。
【００７４】
それに対して、サーバ単位での設置形態の場合、サーバ単位で位置検索モジュールが位置検索処理を実行するため負荷は少ない。また、情報提供要求または回答の通信がサーバ毎に発生するので通信量は少ない。
【００７５】
なお、書込みモジュール、管理簿、位置検索モジュール３４の組の設置形態によって、計算機資源の消費が異なるため、システム要件に合わせて、いずれの設置形態にするかの選択が可能である。
【００７６】
図１５は、本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ４０は、クライアント端末１２、中継サーバ１３、業務サーバ１４等として機能する。コンピュータ４０は、ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４６、通信Ｉ／Ｆ４４、記憶装置４７、出力Ｉ／Ｆ４１、入力Ｉ／Ｆ４５、読み取り装置４８、バス４９、出力機器５１、入力機器５２によって構成されている。
【００７７】
ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス４９には、ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４６、通信Ｉ／Ｆ４４、記憶装置４７、出力Ｉ／Ｆ４１、入力Ｉ／Ｆ４５、及び読み取り装置４８が接続されている。読み取り装置４８は、可搬型記録媒体を読み出す装置である。出力機器５１は、出力Ｉ／Ｆ４１に接続されている。入力機器５２は、入力Ｉ／Ｆ４５に接続にされている。
【００７８】
記憶装置４７としては、ハードディスク、フラッシュメモリ、磁気ディスクなど様々な形式の記憶装置を使用することができる。記憶装置４７またはＲＯＭ４３には、ＣＰＵ４２を応答部３として機能させる本実施形態に係るプログラムが格納されている。ＲＡＭ４６には、情報が一時的に記憶される。記憶装置４７またはＲＡＭ４６は、格納部２として管理情報（例えば、管理簿３３）等を格納する。
【００７９】
ＣＰＵ４２は、制御部２２として、記憶装置４７またはＲＯＭ４３から本実施形態に係るプログラムを読み出し、当該プログラムを実行する。
【００８０】
上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク５０、および通信Ｉ／Ｆ４４を介して、例えば記憶装置４７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置４８にセットされて、ＣＰＵ４２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置など様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置４８によって読み取られる。
【００８１】
また、入力機器５２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレットなどを用いることが可能である。また、出力機器５１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。また、ネットワーク５０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。
【００８２】
上述したように、情報提供要求を送信すると、各コンポーネントからその要求に対応する位置情報がリアルタイムで送信される。すなわち、リアルタイムで電文の位置情報を収集できるので、時間経過に伴う位置情報の累積収集も容易となる。累積した位置情報を可視化処理等（グラフ化やアニメーション化等）することにより、滞留箇所等の判断を容易にしたり、第三者への説明を分かりやすくすることができる。
【００８３】
本実施形態によれば、システム上を往来する電文に識別情報及びトレース情報（その電文がコンポーネントを通過する度に付与されるそのコンポーネント名）を付与する。システム上の各コンポーネントは、その電文を受け取ると、そのコンポーネントが管理する管理簿へその識別情報及びトレース情報を登録する。登録された識別情報及びトレース情報は、そのコンポーネントがその電文を保持している間登録されているが、そのコンポーネントがその電文を保持していない場合には管理簿からその電文に対応する識別情報及びトレース情報を削除する。
【００８４】
そして、電文位置の問い合わせのための電文位置情報提供要求を全てのコンポーネントに行い、問い合わせ条件に一致する電文を保持しているコンポーネントが電文位置情報を応答することにより、電文処理位置を特定することができる。これにより、リアルタイム性の高い電文位置検知ができる。
【００８５】
本実施形態によれば、電文の位置の特定のために電文ログの解析を行わず、各コンポーネントからの情報提供要求に対応する位置情報を収集することにより、リアルタイム性の高い電文の位置の検知が実現することができる。
【００８６】
また、電文の属性等を問い合わせ条件として指定することにより電文のスクリーニングができる。そのため、システム全体の電文の流れから特定の業務等の電文の状態を特定できる。
【００８７】
また、リアルタイムで電文の状態が分かるため、システム内の滞留などの電文状況を監視できる。また、電文伝送ルートの解析も容易となるため正しいルートで処理しているか内部統制監視としても利用できる。
【００８８】
システムパラメタの妥当性（設計時に想定した性能が出るかを確認する）を実際に確認する場合も、電文ログの解析無しで、滞留等の電文状態を確認することができる。その結果、トライアンドエラーによるシステムパラメタの調整が容易になる。
【００８９】
なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
【符号の説明】
【００９０】
１      電文所在検索システム
２      格納部
３      応答部
１１    業務システム
１２    クライアント端末
１３    中継サーバ
１４    業務サーバ
１５    ＤＢＭＳ
１６    検索端末
１７    通信ネットワーク
２１    通信制御部
２２    トランザクション制御部
２３    ＯＳ
２４    業務プログラム
【図１】
2016143317.tif 000003
【図２】
2016143317.tif 000004
【図３】
2016143317.tif 000005
【図４】
2016143317.tif 000006
【図５】
2016143317.tif 000007
【図６】
2016143317.tif 000008
【図７】
2016143317.tif 000009
【図８】
2016143317.tif 000010
【図９】
2016143317.tif 000011
【図１０】
2016143317.tif 000012
【図１１】
2016143317.tif 000013
【図１２】
2016143317.tif 000014
【図１３】
2016143317.tif 000015
【図１４】
2016143317.tif 000016
【図１５】
2016143317.tif 000017