JP5128365B2

JP5128365B2 - 情報処理システム、情報処理方法、プログラム、及び、記録媒体

Info

Publication number: JP5128365B2
Application number: JP2008123443A
Authority: JP
Inventors: 勲上田; 貴信鶴野; 剛高塚; 智子鈴木; 義和小林
Original assignee: キヤノンソフトウェア株式会社
Priority date: 2008-05-09
Filing date: 2008-05-09
Publication date: 2013-01-23
Anticipated expiration: 2028-05-09
Also published as: JP2009271839A

Description

本発明は、ウェブアプリケーション（業務アプリケーション）が動作するウェブアプリケーションサーバと、ワークフローサーバとがネットワークを介して疎結合に構成される情報処理システムに関し、特に障害発生時の制御に関する。

疎結合システム（例えば、ウェブアプリケーションとワークフローアプリケーション等で構成されるシステム）において、障害時のデータの整合性を保つことは非常に困難である。

一般的には、密結合したアプリケーション同士であれば、全てのアプリケーションが２フェーズコミットに対応するなどして、データの原子性（トランザクションが終了した時点で、全ての処理が完了(コミット)しているか、全く行われていないか(ロールバック)のいずれかの状態であること。）を高い確率で保つようにすることが出来る。

ただし、この場合でも、通信障害が発生するなどの現象により、データの整合性を完全に保証することは出来ない。

特許文献１には、ワークフロー状態とアプリケーションの状態との整合を維持できるようにすることが示されているが、前述のような、通信障害によりデータの不整合が発生する可能性はあり、また不整合状態からのリカバリ手順は示されていない。
特開２０００−２９９５６号公報

しかしながら、互いに独立性の強い疎結合のアプリケーション同士だと、全体のトランザクションをモニタするような役割を担うシステムが無いため、障害時にデータの整合性を保つことがより困難となる。

障害が発生した場合、取り消し処理を行えば、整合性を復旧できるが、取り消すデータの範囲の特定が困難であり、作業も煩雑なものとなる。

本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、疎結合なシステムにおいて、障害発生により完全なデータの整合性が実現できない場合、障害発生時のデータ不整合を前提とし、それ以上、データ不整合を拡大させないようにすることを目的とする。
また、別の目的として、管理者の操作によって、簡便且つ速やかにデータ不整合を復旧することができる仕組を提供することを目的とする。

本発明は、ウェブアプリケーションサーバと、ワークフローサーバとがネットワークを介して疎結合に構成される情報処理システムであって、前記ウェブアプリケーションサーバは、トランザクション開始時における前記ワークフローサーバのワークフローデータベースが管理するワークフロー状態を保持しておく保持手段と、前記ウェブアプリケーションサーバが管理するウェブアプリケーションデータベースを更新するウェブアプリケーションデータベース更新手段と、前記ウェブアプリケーションデータベース更新手段による更新の後、前記ワークフローサーバに対し、該ワークフローサーバのワークフローデータベースが管理するワークフロー状態を更新させるための更新指示を行うワークフローデータベース更新指示手段と、前記ワークフローサーバからワークフロー状態が正常に更新された旨の更新結果を受信した場合、前記ウェブアプリケーションデータベース更新手段により更新されたウェブアプリケーションデータベースに対しコミット処理するコミット処理手段と、前記コミット処理手段によりコミット処理が正常に完了した場合、前記ワークフローサーバに対し、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示し、一方、前記コミット処理がエラーとなった場合、前記一時停止状態の解除を指示しない一時停止解除指示制御手段と、前記コミット処理手段によりコミット処理がエラーとなった場合、該ウェブアプリケーションデータベースをロールバックするロールバック手段と、前記ロールバック手段によりロールバックされた場合、前記保持手段に保持された前記トランザクション開始時の前記ワークフローデータベースが管理するワークフロー状態をログに出力するワークフロー状態ログ出力手段と、前記ワークフロー状態ログ出力手段により出力された前記トランザクション開始時のワークフロー状態を示すログの入力を、トランザクションリカバリ画面のワークフロー情報入力欄を介して受け付けるログ入力受付手段と、前記ログ入力受付手段により受け付けた前記トランザクション開始時のワークフロー状態を示すログに従って、ウェブアプリケーションデータベースを回復する操作を行うためのアプリケーション画面を表示する制御を行う表示制御手段と、前記表示制御手段により表示されたアプリケーション画面からの操作に応じて、前記ウェブアプリケーションデータベースを回復する回復手段とを有し、前記コミット処理手段は、前記回復手段により回復されたウェブアプリケーションデータベースに対してコミット処理を行い、一時停止解除指示制御手段は、ウェブアプリケーションデータベースとワークフローデータベースの不整合が解消された後になされるユーザの指示に応じて、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示するものであり、前記ワークフローサーバは、前記ワークフローデータベース更新指示手段による更新指示に応じて、前記ワークフローデータベースが管理するワークフロー状態を更新するワークフローデータベース更新手段と、前記ワークフローデータベース更新手段により更新されたワークフローデータベースが管理するワークフロー状態を一時停止状態にする一時停止手段と、前記一時停止手段によりワークフロー状態が一時停止状態にされたワークフローデータベースに対しコミット処理した後、前記ウェブアプリケーションサーバへ更新結果を通知する更新結果通知手段と、前記一時停止解除指示制御手段による一時停止解除指示に応じて、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態を解除する一時停止解除手段と、を有することを特徴とする。

