BPM ワークフロー設計上のベストプラクティス

ドキュメントのダウンロード

サイトマップ

用語集

検索

e-docs > WebLogic Integration > BPM ワークフローの設計ベストプラクティスガイド > BPM ワークフロー設計上のベストプラクティス

BPM ワークフローの設計ベストプラクティスガイド

BPM ワークフロー設計上のベストプラクティス

BEA WebLogic Integration Studio では、ビジネスプロセスワークフローを設計し、モニタする設計環境を提供しています。Studio ワークフローを作成している、またはワークフロー管理システムとして Integration Studio を使用する予定の場合、ワークフローの設計にベストプラクティスを念頭に置くようにすることをお勧めします。以下の節では、将来の製品リリースに移行するときに、スムーズに移行作業が行なえるためのワークフロー構築のガイドラインを示します。

ベストプラクティスをお勧めする理由

現行の WebLogic Integration Studio 実装では、構造化していないワークフローでも構築することができます。しかし、ワークフロー管理の関係業界、および近年意識されつつあるワークフロー規格においても、構造化ワークフローの設計を推奨しています。将来バージョンの WebLogic Integration Studio では構造化ワークフローの使用が必須となる予定で、ワークフロー規格が成熟し、その使用が妥当と思われた段階でこれに準拠する予定です。このマニュアルでは、現在の WebLogic Integration Studio で使用するための構造化ワークフローのパターンを説明します。ここで挙げるガイドラインに従うことにより、よりよい設計のワークフローが構築でき、構造化ワークフローパラダイムへの移行がスムーズに行なえるようになります。

注意: 以下のガイドラインは、従うべきビジネスロジックの実装方法を提起するものではありません。

ビジネスプロセスの設計

ワークフロー定義は、複雑なビジネスプロセス、方針、および手順をカプセル化するものです。その複雑さを考慮して、ベストプラクティスガイドラインでは、共通する一般的なワークフローパターンに関連した事項を提示します。コンセプトによっては、そのコンセプトの望ましい実装方法、および避けるべき事項を具体的に示します。

提示されたワークフローパターンやプログラミングの推奨方法は、それが対応するコンセプトの唯一の実装方法というわけではありません。提示内容は、一般的な設計原理がわかりやすいように、また自動移行するときに最適とは言えないモデルないしワークフローパターンを明確に指摘するために意図的に単純化してあります。当然のことながら、実際のビジネス事例では、それらのコンセプトについて異なる実装または設計が必要な場合もあるでしょうし、実際のワークフロー設計は、このマニュアルで提示される設計パターンよりもおそらくより複雑なものになると思われます。

このガイドで提示される実装例は、ワークフロー設計を最適化する必要度の評価手段、および目安として使用してください。ここで提示されるガイドラインに盲従することは、実際のビジネスプロセスを反映していない、不適切なワークフローになる場合もありますので、決してお勧めできません。

WebLogic Integration Studio を使用したワークフローの設計

ここで規定する望ましいベストプラクティスは、WebLogic Platform リリース 7.0 の WebLogic Integration Design Studio コンポーネントを使用してワークフローを設計することを想定しています。WebLogic Integration Studio を使用したワークフローの設計に関する詳細は、以下の各トピックのマニュアルを参照してください。

よく使用されるワークフローパターンに対するワークフロー設計の推奨例

以下の節では、ワークフロー構築におけるさまざまな推奨パターンを提示します。これらのガイドラインは、よくある共通のワークフロー問題に対する適切な対処法を提示することを目的としています。ビジネスプロセスに関して多くのワークフローで見られる一般的なパターンには、以下のようなものがあります。

ここからは、それらのパターンに関する説明、およびそれらのワークフローの推奨される実装について具体的に記載します。

並行実行

「並行実行」パターンは、1 つのワークフローノードから出るすべての並行パスが、同時に実行され、その並行処理の終了地点の AND ノードで再び 1 つになる場合を表します。このワークフローパターンを適切に実装するためには、次のガイドラインに従ってください。

