JP4094752B2 - トランザクション処理方法及びその実施装置並びにその処理プログラムを記録した媒体 - Google Patents
トランザクション処理方法及びその実施装置並びにその処理プログラムを記録した媒体 Download PDFInfo
- Publication number
- JP4094752B2 JP4094752B2 JP33669998A JP33669998A JP4094752B2 JP 4094752 B2 JP4094752 B2 JP 4094752B2 JP 33669998 A JP33669998 A JP 33669998A JP 33669998 A JP33669998 A JP 33669998A JP 4094752 B2 JP4094752 B2 JP 4094752B2
- Authority
- JP
- Japan
- Prior art keywords
- processing
- transaction
- recovery
- workflow
- flow
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1474—Saving, restoring, recovering or retrying in transactions
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はワークフローに従って一連のトランザクション処理を実行するトランザクション処理システムに関し、特にトランザクション実行中に障害が発生した場合に回復処理を行うトランザクション処理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
ホテルと航空券の予約が必要な旅行予約システムや、複数の銀行の口座間で送金をする様なシステムにおいては、チャネルからの要求に対して複数のサーバにアクセスしてトランザクション処理を行う必要がある。トランザクション処理とは、原子性、一貫性、隔離性、耐久性という性質を持つプログラムを実行することである。トランザクション処理については、例えば、「トランザクション処理システム入門」（フィリップ・Ａ・バーンスタイン、エリック・ニューカマー著、日経ＢＰ社）で紹介されている。また、本明細書においては、これ以降、ワークフロー制御システムに要求メッセージを送信するシステムを総称して「チャネル」と呼ぶことにする。
【０００３】
一連の処理を一つのトランザクションで実行しようとすると、各サーバにおいてトランザクションが終了するまでの期間、該当するデータをロックしておく必要がある。この為、他の処理が長時間待たされ、性能上問題となる場合がある。そこで一連の処理を各サーバへのアクセス毎のトランザクションに分割し、複数のトランザクションから成るワークフローとして実行することが一般的に行われる。
【０００４】
この様なシステムにおいては、ワークフローの実行中に障害が発生した場合、障害発生時点までに行った一連のトランザクション処理を取消す回復処理が必要である。この為従来は各トランザクションにおいて行った処理の内容を履歴としてキューに登録し、障害発生時にはこのキューの後尾から一つずつ順に履歴情報を取出して各トランザクションに対する補償処理を行っていた。この様なシステムは、例えば「トランザクション処理システム入門」（フィリップ・Ａ・バーンスタイン、エリック・ニューカマー著、日経ＢＰ社、１１１頁）で紹介されている。
【０００５】
【発明が解決しようとする課題】
前記従来の方式において、補償処理によってトランザクションが取消されるまでの間に別のトランザクションが同じサーバに対して処理を行った場合、そのトランザクションは取消されるべきトランザクションの結果に影響を受けることになる。例えばホテルの予約を行うトランザクションでは、キャンセルにより空きが生じるまでの間、満室の為予約できない状態が続くことになる。従って、回復処理に要する時間はできるだけ短いほうが望ましい。
【０００６】
従来の方式によれば、分岐により並列に実行されたトランザクションを回復する場合にも、一つずつ補償トランザクションが実行される。従って、一連のトランザクションに関する回復処理を完了するまでに多くの時間を要するという問題があった。
【０００７】
本発明の目的は上記問題を解決し、回復処理の効率を向上させることが可能な技術を提供することにある。
本発明の他の目的はトランザクション処理システムが複数のチャネルから同時に要求メッセージを受信して処理を行う場合にも効率的な回復処理を行うことが可能な技術を提供することにある。
【０００８】
【課題を解決するための手段】
本発明は、ワークフローに従って一連のトランザクションを実行するトランザクション処理システムにおいて、障害回復を行う為の回復処理フローまたは実行した処理内容を示す履歴情報をトランザクション実行時に登録し、トランザクション実行中に障害が発生した場合に、前記登録した回復処理フローまたは履歴情報に従って一連の補償処理を並列に実行するものである。
【０００９】
本発明のトランザクション処理システムでは、ワークフローに従ってトランザクションを実行すると共に、トランザクション実行中に障害が発生した場合の障害回復を行う補償処理をトランザクションの実行時に回復処理フローとして登録しておく。
【００１０】
その際、ワークフローに従って分岐処理を行うときにはその分岐処理に対応させて待合せ処理を回復処理フローに登録し、ワークフローに従って待合せ処理を行うときにはその待合わせ処理に対応させて分岐処理を回復処理フローに登録しておく。
【００１１】
トランザクション実行中に障害が発生した場合には、前記登録しておいた回復処理フローに従って一連の補償処理を実行する。ワークフローの正常処理フローに対応して回復処理フローが生成されるので、トランザクション実行中に分岐処理により並列に実行された部分は補償処理でも並列に実行され、補償処理が高速に実行される。
【００１２】
また本発明のトランザクション処理システムでは、ワークフローに従ってトランザクションを実行すると共に、トランザクションの実行内容を示す履歴情報を登録しておく。
【００１３】
トランザクション実行中に障害が発生した場合には前記登録しておいた履歴情報を取出し、履歴情報中のトランザクションの内容毎に補償トランザクションを並列に実行する。このときワークフローのパスや送信先毎に補償トランザクションを並列化することとしても良い。前記の様に履歴情報に従って補償トランザクションが並列に実行されるので、補償処理が高速に実行される。
【００１４】
以上の様に本発明のトランザクション処理システムによれば、正常処理フローの分岐により生じたパス毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【００１５】
【発明の実施の形態】
（実施形態１）
以下に正常処理フローにおいて分岐したパス毎に回復処理を並列化する実施形態１のトランザクション処理システムについて説明する。
図１は本実施形態のワークフロー制御システムのソフトウェア構成を示す図である。本実施形態では、ワークフロー制御システム内のソフトウェアを構成する各コンポーネントをオブジェクトとして実装した場合について説明する。
【００１６】
図２は本実施形態のトランザクション処理システムのハードウェア構成を示す図である。本実施形態のシステムは、ワークフロー制御システム２０１と、このシステムにネットワーク２１５〜２１８で接続されたチャネル２０９及びサーバ２１０〜２１２とで構成される。
【００１７】
ワークフロー制御システム２０１は、チャネル２０９からの要求メッセージを解釈し、サーバ２１０〜２１２に対してトランザクションを要求しながら、チャネル２０９からの要求を満たす為の処理を行うシステムである。チャネル２０９は、ユーザからの要求に従ってワークフロー制御システム２０１に要求メッセージを送信するシステムである。サーバ２１０〜２１２は、ワークフロー制御システム２０１からの要求に従ってトランザクションを実行するシステムである。ここでは、サーバ２１０〜２１２がそれぞれ別のサービスを提供していると仮定する。本実施形態では、チャネルが１つとサーバが３つ接続された構成を示しているが、より多くのチャネル及びサーバを接続した構成としても良い。
【００１８】
ワークフロー制御システム２０１は、ＣＰＵ２０２、メモリ２０３、ハードディスク装置２０４、ネットワーク・インタフェース・コントローラ２０５〜２０８、入力装置２１３、出力装置２１４で構成される。ハードディスク装置２０４には、ワークフローに従って処理を行う為のソフトウェア群が保存されており、これらのソフトウェアはメモリ２０３にロードされてＣＰＵ２０２により実行される。ネットワーク・インタフェース・コントローラ２０５〜２０８は、ネットワーク２１５〜２１８に対するインタフェースを制御し、チャネル２０９及びサーバ２１０〜２１２と接続する。
【００１９】
次に本実施形態のワークフロー制御システム２０１のソフトウェア構成について図１を用いて説明する。ワークフロー制御システム２０１は、オブジェクト・リクエスト・ブローカであるＯＲＢ１０１と、トレーダ１０７と、アダプタ１０３〜１０６と、通番管理プログラム１０８と、ワークフロー実行プログラム１０２とで構成される。
【００２０】
ＯＲＢ１０１は、オブジェクト間のリクエストと、その応答の送受信を可能にするメッセージング機構を提供する。ワークフロー制御システム２０１内の各コンポーネントは、ＯＲＢ１０１を使用して他のコンポーネントとの間で通信を行う。
【００２１】
トレーダ１０７は、各コンポーネントのサービス内容からオブジェクトを検索する為の仕組みを提供する。アダプタ１０３〜１０６、ワークフロー実行プログラム１０２は、自分の提供するサービス内容をトレーダ１０７に登録する。また、メッセージ送信時にはトレーダ１０７によりサービスを検索して送信先のオブジェクト・リファレンスを受け取る。オブジェクト・リファレンスは、対象になるオブジェクトを一意に識別する為の情報を含んだデータである。各オブジェクトは、オブジェクト・リファレンスを使用して対象となるオブジェクトへのメッセージの送信をＯＲＢに要求する。
【００２２】
アダプタ１０３〜１０６は、チャネル２０９及びサーバ２１０〜２１２と、ワークフロー実行プログラム１０２との間でのメッセージの転送を行うコンポーネントである。アダプタ１０３〜１０６は、それぞれ異なるプロトコルでチャネル２０９やサーバ２１０〜２１２と接続されており、ネットワーク２１５〜２１８を介してチャネル２０９やサーバ２１０〜２１２と接続する為のプロトコルの制御及びメッセージフォーマットの変換を行う。
【００２３】
通番管理プログラム１０８は、ワークフロー制御システム２０１内で転送されるメッセージに固有の番号を与える為のコンポーネントである。通番管理プログラム１０８では、シーケンシャルに番号を管理しており、各コンポーネントからの要求を受けてワークフロー制御システム２０１内で一意な番号を返す。各コンポーネントは、通番管理プログラム１０８から受け取った通番でメッセージに番号を付ける。
【００２４】
ワークフロー実行プログラム１０２は、チャネル２０９から要求メッセージを受信し、ワークフローに従ってサーバ２１０〜２１２にトランザクションの処理を依頼してチャネル２０９からの要求を処理するコンポーネントである。
【００２５】
ワークフロー実行プログラム１０２は、チャネル２０９からの要求を受け付ける要求受付プログラム１０９と、要求内容や処理の中間データを保存する為の業務ＤＢ１１０と、ワークフローに従ってトランザクションを起動するワークフロー制御プログラム１１１と、ワークフローを保存する為のワークフロー管理ＤＢ１１８と、ワークフロー制御プログラム１１１から起動され、サーバ２１０〜２１２に対して処理を要求するトランザクション要求処理プログラム１１２〜１１４と、ワークフロー制御プログラム１１１から起動され、チャネル２０９へ応答メッセージを送信する応答処理プログラム１１５と、ワークフロー管理ＤＢ１１８にワークフローを登録する為のワークフロー登録処理プログラム１１７と、ワークフローの実行中に障害が発生した場合に回復処理を行う回復処理プログラム１１６とで構成される。
【００２６】
図３は本実施形態の要求処理プログラム１１２〜１１４及び応答処理プログラム１１５の概略構成を示す図である。図３に示す様に本実施形態のワークフロー制御システム２０１は、正常処理部３０２と、補償処理部３０３とを有している。
【００２７】
正常処理部３０２は、トランザクション実行中に障害が発生した場合の障害回復を行う補償処理をトランザクションの実行時に回復処理フロー１２０として登録する処理部である。補償処理部３０３は、トランザクション実行中に障害が発生した場合に前記登録した回復処理フロー１２０に従って一連の補償処理を並列に実行する処理部である。
【００２８】
ワークフロー制御システム２０１を正常処理部３０２及び補償処理部３０３として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する媒体はＣＤ−ＲＯＭ以外の他の媒体でも良い。
【００２９】
図３の処理プログラム３０１に示す様にトランザクション要求処理プログラム１１２〜１１４及び応答処理プログラム１１５は、サーバ２１０〜２１２に対してトランザクションを要求する為の正常処理部３０２と、正常に実行されたトランザクションを取消す為の補償処理部３０３とで構成される。
【００３０】
ワークフロー管理ＤＢ１１８及び業務ＤＢ１１０は、ハードディスク装置２０４に保存される。ワークフロー管理ＤＢ１１８には、正常時のワークフローを記述した正常処理フロー１１９と、障害発生時に実行される回復処理フロー１２０とが保存される。業務ＤＢ１１０には図４に示す様な業務ＤＢテーブルが保存される。
【００３１】
図４は本実施形態の業務ＤＢテーブルの一例を示す図である。業務ＤＢテーブル４００の一つの行は、要求メッセージに付与された要求通番４０１と、要求内容４０２と、正常処理フロー１１９を識別する為の正常処理フローＩＤ４０３と、回復処理フロー１２０を識別する為の回復処理フローＩＤ４０４と、サーバ２１０〜２１２で各トランザクションに対して付けられる処理番号４０５，４０７及び４０９と、サーバ２１０〜２１２からの応答メッセージで得られたデータ４０６，４０８及び４１０と、チャネル２０９に対する応答番号４１１と、応答内容４１２とを格納する列を持つ。
【００３２】
ワークフロー制御システム２０１の運用者は、予め入力装置２１３から正常処理フロー１１９を登録する。ワークフロー登録処理プログラム１１７は、ワークフローを登録する為のコマンドやＧＵＩを提供し、入力されたワークフローをワークフロー管理ＤＢ１１８の正常処理フロー１１９に登録する。ワークフローの登録時に運用者は、ワークフローを一意に識別する為の正常処理フローＩＤ４０３を付ける。このＩＤによりワークフロー制御プログラム１１１は、正常処理フロー１１９に登録された複数のワークフローを管理することができる。この様にして定義された正常処理フロー１１９の例を図５に示す。
【００３３】
図５は本実施形態の正常処理フロー１１９の一例を示す図である。ワークフロー中のトランザクションを記述したノード５０１，５０５，５０６及び５１２には、対応するトランザクションを実行する為のプログラムを定義する。
【００３４】
本実施形態では、各トランザクションに対応してトランザクション処理プログラム３０１を用意し、その正常処理部３０２をオブジェクトとして実装する。そして、これらのオブジェクトを各ノードで起動するオブジェクトとして定義する。回復処理ノード５０４，５１０，５１１及び５１４には、起動するオブジェクトとして回復処理プログラム１１６を定義しておく。回復処理ノードに定義する内容は、ワークフロー中のどの位置にあっても全て同一の内容を設定することができる。
【００３５】
以下では、チャネル２０９から要求メッセージを受信し、図５に示したワークフローに従って処理を行う場合の動作について説明する。アダプタ１０３は、チャネル２０９から要求メッセージを受信し、通番管理プログラム１０８により要求メッセージに対する通番を取得し、この通番をメッセージに付加する。次にトレーダ１０７により、要求受付プログラム１０９のオブジェクト・リファレンスを取得し、そのオブジェクト・リファレンスを使用して要求受付プログラム１０９へ要求メッセージを送信する。
【００３６】
要求受付プログラム１０９は、アダプタ１０３から要求メッセージを受信し、業務ＤＢテーブル４００に要求通番４０１及び要求内容４０２を登録する。そして、要求メッセージの内容を元に要求に対応する正常処理フロー１１９を決定し、その正常処理フロー１１９を識別する為の正常処理フローＩＤ４０３を登録する。また回復処理フロー１２０を識別する為の回復処理フローＩＤ４０４を生成して登録する。その後、正常処理フロー１１９の実行をワークフロー制御プログラム１１１に要求する。このとき要求受付プログラム１０９は、入力として要求通番４０１と正常処理フローＩＤ４０３をワークフロー制御プログラム１１１へ渡す。
【００３７】
ワークフロー制御プログラム１１１は、要求されたワークフローをワークフロー管理ＤＢ１１８から読み出し、図５の様な正常処理フロー１１９に記述された内容に従って処理を進める。ワークフロー制御プログラム１１１は、ワークフロー中に記述された順にトランザクションを実行し、判定を行い、分岐、待合せ処理を行う。ワークフロー中のトランザクションノードには、そのトランザクションで起動すべき正常処理部３０２が定義されており、ワークフロー制御プログラム１１１は、定義されている正常処理部３０２をトランザクションの実行時に起動する。
【００３８】
図５の正常処理フロー１１９に従って、ワークフロー制御プログラム１１１は、ワークフローの実行を開始し、トランザクション１を実行する為にトランザクション１要求処理プログラム１１２の正常処理部３０２を起動する（ノード５０１）。
【００３９】
図６は本実施形態のトランザクション要求処理プログラム１１２〜１１４の正常処理部３０２の処理手順を示すフローチャートである。正常処理部３０２は図６の手順に従って処理を行う。ここで図６を用いて正常処理部３０２の処理手順について説明する。
【００４０】
ワークフロー制御プログラム１１１は、入力として要求通番４０１を正常処理部３０２へ渡す。正常処理部３０２は、業務ＤＢテーブル４００の要求通番４０１に該当する行の内容を読み出し、要求された処理に必要なサービスへの要求メッセージを作成する。そして、必要なサービスを提供するサーバに接続しているアダプタのオブジェクト・リファレンスをトレーダ１０７により取得して、要求メッセージを送信する（ステップ７０１）。
【００４１】
例えばトランザクション１要求処理プログラム１１２の正常処理部３０２は、サーバ２１０に接続されたアダプタ１０４のオブジェクト・リファレンスを取得して要求メッセージを送信する。アダプタ１０４は、要求メッセージを受信すると、ネットワーク２１６を介してサーバ２１０にそのメッセージを送信する。サーバ２１０は、要求メッセージを受信し、要求された処理を行った後、サーバ２１０で付けた処理番号と処理結果のデータを含む応答メッセージをアダプタ１０４に送信する。アダプタ１０４は、サーバ２１０からの応答メッセージを受信し、トランザクション１要求処理プログラム１１２の正常処理部３０２に送信する。
【００４２】
正常処理部３０２は、アダプタ１０４から応答メッセージを受信し、業務ＤＢテーブル４００に処理番号４０５と応答メッセージに含まれるデータ４０６を保存する（ステップ７０２）。次に正常処理部３０２は、要求メッセージに対する処理が正常に終了したかどうかを判定する（ステップ７０３）。正常に終了している場合に正常処理部３０２は、自分が行った処理を取消す為の補償トランザクションを回復処理フロー１２０に登録する（ステップ７０４）。
【００４３】
ワークフロー登録処理プログラム１１７は、正常処理部３０２に対して回復処理フロー１２０を登録する為のインタフェースを提供している。正常処理部３０２は、このインタフェースを使用して回復処理フロー１２０へ補償トランザクションを登録する。このとき正常処理部３０２は、業務ＤＢテーブル４００の回復処理フローＩＤ４０４を読み出し、そのＩＤを指定して登録を要求する。
【００４４】
ワークフロー登録処理プログラム１１７は、登録要求を受け取り、指定されたＩＤで識別される回復処理フロー１２０が未だ存在しない場合には新たに生成し、補償トランザクションの実行を記述したノードを登録する。補償トランザクションは、補償処理部３０３を起動するという作業によって記述される。最後に正常処理部３０２は、正常終了をワークフロー制御プログラム１１１に報告して（ステップ７０５）、処理を終了する。
【００４５】
ステップ７０３で判定した結果、サーバ２１０に対する要求が正常に終了していなかった場合、正常処理部３０２は、異常終了をワークフロー制御プログラム１１１に報告して処理を終了する（ステップ７０６）。
【００４６】
図７は本実施形態の回復処理フロー１２０の例を示す図である。図７ではトランザクション１（ノード５０１）の処理が終了した時点で登録されている回復処理フロー１２０を表している。
【００４７】
ワークフロー登録処理プログラム１１７は、補償トランザクションの登録を要求されると、渡されたＩＤを持つ回復処理のフローを生成し、ワークフロー管理ＤＢ１１８の回復処理フロー１２０に登録する。開始ノード６０１及び正常終了ノード６０４は、ワークフロー登録処理プログラム１１７によって、最初に回復処理フロー１２０を登録するときに付加される。補償処理１（ノード６０２）は、図６のステップ７０４で登録要求された補償トランザクションである。またこの例では、正常処理部３０２が補償トランザクションと共に判定ノード６０３及び異常終了ノード６０５を付加する例を示している。
【００４８】
ここで図５の正常処理フロー１１９に戻って説明を続ける。トランザクション１（ノード５０１）の処理が上で説明した様に終了すると、ワークフロー制御プログラム１１１は、トランザクション処理プログラム３０１からの終了報告を判定し（ノード５０２）、正常終了の場合には分岐処理を行う（ノード５０３）。トランザクション処理プログラム３０１が異常終了している場合には回復処理（ノード５０４）を実行する。回復処理については後で説明する。
【００４９】
図８は本実施形態の回復処理フロー１２０の例を示す図である。図８に示す様に分岐処理においてワークフロー制御プログラム１１１は、回復処理フロー１２０に待合せノード６０９、分岐ノード６０６、ＮＯＰ１（ノード６０７）、ＮＯＰ２（ノード６０８）を登録する。ＮＯＰ１及びＮＯＰ２は、何も処理を行わないことを示す。
【００５０】
ワークフロー制御プログラム１１１は、分岐後に並列実行されるパスの数を判断して、その数分のＮＯＰノードを登録する。その後、ワークフロー制御プログラム１１１は、トランザクション２とトランザクション３を並列に実行する。
【００５１】
ワークフロー制御プログラム１１１は、トランザクション２（ノード５０５）においてトランザクション２要求処理プログラム１１３を起動し、トランザクション３（ノード５０６）においてトランザクション３要求処理プログラム１１４を起動する。両トランザクション要求処理プログラムは図６と同様の手順で処理を行う。トランザクション２要求処理プログラム１１３は、サーバ２１１が提供するサービスをアダプタ１０５経由で要求し、トランザクション３要求処理プログラム１１４は、サーバ２１２が提供するサービスをアダプタ１０６経由で要求する。
【００５２】
各トランザクションによる処理結果は、トランザクション１（ノード５０１）のときと同じ様に業務ＤＢテーブル４００中に保存される。トランザクション２の処理結果は処理番号４０７とデータ４０８に、トランザクション３の処理結果は処理番号４０９とデータ４１０に保存される。
【００５３】
図９は本実施形態の回復処理フロー１２０の例を示す図である。図９では両トランザクションが終了した時点での回復処理フロー１２０を表している。
ワークフロー登録処理プログラム１１７は、各トランザクションからの登録要求を受けると、登録を要求されたトランザクションでＮＯＰノードを置き換える。図９において、補償処理２（ノード６１０）と補償処理３（ノード６１１）が、それぞれトランザクション２とトランザクション３の補償トランザクションである。また正常処理部３０２は補償トランザクションと共に判定ノード６１２及び６１４並びに異常終了ノード６１３及び６１５を付加している。
【００５４】
図５で両トランザクションの処理が終了すると、ワークフロー制御プログラム１１１はそれぞれのトランザクションに関して判定を行う（ノード５０７，５０８）。判定の結果、トランザクションが正常終了している場合には、待合せを行う（ノード５０９）。待合せ処理において、ワークフロー制御プログラム１１１は、二つの判定処理（ノード５０７，５０８）の両方が正常に終了したことを検出すると、次のトランザクションを処理する（ノード５１２）。トランザクション２またはトランザクション３が異常終了した場合については、後で説明する。
【００５５】
トランザクション４（ノード５１２）には、チャネル２０９への応答処理が定義されている。応答処理プログラム１１５は図３に示したトランザクション処理プログラム３０１と同様に、正常処理部３０２と補償処理部３０３とで構成される。但しトランザクション要求処理プログラムにおける正常処理部３０２及び補償処理部３０３とは動作が異なる。ワークフロー制御プログラム１１１は応答処理プログラム１１５における正常処理部３０２を起動する。
【００５６】
図１０は本実施形態の応答処理プログラム１１５における正常処理部３０２の処理手順を示すフローチャートである。応答処理プログラム１１５における正常処理部３０２は、図１０の手順に従って処理を行う。ここで図１０を用いて応答処理プログラム１１５における正常処理部３０２の処理について説明する。
【００５７】
ワークフロー制御プログラム１１１は、入力として要求通番４０１を正常処理部３０２へ渡す。正常処理部３０２は、要求通番４０１に該当する業務ＤＢ１１０の内容を読み出し、それらのデータを元にチャネル２０９への応答メッセージを生成し、通番管理プログラム１０８に要求してメッセージに通番を付ける（ステップ８０１）。
【００５８】
次に正常処理部３０２は、生成した応答メッセージをアダプタ１０３に送信する（ステップ８０２）。アダプタ１０３はネットワーク２１５経由でチャネル２０９へ応答メッセージを送信する。
【００５９】
次に正常処理部３０２は、これらの処理が正常に終了したかどうかを判定する（ステップ８０３）。正常に終了した場合には、業務ＤＢテーブル４００に応答メッセージの応答番号４１１と応答内容４１２を保存し、正常処理部３０２で行った応答メッセージによる処理を取消す為の補償トランザクションを回復処理フロー１２０に登録する（ステップ８０４）。そして正常終了をワークフロー制御プログラム１１１に報告して（ステップ８０５）処理を終了する。ステップ８０３の判定で異常が発生していると判断した場合には、異常終了をワークフロー制御プログラム１１１に報告して（ステップ８０６）処理を終了する。
【００６０】
図５でトランザクション４の処理が終了すると、ワークフロー制御プログラム１１１は判定を行う（ノード５１３）。判定の結果、トランザクション４が正常終了している場合には、ワークフロー制御プログラム１１１は処理を終了する。トランザクション４で異常終了した場合の処理については後で説明する。
【００６１】
図１１は本実施形態の回復処理フロー１２０の例を示す図である。図１１ではトランザクション４（ノード５１２）が終了した時点での回復処理フロー１２０を表している。応答処理プログラム１１５は、補償処理４（ノード６１６）、判定ノード６１７及び異常終了ノード６１８を登録している。
【００６２】
次に、トランザクションが異常終了した場合の処理について説明する。判定ノード５０２，５０７，５０８及び５１３においてトランザクションの異常終了を検出した場合、ワークフロー制御プログラム１１１は、回復処理プログラム１１６を起動する（ノード５０４，５１０，５１１及び５１４）。
【００６３】
このとき、ワークフロー制御プログラム１１１は、入力として要求通番４０１を回復処理プログラム１１６に渡す。回復処理プログラム１１６は、業務ＤＢテーブル４００の入力で与えられた要求通番４０１に該当する行から回復処理フロー１２０のＩＤを読み出し、その回復処理フロー１２０の実行をワークフロー制御プログラム１１１に要求する。回復処理プログラム１１６は、入力として要求通番４０１と回復処理フローＩＤ４０４をワークフロー制御プログラム１１１へ渡す。
【００６４】
回復処理フロー１２０は、図７〜図９及び図１１に示した様に、正常処理フロー１１９中のどの回復処理ノードで回復処理プログラム１１６が起動されたかによって異なる。ワークフロー制御プログラム１１１は、回復処理プログラム１１６からの要求を受け、入力で与えられた回復処理フローＩＤ４０４で識別される回復処理フロー１２０に従って、補償処理部３０３を起動しながら処理を行う。なお補償処理部３０３は、トランザクション要求処理プログラム１１２〜１１４と応答処理プログラム１１５とで処理手順が異なる。
【００６５】
図１２は本実施形態のトランザクション要求処理プログラム１１２〜１１４の補償処理部３０３の処理手順を示すフローチャートである。ここでトランザクション要求処理プログラム１１２〜１１４における補償処理部３０３の処理手順について図１２を用いて説明する。
【００６６】
ワークフロー制御プログラム１１１は、入力として要求通番４０１を補償処理部３０３へ渡す。補償処理部３０３は、与えられた要求通番４０１に該当する行の情報を業務ＤＢ１１０から読み出して処理を行う。
【００６７】
補償処理部３０３は、各トランザクションに対応する処理番号４０５，４０７及び４０９並びにサーバ２１０〜２１２からの応答メッセージに関するデータ４０６，４０８及び４１０を読み出し、トランザクションのキャンセルを要求する為のメッセージを生成してアダプタ１０４〜１０６に送信する（ステップ９０１）。
【００６８】
サーバ２１０〜２１２は、キャンセル要求メッセージに従って指定されたトランザクションをキャンセルし、応答メッセージをアダプタ１０４〜１０６に送信する。補償処理部３０３はサーバ２１０〜２１２からの応答メッセージを受信する（ステップ９０２）。そしてキャンセル処理が正常に終了したかどうかを判定する（ステップ９０３）。正常に終了している場合、正常終了をワークフロー制御プログラム１１１に報告する（ステップ９０４）。異常終了している場合、異常終了をワークフロー制御プログラム１１１に報告する（ステップ９０５）。
【００６９】
図１３は本実施形態の応答処理プログラム１１５の補償処理部３０３の処理手順を示すフローチャートである。応答処理プログラム１１５において補償処理部３０３は、図１３の手順に従って処理を行う。次に応答処理プログラム１１５における補償処理部３０３の処理手順について図１３を用いて説明する。
【００７０】
トランザクション要求処理プログラム１１２〜１１４に関する補償処理部３０３のときと同様に、ワークフロー制御プログラム１１１は入力として要求通番４０１を補償処理部３０３へ渡す。補償処理部３０３は、業務ＤＢ１１０から与えられた要求通番４０１に該当する行の情報を読み出して処理を行う。補償処理部３０３は、業務ＤＢ１１０から応答メッセージの応答番号４１１及び応答内容４１２を読み出して、この応答メッセージのキャンセルを要求する為のメッセージを生成してアダプタ１０３へ送信する（ステップ１００１）。
【００７１】
次に、送信処理が正常に終了したかどうかを判定する（ステップ１００２）。正常に終了した場合、正常終了をワークフロー制御プログラム１１１に報告する（ステップ１００３）。異常終了した場合は、ワークフロー制御プログラム１１１に異常終了を報告する（ステップ１００４）。
【００７２】
ワークフロー制御プログラム１１１は、判定ノードにおいて異常終了したと判定すると異常終了処理を行う。異常終了処理でワークフロー制御プログラム１１１は、回復処理が異常終了したことを示すメッセージを出力装置２１４に表示する。
【００７３】
以上で説明した様に本実施形態では、正常処理フロー１１９の実行時に各トランザクションにおいて、その補償トランザクションを回復処理フロー１２０に登録しながら処理を進める。そして障害により何れかのトランザクションが異常終了した場合には、その時点までに行ったトランザクションを回復処理フロー１２０に従って回復する。
【００７４】
本実施形態では、回復処理フロー１２０において補償処理トランザクションが異常終了した場合には、その時点で回復処理を終了する様にしたが、補償処理トランザクションの正常／異常終了に関わらず、次の補償処理トランザクションを実行する様な回復処理フロー１２０を生成することもできる。この為には正常処理部３０２が補償トランザクションだけを回復処理フロー１２０に登録し、判定ノード及び異常終了ノードの登録を行わない様にすれば良い。
【００７５】
また運用者が入力装置２１３からワークフロー制御プログラム１１１に対して回復処理フロー１２０の実行を要求する様にして、チャネル２０９からの要求メッセージに対する処理が正常に終了した後の任意の時点で回復処理を実行できる様にすることもできる。
【００７６】
本実施形態によればワークフロー制御システム２０１は、並列に実行されるパスを含む様なワークフローの実行中に回復処理の為のワークフローを動的に生成することができる。またワークフロー制御プログラム１１１が、回復処理フロー１２０に分岐処理及び待合せ処理を登録でき、並列に実行されるパスを生成することができる。そして障害が発生した場合には、この回復処理フロー１２０に従ってパス毎に回復処理を並列に実行することができる。従って回復処理に要する時間を短縮することができる。
【００７７】
更にワークフロー制御システム２０１が、要求通番４０１と回復処理フローＩＤ４０４との対応をデータベースにより管理しているので、チャネル２０９からの要求メッセージ毎に対応する回復処理フロー１２０を管理でき、複数のチャネルから同時に要求を受け付けて処理する場合にも障害が発生した要求メッセージに対応する回復処理を実行することができる。
【００７８】
以上説明した様に本実施形態のトランザクション処理システムによれば、正常処理フローの分岐により生じたパス毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【００７９】
また本実施形態のトランザクション処理システムによれば、各要求メッセージと回復処理に関する情報を対応付けて管理するので、トランザクション処理システムが複数のチャネルから同時に要求メッセージを受信して処理を行う場合にも効率的な回復処理を行うことが可能である。
【００８０】
（実施形態２）
以下に履歴情報中に登録された各パス毎に回復処理を並列化する実施形態２のトランザクション処理システムについて説明する。
本実施形態の目的は、第１の実施形態と同様に回復処理の効率を向上する為に、正常処理フロー１１９の分岐により生じる複数のパス毎に回復処理を並列化することにある。第１の実施形態においては、トランザクション処理システムが回復処理フロー１２０を生成し、これを用いて回復処理を行ったが、本実施形態では、トランザクション処理システムが履歴情報をキューに保存し、これを用いて回復処理を並列に実行する。本実施形態におけるハードウェア構成は図２に示した構成と同一である。
【００８１】
図１４は本実施形態のトランザクション処理システムのソフトウェア構成を示す図である。本実施形態ではワークフロー実行プログラム１０２に履歴情報保存キュー１１０１を設けた。また本実施形態では回復処理において回復処理フロー１２０を使用しない為、ワークフロー管理ＤＢ１１８内には正常処理フロー１１９だけを示している。
【００８２】
図１５は本実施形態の業務ＤＢテーブルの一例を示す図である。業務ＤＢ１１０内には、図１５の様な業務ＤＢテーブル１３００が保存される。
業務ＤＢテーブル１３００は、要求通番１３０２と、要求内容１３０３と、正常処理フローＩＤ１３０４と、キューＩＤ１３０１を保存する為の列を含んでいる。キューＩＤ１３０１は、履歴情報保存キュー１１０１を識別する為のＩＤである。
【００８３】
本実施形態において、チャネル２０９、サーバ２１０〜２１２、ＯＲＢ１０１、アダプタ１０３〜１０６、通番管理プログラム１０８、トレーダ１０７は第１の実施形態と同様の処理を行う。以下、第１の実施形態の説明で用いた図５と同様の正常処理フロー１１９がワークフロー管理ＤＢ１１８に登録されている場合について説明する。
【００８４】
チャネル２０９からの要求メッセージは、アダプタ１０３により第１の実施形態と同様の手順で処理され、要求受付プログラム１１０３に対して要求メッセージが送信される。
要求受付プログラム１１０３は、アダプタ１０３から要求メッセージを受信し、業務ＤＢテーブル１３００に要求通番１３０２及び要求内容１３０３を登録する。そして要求メッセージの内容を元に要求に対応する正常処理フロー１１９を決定し、その正常処理フロー１１９を識別する正常処理フローＩＤ１３０４を登録する。また履歴情報保存キュー１１０１を識別する為のキューＩＤ１３０１を生成して登録する。そして正常処理フロー１１９の実行をワークフロー制御プログラム１１０８に要求する。このとき要求受付プログラム１１０３は、入力として要求通番１３０２と正常処理フローＩＤ１３０４をワークフロー制御プログラム１１０８へ渡す。
【００８５】
ワークフロー制御プログラム１１０８は、正常処理フローＩＤ１３０４で識別されるワークフローをワークフロー管理ＤＢ１１８の正常処理フロー１１９から読み出し、これに従って処理を進める。
【００８６】
図１６は本実施形態のトランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７の概略構成を示す図である。図１６に示す様に本実施形態のワークフロー制御システム２０１は、正常処理部１２０２と、補償処理部１２０３とを有している。
【００８７】
正常処理部１２０２は、実行したトランザクションの内容を示す履歴情報をトランザクションの実行時に登録する処理部である。補償処理部１２０３は、トランザクション実行中に障害が発生した場合に前記履歴情報を取出し、前記履歴情報中に登録されたトランザクションの内容毎に補償トランザクションを並列に実行する処理部である。
【００８８】
ワークフロー制御システム２０１を正常処理部１２０２及び補償処理部１２０３として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する媒体はＣＤ−ＲＯＭ以外の他の媒体でも良い。
【００８９】
図１６の処理プログラム１２０１で示す様に、トランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７は、正常処理部１２０２と補償処理部１２０３とで構成される。
【００９０】
ワークフロー制御プログラム１１０８は、定義に従ってトランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７の正常処理部１２０２を起動する。またワークフロー制御プログラム１１０８は、ワークフロー中のノードの並びにＩＤを付ける。例えば、図５に示すワークフローでは、トランザクション１を含むパスのパスＩＤ＝Ａ、トランザクション２を含むパスのパスＩＤ＝Ｂ、トランザクション３を含むパスのパスＩＤ＝Ｃ、トランザクション４を含むパスのパスＩＤ＝Ｄ、として管理している。そしてワークフロー制御プログラム１１０８は、正常処理部１２０２を起動するときに前記パスＩＤを起動時の入力パラメータとして渡す。正常処理部１２０２は、その渡されたパスＩＤを履歴情報の一部として保存する。なお正常処理部１２０２の処理手順はトランザクション要求処理プログラム１１０４〜１１０６と応答処理プログラム１１０７とで異なっている。
【００９１】
図１７は本実施形態のトランザクション要求処理プログラム１１０４〜１１０６の正常処理部１２０２の処理手順を示すフローチャートである。トランザクション要求処理プログラム１１０４〜１１０６内の正常処理部１２０２は図１７の手順に従って処理を行う。以下、トランザクション要求処理プログラム１１０４〜１１０６における正常処理部１２０２の処理手順について図１７を用いて説明する。
【００９２】
ワークフロー制御プログラム１１０８は、入力として要求通番１３０２及びパスＩＤを正常処理部１２０２に与える。トランザクション要求処理プログラム１１０４〜１１０６における正常処理部１２０２は、第１の実施形態と同様の手順で要求メッセージをアダプタ１０３〜１０６へ送信する（ステップ１４０１）。サーバ２１０〜２１２でのトランザクションが終了すると、正常処理部１２０２は、アダプタから応答メッセージを受信する（ステップ１４０２）。
【００９３】
次に正常処理部１２０２は、要求メッセージに対する処理が正常に終了したかどうかを判定する（ステップ１４０３）。正常に終了している場合に正常処理部１２０２は、トランザクションに関する履歴情報を履歴情報保存キュー１１０１に登録する（ステップ１４０４）。そして、正常終了をワークフロー制御プログラム１１０８に報告して（ステップ１４０５）処理を終了する。要求が正常に終了しなかった場合に正常処理部１２０２は、異常終了をワークフロー制御プログラム１１０８に報告して処理を終了する（ステップ１４０６）。
【００９４】
図１８は本実施形態の応答処理プログラム１１０７内の正常処理部１２０２の処理手順を示すフローチャートである。応答処理プログラム１１０７内の正常処理部１２０２は、図１８の手順に従って処理を行う。次に応答処理プログラム１１０７における正常処理部１２０２の処理手順について図１８を用いて説明する。
【００９５】
ワークフロー制御プログラム１１０８は、入力として要求通番１３０２及びパスＩＤを正常処理部１２０２に与える。応答処理プログラム１１０７における正常処理部１２０２は、業務ＤＢ１１０の要求通番１３０２に該当する行の内容を読み出す。そして、それらのデータを元にチャネル２０９への応答メッセージを生成し、通番管理プログラム１０８に要求してメッセージに応答通番を付ける（ステップ１５０１）。次に正常処理部１２０２は、アダプタ１０３に生成した応答メッセージを送信する（ステップ１５０２）。
【００９６】
そして正常処理部１２０２は、これらの処理が正常に終了したかどうかを判定する（ステップ１５０３）。次に、履歴情報保存キュー１１０１に応答処理に関する履歴情報を保存する（ステップ１５０４）。そして正常終了をワークフロー制御プログラム１１０８に報告して（ステップ１５０５）処理を終了する。異常が発生していると判断した場合には、異常終了をワークフロー制御プログラム１１０８に報告して（ステップ１５０６）処理を終了する。
【００９７】
図１９は本実施形態の履歴情報保存キュー１１０１の内容例を示す図である。図１９では正常処理フロー１１９の実行が正常に終了した時点での履歴情報保存キュー１１０１の内容を表している。履歴情報保存キュー１１０１は、Ｆｉｒｓｔ Ｉｎ Ｌａｓｔ Ｏｕｔ型のキューである。
【００９８】
トランザクション要求処理プログラム１１０４〜１１０６によって保存された履歴情報は、図１９の履歴情報１６０１，１６０３及び１６０４である。また応答処理プログラム１１０７によって保存された履歴情報は履歴情報１６０６である。履歴情報１６０２及び１６０５はワークフロー制御プログラム１１０８によって保存された履歴情報である。なおトランザクション２とトランザクション３は並列に実行される為、トランザクション２に関する履歴情報１６０３とトランザクション３に関する履歴情報１６０４の順番は、各トランザクションに関する正常処理が終了したタイミングによって異なる。
【００９９】
トランザクション要求処理プログラム１１０４〜１１０６は、図１７のステップ１４０４において、各トランザクション要求処理を識別する為の処理ＩＤと、要求メッセージを送信したサーバを識別する為の送信先ＩＤと、サーバ２１０〜２１２において各トランザクションに付けられた処理番号と、各トランザクション要求処理が実行されたパスを識別する為のパスＩＤと、各サーバからの応答内容に関するデータから構成される履歴情報を保存する。
【０１００】
また応答処理プログラム１１０７は、図１８のステップ１５０４において、応答処理を識別する為の処理ＩＤと、応答メッセージを送信したチャネル２０９を識別する為の送信先ＩＤと、応答メッセージに付けた応答通番と、応答処理が実行されたパスを識別する為のパスＩＤと、応答メッセージの内容に関するデータから構成される履歴情報を保存する。
【０１０１】
更にワークフロー制御プログラム１１０８は、分岐、待合せ処理を行うときに、履歴情報保存キュー１１０１に履歴情報を保存する。分岐処理の履歴情報は、履歴情報１６０２に示す様に、分岐処理を識別する為の処理ＩＤと、分岐する前のパスを識別する為の分岐元パスＩＤと、分岐した後のパスを識別する為の分岐先パスＩＤから構成される。待合せ処理の履歴情報は、履歴情報１６０５に示す様に、待合せ処理を識別する為の処理ＩＤと、待合せの対象となるパスを識別する為の待合せパスＩＤと、待合せ処理後のパスを識別する為の待合せ後パスＩＤから構成される。
【０１０２】
障害発生時には、この様にして保存された履歴情報を利用して回復処理を行う。ワークフロー制御プログラム１１０８は、障害発生時に回復処理プログラム１１０２を起動する（図５のノード５０４，５１０，５１１及び５１４）。このときワークフロー制御プログラム１１０８は、業務ＤＢテーブル１３００に保存されているキューＩＤ１３０１を回復処理プログラム１１０２へ入力として渡す。回復処理プログラム１１０２は、キューＩＤ１３０１で識別される履歴情報保存キュー１１０１内の履歴情報を取出しながら、図２０に示す処理手順に従って処理を行う。
【０１０３】
図２０は本実施形態の回復処理プログラム１１０２の処理手順を示すフローチャートである。以下、回復処理プログラム１１０２の処理について図２０を用いて説明する。
回復処理プログラム１１０２は、キューＩＤ１３０１で識別される履歴情報保存キュー１１０１内に履歴情報があるかどうかを判定する（ステップ１７０１）。履歴情報が履歴情報保存キュー１１０１に存在しない場合には処理を終了し、履歴情報が存在する場合には履歴情報を取出す（ステップ１７０２）。
【０１０４】
取出した履歴情報が待合せ処理に関する情報であるかどうかを判定する（ステップ１７０３）。待合せ処理でない場合、分岐処理に関する情報であるかどうかを判定する（ステップ１７０４）。分岐処理でもない場合、すなわちトランザクション要求処理または応答処理に関する情報である場合、処理ＩＤで識別される処理の補償処理部１２０３を起動する（ステップ１７０５）。
【０１０５】
次に補償処理が正常に終了したかどうかを判定する（ステップ１７０６）。正常に終了している場合には、ステップ１７０１に戻り、処理を続行する。異常終了した場合には、ワークフロー制御プログラム１１０８に報告し、処理を終了する（ステップ１７０７）。
【０１０６】
履歴情報保存キュー１１０１から取出した履歴情報が待合せ処理に関する情報であった場合、待合せパスＩＤ毎に回復処理を並列化して処理を実行する（ステップ１７０８）。これは例えば、新たにスレッドを生成して同一の履歴情報保存キュー１１０１から複数のスレッドにより履歴情報を取出して処理を行うことにより実現する。また、取出した履歴情報が分岐処理に関するものであった場合、分岐先パス毎に並列に行われている回復処理の終了を待つ（ステップ１７０９）。これは例えば複数起動したスレッドの終了を待つことによって実現する。
【０１０７】
以上で説明した回復処理プログラム１１０２の処理によって起動される補償処理部１２０３の処理手順を図２１及び図２２に示す。補償処理部１２０３は、トランザクション要求処理プログラム１１０４〜１１０６と応答処理プログラム１１０７とで処理手順が異なる。
【０１０８】
図２１は本実施形態のトランザクション要求処理プログラム１１０４〜１１０６の補償処理部１２０３の処理手順を示すフローチャートである。先ずトランザクション要求処理プログラム１１０４〜１１０６における補償処理部１２０３の処理手順について図２１を用いて説明する。
【０１０９】
回復処理プログラム１１０２は、履歴情報保存キュー１１０１から取出した履歴情報を補償処理部１２０３に入力として渡す。補償処理部１２０３は、履歴情報を元に処理番号に対応する処理をキャンセルする為のメッセージを生成し、送信先ＩＤで識別されるサーバ２１０〜２１２に接続されているアダプタ１０４〜１０６へキャンセル要求メッセージを送信する（ステップ１８０１）。
【０１１０】
次に、そのアダプタ１０４〜１０６から、サーバ２１０〜２１２で行われたキャンセル処理に関する応答メッセージを受信する（ステップ１８０２）。そしてキャンセル処理が正常に終了したかどうかを判定する（ステップ１８０３）。正常に終了している場合、回復処理プログラム１１０２に報告して終了する（ステップ１８０４）。キャンセル処理が正常に終了しなかった場合、異常終了を回復処理プログラム１１０２に報告して処理を終了する（ステップ１８０５）。
【０１１１】
図２２は本実施形態の応答処理プログラム１１０７の補償処理部１２０３の処理手順を示すフローチャートである。次に応答処理プログラム１１０７における補償処理部１２０３の処理について図２２を用いて説明する。
【０１１２】
回復処理プログラム１１０２は、履歴情報保存キュー１１０１から取出した履歴情報を補償処理部１２０３へ入力として渡す。補償処理部１２０３は、履歴情報を元に処理番号に対応する処理をキャンセルする為のメッセージを生成し、送信先ＩＤで識別されるチャネル２０９に接続されているアダプタ１０３へキャンセル要求メッセージを送信する（ステップ１９０１）。
【０１１３】
次に、キャンセル要求メッセージの送信処理が正常に終了したかどうかを判定する（ステップ１９０２）。正常に終了している場合、回復処理プログラム１１０２に報告して終了する（ステップ１９０３）。正常に終了しなかった場合、異常終了を回復処理プログラム１１０２に報告して処理を終了する（ステップ１９０４）。
【０１１４】
以上で説明した様に本実施形態によれば、正常処理部１２０２によりパスＩＤを含む履歴情報を履歴情報保存キュー１１０１に登録し、またワークフロー制御プログラム１１０８により履歴情報保存キュー１１０１に分岐処理及び待合せ処理に関する履歴情報を登録できる。そして障害が発生した場合には、ワークフロー制御システム２０１は、履歴情報保存キュー１１０１に保存した履歴情報を用いて、パス毎に回復処理を並列に実行することができる。従って回復処理に要する時間を短縮することができる。
【０１１５】
更にワークフロー制御システム２０１が、要求通番１３０２と履歴情報保存キュー１１０１との対応をデータベースにより管理しているので、チャネル２０９からの要求メッセージ毎に対応するキューを管理でき、複数のチャネルから同時に要求を受け付けて処理する場合にも、障害が発生した要求メッセージに対応する回復処理を実行することができる。
【０１１６】
本実施形態では履歴情報保存キュー１１０１を業務ＤＢ１１０とは別に設ける構成としたが、業務ＤＢ１１０内に履歴情報保存用のテーブルを設け、それを利用する形態としても良い。また運用者が入力装置２１３から回復処理プログラム１１０２を起動して、チャネル２０９からの要求メッセージに対する処理が正常に終了した後の任意の時点で回復処理を実行できる様にすることもできる。
【０１１７】
以上説明した様に本実施形態のトランザクション処理システムによれば、ワークフロー制御システムが正常処理を行ったワークフロー上のパス毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【０１１８】
（実施形態３）
以下に履歴情報中に登録されたトランザクションの内容毎に回復処理を並列化する実施形態３のトランザクション処理システムについて説明する。
第２の実施形態では、回復処理の効率を向上する為に正常処理フロー１１９において並列に実行されるパス毎に回復処理を並列化した。そして、各パスにおいては、各トランザクションについて正常実行時と逆順に回復処理を行った。しかし、トランザクション処理システムが扱う業務によっては、回復時にトランザクションの順番を全く意識する必要がない場合も有り得る。本実施形態では、その様なトランザクション処理システムにおける回復処理の効率を向上する為に、履歴情報中に登録されたトランザクションの内容毎に並列に回復処理を行う。なお本実施形態におけるハードウェア構成及びソフトウェア構成は、第２の実施形態に示した構成と同一であるものとする。
【０１１９】
図２３は本実施形態の履歴情報保存キュー１１０１の内容例を示す図である。本実施形態におけるワークフロー制御プログラム１１０８は、分岐処理及び待合せ処理において履歴情報保存キュー１１０１への履歴情報の保存を行わない。また、各トランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７内の正常処理部１２０２は、履歴情報を保存する際にパスＩＤを保存する必要がない。
【０１２０】
図２４は本実施形態の回復処理プログラム１１０２の処理手順を示すフローチャートである。次に本実施形態における回復処理プログラム１１０２の処理手順について図２４を用いて説明する。
【０１２１】
ワークフロー制御プログラム１１０８は、業務ＤＢテーブル１３００に保存されているキューＩＤ１３０１を回復処理プログラム１１０２へ入力として渡す。回復処理プログラム１１０２は、ワークフロー制御プログラム１１０８から起動されると、履歴情報保存キュー１１０１に履歴情報があるかどうかを判定する（ステップ２１０１）。履歴情報がある場合、履歴情報を取出す（ステップ２１０２）。
【０１２２】
次に、取出した履歴情報を処理する為のスレッドを生成して補償処理を並列化する（ステップ２１０３）。そして、新しく生成したスレッドにおいて補償処理部１２０３を起動する（ステップ２１０４）。履歴情報が履歴情報保存キュー１１０１内に存在する間は、以上の処理を繰り返し、履歴情報が存在しなくなると、並列化したスレッドの終了を待つ（ステップ２１０５）。
【０１２３】
次に、全ての補償処理が正常に終了したかどうかを判定する（ステップ２１０６）。全ての補償処理が正常に終了した場合、ワークフロー制御プログラム１１０８に正常終了を報告して処理を終了する（ステップ２１０７）。何れかの補償処理が異常終了した場合には、ワークフロー制御プログラム１１０８に異常を報告して処理を終了する（ステップ２１０８）。
【０１２４】
本実施形態によれば、履歴情報中に登録されたトランザクションの内容毎に並列に補償処理を行うことができる。ステップ２１０３においてスレッドを生成するときに生成したスレッド数を覚えておいて、一定数以上のスレッドを生成しない様に制御する様にしても良い。
【０１２５】
以上説明した様に本実施形態のトランザクション処理システムによれば、履歴情報中に登録されたトランザクションの内容毎に並列に回復処理を行うので、回復処理の効率を向上させることが可能である。
【０１２６】
（実施形態４）
以下に履歴情報中に登録されたメッセージの送信先毎に回復処理を並列化する実施形態４のトランザクション処理システムについて説明する。
本実施形態では、回復処理の効率を向上する為にワークフロー制御システム２０１からのメッセージの送信先毎に回復処理を並列化する。その為に回復処理プログラム１１０２において送信先ＩＤを判定し、送信先ＩＤ毎に回復処理を並列実行する様にした。
本実施形態のハードウェア構成及びソフトウェア構成は、第２の実施形態及び第３の実施形態と同一である。また、本実施形態において履歴情報保存キュー１１０１内に保存される履歴情報の内容は第３の実施形態と同一である。
【０１２７】
図２５は本実施形態の回復処理プログラム１１０２の処理手順を示すフローチャートである。本実施形態における回復処理プログラム１１０２の処理手順について図２５を用いて説明する。
【０１２８】
ワークフロー制御プログラム１１０８は、業務ＤＢテーブル１３００に保存されているキューＩＤ１３０１を回復処理プログラム１１０２へ入力として渡す。回復処理プログラム１１０２は、履歴情報保存キュー１１０１内に履歴情報があるかどうかを判定する（ステップ２２０１）。履歴情報がある場合には、履歴情報を取出す（ステップ２２０２）。
【０１２９】
次に、送信先ＩＤに対応する回復処理を実行中かどうかを判定する（ステップ２２０３）。実行中でない場合には、送信先ＩＤに対応する回復処理を実行する為のスレッドを生成し、新たに生成したスレッドにおいて、以後その送信先ＩＤに関する回復処理を実行する（ステップ２２０４）。
【０１３０】
取出した履歴情報内の送信先ＩＤに対応する回復処理が実行中である場合にはステップ２２０１に戻って次の履歴情報に関する処理を行う。ステップ２２０１において、履歴情報保存キュー１１０１内に次の履歴情報がない場合、スレッドの終了を待ち（ステップ２２０７）、次に全ての回復処理が正常に終了したかどうかを判定する（ステップ２２０８）。全ての回復処理が正常に終了した場合、ワークフロー制御プログラム１１０８に正常終了を報告して処理を終了する（ステップ２２０９）。何れかの回復処理が異常終了した場合には、ワークフロー制御プログラム１１０８に異常を報告して処理を終了する（ステップ２２１０）。
【０１３１】
図２６は本実施形態のステップ２２０４において生成されるスレッドの処理手順を示すフローチャートである。ステップ２２０４において生成された各スレッドの処理手順について図２６を用いて説明する。
【０１３２】
各スレッドは、履歴情報保存キュー１１０１内に履歴情報があるかどうかを判定する（ステップ２６０１）。履歴情報がある場合には、履歴情報を取出す（ステップ２６０２）。取出した履歴情報内の送信先ＩＤに対応する回復処理が、自分の処理している送信先ＩＤと一致するかを判定する（ステップ２６０３）。一致する場合には補償処理部１２０３を実行する（ステップ２６０４）。一致しない場合にはステップ２６０１に戻って次の履歴情報に関する処理を行う。
【０１３３】
補償処理部１２０３の実行終了後、当該処理が正常に終了したかどうかを確認する（ステップ２６０５）。正常に終了している場合、ステップ２６０１に戻って次の履歴情報に関する処理を行う。異常終了した場合、回復処理プログラム１１０２に異常終了を報告して処理を終了する（ステップ２６０６）。ステップ２６０１において、履歴情報保存キュー１１０１内に次の履歴情報がない場合、回復処理プログラム１１０２に正常終了を報告して終了する（ステップ２６０７）。
【０１３４】
本実施形態によれば、正常処理において要求メッセージを送信したときの送信先サーバ及び応答メッセージを送信したチャネル毎に並列に回復処理を行うことができる。
【０１３５】
以上説明した様に本実施形態のトランザクション処理システムによれば、ワークフロー制御システムが正常処理において送信したメッセージの送信先毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【０１３６】
【発明の効果】
本発明によれば正常処理フローの分岐により生じたパス毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【図面の簡単な説明】
【図１】実施形態１のワークフロー制御システムのソフトウェア構成を示す図である。
【図２】実施形態１のトランザクション処理システムのハードウェア構成を示す図である。
【図３】実施形態１の要求処理プログラム１１２〜１１４及び応答処理プログラム１１５の概略構成を示す図である。
【図４】実施形態１の業務ＤＢテーブルの一例を示す図である。
【図５】実施形態１の正常処理フロー１１９の一例を示す図である。
【図６】実施形態１のトランザクション要求処理プログラム１１２〜１１４の正常処理部３０２の処理手順を示すフローチャートである。
【図７】実施形態１の回復処理フロー１２０の例を示す図である。
【図８】実施形態１の回復処理フロー１２０の例を示す図である。
【図９】実施形態１の回復処理フロー１２０の例を示す図である。
【図１０】実施形態１の応答処理プログラム１１５における正常処理部３０２の処理手順を示すフローチャートである。
【図１１】実施形態１の回復処理フロー１２０の例を示す図である。
【図１２】実施形態１のトランザクション要求処理プログラム１１２〜１１４の補償処理部３０３の処理手順を示すフローチャートである。
【図１３】実施形態１の応答処理プログラム１１５の補償処理部３０３の処理手順を示すフローチャートである。
【図１４】実施形態２のトランザクション処理システムのソフトウェア構成を示す図である。
【図１５】実施形態２の業務ＤＢテーブルの一例を示す図である。
【図１６】実施形態２のトランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７の概略構成を示す図である。
【図１７】実施形態２のトランザクション要求処理プログラム１１０４〜１１０６の正常処理部１２０２の処理手順を示すフローチャートである。
【図１８】実施形態２の応答処理プログラム１１０７内の正常処理部１２０２の処理手順を示すフローチャートである。
【図１９】実施形態２の履歴情報保存キュー１１０１の内容例を示す図である。
【図２０】実施形態２の回復処理プログラム１１０２の処理手順を示すフローチャートである。
【図２１】実施形態２のトランザクション要求処理プログラム１１０４〜１１０６の補償処理部１２０３の処理手順を示すフローチャートである。
【図２２】実施形態２の応答処理プログラム１１０７の補償処理部１２０３の処理手順を示すフローチャートである。
【図２３】実施形態３の履歴情報保存キュー１１０１の内容例を示す図である。
【図２４】実施形態３の回復処理プログラム１１０２の処理手順を示すフローチャートである。
【図２５】実施形態４の回復処理プログラム１１０２の処理手順を示すフローチャートである。
【図２６】実施形態４のステップ２２０４において生成されるスレッドの処理手順を示すフローチャートである。
【符号の説明】
１０１…ＯＲＢ、１０２…ワークフロー実行プログラム、１０３〜１０６…アダプタ、１０７…トレーダ、１０８…通番管理プログラム、１０９…要求受付プログラム、１１０…業務ＤＢ、１１１…ワークフロー制御プログラム、１１２〜１１４…要求処理プログラム、１１５…応答処理プログラム、１１６…回復処理プログラム、１１７…ワークフロー登録処理プログラム、１１８…ワークフロー管理ＤＢ、１１９…正常処理フロー、１２０…回復処理フロー、２０１…ワークフロー制御システム、２０２…ＣＰＵ、２０３…メモリ、２０４…ハードディスク装置、２０５〜２０８…ネットワーク・インタフェース・コントローラ、２０９…チャネル、２１０〜２１２…サーバ、２１３…入力装置、２１４…出力装置、２１５〜２１８…ネットワーク、３０１…処理プログラム、３０２…正常処理部、３０３…補償処理部、４００…業務ＤＢテーブル、４０１…要求通番、４０２…要求内容、４０３…正常処理フローＩＤ、４０４…回復処理フローＩＤ、４０５，４０７及び４０９…処理番号、４０６，４０８及び４１０…データ、４１１…応答番号、４１２…応答内容、５０１〜５１４…ノード、６０１〜６０５…ノード、６０６〜６０９…ノード、６１０〜６１５…ノード、６１６〜６１８…ノード、１１０１…履歴情報保存キュー、１１０２…回復処理プログラム、１１０３…要求受付プログラム、１１０４〜１１０６…要求処理プログラム、１１０７…応答処理プログラム、１１０８…ワークフロー制御プログラム、１３００…業務ＤＢテーブル、１３０１…キューＩＤ、１３０２…要求通番、１３０３…要求内容、１３０４…正常処理フローＩＤ、１２０１…処理プログラム、１２０２…正常処理部、１２０３…補償処理部、１６０１〜１６０６…履歴情報。
【発明の属する技術分野】
本発明はワークフローに従って一連のトランザクション処理を実行するトランザクション処理システムに関し、特にトランザクション実行中に障害が発生した場合に回復処理を行うトランザクション処理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
ホテルと航空券の予約が必要な旅行予約システムや、複数の銀行の口座間で送金をする様なシステムにおいては、チャネルからの要求に対して複数のサーバにアクセスしてトランザクション処理を行う必要がある。トランザクション処理とは、原子性、一貫性、隔離性、耐久性という性質を持つプログラムを実行することである。トランザクション処理については、例えば、「トランザクション処理システム入門」（フィリップ・Ａ・バーンスタイン、エリック・ニューカマー著、日経ＢＰ社）で紹介されている。また、本明細書においては、これ以降、ワークフロー制御システムに要求メッセージを送信するシステムを総称して「チャネル」と呼ぶことにする。
【０００３】
一連の処理を一つのトランザクションで実行しようとすると、各サーバにおいてトランザクションが終了するまでの期間、該当するデータをロックしておく必要がある。この為、他の処理が長時間待たされ、性能上問題となる場合がある。そこで一連の処理を各サーバへのアクセス毎のトランザクションに分割し、複数のトランザクションから成るワークフローとして実行することが一般的に行われる。
【０００４】
この様なシステムにおいては、ワークフローの実行中に障害が発生した場合、障害発生時点までに行った一連のトランザクション処理を取消す回復処理が必要である。この為従来は各トランザクションにおいて行った処理の内容を履歴としてキューに登録し、障害発生時にはこのキューの後尾から一つずつ順に履歴情報を取出して各トランザクションに対する補償処理を行っていた。この様なシステムは、例えば「トランザクション処理システム入門」（フィリップ・Ａ・バーンスタイン、エリック・ニューカマー著、日経ＢＰ社、１１１頁）で紹介されている。
【０００５】
【発明が解決しようとする課題】
前記従来の方式において、補償処理によってトランザクションが取消されるまでの間に別のトランザクションが同じサーバに対して処理を行った場合、そのトランザクションは取消されるべきトランザクションの結果に影響を受けることになる。例えばホテルの予約を行うトランザクションでは、キャンセルにより空きが生じるまでの間、満室の為予約できない状態が続くことになる。従って、回復処理に要する時間はできるだけ短いほうが望ましい。
【０００６】
従来の方式によれば、分岐により並列に実行されたトランザクションを回復する場合にも、一つずつ補償トランザクションが実行される。従って、一連のトランザクションに関する回復処理を完了するまでに多くの時間を要するという問題があった。
【０００７】
本発明の目的は上記問題を解決し、回復処理の効率を向上させることが可能な技術を提供することにある。
本発明の他の目的はトランザクション処理システムが複数のチャネルから同時に要求メッセージを受信して処理を行う場合にも効率的な回復処理を行うことが可能な技術を提供することにある。
【０００８】
【課題を解決するための手段】
本発明は、ワークフローに従って一連のトランザクションを実行するトランザクション処理システムにおいて、障害回復を行う為の回復処理フローまたは実行した処理内容を示す履歴情報をトランザクション実行時に登録し、トランザクション実行中に障害が発生した場合に、前記登録した回復処理フローまたは履歴情報に従って一連の補償処理を並列に実行するものである。
【０００９】
本発明のトランザクション処理システムでは、ワークフローに従ってトランザクションを実行すると共に、トランザクション実行中に障害が発生した場合の障害回復を行う補償処理をトランザクションの実行時に回復処理フローとして登録しておく。
【００１０】
その際、ワークフローに従って分岐処理を行うときにはその分岐処理に対応させて待合せ処理を回復処理フローに登録し、ワークフローに従って待合せ処理を行うときにはその待合わせ処理に対応させて分岐処理を回復処理フローに登録しておく。
【００１１】
トランザクション実行中に障害が発生した場合には、前記登録しておいた回復処理フローに従って一連の補償処理を実行する。ワークフローの正常処理フローに対応して回復処理フローが生成されるので、トランザクション実行中に分岐処理により並列に実行された部分は補償処理でも並列に実行され、補償処理が高速に実行される。
【００１２】
また本発明のトランザクション処理システムでは、ワークフローに従ってトランザクションを実行すると共に、トランザクションの実行内容を示す履歴情報を登録しておく。
【００１３】
トランザクション実行中に障害が発生した場合には前記登録しておいた履歴情報を取出し、履歴情報中のトランザクションの内容毎に補償トランザクションを並列に実行する。このときワークフローのパスや送信先毎に補償トランザクションを並列化することとしても良い。前記の様に履歴情報に従って補償トランザクションが並列に実行されるので、補償処理が高速に実行される。
【００１４】
以上の様に本発明のトランザクション処理システムによれば、正常処理フローの分岐により生じたパス毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【００１５】
【発明の実施の形態】
（実施形態１）
以下に正常処理フローにおいて分岐したパス毎に回復処理を並列化する実施形態１のトランザクション処理システムについて説明する。
図１は本実施形態のワークフロー制御システムのソフトウェア構成を示す図である。本実施形態では、ワークフロー制御システム内のソフトウェアを構成する各コンポーネントをオブジェクトとして実装した場合について説明する。
【００１６】
図２は本実施形態のトランザクション処理システムのハードウェア構成を示す図である。本実施形態のシステムは、ワークフロー制御システム２０１と、このシステムにネットワーク２１５〜２１８で接続されたチャネル２０９及びサーバ２１０〜２１２とで構成される。
【００１７】
ワークフロー制御システム２０１は、チャネル２０９からの要求メッセージを解釈し、サーバ２１０〜２１２に対してトランザクションを要求しながら、チャネル２０９からの要求を満たす為の処理を行うシステムである。チャネル２０９は、ユーザからの要求に従ってワークフロー制御システム２０１に要求メッセージを送信するシステムである。サーバ２１０〜２１２は、ワークフロー制御システム２０１からの要求に従ってトランザクションを実行するシステムである。ここでは、サーバ２１０〜２１２がそれぞれ別のサービスを提供していると仮定する。本実施形態では、チャネルが１つとサーバが３つ接続された構成を示しているが、より多くのチャネル及びサーバを接続した構成としても良い。
【００１８】
ワークフロー制御システム２０１は、ＣＰＵ２０２、メモリ２０３、ハードディスク装置２０４、ネットワーク・インタフェース・コントローラ２０５〜２０８、入力装置２１３、出力装置２１４で構成される。ハードディスク装置２０４には、ワークフローに従って処理を行う為のソフトウェア群が保存されており、これらのソフトウェアはメモリ２０３にロードされてＣＰＵ２０２により実行される。ネットワーク・インタフェース・コントローラ２０５〜２０８は、ネットワーク２１５〜２１８に対するインタフェースを制御し、チャネル２０９及びサーバ２１０〜２１２と接続する。
【００１９】
次に本実施形態のワークフロー制御システム２０１のソフトウェア構成について図１を用いて説明する。ワークフロー制御システム２０１は、オブジェクト・リクエスト・ブローカであるＯＲＢ１０１と、トレーダ１０７と、アダプタ１０３〜１０６と、通番管理プログラム１０８と、ワークフロー実行プログラム１０２とで構成される。
【００２０】
ＯＲＢ１０１は、オブジェクト間のリクエストと、その応答の送受信を可能にするメッセージング機構を提供する。ワークフロー制御システム２０１内の各コンポーネントは、ＯＲＢ１０１を使用して他のコンポーネントとの間で通信を行う。
【００２１】
トレーダ１０７は、各コンポーネントのサービス内容からオブジェクトを検索する為の仕組みを提供する。アダプタ１０３〜１０６、ワークフロー実行プログラム１０２は、自分の提供するサービス内容をトレーダ１０７に登録する。また、メッセージ送信時にはトレーダ１０７によりサービスを検索して送信先のオブジェクト・リファレンスを受け取る。オブジェクト・リファレンスは、対象になるオブジェクトを一意に識別する為の情報を含んだデータである。各オブジェクトは、オブジェクト・リファレンスを使用して対象となるオブジェクトへのメッセージの送信をＯＲＢに要求する。
【００２２】
アダプタ１０３〜１０６は、チャネル２０９及びサーバ２１０〜２１２と、ワークフロー実行プログラム１０２との間でのメッセージの転送を行うコンポーネントである。アダプタ１０３〜１０６は、それぞれ異なるプロトコルでチャネル２０９やサーバ２１０〜２１２と接続されており、ネットワーク２１５〜２１８を介してチャネル２０９やサーバ２１０〜２１２と接続する為のプロトコルの制御及びメッセージフォーマットの変換を行う。
【００２３】
通番管理プログラム１０８は、ワークフロー制御システム２０１内で転送されるメッセージに固有の番号を与える為のコンポーネントである。通番管理プログラム１０８では、シーケンシャルに番号を管理しており、各コンポーネントからの要求を受けてワークフロー制御システム２０１内で一意な番号を返す。各コンポーネントは、通番管理プログラム１０８から受け取った通番でメッセージに番号を付ける。
【００２４】
ワークフロー実行プログラム１０２は、チャネル２０９から要求メッセージを受信し、ワークフローに従ってサーバ２１０〜２１２にトランザクションの処理を依頼してチャネル２０９からの要求を処理するコンポーネントである。
【００２５】
ワークフロー実行プログラム１０２は、チャネル２０９からの要求を受け付ける要求受付プログラム１０９と、要求内容や処理の中間データを保存する為の業務ＤＢ１１０と、ワークフローに従ってトランザクションを起動するワークフロー制御プログラム１１１と、ワークフローを保存する為のワークフロー管理ＤＢ１１８と、ワークフロー制御プログラム１１１から起動され、サーバ２１０〜２１２に対して処理を要求するトランザクション要求処理プログラム１１２〜１１４と、ワークフロー制御プログラム１１１から起動され、チャネル２０９へ応答メッセージを送信する応答処理プログラム１１５と、ワークフロー管理ＤＢ１１８にワークフローを登録する為のワークフロー登録処理プログラム１１７と、ワークフローの実行中に障害が発生した場合に回復処理を行う回復処理プログラム１１６とで構成される。
【００２６】
図３は本実施形態の要求処理プログラム１１２〜１１４及び応答処理プログラム１１５の概略構成を示す図である。図３に示す様に本実施形態のワークフロー制御システム２０１は、正常処理部３０２と、補償処理部３０３とを有している。
【００２７】
正常処理部３０２は、トランザクション実行中に障害が発生した場合の障害回復を行う補償処理をトランザクションの実行時に回復処理フロー１２０として登録する処理部である。補償処理部３０３は、トランザクション実行中に障害が発生した場合に前記登録した回復処理フロー１２０に従って一連の補償処理を並列に実行する処理部である。
【００２８】
ワークフロー制御システム２０１を正常処理部３０２及び補償処理部３０３として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する媒体はＣＤ−ＲＯＭ以外の他の媒体でも良い。
【００２９】
図３の処理プログラム３０１に示す様にトランザクション要求処理プログラム１１２〜１１４及び応答処理プログラム１１５は、サーバ２１０〜２１２に対してトランザクションを要求する為の正常処理部３０２と、正常に実行されたトランザクションを取消す為の補償処理部３０３とで構成される。
【００３０】
ワークフロー管理ＤＢ１１８及び業務ＤＢ１１０は、ハードディスク装置２０４に保存される。ワークフロー管理ＤＢ１１８には、正常時のワークフローを記述した正常処理フロー１１９と、障害発生時に実行される回復処理フロー１２０とが保存される。業務ＤＢ１１０には図４に示す様な業務ＤＢテーブルが保存される。
【００３１】
図４は本実施形態の業務ＤＢテーブルの一例を示す図である。業務ＤＢテーブル４００の一つの行は、要求メッセージに付与された要求通番４０１と、要求内容４０２と、正常処理フロー１１９を識別する為の正常処理フローＩＤ４０３と、回復処理フロー１２０を識別する為の回復処理フローＩＤ４０４と、サーバ２１０〜２１２で各トランザクションに対して付けられる処理番号４０５，４０７及び４０９と、サーバ２１０〜２１２からの応答メッセージで得られたデータ４０６，４０８及び４１０と、チャネル２０９に対する応答番号４１１と、応答内容４１２とを格納する列を持つ。
【００３２】
ワークフロー制御システム２０１の運用者は、予め入力装置２１３から正常処理フロー１１９を登録する。ワークフロー登録処理プログラム１１７は、ワークフローを登録する為のコマンドやＧＵＩを提供し、入力されたワークフローをワークフロー管理ＤＢ１１８の正常処理フロー１１９に登録する。ワークフローの登録時に運用者は、ワークフローを一意に識別する為の正常処理フローＩＤ４０３を付ける。このＩＤによりワークフロー制御プログラム１１１は、正常処理フロー１１９に登録された複数のワークフローを管理することができる。この様にして定義された正常処理フロー１１９の例を図５に示す。
【００３３】
図５は本実施形態の正常処理フロー１１９の一例を示す図である。ワークフロー中のトランザクションを記述したノード５０１，５０５，５０６及び５１２には、対応するトランザクションを実行する為のプログラムを定義する。
【００３４】
本実施形態では、各トランザクションに対応してトランザクション処理プログラム３０１を用意し、その正常処理部３０２をオブジェクトとして実装する。そして、これらのオブジェクトを各ノードで起動するオブジェクトとして定義する。回復処理ノード５０４，５１０，５１１及び５１４には、起動するオブジェクトとして回復処理プログラム１１６を定義しておく。回復処理ノードに定義する内容は、ワークフロー中のどの位置にあっても全て同一の内容を設定することができる。
【００３５】
以下では、チャネル２０９から要求メッセージを受信し、図５に示したワークフローに従って処理を行う場合の動作について説明する。アダプタ１０３は、チャネル２０９から要求メッセージを受信し、通番管理プログラム１０８により要求メッセージに対する通番を取得し、この通番をメッセージに付加する。次にトレーダ１０７により、要求受付プログラム１０９のオブジェクト・リファレンスを取得し、そのオブジェクト・リファレンスを使用して要求受付プログラム１０９へ要求メッセージを送信する。
【００３６】
要求受付プログラム１０９は、アダプタ１０３から要求メッセージを受信し、業務ＤＢテーブル４００に要求通番４０１及び要求内容４０２を登録する。そして、要求メッセージの内容を元に要求に対応する正常処理フロー１１９を決定し、その正常処理フロー１１９を識別する為の正常処理フローＩＤ４０３を登録する。また回復処理フロー１２０を識別する為の回復処理フローＩＤ４０４を生成して登録する。その後、正常処理フロー１１９の実行をワークフロー制御プログラム１１１に要求する。このとき要求受付プログラム１０９は、入力として要求通番４０１と正常処理フローＩＤ４０３をワークフロー制御プログラム１１１へ渡す。
【００３７】
ワークフロー制御プログラム１１１は、要求されたワークフローをワークフロー管理ＤＢ１１８から読み出し、図５の様な正常処理フロー１１９に記述された内容に従って処理を進める。ワークフロー制御プログラム１１１は、ワークフロー中に記述された順にトランザクションを実行し、判定を行い、分岐、待合せ処理を行う。ワークフロー中のトランザクションノードには、そのトランザクションで起動すべき正常処理部３０２が定義されており、ワークフロー制御プログラム１１１は、定義されている正常処理部３０２をトランザクションの実行時に起動する。
【００３８】
図５の正常処理フロー１１９に従って、ワークフロー制御プログラム１１１は、ワークフローの実行を開始し、トランザクション１を実行する為にトランザクション１要求処理プログラム１１２の正常処理部３０２を起動する（ノード５０１）。
【００３９】
図６は本実施形態のトランザクション要求処理プログラム１１２〜１１４の正常処理部３０２の処理手順を示すフローチャートである。正常処理部３０２は図６の手順に従って処理を行う。ここで図６を用いて正常処理部３０２の処理手順について説明する。
【００４０】
ワークフロー制御プログラム１１１は、入力として要求通番４０１を正常処理部３０２へ渡す。正常処理部３０２は、業務ＤＢテーブル４００の要求通番４０１に該当する行の内容を読み出し、要求された処理に必要なサービスへの要求メッセージを作成する。そして、必要なサービスを提供するサーバに接続しているアダプタのオブジェクト・リファレンスをトレーダ１０７により取得して、要求メッセージを送信する（ステップ７０１）。
【００４１】
例えばトランザクション１要求処理プログラム１１２の正常処理部３０２は、サーバ２１０に接続されたアダプタ１０４のオブジェクト・リファレンスを取得して要求メッセージを送信する。アダプタ１０４は、要求メッセージを受信すると、ネットワーク２１６を介してサーバ２１０にそのメッセージを送信する。サーバ２１０は、要求メッセージを受信し、要求された処理を行った後、サーバ２１０で付けた処理番号と処理結果のデータを含む応答メッセージをアダプタ１０４に送信する。アダプタ１０４は、サーバ２１０からの応答メッセージを受信し、トランザクション１要求処理プログラム１１２の正常処理部３０２に送信する。
【００４２】
正常処理部３０２は、アダプタ１０４から応答メッセージを受信し、業務ＤＢテーブル４００に処理番号４０５と応答メッセージに含まれるデータ４０６を保存する（ステップ７０２）。次に正常処理部３０２は、要求メッセージに対する処理が正常に終了したかどうかを判定する（ステップ７０３）。正常に終了している場合に正常処理部３０２は、自分が行った処理を取消す為の補償トランザクションを回復処理フロー１２０に登録する（ステップ７０４）。
【００４３】
ワークフロー登録処理プログラム１１７は、正常処理部３０２に対して回復処理フロー１２０を登録する為のインタフェースを提供している。正常処理部３０２は、このインタフェースを使用して回復処理フロー１２０へ補償トランザクションを登録する。このとき正常処理部３０２は、業務ＤＢテーブル４００の回復処理フローＩＤ４０４を読み出し、そのＩＤを指定して登録を要求する。
【００４４】
ワークフロー登録処理プログラム１１７は、登録要求を受け取り、指定されたＩＤで識別される回復処理フロー１２０が未だ存在しない場合には新たに生成し、補償トランザクションの実行を記述したノードを登録する。補償トランザクションは、補償処理部３０３を起動するという作業によって記述される。最後に正常処理部３０２は、正常終了をワークフロー制御プログラム１１１に報告して（ステップ７０５）、処理を終了する。
【００４５】
ステップ７０３で判定した結果、サーバ２１０に対する要求が正常に終了していなかった場合、正常処理部３０２は、異常終了をワークフロー制御プログラム１１１に報告して処理を終了する（ステップ７０６）。
【００４６】
図７は本実施形態の回復処理フロー１２０の例を示す図である。図７ではトランザクション１（ノード５０１）の処理が終了した時点で登録されている回復処理フロー１２０を表している。
【００４７】
ワークフロー登録処理プログラム１１７は、補償トランザクションの登録を要求されると、渡されたＩＤを持つ回復処理のフローを生成し、ワークフロー管理ＤＢ１１８の回復処理フロー１２０に登録する。開始ノード６０１及び正常終了ノード６０４は、ワークフロー登録処理プログラム１１７によって、最初に回復処理フロー１２０を登録するときに付加される。補償処理１（ノード６０２）は、図６のステップ７０４で登録要求された補償トランザクションである。またこの例では、正常処理部３０２が補償トランザクションと共に判定ノード６０３及び異常終了ノード６０５を付加する例を示している。
【００４８】
ここで図５の正常処理フロー１１９に戻って説明を続ける。トランザクション１（ノード５０１）の処理が上で説明した様に終了すると、ワークフロー制御プログラム１１１は、トランザクション処理プログラム３０１からの終了報告を判定し（ノード５０２）、正常終了の場合には分岐処理を行う（ノード５０３）。トランザクション処理プログラム３０１が異常終了している場合には回復処理（ノード５０４）を実行する。回復処理については後で説明する。
【００４９】
図８は本実施形態の回復処理フロー１２０の例を示す図である。図８に示す様に分岐処理においてワークフロー制御プログラム１１１は、回復処理フロー１２０に待合せノード６０９、分岐ノード６０６、ＮＯＰ１（ノード６０７）、ＮＯＰ２（ノード６０８）を登録する。ＮＯＰ１及びＮＯＰ２は、何も処理を行わないことを示す。
【００５０】
ワークフロー制御プログラム１１１は、分岐後に並列実行されるパスの数を判断して、その数分のＮＯＰノードを登録する。その後、ワークフロー制御プログラム１１１は、トランザクション２とトランザクション３を並列に実行する。
【００５１】
ワークフロー制御プログラム１１１は、トランザクション２（ノード５０５）においてトランザクション２要求処理プログラム１１３を起動し、トランザクション３（ノード５０６）においてトランザクション３要求処理プログラム１１４を起動する。両トランザクション要求処理プログラムは図６と同様の手順で処理を行う。トランザクション２要求処理プログラム１１３は、サーバ２１１が提供するサービスをアダプタ１０５経由で要求し、トランザクション３要求処理プログラム１１４は、サーバ２１２が提供するサービスをアダプタ１０６経由で要求する。
【００５２】
各トランザクションによる処理結果は、トランザクション１（ノード５０１）のときと同じ様に業務ＤＢテーブル４００中に保存される。トランザクション２の処理結果は処理番号４０７とデータ４０８に、トランザクション３の処理結果は処理番号４０９とデータ４１０に保存される。
【００５３】
図９は本実施形態の回復処理フロー１２０の例を示す図である。図９では両トランザクションが終了した時点での回復処理フロー１２０を表している。
ワークフロー登録処理プログラム１１７は、各トランザクションからの登録要求を受けると、登録を要求されたトランザクションでＮＯＰノードを置き換える。図９において、補償処理２（ノード６１０）と補償処理３（ノード６１１）が、それぞれトランザクション２とトランザクション３の補償トランザクションである。また正常処理部３０２は補償トランザクションと共に判定ノード６１２及び６１４並びに異常終了ノード６１３及び６１５を付加している。
【００５４】
図５で両トランザクションの処理が終了すると、ワークフロー制御プログラム１１１はそれぞれのトランザクションに関して判定を行う（ノード５０７，５０８）。判定の結果、トランザクションが正常終了している場合には、待合せを行う（ノード５０９）。待合せ処理において、ワークフロー制御プログラム１１１は、二つの判定処理（ノード５０７，５０８）の両方が正常に終了したことを検出すると、次のトランザクションを処理する（ノード５１２）。トランザクション２またはトランザクション３が異常終了した場合については、後で説明する。
【００５５】
トランザクション４（ノード５１２）には、チャネル２０９への応答処理が定義されている。応答処理プログラム１１５は図３に示したトランザクション処理プログラム３０１と同様に、正常処理部３０２と補償処理部３０３とで構成される。但しトランザクション要求処理プログラムにおける正常処理部３０２及び補償処理部３０３とは動作が異なる。ワークフロー制御プログラム１１１は応答処理プログラム１１５における正常処理部３０２を起動する。
【００５６】
図１０は本実施形態の応答処理プログラム１１５における正常処理部３０２の処理手順を示すフローチャートである。応答処理プログラム１１５における正常処理部３０２は、図１０の手順に従って処理を行う。ここで図１０を用いて応答処理プログラム１１５における正常処理部３０２の処理について説明する。
【００５７】
ワークフロー制御プログラム１１１は、入力として要求通番４０１を正常処理部３０２へ渡す。正常処理部３０２は、要求通番４０１に該当する業務ＤＢ１１０の内容を読み出し、それらのデータを元にチャネル２０９への応答メッセージを生成し、通番管理プログラム１０８に要求してメッセージに通番を付ける（ステップ８０１）。
【００５８】
次に正常処理部３０２は、生成した応答メッセージをアダプタ１０３に送信する（ステップ８０２）。アダプタ１０３はネットワーク２１５経由でチャネル２０９へ応答メッセージを送信する。
【００５９】
次に正常処理部３０２は、これらの処理が正常に終了したかどうかを判定する（ステップ８０３）。正常に終了した場合には、業務ＤＢテーブル４００に応答メッセージの応答番号４１１と応答内容４１２を保存し、正常処理部３０２で行った応答メッセージによる処理を取消す為の補償トランザクションを回復処理フロー１２０に登録する（ステップ８０４）。そして正常終了をワークフロー制御プログラム１１１に報告して（ステップ８０５）処理を終了する。ステップ８０３の判定で異常が発生していると判断した場合には、異常終了をワークフロー制御プログラム１１１に報告して（ステップ８０６）処理を終了する。
【００６０】
図５でトランザクション４の処理が終了すると、ワークフロー制御プログラム１１１は判定を行う（ノード５１３）。判定の結果、トランザクション４が正常終了している場合には、ワークフロー制御プログラム１１１は処理を終了する。トランザクション４で異常終了した場合の処理については後で説明する。
【００６１】
図１１は本実施形態の回復処理フロー１２０の例を示す図である。図１１ではトランザクション４（ノード５１２）が終了した時点での回復処理フロー１２０を表している。応答処理プログラム１１５は、補償処理４（ノード６１６）、判定ノード６１７及び異常終了ノード６１８を登録している。
【００６２】
次に、トランザクションが異常終了した場合の処理について説明する。判定ノード５０２，５０７，５０８及び５１３においてトランザクションの異常終了を検出した場合、ワークフロー制御プログラム１１１は、回復処理プログラム１１６を起動する（ノード５０４，５１０，５１１及び５１４）。
【００６３】
このとき、ワークフロー制御プログラム１１１は、入力として要求通番４０１を回復処理プログラム１１６に渡す。回復処理プログラム１１６は、業務ＤＢテーブル４００の入力で与えられた要求通番４０１に該当する行から回復処理フロー１２０のＩＤを読み出し、その回復処理フロー１２０の実行をワークフロー制御プログラム１１１に要求する。回復処理プログラム１１６は、入力として要求通番４０１と回復処理フローＩＤ４０４をワークフロー制御プログラム１１１へ渡す。
【００６４】
回復処理フロー１２０は、図７〜図９及び図１１に示した様に、正常処理フロー１１９中のどの回復処理ノードで回復処理プログラム１１６が起動されたかによって異なる。ワークフロー制御プログラム１１１は、回復処理プログラム１１６からの要求を受け、入力で与えられた回復処理フローＩＤ４０４で識別される回復処理フロー１２０に従って、補償処理部３０３を起動しながら処理を行う。なお補償処理部３０３は、トランザクション要求処理プログラム１１２〜１１４と応答処理プログラム１１５とで処理手順が異なる。
【００６５】
図１２は本実施形態のトランザクション要求処理プログラム１１２〜１１４の補償処理部３０３の処理手順を示すフローチャートである。ここでトランザクション要求処理プログラム１１２〜１１４における補償処理部３０３の処理手順について図１２を用いて説明する。
【００６６】
ワークフロー制御プログラム１１１は、入力として要求通番４０１を補償処理部３０３へ渡す。補償処理部３０３は、与えられた要求通番４０１に該当する行の情報を業務ＤＢ１１０から読み出して処理を行う。
【００６７】
補償処理部３０３は、各トランザクションに対応する処理番号４０５，４０７及び４０９並びにサーバ２１０〜２１２からの応答メッセージに関するデータ４０６，４０８及び４１０を読み出し、トランザクションのキャンセルを要求する為のメッセージを生成してアダプタ１０４〜１０６に送信する（ステップ９０１）。
【００６８】
サーバ２１０〜２１２は、キャンセル要求メッセージに従って指定されたトランザクションをキャンセルし、応答メッセージをアダプタ１０４〜１０６に送信する。補償処理部３０３はサーバ２１０〜２１２からの応答メッセージを受信する（ステップ９０２）。そしてキャンセル処理が正常に終了したかどうかを判定する（ステップ９０３）。正常に終了している場合、正常終了をワークフロー制御プログラム１１１に報告する（ステップ９０４）。異常終了している場合、異常終了をワークフロー制御プログラム１１１に報告する（ステップ９０５）。
【００６９】
図１３は本実施形態の応答処理プログラム１１５の補償処理部３０３の処理手順を示すフローチャートである。応答処理プログラム１１５において補償処理部３０３は、図１３の手順に従って処理を行う。次に応答処理プログラム１１５における補償処理部３０３の処理手順について図１３を用いて説明する。
【００７０】
トランザクション要求処理プログラム１１２〜１１４に関する補償処理部３０３のときと同様に、ワークフロー制御プログラム１１１は入力として要求通番４０１を補償処理部３０３へ渡す。補償処理部３０３は、業務ＤＢ１１０から与えられた要求通番４０１に該当する行の情報を読み出して処理を行う。補償処理部３０３は、業務ＤＢ１１０から応答メッセージの応答番号４１１及び応答内容４１２を読み出して、この応答メッセージのキャンセルを要求する為のメッセージを生成してアダプタ１０３へ送信する（ステップ１００１）。
【００７１】
次に、送信処理が正常に終了したかどうかを判定する（ステップ１００２）。正常に終了した場合、正常終了をワークフロー制御プログラム１１１に報告する（ステップ１００３）。異常終了した場合は、ワークフロー制御プログラム１１１に異常終了を報告する（ステップ１００４）。
【００７２】
ワークフロー制御プログラム１１１は、判定ノードにおいて異常終了したと判定すると異常終了処理を行う。異常終了処理でワークフロー制御プログラム１１１は、回復処理が異常終了したことを示すメッセージを出力装置２１４に表示する。
【００７３】
以上で説明した様に本実施形態では、正常処理フロー１１９の実行時に各トランザクションにおいて、その補償トランザクションを回復処理フロー１２０に登録しながら処理を進める。そして障害により何れかのトランザクションが異常終了した場合には、その時点までに行ったトランザクションを回復処理フロー１２０に従って回復する。
【００７４】
本実施形態では、回復処理フロー１２０において補償処理トランザクションが異常終了した場合には、その時点で回復処理を終了する様にしたが、補償処理トランザクションの正常／異常終了に関わらず、次の補償処理トランザクションを実行する様な回復処理フロー１２０を生成することもできる。この為には正常処理部３０２が補償トランザクションだけを回復処理フロー１２０に登録し、判定ノード及び異常終了ノードの登録を行わない様にすれば良い。
【００７５】
また運用者が入力装置２１３からワークフロー制御プログラム１１１に対して回復処理フロー１２０の実行を要求する様にして、チャネル２０９からの要求メッセージに対する処理が正常に終了した後の任意の時点で回復処理を実行できる様にすることもできる。
【００７６】
本実施形態によればワークフロー制御システム２０１は、並列に実行されるパスを含む様なワークフローの実行中に回復処理の為のワークフローを動的に生成することができる。またワークフロー制御プログラム１１１が、回復処理フロー１２０に分岐処理及び待合せ処理を登録でき、並列に実行されるパスを生成することができる。そして障害が発生した場合には、この回復処理フロー１２０に従ってパス毎に回復処理を並列に実行することができる。従って回復処理に要する時間を短縮することができる。
【００７７】
更にワークフロー制御システム２０１が、要求通番４０１と回復処理フローＩＤ４０４との対応をデータベースにより管理しているので、チャネル２０９からの要求メッセージ毎に対応する回復処理フロー１２０を管理でき、複数のチャネルから同時に要求を受け付けて処理する場合にも障害が発生した要求メッセージに対応する回復処理を実行することができる。
【００７８】
以上説明した様に本実施形態のトランザクション処理システムによれば、正常処理フローの分岐により生じたパス毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【００７９】
また本実施形態のトランザクション処理システムによれば、各要求メッセージと回復処理に関する情報を対応付けて管理するので、トランザクション処理システムが複数のチャネルから同時に要求メッセージを受信して処理を行う場合にも効率的な回復処理を行うことが可能である。
【００８０】
（実施形態２）
以下に履歴情報中に登録された各パス毎に回復処理を並列化する実施形態２のトランザクション処理システムについて説明する。
本実施形態の目的は、第１の実施形態と同様に回復処理の効率を向上する為に、正常処理フロー１１９の分岐により生じる複数のパス毎に回復処理を並列化することにある。第１の実施形態においては、トランザクション処理システムが回復処理フロー１２０を生成し、これを用いて回復処理を行ったが、本実施形態では、トランザクション処理システムが履歴情報をキューに保存し、これを用いて回復処理を並列に実行する。本実施形態におけるハードウェア構成は図２に示した構成と同一である。
【００８１】
図１４は本実施形態のトランザクション処理システムのソフトウェア構成を示す図である。本実施形態ではワークフロー実行プログラム１０２に履歴情報保存キュー１１０１を設けた。また本実施形態では回復処理において回復処理フロー１２０を使用しない為、ワークフロー管理ＤＢ１１８内には正常処理フロー１１９だけを示している。
【００８２】
図１５は本実施形態の業務ＤＢテーブルの一例を示す図である。業務ＤＢ１１０内には、図１５の様な業務ＤＢテーブル１３００が保存される。
業務ＤＢテーブル１３００は、要求通番１３０２と、要求内容１３０３と、正常処理フローＩＤ１３０４と、キューＩＤ１３０１を保存する為の列を含んでいる。キューＩＤ１３０１は、履歴情報保存キュー１１０１を識別する為のＩＤである。
【００８３】
本実施形態において、チャネル２０９、サーバ２１０〜２１２、ＯＲＢ１０１、アダプタ１０３〜１０６、通番管理プログラム１０８、トレーダ１０７は第１の実施形態と同様の処理を行う。以下、第１の実施形態の説明で用いた図５と同様の正常処理フロー１１９がワークフロー管理ＤＢ１１８に登録されている場合について説明する。
【００８４】
チャネル２０９からの要求メッセージは、アダプタ１０３により第１の実施形態と同様の手順で処理され、要求受付プログラム１１０３に対して要求メッセージが送信される。
要求受付プログラム１１０３は、アダプタ１０３から要求メッセージを受信し、業務ＤＢテーブル１３００に要求通番１３０２及び要求内容１３０３を登録する。そして要求メッセージの内容を元に要求に対応する正常処理フロー１１９を決定し、その正常処理フロー１１９を識別する正常処理フローＩＤ１３０４を登録する。また履歴情報保存キュー１１０１を識別する為のキューＩＤ１３０１を生成して登録する。そして正常処理フロー１１９の実行をワークフロー制御プログラム１１０８に要求する。このとき要求受付プログラム１１０３は、入力として要求通番１３０２と正常処理フローＩＤ１３０４をワークフロー制御プログラム１１０８へ渡す。
【００８５】
ワークフロー制御プログラム１１０８は、正常処理フローＩＤ１３０４で識別されるワークフローをワークフロー管理ＤＢ１１８の正常処理フロー１１９から読み出し、これに従って処理を進める。
【００８６】
図１６は本実施形態のトランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７の概略構成を示す図である。図１６に示す様に本実施形態のワークフロー制御システム２０１は、正常処理部１２０２と、補償処理部１２０３とを有している。
【００８７】
正常処理部１２０２は、実行したトランザクションの内容を示す履歴情報をトランザクションの実行時に登録する処理部である。補償処理部１２０３は、トランザクション実行中に障害が発生した場合に前記履歴情報を取出し、前記履歴情報中に登録されたトランザクションの内容毎に補償トランザクションを並列に実行する処理部である。
【００８８】
ワークフロー制御システム２０１を正常処理部１２０２及び補償処理部１２０３として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する媒体はＣＤ−ＲＯＭ以外の他の媒体でも良い。
【００８９】
図１６の処理プログラム１２０１で示す様に、トランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７は、正常処理部１２０２と補償処理部１２０３とで構成される。
【００９０】
ワークフロー制御プログラム１１０８は、定義に従ってトランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７の正常処理部１２０２を起動する。またワークフロー制御プログラム１１０８は、ワークフロー中のノードの並びにＩＤを付ける。例えば、図５に示すワークフローでは、トランザクション１を含むパスのパスＩＤ＝Ａ、トランザクション２を含むパスのパスＩＤ＝Ｂ、トランザクション３を含むパスのパスＩＤ＝Ｃ、トランザクション４を含むパスのパスＩＤ＝Ｄ、として管理している。そしてワークフロー制御プログラム１１０８は、正常処理部１２０２を起動するときに前記パスＩＤを起動時の入力パラメータとして渡す。正常処理部１２０２は、その渡されたパスＩＤを履歴情報の一部として保存する。なお正常処理部１２０２の処理手順はトランザクション要求処理プログラム１１０４〜１１０６と応答処理プログラム１１０７とで異なっている。
【００９１】
図１７は本実施形態のトランザクション要求処理プログラム１１０４〜１１０６の正常処理部１２０２の処理手順を示すフローチャートである。トランザクション要求処理プログラム１１０４〜１１０６内の正常処理部１２０２は図１７の手順に従って処理を行う。以下、トランザクション要求処理プログラム１１０４〜１１０６における正常処理部１２０２の処理手順について図１７を用いて説明する。
【００９２】
ワークフロー制御プログラム１１０８は、入力として要求通番１３０２及びパスＩＤを正常処理部１２０２に与える。トランザクション要求処理プログラム１１０４〜１１０６における正常処理部１２０２は、第１の実施形態と同様の手順で要求メッセージをアダプタ１０３〜１０６へ送信する（ステップ１４０１）。サーバ２１０〜２１２でのトランザクションが終了すると、正常処理部１２０２は、アダプタから応答メッセージを受信する（ステップ１４０２）。
【００９３】
次に正常処理部１２０２は、要求メッセージに対する処理が正常に終了したかどうかを判定する（ステップ１４０３）。正常に終了している場合に正常処理部１２０２は、トランザクションに関する履歴情報を履歴情報保存キュー１１０１に登録する（ステップ１４０４）。そして、正常終了をワークフロー制御プログラム１１０８に報告して（ステップ１４０５）処理を終了する。要求が正常に終了しなかった場合に正常処理部１２０２は、異常終了をワークフロー制御プログラム１１０８に報告して処理を終了する（ステップ１４０６）。
【００９４】
図１８は本実施形態の応答処理プログラム１１０７内の正常処理部１２０２の処理手順を示すフローチャートである。応答処理プログラム１１０７内の正常処理部１２０２は、図１８の手順に従って処理を行う。次に応答処理プログラム１１０７における正常処理部１２０２の処理手順について図１８を用いて説明する。
【００９５】
ワークフロー制御プログラム１１０８は、入力として要求通番１３０２及びパスＩＤを正常処理部１２０２に与える。応答処理プログラム１１０７における正常処理部１２０２は、業務ＤＢ１１０の要求通番１３０２に該当する行の内容を読み出す。そして、それらのデータを元にチャネル２０９への応答メッセージを生成し、通番管理プログラム１０８に要求してメッセージに応答通番を付ける（ステップ１５０１）。次に正常処理部１２０２は、アダプタ１０３に生成した応答メッセージを送信する（ステップ１５０２）。
【００９６】
そして正常処理部１２０２は、これらの処理が正常に終了したかどうかを判定する（ステップ１５０３）。次に、履歴情報保存キュー１１０１に応答処理に関する履歴情報を保存する（ステップ１５０４）。そして正常終了をワークフロー制御プログラム１１０８に報告して（ステップ１５０５）処理を終了する。異常が発生していると判断した場合には、異常終了をワークフロー制御プログラム１１０８に報告して（ステップ１５０６）処理を終了する。
【００９７】
図１９は本実施形態の履歴情報保存キュー１１０１の内容例を示す図である。図１９では正常処理フロー１１９の実行が正常に終了した時点での履歴情報保存キュー１１０１の内容を表している。履歴情報保存キュー１１０１は、Ｆｉｒｓｔ Ｉｎ Ｌａｓｔ Ｏｕｔ型のキューである。
【００９８】
トランザクション要求処理プログラム１１０４〜１１０６によって保存された履歴情報は、図１９の履歴情報１６０１，１６０３及び１６０４である。また応答処理プログラム１１０７によって保存された履歴情報は履歴情報１６０６である。履歴情報１６０２及び１６０５はワークフロー制御プログラム１１０８によって保存された履歴情報である。なおトランザクション２とトランザクション３は並列に実行される為、トランザクション２に関する履歴情報１６０３とトランザクション３に関する履歴情報１６０４の順番は、各トランザクションに関する正常処理が終了したタイミングによって異なる。
【００９９】
トランザクション要求処理プログラム１１０４〜１１０６は、図１７のステップ１４０４において、各トランザクション要求処理を識別する為の処理ＩＤと、要求メッセージを送信したサーバを識別する為の送信先ＩＤと、サーバ２１０〜２１２において各トランザクションに付けられた処理番号と、各トランザクション要求処理が実行されたパスを識別する為のパスＩＤと、各サーバからの応答内容に関するデータから構成される履歴情報を保存する。
【０１００】
また応答処理プログラム１１０７は、図１８のステップ１５０４において、応答処理を識別する為の処理ＩＤと、応答メッセージを送信したチャネル２０９を識別する為の送信先ＩＤと、応答メッセージに付けた応答通番と、応答処理が実行されたパスを識別する為のパスＩＤと、応答メッセージの内容に関するデータから構成される履歴情報を保存する。
【０１０１】
更にワークフロー制御プログラム１１０８は、分岐、待合せ処理を行うときに、履歴情報保存キュー１１０１に履歴情報を保存する。分岐処理の履歴情報は、履歴情報１６０２に示す様に、分岐処理を識別する為の処理ＩＤと、分岐する前のパスを識別する為の分岐元パスＩＤと、分岐した後のパスを識別する為の分岐先パスＩＤから構成される。待合せ処理の履歴情報は、履歴情報１６０５に示す様に、待合せ処理を識別する為の処理ＩＤと、待合せの対象となるパスを識別する為の待合せパスＩＤと、待合せ処理後のパスを識別する為の待合せ後パスＩＤから構成される。
【０１０２】
障害発生時には、この様にして保存された履歴情報を利用して回復処理を行う。ワークフロー制御プログラム１１０８は、障害発生時に回復処理プログラム１１０２を起動する（図５のノード５０４，５１０，５１１及び５１４）。このときワークフロー制御プログラム１１０８は、業務ＤＢテーブル１３００に保存されているキューＩＤ１３０１を回復処理プログラム１１０２へ入力として渡す。回復処理プログラム１１０２は、キューＩＤ１３０１で識別される履歴情報保存キュー１１０１内の履歴情報を取出しながら、図２０に示す処理手順に従って処理を行う。
【０１０３】
図２０は本実施形態の回復処理プログラム１１０２の処理手順を示すフローチャートである。以下、回復処理プログラム１１０２の処理について図２０を用いて説明する。
回復処理プログラム１１０２は、キューＩＤ１３０１で識別される履歴情報保存キュー１１０１内に履歴情報があるかどうかを判定する（ステップ１７０１）。履歴情報が履歴情報保存キュー１１０１に存在しない場合には処理を終了し、履歴情報が存在する場合には履歴情報を取出す（ステップ１７０２）。
【０１０４】
取出した履歴情報が待合せ処理に関する情報であるかどうかを判定する（ステップ１７０３）。待合せ処理でない場合、分岐処理に関する情報であるかどうかを判定する（ステップ１７０４）。分岐処理でもない場合、すなわちトランザクション要求処理または応答処理に関する情報である場合、処理ＩＤで識別される処理の補償処理部１２０３を起動する（ステップ１７０５）。
【０１０５】
次に補償処理が正常に終了したかどうかを判定する（ステップ１７０６）。正常に終了している場合には、ステップ１７０１に戻り、処理を続行する。異常終了した場合には、ワークフロー制御プログラム１１０８に報告し、処理を終了する（ステップ１７０７）。
【０１０６】
履歴情報保存キュー１１０１から取出した履歴情報が待合せ処理に関する情報であった場合、待合せパスＩＤ毎に回復処理を並列化して処理を実行する（ステップ１７０８）。これは例えば、新たにスレッドを生成して同一の履歴情報保存キュー１１０１から複数のスレッドにより履歴情報を取出して処理を行うことにより実現する。また、取出した履歴情報が分岐処理に関するものであった場合、分岐先パス毎に並列に行われている回復処理の終了を待つ（ステップ１７０９）。これは例えば複数起動したスレッドの終了を待つことによって実現する。
【０１０７】
以上で説明した回復処理プログラム１１０２の処理によって起動される補償処理部１２０３の処理手順を図２１及び図２２に示す。補償処理部１２０３は、トランザクション要求処理プログラム１１０４〜１１０６と応答処理プログラム１１０７とで処理手順が異なる。
【０１０８】
図２１は本実施形態のトランザクション要求処理プログラム１１０４〜１１０６の補償処理部１２０３の処理手順を示すフローチャートである。先ずトランザクション要求処理プログラム１１０４〜１１０６における補償処理部１２０３の処理手順について図２１を用いて説明する。
【０１０９】
回復処理プログラム１１０２は、履歴情報保存キュー１１０１から取出した履歴情報を補償処理部１２０３に入力として渡す。補償処理部１２０３は、履歴情報を元に処理番号に対応する処理をキャンセルする為のメッセージを生成し、送信先ＩＤで識別されるサーバ２１０〜２１２に接続されているアダプタ１０４〜１０６へキャンセル要求メッセージを送信する（ステップ１８０１）。
【０１１０】
次に、そのアダプタ１０４〜１０６から、サーバ２１０〜２１２で行われたキャンセル処理に関する応答メッセージを受信する（ステップ１８０２）。そしてキャンセル処理が正常に終了したかどうかを判定する（ステップ１８０３）。正常に終了している場合、回復処理プログラム１１０２に報告して終了する（ステップ１８０４）。キャンセル処理が正常に終了しなかった場合、異常終了を回復処理プログラム１１０２に報告して処理を終了する（ステップ１８０５）。
【０１１１】
図２２は本実施形態の応答処理プログラム１１０７の補償処理部１２０３の処理手順を示すフローチャートである。次に応答処理プログラム１１０７における補償処理部１２０３の処理について図２２を用いて説明する。
【０１１２】
回復処理プログラム１１０２は、履歴情報保存キュー１１０１から取出した履歴情報を補償処理部１２０３へ入力として渡す。補償処理部１２０３は、履歴情報を元に処理番号に対応する処理をキャンセルする為のメッセージを生成し、送信先ＩＤで識別されるチャネル２０９に接続されているアダプタ１０３へキャンセル要求メッセージを送信する（ステップ１９０１）。
【０１１３】
次に、キャンセル要求メッセージの送信処理が正常に終了したかどうかを判定する（ステップ１９０２）。正常に終了している場合、回復処理プログラム１１０２に報告して終了する（ステップ１９０３）。正常に終了しなかった場合、異常終了を回復処理プログラム１１０２に報告して処理を終了する（ステップ１９０４）。
【０１１４】
以上で説明した様に本実施形態によれば、正常処理部１２０２によりパスＩＤを含む履歴情報を履歴情報保存キュー１１０１に登録し、またワークフロー制御プログラム１１０８により履歴情報保存キュー１１０１に分岐処理及び待合せ処理に関する履歴情報を登録できる。そして障害が発生した場合には、ワークフロー制御システム２０１は、履歴情報保存キュー１１０１に保存した履歴情報を用いて、パス毎に回復処理を並列に実行することができる。従って回復処理に要する時間を短縮することができる。
【０１１５】
更にワークフロー制御システム２０１が、要求通番１３０２と履歴情報保存キュー１１０１との対応をデータベースにより管理しているので、チャネル２０９からの要求メッセージ毎に対応するキューを管理でき、複数のチャネルから同時に要求を受け付けて処理する場合にも、障害が発生した要求メッセージに対応する回復処理を実行することができる。
【０１１６】
本実施形態では履歴情報保存キュー１１０１を業務ＤＢ１１０とは別に設ける構成としたが、業務ＤＢ１１０内に履歴情報保存用のテーブルを設け、それを利用する形態としても良い。また運用者が入力装置２１３から回復処理プログラム１１０２を起動して、チャネル２０９からの要求メッセージに対する処理が正常に終了した後の任意の時点で回復処理を実行できる様にすることもできる。
【０１１７】
以上説明した様に本実施形態のトランザクション処理システムによれば、ワークフロー制御システムが正常処理を行ったワークフロー上のパス毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【０１１８】
（実施形態３）
以下に履歴情報中に登録されたトランザクションの内容毎に回復処理を並列化する実施形態３のトランザクション処理システムについて説明する。
第２の実施形態では、回復処理の効率を向上する為に正常処理フロー１１９において並列に実行されるパス毎に回復処理を並列化した。そして、各パスにおいては、各トランザクションについて正常実行時と逆順に回復処理を行った。しかし、トランザクション処理システムが扱う業務によっては、回復時にトランザクションの順番を全く意識する必要がない場合も有り得る。本実施形態では、その様なトランザクション処理システムにおける回復処理の効率を向上する為に、履歴情報中に登録されたトランザクションの内容毎に並列に回復処理を行う。なお本実施形態におけるハードウェア構成及びソフトウェア構成は、第２の実施形態に示した構成と同一であるものとする。
【０１１９】
図２３は本実施形態の履歴情報保存キュー１１０１の内容例を示す図である。本実施形態におけるワークフロー制御プログラム１１０８は、分岐処理及び待合せ処理において履歴情報保存キュー１１０１への履歴情報の保存を行わない。また、各トランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７内の正常処理部１２０２は、履歴情報を保存する際にパスＩＤを保存する必要がない。
【０１２０】
図２４は本実施形態の回復処理プログラム１１０２の処理手順を示すフローチャートである。次に本実施形態における回復処理プログラム１１０２の処理手順について図２４を用いて説明する。
【０１２１】
ワークフロー制御プログラム１１０８は、業務ＤＢテーブル１３００に保存されているキューＩＤ１３０１を回復処理プログラム１１０２へ入力として渡す。回復処理プログラム１１０２は、ワークフロー制御プログラム１１０８から起動されると、履歴情報保存キュー１１０１に履歴情報があるかどうかを判定する（ステップ２１０１）。履歴情報がある場合、履歴情報を取出す（ステップ２１０２）。
【０１２２】
次に、取出した履歴情報を処理する為のスレッドを生成して補償処理を並列化する（ステップ２１０３）。そして、新しく生成したスレッドにおいて補償処理部１２０３を起動する（ステップ２１０４）。履歴情報が履歴情報保存キュー１１０１内に存在する間は、以上の処理を繰り返し、履歴情報が存在しなくなると、並列化したスレッドの終了を待つ（ステップ２１０５）。
【０１２３】
次に、全ての補償処理が正常に終了したかどうかを判定する（ステップ２１０６）。全ての補償処理が正常に終了した場合、ワークフロー制御プログラム１１０８に正常終了を報告して処理を終了する（ステップ２１０７）。何れかの補償処理が異常終了した場合には、ワークフロー制御プログラム１１０８に異常を報告して処理を終了する（ステップ２１０８）。
【０１２４】
本実施形態によれば、履歴情報中に登録されたトランザクションの内容毎に並列に補償処理を行うことができる。ステップ２１０３においてスレッドを生成するときに生成したスレッド数を覚えておいて、一定数以上のスレッドを生成しない様に制御する様にしても良い。
【０１２５】
以上説明した様に本実施形態のトランザクション処理システムによれば、履歴情報中に登録されたトランザクションの内容毎に並列に回復処理を行うので、回復処理の効率を向上させることが可能である。
【０１２６】
（実施形態４）
以下に履歴情報中に登録されたメッセージの送信先毎に回復処理を並列化する実施形態４のトランザクション処理システムについて説明する。
本実施形態では、回復処理の効率を向上する為にワークフロー制御システム２０１からのメッセージの送信先毎に回復処理を並列化する。その為に回復処理プログラム１１０２において送信先ＩＤを判定し、送信先ＩＤ毎に回復処理を並列実行する様にした。
本実施形態のハードウェア構成及びソフトウェア構成は、第２の実施形態及び第３の実施形態と同一である。また、本実施形態において履歴情報保存キュー１１０１内に保存される履歴情報の内容は第３の実施形態と同一である。
【０１２７】
図２５は本実施形態の回復処理プログラム１１０２の処理手順を示すフローチャートである。本実施形態における回復処理プログラム１１０２の処理手順について図２５を用いて説明する。
【０１２８】
ワークフロー制御プログラム１１０８は、業務ＤＢテーブル１３００に保存されているキューＩＤ１３０１を回復処理プログラム１１０２へ入力として渡す。回復処理プログラム１１０２は、履歴情報保存キュー１１０１内に履歴情報があるかどうかを判定する（ステップ２２０１）。履歴情報がある場合には、履歴情報を取出す（ステップ２２０２）。
【０１２９】
次に、送信先ＩＤに対応する回復処理を実行中かどうかを判定する（ステップ２２０３）。実行中でない場合には、送信先ＩＤに対応する回復処理を実行する為のスレッドを生成し、新たに生成したスレッドにおいて、以後その送信先ＩＤに関する回復処理を実行する（ステップ２２０４）。
【０１３０】
取出した履歴情報内の送信先ＩＤに対応する回復処理が実行中である場合にはステップ２２０１に戻って次の履歴情報に関する処理を行う。ステップ２２０１において、履歴情報保存キュー１１０１内に次の履歴情報がない場合、スレッドの終了を待ち（ステップ２２０７）、次に全ての回復処理が正常に終了したかどうかを判定する（ステップ２２０８）。全ての回復処理が正常に終了した場合、ワークフロー制御プログラム１１０８に正常終了を報告して処理を終了する（ステップ２２０９）。何れかの回復処理が異常終了した場合には、ワークフロー制御プログラム１１０８に異常を報告して処理を終了する（ステップ２２１０）。
【０１３１】
図２６は本実施形態のステップ２２０４において生成されるスレッドの処理手順を示すフローチャートである。ステップ２２０４において生成された各スレッドの処理手順について図２６を用いて説明する。
【０１３２】
各スレッドは、履歴情報保存キュー１１０１内に履歴情報があるかどうかを判定する（ステップ２６０１）。履歴情報がある場合には、履歴情報を取出す（ステップ２６０２）。取出した履歴情報内の送信先ＩＤに対応する回復処理が、自分の処理している送信先ＩＤと一致するかを判定する（ステップ２６０３）。一致する場合には補償処理部１２０３を実行する（ステップ２６０４）。一致しない場合にはステップ２６０１に戻って次の履歴情報に関する処理を行う。
【０１３３】
補償処理部１２０３の実行終了後、当該処理が正常に終了したかどうかを確認する（ステップ２６０５）。正常に終了している場合、ステップ２６０１に戻って次の履歴情報に関する処理を行う。異常終了した場合、回復処理プログラム１１０２に異常終了を報告して処理を終了する（ステップ２６０６）。ステップ２６０１において、履歴情報保存キュー１１０１内に次の履歴情報がない場合、回復処理プログラム１１０２に正常終了を報告して終了する（ステップ２６０７）。
【０１３４】
本実施形態によれば、正常処理において要求メッセージを送信したときの送信先サーバ及び応答メッセージを送信したチャネル毎に並列に回復処理を行うことができる。
【０１３５】
以上説明した様に本実施形態のトランザクション処理システムによれば、ワークフロー制御システムが正常処理において送信したメッセージの送信先毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【０１３６】
【発明の効果】
本発明によれば正常処理フローの分岐により生じたパス毎に回復処理を並列化するので、回復処理の効率を向上させることが可能である。
【図面の簡単な説明】
【図１】実施形態１のワークフロー制御システムのソフトウェア構成を示す図である。
【図２】実施形態１のトランザクション処理システムのハードウェア構成を示す図である。
【図３】実施形態１の要求処理プログラム１１２〜１１４及び応答処理プログラム１１５の概略構成を示す図である。
【図４】実施形態１の業務ＤＢテーブルの一例を示す図である。
【図５】実施形態１の正常処理フロー１１９の一例を示す図である。
【図６】実施形態１のトランザクション要求処理プログラム１１２〜１１４の正常処理部３０２の処理手順を示すフローチャートである。
【図７】実施形態１の回復処理フロー１２０の例を示す図である。
【図８】実施形態１の回復処理フロー１２０の例を示す図である。
【図９】実施形態１の回復処理フロー１２０の例を示す図である。
【図１０】実施形態１の応答処理プログラム１１５における正常処理部３０２の処理手順を示すフローチャートである。
【図１１】実施形態１の回復処理フロー１２０の例を示す図である。
【図１２】実施形態１のトランザクション要求処理プログラム１１２〜１１４の補償処理部３０３の処理手順を示すフローチャートである。
【図１３】実施形態１の応答処理プログラム１１５の補償処理部３０３の処理手順を示すフローチャートである。
【図１４】実施形態２のトランザクション処理システムのソフトウェア構成を示す図である。
【図１５】実施形態２の業務ＤＢテーブルの一例を示す図である。
【図１６】実施形態２のトランザクション要求処理プログラム１１０４〜１１０６及び応答処理プログラム１１０７の概略構成を示す図である。
【図１７】実施形態２のトランザクション要求処理プログラム１１０４〜１１０６の正常処理部１２０２の処理手順を示すフローチャートである。
【図１８】実施形態２の応答処理プログラム１１０７内の正常処理部１２０２の処理手順を示すフローチャートである。
【図１９】実施形態２の履歴情報保存キュー１１０１の内容例を示す図である。
【図２０】実施形態２の回復処理プログラム１１０２の処理手順を示すフローチャートである。
【図２１】実施形態２のトランザクション要求処理プログラム１１０４〜１１０６の補償処理部１２０３の処理手順を示すフローチャートである。
【図２２】実施形態２の応答処理プログラム１１０７の補償処理部１２０３の処理手順を示すフローチャートである。
【図２３】実施形態３の履歴情報保存キュー１１０１の内容例を示す図である。
【図２４】実施形態３の回復処理プログラム１１０２の処理手順を示すフローチャートである。
【図２５】実施形態４の回復処理プログラム１１０２の処理手順を示すフローチャートである。
【図２６】実施形態４のステップ２２０４において生成されるスレッドの処理手順を示すフローチャートである。
【符号の説明】
１０１…ＯＲＢ、１０２…ワークフロー実行プログラム、１０３〜１０６…アダプタ、１０７…トレーダ、１０８…通番管理プログラム、１０９…要求受付プログラム、１１０…業務ＤＢ、１１１…ワークフロー制御プログラム、１１２〜１１４…要求処理プログラム、１１５…応答処理プログラム、１１６…回復処理プログラム、１１７…ワークフロー登録処理プログラム、１１８…ワークフロー管理ＤＢ、１１９…正常処理フロー、１２０…回復処理フロー、２０１…ワークフロー制御システム、２０２…ＣＰＵ、２０３…メモリ、２０４…ハードディスク装置、２０５〜２０８…ネットワーク・インタフェース・コントローラ、２０９…チャネル、２１０〜２１２…サーバ、２１３…入力装置、２１４…出力装置、２１５〜２１８…ネットワーク、３０１…処理プログラム、３０２…正常処理部、３０３…補償処理部、４００…業務ＤＢテーブル、４０１…要求通番、４０２…要求内容、４０３…正常処理フローＩＤ、４０４…回復処理フローＩＤ、４０５，４０７及び４０９…処理番号、４０６，４０８及び４１０…データ、４１１…応答番号、４１２…応答内容、５０１〜５１４…ノード、６０１〜６０５…ノード、６０６〜６０９…ノード、６１０〜６１５…ノード、６１６〜６１８…ノード、１１０１…履歴情報保存キュー、１１０２…回復処理プログラム、１１０３…要求受付プログラム、１１０４〜１１０６…要求処理プログラム、１１０７…応答処理プログラム、１１０８…ワークフロー制御プログラム、１３００…業務ＤＢテーブル、１３０１…キューＩＤ、１３０２…要求通番、１３０３…要求内容、１３０４…正常処理フローＩＤ、１２０１…処理プログラム、１２０２…正常処理部、１２０３…補償処理部、１６０１〜１６０６…履歴情報。
Claims (4)
- ネットワークにより接続された複数の処理装置へトランザクション処理要求メッセージを送信するトランザクション処理装置における中央処理装置が、
ワークフローに従って一連のトランザクションの実行を要求するトランザクション処理方法であって、
前記中央処理装置が、当該ワークフローの実行中に、障害が発生した場合に障害発生時点までに前記複数の処理装置で行ったトランザクション処理を取り消す回復処理に係るワークフローである回復処理フローを記憶装置に登録する場合においては、
前記中央処理装置にロードされたワークフロー処理プログラムの処理で前記中央処理装置が、新たにワークフロー処理を開始する場合に当該ワークフロー処理を取り消す回復処理フローを新たに前記記憶装置上に生成し、前記実行に係るワークフロー中で処理内容が記述された各ノードの実行時に、トランザクション処理に係るノードを実行する場合に、当該処理の結果得られた応答メッセージの内容を読み出し、前記応答メッセージから当該トランザクションを取り消すための情報を抽出し、該情報を用いて当該トランザクションを取り消すメッセージを生成して前記複数の処理装置へ送信する処理である補償処理を示すノードを、前記記憶装置に保存された回復処理フローに登録し、
前記中央処理装置にロードされたワークフロー処理プログラムの処理で前記中央処理装置が、前記実行に係るワークフロー中で分岐処理を実行する場合に、前記記憶装置に登録した前記回復処理フローに前記分岐処理を取り消すための回復処理を示すノードとして、待合わせ処理を示すノード及び分岐処理を示すノードを、前記記憶装置に保存された回復処理フローに登録し、
前記障害が発生した場合においては、前記中央処理装置にロードされたワークフロー処理プログラムの処理で前記中央処理装置が、前記記憶装置から前記回復処理フローを読み出し、前記登録した回復処理フローの分岐に従って前記複数の処理装置に対して前記トランザクション処理を取り消す回復処理を通信処理装置により要求し、複数の処理装置により並列に実行させることを特徴とするトランザクション処理方法。 - 中央処理装置が、クライアントからの要求メッセージに通番を付与し、該通番と回復処理フローの識別子を記憶装置に保存して要求メッセージに対応する回復処理フローを管理することを特徴とする請求項１に記載されたトランザクション処理方法。
- ネットワークにより接続された複数の処理装置へトランザクション処理要求メッセージを送信し、
ワークフローに従って一連のトランザクションの実行を要求するトランザクション処理装置であって、
当該ワークフローの実行中に、障害が発生した場合に障害発生時点までに前記複数の処理装置で行ったトランザクション処理を取り消す回復処理に係るワークフローである回復処理フローを記憶装置に登録する場合においては、
ワークフロー処理プログラムの処理で中央処理装置が新たにワークフロー処理を開始する場合に当該ワークフロー処理を取り消す回復処理フローを新たに前記記憶装置上に生成し、前記実行に係るワークフロー中で処理内容が記述された各ノードの実行時に、トランザクション処理に係るノードを実行する場合に、当該処理の結果得られた応答メッセージの内容を読み出し、前記応答メッセージから当該トランザクションを取り消すための情報を抽出し、該情報を用いて当該トランザクションを取り消すメッセージを生成して前記複数の処理装置へ送信する処理である補償処理を示すノードを、前記保存された回復処理フローに登録し、
ワークフロー処理プログラムの処理で前記中央処理装置が前記実行に係るワークフロー中で分岐処理を実行する場合に、前記登録した前記回復処理フローに前記分岐処理を取り消すための回復処理を示すノードとして、待合わせ処理を示すノード及び分岐処理を示すノードを、前記保存された回復処理フローに登録する正常処理部と、
前記障害が発生した場合においては、前記ワークフロー処理プログラムの処理で前記中 央処理装置が、前記回復処理フローを読み出し、前記登録した回復処理フローの分岐に従って前記複数の処理装置に対して前記トランザクション処理を取り消す回復処理を通信処理装置により要求し、複数の処理装置により並列に実行させる補償処理部とを備えることを特徴とするトランザクション処理装置。 - ネットワークにより接続された複数の処理装置へトランザクション処理要求メッセージを送信し、
ワークフローに従って一連のトランザクションの実行を要求するトランザクション処理装置としてコンピュータを機能させる為のプログラムを記録した媒体であって、
当該ワークフローの実行中に、障害が発生した場合に障害発生時点までに前記複数の処理装置で行ったトランザクション処理を取り消す回復処理に係るワークフローである回復処理フローを記憶装置に登録する場合においては、
新たにワークフロー処理を開始する場合に当該ワークフロー処理を取り消す回復処理フローを新たに前記記憶装置上に生成し、前記実行に係るワークフロー中で処理内容が記述された各ノードの実行時に、トランザクション処理に係るノードを実行する場合に、当該処理の結果得られた応答メッセージの内容を読み出し、前記応答メッセージから当該トランザクションを取り消すための情報を抽出し、該情報を用いて当該トランザクションを取り消すメッセージを生成して前記複数の処理装置へ送信する処理である補償処理を示すノードを、前記保存された回復処理フローに登録し、
前記実行に係るワークフロー中で分岐処理を実行する場合に、前記登録した前記回復処理フローに前記分岐処理を取り消すための回復処理を示すノードとして、待合わせ処理を示すノード及び分岐処理を示すノードを、前記保存された回復処理フローに登録する正常処理部と、
前記障害が発生した場合においては、前記回復処理フローを読み出し、前記登録した回復処理フローの分岐に従って前記複数の処理装置に対して前記トランザクション処理を取り消す回復処理を通信処理装置により要求し、複数の処理装置により並列に実行させる補償処理部としてコンピュータを機能させる為のプログラムを記録したことを特徴とする媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP33669998A JP4094752B2 (ja) | 1998-11-27 | 1998-11-27 | トランザクション処理方法及びその実施装置並びにその処理プログラムを記録した媒体 |
| US09/443,102 US6578159B1 (en) | 1998-11-27 | 1999-11-18 | Transaction processing method and apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP33669998A JP4094752B2 (ja) | 1998-11-27 | 1998-11-27 | トランザクション処理方法及びその実施装置並びにその処理プログラムを記録した媒体 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005126511A Division JP4246176B2 (ja) | 2005-04-25 | 2005-04-25 | トランザクション処理方法及びその実施装置並びにその処理プログラムを記録した媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000163372A JP2000163372A (ja) | 2000-06-16 |
| JP4094752B2 true JP4094752B2 (ja) | 2008-06-04 |
Family
ID=18301894
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP33669998A Expired - Fee Related JP4094752B2 (ja) | 1998-11-27 | 1998-11-27 | トランザクション処理方法及びその実施装置並びにその処理プログラムを記録した媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6578159B1 (ja) |
| JP (1) | JP4094752B2 (ja) |
Families Citing this family (61)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050038911A1 (en) * | 1999-04-30 | 2005-02-17 | Yoshikuni Watanabe | Cooperative system and method therefor |
| US6918053B1 (en) * | 2000-04-28 | 2005-07-12 | Microsoft Corporation | Compensation framework for long running transactions |
| US7143128B1 (en) * | 2000-06-08 | 2006-11-28 | International Business Machines Corporation | Interactive data processor controlled display interface for tracking of allocated messages in a dynamic workload balancing communication system |
| US20020147624A1 (en) * | 2000-12-12 | 2002-10-10 | Kabushiki Kaisha Toshiba | System of supporting development of business process |
| US7657590B2 (en) * | 2001-02-07 | 2010-02-02 | Ubs Ag | Load balancing system and method |
| US7412520B2 (en) * | 2001-06-07 | 2008-08-12 | Intel Corporation | Systems and methods for recoverable workflow |
| US7454751B2 (en) * | 2001-06-07 | 2008-11-18 | Intel Corporation | Fault-tolerant system and methods with trusted message acknowledgement |
| CN1524221A (zh) | 2001-07-06 | 2004-08-25 | ���������˼�빫˾ | 信息备份系统和方法 |
| JP3712984B2 (ja) * | 2002-02-18 | 2005-11-02 | 日本電信電話株式会社 | 業務進捗制御装置及びその方法と、業務進捗制御プログラム及びそのプログラムを記録した記録媒体 |
| US7873716B2 (en) * | 2003-06-27 | 2011-01-18 | Oracle International Corporation | Method and apparatus for supporting service enablers via service request composition |
| US8234517B2 (en) * | 2003-08-01 | 2012-07-31 | Oracle International Corporation | Parallel recovery by non-failed nodes |
| US20050144617A1 (en) * | 2003-12-06 | 2005-06-30 | International Business Machines Corporation | Automatic configuration of reinstall information |
| US9245236B2 (en) | 2006-02-16 | 2016-01-26 | Oracle International Corporation | Factorization of concerns to build a SDP (service delivery platform) |
| US8073810B2 (en) * | 2007-10-29 | 2011-12-06 | Oracle International Corporation | Shared view of customers across business support systems (BSS) and a service delivery platform (SDP) |
| US9038082B2 (en) | 2004-05-28 | 2015-05-19 | Oracle International Corporation | Resource abstraction via enabler and metadata |
| US7860490B2 (en) * | 2004-12-01 | 2010-12-28 | Oracle International Corporation | Methods and systems for exposing access network capabilities using an enabler proxy |
| US8458703B2 (en) | 2008-06-26 | 2013-06-04 | Oracle International Corporation | Application requesting management function based on metadata for managing enabler or dependency |
| US9565297B2 (en) | 2004-05-28 | 2017-02-07 | Oracle International Corporation | True convergence with end to end identity management |
| US8966498B2 (en) | 2008-01-24 | 2015-02-24 | Oracle International Corporation | Integrating operational and business support systems with a service delivery platform |
| US8321498B2 (en) * | 2005-03-01 | 2012-11-27 | Oracle International Corporation | Policy interface description framework |
| JP4575088B2 (ja) * | 2004-08-31 | 2010-11-04 | 三菱電機株式会社 | 情報処理システム及び情報処理方法及び情報処理プログラム |
| US8032920B2 (en) * | 2004-12-27 | 2011-10-04 | Oracle International Corporation | Policies as workflows |
| US7949551B2 (en) * | 2005-04-06 | 2011-05-24 | International Business Machines Corporation | Processing of compensation scopes in workflow management systems |
| US8230423B2 (en) * | 2005-04-07 | 2012-07-24 | International Business Machines Corporation | Multithreaded processor architecture with operational latency hiding |
| US7765186B1 (en) | 2005-04-13 | 2010-07-27 | Progress Software Corporation | Update-anywhere replication of distributed systems |
| US7426653B2 (en) * | 2005-04-13 | 2008-09-16 | Progress Software Corporation | Fault tolerant distributed lock management |
| US8280867B2 (en) * | 2005-10-20 | 2012-10-02 | Teradata Us, Inc. | Identifying database request sources |
| US7475275B2 (en) * | 2005-10-27 | 2009-01-06 | International Business Machines Corporation | Method for fault handling in a co-operative workflow environment |
| US20070168720A1 (en) * | 2005-11-30 | 2007-07-19 | Oracle International Corporation | Method and apparatus for providing fault tolerance in a collaboration environment |
| US7610512B2 (en) * | 2006-01-06 | 2009-10-27 | Hewlett-Packard Development Company, L.P. | System and method for automated and assisted resolution of it incidents |
| US8024734B2 (en) * | 2006-03-23 | 2011-09-20 | Oracle International Corporation | Enabling a designer to specify workflows to process various results of execution of transactions |
| US8914493B2 (en) | 2008-03-10 | 2014-12-16 | Oracle International Corporation | Presence-based event driven architecture |
| DE102006051189A1 (de) * | 2006-10-30 | 2008-05-08 | Siemens Ag | Verfahren und System zum Ausführen und Konfigurieren von Applikationen abhängig von einer Einsatzumgebung |
| US20080127182A1 (en) * | 2006-11-29 | 2008-05-29 | Newport William T | Managing Memory Pages During Virtual Machine Migration |
| US8214503B2 (en) | 2007-03-23 | 2012-07-03 | Oracle International Corporation | Factoring out dialog control and call control |
| EP2174222A4 (en) * | 2007-07-26 | 2010-10-27 | Ab Initio Technology Llc | TRANSACTIONAL GRAPH-BASED CALCULATION WITH ERROR HANDLING |
| US8539097B2 (en) | 2007-11-14 | 2013-09-17 | Oracle International Corporation | Intelligent message processing |
| US8161171B2 (en) | 2007-11-20 | 2012-04-17 | Oracle International Corporation | Session initiation protocol-based internet protocol television |
| JP5145910B2 (ja) * | 2007-12-07 | 2013-02-20 | 富士通株式会社 | 情報処理装置及び情報処理方法 |
| US9654515B2 (en) | 2008-01-23 | 2017-05-16 | Oracle International Corporation | Service oriented architecture-based SCIM platform |
| US8589338B2 (en) * | 2008-01-24 | 2013-11-19 | Oracle International Corporation | Service-oriented architecture (SOA) management of data repository |
| US8401022B2 (en) * | 2008-02-08 | 2013-03-19 | Oracle International Corporation | Pragmatic approaches to IMS |
| EP2304922A1 (en) * | 2008-06-17 | 2011-04-06 | Attivio, Inc. | Ordered message processing |
| US8505067B2 (en) * | 2008-08-21 | 2013-08-06 | Oracle International Corporation | Service level network quality of service policy enforcement |
| TW201032535A (en) * | 2008-10-14 | 2010-09-01 | Ibm | A method of handling a message |
| US8879547B2 (en) | 2009-06-02 | 2014-11-04 | Oracle International Corporation | Telephony application services |
| US8205113B2 (en) * | 2009-07-14 | 2012-06-19 | Ab Initio Technology Llc | Fault tolerant batch processing |
| JP4846012B2 (ja) * | 2009-10-05 | 2011-12-28 | 株式会社日立製作所 | 業務フロー検索システム、業務フロー検索方法、および業務フロー検索プログラム |
| US8583830B2 (en) * | 2009-11-19 | 2013-11-12 | Oracle International Corporation | Inter-working with a walled garden floor-controlled system |
| US8533773B2 (en) | 2009-11-20 | 2013-09-10 | Oracle International Corporation | Methods and systems for implementing service level consolidated user information management |
| US9269060B2 (en) | 2009-11-20 | 2016-02-23 | Oracle International Corporation | Methods and systems for generating metadata describing dependencies for composable elements |
| US9509790B2 (en) | 2009-12-16 | 2016-11-29 | Oracle International Corporation | Global presence |
| US9503407B2 (en) | 2009-12-16 | 2016-11-22 | Oracle International Corporation | Message forwarding |
| US8103905B2 (en) | 2010-03-12 | 2012-01-24 | Microsoft Corporation | Detecting and recovering from process failures |
| US8495656B2 (en) | 2010-10-15 | 2013-07-23 | Attivio, Inc. | Ordered processing of groups of messages |
| JP5957293B2 (ja) * | 2012-05-29 | 2016-07-27 | みずほ情報総研株式会社 | 連携処理管理システム、連携処理管理方法及び連携処理管理プログラム |
| JP5978008B2 (ja) * | 2012-05-29 | 2016-08-24 | みずほ情報総研株式会社 | 取引管理システム、取引管理方法及び取引管理プログラム |
| US20140310183A1 (en) * | 2013-04-15 | 2014-10-16 | Lance Weber | Embedded acceptance system |
| JP6289214B2 (ja) * | 2014-03-31 | 2018-03-07 | 三菱プレシジョン株式会社 | 情報処理システム及びその方法 |
| JP6657798B2 (ja) * | 2015-08-19 | 2020-03-04 | 株式会社リコー | 情報処理システム、情報処理装置、及び情報処理方法 |
| US20190005082A1 (en) * | 2017-07-03 | 2019-01-03 | Infosys Limited | Method and system for committing group atomic transaction in non-relational database |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2667039B2 (ja) * | 1990-05-18 | 1997-10-22 | 株式会社東芝 | データ管理システムおよびデータ管理方法 |
| US5287501A (en) * | 1991-07-11 | 1994-02-15 | Digital Equipment Corporation | Multilevel transaction recovery in a database system which loss parent transaction undo operation upon commit of child transaction |
| GB2276737A (en) * | 1993-03-30 | 1994-10-05 | Ibm | Fault-tolerant transaction-oriented data processing |
| US5832203A (en) * | 1995-01-23 | 1998-11-03 | Tandem Computers Incorporated | Method for providing recovery from a failure in a system utilizing distributed audit |
| US5850507A (en) * | 1996-03-19 | 1998-12-15 | Oracle Corporation | Method and apparatus for improved transaction recovery |
| JP3672208B2 (ja) * | 1996-07-02 | 2005-07-20 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 階層化トランザクション処理方法 |
| US5878206A (en) * | 1997-03-25 | 1999-03-02 | Hewlett-Packard Company | Commit scope control in hierarchical information processes |
| US5940839A (en) * | 1997-04-04 | 1999-08-17 | Hewlett-Packard Company | Fault-tolerant system and method of managing transaction failures in hierarchies |
| US5983215A (en) * | 1997-05-08 | 1999-11-09 | The Trustees Of Columbia University In The City Of New York | System and method for performing joins and self-joins in a database system |
| US6185577B1 (en) * | 1998-06-23 | 2001-02-06 | Oracle Corporation | Method and apparatus for incremental undo |
| US6295610B1 (en) * | 1998-09-17 | 2001-09-25 | Oracle Corporation | Recovering resources in parallel |
| GB2343020A (en) * | 1998-10-19 | 2000-04-26 | Ibm | Handling transaction failures in a transaction processing system |
-
1998
- 1998-11-27 JP JP33669998A patent/JP4094752B2/ja not_active Expired - Fee Related
-
1999
- 1999-11-18 US US09/443,102 patent/US6578159B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6578159B1 (en) | 2003-06-10 |
| JP2000163372A (ja) | 2000-06-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4094752B2 (ja) | トランザクション処理方法及びその実施装置並びにその処理プログラムを記録した媒体 | |
| JP4246176B2 (ja) | トランザクション処理方法及びその実施装置並びにその処理プログラムを記録した媒体 | |
| US7669074B2 (en) | Method for fault handling in a co-operative workflow environment | |
| JP5894724B2 (ja) | グラフ型計算の分散サービス | |
| JPS63181063A (ja) | トランザクション処理方法 | |
| JP3554471B2 (ja) | 分散コンピュータ環境におけるグループ・イベント管理方法及び装置 | |
| CN110888718A (zh) | 分布式事务的实现方法及装置 | |
| US20070050425A1 (en) | Log management program of a computer, log management method thereof, and computer system | |
| US9537940B2 (en) | Exchange of information between processing servers | |
| CN108415757A (zh) | 分布式事务处理方法及装置 | |
| JP6111186B2 (ja) | 分散情報連携システムとそのデータ操作方法及びプログラム | |
| WO1996041262A1 (en) | Reduction of logging in distributed systems | |
| JP4141878B2 (ja) | トランザクション処理方法及びその実施装置並びにその処理プログラム | |
| CN102413166A (zh) | 分布式交易方法及其系统 | |
| JP4516594B2 (ja) | メッセージ送信制御方法、メッセージ送信制御装置、及びメッセージ送信制御プログラム | |
| CN111127088B (zh) | 实现最终一致性的方法、装置、计算机设备及存储介质 | |
| US5613133A (en) | Microcode loading with continued program execution | |
| WO2020015576A1 (zh) | 基于一致性协议的分布式处理方法、装置及存储介质 | |
| CN111339089B (zh) | 一种应用于区块链的数据存储与获取方法及装置 | |
| US20180276028A1 (en) | Single-hop two-phase transaction resolution | |
| JP2002099510A (ja) | 複数トランザクション処理システム | |
| JP2001060163A (ja) | トランザクションログ情報の処理装置 | |
| JPH04213126A (ja) | ソフトウェアテスト方式 | |
| CN113407123B (zh) | 一种分布式事务节点信息存储方法、装置、设备及介质 | |
| JP2003345609A (ja) | トランザクション処理装置、同装置のトランザクション処理方法、トランザクション処理プログラムおよび同プログラムを記録したコンピュータ読み取り可能な記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050201 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050222 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050425 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050712 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050912 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20050926 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20051028 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080206 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080306 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110314 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110314 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120314 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130314 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130314 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |