JP4647352B2

JP4647352B2 - 電文処理システムの正常性確認システム、装置、方法及びプログラム

Info

Publication number: JP4647352B2
Application number: JP2005067407A
Authority: JP
Inventors: 茂和猪原
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2005-03-10
Filing date: 2005-03-10
Publication date: 2011-03-09
Anticipated expiration: 2025-03-10
Also published as: JP2006252151A

Description

本発明は、複数の装置が電文を送受信しながら協調して動作する電文処理システムの動作の正常性を確認するための技術に関する。

複数のサーバなどの装置が協調して動作する大規模コンピュータシステムに、新たにサーバを設置して、このサーバにプログラムのインストール、初期設定などを自動的に行うプロビジョニング技術が知られている（例えば特許文献１）。
特開平２−２０１６５７号公報

しかしながら、プロビジョニングによって自動的に追加されたサーバを実際に稼動させる（リリースする）ためには、以下のようなことを確認しなければならない。例えば、追加されたサーバが単独で正常に動作をするか否かや、追加されたサーバを経由したときにシステム全体として正常に動作するか否かなどをテストして確認する必要がある。これらは、従来、テスト実施者が作成したテストデータを流し、その結果をテスト実施者が確認しているため、網羅性に欠けるものであったり、見誤りがあったりして、完璧を期しがたいものであった。

さらには、プロビジョニングによって同時に複数のサーバが追加されると、従来はこれらを一括してリリースしていた。この結果、新たにリリースしたサーバのうちの複数で同時に不具合が発生すると、システム全体に与える影響が大きい。

そこで、本発明の目的は、複数のサーバなどの装置が協調して動作するシステムの正常性確認を自動的に行うための技術を提供することである。

本発明の一実施態様に従う、電文処理システムと、前記電文処理システムの正常性確認装置とを備えた電文処理システムの正常性確認システムでは、前記電文処理システムは、複数のインタフェース装置と複数の内部装置とを備え、前記複数のインタフェース装置のそれぞれは、リクエスト電文を受け付けて、前記リクエスト電文と関連づけられた第１の内部電文を、前記複数の内部装置のいずれかに対して出力する手段と、前記複数の内部装置のいずれかから第２の内部電文を受け付けて、前記第２の内部電文に関連するリプライ電文を出力する手段と、前記リクエスト電文及び前記リプライ電文に関するログデータを記憶した記憶手段とを備える。前記複数の内部装置のそれぞれは、前記第１の内部電文を受信して所定の処理を実行し、前記第１の内部電文と関連づけられた前記第２の内部電文を生成し、出力する手段と、前記受信した第１の内部電文及び前記出力した第２の内部電文に関するログデータを記憶した記憶手段とを備える。前記管理装置は、前記複数のインタフェース装置及び前記複数の内部装置にそれぞれ記憶されている、各電文に関するログデータを収集する手段と、前記収集手段が収集した各電文に関するログデータ同士を、それぞれの電文に予め含まれている電文識別子に基づいて対応づけ、前記電文処理システムの正常性の確認を行う正常性確認手段と、前記正常性確認手段による整合性の確認結果を出力する手段と、を備える。

好適な実施形態では、前記複数のインタフェース装置のそれぞれは、受け付けたリクエスト電文に電文識別子を付与する手段を備える。そして、前記第１の内部電文は、関連づけられているリクエスト電文に付与されている電文識別子と同一の電文識別子を有し、前記第２の内部電文は、関連づけられている第１の内部電文に付与されている電文識別子と同一の電文識別子を有するようにしてもよい。

好適な実施形態では、前記複数の内部装置は、第１のグループと第２のグループのいずれかに属しており、前記第１のグループに属する第１の内部装置は、前記一のインタフェース装置から前記第１の内部電文を受信し、受信した第１の内部電文に関連づけられている第３の内部電文を出力する手段と、前記第２のグループに属する第２の内部装置から第４の内部電文を受信し、受信した第４の内部電文と関連づけて前記第２の内部電文を生成して前記一のインタフェース装置へ送信する手段と、を備える。そして、前記第１の内部装置の記憶手段には、前記第１の内部電文及び前記第２の内部電文に関するログデータが記憶されていて、前記第２の内部装置は、前記第１の内部装置から前記第３の内部電文を受信し、受信した第３の内部電文と関連づけられている前記第４の内部電文を前記第１の内部装置へ送信する手段を備える。前記第２の内部装置の記憶手段には、前記第３の内部電文及び前記第４の内部電文に関するログデータが記憶されていて、前記管理装置の収集手段は、前記インタフェース装置、前記第１の内部装置及び前記第２の内部装置のそれぞれからログデータを収集してもよい。

好適な実施形態では、前記管理装置の解析手段は、所定の電文識別子を有する電文のログデータを抽出し、抽出されたログデータに、リクエスト電文、リプライ電文、及び第１〜第４の内部電文のすべてのログデータが含まれているか否かを判定するようにしてもよい。

好適な実施形態では、前記管理装置の解析手段は、前記抽出されたログデータを解析し、前記第１の内部電文を受信した第１の内部装置と前記第４の内部電文を受信した第１の内部装置が同一であるか否か、及び、前記リクエスト電文を受信したインタフェース装置と前記第２の内部電文を受信したインタフェース装置とが同一であるか否かを判定するようにしてもよい。

好適な実施形態では、前記管理装置は、リクエスト電文のタイプと、それに対して前記電文処理システムから出力されるべきリプライ電文のタイプとを対応付けて登録する手段をさらに有する。そして、前記管理装置の解析手段は、前記抽出されたログデータに含まれるリクエスト電文及びリプライ電文のログデータが、前記登録手段により登録されたリクエスト電文及びリプライ電文のタイプと合致するか否かを判定するようにしてもよい。

本発明の一つの実施態様に従う電文処理システムの管理装置は、複数のインタフェース装置と複数の内部装置とを備え、前記複数のインタフェース装置のうちの一のインタフェース装置がリクエスト電文を受け付け、前記複数の内部装置のうちの一つ以上が前記リクエスト電文に関連する第１の内部電文を受信すると、これに基づく所定の処理を実行して第２の内部電文を出力し、前記一のインタフェース装置が前記第２の内部電文を受信すると、これに基づいて前記リクエスト電文に対するリプライ電文を出力する電文処理システムの管理装置であって、前記複数のインタフェース装置及び前記複数の内部装置のそれぞれに蓄積されている、前記リクエスト電文、前記リプライ電文、第１の内部電文または第２の内部電文に関するログデータを収集する手段と、前記収集手段が収集したログデータを、それぞれの電文に含まれている電文識別子に基づいて分類する手段と、前記分類手段による分類結果を出力する手段と、を備える。

以下、本発明の一実施形態に係るアプリケーションシステム及びその管理を行う管理装置（管理サーバ）について、図面を参照して説明する。

図１は、本実施形態に係るシステムの全体構成を示す図である。本システムは、所定の業務処理を実行するアプリケーションシステム１と、顧客が使用するクライアント２とがネットワーク９を介して接続されている。そして、アプリケーションシステム１には、このシステムを管理するための管理サーバ１５が接続されている。

