(57)【要約】  不備データを有するメッセージが入力された場合でも、後続のメッセージの処理に対して影響を与えずに、運用事業者の運用負荷を増大させずにサービス提供者が不備データを自立的に修正して再投入することを可能とするトランザクション制御システムである。業務アプリケーションは、トランザクション処理を開始して第１のキューから第１のメッセージを取得した後に、識別情報が例外管理テーブルに記録されているか否かを確認し、記録されていない場合には業務処理を実行する。記録されている場合には例外処理に係る第３のキューに第１のメッセージの内容を含む第３のメッセージを出力してトランザクション処理をコミットする。業務処理の実行時に例外が発生した場合に、第１のメッセージの識別情報を例外管理テーブルに記録し、トランザクション処理をロールバックする。
2017094096.tif 000002
【特許請求の範囲】
【請求項１】
第１のキューから第１のメッセージを取得して、前記第１のメッセージに基づいて１つ以上のサービス提供者についてデータベースへのアクセスを含む業務処理を実行し、第２のメッセージを第２のキューへ出力するトランザクション処理を実行する１つ以上の業務アプリケーションを有するトランザクション制御システムであって、
前記業務処理の実行時に例外が発生した前記第１のメッセージの識別情報を記録する例外管理テーブルを有し、
前記業務アプリケーションは、
前記トランザクション処理を開始して前記第１のキューから前記第１のメッセージを取得した後に、取得した前記第１のメッセージに係る前記識別情報が前記例外管理テーブルに記録されているか否かを確認し、記録されていない場合には前記業務処理を実行し、記録されている場合には例外処理に係る第３のキューに前記第１のメッセージの内容を含む第３のメッセージを出力して前記トランザクション処理をコミットし、
前記業務処理の実行時に例外が発生した場合に、前記第１のメッセージの前記識別情報を前記例外管理テーブルに記録し、前記トランザクション処理をロールバックする、トランザクション制御システム。
【請求項２】
請求項１に記載のトランザクション制御システムにおいて、
さらに、前記第３のキューから前記第３のメッセージを取得して、例外管理処理を実行する例外管理アプリケーションを有し、
前記例外管理アプリケーションは、前記第３のメッセージの内容を対応する前記サービス提供者に対して出力し、前記サービス提供者からの指示を受け付けて前記第３のメッセージに含まれる前記第１のメッセージに対して修正を行い、修正した前記第１のメッセージを前記第１のキューへ出力する、トランザクション制御システム。
【請求項３】
第１のキューから第１のメッセージを取得して、前記第１のメッセージに基づいて１つ以上のサービス提供者についてデータベースへのアクセスを含む業務処理を実行し、第２のメッセージを第２のキューへ出力するトランザクション処理を実行する１つ以上の業務アプリケーションを有するトランザクション制御システムにおけるトランザクション制御方法であって、
前記業務アプリケーションが、
前記トランザクション処理を開始して前記第１のキューから前記第１のメッセージを取得した後に、取得した前記第１のメッセージに係る前記識別情報が例外管理テーブルに記録されているか否かを確認し、記録されていない場合には前記業務処理を実行し、記録されている場合には例外処理に係る第３のキューに前記第１のメッセージの内容を含む第３のメッセージを出力して前記トランザクション処理をコミットする工程と、
前記業務処理の実行時に例外が発生した場合に、前記第１のメッセージの前記識別情報を前記例外管理テーブルに記録し、前記トランザクション処理をロールバックする工程と、を有する、トランザクション制御方法。
【請求項４】
請求項３に記載のトランザクション制御方法において、
さらに、前記第３のキューから前記第３のメッセージを取得して、例外管理処理を実行する例外管理アプリケーションが、前記第３のメッセージの内容を対応する前記サービス提供者に対して出力し、前記サービス提供者からの指示を受け付けて前記第３のメッセージに含まれる前記第１のメッセージに対して修正を行い、修正した前記第１のメッセージを前記第１のキューへ出力する工程を有する、トランザクション制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トランザクションの処理技術に関し、特に、メッセージキューイング（ＭＱ）によりデータの授受等の制御を行うトランザクション処理システムおよびトランザクション制御方法に適用して有効な技術に関するものである。
【背景技術】
【０００２】
トランザクション処理を行う情報処理システムにおいて、例えば、証券取引におけるＳＴＰ（Straight Through Processing）化を実現するシステムのように、異なる処理単位に実装された１つ以上のコンポーネントやサブシステム（以下ではこれらを「サブシステム」と総称する場合がある）がキューを介して「バケツリレー」的に連携することで一連の業務処理を実現するという構成がとられる場合がある。これにより、各サブシステム間の疎結合を実現し、可用性や保守性・拡張性などを向上させることができる。【０００３】
ＭＱを利用したサブシステム間の連携によるトランザクション処理に関連する技術として、例えば、特開２００６−１３３８９４号公報（特許文献１）には、フロー制御のためのメッセージがキューに送信されると、サーバのメッセージ処理部が業務用データベースからメッセージデータを取得し、その中に含まれるフロー定義に基づいてアプリケーションを呼び出して実行し、フロー定義とアプリケーションの実行結果を含むメッセージを次の送信先に送信することで、特定の管理サーバを経由することなくフロー定義に基づいたアプリケーションの連携処理を実現することが記載されている。【０００４】
また、特開２００９−９６１３号公報（特許文献２）には、トランザクションを、銘柄、端末、市場、サーバなどの所定の単位のサブトランザクションに分割して並行処理するように構成し、各サブトランザクションの処理結果を所定の単位毎にデータベースに格納して、メッセージの送受信をトリガとして、データベースに格納された処理結果をサブトランザクション間で引き継ぐことで、処理の順序性を確保したサブトランザクションの並行処理を実現する取引システムが記載されている。【０００５】
また、特開２００４−３１８５６０号公報（特許文献３）には、メッセージキューにつながれているメッセージを順次取り出してトランザクション処理を実行している際に異常が発生すると、メッセージキューにつながれているメッセージ内の、異常原因となったメッセージを構成要素とする一連の処理を実行するためのメッセージを破棄することで、異常発生時の影響範囲を小さくすることが記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−１３３８９４号公報
【特許文献２】特開２００９−９６１３号公報
【特許文献３】特開２００４−３１８５６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来技術のようなＭＱを利用したサブシステム間の連携によるトランザクション処理では、不備データを含むメッセージによりアプリケーション処理が停止することがないような方式を実装してオンライン業務の可用性を向上させる必要がある。例えば、あるサブシステムにおいて入力キューから取り出したメッセージが不備データを有している場合、当該サブシステムのアプリケーションでは業務例外（エラー）が発生する。【０００８】
このとき例外発生時の対応として不備データを有するメッセージも含めてトランザクションをロールバックすると、不備データを有するメッセージが入力キューに戻ってしまい、当該メッセージを再度取り出して処理することになって同じ例外発生がループするとともに後続のメッセージが滞留する結果となる。特に、ＳａａＳ（Software as a Service）やＡＳＰ（Application Service Provider）のように複数のサービス提供者が相乗りするシステムの場合、他のサービス提供者の処理にまで滞留の影響が及んでしまう。【０００９】
これに対し、例えば、特許文献３に記載されたような仕組みとすることで、例外発生がループするという事態は回避することができるが、破棄したメッセージに係るトランザクションのリカバリについては考慮されていない。この点、例えば、破棄したメッセージに係るデータをファイル等に出力しておく等の対応をとることも考えられるが、この場合でも当該トランザクションをリカバリするには最終的に不備データを修正する必要があり、これを実施する権限を有する（すなわち本番環境のデータを修正する権限を有する）のは原則として対象のサービス提供者のみである。この場合、従来技術では、システムの運用事業者が不備データをサービス提供者に受け渡したり、サービス提供者から承認や指示を受けて修正を代行したり等の対応が必要となり、運用事業者の運用負荷が増大してしまう。【００１０】
そこで本発明の目的は、不備データを有するメッセージが入力された場合でも、後続のメッセージの処理に対して影響を与えずに、運用事業者の運用負荷を増大させずにサービス提供者が不備データを自立的に修正して再投入（リトライ）することができるトランザクション処理システムおよびトランザクション制御方法を提供することにある。【００１１】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１２】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。【００１３】
本発明の代表的な実施の形態によるトランザクション制御システムは、第１のキューから第１のメッセージを取得して、前記第１のメッセージに基づいて１つ以上のサービス提供者についてデータベースへのアクセスを含む業務処理を実行し、第２のメッセージを第２のキューへ出力するトランザクション処理を実行する１つ以上の業務アプリケーションを有するトランザクション制御システムであって、以下の特徴を有するものである。【００１４】
すなわち、トランザクション制御システムは、前記業務処理の実行時に例外が発生した前記第１のメッセージの識別情報を記録する例外管理テーブルを有し、前記業務アプリケーションは、前記トランザクション処理を開始して前記第１のキューから前記第１のメッセージを取得した後に、取得した前記第１のメッセージに係る前記識別情報が前記例外管理テーブルに記録されているか否かを確認し、記録されていない場合には前記業務処理を実行し、記録されている場合には例外処理に係る第３のキューに前記第１のメッセージの内容を含む第３のメッセージを出力して前記トランザクション処理をコミットし、前記業務処理の実行時に例外が発生した場合に、前記第１のメッセージの前記識別情報を前記例外管理テーブルに記録し、前記トランザクション処理をロールバックする。
【発明の効果】
【００１５】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。【００１６】
すなわち、本発明の代表的な実施の形態によれば、不備データを有するメッセージが入力された場合でも、後続のメッセージの処理に対して影響を与えずに、運用事業者の運用負荷を増大させずにサービス提供者が不備データを自立的に修正して再投入することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施の形態であるトランザクション処理システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態における正常時のトランザクション制御の例について概要を示した図である。
【図３】本発明の一実施の形態における例外発生時のトランザクション制御の例について概要を示した図である。
【図４】本発明の一実施の形態における例外発生時のトランザクション制御の例について概要を示した図である。
【図５】従来技術における例外発生時のトランザクション制御の例について概要を示した図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。
【００１９】
＜システム構成＞
図１は、本発明の一実施の形態であるトランザクション処理システムの構成例について概要を示した図である。トランザクション（ＴＲＸ）処理システム１は、例えば、運用事業者により運用管理されるサーバ機器やクラウドコンピューティング環境上に構築された仮想サーバなどのサーバシステムからなり、１つ以上のサービス提供者が、インターネット等のネットワーク（ＮＷ）２を介してユーザ端末３を利用するユーザに対してトランザクション処理によるものを含む各種業務サービスを提供するシステムである。
【００２０】
ＴＲＸ処理システム１は、ＯＳ（Operating System）１１、ＤＢＭＳ（DataBase Management System）１２、ＭＱ（Message Queue）１３などのミドルウェア、およびその上で稼働するソフトウェアとして実装された１つ以上の業務アプリケーション（ＡＰＬ）１４およびトランザクション（ＴＲＸ）制御部１５、例外管理アプリケーション（ＡＰＬ）１６などの各モジュールを有する。
【００２１】
各業務ＡＰＬ１４は、それぞれがＭＱ１３により提供されるキューを介して「バケツリレー」的に連携することで一連のサービスを実現するサブシステムを構成するアプリケーションプログラムである。図１の例では、全ての業務ＡＰＬ１４が１つのＴＲＸ処理システム１上に実装されている構成を示しているが、複数のサーバシステム上に分散配置される構成であってもよい。
【００２２】
業務ＡＰＬ１４は、基盤プログラムとしてＴＲＸ制御部１５を有している。ＴＲＸ制御部１５は、キューを介して入力されたメッセージが不備データを含むものか否かを判定し、不備データを含むと判定した場合には後述する例外管理ＡＰＬ１６に処理を連携することで、不備データに伴う例外発生のループを抑止する機能を有する。不備データを含むメッセージであるか否かの判定は、後述するように、対象のメッセージが以前に業務例外を発生させたものと同じであるか否かにより行う。
【００２３】
例外管理ＡＰＬ１６は、不備データを含むと判定されたメッセージを受け取り、その不備を修正するリカバリ処理を行う機能を有する。例えば、対象のメッセージに係るサービス提供者の担当者が使用するユーザ端末３に対して例外発生の旨の通知を行った上で対象の不備データを提示し、これに対する修正を受け付けて対象の業務ＡＰＬ１４に対して再投入するユーザインタフェースを提供する。可能な場合にはユーザによる修正を介さずに自動で修正を行って再投入する構成としてもよい。
【００２４】
＜トランザクション制御＞
図２は、本実施の形態における正常時のトランザクション制御の例について概要を示した図である。図中では、一連のサービスを実現するために連携する複数の業務ＡＰＬ１４のうちの１つを取り出して例示している。正常時では、業務ＡＰＬ１４は、トランザクションを開始すると、ユーザ端末３もしくは前段の業務ＡＰＬ１４によって入力キュー（ｉｎｑ）３１にＰＵＴされてキューイングされているメッセージ（ｍｓｇ）３３を１つＧＥＴし、その内容に基づいて所定の業務処理を実行する。このとき、業務データやログ情報などを保持するデータベース（ＤＢ）２１に対するアクセスも行う。
【００２５】
業務処理を全て実行すると、処理結果に係るｍｓｇ３３を出力キュー（ｏｕｔｑ）３２にＰＵＴする。ｍｓｇ３３の内容は入力時と同じでもよいし、業務ＡＰＬ１４により必要に応じて書き換えられていてもよい。その後、データベースのコミットとＭＱのコミットを行うことで、ＤＢ２１に対する更新内容とｉｎｑ３１およびｏｕｔｑ３２に対するｍｓｇ３３のＧＥＴ／ＰＵＴの処理内容が確定してトランザクションが終了し、業務ＡＰＬ１４は次のトランザクションを実行することができる。
【００２６】
図５は、従来技術における例外発生時のトランザクション制御の例について概要を示した図である。図２の例と同様に、業務ＡＰＬ１４がトランザクションを開始してｉｎｑ３１からｍｓｇ３３をＧＥＴし、その内容に基づいてＤＢ２１へのアクセスも含む所定の業務処理を実行している際に、ｍｓｇ３３の内容の不備に基づく例外が発生した場合、従来技術では、データベースおよびＭＱの双方についてロールバックを行う。これにより、ＤＢ２１の内容がトランザクション開始時の状態に戻るとともに、ｍｓｇ３３もｉｎｑ３１に戻ることになる。
【００２７】
この場合、業務ＡＰＬ１４は、次のトランザクションとしてｉｎｑ３１から上記の不備を有するｍｓｇ３３を再度ＧＥＴして業務処理を行う結果、ｍｓｇ３３の内容の不備に基づく同じ内容の例外発生がループしてしまうことになる。その結果、他のサービス提供者に係るものも含めてｉｎｑ３１にキューイングされている後続のメッセージの処理が滞留するという影響が生じてしまう。
【００２８】
一方で、このような不備を有するｍｓｇ３３であっても運用事業者は通常これを独断で破棄したり修正したりすることはできず、対象のサービス提供者による処理もしくはその承認や指示に基づく処理が必要となる。そこで本実施の形態のＴＲＸ処理システム１では、業務ＡＰＬ１４が例外発生に係る不備データを有するｍｓｇ３３を例外管理ＡＰＬ１６に引き渡すことにより、ｉｎｑ３１にキューイングされている後続のメッセージの処理を可能とするとともに、不備データを有するｍｓｇ３３について、例外管理ＡＰＬ１６を介した対象のサービス提供者による自立的な対応を可能とする。
【００２９】
図３、図４は、本実施の形態における例外発生時のトランザクション制御の例について概要を示した図である。図３では、図５の例と同様に、業務ＡＰＬ１４がトランザクションを開始してｉｎｑ３１からｍｓｇ３３をＧＥＴし、その内容に基づいてＤＢ２１へのアクセスも含む所定の業務処理を実行している際に、ｍｓｇ３３の内容の不備に基づく例外が発生した場合を示している。
【００３０】
この場合、本実施の形態では、まず、ＴＲＸ制御部１５が対象のｍｓｇ３３に設定されているＩＤやシーケンス番号等のユニークな識別情報（ｍｓｇＩＤ）を例外管理テーブル１７に記録する。例外管理テーブル１７の実装方法は特に限定されないが、例えばメモリ上に展開されたテーブルやファイルなどを用いることができる。その後、図５の例と同様に、データベースおよびＭＱの双方についてロールバックを行う。これにより、ＤＢ２１の内容がトランザクション開始時の状態に戻るとともに、ｍｓｇ３３もｉｎｑ３１に戻る。
【００３１】
次に、図４に示すように、業務ＡＰＬ１４は、次のトランザクションとして再度ｉｎｑ３１から上記の不備を有するｍｓｇ３３をＧＥＴする。ここで、業務処理を開始する前にＴＲＸ制御部１５が対象のｍｓｇ３３に設定されているｍｓｇＩＤを取得し、同じｍｓｇＩＤが例外管理テーブル１７に登録されているか否かを確認する。登録されていない場合には、対象のｍｓｇ３３は以前に業務例外を発生させたものに該当しないと判断して、業務ＡＰＬ１４は当該ｍｓｇ３３に基づいて通常通り業務処理を行う。
【００３２】
一方、対象のｍｓｇＩＤが例外管理テーブル１７に登録されている場合は、対象のｍｓｇ３３に基づいて既に業務処理が行われ、その際に業務例外が発生してロールバックされたものであると判断することができる。この場合、業務ＡＰＬ１４（もしくはＴＲＸ制御部１５）は、対象のｍｓｇ３３をエラーキュー（ｅｒｒｑ）３４にＰＵＴする。このとき、ｍｓｇ３３に対して例外に係る各種情報を付加しておいてもよい。その後、ＭＱのコミットを行うことで（データベースのコミットを併せて行ってもよい）、ｉｎｑ３１およびｅｒｒｑ３４に対するｍｓｇ３３のＧＥＴ／ＰＵＴの処理内容が確定してトランザクションが終了し、業務ＡＰＬ１４は次のトランザクションを実行することができる。このとき、ＴＲＸ制御部１５は、例外管理テーブル１７に登録されている対象のｍｓｇＩＤのエントリを削除するようにしてもよい。
【００３３】
そして、ｅｒｒｑ３４（もしくはｅｒｒｑ３４からｍｓｇ３３の転送を受けた対応する他のキューであってもよい）にキューイングされたｍｓｇ３３については、別のサブシステムとして稼働する例外管理ＡＰＬ１６がこれをＧＥＴして、業務ＡＰＬ１４とは非同期にリカバリ処理を行う。例えば、対象のサービス提供者の担当者が使用するユーザ端末３に対して例外発生の旨の通知を行った上で対象のｍｓｇ３３の内容や例外の内容を提示し、修正等の例外原因の除去と、業務ＡＰＬ１４に対する再投入（すなわちｉｎｑ３１へのＰＵＴによるリトライ）の指示を受け付けて実行する。可能な場合にはユーザによる指示等を介さずに自動で修正等を行って業務ＡＰＬ１４に再投入する構成としてもよい。
【００３４】
以上に説明したように、本発明の一実施の形態であるＴＲＸ処理システム１によれば、業務ＡＰＬ１４に対してｉｎｑ３１から不備データを有するｍｓｇ３３が入力された場合に、例外管理テーブル１７にそのｍｓｇＩＤを記録した上でロールバックすることで、再度当該ｍｓｇ３３が入力された場合でもこれを判別し、ｅｒｒｑ３４を介して例外管理ＡＰＬ１６に引き渡すことができる。これにより、業務ＡＰＬ１４はｉｎｑ３１にキューイングされた後続のメッセージの処理を継続することができ、他のサービス提供者に係るものも含む後続のメッセージの処理に対して影響を与えずに可用性を向上させることができる。
【００３５】
また、例外管理ＡＰＬ１６を介して、対象のｍｓｇ３３に係るサービス提供者が自立的に修正等の例外原因の除去を行った上で業務ＡＰＬ１４に対する再投入を行うことができ、運用事業者の運用負荷を増大させずに不備データのリカバリを行うことを可能として可用性を向上させることができる。
【００３６】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【００３７】
例えば、上記の実施の形態では、図４に示すように、業務ＡＰＬ１４から例外管理ＡＰＬ１６への不備データを含むｍｓｇ３３の引き渡しをｅｒｒｑ３４を介して行っているが、このような構成に限られない。例えば、業務ＡＰＬ１４が図示しない例外管理用データベースに対してｍｓｇ３３の内容および例外情報等を書き込み、例外管理ＡＰＬ１６がその内容を参照できるようにすることで引き渡すような構成としてもよい。
【産業上の利用可能性】
【００３８】
本発明は、ＭＱによりデータの授受等の制御を行うトランザクション処理システムおよびトランザクション制御方法に利用可能である。
【符号の説明】
【００３９】
１…ＴＲＸ処理システム、２…ＮＷ、３…ユーザ端末、
１１…ＯＳ、１２…ＤＢＭＳ、１３…ＭＱ、１４…業務ＡＰＬ、１５…ＴＲＸ制御部、１６…例外管理ＡＰＬ、１７…例外管理テーブル、
２１…ＤＢ、
３１…ｉｎｑ、３２…ｏｕｔｑ、３３…ｍｓｇ、３４…ｅｒｒｑ
【図１】
2017094096.tif 000003
【図２】
2017094096.tif 000004
【図３】
2017094096.tif 000005
【図４】
2017094096.tif 000006
【図５】
2017094096.tif 000007
【手続補正書】
【提出日】平成28年12月14日(2016.12.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１のキューから第１のメッセージを取得して、前記第１のメッセージに基づいて１つ以上のサービス提供者についてデータベースへのアクセスを含む業務処理を実行し、第２のメッセージを第２のキューへ出力するトランザクション処理を実行する１つ以上の業務アプリケーションを有するトランザクション制御システムであって、
前記業務処理の実行時に例外が発生した前記第１のメッセージの識別情報を記録する例外管理テーブルと、
例外処理に係る第３のキューから第３のメッセージを取得して、例外管理処理を実行する例外管理アプリケーションと、を有し、
前記業務アプリケーションは、
前記トランザクション処理を開始して前記第１のキューから前記第１のメッセージを取得した後に、取得した前記第１のメッセージに係る前記識別情報が前記例外管理テーブルに記録されているか否かを確認し、記録されていない場合には前記業務処理を実行し、記録されている場合には前記第３のキューに前記第１のメッセージの内容を含む前記第３のメッセージを出力して前記トランザクション処理をコミットし、
前記業務処理の実行時に例外が発生した場合に、前記第１のメッセージの前記識別情報を前記例外管理テーブルに記録し、前記トランザクション処理をロールバックし、
前記例外管理アプリケーションは、
前記第３のキューから取得した前記第３のメッセージの内容を対応する前記サービス提供者に対して出力し、前記サービス提供者からの指示を受け付けて前記第３のメッセージに含まれる前記第１のメッセージに対して修正を行い、修正した前記第１のメッセージを前記第１のキューへ出力する、トランザクション制御システム。
【請求項２】
（削除）
【請求項３】
第１のキューから第１のメッセージを取得して、前記第１のメッセージに基づいて１つ以上のサービス提供者についてデータベースへのアクセスを含む業務処理を実行し、第２のメッセージを第２のキューへ出力するトランザクション処理を実行する１つ以上の業務アプリケーションを有するトランザクション制御システムにおけるトランザクション制御方法であって、
前記業務アプリケーションが、
前記トランザクション処理を開始して前記第１のキューから前記第１のメッセージを取得した後に、取得した前記第１のメッセージに係る前記識別情報が例外管理テーブルに記録されているか否かを確認し、記録されていない場合には前記業務処理を実行し、記録されている場合には例外処理に係る第３のキューに前記第１のメッセージの内容を含む第３のメッセージを出力して前記トランザクション処理をコミットする工程と、
前記業務処理の実行時に例外が発生した場合に、前記第１のメッセージの前記識別情報を前記例外管理テーブルに記録し、前記トランザクション処理をロールバックする工程と、
前記第３のキューから前記第３のメッセージを取得して、例外管理処理を実行する例外管理アプリケーションが、前記第３のメッセージの内容を対応する前記サービス提供者に対して出力し、前記サービス提供者からの指示を受け付けて前記第３のメッセージに含まれる前記第１のメッセージに対して修正を行い、修正した前記第１のメッセージを前記第１のキューへ出力する工程と、を有する、トランザクション制御方法。
【請求項４】
（削除）
【国際調査報告】
2017094096.tif 000008
2017094096.tif 000009
2017094096.tif 000010
2017094096.tif 000011