JP2006338197A - トランザクション制御プログラム、トランザクション制御方法及びトランザクション処理システム - Google Patents

Abstract

【課題】 非同期業務処理形態のトランザクション処理システムにおいて、業務処理のトランザクション状態と処理結果応答メッセージの整合を保証する制御機構を提供する。
【解決手段】 メッセージ管理データベースを設け、さらに業務処理とトランザクション制御とを分離するとともに、処理依頼メッセージに対する業務処理とメッセージ管理データベースで管理するメッセージ処理状態の状態遷移を１つのトランザクションとして実行する。
【選択図】図１

Description

本発明は、トランザクション制御プログラム、トランザクション制御方法及び当該トランザクション制御プログラム、トランザクション制御方法を用いたトランザクション処理システムに関し、特に、非同期業務処理形態のトランザクション処理システムとそのためのトランザクション制御プログラム、トランザクション制御方法に関する。

トランザクション処理システムは、銀行等の各企業の基幹業務を遂行するために各所で構築されている。そして、近年では、オープンシステムとして構築することも行われている。

トランザクション処理システムの一つの形態は、オンラインリアルタイムシステムであり、処理受付、業務処理及び処理結果出力が一連の流れで行われ、処理受付と処理結果出力が同期した同期処理形態が取られる。ところが、図１７に示すように、帳票出力を伴う業務処理をオンラインリアルタイム処理の処理形態で実現すると、帳票編集に時間がかかりシステム資源占有時間が長くなり、スループットを確保することができない。そこで、このような業務は、処理受付及び業務処理と処理結果出力を別個に行い、処理受付のタイミングからの時間遅れを前提として処理結果出力を行う非同期業務処理形態で実現している。

図１８は、このような、非同期業務処理形態のためのトランザクション処理システムの一例を示すものであり、同図に基づき、従来の非同期業務処理形態のためのトランザクション処理システムについて説明する。

クライアント側が従業員番号等を入力して発注依頼を行うと、サーバの依頼受付部Ａが発注依頼を受信し、発注依頼のメッセージをメッセージ管理データベースに格納するとともにその処理をアプリケーション制御部Ｂに非同期通信で依頼する。依頼受付部Ａは依頼が完了するとクライアントに受付完了を応答する。アプリ制御部Ｂは、依頼された発注業務処理を行い、対象の業務データベースを更新し、結果帳票ファイルを作成する。

クライアント側では、発注依頼の後しばらく間をおいて結果確認依頼を行う。サーバの処理結果取り出し部Ｃは、結果確認依頼を受信し、結果帳票ファイルをクライアントに返送する。

以上のような流れで、非同期業務処理形態の処理が行われるが、上記処理のほかに、各処理間の制御移行、情報や状態の引継ぎなど制御処理が必要であり、また、サーバダウン時には再処理の運用が必要である。このような制御処理や再処理の運用を実行するためには、ユーザの業務自体を実行する業務アプリケーションとは独立した制御機構を設けることが望ましい。

一般的に、依頼受付部Ａからアプリケーション制御部Ｂ、アプリケーション制御部Ｂから処理結果取り出し部Ｃ等のメッセージ通信については、メッセージ送信の保証機構を提供する製品が知られており、下記特許文献１にも、このようなメッセージ送信の保証機構が記載されている。

しかし、メッセージに対する業務処理のトランザクション（未処理メッセージの取り込み、処理結果メッセージの格納と業務データベース更新）と連携してメッセージ送信を保証する機構は存在せず、そのために、特にオープン分野ではアプリケーション制御製品とデータベース製品のベンダーが別であることが多いため、業務アプリケーションがトランザクション制御機能を実装する必要がある。例えば、サーバダウンが発生した場合、処理中であったメッセージの状態を確認し、再処理を行う複雑な制御機能が業務アプリケーションに必要である。
特開２００４−３２６１５１号公報

そこで、本発明の解決しようとする課題は、非同期業務処理形態のトランザクション処理システムにおいて、業務処理のトランザクション状態と処理結果応答メッセージの整合を保証する制御機構を提供し、業務アプリケーションがトランザクション制御機能を持つ必要性をなくすことである。

本発明は上記課題を解決するために、依頼メッセージの本文と当該メッセージの処理状態及び前記処理依頼に対する処理結果メッセージを管理するメッセージ管理データベースと、さらに未処理メッセージの取り込み要求によりトランザクションを開始し、前記メッセージ管理データベースから前記未処理メッセージを取り出し、前記未処理メッセージと業務データベースを用いて業務処理を実行し前記業務データベースの仮更新を行うとともに処理結果メッセージを作成する業務アプリケーションを呼び出し、前記業務アプリケーションから前記処理結果メッセージを受け取り、前記メッセージ管理データベースに格納し、前記メッセージ管理データベース上の前記未処理メッセージの処理状態を処理済みに変更し、前記業務データベースと前記メッセージ管理データベースの実更新を行ってトランザクションを終了するトランザクション制御手段を備える。

上記本発明の課題解決手段によれば、業務処理のトランザクション状態と処理結果応答メッセージの整合を保証するとともに、業務アプリケーションは、トランザクション制御機能が必要でなく、業務データベースの更新状況やメッセージ処理状況（未処理メッセージの取り込み、処理結果メッセージの格納）を意識することなく渡されるメッセージを処理するだけの簡単な構造とすることができ、業務アプリケーションが複雑になり、開発負担、メンテナンス負担が大きくなることを防ぐことができる。

トランザクションと連携した非同期メッセージ送信機能を実現し、業務アプリケーションがトランザクション制御機能を持つ必要性をなくすための本発明の制御機構は、処理依頼受付及び結果取り出し保証機能、業務実行制御機能、メッセージ管理操作機能及びサーバダウン時の処理再開機能を提供する。これらの機能は、本発明のメッセージ受付機構、トランザクション連携アプリケーション制御機構、処理結果取り出し機構及び非同期メッセージ管理機構により実現される。