アプリケーションシステム１は、クライアント２からのリクエストを振り分けて負荷分散をするロードバランサ１０と、クライアント２に対する入出力インタフェースを提供する複数のＰＬサーバ１１を含むＰＬサーバ群１１Ａと、様々な業務処理（ビジネスロジック、ＢＬ）を実行する複数のＢＬサーバ１２を含むＢＬサーバ群１２Ａ（第１のグループ）と、データベース１３１４の参照、更新などを行う複数のＤＢサーバ１３を含むＤＢサーバ群１３Ａ（第２のグループ）と、データベース（ＤＢ）１４とを備える。ＰＬサーバ１１が、クライアント２へ表示する画面の制御（プレゼンテーションロジック、ＰＬ）などのインタフェースを提供するインタフェース装置である。ＢＬサーバ１２（第１の装置）及びＤＢサーバ１３（第２の装置）が、アプリケーションシステム１の内部処理を実行する内部装置である。

クライアント２、各ＰＬサーバ１１、各ＢＬサーバ１２、各ＤＢサーバ１３および管理サーバ１５は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ等２，１１，１２，１３，１５内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。

ＰＬサーバ群１１Ａの各ＰＬサーバ１１，ＢＬサーバ群１２Ａの各ＢＬサーバ１２及びＤＢサーバ群１３Ａの各ＤＢサーバ１３は、それぞれ共通の構成を備え、同じ処理を実行するようになっている（図２参照）。つまり、サーバ群１１Ａ，１２Ａ，１３Ａがそれぞれ複数のサーバにより多重化されている。これは、耐障害性及び処理性能を確保するためである。そして、各サーバ群１１Ａ，１２Ａ，１３Ａの中では、それぞれどのサーバに処理を実行させても、同じ処理が行われる。この結果、各ＰＬサーバ１１，各ＢＬサーバ１２及び各ＤＢサーバ１３を、それぞれ比較的安価なパーソナルコンピュータなどを用いて実現するとともに、ロードバランサ１０によって負荷分散することにより、本システム１は、高額の高速コンピュータを導入することなく、低コストでハイパフォーマンスを得ることができる。さらには、本システムは、処理するデータ量の増減に伴って、各サーバ１１，１２，１３の台数を容易に増減させることができ、これにより容易に処理能力を調整することができる。本実施形態では、管理サーバ１５が、アプリケーションシステム１がシステムの動作の正常性を確認し、新たに追加されたサーバ１１，１２，１３をテストするための処理を実行し、そのサーバをリリースするための処理を実行する。

なお、本システムにおけるＰＬサーバ１１の台数、ＢＬサーバ１２の台数、及びＤＢサーバ１３の台数は、同じ台数でもよいし、それぞれ異なる台数でもよい。

アプリケーションシステム１では、クライアント２からのリクエストがＰＬサーバ群１１Ａ、ＢＬサーバ群１２Ａ、及びＤＢサーバ群１３Ａの順に伝達され、このリクエストに対するリプライがＤＢサーバ群１３ＡからＢＬサーバ群１２Ａ、ＰＬサーバ群１１Ａへと伝達されて、クライアント２へ送信される。詳細に説明すれば、リクエスト及びリプライは、例えば以下のように伝達される。

ＰＬサーバ群１１Ａは、前段であるクライアント２からリクエスト電文２１（図２参照）を受け付けると、１台のＰＬサーバ１１が所定の処理を実行後、後段のＢＬサーバ群１２Ａに対するサーバ間リクエスト電文Ａ２３（図２参照）を生成して、出力する。

ＢＬサーバ群１２Ａは、前段のＰＬサーバ群１１Ａからサーバ間リクエスト電文Ａ２３を受け付けると、１台のＢＬサーバ１２が所定の処理を実行後、後段のＤＢサーバ群１３Ａに対するサーバ間リクエスト電文Ｂ２５（図２参照）を生成して、出力する。

ＤＢサーバ群１３Ａは、前段のＢＬサーバ群１２Ａからサーバ間リクエスト電文Ｂ２５を受け付けると、１台のＤＢサーバ１３がＤＢ１４に対する所定の処理を実行する。そして、前段のＢＬサーバ群１２Ａに対するサーバ間リプライ電文Ｂ３５（図２参照）を生成して、出力する。

ＢＬサーバ群１２Ａでは、１台のＢＬサーバ１２が後段のＤＢサーバ群１３Ａからのサーバ間リプライ電文Ｂ３５に基づいて、前段のＰＬサーバ群１１Ａに対するサーバ間リプライ電文Ａ３３（図２参照）を生成して、出力する。

ＰＬサーバ群１１Ａでは、１台のＰＬサーバ１１が後段のＢＬサーバ群１２Ａからのサーバ間リプライ電文Ａ３３に基づいて、前段のクライアント２に対するクライアントリプライ電文３１（図２参照）を生成して、出力する。

図２には、ＰＬサーバ１１，ＢＬサーバ１２及びＤＢサーバ１３の詳細な構成図を示す。

ＰＬサーバ１１は、ロードバランサ１０を介してクライアント２から送られてくるクライアントリクエスト電文２１を受信し、これをサーバ間リクエスト電文Ａ２３に変換していずれかのＢＬサーバ１２へ出力する。また、いずれかのＢＬサーバ１２からサーバ間リプライ電文Ａ３３を受信すると、これをクライアントリプライ電文３１に変換して、ロードバランサ１０を介してクライアント２へ送信する。

ＰＬサーバ１１は、同図（ａ）に示すように、電文識別子付与部１１１と、ＰＬ処理部１１３と、ステータス記憶部１１４と、電文記録部１１５と、ＰＬログ１１７とを備える。

電文識別子付与部１１１は、クライアントリクエスト電文２１を受信すると、これに電文識別子を付与する。電文識別子は、それぞれのＰＬサーバ１１が生成するユニークな数字または文字列等である。例えば、ＰＬサーバ１１に割り当てられているＩＰアドレスと、そのサーバ１１内でのカウンタ値（シリアル番号）とを組み合わせて、電文識別子を生成してもよい。

ＰＬ処理部１１３は、クライアントリクエスト電文２１及びサーバ間リプライ電文Ａ３３に従って、所定の処理を実行する。例えば、クライアントリクエスト電文２１に対しては、その電文に含まれるデータの整合性チェックなどを行い、サーバ間リクエスト電文Ａ２３を生成する。ここで、サーバ間リクエスト電文Ａ２３に、電文識別子付与部１１１によってクライアントリクエスト電文２１に付与された電文識別子が付与され、クライアントリクエスト電文２１とサーバ間リクエスト電文Ａ２３とが関連づけられる。また、サーバ間リプライ電文Ａ３３に対しては、クライアント２に表示される画面（Ｗｅｂページ）の合成を行い、それを含むクライアントリプライ電文３１を生成する。ここで、サーバ間リプライ電文Ａ３３に付与されている電文識別子が、クライアントリプライ電文３１には含まれない。しかし、電文記録部１１５がＰＬログ１１７に格納するクライアントリプライ電文３１のログデータには付与される。

ステータス記憶部１１４については後述する。

