高度なワークフロー・パターンを WebSphere Integration Developer と WebSphere Process Server で実装する: 第 1 回 基本的な制御フロー・パターンと、キャンセルおよび強制終了パターン

Workflow Patterns Initiative は、企業がワークフローをモデル化するときに広く使用、あるいは参照されていますが、その最新の 43 のワークフロー・パターンは、あらゆる種類の BPEL エンジンに大きな課題を投げかけています。

WebSphere Process Server (WPS) は、パフォーマンスに優れた強力なビジネス・プロセス自動化エンジンです。WPS と WebSphere Integrated Developer (WID) を使うことで、ユーザーはそのワークフロー・パターンを簡単に実装することができます。他の BPEL エンジン製品に比べ、最新の WebSphere Integrated Developer V7.0 と WebSphere Process Server V7.0 は Workflow Patterns Initiative の43 のパターンをすべて実装できるというだけでなく、簡単に実装できるようにします。

Jing Wen Cui, Software Engineer, IBM

Jing Wen Cui は、3 年以上、WebSphere Process Server のテストに取り組んでいます。彼はワークフロー、BPEL、および関連する WebSphere 製品についても熟知しています。



Ying Ji Sun, Staff Software Engineer, IBM

Ying Ji Sun は現在、WebSphere Process Server SWAT チームに参加しています。以前は WebSphere Enterprise Service Bus 機能検証テストに取り組んでいた彼は、Web サービスおよび WebSphere Enterprise Service Bus を話題に取り上げた developerWorks 記事もいくつか書いています。



Yu Jie Gu, Staff Software Engineer, IBM

Yu Jie Gu は現在、WebSphere Process Server Level 3 サポート・チームのメンバーです。



2010年 10月 18日

はじめに

Workflow Patterns Initiative (WPI) は、ビジネス・プロセスをモデル化する際に繰り返し持ちあがってくる基本的な要件を図で表現し、そうした図の要素を順次つないでいくことで要件全体を記述することを目的に策定されました。WPI は、企業がワークフローをモデル化するときに広く使用、または参照されています。2003年に WPI の最初のバージョンとして発表されたパターンは 20 でしたが、最新リリースではその数が 43 にまで増えています。これらのパターンは、あらゆる種類の BPEL エンジンに大きな課題を投げかけています。このそれぞれのパターンをサポートするのは極めて困難だからです。これを言い換えれば、このすべてのパターンをサポートできる 1 つの BPEL エンジンがあれば、強化されたその能力の分だけ、多くのユーザーを獲得できるということになります。

WebSphere Process Server (WPS) は、あらゆる類のプロセスをサポートする完璧なランタイム・サポートを提供してくれる、パフォーマンスに優れた強力なビジネス・プロセス自動化エンジンです。そしてこの WPS で実行するアプリケーションの開発ツールとしてワークフローを視覚的にモデル化できるのが、WebSphere Integrated Developer (WID) です。WID でビジネス・プロセスを作成するのに必要な操作はドラッグ・アンド・ドロップだけで、コードを作成する必要は一切ありません。実行可能な BPEL コードは自動的に生成されます。最新の WID V7.0 と WPS V7.0 では、他の BPEL エンジン製品に比べ、より簡単にユーザーが 43 のパターンを実装できるようになっています。

この連載の第 1 回では、2 つのカテゴリーのパターン (基本制御フロー・パターンとキャンセルおよび強制終了パターン) について詳しく説明します。


基本制御フロー・パターン

このカテゴリーには、以下の 5 つの基本パターンがあります。

  1. 順次 (Sequence)
  2. 並列分割 (Parallel Split)
  3. 同期合成 (Synchronization)
  4. 排他条件分岐 (Exclusive Choice)
  5. 単純合成 (Simple Merge)

以上はすべて、基本的なワークフロー・パターンです。これらのパターンは、ユーザーの実際のビジネス・シナリオで広く使用されており、基本的で単純なワークフローはこの 5 つのパターンを使って実装することができます。


「順次」パターン

「順次 (Sequence)」パターンでは、タスクが順番に実行されます。これは最も基本的なワークフロー・パターンであり、すべてのビジネス・プロセスにはこのような構成要素があります。

例えば、銀行が発行するクレジット・カードの申し込みプロセスでは、「申し込み者が発行を申請」した後に、「信用調査」が行われます。このように「何かが行われてから何かを行う」というシナリオが、この「順次 (Sequence)」ワークフロー・パターンに当てはまる典型的な例です。

別の例としては、列車の乗車券を購入するためのオンライン・システムも挙げられます。「乗車券を選び、オンラインで支払いをし、乗車券を印刷する」というタスクは、順番に実行されなければなりません。この「何かの次に何かを行い、さらにその次に何かを行う」というシナリオも、「順次 (Sequence)」ワークフロー・パターンに当てはまります。

このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