図１は、上記各機構を備えた本発明のトランザクション処理システム１００の全体構成を説明する図である。
メッセージ受付機構１０は、依頼メッセージを受信すると、当該依頼メッセージを一意に識別する受付ＩＤを採番し、依頼を受け付けるだけの業務アプリケーション１２で編集された編集メッセージを、非同期メッセージ管理機構４０が管理するメッセージ管理データベース４５のメッセージエントリテーブル４５１に格納し、トランザクション連携アプリケーション制御機構２０にメッセージ処理を依頼する。

トランザクション連携アプリケーション制御機構２０は、依頼メッセージをメッセージエントリテーブル４５１から取り出し、業務ロジックを実行する業務アプリケーション２２を呼び出して業務処理を行う。その後、状態管理テーブル４５２にアクセスして正常消し込み、あるいは異常状態管理のメッセージ状態管理を行う。また、業務処理の処理結果を処理結果メッセージとして結果管理テーブル４５３に書き込み、処理結果メッセージ管理を行う。

処理結果取り出し機構３０は、依頼メッセージの受付ＩＤを持つ処理結果照会メッセージを受信すると、結果管理テーブル４５３から処理結果メッセージを取り出し、結果を確認、取り出すだけの業務アプリケーション３２で編集された処理結果メッセージをクライアントに送信する。

以下、図面を参照して、上記４つの機構について詳細に説明する。
図２は、メッセージ受付機構１０の概要を説明する図であり、図３は、メッセージ受付機構１０の処理フローを説明する図である。

メッセージ受付機構１０は、利用者からの依頼メッセージの受付を行い、非同期メッセージ管理機構４０を構成するメッセージ管理データベース４５のメッセージエントリテーブル４５１へ格納する。その際に、メッセージの格納とトランザクションを連携させ、一意となる受付ＩＤの払出を行い、その後のメッセージに対する操作、管理が容易に行えるようにする。また、受付ＩＤは、処理結果取得時のキーワードとなる。

図３によりメッセージ受付機構の処理フローについて説明すると、依頼メッセージの受信により、処理メッセージ受付ステップ（１）で処理メッセージ受付を行い、トランザクション開始ステップ（２）でトランザクションを開始し、業務処理呼出しステップ（３）で業務アプリケーション１２を呼び出す。ここで呼び出される業務アプリケーション１２は、例えば、業務ロジックによる受付条件、依頼メッセージのチェック、編集操作などを行う。受付メッセージの管理は制御機構側で行うので不要であり、受付ＩＤも意識する必要がない。

次に、編集メッセージ格納ステップ（４）で編集メッセージの格納を行い、受付ＩＤの採番・状態の登録ステップ（５）で受付ＩＤの採番と状態管理テーブルへの状態の登録を行う。そして、トランザクションエンドステップ（６）でトランザクションを終了させ、メッセージの格納保証が行われる。業務ロジックによる編集操作と、通番の払い出し、編集メッセージの格納を一つのトランザクションとして連携して行うため、受付ＩＤによるメッセージの管理が可能となる。

最後に、未処理メッセージ取り込み要求ステップ（７）で未処理メッセージ取り込み要求をトランザクション連携アプリケーション制御機構２０に対して行い、応答メッセージ送信ステップ（８）で応答メッセージの送信（受付ＩＤの通知）を行う。最後のステップ（７）とステップ（８）の順番は、逆でも可能である。

次に、トランザクション連携アプリケーション制御機構２０について説明する。
図４は、トランザクション連携アプリケーション制御機構２０の処理概要を説明する図である。トランザクション連携アプリケーション制御機構２０は、先に図１において説明したように、依頼メッセージをメッセージエントリテーブル４５１から取り出し、業務ロジックを実行する業務アプリケーション２２を呼び出して業務処理を行い、その後、状態管理テーブル４５２にアクセスして正常消し込み、あるいは異常状態管理のメッセージ状態管理を行い、さらに、業務処理の処理結果を処理結果メッセージとして結果管理テーブル４５３に書き込み、処理結果メッセージ管理を行う。また、編集メッセージの取り出しの契機に関して、メッセージ受付機構１０からの取り出し要求だけでなく、同機構内にタイマ監視部２４を設け、起動時および起動後の一定時間間隔で未処理メッセージの取込み要求を出すようにして、メッセージ受付機構１０との通信に一時的な異常が発生した場合やサーバダウン後の再起動時に、メッセージエントリテーブル４５１にたまった編集メッセージを取込んで業務処理を継続することができるようになっている。

図５は、トランザクション連携アプリケーション制御機構２０の処理フローを説明する図であり、左側に記載したフローは、トランザクション連携アプリケーション制御機構本体の処理フローであり、右側に記載したフローは、タイマ監視部２４の処理フローである。

タイマ監視部２４は、図示のとおり、起動（ダウン後再起動）時および一定周期で、未処理メッセージ及びダウン時に処理中であったメッセージの取込みを要求する。これにより、ダウン再開時や一時的なネットワーク障害時も業務処理を継続することができる。

トランザクション連携アプリケーション制御機構本体は、メッセージ受付機構１０あるいはタイマ監視部２４から未処理メッセージあるいは処理中メッセージの取込み要求により、トランザクション開始ステップ（１）でトランザクションを開始し、編集メッセージ取り出し処理ステップ（２）でメッセージエントリテーブル４５１から編集メッセージの取り出し処理を行い、未処理メッセージについて、状態管理テーブルの編集メッセージの状態を未処理から処理中に更新する状態遷移処理ステップ（３）を実行し、一旦、トランザクションエンドステップ（４）でトランザクションを終了する。これにより、編集メッセージが処理中であることを確定する。

次に再びトランザクション開始ステップ（５）でトランザクションを開始し、業務処理呼出しステップ（６）で業務アプリケーション２２を呼び出す。ここでの業務アプリケーション２２は、純粋な業務ロジックによるものであり、結果応答メッセージの編集と業務データベース２５の仮更新のみを行う。メッセージエントリテーブル４５１にアクセスしての受付メッセージの読み込み、業務データベース２５の実更新、応答メッセージの結果管理テーブル４５３への格納、及び受付メッセージの消し込みなどの機能は、業務アプリケーション２２には不要である。

次に、業務処理結果による状態管理ステップ（７）において業務処理結果による状態管理、すなわち業務アプリケーション２２からのリターンコードが正常終了を示しているか異常終了を示しているかによって状態管理の処理を分岐する。

正常終了であれば、処理結果メッセージ格納ステップ（８）で、業務アプリケーション２２で作成された処理結果メッセージを結果管理テーブル４５３に格納する。そして、状態遷移ステップ（９）において、状態管理テーブル４５２で管理されている編集メッセージの状態を処理中から処理済みに更新する正常処理メッセージ消し込み処理を行う。最後にトランザクションエンドステップ（１０）で各データベースの実更新を行い、トランザクションを終了させてアイドル状態に戻る。

異常終了の場合には、異常発生時の状態を管理するための、非同期メッセージ管理機構４０と連携したトランザクション制御のフローが実行される。トランザクションキャンセルステップ（１１）でトランザクションはキャンセルされ、業務アプリケーション２２による業務データベース２５の仮更新は取り消され、トランザクション開始ステップ（１２）で、異常発生時の状態管理用のトランザクションが開始される。そして、状態遷移ステップ（１３）において、状態管理テーブル４５２で管理されている編集メッセージの状態を処理中からエラー処理済みに更新する異常処理メッセージ管理処理を行う。また、異常処理結果メッセージ格納ステップ（１４）で、異常処理結果メッセージを結果管理テーブル４５３に格納する。

異常発生時の処理に関して、ユーザ特有の処理の要請がある場合には、ユーザカクタマイズ処理ステップ（１５）において、ユーザ定義の状態遷移や、処理受け付け用のキューの閉塞などを行う。

最後にトランザクションエンドステップ（１６）でトランザクションを終了させてアイドル状態に戻る。
図５に示した例では、編集メッセージの状態として“処理中”という状態を設け、処理中であることを確定させるためにステップ（３）〜ステップ（５）を実行しているが、これは、トランザクション処理システムの障害発生時に編集メッセージの処理状態を詳しく把握してデバッグを行うという要請に応えるためであり、そのような要請がなければ、上記ステップ（３）〜ステップ（５）は省略可能である。

図６は、業務処理が正常終了時のトランザクション制御を説明する図である。図示した処理、（１）編集メッセージ取出しから（６）コミットまでが一つの業務トランザクションと定義され、この一つの業務トランザクションにおいて、業務データベース２５の更新とメッセージ管理データベース４５の更新が行われる。このように、同一のトランザクションで業務データベース２５の更新とメッセージ管理データベース４５の更新を行うので、業務処理のトランザクション状態と処理結果応答メッセージの整合性を保証することができる。

そして、業務データベース２５とメッセージ管理ＢＤ４５については、同一のデータベースに配置し、それぞれをサブのデータベースとすることで、同一のトランザクションで業務データベース２５の更新とメッセージ管理データベース４５の更新を行うためのトランザクション制御を容易にすることが好ましい。

以下、図６を参照して、業務処理が正常時の業務トランザクションを詳細に説明する。なお、図６に示す例は、図５のステップ（３）からステップ（５）を省いたものであり、“処理中”というメッセージの状態を定義しない場合のものである。

トランザクション連携アプリケーション制御機構２０は、編集メッセージ取出しステップ（１）でメッセージ管理データベース４５１のメッセージエントリテーブル中の依頼キューから編集メッセージを取り込む。次に、呼び出し業務確定ステップ（２）において、編集メッセージで依頼された業務処理の決定を行い、業務呼び出しステップ（３）で当該業務処理（業務ロジック）２２を呼び出す。業務処理２２は業務ＢＤ２５のデータを参照し、業務ロジックに基づいた処理を行い、当該データの仮更新を行い、正常復帰ステップ（４）で正常復帰であることを示すリターンコードを返す。

次に、トランザクション連携アプリケーション制御機構２０は、状態変更・応答格納ステップ（５）で、状態管理テーブル４５１の処理を依頼された編集メッセージの処理状態を処理済みに仮更新するとともに、処理結果を正常と仮更新状態で記録する。さらに、業務データベース２５のレコードと正常応答メッセージを結果管理テーブル４５３に格納（仮更新）する。最後にコミットステップ（６）で仮更新状態にある業務データベース２５及びメッセージ管理データベース４５のデータを実更新し、トランザクションを終了する。

次に、図７を参照して、業務処理が異常時の業務トランザクションを詳細に説明する。ステップ（１）からステップ（３）までと業務処理２２が仮更新を行うところまでは、正常時と同様である。異常時には、業務処理２２は異常復帰ステップ（４）で異常復帰であることを示すリターンコードを返す。

トランザクション連携アプリケーション制御機構２０は、ロールバックステップ（５）（図５のトランザクションキャンセルステップ（１１））で、業務処理２２の行った仮更新をキャンセルする業務データベース２５のレコードの更新取消（ロールバック）を行う。そして、図５のステップ（１２）に示したように、制御トランザクションを開始し、状態変更・応答格納ステップ（６）において、メッセージ管理データベース４５に処理結果（異常）、処理依頼メッセージの状態変更（処理済み）及び異常応答メッセージの格納の仮更新を行う。

最後に、コミットステップ（７）で、メッセージ管理データベース４５の実更新を行い上記仮更新をデータベースに反映してトランザクションを終了する。
次に、処理結果取り出し機構３０について説明する。