本発明によれば、疎結合なシステムにおいて、障害により、データ不整合が発生した場合、それ以上、データ不整合を拡大させないようにするという効果を奏する。

図１は、本発明の一実施形態を示す情報処理システムの一例を示すシステム構成図である。本例では、基幹業務におけるワークフローアプリケーションの構成を示す。

図１において、００１，００２はアプリケーションサーバ（ウェブアプリケーションサーバ）である。アプリケーションサーバ１（００１），アプリケーションサーバ２（００２）は、業務処理（例えば、受注システム，出荷システム等）の業務アプリケーション（ウェブアプリケーション）を実行する。そして、アプリケーションサーバ１（００１）、アプリケーションサーバ２（００２）は、アプリケーションＤＢ００５（ウェブアプリケーションデータベース）に、上記業務データ（受注情報、在庫情報、出荷情報）を格納する。

ワークフローサーバ００３は、ワークフロー経路情報に従って、ワークフロー操作（承認、否認、差戻し等）処理を行い、ワークフローＤＢ００４（ワークフローデータベース）に、その情報を保管する。

クライアントブラウザ００６は、クライアント端末でウェブクライアントとして動作するウェブブラウザを示す。クライアントブラウザ００６は、ユーザの指示に従って、ネットワーク００７を介してアプリケーションサーバ１（００１）、アプリケーションサーバ２（００２）、ワークフローサーバ００３に通信し、アプリケーション処理を行う。

本情報処理システムは、独立性の高い業務アプリケーションとワークフローアプリケーションより構成されている疎結合システムである。なお、一般に、疎結合とは、細分化された個々のコンポーネント同士の結びつきが比較的緩やかで、独立性が強い状態のことをいう。

なお、図中、００１〜００６は、それぞれ異なる情報処理装置に実装されてもよいし、いずれか又は全てが同一の情報処理装置に実装される構成であってもよい。

図２は、図１に示した情報処理システムを構成する各装置に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。

図２において、１０１はＣＰＵであり、ＲＯＭ１０３或いは外部記憶装置（ハードディスク（ＨＤ）等）１０４に記憶されている制御プログラムに基づいて、システムバスに接続されている各種デバイスとのアクセスを総括的に制御する。

１０２はＲＡＭで、ＣＰＵ１０１の主メモリ、ワークエリア等として機能する。ＲＯＭ１０３或いはＨＤ１０４には、ＣＰＵ１０１の制御プログラムであるＢＩＯＳ（Basic Input / Output Ｓystem）やオペレーティングシステム（ＯＳ）プログラム、後述するフローチャートに示す処理をＣＰＵに実行させるために必要な各種プログラム等が記憶されている。そして、ＣＰＵ１０１は、必要なプログラム等をＲＡＭ１０２にロードして実行することにより、各種機能を実現するものである。

また、１０５は、キーボードやマウス等の入力装置である。１０６は、ＬＣＤやＣＲＴ等の表示装置である。１０７はネットワークインタフェースカード（ＮＩＣ）であり、ＬＡＮ，ＷＡＮ等のネットワーク００７を介して、他の装置と通信可能に構成されている。

以下、図３のシーケンスチャートを参照して、業務処理を業務アプリケーションで行い、ワークフローサーバでワークフロー処理をする場合の処理手順を示す。本処理は、クライアントから入力される要求に従って開始される。ここでは、受注システムの受注承認、在庫引当処理を行う場合を例にあげる。

図３，図４は、業務処理を業務アプリケーションで行いワークフローサーバでワークフロー処理をする場合の処理手順の一例を示すシーケンスチャートである。なお、図３はエラー発生しても各ＤＢ間に不整合が発生しない場合に対応する。一方、図４はエラー発生により各ＤＢ間に不整合が発生する場合に対応する。また、図３，図４において同一の処理には同一の番号を付してある。

さらに、図３，図４のシーケンスチャートで、アプリケーションサーバの処理は、アプリケーションサーバ（例えば、アプリケーションサーバ１（００１））を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、アプリケーションサーバが実行すると記載する。また、ワークフローサーバ００３の処理は、ワークフローサーバを実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、ワークフローサーバ００３が実行すると記載する。

まず、図３を用いて説明する。

まず、図３において、Ｓ２００１では、アプリケーションサーバ（例えば、アプリケーションサーバ１（００１））は、アプリケーションＤＢ００５にトランザクションの開始を指示する。

Ｓ２００２において、アプリケーションサーバは、アプリケーションＤＢ００５にデータを書き込む。例えば、受注情報の保管、在庫引当による商品在庫数の減少などデータ更新をする。

次に、Ｓ２００３において、アプリケーションサーバは、承認処理をワークフローサーバ００３に案件番号とともに要求する。ここで伝票番号は、予め、ワークフローサーバ００３の処理待ち一覧画面からアプリケーションサーバに受け渡されているものとする。

次に、Ｓ２００４において、ワークフローサーバ００３は、アプリケーションサーバからの承認処理要求（Ｓ２００３）を受け、ワークフロー情報を格納しているワークフローＤＢ００４にトランザクションの開始を指示する。

Ｓ２００５において、ワークフローサーバ００３は、承認処理のためワークフローＤＢ００４のアプリケーションサーバから渡された案件番号に関連するデータ（案件）を更新する。

