はじめに

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

これまで、この連載の第 1 回、第 2 回、第 3 回で、合計 34 のパターンをそれぞれの実装と併せて紹介しました。連載第 4 回目となるこの記事では、残る 3 つのカテゴリーのパターンとして、状態に基づくパターン、完了パターン、そしてトリガー・パターンについて詳しく説明します。

上に戻る

状態に基づくパターン

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

1. 遅延選択 (Deferred Choice)
2. インターリーブ並列ルーティング (Interleaved Parallel Routing)
3. マイルストーン (Milestone)
4. クリティカル・セクション (Critical Section)
5. インターリーブ・ルーティング (Interleaved Routing)

これらのパターンを使用すれば、顧客は状態に基づくプロセスのほとんどの種類を簡単に実装することができます。

上に戻る

「遅延選択」パターン

「遅延選択 (Deferred Choice)」パターンでは、プロセス内での選択のタイミングを遅延させることができます。決定は、プロセス・インスタンスの外部要因 (着信メッセージ、環境データ、リソースの使用可能状況、タイムアウトなど) に基づいて行われます。

例えば、銀行が発行するクレジット・カードの申し込みプロセスで、申し込み者がカードの発行を申請した後、ヒューマン・タスクによって信用調査が行われます。この信用調査の結果が、その後どのブランチに進むことになるかを決定します。このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

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

1. このプロセス内では、外部情報によって以降のブランチが決定されるポイントがあります。
2. 外部情報には、着信メッセージ、環境データ、リソースの使用可能状況、タイムアウトなどがあります。
3. 次に進むブランチが決定された後、選択されたブランチ以外のブランチに含まれる実行選択肢は破棄されます。

WID では、ヒューマン・タスクと「Choice (選択肢)」要素を使用して、このパターンを実装することができます。

実装

どのケースに進むかは、ヒューマン・タスク・ノード「InputDeferredChoice (遅延選択の入力)」で決定されます。field2 が 1 の場合は「Case1 (ケース 1)」に進み、field2 が 2 の場合は「Case2 (ケース 2)」に進みます。field2 がその他の値の場合には「Case3 (ケース 3)」に進みます。

WebSphere Process Server での実行

ヒューマン・タスクでの入力が「1」の場合、プロセスは「Case1 (ケース 1)」に進みます (以下のログを参照)。

[8/23/10 14:52:16:453 GMT+08:00] 0000004e SystemOut     O [Sequence] Run into Case1

上に戻る

「インターリーブ並列ルーティング」パターン

「インターリーブ並列ルーティング (Interleaved Parallel Routing)」パターンでは、一般にプロセスが一連のタスクに課す厳密な順序を緩和します。すべてのタスクが実行されることは必須ですが、一度に実行できるのは 1 つのタスクだけです。

例えば、オンライン・ストアの注文品配送プロセスでは、商品選定タスク、商品梱包タスク、納品・請求書作成タスクを完了しなければなりません。商品選定タスクは、商品梱包タスクの前に完了する必要があります。納品・請求書作成タスクを行うタイミングは決まっていません。特定の注文に対して、この 3 つのタスクのうちの 1 つのタスクだけを任意の時点で行うことができます。このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

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

1. 一連のタスクには、一部に順序が定義されます。
2. 各タスクは一度実行する必要があり、定義された部分的な順序に従っていれば、後は任意の順序で完了することができます。
3. 一度に実行できるタスクは 1 つだけです。

WID ではこのパターンを、「Isolated Scope (分離スコープ)」および「Fork Gateway (フォーク・ゲートウェイ)」を使用して簡単に実装することができます。

実装