このパターンの焦点は以下のとおりです。

  1. タスクの順序は、プロセスの設計段階で定義されます。つまり、プロセスのモデル化フェーズでは、どのタスクを最初に行い、どのタスクを次に行うといった順序が既に定義されている状態になっています。
  2. あるタスクが完了すると、次のタスクが実行可能になります。条件は不要です。

WID では、デフォルトでタスクは順番に実行されます。

実装

図 1. 「順次 (Sequence)」ワークフローの実装
「順次 (Sequence)」ワークフローの実装

「Case2 (ケース 2)」は、「Case1 (ケース 1)」の直後に実行されます。

WPS での実行

リスト 1. 「順次 (Sequence)」ワークフローのログ
[8/23/10 14:52:16:453 GMT+08:00] 0000004e SystemOut     O [Sequence] Run into Case1
[8/23/10 14:52:16:453 GMT+08:00] 0000004e SystemOut     O [Sequence] Run into Case2

「並列分割」パターン

「並列分割 (Parallel Split)」パターンでは、タスクが並行して実行されます。ほとんどすべてのプロセスでは、システムの効率性を上げるために複数のタスクを同時に行わなければならない場合があるため、このパターンは広く使用されています。

例えば、前述の銀行クレジット・カードの申し込みプロセスでは、「申込者が発行を申請」した後に、「信用調査」が行われますが、この調査の中では異なるプロセス所有者によって「身元の確認」、「既存の口座の確認」が並行して行われます。これは、「並列分割 (Parallel Split)」ワークフロー・パターンが必要となる典型的な例です。

分析

このパターンの焦点は以下のとおりです。

  1. プロセスは特定の時点で、複数のブランチに分割されます。
  2. 分割されたそれぞれのブランチは、同時に実行されます。その後、ブランチが再び同期合成されることもあれば、そうでない場合もあります。
  3. すべてのブランチは、プロセスのモデル化フェーズで定義されます。

WID では、このパターンに対応する「並列スコープ (Parallel Scope)」を簡単に使用することができます。

実装

図 2. 「並列分割 (Parallel Split)」ワークフローの実装
「並列分割 (Parallel Split)」ワークフローの実装

「Case1 (ケース 1)」、「Case2 (ケース 2)」、「Case3 (ケース 3)」は、並行して実行されます。

WPS での実行

リスト 2. 並列分割ワークフローのログ
[8/23/10 14:53:55:140 GMT+08:00] 0000004e SystemOut     O [Parallel_Split] Run into Case2
[8/23/10 14:53:55:171 GMT+08:00] 0000004e SystemOut     O [Parallel_Split] Run into Case1
[8/23/10 14:53:55:187 GMT+08:00] 0000004e SystemOut     O [Parallel_Split] Run into Case3

注: 上記のログには、3 つのブランチが同じ 1 つのスレッドで順番に実行されていることが示されています。これは、データベースの制約によるものです。詳しい理由については、http://www-01.ibm.com/support/docview.wss?uid=swg21293793 に掲載されている Technote の説明を読んでください。


「同期合成」パターン

「同期合成 (Synchronization)」パターンでは、複数のブランチが 1 つのノードで同期合成されます。このパターンは、必ず「並列分割 (Parallel Split)」パターンと併せて使用され、分割したタスクの結果の同期合成を行います。

「同期合成 (Synchronization)」パターンは、前にプロセスのモデル化フェーズで「並列分割 (Parallel Split)」要素を使って作成した並列ブランチを 1 つに合成する手段となります。すべてのブランチの作業が完了すると、シンクロナイザーの直後に続くタスクにスレッド制御が渡されます。

例えば、前述の銀行クレジット・カードの申し込みプロセスでは、「申込者が発行を申請」した後に、「身元の確認」、「既存の口座の確認」などの信用調査が並行して完了すると、その直後に「信用結果」タスクが実行されます。この場合は「信用結果」タスクが、「同期合成 (Synchronization)」ブロックに相当します。

このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

このパターンの焦点は以下のとおりです。

  1. 複数のブランチが合成されて 1 つの後続ブランチになります。
  2. すべてのブランチの処理が完了した時点で、プロセスは即座に後続するブランチに進みます。

WID では、「並列スコープ (Parallel Scope)」を使用して複数のブランチを同時に開始し、リンクを使用してこれらのブランチを後続する 1 つのブランチへと合成します。

実装

図 3. 「同期合成 (Synchronization)」パターンの実装
「同期合成 (Synchronization)」パターンの実装

「Case1 (ケース 1)」と「Case2 (ケース 2)」は並行して開始されます。この 2 つが両方とも完了した時点でプロセスが 1 つに同期化され、それから「Case3 (ケース 3)」が実行されます。

WPS での実行

リスト 3. 「同期合成 (Synchronization)」パターンのログ
[8/23/10 14:55:27:484 GMT+08:00] 0000004e SystemOut     O [Synchronization_Basic] 
                                                            Run into Case1
[8/23/10 14:55:27:484 GMT+08:00] 0000004e SystemOut     O [Synchronization_Basic]   
                                                            Run into Case2
[8/23/10 14:55:27:500 GMT+08:00] 0000004e SystemOut     O [Synchronization_Basic] 
                                                            Run into Case3

「排他条件分岐」パターン

この「排他条件分岐 (Exclusive Choice)」パターンでは、複数のブランチのうち、1 つのブランチだけが有効にされます。どのブランチを取るかは、前のタスクの結果や、プロセスにおける特定のデータ要素の値、さらには式の評価結果やその他の形でのプログラムによる選択メカニズムの結果、などによって決まります。

どの企業においてもビジネス決定は必要であることから、このパターンも同じくよく使用されています。実行時の可能な限り遅い時点でブランチを選択できるように、ルーティングの決定は動的に行われます。

例えば、銀行クレジット・カードの申し込みプロセスでは、次にどのブランチにルーティングするかは「信用結果」タスクの結果によって決まります。結果が合格であれば、プロセスは「カード作成」タスクに進み、不合格であれば「要求失敗」タスクに進みます。結果が保留となった場合には、プロセスは「2 次審査」タスクに進みます。これは、「排他条件分岐 (Exclusive Choice)」パターンが必要となる典型的な例です。

このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

このパターンの焦点は以下のとおりです。

  1. 1 つのブランチが複数の後続ブランチに分岐します。
  2. 定義された条件に従って、1 つの後続ブランチだけが有効になります。
  3. ルーティングは特定のデータ要素などに基づき、動的に行われます。

WID では、このパターンに以下の 2 つのソリューションを使用することができます。

  • ソリューション 1: 「Choice (選択肢)」要素
  • ソリューション 2: フォーク・ゲートウェイを使用した汎用フロー

実装

図 4. 「排他条件分岐 (Exclusive Choice)」パターンの実装
「排他条件分岐 (Exclusive Choice)」パターンの実装

「Choice (選択肢)」要素を使用するソリューション 1 では、ケースごとに詳細な条件を定義します。フォーク・ゲートウェイを使用した汎用フローを使用するソリューション 2 では、詳細な条件は、各ケースに張られたリンクに定義されます。

WPS での実行

いずれのソリューションでも、プロセスは「Case1 (ケース 1)」に進みます。

リスト 4. 「排他条件分岐 (Exclusive Choice)」パターンのログ
[8/23/10 14:58:38:296 GMT+08:00] 0000004e SystemOut     O [ExclusiveChoice] Run into Case1
[8/23/10 14:58:38:328 GMT+08:00] 0000004e SystemOut     O [ExclusiveChoice] Run into Case1

「単純合成」パターン

「単純合成 (Simple Merge)」パターンでは、合成されるブランチのいずれか 1 つの処理が完了した時点で、合成されたノードが有効にされます。このパターンが使用されるのは、複数の個別のブランチを同期化することなく合成する必要があるビジネス・シナリオです。したがって、複数のブランチに共通するタスク・シーケンスを明示的に複製する必要がなくなるため、プロセス・モデルを単純化することができます。さらには、単純な合成要素によって複数のブランチを結合できるので、一連の共通タスクを何度も繰り返しプロセス・モデルに表現する必要がありません。

例えば、銀行クレジット・カードの申し込みプロセスでは、「信用結果」タスクの結果に応じてどのブランチ (「カード作成」、「要求失敗」、または「2 次審査」) が実行されるとしても、次に行わなければならないタスクが「ユーザーへの通知」タスクであることは共通しています。そこで必要となるのが、「単純合成 (Simple Merge)」パターンです。

このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

このパターンの焦点は以下のとおりです。

  1. 複数のブランチが合成されて 1 つの後続ブランチになります。
  2. いずれかのブランチの処理が完了した時点で、後続ブランチが可能になります。

注: このパターンは、複数のブランチを 1 つのノードで合成しなければならないという点では、「同期合成 (Synchronization)」パターンと似ていますが、ブランチの合成ノードが有効になる状況は異なります。「同期合成 (Synchronization)」パターンでは、すべてのブランチの処理が完了した時点で合成ノードが有効になります。一方、「単純合成 (Simple Merge)」パターンの場合、合成ノードが有効になるのは、いずれか 1 つのブランチの処理が完了した時点です。

WIDでは、「Choice (選択肢)」要素を使用してこのパターンを実装します。

実装

図 5. 「単純合成 (Simple Merge)」パターンの実装
「単純合成 (Simple Merge)」パターンの実装

「Case1 (ケース 1)」、「Case2 (ケース 2)」、および「Otherwise (その他)」のケースはすべて有効になりますが、定義された条件に従って、1 つのブランチだけが選択されます。「Choice (選択肢)」要素のスコープが完了すると、プロセスは「SimpleMerge (単純合成)」アクティビティーに進みます。

WPS での実行

リスト 5. 「単純合成 (Simple Merge)」パターンのログ
[8/23/10 14:59:53:093 GMT+08:00] 0000004e SystemOut     O [Simple Merge] Run into Case1
[8/23/10 14:59:53:109 GMT+08:00] 0000004e SystemOut     O [Simple Merge] 
                                                           Run into Simple Merge

キャンセルおよび強制終了パターン

このカテゴリーには、以下の 5 つのパターンがあります。

  1. タスクのキャンセル (Cancel Task)
  2. ケースのキャンセル (Cancel Case)
  3. リージョンのキャンセル (Cancel Region)
  4. 複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)
  5. 複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)

以上は、タスク、プロセス、一連のタスク、およびタスクの複数インスタンスをどのように終了するかを定義するためのパターンです。


「タスクのキャンセル」パターン

「タスクのキャンセル (Cancel Task)」パターンでは、有効にされているタスク、あるいは既に実行中の 1 つのタスクがキャンセル可能になります。さらに可能な場合には、現在実行中のインスタンスが中断されて、除去されます。このパターンは、まだ完了してない実行中の 1 つのタスクをユーザーがキャンセルする必要がある場合に最もよく使われるパターンです。このパターンは、不要になったタスクをキャンセルし、それによってプロセスを強制終了させる手段となります。

例えば、銀行クレジット・カードの申し込みプロセスでは、顧客の気が変わって申し込みの取り消しを希望する場合に備え、顧客が要求したタスクで未完了のものを顧客自身がキャンセルできるようになっていなければなりません。

別の例として、自動車の車両保険の損害見積もりタスクが、2 人の保険査定人によって行われるとします。一方の査定人がタスクを完了した場合には、もう一方の査定人のタスクはキャンセルする必要があります。

このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

このパターンの焦点は以下のとおりです。

  1. 有効にされたタスクは、実行される前に取り消されます。
  2. タスクが既に開始されている場合、タスクは無効にされます。
  3. 現在実行中のインスタンスは中断されて除去されます。

タスクが同時に行われているか、順番に行われているかによって、以下の 2 つのケースがあります。

上記の銀行の例のように、タスクが順番に行われるというケース。この場合、WID では「Event Handler (イベント・ハンドラー)」と「Terminate (強制終了)」を使用してパターンを実装することができます。これをソリューション 1 と呼びます。

上記の自動車車両保険の例のように、タスクが並行して行われるというケース。この場合、WID では「Throw (スロー)」、「Fault Handler (障害ハンドラー)」、および「Terminate (強制終了)」を使用してパターンを実装することができます。これをソリューション 2 と呼びます。

注: イベント・ハンドラーを使用する場合は、相関セット ID を構成する必要があります。

実装 – ソリューション 1

図 6. 「タスクのキャンセル (Cancel Task)」パターンの実装 - ソリューション 1
「タスクのキャンセル (Cancel Task)」パターンの実装 - ソリューション 1

「Task1 (タスク 1)」と「Task2 (タスク 2)」は順番に行われます。「Task1 (タスク 1)」が実行中の場合には、「CancelTask (タスクのキャンセル)」によってタスクとプロセス・インスタンスを強制終了させることができます。この場合、「Task2 (タスク 2)」は当然実行されません。

実装 – ソリューション 2

図 7. 「タスクのキャンセル (Cancel Task)」パターンの実装 - ソリューション 2
「タスクのキャンセル (Cancel Task)」パターンの実装 - ソリューション 2

「Task1 (タスク 1)」と「Task2 (タスク 2)」は並行して作成されます。一方のタスクが完了すると、もう一方のタスクが取り消され、プロセス・インスタンスも強制終了されます。

WPS での実行 – ソリューション 1

プロセスの開始後、「Task1 (タスク 1)」が完了する前に、「CancelTask (タスクのキャンセル)」を呼び出すと、「Task1 (タスク 1)」とともにプロセス・インスタンスも強制終了されます (以下のログを参照)。

リスト 6. 「タスクのキャンセル (Cancel Task)」パターンのログ – ソリューション 1
[8/31/10 13:51:59:625 GMT+08:00] 00000061 SystemOut  O [Cancel Task] Task1 Start
[8/31/10 13:52:18:656 GMT+08:00] 00000061 SystemOut  O [Cancel Task] Cancel Task1

「Task1 (タスク 1)」とプロセス・インスタンスが強制終了されます。

WPS での実行 – ソリューション 2

実行の順序は以下のとおりです。

  1. プロセス・インスタンスを開始します。
  2. 「Task2 (タスク 2)」を要求します。
  3. 「Task1 (タスク 1)」を要求して完了します。

続いて「Task2 (タスク 2)」がキャンセルされ、プロセス・インスタンスが強制終了されます (以下のログを参照)。

リスト 7. 「タスクのキャンセル (Cancel Task)」パターンのログ – ソリューション2
[8/23/10 17:28:44:812 GMT+08:00] 0000004e SystemOut     O [Cancel Task]Enter 
                                                                    Task1 Completed