さらに、Ｓ２００６において、ワークフローサーバ００３は、ワークフローＤＢ００４が管理する案件の状態をsuspend状態に変更する。

Ｓ２００７において、ワークフローサーバ００３は、ワークフローＤＢ００４にコミットを指示する。コミットとは、トランザクション処理が成功したときに、その結果を確定させることをいう。ここでは、更新されたワークフローＤＢ００４の結果を確定する指示を行っている。

なお、Ｓ２００５〜Ｓ２００７において、ワークフローサーバ００３、又は、ワークフローＤＢ００４においてエラーが発生した場合、ワークフローサーバ００３は、ワークフローＤＢ００４にロールバック処理をして、アプリケーションサーバにエラー発生を通知するものとする。この通知を受けて、アプリケーションサーバは、アプリケーションＤＢ００５をロールバック処理することができる。なお、上記エラーは、例えば、ワークフローＤＢ００４に障害が発生した場合に発生する。

Ｓ２００５〜Ｓ２００７の処理が正常終了した場合、Ｓ２００８において、ワークフローサーバ００３は、承認処理が完了したことをアプリケーションサーバへ通知する。

この通知を受信することにより正常終了を確認したアプリケーションサーバは、Ｓ２００９において、アプリケーションＤＢ００５にコミットを指示する。

そして、Ｓ２００９で指示したアプリケーションＤＢ００５のコミットが完了した場合、Ｓ２０１０において、アプリケーションサーバは、ワークフローサーバ００３に、案件の状態をsuspend状態からresume状態に変更することを、案件番号とともに要求する。

そして、Ｓ２０１１において、ワークフローサーバ００３は、ワークフローＤＢ００４が管理する案件の状態をsuspend状態からresume状態に変更する。

ここで、上記案件の状態を示すresume状態、suspend状態について説明する。

ワークフローサーバ００３で管理する案件は、常にresume状態あるいは、suspend状態の何れかとなるように、該案件の状態がワークフローＤＢ００４に保持されている。ワークフローサーバ００３は、案件について操作する場合（承認、否決、差戻し、引戻しなど）、この案件の状態が、resume状態でなければ操作できずエラーとなる。即ち、resume状態とは、案件を操作可能な状態（完了）を示す。一方、suspend状態とは、案件を操作できない状態（一時停止）を示す。

なお、図３に示したシーケンスで、ネットワークや機器不具合によるエラーが発生した場合、アプリケーションＤＢ００５とワークフローＤＢ００４のデータで不整合が発生する場合がある。

Ｓ２００１〜Ｓ２００７でエラーが発生した場合、上述したようにアプリケーションＤＢ００５、ワークフローＤＢ００４ともにロールバック処理をするため、それぞれのＤＢ内容の不整合は発生しない。

即ち、アプリケーションＤＢ００５がロールバックされるだけではなく、ワークフローＤＢ００４においても承認がなされず、ワークフロー処理が進まないため不整合が生じない。従って、このようなケースにおいては、本願発明の解決すべき課題は発生しない。

次に、図４を用いて、エラー発生により、アプリケーションＤＢ００５、ワークフローＤＢ００４の内容に不整合が発生してしまう場合について説明する。

図４のＳ２１１０に示すように、Ｓ２００９においてアプリケーションサーバが実行したコミット処理でエラーが発生した場合、Ｓ２１１１に示すように、アプリケーションＤＢ００５はロールバックされる。一方、ワークフローＤＢ００４は、Ｓ２００５において承認済みとなっており、アプリケーションＤＢ００５とワークフローＤＢ００４との間での不整合が生じてしまう。

しかし、案件の状態はsuspend状態（Ｓ２００６）のままであるため、ワークフローサーバ００３は、当該案件に対して、他の操作は行うことはできないため、さらに承認処理を継続して先に進めることは不可能になる。

以下、図５のフローチャートを参照して、図３に示したエラー発生しても各ＤＢ間に不整合が発生しない場合のアプリケーションサーバの処理について説明する。

図５は、アプリケーションサーバ（例えば、アプリケーションサーバ１（００１））の動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ２２０１〜Ｓ２２１７）は、アプリケーションサーバ（例えば、アプリケーションサーバ１（００１））を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、アプリケーションサーバが実行すると記載する。

Ｓ２２０１において、アプリケーションサーバは、セッション内のリカバリモードがtrueであるかチェックする。図３，図４のように通常の処理の場合、Ｓ２２０１の判断は偽（Ｎ）となる。アプリケーションサーバは、Ｓ２２０１において、リカバリモードでないと判断し、Ｓ２２０２に処理を進める。

Ｓ２２０２において、アプリケーションサーバは、アプリケーションサーバ側のメモリで保持管理するワークフロー状態（案件番号、処理情報等を含む）を初期化する。アプリケーションサーバは、案件番号を、ワークフローサーバ００３から予め受け取った現在処理対象の案件の案件番号で初期化する。また、アプリケーションサーバは、現在処理対象の案件の処理状態を示す処理状態を、「未処理」（ここでは処理前なので「未処理」）で初期化する。

次に、Ｓ２２０３において、アプリケーションサーバは、Ｓ２２０２で初期化したワークフロー状態のコピーを別途、アプリケーションサーバ側のメモリに保存しておく。

次に、Ｓ２２０４では、アプリケーションサーバは、図３のＳ２００１の通り、アプリケーションＤＢ００５にトランザクションの開始を指示する。

次に、Ｓ２２０５において、アプリケーションサーバは、図３のＳ２００２の通り、アプリケーションＤＢ００５の更新処理をする。また、アプリケーションサーバ上のログにＤＢ更新データログを出力する（図６）。

図６は、図５のＳ２２０５で出力されるログの出力例（ＤＢ更新データログ）を示す図である。

次に、Ｓ２２０６において、アプリケーションサーバは、Ｓ２２０５の処理でエラーが発生したか判断し、エラーが発生したと判断した場合には、Ｓ２２０７において、アプリケーションＤＢ００５をロールバックし、処理を終了する。

一方、Ｓ２２０６において、Ｓ２２０５の処理でエラーが発生していないと判断した場合には、アプリケーションサーバは、Ｓ２２０８に処理を進める。

Ｓ２２０８では、アプリケーションサーバは、セッション内のリカバリモードがtrueであるかチェックし、図３，図４の場合、リカバリモードがtrueでないので（通常モードであるので）、ワークフロー処理を行うため次のＳ２２０９に処理を進める。

Ｓ２２０９では、アプリケーションサーバは、ワークフロー処理（承認処理）をワークフローサーバ００３に指示し（図３のＳ２００３）、Ｓ２２１０に処理を進める。

Ｓ２２１０では、アプリケーションサーバは、ワークフロー処理が完了したため、ワークフロー処理状態を「処理済み」に変更する。ワークフロー処理状態は、後述する、クライアントに表示するボタンの状態（有効、無効）の判断などに使用するためにある。このワークフロー処理状態を使用して、例えば、一度、承認処理を行った後の、処理後の画面では、承認ボタンを無効化すること等ができる。

次に、Ｓ２２１１において、アプリケーションサーバは、ワークフロー処理の完了を確認したら（図３のＳ２００８）、アプリケーションＤＢ００５にコミットを指示する（図３のＳ２００９）。

次に、Ｓ２２１２において、アプリケーションサーバは、Ｓ２２１１のコミット処理エラーが発生したか判断する。図３に示した場合では、発生しないため、アプリケーションサーバは、Ｓ２２１２を偽（Ｎ）と判断し、Ｓ２２１４に処理を進める。

Ｓ２２１４では、アプリケーションサーバは、動作モードがリカバリモードかどうか判断する。図３のように通常の処理の場合、Ｓ２２１４の判断は偽（Ｎ）となる。アプリケーションサーバは、Ｓ２２１４において、リカバリモードでないと判断した場合には、Ｓ２２１５において、ワークフローサーバ００３に、案件の状態をsuspend状態からresume状態に変更する（一時停止状態を解除する）ことを、案件番号とともに要求する。そして、本フローチャートの処理を終了する。

以上、図３のＳ２００１〜Ｓ２０１１に示したエラー発生しても各ＤＢ間に不整合が発生しない場合のアプリケーションサーバの処理を説明した。

以下、図５のフローチャートを参照して、図４に示したエラー発生により各ＤＢ間に不整合が発生してしまう場合のアプリケーションサーバの処理について説明する。

Ｓ２２０１〜Ｓ２２１１は、前述の図３の場合と同一であるので、説明は省略する。

次に、Ｓ２２１２において、アプリケーションサーバは、Ｓ２２１１のコミット処理エラーが発生したか判断する。図４はコミット処理エラーが発生した場合であるため、アプリケーションサーバは、Ｓ２２１２を真（Ｙ）と判断し、Ｓ２２１３に処理を進める。

Ｓ２２１３では、アプリケーションサーバは、アプリケーションＤＢ００５のロールバック処理を行う。

次に、Ｓ２２１６において、アプリケーションサーバは、アプリケーションサーバ上のログに、Ｓ２２０３で別途、メモリに保存しておいたワークフロー状態を出力する（図７）。

図７は、図５のＳ２２１６で出力されるログの出力例（ワークフロー状態ログ）を示す図である。

図７において、６０１はワークフロー状態ログであり、図５のＳ２２１６で出力される保存しておいたワークフロー状態を示すログに対応する。

なお、図５には示していないが、エラーが発生した場合、アプリケーションサーバは、操作者のクライアントブラウザにエラー画面を表示し、システム管理者へ連絡するようにユーザに指示をする。そして、図５のフローチャートの処理を終了する。

即ち、図４に示した場合では、（Ｓ２２１５を実行しないため、）案件の状態はsuspend状態（Ｓ２００６）のままである。このため、ワークフローサーバ００３は、当該案件に対して、他の操作は行うことはできず、データ不整合を拡大させることがない。

以上、図４のＳ２００１〜Ｓ２００９，２１１０，２１１１に示したエラー発生により各ＤＢ間に不整合が発生する場合のアプリケーションサーバの処理を説明した。

次に、図８を参照して、図４で発生したエラーのリカバリ手順について（図１１）に示す。

図８は、図４で発生したエラーのリカバリ手順を示すシーケンスチャートである。

なお、図８のシーケンスチャートで、アプリケーションサーバの処理は、アプリケーションサーバ（例えば、アプリケーションサーバ１（００１））を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、アプリケーションサーバが実行すると記載する。また、ワークフローサーバ００３の処理は、ワークフローサーバを実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、ワークフローサーバ００３が実行すると記載する。さらに、クライアントブラウザ００６の処理は、クライアントブラウザ００６を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、クライアントブラウザ００６が実行すると記載する。