電文記録部１１５は、クライアントリクエスト電文２１を受信したとき、及びクライアントリプライ電文３１を出力するときに、それぞれの電文２１，３１の電文識別子を含む、各電文に関連する情報をＰＬログ１１７に格納する。

図３に、ＰＬログ１７のデータ構造の一例を示す。ＰＬログ１１７には、ＰＬサーバ１１がクライアント２に対して送受信した電文の送受信履歴が記憶されている。例えば、ＰＬログ１１７は、データ項目として、電文識別子５１と、送信サーバ名５２と、受信サーバ名５３と、電文内容５４とを有する。

図２（ｂ）には、ＢＬサーバ１２の構成を示す。ＢＬサーバ１２は、ＰＬサーバ１１から送られてくるサーバ間リクエスト電文Ａ２３を受信し、これをサーバ間リクエスト電文Ｂに変換して、いずれかのＤＢサーバ１３へ出力する。また、いずれかのＤＢサーバ１３からサーバ間リプライ電文Ｂ３５を受信すると、これをサーバ間リプライ電文Ａ３３に変換して、ＰＬサーバ１１へ送信する。なお、サーバ間リプライ電文Ａ３３の送信先は、サーバ間リクエスト電文Ａ２３の送信元のＰＬサーバ１１である。

ＢＬサーバ１２は、内部の構成として、ＢＬ処理部１２３と、ステータス記憶部１２４と、電文記録部１２５と、ＢＬログ１２７とを備える。

ＢＬ処理部１２３は、サーバ間リクエスト電文Ａ２３及びサーバ間リプライ電文Ｂ３５に従って、所定の処理を実行する。例えば、サーバ間リクエスト電文Ａ２３を受信したときは、その電文の内容に従って所定の業務処理を実行し、サーバ間リクエスト電文Ｂ２５を生成する。ここで、サーバ間リクエスト電文ＡＢ２５には、サーバ間リクエスト電文Ａ２３に付与されている電文識別子が付与され、サーバ間リクエスト電文Ａ２３とサーバ間リクエスト電文ＡＢ２５とが関連づけられる。また、サーバ間リプライ電文Ａ３３Ｂ３５を受信したときは、その電文の内容に従って所定の業務処理を実行し、サーバ間リプライ電文Ａ３３を生成する。この場合も同様に、サーバ間リプライ電文Ａ３５Ａ３３には、サーバ間リプライ電文３３Ｂ３５に付与されている電文識別子が付与され、サーバ間リプライ電文Ａ３３とサーバ間リプライ電文ＡＢ３５とが関連づけられる。

ステータス記憶部１２４については後述する。

電文記録部１２５は、サーバ間リクエスト電文Ａ２３を受信したとき、及びサーバ間リプライ電文Ａ３３を出力するときに、それぞれの電文２３，３３の電文識別子を含む、各電文に関連する情報をＢＬログ１２７に格納する。

ＢＬログ１２７には、ＢＬサーバ１２がＰＬサーバ１１に対して送受信した電文の送受信履歴が記憶されている。ＢＬログ１２７のデータ構造は、ＰＬログ１１７と共通である。

図２（ｃ）には、ＤＢサーバ１３の構成を示す。ＤＢサーバ１３は、ＢＬサーバ１２から送られてくるサーバ間リクエスト電文Ｂ２５を受信し、これに基づいてＤＢ１４の参照、更新などのＤＢ処理を実行する。そして、この実行結果に基づいてサーバ間リプライ電文Ｂ３５を生成し、これをサーバ間リクエスト電文Ｂ２５の送信元のＢＬサーバ１３１２へ送信する。

ＤＢサーバ１３は、内部の構成として、ＤＢ処理部１３３と、ステータス記憶部１３４電文記録部１３５と、ＤＢログ１３７とを備える。

ＤＢ処理部１３３は、サーバ間リクエスト電文Ｂ２５を受信すると、その電文の内容に従ってＤＢ１４の参照、更新などの処理を実行する。そして、その処理結果に基づいてサーバ間リプライ電文Ｂ３５を生成する。ここで、サーバ間リプライ電文Ｂ３５には、サーバ間リクエスト電文Ｂ２５に付与されている電文識別子が付与され、サーバ間リプライ電文Ｂ３５とサーバ間リクエスト電文Ｂ２５とが関連づけられる。

ステータス記憶部１３４については後述する。

電文記録部１３５は、サーバ間リクエスト電文Ｂ２５を受信したとき、及びサーバ間リプライ電文Ｂ３５を出力するときに、それぞれの電文２５，３５の電文識別子を含む、各電文に関連する情報をＤＢログ１３７に格納する。

ＤＢログ１３７には、ＤＬＤＢサーバ１３がＢＬサーバ１２に対して送受信した電文の送受信履歴が記憶されている。ＤＢログ１３７のデータ構造は、ＰＬログ１１７及びＢＬログ１２７と共通である。

ここで、図４にそれぞれの電文フォーマットを示す。同図（ａ）に示すように、クライアントリクエスト電文２１は、ＨＴＭＬなどで記述されたクライアントリクエスト本文を含んでいる。同図（ｂ）に示すように、クライアントリプライ電文３１は、ＨＴＭＬなどで記述されたクライアントリプライ本文を含んでいる。同図（ｃ）に示すサーバ間リクエスト電文２３、２５には、それぞれのリクエスト内容を示すサーバ間リクエスト本文と、電文識別子とが含まれ、同様に同図（ｄ）に示すサーバ間リプライ電文３３、３５には、それぞれのリプライ内容を示すサーバ間リプライ本文と、電文識別子とが含まれる。

図５に、管理サーバ１５の構成図を示す。管理サーバ１５には、キーボードまたはポインティングデバイスなどの入力装置７と液晶ディスプレイなどの表示装置８が接続されている。そして、管理サーバ１５は、外部インタフェースとして、これらの入出力装置を制御する入出力装置制御部１５３と、アプリケーションシステム１とのインタフェースであるシステムインタフェース１５１とを有する。

管理サーバ１５は、各サーバ１１，１２，１３からログデータを収集し、その解析などを行う。さらに、管理サーバ１５は、プロビジョニングなどによりアプリケーションシステム１に自動的に配備されたサーバ１１，１２，１３に対し、テストデータの生成、テストの実行及びテスト結果の検証などの自動テスト処理を行う。さらに、管理サーバ１５は、プロビジョニングにより配備されたサーバ１１，１２，１３を実際に稼働させるリリース制御を行う。

これらの機能を実現するために、管理サーバ１５は、例えば、以下のような構成を備える。管理サーバ１５は、まず、主にログの処理に関する構成として、ログデータ収集部１６１と、収集したログを保存しておく収集ログ記憶部１６３と、収集したログデータを解析するログデータ解析部１６５とを備える。また、管理サーバ１５は、主に自動テストのための構成として、ユーザ登録部１７１と、登録情報記憶部１７２と、テストデータ生成部１７３と、テストデータ記憶部１７４と、テスト実行部１７５と、テスト結果記憶部１７６と、テスト結果処理部１７７と、ＤＢ設定変更部１７８とを備える。そして、主にリリース制御に関する構成として、リリース管理部１８１と、リリース条件表１８２と、ステータステーブル表１８３とを備える。以下、各構成について詳細に説明する。