「HumanTaskC (ヒューマン・タスク C)」は、「HumanTaskA (ヒューマン・タスク A)」の後に実行しなければなりません。これが定義されている部分的な順序です。「Fork Gateway (フォーク・ゲートウェイ)」から開始されるタスクのパスは 2 つあります。どちらのタスク (「HumanTaskA (ヒューマン・タスク A)」または「HumanTaskB (ヒューマン・タスク B)」) を最初に実行するのかは、「Wait1 (待機 1)」と「Wait2 (待機 2)」が制御します。プロセスは最後に、「PrintResult (結果の印刷)」アクティビティーに進みます。

注: 各スコープを (「Property Detail (プロパティーの詳細)」タブで) 「isolated (分離)」として定義する必要があります。このように定義することにより、実行時にこれらの分離スコープが順に実行されることが確実になります。つまり、一度に 1 つの分離スコープしか実行できないということです。

WebSphere Process Server での実行

[9/6/10 15:49:20:000 GMT+08:00] 00000097 SystemOut     O 
                                            [run InterleavedParallelRouting] and the 
sequence is : [runHumanTaskA] ->  [runHumanTaskB] ->  [runHumanTaskC] ->  End.           

上に戻る

「マイルストーン」パターン

「マイルストーン (Milestone)」パターンは、プロセス・インスタンスが特定の状態になったという条件で、タスクまたはサブプロセスを実行するためのメカニズムです。つまり、プロセス・インスタンスに 2 つの別個のブランチがある場合、一方のブランチが指定された状態にならなければ、もう一方のブランチが進めないように、2 つのブランチを同期させる手段となります。

例えば、銀行口座開設申請プロセスでは、銀行スタッフによって口座開設タスクが開始される前であれば、口座の開設に必要な情報を顧客が更新することができます。しかし口座開設タスクが完了した後は、顧客は申請内容を更新できなくなります。このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

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

1. ある特定のタスクは、プロセス・インスタンスが特定の状態にならないと有効になりません。
2. その状態は、プロセス・モデル内の特定の実行ポイント (別名、マイルストーン) と見なされます。
3. マイルストーンに達すると、所定のタスクを有効にすることができます。
4. プロセス・インスタンスがこの状態を通り過ぎると、その時点から、そして将来のある時点でも、タスクを有効にすることができなくなります。

WID でこのパターンを実装するには、「GeneralizedFlow (汎用フロー)」内で「Fork (フォーク)」、「Join (結合)」、および「Split (分割)」ゲートウェイを条件付きリンクと併せて使用します。

実装

「Trigger (トリガー)」タスクが、タスク「E」のマイルストーンです。「Trigger (トリガー)」タスクが有効になり、「DeferChoice (遅延選択)」タスクが完了していなければ、タスク「E」のブランチを有効にして、タスク「D」にロールバックすることができます。「Trigger (トリガー)」タスクが有効であるか、あるいは無効であるかをマークするには、変数 istri を使用します。変数 EorF は、「DeferChoice (遅延選択)」タスクの後に進むブランチ (タスク「E」またはタスク「F」) を制御します。

注:

1. 実行時に、「DeferChoice (遅延選択)」インスタンスが作成された後に「Trigger (トリガー)」タスクが有効にされた場合、取り得る選択肢 (入力パラメーターとして「DeferChoice (遅延選択)」タスクに渡される) の更新は行われなくなります。
2. 「DeferChoice (遅延選択)」の後に「Error (エラー)」パスが追加されているのは、「Trigger (トリガー)」が無効にされた場合にユーザーがタスク「E」を選択することは許可されないためです。このパスにより、ユーザーが正しい選択を行えるように 1 つの「DeferChoice (遅延選択)」インスタンスが新しく作成されます。

WebSphere Process Server での実行

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