[8/23/10 17:28:45:015 GMT+08:00] 0000004e SystemOut     O [Cancel Task]Enter 
                                                                    Cancel Task

「ケースのキャンセル」パターン

「ケースのキャンセル (Cancel Case)」パターンでは、現在実行中のタスクとサブプロセスのすべてを含め、プロセス全体がキャンセルされます。このパターンは特定のプロセス・インスタンスを中止し、そのプロセス・インスタンスに関連付けられたすべてのタスクを取り消す方法となります。

例えば、銀行クレジット・カードの申し込みプロセスでは、「顧客情報の入力待機」タスクがタイムアウトした場合、プロセス・インスタンスと関連タスクのすべてをキャンセルすることができなければなりません。それと同時に、今後の監査のためにプロセス・インスタンスに失敗のマークを付ける必要があります。

このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

このパターンの焦点は以下のとおりです。

  1. プロセス・インスタンスが完全に除去されます。
  2. プロセスに関連するタスクは、現在実行中であるか、有効になっているかに関わらず、すべてキャンセルされます。
  3. サブプロセスについても一切実行されません。
  4. プロセス・インスタンスは、正常に完了しなかったとして記録されます。

WID でこのパターンを実装するには、「Event Handler (イベント・ハンドラー)」と「Terminate (強制終了)」を使用します。

実装

図 8. 「ケースのキャンセル (Cancel Case)」パターンの実装
「ケースのキャンセル (Cancel Case)」パターンの実装

プロセス・インスタンスの開始後、「Task1 (タスク 1)」とサブプロセス・インスタンスが並行して作成されます。「CancelCase (ケースのキャンセル)」要求が出されると、すべてのタスク、サブプロセス・インスタンス、および親プロセス・インスタンスがすべて強制終了されます。

注: サブプロセスを「ライフサイクルを呼び出し側ビジネス・プロセスにバインドする」ように設定することによって、親プロセスで強制終了アクションを実行すると、そのサブプロセスも強制終了されるようにしなければなりません。サブプロセスのライフサイクルについての詳細は、WPS 7.0 インフォメーション・センターを参照してください。

WPS での実行

実行の順序は以下のとおりです。

  1. プロセス・インスタンスを開始します。
  2. 「Task1 (タスク 1)」を要求します。
  3. キャンセル操作を呼び出します。

その後、すべてのタスクとサブプロセスを含め、プロセス全体が強制終了されます (以下のログを参照)。

リスト 8. 「ケースのキャンセル (Cancel Case)」パターンのログ
[8/31/10 11:36:28:531 GMT+08:00] 00000e5f SystemOut O [Cancel Case]Run into Initiate
[8/31/10 11:36:30:000 GMT+08:00] 00000061 SystemOut O [Cancel Case]Run into SubProcess
[8/31/10 11:37:07:078 GMT+08:00] 00000061 SystemOut O [Cancel Case]Run into CancelCase

プロセス・インスタンス、サブプロセス・インスタンス、そしてすべての未完了のタスクが強制終了されます。


「リージョンのキャンセル」パターン

「リージョンのキャンセル (Cancel Region)」パターンでは、一連のタスクがキャンセルされます。これらのタスクは、プロセス・モデル全体の中で互いに関連付けられたタスクである必要はありません。このパターンは、一連の (おそらく互いに関連付けられていない) タスクをキャンセルする際に便利な方法です。

例えば、オンライン・ショップの販売促進プロセスがあるとします。このプロセスでは、100 人の顧客が販促賞品を獲得した後、他の「顧客からの販促商品要求」タスクをまとめてキャンセルしなければなりません。

このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

このパターンの焦点は以下のとおりです。

  1. プロセス・インスタンスの一連のタスクを無効にします。
  2. 既に実行中のタスク、または現在有効にされているタスクは、すべて取り消されます。
  3. これらのタスクは、プロセス・モデル全体の中で互いに関連付けられたタスクである必要はありません。
  4. リージョンのキャンセル後、プロセス・インスタンスは次のアクティビティーを続けることができます。

WID では、このパターンを部分的にサポートします。まとめてキャンセルするタスクは、すべて同じスコープ内になければなりません。このパターンを実装するには、「Nesting Scope (ネスト・スコープ)」、「Event Handler (イベント・ハンドラー)」、「Throw (スロー)」、「Fault Handler (障害ハンドラー)」を使用します。

実装

図 9. 「リージョンのキャンセル (Cancel Region)」パターンの実装
「リージョンのキャンセル (Cancel Region)」パターンの実装

「Task1 (タスク 1)」と「Task2 (タスク 2)」は並行して作成され、「CancelRegion (リージョンのキャンセル)」が呼び出されると、スコープ内の未完了のタスクがすべて強制終了されます。プロセスは「AlternativeTask (代替タスク)」、そして「Next (次)」アクティビティーの順に進みます。

WPS での実行