ログデータ収集部１６１は、システムインタフェース１５１を介して、アプリケーションシステム１の各サーバ１１，１２，１３がそれぞれ保持しているログデータを収集し、収集ログ記憶部１６３に格納する。

図６に収集ログ記憶部１６３に記憶されているログデータの一例を示す。収集ログ記憶部１６３のデータ項目は、ＰＬログ１１７、ＢＬログ１２７及びＤＢログ１３７と同一である。収集されたログデータには、クライアントリクエスト電文２１，クライアントリプライ電文３１，サーバ間リクエスト電文２３，２５及びサーバ間リプライ電文３３，３５のすべてのすべてのログが含まれているが、それらは互いに電文識別子５１により関連づけが可能である。例えば、図６のレコード１６３ａ〜ｆは、いずれも電文識別子５１が共通であるから、一つのクライアントリクエスト電文２１及びそれから派生した各電文のログであることがわかる。さらに、この例では、送信サーバ名５２及び受信サーバ名５３により、レコード１６３ａがクライアントリクエスト電文２１，レコード１６３ｂがサーバ間リクエスト電文Ａ２３，レコード１６３ｃがサーバ間リクエスト電文Ｂ２５，レコード１６３ｄがサーバ間リプライ電文Ｂ３５，レコード１６３ｅがサーバ間リプライ電文Ａ３３，及びレコード１６３ｆがクライアントリプライ電文３１であることがわかる。

なお、各リプライ電文３１，３３，３５は、各リクエスト電文２１，２３，２５が通ったＰＬサーバ及び、ＢＬサーバ及びＤＢサーバと同一のＰＬサーバ及び、ＢＬサーバ及びＤＢサーバを通るようになっている。つまり、同じ電文識別子を有する電文は、ＰＬサーバからＤＢサーバへ向かう昇り方向とＤＢサーバからＰＬサーバへ向かう下り方向とでは、同一のパスを通る。

ログデータ解析部１６５は、収集ログ記憶部１６３に格納されているログデータを解析し、アプリケーションシステム１の動作の正常性の確認をする。例えば、ログデータ解析部１６５は、電文識別子５１をキーにして収集したログデータのレコードをソートし、あるいは、同一の電文識別子５１を有する複数のレコードを１グループとしてまとめる。さらに、ログデータ解析部１６５は、同一の電文識別子５１を有するレコード間で、電文内容５４の整合性チェックを行う。そして、これらの解析結果を、入出力装置制御部１５３が表示装置８に表示する。

図７は、ログデータ解析部１６５がログデータの各レコードを電文識別子５１でソートした結果の一例を示す図である。

図８は、ログデータ解析部１６５によって抽出された電文識別子「192.168.0.102-0845」のレコード群を示す。ログデータ解析部１６５は、このレコード群に対して、さらに、整合性チェックを行う。例えば、「送信サーバ名５２→受信サーバ名５３」のペアにおいて、「client→ＰＬ*」「ＰＬ*→ＢＬ*」「ＢＬ*→ＤＢ*」「ＤＢ*→ＢＬ*」「ＢＬ*→ＰＬ*」「ＰＬ*→client」のすべてが存在することを確認する。これにより、入力されたクライアントリクエスト電文２１が途中で消失せずに、最終的なクライアントリプライ電文３１を返しているか否かを確認できる。

さらに、昇り電文と下り降り電文では同一パスを経由するようになっているため、ログデータ解析部１６５は、ＰＬサーバ及びＢＬサーバのサーバ名が同一であるか否かをチェックする。また、電文内容５４において、特定のパラメータに同一の値が設定されているか（例えばkozaID=1234567）などをチェックする。これにより、入力されたクライアントリクエスト電文２１の内容が、その後生成される各電文に受け継がれているかを確認できる。

また、ログデータ解析部１６５は、予め登録されている電文確認表６０を参照し、同一電文識別子１７１５１を有するレコード群が、この表６０に登録されているリクエスト電文とリプライ電文の対応パターンに合致するか否かを判定する。電文確認表６０は、予めユーザによって登録されて、登録情報記憶部１７２に格納されている。

図９に、電文確認表６０の一例を示す。電文確認表６０は、対象サーバ６１と、対象サーバ６１が受信するリクエスト電文内容６２と、対象サーバが出力するリプライ電文内容６３とが対応付けられている。一つのリクエスト電文内容６２に対して、生じ得るリプライ電文内容６３は複数存在することがある。図９の場合、ＰＬサーバに対するリクエスト電文内容６０１に対するリプライとしては、リプライ電文内容６１１〜６１３があり得ることを示している。また、ＢＬサーバが受信するリクエスト電文内容６０２に対するリプライとしては、リプライ電文内容６１４，６１５があり得ることを示している。さらに、ＤＢサーバのリクエスト電文内容６０３に対するリプライとしては、リプライ電文内容６１６，６１７があり得ることを示している。

そして、ログデータ解析部１６５は、同じ電文識別子５１を有するレコードの中から、ＰＬサーバが受信したクライアントリクエスト電文２１のレコード（つまり、送信サーバ５２がクライアント、受信サーバ５３がＰＬサーバであるレコード１６１１６３ａ）と、クライアントリプライ電文３１のレコード（つまり、送信サーバ５２がＰＬサーバ、受信サーバ５３がクライアントであるレコード１６１１６３ｆ）を抽出する。そして、ここで抽出したレコードのペアが、電文確認表６０のリクエスト電文内容６０１とリプライ電文内容６１１〜６１３のペアのいずれかに合致するかを判定する。

ログデータ解析部１６５は、ＢＬサーバに対するリクエスト及びリプライのペア、とＤＢサーバに対するリクエスト及びリプライのペアについても同様に抽出し、電文確認表６０に登録されているペアと合致するか否かを判定する。

これにより、各リクエスト電文に対し、予め定められている所定のリプライ電文が生成されているか否かを確認できる。

次に、再び図５を参照し、自動テスト処理に関する構成及び処理について説明する。

ユーザ登録部１７１は、入力装置７を用いてユーザが入力するユーザ設定情報の登録を受け付ける。ユーザ登録部１７１が受け付けたユーザ設定情報は、登録情報記憶部１７２及びリリース条件表１８２に登録される。

登録情報記憶部１７２には、ユーザが設定した情報が記憶されている。図５の場合、ユーザ設定情報として、既に説明した電文確認表６０と、テストデータに設定されるパラメータ値が記憶されているパラメータ表７０と、テンプレート８０と、ＤＢ設定表９０とが記憶されている。

図１０には、パラメータ表７０の一例を示す。すなわち、パラメータ表７０は、クライアントリクエスト電文２１に含まれるパラメータ７０７１と、それに設定される複数のパラメータ値７２とが対応付けて登録されている。