1. プロセス・インスタンスを開始します。
2. 「Trigger (トリガー)」タスクを要求します。
3. 「DeferChoice (遅延選択)」タスクを完了します (出力は「E」です)。
4. 「Trigger (トリガー)」タスクを完了します (出力は「false」です)。
5. 「DeferChoice (遅延選択)」タスクを完了します (出力は「F」です)。

       
[9/27/10 16:32:07:109 GMT+08:00] 00000054 SystemOut     O Enter Start
[9/27/10 16:32:07:109 GMT+08:00] 00000054 SystemOut     O Enter D
[9/27/10 16:32:07:109 GMT+08:00] 00000054 SystemOut     O Enter A
[9/27/10 16:32:45:500 GMT+08:00] 00000054 SystemOut     O Enter E
[9/27/10 16:32:45:500 GMT+08:00] 00000054 SystemOut     O Enter D
[9/27/10 16:33:17:609 GMT+08:00] 00000054 SystemOut     O Enter F
[9/27/10 16:33:17:609 GMT+08:00] 00000054 SystemOut     O Enter G
[9/27/10 16:33:29:703 GMT+08:00] 00000054 SystemOut     O Enter C
[9/27/10 16:33:29:718 GMT+08:00] 00000054 SystemOut     O Enter End 

上に戻る

「クリティカル・セクション」パターン

「クリティカル・セクション (Critical Section)」パターンは、プロセスの複数のセクションを同時に実行できないようにするための手段となります。このパターンが必要となるのは、セクション内のタスクが、タスクを完了するために必要な共通リソース (データまたは物理リソース) に排他的にアクセスしなければならない場合です。

例えば、旅行予約プロセスの「予約金受領」タスクと「保険金支払い」タスクでは、クレジット・カード処理端末を排他的に使用しなければなりません。したがって、任意の時点で実行できるのは、2 つのタスクのうち、いずれか一方だけです。このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

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

1. プロセス・モデルに接続された複数のサブグラフは、「クリティカル・セクション」として識別されます。
2. 特定のプロセス・インスタンスの実行時には常に、これらの「クリティカル・セクション」のうちいずれか 1 つの「クリティカル・セクション」のタスクしか実行することができません。

WID でこのパターンを実装するには、トークン変数を定義した「WhileLoop (while ループ)」を使用することができます。

実装

各パスにあるスコープが、定義された「クリティカル・セクション」です。このスコープに入ったパスは、完了するまでトークン変数を保持します。その間、別のパスは待機状態となり、トークンが解放されるまではクリティカル・セクションを実行することはできません。

WebSphere Process Server での実行

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

1. プロセス・インスタンスを開始します。
2. 「HumanTask1 (ヒューマン・タスク 1)」を完了します。
3. 「HumanTask (ヒューマン・タスク)」を完了します。
4. 「HumanTask3 (ヒューマン・タスク 3)」を完了します。
5. 「HumanTask2 (ヒューマン・タスク 2)」を完了します。

              
[9/6/10 18:05:20:765 GMT+08:00] 00000071 SystemOut     O Process Starts
[9/6/10 18:05:37:312 GMT+08:00] 00000075 SystemOut     O Process2 starts
[9/6/10 18:05:37:375 GMT+08:00] 00000075 SystemOut     O Run into Critical Section 2 
                                                                    : true
[9/6/10 18:05:49:687 GMT+08:00] 00000075 SystemOut     O Process1 starts
[9/6/10 18:05:49:703 GMT+08:00] 00000075 SystemOut     O Process1 is waiting
[9/6/10 18:05:54:953 GMT+08:00] 00000045 SystemOut     O Process1 is waiting
[9/6/10 18:06:00:000 GMT+08:00] 00000045 SystemOut     O Process1 is waiting
[9/6/10 18:06:05:031 GMT+08:00] 00000044 SystemOut     O Process1 is waiting
[9/6/10 18:06:05:109 GMT+08:00] 00000075 SystemOut     O Process2 finished
[9/6/10 18:06:05:109 GMT+08:00] 00000075 SystemOut     O Process2 release the token
[9/6/10 18:06:10:062 GMT+08:00] 00000044 SystemOut     O Run into Critical Section 1 
                                                                    : true