システム管理者は、ユーザから連絡を受け、アプリケーションサーバ上に出力されているログファイルから、ＤＢ更新データログ（図６）とワークフロー状態ログ（図７の６０１）を抽出する。そして、システム管理者は、ＤＢエラーの原因（例えば、アプリケーションＤＢ００５において発生した障害など）を除去したあと次の手順をする。

システム管理者の操作に応じて、クライアントブラウザ００６は、Ｓ２３０１において、アプリケーションサーバに、アプリケーションサーバのリカバリ画面（図９）の要求を送信する。

Ｓ２３０２では、アプリケーションサーバは、クライアントブラウザ００６からの要求に応じて、リカバリ画面（図９）をクライアントブラウザ００６に送信し、クライアントブラウザ００６にリカバリ画面（図９）を表示させる。

図９は、アプリケーションサーバのリカバリ画面の一例を示す図である。

図９に示すように、クライアントブラウザ００６にリカバリ画面が表示されると、システム管理者は、ログファイルから取得したワークフロー状態ログ（図７の６０１）をリカバリ画面のワークフロー情報項目８０１に入力する（例えば、コピー＆ペーストにより入力する）。さらに、システム管理者によって、リカバリ画面のリカバリモードで遷移ボタン８０２が押下されると、Ｓ２３０３において、クライアントブラウザ００６は、アプリケーションサーバに、ワークフロー情報項目８０１に入力されたワークフロー状態ログを送信してリカバリモード遷移を要求する。アプリケーションサーバは、クライアントブラウザ００６からの要求に基づいて、アプリケーションサーバ上のセッション内のリカバリモードをtrueにセットする。

次に、Ｓ２３０４において、アプリケーションサーバは、クライアントブラウザ００６から受け取ったワークフロー状態ログから、エラー発生時のアプリケーション画面を生成する。

そして、Ｓ２３０５において、アプリケーションサーバは、Ｓ２３０４で生成したアプリケーション画面をクライアントブラウザ００６に送信し、クライアントブラウザ００６にエラーが発生時のアプリケーション画面（図１０）を表示させる。

図１０は、アプリケーションサーバのリカバリモードでクライアントブラウザ００６に表示されるエラー発生時のアプリケーション画面の一例を示す図である。

システム管理者は、このとき、エラー発生時の処理で、エンドユーザが入力したデータは、エラーによりロールバックされているためシステム管理者が、再度入力する必要がある。なお、再入力する内容は、ＤＢ更新データログ（図６）から抽出することができる。

システム管理者は、例えば、エラー発生時のアプリケーション画面（図１０）の備考９０１に、ＤＢ更新データログ（図６）から取得した更新内容を再入力する。即ち、システム管理者は、前記ＤＢ更新データログから取得した更新内容に基づいてエラー発生時と同様の操作を行うことになる。

Ｓ２３０６において、システム管理者が、エラー発生時のアプリケーション画面（図１０）の承認ボタン９０２を押下すると、この操作を検知したクライアントブラウザ００６は、アプリケーションサーバに承認処理の実行を要求する。

この要求に応じて、アプリケーションサーバは、Ｓ２３０７において、リカバリモード時の処理を実行する。

以下、図５のフローチャートを参照して、リカバリモード時のアプリケーションサーバの処理について説明する。

Ｓ２２０１において、アプリケーションサーバは、セッション内のリカバリモードがtrueであるかチェックする。図８の場合、Ｓ２２０１の判断は真（Ｙ）となる。アプリケーションサーバは、Ｓ２２０１において、リカバリモードであると判断し、Ｓ２２１７に処理を進める。

次に、Ｓ２２１７において、アプリケーションサーバは、Ｓ２３０１でシステム管理者がリカバリ画面（図９）から入力したワークフロー状態ログ（図６の６０１）を読み取り、メモリ上にワークフロー状態オブジェクトを復元する。そして、アプリケーションサーバは、Ｓ２２０４に処理を進める。

Ｓ２２０４〜Ｓ２２０７は、前述の図３，図４の場合と同一であるので、説明は省略する。

Ｓ２２０８では、アプリケーションサーバは、セッション内のリカバリモードがtrueであるかチェックし、図８の場合、リカバリモードがtrueであるので、ワークフロー処理は行わないため、そのままＳ２２１０に処理を進める。

Ｓ２２１０では、アプリケーションサーバは、図３，図４の場合に示した通り、ワークフロー処理状態を「処理済み」に変更する。この処理は、リカバリモードであっても、ワークフロー処理状態に基づいて承認ボタンの有効／無効の判断に使用できるように更新する必要がある。

次に、Ｓ２２１１において、アプリケーションサーバは、アプリケーションＤＢ００５にコミットを指示する（図３のＳ２００９）。

次に、Ｓ２２１２において、アプリケーションサーバは、Ｓ２２１１のコミット処理エラーが発生したか判断し、エラーが発生しない場合には、Ｓ２２１４に処理を進める。

Ｓ２２１４では、アプリケーションサーバは、動作モードがリカバリモードかどうか判断する。図８の場合、リカバリモードであるので、案件はresumeせず、そのまま処理を終了する。