図１１には、テンプレート８０の例を示す。すなわち、同図（ａ）には、送受信サーバを特定する通信パターン８１ごとに、入力リクエスト電文８２とそれに対する生成リプライ電文８３とが対応付けられているテンプレートＡを示す。例えば、テスト対象サーバに入出力する電文を同図（ｃ）に示すようにＸ，Ｙ，Ｚ，Ｗとすれば、テンプレートＡでは、ＸとＷとの対応関係が示されている。また、同図（ｂ）には、送受信サーバを特定する通信パターン８５ごとに、あるサーバの前段に対する電文８４と後段に対する電文８６とが対応付けられているテンプレートＢを示す。例えば同図（ｃ）と対応させると、前段に対する電文８４がＸまたはＷであり、後段に対する電文８６がＹまたはＺであり、ＸとＹまたはＷとＺがそれぞれ対応付けられている。

図１２には、ＤＢ設定表９０の一例を示す。ＤＢ設定表９０には、同図（ａ）に示すデータ設定表９０１と同図（ｂ）に示すデータ戻し表９０２とがある。データ設定表９０１及びデータ戻し表９０２は、いずれも、値を設定する表名９１と、値を設定する条件９２と、値を設定する列名９３と、設定値９４とを、データ項目として有する。

テストを実行する場合、所定の条件下でテストを実行するために、ＤＢ１４の設定を一時的に変更したいときがある。このような場合のために、データ設定表９０１の設定値９４にはユーザが入力した値が記憶されている。また、ＤＢ１４の設定を一時的に変更してテストを実行した後は、その設定を元に戻す必要がある。そこで、データ戻し表９０２の表名９１、条件９２及び列名９３には、設定を変更する際の表名、条件及び列名が記憶されるとともに、設定値９４には、設定を変更する際に取得した変更前のＤＢ１４の値が記憶される。

テストデータ生成部１７３は、パラメータ表７０、テンプレート８０及び収集ログ記憶部１６３に格納されているログデータに基づいてテストデータを生成し、テストデータ記憶部１７４に格納する。例えば、テンプレート８０に含まれているパラメータに、パラメータ表７０に設定されているパラメータ値７２を優先させて設定し、パラメータ表７０にパラメータ値が設定されていないパラメータについては、ログデータから抽出して設定する。これにより、テスト実施者は、自らが着目するパラメータについてだけパラメータ値を登録しておけばよい。この場合、特に着目しないパラメータについてはログデータから自動設定される。従って、テンプレート８０内のすべてのパラメータに値が設定されるので、テストデータの不備によりテストが滞ってしまうようなことがない。

一方、パラメータ表７０にすべてのパラメータの値が設定されていれば、ログデータは不要である。また、パラメータ表７０がないとき、あるいはパラメータ表７０にはパラメータ値が何も設定されていないときは、ログデータからすべてのパラメータ値を取得してテストデータを生成してもよい。

本実施形態では、まず、テンプレートＡ、パラメータ表７０及びログデータに基づいて中間的なテストデータであるテストデータＡ（図１３参照）が生成される。そして、テストデータＡとテンプレートＢに基づいて最終的なテストデータであるテストデータＢ（図１４参照）が生成される。以下、具体的に説明する。

まず、図１１（ａ）のテンプレートＡは、各サーバに対するリクエスト電文（Ｘ）と各サーバから出力され得るリプライ電文（Ｗ）とのペアを定義している。そこで、テストデータ生成部１７３は、テンプレートＡの各パラメータに図１０に示すパラメータ表７０に登録されている値を設定する。この例では、支店ＩＤ（sitenID）、口座ＩＤ（kozaID）、パスワード（passward）、口数（item_count）及び残高（zandaka）に、パラメータ表７０に登録されているそれぞれの値がセットされる。

この段階では、テンプレートＡにおけるパラメータitemには値がセットされていない。そこで、テストデータ生成部１７３は、パラメータitemに設定すべき値を、ログデータのいずれかのレコードから抽出してセットする。このようにして、図１３に示すテストデータＡが生成される。

図１３のテストデータＡは、サーバＡ４０１からサーバＢ４０２へのリクエスト電文（Ｘ）４０３及びそのリクエスト電文（Ｘ）４０３に対するサーバＢからサーバＡへのリプライ電文（Ｗ）４０４からなる。図１３の例では、テストデータ４３１及び４３２は、のリクエスト電文（Ｘ）４０３は共通であり、これに対するリプライ電文（Ｗ）４０４として異なるパターンがセットされたものである。

次に、図１１（ｂ）のテンプレートＢは、リクエスト電文（Ｘ）とそれにより生成される後段へのリクエスト電文（Ｙ）、及びリプライ電文（Ｗ）とそれが生成される前の後段からのリプライ電文（Ｚ）とのペアを定義している。そこで、テストデータ生成部１７３は、テンプレートＢに図１３のテストパターンＡのリクエスト電文（Ｘ）４０３及びリプライ電文（Ｗ）４０４を適用し、それぞれに対応する電文Ｙ，Ｚを生成する。このとき、テストパターンＡにおいて既に設定されているパラメータは、それぞれ対応する電文Ｙ，Ｚに設定される。この処理により生成されたテストデータＢを図１４に示す。

図１４のテストデータＢは、テスト対象サーバ４１１に対するリクエスト電文（Ｘ）４１２と，これに対応するリプライ電文（Ｗ）４１３と、後段に対するリクエスト電文（Ｙ）４１４と、後段からのリプライ電文（Ｚ）４１５とがワンセットになっている。ここで、テストデータ４４１，４４２，４４３はいずれもリクエスト電文（Ｘ）４１２は共通である。これは、同じリクエスト電文（Ｘ）４１２を入力した場合でも、そこから派生する電文Ｙ，Ｚ，Ｗについては複数のパターンが生じ得るので、正常に動作する場合のすべてのパターンが用意されているからである。

テストデータ記憶部１７４には、上記のようにして生成されたテストデータＢが記憶される。

テスト実行部１７５は、テストデータ記憶部１７４からテストデータを取得してテストを実行し、そのテスト結果をテスト結果記憶部１７６に格納する。例えば、テスト実行部１７５は、テストデータ記憶部１７４からテストデータＢのテストデータを１つずつ読み出し、システムインタフェース１５１を介して、テスト対象サーバ４１１にリクエスト電文（Ｘ）４１２を入力する。テスト対象サーバ４１１は、リクエスト電文（Ｘ）４１２が入力されると、この電文４１２に基づいて所定の処理を実行する。その結果、テスト対象サーバ４１１から後段のサーバへリクエスト電文（Ｙ）が出力され、後段の各サーバもこれに従って動作する。そして、最終的にテスト対象サーバからリプライ電文（Ｗ）が出力される。ここで、テスト実行部１７５は、入力したリクエスト電文（Ｘ）４１２に基づく電文Ｙ，Ｚ，Ｗを、テスト対象サーバ及び後段のサーバのログファイルからそれぞれ取得して、これらを関連づけた形でテスト結果記憶部１７６に格納する。

テスト結果処理部１７７は、テスト結果記憶部１７６に記憶されているテスト結果の電文と、テストデータ記憶部１７４に記憶されているテストデータＢとを対比してテスト結果の解析などを行う。この解析結果は、表示装置８に出力される。

例えば、テスト結果処理部１７７は、入力されたリクエスト電文（Ｘ）及びこれに対するサーバの処理結果として得られた電文Ｙ，Ｚ，Ｗの組が、テストデータ記憶部１７４に記憶されているテストデータＢのいずれかと一致するか否かを判定する。いずれかと一致すれば、アプリケーションシステム１は正常に動作していると考えられる。一方、いずれとも一致しない場合は、テスト対象サーバまたはその後段のサーバに何らかの異常があると考えられる。これらの解析結果は、例えば表示装置８に一覧表示される。