1 つのワークフローノードから出るすべての並行パスが同じ AND ノードに合流するようにします。起点が異なる複数のノードになっている並行パスは、同じ AND ノードに合流することはできません。言い換えれば、並行実行域では、必ず単独の入口ポイントと出口ポイントを持たなければならない、ということです。これらのパスは、パスの構成要素も同様に単独の入口ポイントと出口ポイントを持つ、という条件が満たされていれば、複合化は自由にできます。図1は、並行実行のワークフローパターンを示しています。

注意: BPM では、並行実行は、同時には実行されません。同一のスレッドでそれぞれのパスが実行され、まず最初のパスが終了するまで進行し、次に新しいパスに移り、すべてのパスが進行できなくなるか、またはすべてのパスが AND ノードに進む状態になるまで、そのように作業が進行します。開始パスがどれになるかは一定ではありません。

図 1 並行実行パターンの実装
並行パスのサブセットが別のノードで合流する必要がある場合、そのサブセットの起点としてダミーのタスクノードを設定し、そのダミータスクノードは無条件で終了しているものとマークします。これによって、ネストされた並行処理が機能的に作成され、並行実行パスが単独の入口ポイントと出口ポイントを持つ原則が確実に守られます。

図2は、複数のタスクノード、複数の入口ポイントを持つワークフローが、ダミータスクノードを使用することによって、並行実行パスの入口ポイントが 1 つになり、1 つの AND ノードに合流するように変わるしくみを示しています。

図 2 単独の入口ポイントと出口ポイント方式を使って、ネストされた並行処理を作成する
パスが途中で消失するようにすることはできません。後続するパスがないノードにパスがつながっていると、そのパスは消失してしまいます。消失しないように修正するには、そのパスが直接 AND ノードにつながるように線を追加します。図3 の左側の部分は、消失するパスがあるワークフローを示しています。図3 の右の部分は、このワークフローをどのように実装したらよいかが示されています。

注意: 消失するパスは、タイムアウト付きイベントに示されているワークフロー以外、設定できません。

図 3 必ず 1 対の入口ポイントと出口ポイントを持つようにする

イベント選択

「イベント選択」パターンは、1 つのノードから分岐するすべての並行パスが一定のイベントが発生するのを待ち、最初に起きたイベントによって、どのパスが実行されるか決まるものです（図4 を参照）。複数の並行パスのうち、実行されるパスは、どのイベントが最初に発生するかによってただ 1 つだけです（その他のパスはすべて抑止され、発動しません）。実行パスが互いに排他的になることを保証するため、次のガイドラインに示されているようにイベントの取消しアクションを使用します。

図 4 「イベント選択」パターンの実装

「イベント選択」ワークフローパターンを適切に実装するには、以下の手順に従ってください。

1 つのノードから出るすべての並行パスがイベントノードで開始されるようにします。図4 では、3 つの並行パスが [任意のノード] を出て、各パスが 3 つのイベントノードで開始するようになっています。ノードの数は、すべてのノードがイベントノードで開始される限り、必要に応じていくつでも設定できます。
イベントの取消しアクションを使用して、相互排他性が確立するようにします。各イベントノードに定義されたアクションリストには、兄弟イベントノードごとにイベントの取消しアクションを 1 つずつ入れます。

注意: 2 つのノードが同じ親を持つ場合、その 2 つのノードは兄弟となります。
1. イベントの取消しアクションでは、当該ワークフローパターンのイベント兄弟以外のイベントノードは一切取り消さないようにします。このイベントの取消しアクションによって、並行パスの 1 つだけが実行できるようになることが保証されます。このイベントの取消しアクションは、[イベントノード] の [アクション] タブで定義できます。
2. イベントが互いに排他的であることが保証されている場合でも、イベントの取消しアクションを組み込むようにします。そのようにすることにより、移行ツールによるこのワークフローパターンの移行がよりスムーズにできるようになります。
イベントの取消しアクションは、そのイベントノードの [アクション] タブで宣言されている他のどのアクションよりも前に配置します。できれば、イベントの取消しアクション以外のアクションは、タスクノードに配置し、そのノードをイベントノードの後に置くようにしてください。
すべての並行パスが同一の OR ノードに合流するようにします。図4 は、すべての並行パスが同一の OR ノードに合流するパターンを示しています。
実行パスには、複合構成要素（サブ並行処理、ネストされた「イベント選択」パターン、およびループなど）を自由に入れることができます。