以上、２２０１〜２２１４の手順により、ワークフローサーバ００３の状態（ワークフローＤＢ００４）とアプリケーションＤＢ００５のデータ不整合が解消された状態になる。

この後、システム管理者は、クライアントブラウザ００６からワークフローの管理画面（図１１）にアクセスし、該ワークフローの管理画面（図１１）により、７０２に示すように、該当の案件を選択し、案件再開ボタン７０１を押下指示する。この操作に応じて、ワークフローサーバ００３は、該当の案件の状態（７０２）を、一時停止状態、即ちsuspend状態からresume状態（完了）に変更する。これにより、以後、当該案件を操作することが可能となる。

図１１は、ワークフローの管理画面の一例を示す図である。

以上、説明したように、本実施形態によれば、疎結合なシステムにおいて、図４に示したように、障害発生により完全なデータの整合性が実現できない場合、本実施形態の情報処理システムでは、障害発生時のデータ不整合を前提とし、それ以上、データ不整合を拡大させないようにしておく（suspend状態にしておく）。そして、図８〜図１１に示したように、管理者の操作によって、簡便且つ速やかにデータ不整合を復旧することができる。

また、リカバリ画面は、通常処理時の画面と同じであり、わざわざリカバリ用の画面を用意していない。そのため、リカバリ用の画面を作成する開発者の負担も減り、また管理者も同じ画面から回復することが可能となるため容易に回復操作をすることができる。

なお、本実施形態の情報処理システムが、アプリケーションサーバ（００１，００２）、アプリケーションＤＢ００５、ワークフローサーバ００３とワークフローＤＢ００４を備える場合について説明した。しかし、ワークフローサーバ００３とワークフローＤＢ００４の代わりに、他のアプリケーションサーバ、他のアプリケーションＤＢを備える構成であってもよい。この構成の場合、上述したような構成により、アプリケーションＤＢ００５と他のアプリケーションＤＢとの整合性がとれるようにする。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

以下、図１２に示すメモリマップを参照して本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。

図１２は、本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図３，図４，図５，図８に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

本発明の一実施形態を示す情報処理システムの一例を示すシステム構成図である。図１に示した情報処理システムを構成する各装置に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。業務処理を業務アプリケーションで行いワークフローサーバでワークフロー処理をする場合の処理手順の一例を示すシーケンスチャートである。

シーケンスチャートである。
業務処理を業務アプリケーションで行いワークフローサーバでワークフロー処理をする場合の処理手順の一例を示すシーケンスチャートである。アプリケーションサーバの動作の一例を示すフローチャートである。図５のＳ２２０５で出力されるログの出力例（ＤＢ更新データログ）を示す図である。図５のＳ２２１６で出力されるログの出力例（ワークフロー状態ログ）を示す図である。図４で発生したエラーのリカバリ手順を示すシーケンスチャートである。アプリケーションサーバのリカバリ画面の一例を示す図である。アプリケーションサーバのリカバリモードでクライアントブラウザ００６に表示されるエラーが発生時のアプリケーション画面の一例を示す図である。ワークフローの管理画面の一例を示す図である。本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。

符号の説明

００１アプリケーションサーバ１
００２アプリケーションサーバ２
００３ワークフローサーバ
００４ワークフローＤＢ
００５アプリケーションＤＢ
００６クライアントブラウザ
００７ネットワーク

Claims