これにより、テンプレート及び必要なパラメータを設定するだけで、網羅的なテストデータの生成、テストの実施及びその結果の解析を自動的に行うことができる。さらに、テスト実施者は、表示装置８にテストの解析結果が表示されるので、システムが正常であるかを直ちに知ることができる。

ＤＢ設定変更部１７８は、テストを実施するために、アプリケーションシステム１の動作環境の変更及びその復帰を行う。例えば、ＤＢ設定変更部１７８は、ＤＢ設定表９０を参照して、システムインタフェース１５１を介してＤＢ１４の内容を一時的に変更する。例えば、ＤＢ設定変更部１７８は、データ設定表９０１（図１２（ａ））に基づいてＤＢ１４を更新する。また、上記の設定変更をする際に、ＤＢ設定変更部１７８は、変更前の状態をデータ戻し表９０２（図１２（ｂ））に設定する。そして、テスト終了後に、データ戻し表９０２を参照して前の状態へ戻す。

例えば、図１２（ａ）に示すデータ設定表９０１の場合、ＤＢ設定変更部１７８は、表名９１に設定されている表から、条件９２を満たすレコードを抽出する。そして、そのレコードの列名９３に合致する列を設定値９４に設定されている値に変更する。これにより、テストを行うときのＤＢの設定を自在に変更することができる。

次に、リリース制御に関する構成及び処理について説明する。

リリース管理部１８１は、システムインタフェース１５１を介して、アプリケーションシステム１内の各サーバ１１，１２，１３のステータスを照会する。例えば、各サーバ内のステータス記憶部１１４、１２４，１３４に記憶されている各サーバのステータスを取得する。ここで取得した各サーバ１１，１２，１３のステータスは、ステータス表１８３に格納される。

ここで、各サーバ内のステータス記憶部１１４、１２４，１３４に格納されるステータス情報について説明する。

アプリケーションシステム１に新たに追加されたサーバの場合、ステータス記憶部にはプロビジョニングが終了した時点で「未テスト」というステータスが設定される。その後、上述したテストが実行されているときは、テスト実行部１７５によりステータスが「テスト中」に変更される。そして、表示装置８に表示されたテスト結果などにより、すべてのテストが正常終了したことが確認され、テスト実施者によりテスト完了を示す入力がなされると、そのサーバのステータス記憶部には、アプリケーションシステム１の一部として正式に稼働可能であることを示す「リリース可」というステータスが設定される。さらに、後述するように、リリース管理部１８１がリリースしたときは、リリースされたサーバ内のステータス記憶部には、「リリース済み」というステータスが設定される。

図１５には、ステータス表１８３の一例を示す。すなわち、ステータス表１８３には、サーバ名１８３１とステータス１８３２とが対応付けて登録されている。ステータス１８３２には、各サーバのステータス記憶部１１４、１２４，１３４から取得したステータスが格納される。

また、リリース管理部１８１は、ステータス表１８３のステータス１８３２が「リリース可」であるサーバについて、リリース条件表１８２に設定された条件が満たされているか否かを判定し、条件が満たされている場合にそのサーバをリリースする。ここで、サーバのリリースを実行するためには、リリース管理部１８１がリリース対象のサーバを指定して、所定のリリース処理コマンドを発行する。リリース処理コマンドは、例えば、リリース管理部１８１が有するコマンド表１８４を参照して取得する。

図１６には、コマンド表１８４の一例を示す。コマンド表１８４には、サーバ種別１８４１ごとにリリース処理コマンド１８４２が登録されている。リリース管理部１８１は、リリースするサーバの種別に応じて、リリース処理コマンドを取得して、実行する。

図１７には、リリース条件表１８２の一例を示す。すなわち、リリース条件表１８２には、リリース対象サーバ１８２１と依存サーバ１８２２とが対応付けて記憶されている。ここで、依存サーバ１８２２とは、リリース対象サーバ１８２１をリリースするためにはリリース済みでなければならないサーバである。つまり、リリース対象サーバ１８２１がリリース可能な状態であっても、依存サーバ１８２２がリリース済みでなければリリース対象サーバ１８２１をリリースすることができない。リリース条件表１８２は、システム管理者等によって予め設定される。

つぎに、上記のような構成を備えたシステムにおける種々の処理手順について、図１８〜図２０のフローチャートを用いて説明する。

まず、図１８には、ログの収集及び解析を行う場合の管理サーバ１５の処理手順を示す。

ログデータ収集部１６１がアプリケーションシステム１内の各サーバ１１，１２，１３から、それぞれに蓄積されているログデータを収集し、収集ログ記憶部１６３に格納する（Ｓ１０１）。ログデータ解析部１６５は、収集ログ記憶部１６３に格納されているログデータを、各レコードに含まれている電文識別子をキーにして分類し、電文識別子別に抽出する（Ｓ１０２）。ログデータ解析部１６５は、登録情報記憶部１７２に予め登録されている電文確認表６０を参照して、同じ電文識別子を有する電文間の整合性をチェックする（Ｓ１０３）。ここでは、例えば、リクエストに対するリプライが予め定められているパターンと一致するか否かを判定する。そして、その解析結果を表示装置８に表示出力する（Ｓ１０４）。

これにより、複数のサーバが間で電文を送受信して動作するアプリケーションシステム１において、各サーバ間で送受信される電文が正常であるか否かを自動的に確認することができる。さらに、各サーバ群でそれぞれ複数のサーバを有し、様々な経路で電文がやりとりされる場合であっても、すべての電文のやりとりをもれなくチェックすることができ、網羅性の高いテストを行うことができる。

次に、図１９には、テストデータの生成及びテストの実施を自動的に行う場合の管理サーバ１５の処理手順を示す。

テスト実施者が、テストデータの基となるテストパターンのテンプレート及びそのテンプレートにセットされるパラメータ値を登録する（Ｓ２０１）。ログデータ収集部１６１は、アプリケーションシステム１の各サーバ１１，１２，１３からログデータを収集し、収集ログ記憶部１６３に格納する（Ｓ２０２）。

そして、テストデータ生成部１７３は、上述の処理で登録されたテンプレート及びパラメータ値と、ログデータとに基づいて、中間的なテストデータであるテストデータＡを生成する（Ｓ２０３）。このとき、テスト実施者が登録したパラメータ値をまず設定し、テスト実施者が設定していないパラメータについては、ログデータから取得した値を設定する。次に、テストデータ生成部１７３は、テストデータＡとテンプレートとを用いて、最終的なテストデータであるテストデータＢを生成する（Ｓ２０４）。

ここで、テストデータを流してテストを実施するに当たり、テスト環境であるＤＢ１４の設定を変更する必要がある場合には、ＤＢ設定変更部１７８が、予め登録されているＤＢ設定表９０を参照して設定変更を行う（Ｓ２０５，２０６）。

そして、テスト実行部１７５がテスト対象サーバにテストデータのリクエスト電文を入力して、アプリケーションシステム１を動作させて、テストを実施する（Ｓ２０７）。