[9/6/10 18:06:24:984 GMT+08:00] 00000075 SystemOut     O Process1 finished
[9/6/10 18:06:24:984 GMT+08:00] 00000075 SystemOut     O Process1 release the token
[9/6/10 18:06:24:984 GMT+08:00] 00000075 SystemOut     O All Processes Finished 

上に戻る

「インターリーブ・ルーティング」パターン

「インターリーブ・ルーティング (Interleaved Routing)」パターンでは、一連のタスクを任意の順序で実行することはできますが、2 つのタスクを同時に実行することはできません。

例えば、機械の保守プロセスでは、オイル・チェック、フィーダーのテスト、メイン・ユニットの検査、保証内容の点検というすべてのタスクをプロセスの一環として行わなければなりません。一度に実行できるのは 1 つのタスクだけですが、任意の順序で実行することができます。

注: このパターンは「インターリーブ並列ルーティング (Interleaved Parallel Routing)」パターンと同様です。異なる点は、「インターリーブ並列ルーティング (Interleaved Parallel Routing)」パターンには部分的な実行順序の制約がありますが、このパターンには順序の制約は一切ありません。一連のタスクを任意の順序で実行することができます。

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

分析

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

1. 一連のタスクの各メンバーを一度実行する必要があります。
2. 任意の順序でタスクを実行することができますが、2 つのタスクを同時に実行することはできません。
3. すべてのタスクが完了したら、プロセスの次のタスクを開始することができます。

WID でこのパターンを実装するには、「Fork (フォーク)」ゲートウェイと「WhileLoop (while ループ)」をトークン変数と併せて使用します。

実装

「Branch1 (ブランチ 1)」、「Branch2 (ブランチ 2)」、および「Branch3 (ブランチ 3)」は同時に有効になり、入力ビジネス・データに定義された実行順序に応じて「Case1 (ケース 1)」、「Case2 (ケース 2)」、および「Case3 (ケース 3)」が実行されます。1 つのケースが実行されている間 (このケースがトークンを保持)、完了していない他のブランチは、トークンが解放されるまで待機状態となります。

WebSphere Process Server での実行

          
[9/7/10 9:39:41:890 GMT+08:00] 0000007b SystemOut     O process starts
[9/7/10 9:39:41:890 GMT+08:00] 0000007b SystemOut     O branch2 is ready
[9/7/10 9:39:41:921 GMT+08:00] 0000007b SystemOut     O branch1 is ready
[9/7/10 9:39:41:921 GMT+08:00] 0000007b SystemOut     O branch3 is ready
[9/7/10 9:39:42:015 GMT+08:00] 0000007b SystemOut     O branch2 is waiting
[9/7/10 9:39:42:031 GMT+08:00] 0000007b SystemOut     O Case1 finish
[9/7/10 9:39:42:046 GMT+08:00] 0000007b SystemOut     O branch3 is waiting
[9/7/10 9:39:44:250 GMT+08:00] 00000044 SystemOut     O Case2 finish
[9/7/10 9:39:44:468 GMT+08:00] 00000045 SystemOut     O Case3 finish
[9/7/10 9:39:44:468 GMT+08:00] 00000045 SystemOut     O process completes

上に戻る

「完了」パターン

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

1. 暗黙的完了 (Implicit Termination)
2. 明示的完了 (Explicit Termination)

この 2 つのパターンは、ワークフローが完了すると見なされているときに広く使用されます。ビジネス・インスタンスを暗黙的に、または明示的に完了する手段となります。

「暗黙的完了」パターン

「暗黙的完了 (Implicit Termination)」パターンでは、実行できるワーク・アイテムが残っていないこと、そしてプロセス・インスタンスがデッドロック状態にはないことを条件に、特定のプロセス (またはサブプロセス) を完了します。このパターンは、プロセス・インスタンスが正常に完了したかどうかを判断する方法となります。プロセス・インスタンスが正常に完了したかどうかを判断することは、あらゆる種類のプロセスで極めて一般的な要件です。