タイムアウト付きイベント

「タイムアウト付きイベント」パターンは、互いに排他的なイベントのセットが、一定の時間枠内または期限前に発生する必要がある場合を表しています。タイムアウト前に発生した最初のイベントの実行パスは完了するまで実行され、他のパスはタイムアウトパスも含めて抑止されます。タイムアウト前にどのイベントも発生しない場合は、タイムアウトパスが実行されます。タイムアウト後にイベントが発生しても、対応する実行パスが開始されることはありません。タイムアウトロジックは時限イベントアクションかタスク期日を設定アクションのどちらかを使用すれば実装できますが、タスク期日を設定アクションのほうがより明確でわかりやすい構成になるので、タスク期日を設定アクションを使用することをお勧めします。図5 は、このワークフローパターンの適切な実装形態を示しています。時限イベントアクションを使ったベストプラクティスの説明については、タイムアウト付きイベントを参照してください。

「タイムアウト付きイベント」ワークフローパターンを適切に実装するには、以下のガイドラインに従います。

パスは、1 つを除いて他はすべてイベントノードで開始するようにします。それぞれのイベントノードには、一定のイベントが発生したことを示す変数を設定します。図5 では、2 つのイベントノード、E1 と E2 が示されています。
その唯一の例外パスを開始するノードとして、タスクノードを 1 つ設定します（ここでは「タイムアウトタスク」ノードと呼びます）。タイムアウトタスクノードの後には分岐ノードを設定し、イベントノードで設定された変数値を検査します。図5 では、この分岐ノードは「イベント発生?」という名前になっています。「タイムアウトタスク」ノードを使用するにあたってのガイドラインは、次のとおりです。
1. タイムアウトタスクノードのアクティブ化リストにあるアクションは、タスク期日を設定だけです。このアクションにより、タイムアウトタスクノードの期日が設定されます。タイムアウトタスクノードの実行時リストまたは完了マーク時リストには、どのようなアクションも含まれません。
2. 最後のサブアクション（タイムアウトアクション）では、タイムアウトタスクノードを完了とマークする必要があります。—> 図5 の右側分岐にその使用例が示されています。タスクに完了マークを付けるアクションを使用して、タイムアウト起動後にタイムアウトタスクノードから実行が継続されるようにします。他のサブアクションはあってはなりません。
すべての実行パスが同一の OR ノードに合流するようにします。
タイムアウトが実際に発生したかどうかをチェックします。タイムアウトタスクノードから出るパスは、イベントが発生したかどうかとは無関係に、期日到来によって実行が開始されます。イベントが実際に発生した場合は、タイムアウトパスの実行は停止される必要があります。イベント発生によりそのように停止させるためには、タイムアウトタスクノードの後に分岐ノードを挿入します。この分岐ノードは、イベントによって設定される変数の値を検査します。変数が設定されていれば、イベントが発生済みであることを示しています。その場合、対応する分岐ノードの分岐が消失するようにします。これは、その分岐の次にノードを指定しなければ自然にそのようになります。false の場合、分岐ノードの分岐は次のノードに移るようにします（図5 で「イベント発生?」の分岐ノードの後の分岐を参照）。
タイムアウトが発生したら、他のイベントはすべて取り消します。タイムアウトパスにはイベントの取消しアクションを設定し、イベントが起動することのないようにすべてのイベントを取り消します。できれば、これらのイベントの取消しアクションは分岐ノードの直後のタスクノードに配置してください。図5 は、分岐ノード後に 2 つのイベントの取消し、E1 と E2 がある実装例を示しています。
図 5 「タイムアウト付きイベント」パターンの実装

イベントによる取消し

「イベントによる取消し」パターンは、実行パスが特定のイベントによって取り消される（メッセージ到着により、以前に発注されていた注文を取り消す場合など）場合を表しています。実行パスが実行途中で取り消すことができるかどうかによって、2 つのタイプが考えられます。

中途取消しなし: 実行パスがまだ開始されていない場合、キャンセルイベントにより実行パスの実行が中止されます。実行パスの実行が開始されている場合、キャンセルイベントは無効となり、実行パスは完了まで実行が継続されます。
中途取消しあり: キャンセルイベントは、取消し対象となるパスの実行期間全体にわたって有効となります。言い換えれば、実行パスは、キャンセルイベントを受信したら、実行の途中でも中止できることになります。ビジネスロジックによっては、キャンセルイベント受信前に実行された作業部分を元に戻す（取り消す）ため、一定のクリーンアップ処理が必要な場合があります。

どちらのタイプのほうが実際のビジネスロジックに近いかを判断した上で、選択したタイプを次のガイドラインの提示に従って実装してください。最初の方法、すなわち「中途取消しなし」のタイプのほうが、部分的に完了した作業を取り消すクリーンアップ処理の必要がないため、実装が簡単です。—> 2 番目の方法、「中途取消しあり」はより強力で、取消し対象の実行パスの実行期間が長い場合はこちらの方法が唯一の選択肢ということもあります。

「中途取消しなし」タイプ

図6 は、取消し対象のパスが実行前にキャンセルイベントを受信しない限りパスが実行される場合の、「イベントによる取消し」パターンの推奨される実装を示しています。このタイプを適切に実装するには、次の手順に従ってください。

図 6 「イベントによる取消し」パターンの「中途取消しなし」タイプの実装

キャンセルパスの最初は、キャンセルイベント（CE と表記）を待機するイベントノードにする必要があります。
イベントノードが適切に登録され、キャンセルメッセージの受信によってただちに開始されるようにするには、通常実行パスの最初に短期間実行をブロックする（静止状態を入れる）タスクノードを置きます。静止状態を入れることにより、イベントノードが確実に登録されます。キャンセルイベントが受信されると、それによって取消しを待機していたイベントノードが開始されます。
イベントノードに変数を設定するアクションを追加します。この変数の値は、通常実行パスを継続して実行するかどうかを判断するため、通常実行パスによって静止状態終了後ただちに検査されます。
分岐ノードを、イベントによる取消しの手順 3.に示された変数値を検査するタイムアウトノードの後に追加します。変数が設定された場合、この分岐ノードの true 分岐は、その分岐の次のノードを定義しないことにより、消失するようにします。false 分岐については、通常実行を開始するノードに移るようにします。図6 はこのガイドラインを示しており、「イベント発生?」分岐ノードの後に false 分岐が配置されています。
通常実行パスが実行開始されたら、イベントノードがその後に開始されることはあってはなりません。キャンセルイベントを取り消すイベントの取消しアクションを追加することにより、イベントノードを無効化します。このアクションは、分岐ノードの直後に配置する必要があります。図6 は、分岐ノードの直後のタスクノードとそれに関連付けられたイベントの取消し (CE) アクションを示しています。
どちらのパスも同じ OR ノードに合流させます。

「中途取消しなし」の「イベントによる取消し」は、重要タスクを実行する前に特定のイベントが発生したかどうかをチェックするように設計されたパターンです。このパターンの簡単な例は、受注処理ワークフロー内に見られます（図7を参照してください）。受注処理ワークフロー内のタスクとしては、次のようなものが考えられます。

顧客ステータスのチェック
受注ステータスの実行
注文の有効性チェック

注意: 次の手順に進む前であれば、任意の時点で注文を取り消すことができます。図7 に示されているように、依頼済みの注文の実行を処理する保護タスクのセットより前であれば、キャンセルイベントノードを挿入できます。
注文管理システムに対する注文の実行指示
図 7 受注処理における「中途取消しなし」タイプの例

「中途取消しあり」タイプ

図8 は、「中途取消しあり」タイプの推奨実装を示しています。ただし、このタイプの実装では、クリーンアップロジックが正しく実装されるために、取消し対象の通常実行パスとキャンセルパスとの間により高度な調整が必要です。

一般に、キャンセルパスでは、必要なクリーンアップロジックを実行する必要があります。このクリーンアップロジックは、通常実行パスがどこまで先に進んだかによって異なる可能性があります。通常実行パスの進行度の検出は、通常実行パスに一定の変数を設定し、キャンセルイベントの発生時にキャンセルパスでそれらの変数を検査することにより行なうことができます。同様に、通常実行パスでは、キャンセルパスがアクティブ化したことを検出し、キャンセルパスでは実行されない一定のクリーンアップアクションを実行する必要がある場合があります。作成したワークフローが実際のビジネスプロセスを正確に反映したものになるための適切な調整を実装する作業は、ワークフロー作成者自身が適宜行なってください。クリーンアップ処理は 1 つのパス上で行なうことを推奨します。

図8 は、「中途取消しあり」タイプの実装の骨格だけを示したものです。取消しおよびクリーンアップロジックの詳細は、記載されていません。

図 8 「イベントによる取消し」パターンの「中途取消しあり」タイプの実装

以下の一般的な手順は、このワークフローパターンを適切に実装する方法を示しています。

キャンセルパスの最初は、キャンセルイベント（CE と表記）を待機するイベントノードにする必要があります。
通常実行パスの最初は、12 ページの「「中途取消しなし」タイプ」に示したように、短期間実行をブロックするタスクノードにします。これによって、イベントノードが適切に登録されます。
通常実行パスの最後のアクションでは、イベントの取消しアクションを使用してイベントの取消し（CE）を取り消すことにより、イベントノードを無効化する必要があります。これによって、通常実行パスが実行完了し、OR ノードに到達した以降にイベントノードが起動することがなくなります。図8 では、左側分岐の最後にイベントノードを完了するためのタスクノードを設定してこの処理を行なっています。
どちらのパスも同じ OR ノードに合流させます。キャンセルイベント/メッセージでイベントノードがアクティブ化するのは、任意の時点ではなく、通常実行パスが静止状態に入ったときに限られますので注意してください。そうなっていることにより、通常実行パスが静止状態に入るポイントは普通は少数ですから、クリーンアップロジックが単純化されます。したがって、取り消し/クリーンアップの組み合わせ作業がごく少ない箇所で済みます。

実行タイムアウト

「実行タイムアウト」パターンは、「イベントによる取消し」パターンと似ていますが、パスの実行を取り消す原因はイベントではなくタイムアウトです。図9 は、このワークフローパターンの推奨される実装形態を示しています。

実行タイムアウトパターンでは、タイムアウトが起動した場合の、通常実行パスとタイムアウトパスとの間に一定レベルの調整が必要な場合があります。さらに、複雑なクリーンアップロジックが必要なこともあります（これに関してはイベントによる取消しの節を参照してください）。クリーンアップに必要なワークフローアクションの実装は、ワークフロー作成者自身が行なってください。この節では、このワークフローパターンの実装の骨格のみを示します。

「実行タイムアウト」パターンを実装する場合、以下の手順を実行してください。

タイムアウトパスの最初は、タイムアウトアクションを含むタスクノードにする必要があります。タイムアウトは、時限イベントアクションまたはタスク期日を設定アクションのいずれを使用しても実装できますが、タスク期日を設定のほうがよりわかりやすいコードになるので、タスク期日を設定アクションを使用することをお勧めします。通常実行パスとタイムアウトパスは、これらのパスに含まれる構成要素が単独の入口ポイントと出口ポイントをそれぞれ持つようになっている限り、どちらも自由に複合化することができます。
どちらのパスも同じ OR ノードに合流させます。
タイムアウトパスは、通常実行パスが実行終了したら（すなわち OR ノードに到達したら）、無効化するようにしなければなりません。そのためには、通常実行パスの最後で変数を設定し、分岐ノードをタイムアウトノードの後に置いて、そこでこの変数の値をチェックするようにします。図9 では、「timeout_disabled」という名前のブール変数が実行パスの最後で true に設定されており、この値が分岐ノードでチェックされます。タイムアウトパスが無効化されない場合、タイムアウトパスが進行します。
図 9 「実行タイムアウト」パターンの実装

ワークフローパターンにおけるアクションの使用法

表 1 は、このマニュアルで前述したワークフローパターンに関連するアクションをリストにしたものです。自動移行できるようにワークフローを最適化するには、ワークフローでこれら特定のアクションを使用するときに表 1 に示すガイドラインに従ってください。

注意: 非同期アクションのコールバックアクションリストには、Set Task as Done 以外のアクション（ワークフローを開始など）は定義しないでください。

表1 : ワークフローアクションの使用に関するガイドライン

アクション	使い方
イベントの取消し	このアクションは、イベント選択、タイムアウト付きイベント、またはイベントによる取消しの各パターンの実装時に相互排他性を確立するためにのみ使用する。
タスクに完了マークを付ける	このアクションは、自己に完了マークを付ける場合、またはタイムアウト付きイベントパターンを実装する場合にのみ使用する。
タスクの完了マークを外す	このアクションは使用しないこと。
タスク期日を設定	このアクションは、タイムアウト付きイベントパターンまたは実行タイムアウトパターンのタイムアウトロジックを実装する場合にのみ使用する。
タスクを実行	このアクションは、自己を自動実行する場合にのみ使用する。
OR 結合	OR 結合は、前述のワークフローパターンの実装、または複数の開始ノードの結合にのみ使用する。
AND 結合	AND 結合は、並行実行パターンを実装する場合にのみ使用する。

タスクノードの使用法

WebLogic Integration Studio のタスクノードには、任意の数のアクションを作成時、アクティブ時、実行時、および完了マーク時リストに入れることができます。これらのリストは、WebLogic Integration Studio の [タスクのプロパティ] ダイアログで定義します。 [タスクのプロパティ] ダイアログの詳細については、『WebLogic Integration Studio ユーザーズガイド』を参照してください。

一般に、タスクには次の 2 種類があります。

表2 : タスクの種類

タスク	使い方
ユーザタスク	ユーザに割り当てられているタスク。ユーザタスクは、ユーザまたはロールによって明示的に実行されなければ、実行されることはない。
自動タスク	ユーザの介在が不要なタスク。自動タスクは、通常ユーザの介在なく一連のアクションを実行し、自己に完了マークを付けて次のノードへと実行を進める。

ユーザタスクのガイドライン

ユーザタスクを実装する場合、以下のガイドラインに従ってください。

アクティブ時リストには、事前割り当てタスクを配置します。アクティブ時リストの最後のアクションは、3 つのタスク割り当てアクションのいずれかでなければなりません。それらのアクションは次のとおりです。
Executed リストには、事後割り当てタスクを配置します。これらのアクションは、ユーザが明示的にタスクを実行する場合に実行されます。Executed リストの最後のアクションは、タスクに完了マークを付けるため、タスクに完了マークを付けるアクションにする必要があります。
タスクに関連するアクション（タスクコメントを設定およびタスク期日を設定など）はすべて「タスクの割り当て」アクションの直前に置くようにします。

自動タスクのガイドライン

自動タスクを実装する場合、以下のガイドラインに従ってください。

アクションはすべてアクティブ時リストに配置します。
Executed リストにはアクションを配置しないでください。
アクティブ時リストの最後のアクションは、タスクに完了マークを付けるアクションにして、タスクに完了マークを付ける必要があります。

例外処理

将来バージョンの WebLogic Integration では、構造化された例外処理を使用する予定です。将来の WebLogic Integration 製品リリースにスムーズに移行できるようにするため、例外ハンドラを設定する時に、以下の事項を考慮するようにしてください。

例外ハンドラをワークフローの中ほどに設定する場合、順番的に最も前にあるノードのデフォルトの例外ハンドラに対して後ろになるようにそのハンドラを設定し、設定ノードおよび解除ノードによって、出入りするパスがない適切なブロックが形成されるようにします。次の図、図10 では、この種の例外ハンドラブロックを示しています。一般的に、例外ハンドラがアクティブになる範囲はできるだけ小さくするようにしてください。
タイムアウト付きイベントパターンまたは実行タイムアウトパターンを使用する場合、タイムアウトパス内の例外ハンドラは、変更および追加しないようにします。
イベントによる取消しパターンを使用する場合、例外ハンドラを変更しないようにします。
図 10 例外ハンドラブロックの例

Studio プラグインを使用する場合のガイドライン

WebLogic Integration Studio では、一部のワークフローコンポーネントの機能を拡張するプラグインをサポートしています。プラグインの機能はそのままでも継続しますが、できればカスタマイズしたプラグインに対して EJB を使用して、自動移行ができるようにワークフローを最適化してください。『WebLogic Integration BPM プラグインプログラミングガイド』を参照してください。