テストの実施が終了すると、ステップＳ２０６でＤＢの設定変更を行っている場合は、その変更を元に戻し、変更前の状態に復帰させる（Ｓ２０８，２０９）。

テスト結果処理部１７７は、テスト結果記憶部１７６に格納されているテスト結果を、テストデータ記憶部１７４に記憶されているテストデータと比較して検証する（Ｓ２１０）。そして、検証結果が、表示装置８に表示される。

これにより、テスト実施者は、数多くのテストデータそのものを作成しなくても、テンプレートとしてテストしたいパターンを登録し、重要なパラメータ値を登録しておくことにより、テストデータが自動的に生成され、かつ、テスト及びその結果検証も自動的に行うことができる。さらに、パラメータ値の設定も、すべてのパラメータについて行う必要がない。つまり、テスト実施者が特に指定しないパラメータはログデータから抽出して自動的に補われるので、テスト実施者は、パラメータ値を網羅的に設定しなくてもテストデータを生成することができる。これにより、テスト実施者の負担が軽減される。

図２０には、管理サーバ１５が行うリリース制御の処理手順を示す。

まず、システム管理者が、新規に追加されたサーバをリリースするためのリリース条件を登録する（Ｓ３０１）。登録されたリリース条件は、リリース条件表１８２に格納される。リリース管理部１８１は、リリース判定を行う対象のサーバから、そのサーバのステータスを取得し、ステータス管理表１８３に格納する（Ｓ３０２）。対象のサーバが複数ある場合は、すべての対象サーバから取得する。

リリース管理部１８１は、ステータス管理表１８３を参照し、「リリース可」であるサーバの有無を判定する（Ｓ３０３）。そして、「リリース可」であるサーバがないときは、終了する（Ｓ３０３：Ｎｏ）。

一方、「リリース可」であるサーバがあるときは（Ｓ３０３：Ｙｅｓ）、リリース管理部１８１は、リリース条件表１８２を参照し、そのサーバのリリース条件が満たされているか否かを判定する（Ｓ３０４）。そして、リリース条件が満たされていないときは、終了する（Ｓ３０４：Ｎｏ）。

リリース条件が満たされているときは（Ｓ３０４：Ｙｅｓ）、リリース管理部１８１は、リリース対象サーバの種別に応じて、コマンド表１８４からリリースコマンドを取得し、それをリリース対象サーバへ送信して、リリースを実行する（Ｓ３０５，３０６）。

ステップＳ３０３以降の処理を繰り返すことにより、リリース対象サーバが複数ある時は、順次リリース判定及びリリースを実施することができる。

これにより、システム管理者が定めたリリース対象サーバごとのリリース条件に従って、サーバごとにリリース判定が行われる。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

例えば、上述の実施形態では、アプリケーションシステム１がＰＬサーバ群１１Ａ，ＢＬサーバ群１２Ａ，及びＤＢサーバ群１３Ａの３層構造になっているが、２層、あるいは４層以上であってもよい。さらには、アプリケーションシステム１は、必ずしも層構造になっていなくてもよい。

本実施形態に係るシステムの全体構成図。ＰＬサーバ１１，ＢＬサーバ１２及びＤＢサーバ１３の詳細な構成図。ＰＬログ１１７、ＢＬログ１２７、ＤＢログ１３７のデータ構造の一例。各電文フォーマットの一例。管理サーバ１５の構成図。収集ログ記憶部１６３に記憶されているログデータの一例。ログデータ解析部１６５がログデータの各レコードを電文識別子５１でソートした結果の一例。電文識別子「192.168.0.102-0845」のレコード群。電文確認表６０の一例。パラメータ表７０の一例。テンプレート８０の一例。ＤＢ設定表９０の一例。テストデータＡの一例。テストデータＢの一例。ステータス表１８３の一例。コマンド表１８４の一例。リリース条件表１８２の一例。ログの収集及び解析を行う場合の処理手順を示すフローチャート。テストデータの生成及びテストの実施を自動的に行う場合の処理手順を示すフローチャート。リリース制御の処理手順を示すフローチャート。

符号の説明

１アプリケーションシステム
２クライアント
１０ロードバランサ
１１ＰＬサーバ
１２ＢＬサーバ
１３ＤＢサーバ
１４ＤＢ
１５管理サーバ
２１クライアントリクエスト電文
２３，２５サーバ間リクエスト電文
３１クライアントリプライ電文
３３，３５サーバ間リプライ電文

Claims

電文処理システムと、前記電文処理システムの正常性確認装置とを備えた電文処理システムの正常性確認システムであって、
前記電文処理システムは、
複数のインタフェース装置と、第１のグループ又は第２のグループに属する複数の内部装置とを備え、
前記複数のインタフェース装置のそれぞれは、
リクエスト電文を受け付けて、前記リクエスト電文と関連づけられた第１の内部電文を、前記第１のグループに属する複数の内部装置のいずれかに対して出力する手段と、
前記第１のグループに属する複数の内部装置のいずれかから第２の内部電文を受け付けて、前記第２の内部電文に関連するリプライ電文を出力する手段と、
前記リクエスト電文及び前記リプライ電文に関するログデータを記憶した記憶手段と、を備え、
前記第１のグループに属する第１の内部装置は、
前記一のインタフェース装置から前記第１の内部電文を受信し、受信した第１の内部電文に関連づけられている第３の内部電文を生成して出力する手段と、
前記第２のグループに属する第２の内部装置から第４の内部電文を受信し、受信した第４の内部電文と関連づけて前記第２の内部電文を生成して前記一のインタフェース装置へ送信する手段と、
前記第１の内部電文及び前記第２の内部電文に関するログデータを記憶した記憶手段と、を備え
前記第２の内部装置は、
前記第１の内部装置から前記第３の内部電文を受信し、受信した第３の内部電文と関連づけられている前記第４の内部電文を生成して前記第１の内部装置へ送信する手段と、
前記第３の内部電文及び前記第４の内部電文に関するログデータを記憶した記憶手段と、を備え、
前記正常性確認装置は、
前記複数のインタフェース装置及び前記第１の内部装置及び前記第２の内部装置のそれぞれから各電文に関するログデータを収集する収集手段と、
前記収集手段が収集した各電文に関するログデータから所定の電文識別子を有する電文のログデータを抽出し、抽出されたログデータに、リクエスト電文、リプライ電文、及び第１〜第４の内部電文のログデータが含まれているか否かを判定し、その判定が肯定的であるとき、前記抽出されたログデータに基づいて、前記第１の内部電文を受信した第１の内部装置と前記第４の内部電文を受信した第１の内部装置とが同一であるか否か、及び、前記リクエスト電文を受信したインタフェース装置と前記第２の内部電文を受信したインタフェース装置とが同一であるか否かを判定することにより前記電文処理システムの正常性の確認を行う正常性確認手段と、
前記正常性確認手段による正常性の確認結果を出力する手段と、を備えることを特徴とするシステム。
前記複数のインタフェース装置のそれぞれは、
受け付けたリクエスト電文に電文識別子を付与する手段を備え、
前記第１の内部電文は、関連づけられているリクエスト電文に付与されている電文識別子と同一の電文識別子を有し、
前記第２の内部電文は、関連づけられている第１の内部電文に付与されている電文識別子と同一の電文識別子を有することを特徴とする請求項１に記載のシステム。
複数のインタフェース装置と、第１のグループ又は第２のグループに属する複数の内部装置とを備え、
前記複数のインタフェース装置のそれぞれは、リクエスト電文を受け付けて、前記リクエスト電文と関連づけられた第１の内部電文を、前記第１のグループに属する複数の内部装置のいずれかに対して出力する手段と、前記第１のグループに属する複数の内部装置のいずれかから第２の内部電文を受け付けて、前記第２の内部電文に関連するリプライ電文を出力する手段と、前記リクエスト電文及び前記リプライ電文に関するログデータを記憶した記憶手段とを備え、
前記第１のグループに属する第１の内部装置は、前記一のインタフェース装置から前記第１の内部電文を受信し、受信した第１の内部電文に関連づけられている第３の内部電文を生成して出力する手段と、前記第２のグループに属する第２の内部装置から第４の内部電文を受信し、受信した第４の内部電文と関連づけて前記第２の内部電文を生成して前記一のインタフェース装置へ送信する手段と、前記第１の内部電文及び前記第２の内部電文に関するログデータを記憶した記憶手段とを備え、
前記第２の内部装置は、前記第１の内部装置から前記第３の内部電文を受信し、受信した第３の内部電文と関連づけられている前記第４の内部電文を生成して前記第１の内部装置へ送信する手段と、前記第３の内部電文及び前記第４の内部電文に関するログデータを記憶した記憶手段とを備える電文処理システムの正常性確認装置であって、
前記複数のインタフェース装置、前記第１の内部装置、及び前記第２の内部装置のそれぞれから各電文に関するログデータを収集する収集手段と、
前記収集手段が収集した各電文に関するログデータから所定の電文識別子を有する電文のログデータを抽出し、抽出されたログデータに、リクエスト電文、リプライ電文、及び第１〜第４の内部電文のログデータが含まれているか否かを判定し、その判定が肯定的であるとき、前記抽出されたログデータに基づいて、前記第１の内部電文を受信した第１の内部装置と前記第４の内部電文を受信した第１の内部装置とが同一であるか否か、及び、前記リクエスト電文を受信したインタフェース装置と前記第２の内部電文を受信したインタフェース装置とが同一であるか否かを判定することにより前記電文処理システムの正常性の確認を行う正常性確認手段と、
前記正常性確認手段による正常性の確認結果を出力する手段と、
を備えることを特徴とする電文処理システムの正常性確認装置。
複数のインタフェース装置と、第１のグループ又は第２のグループに属する複数の内部装置とを備え、
前記複数のインタフェース装置のそれぞれは、リクエスト電文を受け付けて、前記リクエスト電文と関連づけられた第１の内部電文を、前記第１のグループに属する複数の内部装置のいずれかに対して出力する手段と、前記第１のグループに属する複数の内部装置のいずれかから第２の内部電文を受け付けて、前記第２の内部電文に関連するリプライ電文を出力する手段と、前記リクエスト電文及び前記リプライ電文に関するログデータを記憶した記憶手段とを備え、
前記第１のグループに属する第１の内部装置は、前記一のインタフェース装置から前記第１の内部電文を受信し、受信した第１の内部電文に関連づけられている第３の内部電文を生成して出力する手段と、前記第２のグループに属する第２の内部装置から第４の内部電文を受信し、受信した第４の内部電文と関連づけて前記第２の内部電文を生成して前記一のインタフェース装置へ送信する手段と、前記第１の内部電文及び前記第２の内部電文に関するログデータを記憶した記憶手段とを備え、
前記第２の内部装置は、前記第１の内部装置から前記第３の内部電文を受信し、受信した第３の内部電文と関連づけられている前記第４の内部電文を生成して前記第１の内部装置へ送信する手段と、前記第３の内部電文及び前記第４の内部電文に関するログデータを記憶した記憶手段とを備える電文処理システムの正常性確認方法であって、
正常性確認装置は、前記複数のインタフェース装置、前記第１の内部装置、及び前記第２の内部装置のそれぞれから各電文に関するログデータを収集するステップと、
前記収集した各電文に関するログデータから所定の電文識別子を有する電文のログデータを抽出し、抽出されたログデータに、リクエスト電文、リプライ電文、及び第１〜第４の内部電文のログデータが含まれているか否かを判定するステップと、その判定が肯定的であるとき、前記抽出されたログデータに基づいて、前記第１の内部電文を受信した第１の内部装置と前記第４の内部電文を受信した第１の内部装置とが同一であるか否か、及び、前記リクエスト電文を受信したインタフェース装置と前記第２の内部電文を受信したインタフェース装置とが同一であるか否かを判定するステップと、
を備えることを特徴とする電文処理システムの正常性を確認する方法。
複数のインタフェース装置と、第１のグループ又は第２のグループに属する複数の内部装置とを備え、
前記複数のインタフェース装置のそれぞれは、リクエスト電文を受け付けて、前記リクエスト電文と関連づけられた第１の内部電文を、前記第１のグループに属する複数の内部装置のいずれかに対して出力する手段と、前記第１のグループに属する複数の内部装置のいずれかから第２の内部電文を受け付けて、前記第２の内部電文に関連するリプライ電文を出力する手段と、前記リクエスト電文及び前記リプライ電文に関するログデータを記憶した記憶手段とを備え、
前記第１のグループに属する第１の内部装置は、前記一のインタフェース装置から前記第１の内部電文を受信し、受信した第１の内部電文に関連づけられている第３の内部電文を生成して出力する手段と、前記第２のグループに属する第２の内部装置から第４の内部電文を受信し、受信した第４の内部電文と関連づけて前記第２の内部電文を生成して前記一のインタフェース装置へ送信する手段と、前記第１の内部電文及び前記第２の内部電文に関するログデータを記憶した記憶手段とを備え、
前記第２の内部装置は、前記第１の内部装置から前記第３の内部電文を受信し、受信した第３の内部電文と関連づけられている前記第４の内部電文を生成して前記第１の内部装置へ送信する手段と、前記第３の内部電文及び前記第４の内部電文に関するログデータを記憶した記憶手段とを備える電文処理システムの正常性を確認するためのコンピュータプログラムであって、
前記複数のインタフェース装置、前記第１の内部装置、及び前記第２の内部装置のそれぞれから各電文に関するログデータを収集するステップと、
前記収集した各電文に関するログデータから所定の電文識別子を有する電文のログデータを抽出し、抽出されたログデータに、リクエスト電文、リプライ電文、及び第１〜第４の内部電文のログデータが含まれているか否かを判定するステップと、その判定が肯定的であるとき、前記抽出されたログデータに基づいて、前記第１の内部電文を受信した第１の内部装置と前記第４の内部電文を受信した第１の内部装置とが同一であるか否か、及び、前記リクエスト電文を受信したインタフェース装置と前記第２の内部電文を受信したインタフェース装置とが同一であるか否かを判定するステップと、
をコンピュータに実行させるためのコンピュータプログラム。