図８は、処理結果取り出し機構３０の概要を説明する図である。図１について説明したように、処理結果取り出し機構３０は、依頼メッセージの受付ＩＤを持つ処理結果照会メッセージを受信すると、結果管理テーブル４５３から処理結果メッセージを取り出し、結果を確認、取り出すだけの業務アプリケーション３２で編集された処理結果メッセージをクライアントに送信する。

処理結果取り出し機構３０の上記処理のフローを図９を参照して説明すると、処理メッセージ受付ステップ（１）で処理結果照会メッセージから受付ＩＤを取得し、それに基づき、処理結果メッセージ取得ステップ（２）で、結果管理テーブル４５３から処理結果メッセージを獲得する。

次に、業務処理呼び出しステップ（３）において、必要とあれば業務に特有な処理を行うための業務アプリケーション３２を呼び出す。業務アプリケーション３２により、業務処理にディペンドした処理結果メッセージの再編集が可能となる。一方、応答メッセージの取り出しや消し込み管理などの機能は、業務アプリケーション３２には必要がない。

最後に、応答メッセージ送信ステップ（４）において、業務アプリケーション３２で編集した処理結果メッセージを処理結果照会メッセージの応答として送信して処理を終了する。

以上のとおり、クライアント側は、処理依頼時に返却された受付ＩＤで処理結果の照会を依頼するだけで、処理結果取り出し機構３０が自動的に結果管理テーブル４５３から処理結果メッセージの取り出しを行う。そして、利用者は業務アプリケーション３２により任意の編集を行うことができる。その際、業務アプリケーション開発者は、複雑な処理を考慮する必要がなくなる。

次に、非同期メッセージ管理機構４０について説明する。
図１０は、非同期メッセージ管理機構４０の概要を説明する図である。非同期メッセージ管理機構４０は、メッセージを保証するために、データベースシステム（メッセージ管理データベース４５）上に管理機構を構築している。そして、非同期メッセージ管理機構４０は、前記データベースを操作するためのアプリケーションインターフェース（ＡＰＩ）を提供している。したがって、メッセージ受付機構１０、トランザクション連携アプリケーション制御機構２０及び処理結果取り出し機構３０はこのＡＰＩを利用してメッセージ管理データベース４５にアクセスする。また、各種業務アプリケーションもこのＡＰＩを利用してメッセージ管理データベース４５にアクセスすることができる。

メッセージ管理データベース４５は、メッセージエントリテーブル４５１，状態管理テーブル４５２及び結果管理テーブル４５３を含み、受付ＩＤをキーとして、処理依頼されたメッセージ、当該メッセージの処理結果、当該メッセージの処理状態などを管理する。また、メッセージの処理状態の状態遷移を管理し、エラー状態となったメッセージに対して前記ＡＰＩを利用してその状態を未処理とする状態遷移の依頼があった場合に、状態遷移を実施して当該メッセージの再処理を可能とする。そして、メッセージ本文、メッセージの状態を管理することにより、サーバダウン発生時にもメッセージの状態と本文を保証することが可能であり、処理再開時の処理対象メッセージの検出が可能である。

図１１は、非同期メッセージ管理機構４０のメッセージ管理データベース４５の構成概要を説明する図である。図１１では、空室照会、予約業務を例としている。
図１１に示されているように、全てのテーブルが受付ＩＤをキーにして関連づけられて管理されている。

受付ＩＤの付与方法を規定することにより、優先制御を行うこともできる。
例えば、受付ＩＤを、「予約（Ｒ）／照会（Ｉ），優先（Ｈ）／非優先（Ｌ），通番」のフォーマットとすることにより、業務が空室の予約であるのか空室の照会であるのかが識別され、それぞれの業務においてそのメッセージの処理が優先されるのかが識別される。図１１に例示された受付ＩＤがＲＨ０２３１のメッセージについてみると、メッセージエントリテーブル４５１には、山田太郎が２００５年６月２０日の空室予約を依頼する趣旨の編集メッセージが格納され、メッセージ状態管理テーブル４５２には、当該メッセージの処理が完了したことが示されている。そして、処理結果管理テーブル４５３には、山田太郎が２００５年６月２０日に会議室Ａ７０１を予約したことを示す処理結果メッセージが格納されている。受付ＩＤがＩＬ０５６２のメッセージについては、未処理状態であり、処理結果管理テーブル４５３には該当する受付ＩＤのエントリには処理結果メッセージが格納されていないことが示されている。上記の２例は、業務トランザクションの状態とメッセージ送信の整合性が保たれていることを示すものである。

次に図１２により、非同期メッセージ管理機構４０のメッセージ状態遷移について説明する。利用者のオペレーションにより依頼メッセージがエントリされると当該メッセージの状態は未処理状態４６となる。なお、未処理状態４６は、処理中の状態も含むものとする。業務処理が正常に終了すれば、完了（正常）状態４７に遷移する。再処理可能なエラーが発生した場合は、未処理状態４６のままである。しかし、再処理を繰り返し、リトライオーバになると、保留（エラー）状態４６１に遷移する。未処理状態４６で保留依頼があると、保留状態４６３に遷移し、再度処理を依頼する再処理依頼があると再び未処理状態４６に戻る。業務エラーあるいはシステムエラーが発生すると、完了（エラー）状態４６２に遷移する。この状態で再送依頼があると、未処理状態４６となる。未処理状態４６で利用者から取り消し依頼があると、取り消し状態４６４に遷移する。

