JP3712984B2 - 業務進捗制御装置及びその方法と、業務進捗制御プログラム及びそのプログラムを記録した記録媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
複数の単位業務の組み合わせによって構成される複合業務の進捗を制御する業務進捗制御装置及びその方法と、その業務進捗制御方法の実現に用いられる業務進捗制御プログラム及びそのプログラムを記録した記録媒体とに関する。
【０００２】
【従来の技術】
（１）分散トランザクションサービス
クライアントサーバ型システム環境や分散オブジェクト指向型システム環境においては、従来から分散トランザクションサービスを提供する標準ＡＰＩが存在する。
【０００３】
例えば、Ｘ／Ｏpen(X/Open Company Limited) で制定するＸＡインターフェイス、あるいはＯＭＧ（Object Management Group)で制定するＯＴＳ／Ｒesource Ｉnterface (Object Transaction Service）、あるいはＩＳＯ（International Organization for Standardization）で制定するＯＳＩ−ＴＰ（Transaction Processing）などである。
【０００４】
分散トランザクションサービスを利用する際は、それに参加するサブシステムを前記標準ＡＰＩに適合させる必要がある。このため、サブシステムがレガシィシステムである等の理由により直接改造ができない場合は、アダプタを作成しなければならない。
【０００５】
ここで、異なる開発経緯のサブシステムを複数統合して１つのトランザクションを処理する場合、各サブシステムにおける業務処理や取消操作の粒度が異なるために、前記アダプタが使えない場合がある。
【０００６】
例えば、ひとつの伝票に対する処理が完了するまでに数日かかるような業務ドメインの場合、その伝票に対して実行される単位業務ごとに、完結したトランザクションとして扱うのが一般的である。すなわち、１つのトランザクションとして扱う処理の粒度を小さく抑える設計とするのが一般的である。
【０００７】
さらに、取消操作については、それに対応する単位業務と同じ粒度で定義されるとは限らない。例えば、Ａという単位業務と、Ａに続いて行われるＢという単位業務とが存在した場合、Ａの取消操作Ａ’と、Ｂの取消操作Ｂ’とが、前記単位業務と１対１に対応しない場合がある。つまりＢを取り消す場合は、Ｂ’を実行するが、その後、Ａ’を実行しなくても、Ａを実行する前の状態まで一気に戻す形の設計が考えられる。
【０００８】
これは、ＡとＢとの間の状態は一時的なものであり、取消操作としては、常にＡの前の状態まで戻すほうがその業務ドメインで一般化している場合に行われる。すなわち、取消操作の粒度を業務ドメインの事情にあわせて設計する場合がしばしば発生する。
【０００９】
他の業務ドメインのシステムについても、前記と同様に、そのドメインに適した処理粒度で設計される。
【００１０】
このような場合、各業務ドメインで既に稼動しているシステムを複数連携させて、より大域的な業務処理を実行するシステムに統合しようとしても、サブシステム相互の処理粒度の違い、ならびにサブシステムと統合システムとの間の処理粒度の違い、あるいは単位業務とそれに対応する取消操作の粒度の違い、等をアダプタによって吸収することは困難である。
【００１１】
一方、トランザクションに参加するサブシステムに対して、コミット操作あるいはロールバック操作を行う場合は、全てに対して一律にどちらか一方の操作を指定する。これはトランザクションのアトミック性を維持することで、システム上のデータの一貫性を保証する考え方である。
【００１２】
しかし、前記の大域的な業務処理においては、一貫性が保証できる形で途中の状態へロールバックさせたい場合がある。分散トランザクションサービスでは、このような要求に対応できない。途中の状態へのロールバック処理を、分散トランザクションを複数組み合せて実現しようとすると、複雑なプログラムコードが必要となるため、開発・改造に大きなコストがかかってしまう。
【００１３】
（２）ワークフローエンジン
複合業務の進捗を管理制御するミドルウェアとして、ワークフローエンジンが広く用いられている。
【００１４】
ワークフローエンジンは、複合業務の構成要素である単位業務について、その処理の実装がどのようなプロセスで構成されているか、どのようなマシン上で稼動しているか、どのようなソフトウェアアーキテクチャ上で実装されているかに関係なく、業務の進捗状態を制御管理できる。近年では、ワークフローエンジンのフロー記述形式が標準化されており、ベンダ依存性も解消される見通しとなっている。
【００１５】
しかし、業務進捗状態を戻す処理が必要な場合、ワークフロー記述では分散トランザクションのようにロールバックの概念がないため、取消の操作も通常の操作と同じように記述しなければならない。
【００１６】
一部の市販ワークフローパッケージには、ワークフロー記述を補助するものとして、ルール記述をワークフロー上のノードと関連付けて与えておくと、当該ノードに進捗が到達した場合に、当該ルールとのマッチングを行うことで、柔軟な進捗状態管理制御機能を提供するものが存在する。
【００１７】
この機能を利用すると、複雑な進捗過程を簡潔なワークフローとして記述することができるが、ルールの適用は進捗状態が当該ノードに停留している場合にのみ行われるので、ロールバック処理の記述には使うことができない。なぜならば、ロールバック処理は、本質的に複数の進捗状態に跨る処理であり、前記のように特定の進捗状態だけで有効な、いわばローカルなスコープに限定されたルールの適用では、実現できないからである。
【００１８】
また、ワークフローパッケージを、ロールバック処理が実現できるように拡張することも考えられるが、特定の業務ドメインに限定された仕様となってしまうために現実的ではない。さらに、ドメインを限定しないようにするために、外部の記述を読み込むようにすることも考えられるが、当該ワークフローエンジンの独自仕様に依存したワークフロー記述となることで、前記標準記述形式との互換性が失われてしまう。
【００１９】
（３）ルールエンジン
複合業務の進捗を管理制御するミドルウェアとして、ワークフローエンジン以外に、ルール形式で記述したスクリプトを解釈実行するルールエンジンが存在する。
【００２０】
ルールにもとづく処理は、複雑な条件判断が多数必要な場合に、ワークフローよりも簡潔に動作を記述できるという利点がある。
【００２１】
しかし、ルールの実行部に記述できる処理は、内部変数への値の設定もしくは内部オブジェクトへのメッセージ送信のみであるため、単独で複雑な動作を実現することはできず、内部オブジェクトの実装部分とどのように組み合せるかが重要になる。
【００２２】
ルールエンジンとして市販されているミドルウェアが既に存在し、これらはビジネスロジックの記述に適合するよう、ルール間の優先順位制御、ルール間の排他制御、前提ルールの導入、などを行っている。
【００２３】
しかし、判定の結果として起動される処理は、前記同様、単純なメッセージ送信のみである。したがって、複合業務の進捗について順方向への制御は柔軟に行えるが、トランザクションにおけるロールバック処理のような逆方向への制御は実現が困難である。
【００２４】
【発明が解決しようとする課題】
（１）実装上の制約の問題
分散トランザクションは、異なる業務ドメインで既に稼動しているシステムを複数連携させる場合、業務ドメインごとの最適設計で生じた処理粒度の違いを吸収することが困難である。
【００２５】
（２）進捗状態管理制御の柔軟性の問題
分散トランザクションは、トランザクションに参加する複数の処理対象に対する操作を非分割にすることで、業務状態の一貫性を保証するだけなので、複合業務における途中の進捗状態までロールバックする等といったような柔軟な管理制御を行うことはできない。
【００２６】
（３）ワークフロー記述の大規模複雑化の問題
ワークフローエンジンは、取消の操作も通常の操作と同じように記述するため、進捗管理制御の自由度は高い。
【００２７】
そのかわり、分散トランザクションサービスのロールバック処理のように、常に内部状態の一貫性を維持するための自動的な機能は提供されないので、システムが常に一貫性を維持するよう、メイン処理とロールバック処理の整合性を取ってワークフローを記述しなければならない。
【００２８】
一般に、実行時例外はワークフロー上のあらゆる個所で発生する可能性があるため、ロールバック処理を記述するためには多くの判断分岐が必要となり、ワークフロー記述そのものが大規模かつ複雑化してしまう。その結果、開発、デバッグ、改造に稼動がかかりすぎるため、時間的、経済的コストが増大する、あるいは設計仕様やテスト内容にもれが生じやすくなるため、プログラムの品質が低下するなどの問題がある。
【００２９】
（４）記述形式の問題
ワークフローエンジンに対し、ロールバック処理が可能なように拡張することも考えられる。
【００３０】
しかし、この場合には、特定の業務ドメインへの限定を避けるため、外部記憶装置上のカスタマイズ用記述データに基づいて動作を変えられるようにする必要がある。
【００３１】
このカスタマイズ用記述として、ワークフロー記述の形式を変更して対応すると、ワークフロー記述の標準形式との互換性が失われ、当該ワークフローエンジン以外への記述の移植ができなくなるという問題がある。
【００３２】
このような従来技術の持つ問題を解決するために、本発明は、次のようなシステムの提供を目的とする。
【００３３】
（イ）実装上の制約に関する目的
本発明は、業務ドメインごとの最適設計により処理粒度の違いが生じた場合、既存のサブシステムに改造を加えずに、かつ複雑なプログラムコードを必要としない方法で、これらの違いを吸収し、一貫性を維持したロールバック処理が可能な業務進捗制御装置を提供することを目的とする。
【００３４】
（ロ）進捗状態管理制御の柔軟性に関する目的
本発明は、複数の単位業務が束集合的依存関係を構成するような複雑な複合業務において、途中の段階までのロールバック処理が可能な業務進捗制御装置を提供することを目的とする。
【００３５】
（ハ）ワークフロー記述の大規模複雑化に関する目的
本発明は、前記記載の柔軟なロールバック処理を、ワークフロー形式で記述する場合に比較して、簡潔かつ管理しやすい形式で記述できる業務進捗制御装置を提供することを目的とする。
【００３６】
（ニ）記述形式に関する目的
本発明は、既存のワークフローエンジンに他のミドルウェアとの接続性を損なう改造や、ワークフロー記述の標準形式との互換性を失う拡張を行うことなく、ロールバック処理の実行方法ならびにロールバック処理の記述形式によって動作する業務進捗制御装置を提供することを目的とする。
【００３７】
【課題を解決するための手段】
この目的を達成するために、本発明の業務進捗制御装置は、複数の単位業務の組み合わせによって構成される複合業務の進捗を制御するという構成を採るときにあって、（１）単位業務の識別子をキーにして、その単位業務に先行して完了すべき他の単位業務の情報、その単位業務に対応する取消操作の情報およびその取消操作が包含する他の取消操作の情報をルールの形で保存するルール保存手段と、（２）単位業務及びその取消操作の間の関係を示すネットワークデータを保存するネットワークデータ保存手段と、（３）単位業務の処理を進めるときに、ルール保存手段に保存されるルールに従って、ネットワークデータ保存手段に保存されるネットワークデータを更新する更新手段と、（４）単位業務の進捗状態を元に戻す必要があるときに、ネットワークデータ保存手段に保存されるネットワークデータに従って、それに必要となる取消操作を検索する検索手段と、（５）検索手段の検索した取消操作の実行を指示する指示手段とを備えるように構成する。
【００３８】
このように構成される本発明の業務進捗制御装置では、ルール保存手段は、単位業務に先行して完了すべき他の単位業務の情報や、単位業務に対応する取消操作の情報や、その取消操作が包含する他の取消操作の情報について記述するルールを保存する。
【００３９】
このルール保存手段に保存されるルールを受けて、更新手段は、単位業務の処理を進めるときに、その単位業務の識別子をキーにしてその保存されるルールを検索し、その検索したルールに従って、ネットワークデータ保存手段に保存されるネットワークデータを更新する。
【００４０】
このようにして更新されるネットワークデータは、例えば、各単位業務を起点として、その単位業務の取消操作と、その取消操作が包含する取消操作と、その包含される取消操作に対応付けられる単位業務と、さらに、その対応付けられる単位業務を起点として同様にリンクしていく取消操作・単位業務というように、単位業務及びその取消操作の間の関係（依存関係や包含関係）を示すものとなっている。
【００４１】
このネットワークデータを受けて、検索手段は、単位業務の進捗状態を元に戻す必要があるときには、進捗状態を戻す単位業務として指定される単位業務を起点にしてネットワークデータを辿ることで、そのロールバックに必要となる取消操作を検索する。このとき、包含先となる取消操作については、包含元となる取消操作を行えば取り消したことになることを考慮しつつ取消操作を検索する。
【００４２】
この検索された取消操作を受けて、指示手段は、その検索された取消操作の実行を指示することで、単位業務の進捗状態を元に戻す（ロールバックする）ように処理する。
【００４３】
この構成を採るときに、単位業務の間に依存関係はないものの、別の理由で単位業務をグループ化して、それらを一括してロールバックしたいというような要求の出ることがある。
【００４４】
このときには、そのグループ化を実現するためのダミーの単位業務や取消操作（依存関係にない単位業務をグループ化するために定義される業務処理を行わないダミーの単位業務や、そのダミーの単位業務に対応付けられるダミーの取消操作）が用意されることになるので、ルール保存手段は、そのダミーの単位業務や取消操作について記述するルールを用意することになる。
【００４５】
但し、このとき、更新手段は、ダミーの単位業務や取消操作についても正規の単位業務や取消操作と何ら変わることなく、単位業務の識別子をキーにしてその保存されるルールを検索し、その検索したルールに従って、ネットワークデータ保存手段に保存されるネットワークデータを更新することになる。
【００４６】
このように構成される本発明の業務進捗制御装置によれば、複数のサブシステムを統合して１つの統合された業務システムを構築する場合にあって、▲１▼サブシステム相互に処理粒度の違い（サブシステムＡとサブシステムＢとで単位業務の大きさや数が異なるといったような処理粒度の違い）があっても、▲２▼また、単位業務とそれに対応する取消操作の処理粒度の違い（単位業務と取消操作が１対１に対応したりしなかったりといったような処理粒度の違い）があっても、▲３▼また、サブシステムと統合された業務システムとの間の処理粒度の違い（処理時間が異なるといったような処理粒度の違い）があっても、その違いを吸収できることから、統合された業務システム上で一貫性を維持したロールバックが可能になる。
【００４７】
また、ルール形式の動作記述に従って、処理を行った単位業務及びその取消操作の間の依存関係や包含関係を記憶管理して、それに基づいてロールバックを行うことから、複雑なプログラムコードを必要とせずにロールバックが可能になり、また、ワークフロー記述などにロールバック処理を記述しなくてもロールバックが可能になり、また、ワークフロー記述などを変更しなくてもロールバックが可能になる。
【００４８】
本発明の業務進捗制御装置の動作については、半導体メモリなどのような適当な記録媒体に記録して提供可能な本発明の業務進捗制御プログラムをインストールすることにより実現されることになる。
【００４９】
この本発明の業務進捗制御プログラムは、上述のルール保存手段からルールを読み出す処理と、単位業務の処理を進めるときに、その読み出したルールに従って、上述のネットワークデータ保存手段に保存されるネットワークデータを更新する処理と、単位業務の進捗状態を元に戻す必要があるときに、上述のネットワークデータ保存手段に保存されるネットワークデータに従って、それに必要となる取消操作を検索する処理と、その検索した取消操作の実行を指示する処理とをコンピュータに実行させるための処理を行うことで、複数の単位業務の組み合わせによって構成される複合業務の進捗を制御する処理を行う。
【００５０】
このように構成される本発明の業務進捗制御プログラムについては、独立したミドルウェアに集約することで実現することが考えられる。
【００５１】
すなわち、単位業務の進行を制御するミドルウェアとして用意される外部プログラム（例えば市販のワークフローエンジン）とは別の形のミドルウェアとして、本発明の業務進捗制御プログラムを実現することが考えられる。
【００５２】
ミドルウェアとして実現する場合には、本発明の業務進捗制御プログラムは、単位業務の進行を制御する外部プログラムから単位業務の処理依頼を受け取るとともに、その処理依頼を受けた単位業務の実行を指示し、さらに、その外部プログラムから単位業務の進捗状態を元に戻す処理依頼を受け取るように処理することになる。ここで、進捗状態を元に戻す処理依頼については、外部プログラムが発行する他に、単位業務の実行に失敗するときに、自動的に発行されることになる。
【００５３】
この構成に従う場合には、ミドルウェアが互いに独立なプロセスとして動作するとともに、メモリ空間を共有しないことから、ミドルウェア間の連携を実現する構成を構築する必要がある。
【００５４】
一方、例えば、同一のワークフロー記述を別々のユーザが使用することがあり、このような場合（処理は同じだがインスタンスが異なる）には、それらのユーザの固有のネットワークデータがネットワークデータ保存手段に保存されることで、それらを区別していく必要がある。
【００５５】
このような事情を考慮して、本発明の業務進捗制御プログラムは、ミドルウェアで構成されるときに、外部プログラムから処理依頼を受けた１つ又は複数の単位業務に対して、その実行毎に割り振られるユニークな識別子であるインスタンスな識別子を生成し、ネットワークデータ保存手段に保存されるネットワークデータの該当する単位業務にそれを記録するとともに、外部プログラムに対してそれを通知する処理を行う。
【００５６】
このインスタンス識別子の通知を受け取ると、外部プログラムは、必要に応じてインスタンス識別子を指定して単位業務の処理依頼を発行したり、必要に応じてインスタンス識別子を指定して単位業務の進捗状態を元に戻す処理依頼を発行することで、インスタンスの違いを考慮した形で処理依頼を発行できるようになる。
【００５７】
さらに、本発明の業務進捗制御プログラムは、親子関係を有するインスタンス識別子を生成する処理を行う。
【００５８】
例えば、ある単位業務グループを実行後、ワークフローが分岐し、それぞれのフローにおいて、同一の複数の単位業務が実行されることがあり、そのような場合には、どちら側のフローのインスタンスであるのかを区別していく必要がある。また、例えば、入れ子のワークフローにおいても、同一の複数の単位業務が実行されることがあり、そのような場合には、フローのどの箇所のインスタンスであるのかを区別していく必要がある。
【００５９】
このような事情を考慮して、本発明の業務進捗制御プログラムは、親に相当する単位業務グループ（１つ又は複数の単位業務で構成される）に対して、子に相当する単位業務グループ（１つ又は複数の単位業務で構成される）があれば、前者のインスタンス識別子を親として持つインスタンス識別子を後者に割り当てることで、外部プログラムが親子関係を有するインスタンス識別子を使って処理依頼を行えるようにする。
【００６０】
そして、その親子関係を持つインスタンス識別子の生成機能に合わせて、本発明の業務進捗制御プログラムは、インスタンス識別子を指定して、親子関係にあるインスタンス識別子の検索要求を発行し、その検索結果を受け取る処理を行ったり、２つのインスタンス識別子を指定して、包含関係にあるのか否かの判定要求を発行し、その判定結果を受け取る処理を行う。
【００６１】
例えば、ワークフローが分岐しているような場合にあって、分岐後の単位業務グループ（子に相当する）内で処理を取り消す必要が起こると、分岐前の単位業務グループ（親に相当）内で処理を取り消す必要が起こる場合がある。
【００６２】
そのような場合に、本発明の業務進捗制御プログラムは、このような親子関係を有するインスタンス識別子の機能を持つことで、分岐後の単位業務グループのインスタンス識別子から、分岐前の単位業務グループのインスタンス識別子を直ちに特定できるようになり、そのような取り消しのためのネットワークデータを作成できるようになることで、そのような取り消しを簡単に行うことができるようになる。
【００６３】
また、例えば、ワークフローの記述が入れ子となっているような場合にあって、入れ子の内側の単位業務グループ（子に相当する）内で処理を取り消す必要が起こると、入れ子の外側の単位業務グループ（親に相当）内で処理を取り消す必要が起こる場合がある。
【００６４】
そのような場合に、本発明の業務進捗制御プログラムは、このような親子関係を有するインスタンス識別子の機能を持つことで、入れ子の内側の単位業務グループのインスタンス識別子から、入れ子の外側のインスタンス識別子を直ちに特定できるようになり、そのような取り消しのためのネットワークデータを作成できるようになることで、そのような取り消しを簡単に行うことができるようになる。
【００６５】
そして、このような機能を持つことで、本発明の業務進捗制御プログラムは、他のミドルウェアとの連携時に、探索の範囲を指定させることができるようになる。
【００６６】
本明細書では、サブシステムの連携を行う統合システムの実装において、市販のミドルウェアパッケージが広く利用されていることから、本発明の業務進捗制御プログラムを実現するソフトウェア部品の具体例としてミドルウェアを挙げている。
【００６７】
しかしながら、本発明は複合業務を提供するシステムに広く適用可能なものであり、実装形態は前記に限定されるものではない。例えば、単一のプロセス上で動作し、異なる業務内容のコンポーネントを組み込むことが可能で、それらの連携によって実現される複合業務を柔軟に定義可能な、複合業務システムフレームワークなどが考えられる。このように実施形態を広く考えた場合、前記ソフトウェア部品の具体的呼称としては、ミドルウェア、コンポーネント、モジュール、ライブラリ、等が含まれる。
【００６８】
また、既存のミドルウェア製品の具体例としては、複数のサブシステムに接続して業務処理依頼を送信するリクエストブローカ、あるいはサブシステムへの業務処理依頼の順序を制御するワークフローエンジン、あるいはワークフローエンジンから発行される処理依頼イベントならびにリクエストブローカを通して返却されるサブシステムの処理結果シグナルなどの様々なシステム内通信を仲介するメッセージバス、等が挙げられる。
【００６９】
【発明の実施の形態】
本発明の実施形態について、まず、ルール記述に基づくロールバック処理について説明する。その後、このロールバック処理の機能を、ステイタスマネージャと呼ぶ独立したミドルウェアに集約する際に必要となるミドルウェア間連携動作について説明する。
【００７０】
図１は、本発明の実施の形態について、全体構成を示した図である。
【００７１】
図中、１００００は、本発明を具備する業務進捗管理制御システムである。
【００７２】
００１は、ロールバック処理を実行するステイタスマネージャである。００２は、ステイタスマネージャ００１と他の処理部のシステム内通信を仲介するメッセージバスである。００３は、メッセージバス００２に接続し、単位業務処理の順序制御を行うワークフローエンジンである。
【００７３】
００４は、メッセージバス００２に接続し、単位業務処理を実行する単位業務処理システムである。００５は、ロールバック処理に必要なルール記述を保存したルール記述外部記憶装置である。００６は、ワークフローエンジン００３が単位業務処理の順序制御を行うために必要なワークフロー記述を保存したワークフロー記述外部記憶装置である。
【００７４】
ここで、単位業務処理システム００４が業務進捗管理制御システム１００００の外部構成要素となっているが、業務進捗管理制御システム１００００の内部に含まれる処理部として構成されている場合でも、本質的な相違は生じない。
【００７５】
また、業務進捗管理制御システム１００００の内部構成要素として、ステイタスマネージャ００１、メッセージバス００２、ワークフローエンジン００３の３つのミドルウェアを組み合せる形態を示しているが、これらの３つの構成要素をシステム内に直接埋め込まれた処理部として実装した場合でも、本質的な相違は生じない。
【００７６】
また、業務進捗管理制御システム１００００の内部構成要素として、メッセージバス００２とワークフローエンジン００３が存在するが、メッセージバス００２に相当する構成要素を使用せずに、直接内部構成要素同士が通信する形態をとった場合や、ワークフローエンジン００３に相当する構成要素を使用せずに、直接単位業務処理の順序をハードコーディングする形態をとった場合でも、本質的な相違は生じない。
【００７７】
引き続いて、図１のステイタスマネージャ００１の構成要素について説明する。
【００７８】
００７は、ルール記述外部記憶装置００５からルール記述をプログラム上に読み込むルール蓄積部である。００８は、複合業務インスタンスごとにメモリ領域を確保し、複合業務の進捗状態に関するデータを保持する進捗状態記憶部である。００９は、ルール蓄積部００７と進捗状態記憶部００８とを参照し、ルール記述によるロールバック処理を実行するルール解釈実行部である。
【００７９】
引き続いて、図１のワークフローエンジン００３の構成要素について説明する。
【００８０】
０１０は、ワークフロー記述外部記憶装置００６からワークフロー記述をプログラム上に読み込むワークフロー蓄積部である。０１１は、ワークフローインスタンスごとにメモリ領域を確保し、実行順序制御に必要なデータを保持するワークフロープロセスワーキングメモリである。０１２は、ワークフロー蓄積部０１０とワークフロープロセスワーキングメモリ０１１とを参照し、ワークフロー記述による実行順序制御を行うワークフロー解釈実行部である。
【００８１】
次に、図２に、ルール蓄積部００７に展開されたルール記述のデータ構造を示す。
【００８２】
０２０１は、１つの依頼ルール要素を表すデータ構造である。この依頼ルール要素０２０１は、０２０２に示す業務識別子（依頼業務の識別子で１つの単位業務識別子）と、０２０３に示す前提業務集合と、０２０４に示す取消操作集合とから構成される。
【００８３】
前提業務集合０２０３は、０２０５に示す１つ又は複数の前提業務識別子から構成される。取消操作集合０２０４は、０２０６に示す１つ又は複数の取消操作識別子から構成される。
【００８４】
一方、０２０７は、１つの取消ルール要素を表すデータ構造である。この取消ルール要素０２０７は、０２０８に示す業務識別子と、０２０９に示す包含業務集合０２０９とから構成される。包含業務集合０２０９は、０２１０に示す１つ又は複数の包含業務識別子から構成される。
【００８５】
ルール蓄積部００７では、複数の依頼ルール要素０２０１や取消ルール要素０２０７がルールの優先順位にもとづいて保持されている。
【００８６】
次に、図３に、進捗状態記憶部００８に展開された進捗状態のデータ構造と、ルール解釈実行部００９に展開された作業用のデータ構造を示す。
【００８７】
進捗状態記憶部００８の内部には、単位業務依頼同士の依存関係を表したネットワーク構造のデータとして進捗状態が表現されている。
【００８８】
０３０１は、１つの単位業務依頼に対応した依頼履歴ノードである。０３０６は、１つの単位業務依頼に対応した取消操作ノードである。
【００８９】
依頼履歴ノード０３０１は、取消操作ノード０３０６を参照する逆操作ポインタ配列０３０５にポインタを０個以上保持する。取消操作ノード０３０６は、依頼履歴ノード０３０１を参照する順操作ポインタ配列０３１０にポインタを１個以上保持する。
【００９０】
依頼履歴ノード０３０１は、０３０４に示す依存操作ポインタ配列を保持し、他の依頼履歴ノード０３０１を０個以上参照する。また、取消操作ノード０３０６は、０３０９に示す包含操作ポインタ配列を保持し、他の取消操作ノード０３０６を０個以上参照する。
【００９１】
ルール解釈実行部００９の作業用データには、０３１１に示す待機ノードリストと、０３１２に示す処理済ノードリストが存在する。
【００９２】
待機ノードリスト０３１１と処理済ノードリスト０３１２は、ともに、依頼履歴ノード０３０１へのポインタと取消操作ノード０３０６へのポインタが混在したリストである。
【００９３】
次に、図４に、ルール解釈実行部００９の動作を表したフローチャートを示す。
【００９４】
このフローチャートのステップＳ０４０２では、実際に単位業務依頼が実行されるか、ユーザから複合処理の中断要求が送信されるまで、イベント待ちの状態を維持し続ける。イベント待ちの状態を抜けた場合、ステップＳ０４０３で、単位業務依頼か中断要求かにより分岐を行う。
【００９５】
イベント待ちの状態を抜けた理由が中断要求の場合には、ステップＳ０４０７で、中断要求で指定されたロールバック地点に該当する依頼履歴ノード０３０１を待機ノードリスト０３１１に登録した後、ステップＳ０４０８で、一括ロールバック処理を実行し、その後再度ステップＳ０４０２に戻る。
【００９６】
一方、イベント待ちの状態を抜けた理由が単位業務依頼であった場合には、ステップＳ０４０４で、進捗状態記憶部００８の更新処理を実行した後、ステップＳ０４０５で、依頼された単位業務を実行する。
【００９７】
その実行結果が異常終了だった場合には、ステップＳ０４０９で、異常終了した依頼履歴ノード０３０１を待機ノードリスト０３１１に登録した後、ステップＳ０４０８で、一括ロールバック処理を実行する。一方、その実行結果が正常終了だった場合には、再びステップＳ０４０２に戻る。
【００９８】
次に、図５に、ルール解釈実行部００９による進捗状態記憶部００８の更新処理の動作を詳細に表したフローチャート（図４のフローチャートのＳ０４０４の詳細なフローチャート）を示す。
【００９９】
このフローでは、後に一括ロールバック処理を実行する際に必要となる、単位業務間の依存関係、単位業務と取消操作の対応関係、取消操作間の包含関係を、進捗状態記憶部００８中のネットワーク構造データを操作することで、記憶、更新している。動作の説明は、「実施例」の欄にて後述する。
【０１００】
次に、図６に、ルール解釈実行部００９による一括ロールバック処理の動作を詳細に表したフローチャート（図４のフローチャートのＳ０４０８の詳細なフローチャート）を示す。
【０１０１】
このフローでは、進捗状態記憶部００８中のネットワーク構造データを参照することで、ロールバックに必要かつ十分な取消操作のリストを計算し、それらを実行する。動作の説明は、「実施例」の欄にて後述する。
【０１０２】
引き続いて、前記ロールバック処理の機能を、ステイタスマネージャ００１と呼ぶ独立したミドルウェアに集約する際に必要となるミドルウェア間連携動作について説明する。
【０１０３】
図７に、本発明のミドルウェア間連携動作を実現するための構成とデータ構造を示す。
【０１０４】
ミドルウェアは、独立したプロセスで動作するとともに、メモリ空間も別々のものになっている。これから、ミドルウェア間連携動作を実現するための仕組みが必要となる。この仕組みとして、本発明では、業務をインスタンスレベルで識別するためのインスタンス識別子を使ってミドルウェア間連携動作を実現するという構成を採っている。
【０１０５】
０７０１は、ステイタスマネージャ００１の中に設けた識別子生成部である。識別子生成部０７０１には、インスタンス識別子の新規生成ならびに親インスタンス識別子の取得の外部オペレーションが用意される。ここで、このインスタンス識別子は、１つの単位業務に対して生成されることもあるし、複数の単位業務のグループに対して生成されることもある。
【０１０６】
０７０２は、ミドルウェア間の通信メッセージの中で他のデータと一緒に渡されるインスタンス識別子である。
【０１０７】
インスタンス識別子０７０２は、ミドルウェア間における通信メッセージ０７０３のデータの一部として受け渡しが可能で、コピー操作、同値判定、包含判定の３つの手段が提供された抽象データ型であればどのように実装しても良い。
【０１０８】
これには、オブジェクトとして実装する場合、あるいは文字列や整数の配列などプログラミング言語に依存しない可変長の基本型データとそれに対する関数として実装する場合、あるいは整数などの基本型と当該基本型を引数とする識別子生成部０７０１の外部オペレーションとして実装する場合などが含まれる。
【０１０９】
識別子生成部０７０１の中には、自身が生成したインスタンス識別子のオリジナルが保持される。識別子生成部０７０１の外部オペレーションによって、インスタンス識別子の新規生成依頼があった場合、前記オリジナルと重複しないようユニークなインスタンス識別子が作成され、返却される。
【０１１０】
また、インスタンス識別子の生成を依頼する際に、引数として他のインスタンス識別子を１つ指定できる。このような生成依頼があった場合、引数として渡されたインスタンス識別子を親として持つインスタンス識別子が作成され、そのコピーが返却される。
【０１１１】
これによって、インスタンス識別子は相互にツリー状の親子関係が定義される。識別子生成部０７０１の外部オペレーションによって、親インスタンス識別子の取得依頼があった場合、前記親子関係にもとづいて親となるインスタンス識別子が返却される。また、インスタンス識別子Ａの子孫がインスタンス識別子Ｂだった場合、「ＢはＡに含まれる」という意味の包含判定に対して、真が返される。
【０１１２】
さらに、０７０４は、ステイタスマネージャ００１の中に設けた単位業務実行部である。単位業務実行部０７０４には、０７０５に示す実行内容テーブルが保持される。
【０１１３】
実行内容テーブル０７０５は、単位業務識別子あるいは取消操作識別子と、実行コードとの組から構成されている。単位業務実行部０７０４には、単位業務識別子や取消操作識別子と必要な業務データとを渡すと、実行内容テーブル０７０５にもとづき、該当する実行コードを処理する外部オペレーションが処理を実行する。
【０１１４】
以上、図７に示した構成を利用することで、各ミドルウェアに分散する様々なデータの対応を実装に依存しない形態でとることができる。これによってミドルウェア間連携動作を行う。動作の説明は、「実施例」の欄にて後述する。
【０１１５】
【実施例】
本発明の実施例について、通信設備選定システムに適用した場合を具体例にして説明する。
【０１１６】
まず、実施例の通信設備選定業務について業務内容を説明する。
【０１１７】
通信設備選定業務は、３つの部分業務ドメインから構成されている。１つは通信事業者の所外通信ケーブル設備のデータベースにおいて、通信事業者の収容局ビルから消費者の住居近辺の接続点までの間に既に敷設されているケーブルを対象として、選定、工事予約、施工結果投入などの業務を行う業務ドメインである。ここでは、これを所外設備業務ドメインと呼ぶ。
【０１１８】
また、もう１つは、通信事業者の所内通信ケーブル設備のデータベースにおいて、所外ケーブルへの接続端子盤から交換機周辺までの間に既に敷設されている所内ケーブルを対象として、選定、工事予約、施工結果投入の業務を行う業務ドメインである。ここでは、これを所内設備業務ドメインと呼ぶ。
【０１１９】
また、もう１つは、交換機側スロットの位置、スロットに差し込む端末装置を対象として、選定、施工結果投入の業務を行う業務ドメインである。ここでは、これを端末設備業務ドメインと呼ぶ。
【０１２０】
各業務ドメインにおける１つ１つの業務を、ここでは非分割な操作という観点で、単位業務と呼ぶことにする。
【０１２１】
図８に、所外設備業務ドメインの単位業務間依存関係を図示し、図９に、所内設備業務ドメインの単位業務間依存関係を図示し、図１０に、端末設備業務ドメインの単位業務間依存関係を図示する。
【０１２２】
この図８ないし図１０において、矢印の元の業務が終了しているときのみ、矢印の先の業務を実行できることを意味している。そして、各業務ドメインの一連の単位業務系列がどこまで実行されたかを、進捗状態と呼ぶことにする。
【０１２３】
途中の段階における進捗状態では、操作対象となる設備データベース上の状態データが一時的に変更される。これは例えば、工事予約を行った設備は、他の業務遂行者によって設備を選定対象とされないようにするためである。
【０１２４】
したがって、途中の進捗状態で業務をとりやめる場合は、データベース上の状態データを最初の状態に戻す必要がある。これを取消操作と呼ぶことにする。各業務ドメインの単位業務間の依存性や取消操作は、その業務ドメインの中で扱いやすい様にモデル化されている場合が多く、一般に統一されていない。
【０１２５】
通信設備選定業務は、このような３つの部分業務ドメインの多様な単位業務の組み合わせで実現される。ここで、通信設備選定業務の結果として得られる設備データはトポロジー的に接続し、かつ提供可能サービスが注文内容に合致するように、全体的な整合性が要求される。
【０１２６】
このため、例えば設備の新設を行う場合は、各部分業務ドメインの作業は選定完了状態で一時停止し、全体的な整合性が満足される設備の組み合わせが確保できたときのみ、工事予約等の次の進捗状態に進むことになる。つまり、各単位業務は部分業務ドメインを跨る形での依存関係を持つということであり、ここでは、このような単位業務群全体を指して複合業務と呼ぶ。
【０１２７】
以下では、実施例として、設備新設の場合の複合業務を示す。
【０１２８】
図１１ないし図１６に、ルール蓄積部００７に蓄積される設備新設に関連する単位業務のルール記述（図２に示すデータ構造を持つ）を図示し、図１７に、設備新設を実行する場合のワークフロー記述を図示する。
【０１２９】
ここで、図１１に示すルール記述は、所外設備業務ドメインの依頼ルールのルール記述（図８に示す単位業務間依存関係から定義される）を示し、図１２に示すルール記述は、所外設備業務ドメインの取消ルールのルール記述（図８に示す単位業務間依存関係から定義される）を示している。
【０１３０】
また、図１３に示すルール記述は、所内設備業務ドメインの依頼ルールのルール記述（図９に示す単位業務間依存関係から定義される）を示し、図１４に示すルール記述は、所内設備業務ドメインの取消ルールのルール記述（図９に示す単位業務間依存関係から定義される）を示している。
【０１３１】
また、図１５に示すルール記述は、端末設備業務ドメインの依頼ルールのルール記述（図１０に示す単位業務間依存関係から定義される）を示し、図１６に示すルール記述は、端末設備業務ドメインの取消ルールのルール記述（図１０に示す単位業務間依存関係から定義される）を示している。
【０１３２】
図１１に示す依頼ルールＲ１１０２について具体的に説明するならば、この依頼ルールＲ１１０２は、図８の所外工事予約０８０２に対応付けられる「所外工事予約」を業務識別子とし、図８の所外設備選定０８０１に対応付けられる「所外設備選定」を前提業務集合とし、図８の所外予約取消０８０６に対応付けられる「所外予約取消」を取消操作集合とするルールである。
【０１３３】
また、図１２に示す取消ルールＲ１２０２について具体的に説明するならば、この取消ルールＲ１２０２は、図８の所外予約取消０８０６に対応付けられる「所外予約取消」を業務識別子（取消操作の業務識別子）とし、図８の所外選定取消０８０５に対応付けられる「所外選定取消」を包含業務集合（包含される取消操作の業務集合）とするルールである。
【０１３４】
ここで、包含業務集合とは、取消ルールＲ１２０２で説明するならば、所外予約取消０８０６を行うと、所外選定取消０８０５については取り消しを行ったことになる、という意味で包含業務集合と呼んでいる。
【０１３５】
次に、図１７に示すワークフローの実行がエラーや中断を発生せずに、全ての業務が正常に完了した場合について説明する。
【０１３６】
まず、ワークフローの開始Ｓ１７０１では、ルール解釈実行部００９も図４の開始Ｓ０４０１の状態にあり、直後にＳ０４０２が実行され、ルール解釈実行部００９は、中断要求もしくは単位業務依頼の入力を待つ状態となる。
【０１３７】
ワークフローの所外設備選定Ｓ１７０２が実行されると、ルール解釈実行部００９は、Ｓ０４０３の条件判断を行い、イベント待ちの状態を抜けた理由が単位業務依頼であることで、Ｓ０４０４に進む。このＳ０４０４で行う進捗状態記憶部更新処理の詳細については後述する。
【０１３８】
次に、Ｓ０４０５で、当該処理プログラムに実際に単位業務の依頼を行い、処理を実行する。Ｓ０４０６で、前記処理の実行結果を判断し、正常に終了した場合は、再びＳ０４０２で待機する。このように、ワークフロー記述のステップが進むに従い、ルール解釈実行部００９における前記動作サイクルを繰り返す。
【０１３９】
ここで、ワークフローのＳ１７０５における選定結果についての承認判定で、「承認しない」（Ｎｏ）になった場合を説明する。
【０１４０】
この状態における進捗状態記憶部００８のデータ構造は、図１８に示すものである。
【０１４１】
この場合、図４における処理は、Ｓ０４０２を抜け、Ｓ０４０３の条件判断で「中断要求」（Ｙｅｓ）に進み、Ｓ０４０７で、待機ノードリスト０３１１に当該依頼履歴ノードが登録される。引き続いて、Ｓ０４０８の一括ロールバック処理で業務進捗状態が元に戻され、再びＳ０４０２で待機する。
【０１４２】
また、ワークフローの所外工事予約Ｓ１７０７における業務エラーにより、ロールバック処理が実行された場合を説明する。
【０１４３】
この状態における進捗状態記憶部００８のデータ構造は、図１９に示すものである。
【０１４４】
この場合、図４における処理は、Ｓ０４０５から返ってきた後、Ｓ０４０６の条件判断で「異常終了」（Ｎｏ）に進み、Ｓ０４０９で、待機ノードリスト０３１１に当該依頼履歴ノードが登録される。引き続いて、Ｓ０４０８の一括ロールバック処理で業務進捗状態が元に戻され、再びＳ０４０２で待機する。
【０１４５】
図１８ないし図２１は、図１７のワークフロー記述にもとづき進捗状態記憶部００８を更新した場合のスナップショットである。
【０１４６】
ここで、図１８はワークフローのＳ１７０５におけるスナップショットであり、図１９はワークフローのＳ１７０７におけるスナップショットであり、図２０はワークフローのＳ１７１０におけるスナップショットであり、図２１はワークフローのＳ１７１７におけるスナップショットである。
【０１４７】
次に、図５に示す進捗状態記憶部００８の更新処理のフローチャートについて説明する。
【０１４８】
この図５に示す進捗状態記憶部更新処理は、図４のＳ０４０４を詳細に示したものである。このＳ０４０４を実行する際は、Ｓ０４０２で入力された業務識別子がワークフローから通知されるものとする。
【０１４９】
ここでは、図１７の所外工事予約Ｓ１７０７における進捗状態記憶部更新処理について説明する。このときのスナップショットは図１９に示すものである。
【０１５０】
まず、図５の最初のステップＳ０５０１で、ルール蓄積部００７の中の依頼ルール集合を検索し、ワークフローから通知された業務識別子と同じ業務識別子を持つ依頼ルールを取得する。
【０１５１】
この場合には、所外工事予約Ｓ１７０７の業務識別子がワークフローから通知されることになるので、「所外工事予約」を業務識別子に持つ依頼ルールＲ１１０２を取得することになる。
【０１５２】
このとき、もし該当する依頼ルールが存在しない場合は、Ｓ０５０２の判断分岐で、Ｓ０５０９のシステムエラー処理へと進む。一方、該当する依頼ルールが複数存在する場合は、ルール蓄積部００７における依頼ルールの優先順位に基づき、１つが決定される。
【０１５３】
Ｓ０５０３では、得られたルールの内容を参照し、業務識別子に対応する依頼履歴ノードを新規に作成する。依頼ルールＲ１１０２の場合には、ワークフローの所外工事予約Ｓ１７０７に対応付けられるノードＮ１８０４（図１９に示す）を新規に作成する。
【０１５４】
引き続いてＳ０５０４では、得られたルールの内容を参照し、ルールの指定する前提業務識別子に対応する依頼履歴ノードからのポインタを作成する。依頼ルールＲ１１０２の場合には、ワークフローの所外設備選定Ｓ１７０２が前提業務識別子になるので、その前提業務識別子に対応するノードＮ１８０１から新規に作成したノードＮ１８０４に向けてポインタを作成し、ノードＮ１８０１の依存操作ポインタ配列０３０４に格納する。
【０１５５】
引き続いてＳ０５０５では、得られたルールの内容を参照し、ルールの指定する取消操作識別子に対応する取消操作ノードを新規に作成し、双方向のポインタを作成する。依頼ルールＲ１１０２の場合には、ルールの指定する取消操作識別子に対応する所外予約取消のノードＮ１８１３を新規に作成する。ポインタは、まずノードＮ１８１３からノードＮ１８０４に向けて作成し、ノードＮ１８１３の順操作ポインタ配列０３１０に格納する。同様に、ノードＮ１８０４からノードＮ１８１３に向けて作成し、ノードＮ１８０４の逆操作ポインタ配列０３０５に格納する。
【０１５６】
引き続いてＳ０５０６では、ルール蓄積部００７の中の取消ルール集合を検索し、新規に作成したノードＮ１８１３の取消操作識別子と同じ取消操作識別子を業務識別子として持つ取消ルールを取得する。依頼ルールＲ１１０２の場合には、「所外予約取消」が取消操作識別子となっているので、図１２の取消ルール集合を検索することで、この「所外予約取消」を業務識別子として持つ取消ルールＲ１２０２を新たに取得する。
【０１５７】
このとき、もし該当する取消ルールが存在しない場合は、Ｓ０５０７の判断分岐で、Ｓ０５１０のシステムエラー処理へと進む。一方、該当する取消ルールが複数存在する場合は、ルール蓄積部００７における取消ルールの優先順位に基づき、１つが決定される。
【０１５８】
引き続いてＳ０５０８では、得られたルールの内容を参照し、ルールの指定する包含業務識別子に対応する取消操作ノードに向けて、ポインタを作成する。取消ルールＲ１２０２の場合には、「所外選定取消」が包含業務識別子となるので、ノードＮ１８１３から、その所外選定取消のノードＮ１８１０に向けてポインタを作成し、ノードＮ１８１３の包含操作ポインタ配列０３０９に格納する。
【０１５９】
以上のステップを実行することによって、進捗状態記憶部００８を更新する。なお、Ｓ０５０４、Ｓ０５０８では、複数の業務識別子があれば、それに対応する複数のノードへのポインタをはる。また、Ｓ０５０５では、既に該当する業務識別子の取消操作ノードが存在すれば、新規にノードを作成しないで、図２０に示すように当該ノードを使用する。
【０１６０】
次に、図６に示す一括ロールバック処理のフローチャートについて説明する。
【０１６１】
この図６に示す一括ロールバック処理は、図４のＳ０４０８を詳細に示したものである。このＳ０４０８を実行する際は、Ｓ０４０７の処理に従って、中断要求で指定された依頼履歴ノードが待機ノードリスト０３１１に登録されているか、あるいは、Ｓ０４０９の処理に従って、異常終了した依頼履歴ノードが待機ノードリスト０３１１に登録されている。
【０１６２】
この待機ノードリスト０３１１は、図３に示すように、ルール解釈実行部００９の作業用データで、処理済ノードリスト０３１２とともに使用する。
【０１６３】
ここでは、図１７のワークフローの所内工事予約Ｓ１７１０でシステム例外が生じ、ロールバック処理を実行する場合について説明する。このときのスナップショットは図２０に示すものである。待機ノードリスト０３１１には、ワークフローの所内工事予約Ｓ１７１０に対応付けられるノードＮ１８０６が登録される。
【０１６４】
まず、図６の最初のステップＳ０６０１で、待機ノードリスト０３１１中の依頼履歴ノードの依存操作ポインタ配列０３０４をたどることで、取消の必要がある依頼履歴ノードを全て検索して、それらを待機ノードリスト０３１１に追加する。Ｓ１７１０に対応付けられるノードＮ１８０６の依存操作ポインタ配列０３０４は何もポイントしていないので、この段階では追加処理は行わないことになる。
【０１６５】
Ｓ０６０２で、待機ノードリスト０３１１中の依頼履歴ノードの逆操作ポインタ配列０３０５をたどることで、取消操作ノードを検索して、それらを待機ノードリスト０３１１に追加する。Ｓ１７１０の場合、逆操作ポインタ０３０５をたどることでノードＮ１８１４を検索できるので、このノードＮ１８１４を待機ノードリスト０３１１に追加することになる。
【０１６６】
Ｓ０６０３で、待機ノードリスト０３１１中の取消操作ノードの包含操作ポインタ配列０３０９をたどることで、取消操作ノードを検索して、それらを待機ノードリスト０３１１に追加する。Ｓ１７１０の場合、包含操作ポインタ配列０３０９をたどることでノードＮ１８１２を検索できるので、このノードＮ１８１２を待機ノードリスト０３１１に追加することになる。
【０１６７】
Ｓ０６０４で、待機ノードリスト０３１１中の取消操作ノードの順操作ポインタ配列０３１０をたどることで、依頼履歴ノードを検索して、それらを待機ノードリスト０３１１に追加する。Ｓ１７１０の場合、順操作ポインタ配列０３１０をたどることでノードＮ１８０３を検索できるので、このノードＮ１８０３を待機ノードリスト０３１１に追加することになる。
【０１６８】
ここで、Ｓ０６０１〜Ｓ０６０４の追加処理を行うにあたって、既に待機ノードリスト０３１１中に存在するものについては重複の無いように処理する。
【０１６９】
Ｓ０６０５で、待機ノードリスト０３１１の要素数がＳ０６０１の時点と比べて増加したかどうかにより判断分岐を行う。ここでは、増加した（Ｙｅｓ）のでＳ０６０１に戻る。
【０１７０】
引き続いてＳ０６０１〜Ｓ０６０５を再度実行する。この過程では待機ノードリスト０３１１の要素数は増大しないので、Ｓ０６０５で、増加しない（Ｎｏ）方へ進む。
【０１７１】
Ｓ０６０６で、待機ノードリスト０３１１中の依頼履歴ノードを全て処理済ノードリスト０３１２に追加する。Ｓ１７１０の場合、ノードＮ１８０６とノードＮ１８０３が追加される。依頼履歴ノードは取消操作ではないので、処理済ノードリスト０３１２に追加するのである。
【０１７２】
Ｓ０６０７で、待機ノードリスト０３１１中の取消操作ノードの包含操作ポインタ配列０３０９をたどって、それにより検索された取消操作ノードを全て処理済ノードリスト０３１２に追加する。Ｓ１７１０の場合、ノードＮ１８１２が追加される。包含される取消操作ノードについては、包含する取消操作ノードについて取消処理を行えば、自動的に取り消しを行ったことになるので、取消処理を行うことなく処理済ノードリスト０３１２に追加するのである。
【０１７３】
Ｓ０６０８で、待機ノードリスト０３１１中の取消操作ノードの内、処理済ノードリスト０３１２中に存在しない全てのノード（取消操作ノードである）について、対応する取消処理を実行する。Ｓ１７１０の場合、ノードＮ１８１４について取消処理を実行する。実行済みの取消操作ノードは処理済ノードリスト０３１２に追加される。
【０１７４】
Ｓ０６０９で、前記取消処理のエラーを判定し、エラー発生（Ｙｅｓ）の場合はＳ０６１２のシステムエラー処理へ移行する。全て正常に終了した場合は（Ｎｏ）に進む。
【０１７５】
Ｓ０６１０で、処理済ノードリスト０３１２の全てのノードを進捗状態記憶部００８から削除する。
【０１７６】
Ｓ０６１１で、待機ノードリスト０３１１と処理済ノードリスト０３１２を空にする。
【０１７７】
以上のステップにより、必要最小限の取消処理が実行される。
【０１７８】
以上の方法によると、ワークフロー記述にロールバック処理を記述しなくても、業務種別ごとのルール記述と依頼履歴の依存関係にもとづいて自動的にロールバック処理が実行されるため、記述の大規模複雑化の傾向を抑えることができる。これは本発明で解決しようとする課題の１つである。
【０１７９】
上述した例では、ノードＮ１８１４について取消処理を実行しており、これにより、包含関係にあるノードＮ１８１２についても取消処理を実行したことになる。従って、図１７のワークフロー上のＳ１７１０とＳ１７０４について取り消しを行ったことになる。
【０１８０】
図１７のワークフロー記述上に、Ｓ１７０４とＳ１７１０のみを選んで再度実行するフローが定義されていれば、ロールバック後の再実行について特に問題は起こらない。
【０１８１】
一方、Ｓ１７０４とＳ１７１０のみを選んで再度実行するフローが定義されていない場合には、最初からワークフローを実行しなおすことが必要であり、ノードＮ１８１２だけではなく、ノードＮ１８１０やノードＮ１８１１やノードＮ１８１３の取消処理も実行しなければならない。
【０１８２】
このように、依頼処理の依存関係はないものの、別の理由で依頼処理群をグループ化し、それらを一体としてロールバックさせたい場合がある。
【０１８３】
このときは、ワークフローのＳ１７０１の直後で、ダミーノードとして依頼履歴ノードと取消操作ノードを作成するステップを追加する。そして、グループ化したいノードを作成するときに、そのダミーノードとの間のポインタを依存操作ポインタ配列０３０４や包含操作ポインタ配列０３０９に格納し、相互に関連付ける。
【０１８４】
図２２に、このダミーノードを追加したスナップショットの一例を図示する。このダミーノードの追加にあたり、ダミーノードの依頼処理識別子を、ルール集合のＲ１１０１、Ｒ１２０１、Ｒ１３０１、Ｒ１４０１、Ｒ１５０１、Ｒ１６０１の依存業務集合または包含業務集合に追加すればよく、特別な機能拡張は不要である。
【０１８５】
ここで、図２２に示すような形でダミーノードを追加すると、全てのノードを取り消すことができるようになるが、このダミーノードの追加の形態については、ワークフローの記述に合わせる形で追加することになる。
【０１８６】
以上の方法によると、ルール記述に業務の種類ごとの依存関係を、ワークフロー記述にグループ化させたい業務インスタンスの範囲を指定するというように、分離して記述できるので、柔軟なロールバック処理が可能となる。これは本発明で解決しようとする課題の１つである。
【０１８７】
次に、ミドルウェア間連携動作の実施例を説明する。
【０１８８】
ワークフローエンジン００３から単位業務の実行が依頼された場合、ステイタスマネージャ００１は、インスタンス識別子を新規生成し、そのコピーを進捗状態記憶部００８とワークフロープロセスワーキングメモリ０１１にそれぞれ記憶する。
【０１８９】
図１７のワークフロー記述の場合、Ｓ１７０２、Ｓ１７０３、Ｓ１７０４が順に実行されると、単位業務依頼のメッセージはステイタスマネージャ００１に送信され、それぞれインスタンス識別子が生成されて、ノードＮ１８０１、ノードＮ１８０２、ノードＮ１８０３のインスタンス識別子０３０８にコピーが格納されるとともに、当該業務が図７に示す単位業務実行部０７０４で実行される。
【０１９０】
当該業務の実行結果が得られたらば、そのデータとともにワークフローエンジン００３に当該インスタンス識別子のコピーを返却する。
【０１９１】
Ｓ１７０５のステップで中断が指示された場合は、ロールバックする地点をステイタスマネージャ００１に伝える必要がある。そこで、ワークフロー記述においてＳ１７０２での結果データとして受け取ったインスタンス識別子を引数として、Ｓ０４０２の状態にあるステイタスマネージャ００１に中断要求を入力する。すると、ステイタスマネージャ００１内の単位業務実行部０７０４により必要な取消操作が実行される。
【０１９２】
以上の方法によると、進捗状態記憶部００８に記憶されたネットワークデータ上の依存関係や包含関係を、ルール解釈実行部００９が参照することにより、単位業務実行部０７０４で実行される単位業務や取消操作の処理粒度の違いは自動的に吸収される。
【０１９３】
また、ネットワークデータへの記憶・更新操作に必要な動作記述は、ルール蓄積部００７にルール形式で取り込まれ実行されるので、複雑なプログラムコードを必要としない。すなわち、従来の分散トランザクションサービスのアダプタでは困難であったことが、実現されている。これは本発明で解決しようとする課題の１つである。
【０１９４】
一方、ステイタスマネージャ００１の側では、インスタンス識別子の包含判定を行うことで、ノードの探索範囲を管理できる。すなわち、インスタンス識別子の親子関係に応じて、あるノードの下に他の複数のノードをグループ化することにより、探索対象をツリー状に構造化できる。
【０１９５】
複数の親を持つインスタンス識別子について探索する場合は、まず当該インスタンス識別子の先祖にあたるインスタンス識別子の系列を、図７に示した識別子生成部０７０１の「親識別子の取得依頼」を必要回数使用することで取得する。得られた識別子系列の任意の部分系列をキーとして、任意のレベルのノードグループを取得できる。
【０１９６】
これは、図２に示す依頼ルール要素０２０１に適合するノードを探索する場合に、基点となるノードに近いレベルのノードグループから、段階的に範囲を広げながら探索することを可能にする。
【０１９７】
探索範囲が構造化されておらず、常に全て探索対象となってしまうと、条件に合致するノードが複数存在する場合が容易に発生する。例えば、ワークフロー記述の側に、同じ業務識別子のステップが複数組み込まれている場合が考えられる。
【０１９８】
この場合は、同じ業務識別子のノードが同じ探索範囲に属さないようにグループをつくり、そのグループに対応するインスタンス識別子をあらかじめ生成しておいて、問題のステップでインスタンス識別子を生成する際、当該識別子を親として、識別子生成部０７０１のオペレーションを呼び出すことで解決できる。
【０１９９】
また例えば、ワークフローエンジン００３が並列処理で実行されている場合などに対応するためには、各ワークフロー記述のプロセスに対応してインスタンス識別子を生成しておき、それを親として指定して識別子生成部０７０１の生成オペレーションを呼び出すことで解決できる。
【０２００】
以上の方法によると、ワークフロー記述形式の変更やワークフローエンジン００３の改造を行うことなく、ステイタスマネージャ００１との連携動作が可能となる。これは本発明で解決しようとする課題の１つである。
【０２０１】
このようにして、本発明のステイタスマネージャ００９は、ミドルウェア間連携動作を実現するために、親に相当する単位業務グループ（１つ又は複数の単位業務で構成される）に対して、子に相当する単位業務グループ（１つ又は複数の単位業務で構成される）があれば、前者のインスタンス識別子を親として持つインスタンス識別子を後者に割り当てることで、ワークフローエンジン００３が親子関係を有するインスタンス識別子を使って処理依頼を行えるように処理するのである。
【０２０２】
そして、本発明のステイタスマネージャ００９は、その親子関係を持つインスタンス識別子の生成機能に合わせて、インスタンス識別子を指定して、親子関係にあるインスタンス識別子の検索要求を発行し、その検索結果を受け取る処理を行ったり、２つのインスタンス識別子を指定して、包含関係にあるのか否かの判定要求を発行し、その判定結果を受け取る処理を行うのである。
【０２０３】
例えば、ワークフローが分岐しているような場合にあって、分岐後の単位業務グループ（子に相当する）内で処理を取り消す必要が起こると、分岐前の単位業務グループ（親に相当）内で処理を取り消す必要が起こる場合がある。
【０２０４】
そのような場合に、図２３や図２４から分かるように、本発明のステイタスマネージャ００９は、このような親子関係を有するインスタンス識別子の機能を持つことで、分岐後の単位業務グループのインスタンス識別子から、分岐前の単位業務グループのインスタンス識別子を直ちに特定できるようになり、そのような取り消しのためのネットワークデータを作成できるようになることで、そのような取り消しを簡単に行うことができるようになる。
【０２０５】
ここで、図２３は、単位業務グループに対して親子関係を有する１つのインスタンス識別子を生成するという構成を採る場合の一例であり、図２４は、１つの単位業務に対して親子関係を有する１つのインスタンス識別子を生成するという構成を採る場合の一例である。
【０２０６】
以上説明したように、本発明では、単位業務や取消操作など、現在の業務状態に関連する処理間の依存性、対応関係、包含関係を進捗状態記憶部００８にネットワークデータとして保持し、そのネットワークデータの作成・更新を行うための動作記述をルール蓄積部００７にルールとして取り込み、ルール解釈実行部００９がこの２つの処理部とその他の処理部との仲介を行ってロールバック処理の管理制御を行うのである。
【０２０７】
そして、このロールバック機能をソフトウェア部品化し業務内容に依存しない構成とするために、ソフトウェア部品間で業務依頼イベント、業務処理結果シグナル、業務処理中断要求のタイミングで連携動作を行い、その際の交換データに、識別子生成部０７０１でユニークに生成された親子関係が定義される識別子を含むことで、複数の処理スコープを扱えるようにするのである。
【０２０８】
【発明の効果】
以上説明したように、本発明によると、既存のサブシステム間での処理粒度の違いが吸収できるため、統合システム上で一貫性を維持したロールバックが可能となる。また、ルール形式の動作記述によって処理間の依存関係・包含関係を記憶管理するため、従来のような複雑なプログラムコードを必要とせず、ロールバック処理の開発・改造が容易になる。
【０２０９】
また、ルール記述に業務種類ごとの依存関係を指定し、ワークフロー記述に業務インスタンスごとのグループ化対象を指定するというように、異なるカテゴリの情報を分離して記述できるので、柔軟なロールバック処理が可能となる。これによって、分散トランザクションでは不可能であった、複合業務における途中の進捗状態までロールバックする等の柔軟な管理制御を行うことが可能になる。
【０２１０】
また、ワークフロー記述にロールバック処理を記述しなくても、業務種別ごとのルール記述と依頼履歴の依存関係にもとづいて自動的にロールバック処理が実行されるため、記述の大規模複雑化の傾向を抑えることができる。これによって開発、デバッグ、改造の稼動が小さくなり、時間的、経済的コストを縮小できるなどの効果がある。
【０２１１】
また、設計やテストの際に検討項目の整理が容易で見落としが生じにくくなるため、プログラムの品質が向上するなどの効果がある。また、ワークフロー記述形式の変更やワークフローエンジンの改造を行うことなく、ステイタスマネージャとの連携動作が可能となる。これによってワークフロー記述の形式を変更する必要がなくなるため、ワークフロー記述の標準形式との互換性が維持でき、当該ワークフローエンジン以外への記述の移植が容易になるなどの効果がある。
【図面の簡単な説明】
【図１】本発明の一実施形態例である。
【図２】ルール蓄積部の一実施形態例である。
【図３】進捗状態記憶部の一実施形態例である。
【図４】ルール解釈実行部の実行するフローチャートの一実施形態例である。
【図５】ルール解釈実行部の実行するフローチャートの一実施形態例である。
【図６】ルール解釈実行部の実行するフローチャートの一実施形態例である。
【図７】本発明のミドルウェア間連携動作を実現するための一実施形態例である。
【図８】所外設備業務ドメインの単位業務間依存関係の説明図である。
【図９】所内設備業務ドメインの単位業務間依存関係の説明図である。
【図１０】端末装置業務ドメインの単位業務間依存関係の説明図である。
【図１１】所外設備業務ドメインのルール記述の説明図である。
【図１２】所外設備業務ドメインのルール記述の説明図である。
【図１３】所内設備業務ドメインのルール記述の説明図である。
【図１４】所内設備業務ドメインのルール記述の説明図である。
【図１５】端末装置業務ドメインのルール記述の説明図である。
【図１６】端末装置業務ドメインのルール記述の説明図である。
【図１７】設備新設業務ワークフロー記述の説明図である。
【図１８】進捗状態記憶部のスナップショットの説明図である。
【図１９】進捗状態記憶部のスナップショットの説明図である。
【図２０】進捗状態記憶部のスナップショットの説明図である。
【図２１】進捗状態記憶部のスナップショットの説明図である。
【図２２】進捗状態記憶部のスナップショットの説明図である。
【図２３】インスタンス識別子を使った処理の一例である。
【図２４】インスタンス識別子を使った処理の一例である。
【符号の説明】
１００００ 業務進捗管理制御システム
００１ ステイタスマネージャ
００２ メッセージバス
００３ ワークフローエンジン
００４ 単位業務処理システム
００５ ルール記述外部記憶装置
００６ ワークフロー記述外部記憶装置
００７ ルール蓄積部
００８ 進捗状態記憶部
００９ ルール解釈実行部
０１０ ワークフロー蓄積部
０１１ ワークフロープロセスワーキングメモリ
０１２ ワークフロー解釈実行部

Claims (13)

1. 複数の単位業務の組み合わせによって構成される複合業務の進捗を制御する業務進捗制御装置であって、
   単位業務の識別子をキーにして、その単位業務に先行して完了すべき他の単位業務の情報、その単位業務に対応する取消操作の情報およびその取消操作が包含する他の取消操作の情報をルールの形で保存する手段と、
   単位業務及びその取消操作の間の関係を示すネットワークデータを保存する手段と、
   単位業務の処理を進めるときに、上記ルールに従って、上記ネットワークデータを更新する手段と、
   単位業務の進捗状態を元に戻す必要があるときに、上記ネットワークデータに従って、それに必要となる取消操作を検索する手段と、
   上記検索した取消操作の実行を指示する手段とを備えることを、
   特徴とする業務進捗制御装置。
2. 請求項１記載の業務進捗制御装置において、
   依存関係にない単位業務をグループ化するために定義される業務処理を行わないダミーの単位業務と、そのダミーの単位業務に対応付けられるダミーの取消操作とが用意される場合には、上記ルールとして、そのダミーについて記述するものが用意されることを、
   特徴とする業務進捗制御装置。
3. 複数の単位業務の組み合わせによって構成される複合業務の進捗を制御する業務進捗制御方法であって、
   単位業務の識別子をキーにして、その単位業務に先行して完了すべき他の単位業務の情報、その単位業務に対応する取消操作の情報およびその取消操作が包含する他の取消操作の情報をルールの形で保存する手段から、該ルールを読み出す過程と、
   単位業務の処理を進めるときに、上記ルールに従って、単位業務及びその取消操作の間の関係を示すネットワークデータを更新する過程と、
   単位業務の進捗状態を元に戻す必要があるときに、上記ネットワークデータに従って、それに必要となる取消操作を検索する過程と、
   上記検索した取消操作の実行を指示する過程とを備えることを、
   特徴とする業務進捗制御方法。
4. 請求項３記載の業務進捗制御方法において、
   依存関係にない単位業務をグループ化するために定義される業務処理を行わないダミーの単位業務と、そのダミーの単位業務に対応付けられるダミーの取消操作とが用意される場合には、上記ルールとして、そのダミーについて記述するものが用意されることを、
   特徴とする業務進捗制御方法。
5. 複数の単位業務の組み合わせによって構成される複合業務の進捗を制御する処理を行う業務進捗制御プログラムであって、
   単位業務の識別子をキーにして、その単位業務に先行して完了すべき他の単位業務の情報、その単位業務に対応する取消操作の情報およびその取消操作が包含する他の取消操作の情報をルールの形で保存する手段から、該ルールを読み出す処理と、
   単位業務の処理を進めるときに、上記ルールに従って、単位業務及びその取消操作の間の関係を示すネットワークデータを更新する処理と、
   単位業務の進捗状態を元に戻す必要があるときに、上記ネットワークデータに従って、それに必要となる取消操作を検索する処理と、
   上記検索した取消操作の実行を指示する処理とをコンピュータに実行させるための業務進捗制御プログラム。
6. 複数の単位業務の組み合わせによって構成される複合業務の進捗を制御する処理を行う業務進捗制御プログラムであって、
   単位業務の識別子をキーにして、その単位業務に先行して完了すべき他の単位業務の情報、その単位業務に対応する取消操作の情報およびその取消操作が包含する他の取消操作の情報をルールの形で保存する手段から、該ルールを読み出す処理と、
   単位業務の進行を制御する外部プログラムから単位業務の処理依頼を受け取るときに、上記ルールに従って、単位業務及びその取消操作の間の関係を示すネットワークデータを更新するとともに、その処理依頼を受けた単位業務の実行を指示する処理と、
   上記外部プログラムから単位業務の進捗状態を元に戻す処理依頼を受け取るときに、上記ネットワークデータに従って、それに必要となる取消操作を検索する処理と、
   上記検索した取消操作の実行を指示する処理とをコンピュータに実行させるための業務進捗制御プログラム。
7. 請求項６記載の業務進捗制御プログラムにおいて、
   単位業務の実行に失敗するときに、上記ネットワークデータに従って、単位業務の進捗状態を元に戻すのに必要となる取消操作を検索する処理をコンピュータに実行させるための業務進捗制御プログラム。
8. 請求項６又は７記載の業務進捗制御プログラムにおいて、
   上記外部プログラムから処理依頼を受けた１つ又は複数の単位業務に対して、その実行毎に割り振られるユニークな識別子であるインスタンスな識別子を生成し、上記ネットワークデータの該当する単位業務にそれを記録するとともに、上記外部プログラムに対してそれを通知する処理をコンピュータに実行させるための業務進捗制御プログラム。
9. 請求項８記載の業務進捗制御プログラムにおいて、
   さらに、親となるインスタンス識別子が指定される１つ又は複数の単位業務に対して、そのインスタンス識別子を親として持つインスタンス識別子を生成する処理をコンピュータに実行させるための業務進捗制御プログラム。
10. 請求項９記載の業務進捗制御プログラムにおいて、
    インスタンス識別子を指定して、親子関係にあるインスタンス識別子の検索要求を発行し、その検索結果を受け取る処理をコンピュータに実行させるための業務進捗制御プログラム。
11. 請求項９記載の業務進捗制御プログラムにおいて、
    ２つのインスタンス識別子を指定して、包含関係にあるのか否かの判定要求を発行し、その判定結果を受け取る処理をコンピュータに実行させるための業務進捗制御プログラム。
12. 請求項５ないし１１のいずれか１項に記載の業務進捗制御プログラムにおいて、
    依存関係にない単位業務をグループ化するために定義される業務処理を行わないダミーの単位業務と、そのダミーの単位業務に対応付けられるダミーの取消操作とが用意される場合には、上記ルールとして、そのダミーについて記述するものが用意されることを、
    特徴とする業務進捗制御プログラム。
13. 請求項５ないし１２のいずれか１項に記載の業務進捗制御プログラムを記録した記録媒体。

Images