ウェブアプリケーションサーバと、ワークフローサーバとがネットワークを介して疎結合に構成される情報処理システムであって、
前記ウェブアプリケーションサーバは、
トランザクション開始時における前記ワークフローサーバのワークフローデータベースが管理するワークフロー状態を保持しておく保持手段と、
前記ウェブアプリケーションサーバが管理するウェブアプリケーションデータベースを更新するウェブアプリケーションデータベース更新手段と、
前記ウェブアプリケーションデータベース更新手段による更新の後、前記ワークフローサーバに対し、該ワークフローサーバのワークフローデータベースが管理するワークフロー状態を更新させるための更新指示を行うワークフローデータベース更新指示手段と、
前記ワークフローサーバからワークフロー状態が正常に更新された旨の更新結果を受信した場合、前記ウェブアプリケーションデータベース更新手段により更新されたウェブアプリケーションデータベースに対しコミット処理するコミット処理手段と、
前記コミット処理手段によりコミット処理が正常に完了した場合、前記ワークフローサーバに対し、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示し、一方、前記コミット処理がエラーとなった場合、前記一時停止状態の解除を指示しない一時停止解除指示制御手段と、
前記コミット処理手段によりコミット処理がエラーとなった場合、該ウェブアプリケーションデータベースをロールバックするロールバック手段と、
前記ロールバック手段によりロールバックされた場合、前記保持手段に保持された前記トランザクション開始時の前記ワークフローデータベースが管理するワークフロー状態をログに出力するワークフロー状態ログ出力手段と、
前記ワークフロー状態ログ出力手段により出力された前記トランザクション開始時のワークフロー状態を示すログの入力を、トランザクションリカバリ画面のワークフロー情報入力欄を介して受け付けるログ入力受付手段と、
前記ログ入力受付手段により受け付けた前記トランザクション開始時のワークフロー状態を示すログに従って、ウェブアプリケーションデータベースを回復する操作を行うためのアプリケーション画面を表示する制御を行う表示制御手段と、
前記表示制御手段により表示されたアプリケーション画面からの操作に応じて、前記ウェブアプリケーションデータベースを回復する回復手段とを有し、
前記コミット処理手段は、前記回復手段により回復されたウェブアプリケーションデータベースに対してコミット処理を行い、一時停止解除指示制御手段は、ウェブアプリケーションデータベースとワークフローデータベースの不整合が解消された後になされるユーザの指示に応じて、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示するものであり、
前記ワークフローサーバは、
前記ワークフローデータベース更新指示手段による更新指示に応じて、前記ワークフローデータベースが管理するワークフロー状態を更新するワークフローデータベース更新手段と、
前記ワークフローデータベース更新手段により更新されたワークフローデータベースが管理するワークフロー状態を一時停止状態にする一時停止手段と、
前記一時停止手段によりワークフロー状態が一時停止状態にされたワークフローデータベースに対しコミット処理した後、前記ウェブアプリケーションサーバへ更新結果を通知する更新結果通知手段と、
前記一時停止解除指示制御手段による一時停止解除指示に応じて、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態を解除する一時停止解除手段と、
を有することを特徴とする情報処理システム。
前記ウェブアプリケーションサーバは、前記ウェブアプリケーションデータベース更新手段により前記ウェブアプリケーションデータベースが更新された際に、該更新内容をログに出力する更新内容ログ出力手段を更に有し、
前記回復手段は、前記更新内容ログ出力手段により出力されたログに記載された更新内容に対応する、前記アプリケーション画面からの操作に応じて、前記ウェブアプリケーションデータベースを回復することを特徴とする請求項１に記載の情報処理システム。
前記表示制御手段は、前記トランザクション開始時のワークフロー状態を示すログに従って、前記アプリケーション画面として前記エラー発生時のウェブアプリケーション画面を表示する制御を行い、
前記回復手段は、前記更新内容ログ出力手段により出力されたログに記載された更新内容に対応する、前記エラー発生時のウェブアプリケーション画面からの前記エラー発生時の操作に応じて、前記ウェブアプリケーションデータベースを回復することを特徴とする請求項２に記載の情報処理システム。
前記ウェブアプリケーションサーバは、前記ログ入力受付手段により前記ログの入力を受け付けた場合、当該ウェブアプリケーションサーバの動作モードとして回復モードを設定する設定手段とを更に有し、
前記ウェブアプリケーションデータベース更新手段は、前記回復モードが設定されている場合、前記回復手段として動作することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
ウェブアプリケーションサーバと、ワークフローサーバとがネットワークを介して疎結合に構成される情報処理システムにおいて実行可能なプログラムであって、
前記ウェブアプリケーションサーバを、
トランザクション開始時における前記ワークフローサーバのワークフローデータベースが管理するワークフロー状態を保持しておく保持手段と、
前記ウェブアプリケーションサーバが管理するウェブアプリケーションデータベースを更新するウェブアプリケーションデータベース更新手段と、
前記ウェブアプリケーションデータベース更新手段による更新の後、前記ワークフローサーバに対し、該ワークフローサーバのワークフローデータベースが管理するワークフロー状態を更新させるための更新指示を行うワークフローデータベース更新指示手段と、
前記ワークフローサーバからワークフロー状態が正常に更新された旨の更新結果を受信した場合、前記ウェブアプリケーションデータベース更新手段により更新されたウェブアプリケーションデータベースに対しコミット処理するコミット処理手段と、
前記コミット処理手段によりコミット処理が正常に完了した場合、前記ワークフローサーバに対し、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示し、一方、前記コミット処理がエラーとなった場合、前記一時停止状態の解除を指示しない一時停止解除指示制御手段と、
前記コミット処理手段によりコミット処理がエラーとなった場合、該ウェブアプリケーションデータベースをロールバックするロールバック手段と、
前記ロールバック手段によりロールバックされた場合、前記保持手段に保持された前記トランザクション開始時の前記ワークフローデータベースが管理するワークフロー状態をログに出力するワークフロー状態ログ出力手段と、
前記ワークフロー状態ログ出力手段により出力された前記トランザクション開始時のワークフロー状態を示すログの入力を、トランザクションリカバリ画面のワークフロー情報入力欄を介して受け付けるログ入力受付手段と、
前記ログ入力受付手段により受け付けた前記トランザクション開始時のワークフロー状態を示すログに従って、ウェブアプリケーションデータベースを回復する操作を行うためのアプリケーション画面を表示する制御を行う表示制御手段と、
前記表示制御手段により表示されたアプリケーション画面からの操作に応じて、前記ウェブアプリケーションデータベースを回復する回復手段として機能させ、
前記コミット処理手段は、前記回復手段により回復されたウェブアプリケーションデータベースに対してコミット処理を行い、一時停止解除指示制御手段は、ウェブアプリケーションデータベースとワークフローデータベースの不整合が解消された後になされるユーザの指示に応じて、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示するものであり、
前記ワークフローサーバを、
前記ワークフローデータベース更新指示手段による更新指示に応じて、前記ワークフローデータベースが管理するワークフロー状態を更新するワークフローデータベース更新手段と、
前記ワークフローデータベース更新手段により更新されたワークフローデータベースが管理するワークフロー状態を一時停止状態にする一時停止手段と、
前記一時停止手段によりワークフロー状態が一時停止状態にされたワークフローデータベースに対しコミット処理した後、前記ウェブアプリケーションサーバへ更新結果を通知する更新結果通知手段と、
前記一時停止解除指示制御手段による一時停止解除指示に応じて、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態を解除する一時停止解除手段として機能させることを特徴とするプログラム。
請求項５に記載のプログラムをコンピュータ読み取り可能に記録した記録媒体。
ウェブアプリケーションサーバと、ワークフローサーバとがネットワークを介して疎結合に構成される情報処理システムにおけるウェブアプリケーションサーバであって、
トランザクション開始時における前記ワークフローサーバのワークフローデータベースが管理するワークフロー状態を保持しておく保持手段と、
前記ウェブアプリケーションサーバが管理するウェブアプリケーションデータベースを更新するウェブアプリケーションデータベース更新手段と、
前記ウェブアプリケーションデータベース更新手段による更新の後、前記ワークフローサーバに対し、該ワークフローサーバのワークフローデータベースが管理するワークフロー状態を更新させるための更新指示を行うワークフローデータベース更新指示手段と、
前記ワークフローサーバからワークフロー状態が正常に更新された旨の更新結果を受信した場合、前記ウェブアプリケーションデータベース更新手段により更新されたウェブアプリケーションデータベースに対しコミット処理するコミット処理手段と、
前記コミット処理手段によりコミット処理が正常に完了した場合、前記ワークフローサーバに対し、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示し、一方、前記コミット処理がエラーとなった場合、前記一時停止状態の解除を指示しない一時停止解除指示制御手段と、
前記コミット処理手段によりコミット処理がエラーとなった場合、該ウェブアプリケーションデータベースをロールバックするロールバック手段と、
前記ロールバック手段によりロールバックされた場合、前記保持手段に保持された前記トランザクション開始時の前記ワークフローデータベースが管理するワークフロー状態をログに出力するワークフロー状態ログ出力手段と、
前記ワークフロー状態ログ出力手段により出力された前記トランザクション開始時のワークフロー状態を示すログの入力を、トランザクションリカバリ画面のワークフロー情報入力欄を介して受け付けるログ入力受付手段と、
前記ログ入力受付手段により受け付けた前記トランザクション開始時のワークフロー状態を示すログに従って、ウェブアプリケーションデータベースを回復する操作を行うためのアプリケーション画面を表示する制御を行う表示制御手段と、
前記表示制御手段により表示されたアプリケーション画面からの操作に応じて、前記ウェブアプリケーションデータベースを回復する回復手段とを有し、
前記コミット処理手段は、前記回復手段により回復されたウェブアプリケーションデータベースに対してコミット処理を行い、一時停止解除指示制御手段は、ウェブアプリケーションデータベースとワークフローデータベースの不整合が解消された後になされるユーザの指示に応じて、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示することを特徴とするウェブアプリケーションサーバ。
ウェブアプリケーションサーバと、ワークフローサーバとがネットワークを介して疎結合に構成される情報処理システムにおけるウェブアプリケーションサーバを、
トランザクション開始時における前記ワークフローサーバのワークフローデータベースが管理するワークフロー状態を保持しておく保持手段と、
前記ウェブアプリケーションサーバが管理するウェブアプリケーションデータベースを更新するウェブアプリケーションデータベース更新手段と、
前記ウェブアプリケーションデータベース更新手段による更新の後、前記ワークフローサーバに対し、該ワークフローサーバのワークフローデータベースが管理するワークフロー状態を更新させるための更新指示を行うワークフローデータベース更新指示手段と、
前記ワークフローサーバからワークフロー状態が正常に更新された旨の更新結果を受信した場合、前記ウェブアプリケーションデータベース更新手段により更新されたウェブアプリケーションデータベースに対しコミット処理するコミット処理手段と、
前記コミット処理手段によりコミット処理が正常に完了した場合、前記ワークフローサーバに対し、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示し、一方、前記コミット処理がエラーとなった場合、前記一時停止状態の解除を指示しない一時停止解除指示制御手段と、
前記コミット処理手段によりコミット処理がエラーとなった場合、該ウェブアプリケーションデータベースをロールバックするロールバック手段と、
前記ロールバック手段によりロールバックされた場合、前記保持手段に保持された前記トランザクション開始時の前記ワークフローデータベースが管理するワークフロー状態をログに出力するワークフロー状態ログ出力手段と、
前記ワークフロー状態ログ出力手段により出力された前記トランザクション開始時のワークフロー状態を示すログの入力を、トランザクションリカバリ画面のワークフロー情報入力欄を介して受け付けるログ入力受付手段と、
前記ログ入力受付手段により受け付けた前記トランザクション開始時のワークフロー状態を示すログに従って、ウェブアプリケーションデータベースを回復する操作を行うためのアプリケーション画面を表示する制御を行う表示制御手段と、
前記表示制御手段により表示されたアプリケーション画面からの操作に応じて、前記ウェブアプリケーションデータベースを回復する回復手段として機能させ、
前記コミット処理手段は、前記回復手段により回復されたウェブアプリケーションデータベースに対してコミット処理を行い、一時停止解除指示制御手段は、ウェブアプリケーションデータベースとワークフローデータベースの不整合が解消された後になされるユーザの指示に応じて、前記ワークフローデータベースが管理するワークフロー状態の一時停止状態の解除を指示することを特徴とするプログラム。