例えば、銀行クレジット・カードの申し込みプロセスの場合、すべてのタスクが意図通りに完了すれば、プロセス・インスタンス全体が正常に完了したことになります。このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

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

1. プロセス・インスタンスは、残りのワーク・アイテムがなくなった時点で完了します。
2. プロセスには正常に完了したというマークが付けられます。

WID ではこのパターンをデフォルトでサポートしています。あるプロセスのワーク・アイテムがすべて意図通りに完了すると、そのプロセス・インスタンスは正常に完了します。

実装

2 つのブランチが順に実行されます。すべてのノード (「NodeA (ノード A)」から「NodeE (ノード E)」まで) が完了すると、プロセスが完了し、正常に完了したというマークが付けられます。

WebSphere Process Server での実行

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

1. プロセス・インスタンスを開始します。
2. ヒューマン・タスク「NodeB (ノード B)」、「NodeC (ノード C)」、「NodeD (ノード D)」、「NodeE (ノード E)」を順に完了します。

プロセス・インスタンスが完了し、正常に完了したことを意味する「Finished」のマーク (図 8 を参照) が付けられます。

注: デフォルトでは、プロセス・インスタンスが正常に完了すると、そのインスタンスは削除されます。正常に完了したプロセス・インスタンスを確認できるようにするには、(プロセス・プロパティーの詳細タブで) 「Automatically delete the process after completion (完了後にプロセスを自動的に削除する)」を「No (いいえ)」に設定してください。

上に戻る

「明示的完了」パターン

「明示的完了 (Explicit Termination)」パターンでは、特定のプロセス (またはサブプロセス) インスタンスが所定の状態に達すると、そのインスタンスを完了します。その所定の状態とは、一般には特定の終了ノードのことです。この終了ノードに達すると、プロセス・インスタンスでの残りの作業はすべてキャンセルされます。その結果、プロセス・インスタンス全体が正常に完了したとして記録されます。このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

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

1. プロセス・インスタンスがを特定の終了ノードに達すると、そのプロセス・インスタンスは完了します。
2. プロセス・インスタンスでの残り作業は、キャンセルされます。
3. プロセス・インスタンス全体は、正常に完了したものとして記録されます。

WID では、「 Throw (スロー) 」および「 Fault Handler (障害ハンドラー) 」を使用して、このパターンを簡単に実装することができます。

実装

プロセス・インスタンスが開始された後、ヒューマン・タスク「Task1 (タスク 1)」が作成されます。それと同時に、次のブランチを選択するための「Choice (選択肢)」要素が作成されます。最初のブランチが選択された場合、ユーザー定義の例外がスローされて障害ハンドラーが有効になります。その後、プロセス・インスタンスが完了し (「Finished」とマークされます)、そのサブインスタンスであるヒューマン・タスク「Task1 (タスク 1)」も同じく完了します。

WebSphere Process Server での実行

プロセス・インスタンスの開始後、入力「id」が「000」に設定されると、「Choice (選択肢)」から最初のブランチに進み、以下のステータスとなります。

1. プロセス・インスタンスは以下のように完了します。

2. サブプロセス・インスタンス (この例ではヒューマン・タスク・インスタンス) も以下のように完了します。

上に戻る

トリガー・パターン

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

1. 一時トリガー (Transient Trigger)
2. 永続トリガー (Persistent Trigger)

この 2 つのパターンは、特定のタスクを開始するために外部シグナルが必要な場合に使用されます。これらのパターンは、一時トリガーおよび永続トリガーを処理する方法となります。

上に戻る

「一時トリガー」パターン

「一時トリガー (Transient Trigger)」パターンでは、プロセスの別の部分からのシグナル、あるいは外部環境からのシグナルによってタスク・インスタンスをトリガーすることが可能です。最も重要な点として、これらのトリガーは一時的なものであり、受信タスクによって即座に反応されなければ失われます。

例えば、ダムが満水であることを示すシグナルを受け取った場合には、洪水対策タスクを即時に開始しなければなりません。このタスクがすぐに実行されなければ、トリガーは無効になり、再トリガー不能な形で失われます。このパターンの詳しい説明を参照するには、ここをクリックしてください。

分析

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

1. タスク・インスタンスをシグナルによってトリガーすることができます。
2. 信号は一時的なものです。
3. 受信タスクが即時に対応できない場合、シグナルは失われる結果となります。

WID でこのパターンを実装するには、特定のビジネス・オブジェクトと「Event Handler (イベント・ハンドラー)」を使用します。

実装

特定のビジネス・オブジェクト (TransientTrigger) が、トリガー起動時間をはじめ、一時トリガーに関する情報を保持することになります (以下の図を参照)。トリガー・イベントにこのビジネス・オブジェクトが付随している場合、プロセスは現在の時刻と、TransientTrigger が保持する起動時刻とを比較します。現在の時刻と起動時刻の差が 100 ミリ秒を超えている場合、トリガーは期限切れとして破棄されます。そうでなければ、トリガーはアクティブであり、「Case 2 (ケース 2)」が実行されます。

上に戻る

「永続トリガー」パターン

「永続トリガー (Persistent Trigger)」パターンでは、プロセスの別の部分からのシグナル、あるいは外部環境からのシグナルによってタスク・インスタンスがトリガーされます。最も重要な点は、これらのトリガーは永続的な形式になっており、受信タスクによる対応がなされるまで、プロセスがトリガーを保持することです。

注: このパターンは「一時トリガー (Transient Trigger)」パターンと同様です。両者が異なる点は、「一時トリガー (Transient Trigger)」パターンではトリガーが一時的なものであり、受信タスクが即時に対応できなければシグナルが失われるという結果になる一方、「永続トリガー (Persistent Trigger)」パターンの場合にはトリガーが永続的であり、受信タスクが対応するまでの厳格な時間制約がないことです。従って、受信タスクを即時に開始することも (そのタスクが既にスレッド制御を受け取っている場合)、後で開始することもできます。

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

分析

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

1. タスク・インスタンスをシグナルによってトリガーすることができます。
2. シグナルは永続的な形式になっています。
3. 受信タスクを即時に開始することも、後で開始することもできます。

WID では、「Event Handler (イベント・ハンドラー)」を使ってこのパターンを実装することができます。

実装

プロセス・インスタンスの開始後、「Case1 (ケース 1)」に進みます。そこでトリガー呼び出し (「FirePerTrigger (トリガー別の起動)」) を受け取ると、イベント・ハンドラーが有効になり、「Case2 (ケース 2)」が実行されます。

上に戻る

まとめ

この記事では、5 つの「状態に基づくパターン」と、2 つの「完了パターン」、そして 2 つの「トリガー・パターン」を、それぞれに対応する WID 実装と併せて紹介しました。これらのワークフロー・パターンがあれば、ビジネス・プロセスの高度な制御が可能になります。しかも WID では、このすべてのパターンを簡単に実装することができます。

上に戻る

ダウンロード

ダウンロード形式について

参考文献

• Workflow Patterns Initiative の詳細を学んでください。
  
  
• ビジネス・プロセス・マネジメントのサンプルにアクセスしてください。
  
  
• WebSphere Process Server インフォメーション・センターにアクセスしてください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 状態に基づくパターン
• 「遅延選択」パターン
• 「インターリーブ並列ルーティング」パターン
• 「マイルストーン」パターン
• 「クリティカル・セクション」パターン
• 「インターリーブ・ルーティング」パターン
• 「完了」パターン
• 「明示的完了」パターン
• トリガー・パターン
• 「一時トリガー」パターン
• 「永続トリガー」パターン
• まとめ
• ダウンロード
• 参考文献
• 著者について
• コメント