上記のメッセージ状態遷移は、非同期メッセージ管理機構４０のメッセージ状態管理テーブル４５２を用いて管理される。非同期メッセージ管理機構４０はメッセージの状態管理手段と前述のＡＰＩによる状態操作手段を提供し、トランザクション連携アプリケーション制御機構２０が上記ＡＰＩを使用して完了（正常）状態４７に状態遷移させ、メッセージの状態を処理済みとすることで正常終了メッセージの消し込みが可能である。エラー状態の場合は、エラーの原因調査と原因除去の後、運用コマンドによりメッセージの状態を未処理にすることで、再処理が可能になる。また、メッセージの処理状況（未処理、処理中、処理済み（正常／異常））を確認可能である。さらに、処理中メッセージを管理することで、サーバダウンからの復旧のための管理が可能であり、メッセージを削除することなく一時的に処理対象から外しておくことも可能である。

次に、サーバダウン時からの復旧について説明する。
図１３はサーバダウン時からの復旧の全体制御フローを示すものであるが、図示のとおり、（１）サーバダウン、（２）サーバ復旧／再起動、（３）オンライン再起動という単純なフローである。

サーバダウン後のオンライン再起動時に、非同期メッセージ管理機構４０で管理するメッセージの状態により、自動的に処理対象メッセージを検出する。したがって、ユーザがメッセージの特定やメッセージの再処理の判断をすることなく自動的にサーバダウン復旧処理が可能である。

次に、図１４により、サーバダウン再開時の要求メッセージ取り出しについて説明する。図１４は、サーバダウン後の業務再開時にトランザクション連携アプリケーション制御機構２０から業務アプリケーションにスケジュールされる（渡される）要求メッセージを示すものである。図１４に示す例では、図５に示す例と同様に、要求メッセージに“処理中”の状態を定義し、編集メッセージ（要求メッセージ）の取り出し後、要求メッセージの状態を“処理中”に確定させるものである。また、サーバダウン時の業務処理の対象メッセージの受付ＩＤをｎとする。

業務処理結果が正常であり、業務データベースとメッセージ管理データベースの実更新前、すなわち図５に示すステップ（９）以前にダウンしたケースでは、業務データベース状態は更新なしであり、メッセージ管理データベース状態は処理中である。この場合には、業務再開時にスケジュールされる要求メッセージは、ダウン時の処理中メッセージ（ｎ）である。すなわち、図５のステップ（ａ）にあるように、タイマ監視部が処理再開時に処理中メッセージの取り込みを要求する。

業務処理結果が正常であり、業務データベースとメッセージ管理データベースの実更新後、すなわち図５に示すステップ（１０）以降にダウンしたケースでは、業務データベース状態は実更新済みであり、メッセージ管理データベース状態は、メッセージの処理状態については処理済みであり、正常な応答電文を格納済みである。この場合には、業務再開時にスケジュールされる要求メッセージは、ダウン時の処理済みの次のメッセージ（ｎ＋１）である。

業務処理結果が異常であり、業務データベース更新取消し前、すなわち図５に示すステップ（１１）以前にダウンしたケースでは、業務データベース状態は更新なしであり、メッセージ管理データベース状態は処理中である。この場合には、業務再開時にスケジュールされる要求メッセージは、ダウン時の処理中メッセージ（ｎ）である。

業務処理結果が異常であり、業務データベース更新取消し後かつメッセージ管理データベース更新前、すなわち図５に示すステップ（１２）以降ステップ（１５）以前にダウンしたケースでは、業務データベース状態は取消し済みであり、メッセージ管理データベース状態は、処理中である。この場合には、業務再開時にスケジュールされる要求メッセージは、ダウン時の処理中メッセージ（ｎ）である。

業務処理結果が異常であり、メッセージ管理データベースの更新後、すなわち図５に示すステップ（１５）以降にダウンしたケースでは、業務データベース状態は取消し済みであり、メッセージ管理データベース状態は、メッセージの処理状態については処理済みであり、異常応答電文を格納済みである。この場合には、業務再開時にスケジュールされる要求メッセージは、ダウン時の処理済みの次のメッセージ（ｎ＋１）である。

上記のとおり、サーバダウン後の業務再開でも、ダウン時の処理中であったメッセージの受付ＩＤにより、メッセージ管理データベース４５で管理する当該受付ＩＤのメッセージの状態を調べ、自動的に処理対象メッセージを検出することができる。

次に、本発明を帳票発行業務に適用した実施例１を図１５により説明する。
まず、端末５０より、印刷出力する出力帳票を識別する出力帳票の番号を指定してメッセージ受付機構１０に帳票出力の依頼を行う。端末５０は、メッセージ受付機構１０から、依頼した結果として受付ＩＤを受け取る。トランザクション連携アプリケーション制御機構２０は、メッセージエントリテーブル４５１に格納された依頼メッセージを取り込み、依頼された帳票番号に従って業務アプリケーション２２を呼び出し、非同期にバックグラウンド処理として帳票データの作成を行う。そして、業務アプリケーションのトランザクションと連携させて作成された帳票データを処理結果として結果管理テーブル４５３に格納する。

しばらく時間をおいて、端末５０より、受付時に発行された受付ＩＤをキーとして、処理結果の取得依頼を行う。処理結果取り出し機構３０は、結果管理テーブル４５３より、依頼された受付ＩＤをキーとして処理結果を取得し業務アプリケーション３２を呼び出し、編集した結果を端末５０に応答メッセージとして返却する。

端末５０は、受け取った帳票データをプリンタで印刷する。
以上のようにして、非同期業務処理形態の帳票発行業務が行われる。
最後に、図１６により、まとめとして本発明の特徴点を説明するとともに、帳票ファイルを用いた帳票発行業務の実施例２について説明する。

本発明は、依頼メッセージと応答メッセージを対応付ける受付ＩＤを設ける。また、非同期メッセージ管理機構４０において、メッセージ及び処理状態をデータベースで管理し不揮発化を実現する。さらに、業務データベース２５とメッセージ管理データベース４５を同一のデータベースに配置し、非同期メッセージ管理と連携したトランザクション制御により、業務データベース２５及びメッセージとその処理状態を保証する。

そして、業務ロジック実装を容易にするため、制御処理機構を分離実装する。図１６に示すように、メッセージ受付部Ａはメッセージ受付機構１０と業務アプリケーション１２に分離され、トランザクション連携アプリケーション制御部Ｂはトランザクション連携アプリケーション制御機構２０と業務アプリケーション２２に、結果確認部Ｃは処理結果取り出し機構３０と業務アプリケーション３２に分離されている。各業務アプリケーションは受付ＩＤを意識する必要はなく、制御処理機構が受付ＩＤを用いてトランザクション制御、管理を行う。

なお、分離された制御機構と業務アプリケーションの間の編集メッセージ等の情報の受け渡しには、記憶装置上のワークエリアやそのアドレスを示すレジスタ等を用いて行うことは勿論である。

次に、帳票ファイル２６を用いた実施例２について、業務アプリケーション２２と業務アプリケーション３２を中心に説明する。実施例２は、業務アプリケーション２２と業務アプリケーション３２の部分を除けば実施例１と同様である。

業務アプリケーション２２は業務データベース２５を用いて帳票データを作成し、作成した帳票データを帳票ファイル２６に格納するとともに、当該格納された帳票データへのアクセス情報を処理結果メッセージとしてトランザクション連携アプリケーション制御２０に返す。トランザクション連携アプリケーション制御機構２０は、当該処理結果メッセージを結果管理テーブル４５３に格納する。処理結果取り出し機構３０は、結果確認依頼を受け付けると結果管理テーブル４５３から前記処理結果メッセージを取り出し、業務アプリケーション３２を呼び出し、当該処理結果メッセージを渡す。業務アプリケーション３２は、処理結果メッセージに含まれる帳票データへのアクセス情報を用いて帳票ファイル２６から帳票データを取り出し、処理結果メッセージを編集して処理結果取り出し機構３０に渡す。処理結果取り出し機構３０は、編集された処理結果メッセージをクライアントに返信する
上記のように業務アプリケーションを構成することにより、実施例２では帳票データ自体を結果管理テーブルに格納することを避けることができるので、帳票データのデータ量が大量であるような業務に適用すると効果的である。

以上詳細に説明したように、本発明の提供する制御機構がトランザクション制御を実行するので、依頼メッセージを受け付ける業務アプリケーション、依頼メッセージで依頼される業務を実行する業務アプリケーション及び処理結果メッセージを編集する業務アプリケーションはトランザクション制御から開放され、したがってその開発負担が大幅に軽減される。

各制御機構である、メッセージ受付機構、トランザクション連携アプリケーション制御機構及び処理結果取り出し機構は、上記それぞれについての説明から明らかなように、コンピュータにそれぞれの機能を実行させるプログラムにより実現可能であり、それらのプログラムは、上述の各業務アプリケーションのためにトランザクション制御を行うミドルウェアあるいはプラットフォームとして汎用性を持つものであり、各種業務の非同期業務処理形態のトランザクション処理システムに適用可能である。

（付記１）依頼メッセージの本文と当該依頼メッセージの処理状態及び前記依頼に対する処理結果メッセージを管理するメッセージ管理データベースと業務データベースを備え、非同期業務処理形態のトランザクション処理を実行するコンピュータに、
未処理メッセージの取り込み要求によりトランザクションを開始するステップと、
前記メッセージ管理データベースから前記未処理メッセージを取り出すステップと、
前記未処理メッセージと前記業務データベースを用いて業務処理を実行し前記業務データベースの仮更新を行うとともに処理結果メッセージを作成する業務アプリケーションを呼び出すステップと、
前記業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新するステップと、
前記メッセージ管理データベース上の前記未処理メッセージの処理状態を処理済みに仮更新するステップと、
前記業務データベースと前記メッセージ管理データベースの実更新を行ってトランザクションを終了するステップと、
を実行させることを特徴とするトランザクション制御プログラム。
（付記２）前記業務アプリケーションは業務処理結果が正常終了であるか異常終了であるかを報告するものであり、前記業務アプリケーションを呼び出すステップに続いて業務処理結果の報告を受け取るステップと、
前記報告を判定するステップと、
前記報告が異常終了を示す場合に、
前記業務アプリケーションによる業務データベースの仮更新を取り消してトランザクションをキャンセルするステップと、
再びトランザクションを開始するステップと、
前記メッセージ管理データベース上の前記未処理メッセージの処理状態をエラー処理済みに仮更新するステップと
異常処理結果メッセージを前記メッセージ管理データベースへの格納を仮更新するステップと、
前記メッセージ管理データベースの実更新を行ってトランザクションを終了するステップと、
を前記コンピュータに実行させ、
前記報告が正常終了を示す場合に、
前記業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新するステップ以降のステップ
を前記コンピュータに実行させることを特徴とする請求項１に記載のトランザクション制御プログラム。
（付記３）前記メッセージ管理データベースと業務データベースは、同一のデータベース上に配置されたことを特徴とする付記１又は付記２に記載のトランザクション制御プログラム。
（付記４） 前記依頼メッセージには、当該依頼メッセージを一意に識別する受付ＩＤが付与されており、前記メッセージ管理データベースで管理される依頼メッセージの本文と当該依頼メッセージの処理状態及び前記依頼に対する処理結果メッセージは、前記受付ＩＤで関連づけられて管理されることを特徴とする付記１又は付記２記載のトランザクション制御プログラム。
（付記５） 依頼メッセージの本文と当該依頼メッセージの処理状態及び前記処理依頼に対する処理結果メッセージを管理するメッセージ管理データベースと業務データベースを備え、非同期業務処理形態のトランザクション処理を実行するコンピュータのトランザクション制御方法において、
未処理メッセージの取り込み要求によりトランザクションを開始するステップと、
前記メッセージ管理データベースから前記未処理メッセージを取り出すステップと、前記未処理メッセージと前記業務データベースを用いて業務処理を実行し前記業務データベースの仮更新を行うとともに処理結果メッセージを作成する業務アプリケーションを呼び出すステップと、
前記業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新するステップと、
前記メッセージ管理データベース上の前記未処理メッセージの処理状態を処理済みに仮更新するステップと、
前記業務データベースと前記メッセージ管理データベースの実更新を行ってトランザクションを終了するステップと、
を実行することを特徴とするトランザクション制御方法。
（付記６） 前記業務アプリケーションは業務処理結果が正常終了であるか異常終了であるかを報告するものであり、前記業務アプリケーションを呼び出すステップに続いて業務処理結果の報告を受け取るステップと、
前記報告を判定するステップと、
前記報告が異常終了を示す場合に、
前記業務アプリケーションによる業務データベースの仮更新を取り消してトランザクションをキャンセルするステップと、
再びトランザクションを開始するステップと、
前記メッセージ管理データベース上の前記未処理メッセージの処理状態をエラー処理済みに仮更新するステップと
異常処理結果メッセージを前記メッセージ管理データベースへの格納を仮更新するステップと、
前記メッセージ管理データベースの実更新を行ってトランザクションを終了するステップと、
を実行し、
前記報告が正常終了を示す場合に、
前記業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新するステップ以降のステップ
を実行することを特徴とする付記５に記載のトランザクション制御方法。
（付記７） 前記メッセージ管理データベースと業務データベースは、同一のデータベース上に配置されたことを特徴とする付記５又は付記６に記載のトランザクション制御方法。
（付記８） 前記依頼メッセージには、当該依頼メッセージを一意に識別する受付ＩＤが付与されており、前記メッセージ管理データベースで管理される依頼メッセージの本文と当該依頼メッセージの処理状態及び前記依頼に対する処理結果メッセージは、前記受付ＩＤで関連づけられて管理されることを特徴とする付記５又は付記６記載のトランザクション制御プログラム
（付記９） 前記未処理メッセージの取り込み要求は、前記依頼メッセージを前記メッセージ管理データベースに格納するトランザクションの終了時と前記コンピュータの起動時及び起動後一定時間間隔で発生することを特徴とする付記５又は付記６記載のトランザクション制御方法
（付記１０） 非同期業務処理形態のトランザクション処理を実行するトランザクション処理システムにおいて、
メッセージ受付部と、トランザクション連携アプリケーション制御部と、結果確認部と、依頼メッセージの本文と当該依頼メッセージの処理状態及び前記処理依頼に対する処理結果メッセージを管理するメッセージ管理データベースとを備え、
前記メッセージ受付部は、業務ロジックによるメッセージ受付及び編集処理を行う第１の業務アプリケーションと、クライアントから依頼メッセージを受信すると前記第１の業務アプリケーションを呼び出し、当該第１の業務アプリケーションが編集した編集メッセージに受付ＩＤを付与して前記メッセージ管理データベースに格納し、当該受付ＩＤを前記クライアントに返送するとともに未処理メッセージの取り込み要求を行うメッセージ受付機構を含み、
前記トランザクション連携アプリケーション制御部は、業務ロジックにより前記編集メッセージの処理を行い、処理結果メッセージを作成する第２の業務アプリケーションと、前記未処理メッセージの取り込み要求によりトランザクションを開始し、前記メッセージ管理データベースから未処理状態の編集メッセージを取り出して前記第２の業務アプリケーションを呼び出し、当該第２の業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新し、前記メッセージ管理データベース上の前記未処理メッセージの処理状態を処理済みに仮更新し、前記メッセージ管理データベースの実更新を行ってトランザクションを終了するトランザクション連携アプリケーション制御機構を含み、
前記結果確認部は、前記処理結果メッセージを業務ロジックにより編集する第３の業務アプリケーションと、前記クライアントから前記依頼メッセージの受付ＩＤを指定した処理結果照会メッセージを受信すると当該受付ＩＤを持つ処理結果メッセージを前記メッセージ管理データベースより取り出して前記第３の業務アプリケーションを呼び出し、編集済みの処理結果メッセージを前記クライアントに送信する処理結果取り出し機構を含むことを特徴とするトランザクション処理システム。
（付記１１） 前記第２の業務アプリケーションが使用して業務処理を実行し仮更新を行う業務データベースを備え、前記トランザクション連携アプリケーション制御機構は、前記業務データベースの実更新と前記メッセージ管理データベースの実更新を一つのトランザクションにおいて実行することを特徴とする付記１０に記載のトランザクション処理システム。
（付記１２） 前記業務データベースとメッセージ管理データベースは、同一のデータベース上に配置されたことを特徴とする付記１１に記載のトランザクション処理システム。
（付記１３） 帳票データを格納する帳票ファイルを備え、前記第２の業務アプリケーションは、前記業務データベースを用いて作成した前記帳票データを前記帳票ファイルに格納するとともに当該帳票データへのアクセス情報を前記処理結果メッセージとして作成し、前記第３の業務アプリケーションは、当該処理結果メッセージのアクセス情報に基づいて前記帳票ファイルから帳票データを読み出して前記処理結果メッセージを編集することを特徴とする付記１２記載のトランザクション処理システム。

本発明のトランザクション処理システム全体構成図。 メッセージ受付機構概要説明図。 メッセージ受付機構処理フロー説明図。 トランザクション連携アプリケーション制御機構処理概要説明図。 トランザクション連携アプリケーション制御機構処理フロー説明図。 業務処理が正常終了時のトランザクション制御説明図。 業務処理が異常終了時のトランザクション制御説明図。 処理結果取り出し機構概要説明図。 処理結果取り出し機構処理フロー説明図。 非同期メッセージ管理機構概要説明図。 非同期メッセージ管理機構のメッセージ管理データベース構成説明図。 非同期メッセージ管理機構のメッセージ状態遷移説明図。 サーバダウン時からの復旧の全体制御フロー図。 サーバダウン再開時の要求メッセージ取り出し説明図。 本発明を帳票発行業務に適用した実施例１の説明図。 本発明を帳票発行業務に適用した実施例２の説明図。 帳票出力を伴うオンラインリアルタイム処理システム構成図。 非同期業務処理形態のトランザクション処理システム構成図。

符号の説明

１０ メッセージ受付機構
１２ 業務アプリケーション
２０ トランザクション連携アプリケーション制御機構
２２ 業務アプリケーション
２５ 業務用データベース
３０ 処理結果取り出し機構
３２ 業務アプリケーション
４０ 非同期メッセージ管理機構
４５ メッセージ管理データベース
４５１ メッセージエントリテーブル
４５２ 状態管理テーブル
４５３ 結果管理テーブル

Claims (5)

1. 依頼メッセージの本文と当該依頼メッセージの処理状態及び前記依頼に対する処理結果メッセージを管理するメッセージ管理データベースと業務データベースを備え、非同期業務処理形態のトランザクション処理を実行するコンピュータに、
   未処理メッセージの取り込み要求によりトランザクションを開始するステップと、
   前記メッセージ管理データベースから前記未処理メッセージを取り出すステップと、
   前記未処理メッセージと前記業務データベースを用いて業務処理を実行し前記業務データベースの仮更新を行うとともに処理結果メッセージを作成する業務アプリケーションを呼び出すステップと、
   前記業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新するステップと、
   前記メッセージ管理データベース上の前記未処理メッセージの処理状態を処理済みに仮更新するステップと、
   前記業務データベースと前記メッセージ管理データベースの実更新を行ってトランザクションを終了するステップと、
   を実行させることを特徴とするトランザクション制御プログラム。
2. 前記業務アプリケーションは業務処理結果が正常終了であるか異常終了であるかを報告するものであり、前記業務アプリケーションを呼び出すステップに続いて業務処理結果の報告を受け取るステップと、
   前記報告を判定するステップと、
   前記報告が異常終了を示す場合に、
   前記業務アプリケーションによる業務データベースの仮更新を取り消してトランザクションをキャンセルするステップと、
   再びトランザクションを開始するステップと、
   前記メッセージ管理データベース上の前記未処理メッセージの処理状態をエラー処理済みに仮更新するステップと
   異常処理結果メッセージを前記メッセージ管理データベースへの格納を仮更新するステップと、
   前記メッセージ管理データベースの実更新を行ってトランザクションを終了するステップと、
   を前記コンピュータに実行させ、
   前記報告が正常終了を示す場合に、
   前記業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新するステップ以降のステップ
   を前記コンピュータに実行させることを特徴とする請求項１に記載のトランザクション制御プログラム。
3. 前記メッセージ管理データベースと業務データベースは、同一のデータベース上に配置されたことを特徴とする請求項１又は請求項２に記載のトランザクション制御プログラム。
4. 依頼メッセージの本文と当該依頼メッセージの処理状態及び前記処理依頼に対する処理結果メッセージを管理するメッセージ管理データベースと業務データベースを備え、非同期業務処理形態のトランザクション処理を実行するコンピュータのトランザクション制御方法において、
   未処理メッセージの取り込み要求によりトランザクションを開始するステップと、
   前記メッセージ管理データベースから前記未処理メッセージを取り出すステップと、前記未処理メッセージと前記業務データベースを用いて業務処理を実行し前記業務データベースの仮更新を行うとともに処理結果メッセージを作成する業務アプリケーションを呼び出すステップと、
   前記業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新するステップと、
   前記メッセージ管理データベース上の前記未処理メッセージの処理状態を処理済みに仮更新するステップと、
   前記業務データベースと前記メッセージ管理データベースの実更新を行ってトランザクションを終了するステップと、
   を実行することを特徴とするトランザクション制御方法。
5. 非同期業務処理形態のトランザクション処理を実行するトランザクション処理システムにおいて、
   メッセージ受付部と、トランザクション連携アプリケーション制御部と、結果確認部と、依頼メッセージの本文と当該依頼メッセージの処理状態及び前記処理依頼に対する処理結果メッセージを管理するメッセージ管理データベースとを備え、
   前記メッセージ受付部は、業務ロジックによるメッセージ受付及び編集処理を行う第１の業務アプリケーションと、クライアントから依頼メッセージを受信すると前記第１の業務アプリケーションを呼び出し、当該第１の業務アプリケーションが編集した編集メッセージに受付ＩＤを付与して前記メッセージ管理データベースに格納し、当該受付ＩＤを前記クライアントに返送するとともに未処理メッセージの取り込み要求を行うメッセージ受付機構を含み、
   前記トランザクション連携アプリケーション制御部は、業務ロジックにより前記編集メッセージの処理を行い、処理結果メッセージを作成する第２の業務アプリケーションと、前記未処理メッセージの取り込み要求によりトランザクションを開始し、前記メッセージ管理データベースから未処理状態の編集メッセージを取り出して前記第２の業務アプリケーションを呼び出し、当該第２の業務アプリケーションから前記処理結果メッセージを受け取り前記メッセージ管理データベースへの格納を仮更新し、前記メッセージ管理データベース上の前記未処理メッセージの処理状態を処理済みに仮更新し、前記メッセージ管理データベースの実更新を行ってトランザクションを終了するトランザクション連携アプリケーション制御機構を含み、
   前記結果確認部は、前記処理結果メッセージを業務ロジックにより編集する第３の業務アプリケーションと、前記クライアントから前記依頼メッセージの受付ＩＤを指定した処理結果照会メッセージを受信すると当該受付ＩＤを持つ処理結果メッセージを前記メッセージ管理データベースより取り出して前記第３の業務アプリケーションを呼び出し、編集済みの処理結果メッセージを前記クライアントに送信する処理結果取り出し機構を含むことを特徴とするトランザクション処理システム。