実行の順序は以下のとおりです。

  1. プロセス・インスタンスを開始します。
  2. 「Task1 (タスク 1)」を要求します。
  3. 「CancelRegion (リージョンのキャンセル)」を呼び出します。

すると、「Task1 (タスク 1)」(実行中)、「Task2 (タスク 2)」(有効になっている状態)、「Task3 (タスク 3)」(有効になっていない状態) がまとめて取り消され、「AlternativeTask (代替タスク)」が実行されます。その後、プロセスは「Next (次)」アクティビティーに進みます (以下のログを参照)。

リスト 9. 「リージョンのキャンセル (Cancel Region)」パターンのログ
[8/31/10 10:48:12:078 GMT+08:00] 00000061 SystemOut     O [Cancel Region]Run 
                                                                into AlternativeTask
[8/31/10 10:48:12:078 GMT+08:00] 00000061 SystemOut     O [Cancel Region]Run 
                                                                into Next

「複数インスタンスから成るアクティビティーのキャンセル」パターン

「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンでは、複数インスタンスから成るアクティビティーがキャンセルされます。このパターンは、実行中の複数インスタンスのタスクを任意の時点でキャンセルすると、残りのすべてのインスタンスもキャンセルされるようにする方法として使用することができます。ただし、既に完了したインスタンスは、このキャンセル操作によって影響を受けません。

例えば、銀行クレジット・カードの申し込みプロセスで、それぞれに異なる個人に対する「最終承認」タスクの同時インスタンスが 3 つあり、そのすべてを1 日で完了しなければならないとします。タイムアウトになると、所有者が時間内にアクションを行わなかったタスクがキャンセルされますが、完了したタスクはそれによって影響されることはありません。

分析

このパターンの焦点は以下のとおりです。

  1. プロセス内で、1 つのタスクのインスタンスを複数作成することができます (タスクの数は設計時に既知になっています)。これらのイスタンスは互いに独立しています。
  2. 複数インスタンスのタスクは随時、キャンセルすることができます。この場合、完了していないタスクは取り消されます。
  3. 既に完了したインスタンスは、複数インスタンスのタスクをキャンセルしても影響されません。

WID では、「For Each (繰り返し)」、「Event Handler (イベント・ハンドラー)」、および「Terminate (強制終了)」を使用して、このパターンを実装することができます。この方法をソリューション 1 と呼びます。

一般に、ビジネス・シナリオではタスクを随時キャンセルする以外にも、何らかの基準に達した時点でタスクをキャンセルしなければならないことがあります。例えば、上記の銀行クレジット・カードの申し込みプロセスで言うと、タイムアウトが発生した時点で、タスクはキャンセルされます。このように、このパターンの上記 2 番目の要件が「基準に到達した時点」でキャンセルするように緩和されたような場合に、それを簡単に実装するための新機能として WID 7.0 には「Parallel Human Task (並列ヒューマン・タスク)」が用意されています。この新機能を使用する方法をソリューション 2 と呼びます。

実装 – ソリューション 1

図 10. 「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンの実装 - ソリューション 1
「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンの実装 - ソリューション 1

「For Each (繰り返し)」は以下のように構成されます。

図 11. 「For Each (繰り返し)」の構成
「For Each (繰り返し)」の構成
  1. 図 11 の赤い枠で囲ったセクション 1 では、「Parallel (並列)」に設定されています。これは、ヒューマン・タスクが並行して作成されることを意味します。「Sequential (順次)」に設定すると、ヒューマン・タスクは順次作成されることになります。
  2. セクション 2 は繰り返しのセクションです。繰り返しのセクションが決定するのは、作成する必要のあるヒューマン・タスクのインスタンス数です。上記では 1 から開始し、3 で終了するように設定しているため、最終的には 3 つのタスク・インスタンスが作成されることになります。

実装 – ソリューション 2

図 12. 「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンの実装 – ソリューション 2
「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンの実装 – ソリューション 2

「HumanTask (ヒューマン・タスク)」の構成を以下に示します。

図 13. 並列ヒューマン・タスクの構成
並列ヒューマン・タスクの構成
  1. 図 13の赤い枠で囲ったセクション 1 では、「Parallel (並列)」に設定されています。これは、複数のタスク・インスタンスが設計に従って並行して作成されることを意味します。
  2. セクション 2 は、潜在的な所有者を設定するためのフィールドです。潜在的所有者をグループのメンバーに設定するために、「GroupName (グループ名)」には「cn=S27Group,o=defaultWIMFileBasedRealm」と設定してください。「S27Group」は WPS リポジトリーに事前定義されたグループで、このグループには複数のユーザーが含まれます。このように指定することで、S27Group に含まれるユーザーごとに、1 つのタスク・インスタンスが実行時に作成されます。
  3. セクション 3 は、タイムアウトのルールを設定する部分です。上記の構成では、5 分以内に完了しないタスクが 1 つでもあると、まだ完了していない残りのタスクがすべてキャンセルされるようになっていますが、タイムアウトのルールは自由に定義することができます。
  4. セクション 4 では早期終了基準を構成しています。上記のスナップショットでは、80% を超えるタスク所有者が特定の出力フィールドに true を返すと、残りのタスク・インスタンスがキャンセルされてプロセスが先に進むように指定されています。

WPS での実行 – ソリューション 1

プロセスの開始後、以下の 3 つのタスクが並行して作成されます。すべてのタスクのステータスは「Ready (実行可能)」になっています。

図 14. ソリューション 1: タスクの作成
ソリューション 1: タスクの作成

以下のように、1 つのタスクが完了 (ステータスが「Finished (完了)」に変化) すると、別の 1 つのタスクを要求します (ステータスが「Claimed (要求済み)」に変化)。

図 15. ソリューション 1: タスクの要求/完了
ソリューション 1: タスクの要求/完了

次に、「取り消し」操作を呼び出すと、完了していないすべてのタスクがキャンセルされ (ステータスが「Terminated (強制終了済み)」に変化)、完了済みタスクはそのステータスが維持されます (以下を参照)。

図 16. ソリューション 1: 未完了タスクのキャンセル
ソリューション 1: 未完了タスクのキャンセル

WPS での実行 – ソリューション 2

注: WPS の統合リポジトリーに 1 つのグループ (この例では S27Group) が事前定義されている必要があります。

プロセス・インスタンスの開始後、以下の 3 つのタスクが並行して作成されます。ステータスは「Claimed (要求済み)」です。

図 17. ソリューション 2: タスクの要求
ソリューション 2: タスクの要求

usr1 のタスクを完了します。他の 2 つのタスクは「Claimed (要求済み)」のステータスのまま残しておきます。5 分に設定されたタイムアウトが発生すると、この 2 つの未完了のタスクがキャンセルされ、ステータスが「Terminated (強制終了済み)」に変化します。

図 18. ソリューション 2: タスクのキャンセル
ソリューション 2: タスクのキャンセル

「複数インスタンスから成るアクティビティーの強制終了」パターン

「複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)」パターンでは、複数のインスタンスから成るアクティビティーをキャンセルした後、プロセスが次のノードに進めるようにします。これは、まだ完了していない実行中の複数インスタンスのタスクを任意の時点でキャンセルすると、残りのすべてのインスタンスが取り消されると同時に、スレッド制御が後続のタスクに渡されるようにする方法となります。

例えば、銀行クレジット・カードの申し込みプロセスで、各個人に対する「最終承認」タスクの同時インスタンスが 3 つあり、そのすべてを1 日で完了しなければならないとします。タイムアウトが発生すると、所有者が時間内にアクションを行わなかったタスクがキャンセルされますが、完了済みのタスクは影響されません。プロセスはその後すぐに、「カード作成」タスクに進みます。

このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

このパターンの焦点は以下のとおりです。

  1. プロセスでは、1 つのタスクのインスタンスを複数作成することができます (タスクの数は設計時に既知になっています)。これらのインスタンスは互いに独立しています。
  2. 複数インスタンスのタスクを任意の時点で強制終了することができます。すると、完了していないタスクは取り消され、スレッド制御が後続のタスクに渡されます。
  3. 既に完了しているインスタンスは、複数インスタンスのタスクをキャンセルしても影響を受けません。

注: このパターンは、複数のインスタンスから成るアクティビティーをキャンセルする必要があるという点で、「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンと同様です。この 2 つのパターンの違いは、「複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)」パターンの場合、複数のインスタンスがキャンセルされた後に、スレッド制御が後続のタスクに渡されるところにあります。

WID では、「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンと同様の 2 つのソリューションを使用することができます。その場合に必要なのは、後続タスクの実装を追加することだけです。

実装 – ソリューション 1

図 19. 「複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)」パターンの実装 – ソリューション 1
「複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)」パターンの実装 – ソリューション 1

主な部分は「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンのソリューション 1 と同じですが、以下の点が異なります。

  1. インラインのヒューマン・タスクではなく、スタンドアロンのヒューマン・タスクを使用します (関連するシステム API は、スタンドアロンのヒューマン・タスクで動作可能であるため)。
  2. Java スニペット「ForceCompleteRestTasks」で WPS のヒューマン・タスク・マネージャー API を使用して未完了のタスクを取り消します。
リスト 10. ForceCompleteRestTasks コード
System.out.println("[Complete Multiple Instance Task]Enter ForceCompleteRestTasks");
try{
javax.naming.Context initialContext= new javax.naming.InitialContext();
com.ibm.task.api.HumanTaskManagerHome home= 
    (com.ibm.task.api.HumanTaskManagerHome)initialContext.lookup
                ("com/ibm/task/api/HumanTaskManagerHome");
com.ibm.task.api.HumanTaskManager manager= home.create();
com.ibm.task.api.QueryResultSet queryresult = 
    manager.query("DISTINCT TASK.TKIID","(TASK.STATE = 
                TASK.STATE.STATE_CLAIMED OR TASK.STATE = 
                TASK.STATE.STATE_READY) AND (TASK.KIND = 
                TASK.KIND.KIND_PARTICIPATING OR TASK.KIND = 
                TASK.KIND.KIND_HUMAN)",
                                   (String)null,(Integer)null, (java.util.TimeZone)null);
System.out.println("task size : " + queryresult.size());

if (queryresult.size() > 0)
{
  queryresult.first();
  do{
	  com.ibm.task.api.TKIID tkiid = (com.ibm.task.api.TKIID) queryresult.getOID(1);
	  System.out.println("terminate : " + tkiid.toString());
	  manager.terminate(tkiid);
  }while(queryresult.next());
  
}
}catch (Exception e){
System.out.println("exception occured! ");
e.printStackTrace();
}

注: ヒューマン・タスク・マネージャー API を呼び出すことができるのは、管理者権限を持つ WPS ユーザーだけです。ヒューマン・タスク・マネージャー API についての詳細は、WPS インフォメーション・センターを参照してください。

実装 – ソリューション 2

図 20. 「複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)」パターンの実装 – ソリューション 2
「複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)」パターンの実装 – ソリューション 2

主な部分は「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンのソリューション 2 と同じですが、並列の「HumanTask (ヒューマン・タスク)」の下に「Case1 (ケース 1)」が追加されているという点が異なります。

WPS での実行 – ソリューション 1

実行の順序は以下のとおりです。

  1. プロセスの開始後、以下の 3 つのタスクが作成されます。すべてのタスクのステータスは「Ready (実行可能)」です。
  2. 1 つのタスクを完了した後、1 つのタスクを要求します。
  3. 「forcecomplete (強制終了)」操作を呼び出します。

SystemOut.log には、以下のログが記録されます。2 つのタスク (一方のステータスは「Ready (実行可能)」、もう一方のステータスは「Claimed (要求済み)」) は強制終了されますが、既に完了しているタスクは影響を受けません。そして、プロセスは「Case1 (ケース 1)」に進みます。

リスト 11. 「複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)」パターンのログ – ソリューション 1
[8/24/10 17:04:27:296 GMT+08:00] 00000051 SystemOut O [Complete Multiple Instance Task]
                                                       Enter ForceCompleteRestTasks
[8/24/10 17:04:27:718 GMT+08:00] 00000051 SystemOut O tasks remained : 2
[8/24/10 17:04:27:718 GMT+08:00] 00000051 SystemOut O terminate 
                                                       : _TKI:a01b012a.a356f291.3aa4af6
                                                                    .f0c21648
[8/24/10 17:04:27:843 GMT+08:00] 00000051 SystemOut O terminate
                                                         : _TKI:a01b012a.a356f291.3aa4af6
                                                                    .f0c21649
[8/24/10 17:04:27:906 GMT+08:00] 00000051 SystemOut O [Complete Multiple Instance Task]
                                                       Enter Case1

WPS での実行 – ソリューション 2

並列の「HumanTask (ヒューマン・タスク)」が終了基準に達すると、まだ完了していない残りのタスクは強制終了され、プロセスは「Case1 (ケース 1)」に入ります。

結果の大半は、「複数インスタンスから成るアクティビティーのキャンセル (Cancel Multiple Instance Activity)」パターンのソリューション 2 と変わりませんが、SystemOut.log に記録された以下のログにあるように、並列の「HumanTask (ヒューマン・タスク)」の後、プロセスは「Case1 (ケース 1)」に進むという点が異なります。

リスト 12. 「複数インスタンスから成るアクティビティーの強制終了 (Complete Multiple Instance Activity)」パターンのログ – ソリューション 2
[8/24/10 14:03:21:922 GMT+08:00] 00000051 SystemOut O [Complete Multiple Instance Task]
                                                       Enter Case1

まとめ

この記事では、5 つの「基本的な制御フロー・パターン」と、5 つの「キャンセルおよび強制終了パターン」を、それぞれに対応する WID 実装と併せて紹介しました。これらのワークフロー・パターンによって、条件付きキャンセルを考慮した、単純で基本的なプロセスを作成することができます。しかも WID では、このすべてのパターンを簡単に実装できることを理解していただけたはずです。

次回の記事では、今回紹介したのとは別の高度なワークフロー・パターンとそれぞれの WID 実装について詳しく説明します。


ダウンロード

内容ファイル名サイズ
PI files for this articlePart1PI.zip255KB

参考文献

学ぶために

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services, WebSphere
ArticleID=587576
ArticleTitle=高度なワークフロー・パターンを WebSphere Integration Developer と WebSphere Process Server で実装する: 第 1 回 基本的な制御フロー・パターンと、キャンセルおよび強制終了パターン
publish-date=10182010