BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA
 ドキュメントのダウンロード   サイト マップ   用語集 
検索
e-docs > WebLogic Integration > BPM トピック > BPM クライアント アプリケーション プログラミング > BPM トランザクション モデルの理解

BPM クライアント アプリケーション プログラミング

 前 次 目次 索引 PDFで表示  

BPM トランザクション モデルの理解

この章では、トランザクションが Business Process Management (BPM) アプリケーション内で処理される方法について説明します。内容は以下のとおりです。

トランザクションの概要や、トランザクション処理と EJB (Enterprise JavaBean: エンタープライズ JavaBean) の詳細については、次の URL から WebLogic Server ドキュメント内の『WebLogic JTA プログラマーズ ガイド』を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/jta/index.html

 

トランザクションの開始方法

WebLogic Integration プロセス エンジンによるワークフロー実行の開始または再開をトリガする次の 3 つのアクションでは、新しいトランザクションの開始をマークする場合もあります。

API メソッド呼び出しによって新しいトランザクションも開始されるかどうかは、呼び出し側アプリケーションにおけるトランザクション コンテキストの有無により決定されます。外部トランザクション コンテキストが存在する場合（つまり、アプリケーションが JTA を使用してトランザクションを作成済み、または JTA トランザクションを継承済みの場合）は、WebLogic Integration EJB によってそのコンテキストが使用されます。それ以外の場合は、EJB コンテナによって新しいトランザクションが自動的に作成され、その中で呼び出しが実行されます。Audit EJB 以外の公開 API のすべての EJB メソッドは、TX_REQUIRED トランザクション属性を持つコンテナ管理によるトランザクションを使用します。

XML イベントと時間ベースのイベントの両方は常に新しいトランザクションを開始します。それぞれの場合で、トランザクションが開始されてから、キューからメッセージが出されます。

注意: WebLogic Integration Worklist クライアント アプリケーションは、個々のトランザクション内の Worklist EJB 上のメソッドを呼び出すことで、ユーザ コマンドを実行します。WebLogic Integration Worklist アプリケーション内のタスクを操作すると、内部で各コマンドが実行されるトランザクションが EJB コンテナにより作成されます。たとえば EJB コンテナにより、タスクを実行したり、タスクに完了マークを付けたり、タスクを別のユーザまたはロールに再割り当てたりする、内部で実行されるトランザクションが作成されます。

Worklist クライアント アプリケーションは、このリリースの WebLogic Integration からは非推奨になります。Worklist クライアント アプリケーションに代わる機能については、『WebLogic Integration リリース ノート』を参照してください。

 

トランザクションのコミット方法

トランザクションのコミット方法を理解するには、次を理解する必要があります。

各方法について、この後の節で詳しく説明します。

ワークフロー インスタンスの処理方法

ワークフローを最初にインスタンス化するときは、WebLogic Integration によりワークフロー内のすべてのタスクに 作成時アクションが実行されます。次に、開始ノードが以下のとおり処理されます。

初期インスタンス化の後のトランザクションの進行状況は、テンプレート定義により異なります。アクティブ化イベントは、各ノード タイプに対して定義済みの処理ルールに応じて、起点から始まるパスに沿って外へ向かって伝播されます。

各ノード タイプの処理ルールを次の表に示します。

表7-1 ノード タイプ別の処理ルール

ノード タイプ

処理ルール

分岐

アクティブ化された分岐ノードによってまず条件が評価され、リストにある true アクションまたは false アクションが適宜実行され、最後に true または false サクセサ ノードがアクティブ化される。

完了

アクティブ化された完了ノードによって、すべての完了ノードへの到達とは無関係に、関連付けられているアクションが実行され、現在のワークフローに完了マークが付けられる。

イベント

アクティブ化されたイベント ノードによって前に受信されたアドレス指定メッセージが確認され、メッセージがない場合は、自身が Event Watch テーブルに登録される。アドレス指定メッセージの詳細については、メッセージ配信の保証を参照。

トリガされたイベント ノードによって以下のタスクが順次実行される。

サクセサ ノードのアクティブ化は、各ノード タイプのルールに従って行われる。

結合

いずれかの単一入力パスによりアクティブ化される場合は OR 結合ノードによって OR 条件が評価される。すべての入力パスによってアクティブ化される場合は AND 結合ノードによって AND 条件が評価される。条件が満たされると、結合ノードによってそのサクセサ ノードがアクティブ化される。

開始

アクティブ化された開始ノードによって以下のタスクが順次実行される。

サクセサ ノードのアクティブ化は、各ノード タイプのルールに従って行われる。

タスク

アクティブ化されたタスク ノードによって、 アクティブ時タスクのリストが順次実行される。行われる可能性のある後続アクションをまとめると次のようになる。

 

ワークフロー インスタンスが静止状態になる方法

ワークフローの処理時は、同期実行するアクションがなくなると、コントロールがプロセス エンジンからシステムに戻されます。つまり、ワークフロー インスタンスが静止状態に入り、以下の要求待ちになります。

ワークフロー インスタンスは、以下の条件が true の場合に静止状態に入ります。

プロセス エンジンが最後にトリガされた時点で新しいトランザクションが開始された場合は、静止状態によってトランザクションの最後もマークされます（その結果、トランザクションがコミットされる）。外部トランザクション コンテキストが API 呼び出しトリガの前にエクスポートされた場合は、外部トランザクションが有効なままとなり、コントロールは呼び出し側アプリケーションに戻されます。詳細については、トランザクションの開始方法を参照してください。

あるアクションによってサブワークフローがインスタンス化されると、サブワークフローが静止状態に入るまでに実行するすべてのワークは、呼び出し側ワークフローと同じトランザクション内で実行されます。このワークには、通常、呼び出されたすべての開始ノード内のアクションの実行、各開始ノードと関連付けられているすべてのサクセサ ノードのアクティブ化、および各サクセサと関連付けられているアクションなどがあります。この処理はサブワークフローを介して伝播され、事前定義済みのルールに従って、完了または静止状態になります。サブワークフローの完了へ向けて実行中（つまり、静止状態ではない）の場合は、親ワークフロー内の 完了アクションも同じトランザクション内で実行されます。タスク（たとえば親）に完了マークを付けるアクションが 完了アクションに含まれている場合は、処理が続行され、 完了マーク時アクションが実行され、サクセサ ノードがアクティブ化されます。

 

例外の処理方法

プロセス エンジンによって例外が受け取られた場合、または送出された場合に、トランザクションのコミットとロールバックのどちらが行われるかは次の 2 つの要因によって決定されます。

アクティブな例外ハンドラは、関連付けられている是正措置を実行でき、次のいずれかの処置を指定できます。

ユーザ トランザクションが「ロールバックのみ」に設定されておらず、例外が回復可能であり（つまり、例外がワークフロー警告である場合）、かつアクションの処理中またはイベント変数の設定中に例外が発生した場合は、例外ハンドラが処理結果を決定できます。それ以外の場合は、ユーザ トランザクションが「ロールバックのみ」に自動設定され、アクティブな例外ハンドラが呼び出され、例外が再送出されます。

コンテナによってトランザクションが作成された場合は、コントロールがプロセス エンジンからコンテナに戻されたときにトランザクションがコミットまたはロールバックされます（コントロールは、ワークフロー インスタンスが静止状態になる方法に記載のとおり、ワークフロー インスタンスが静止状態に入った際に戻される）。

アプリケーションが BPM EJB を外部トランザクションに入れ、ユーザ トランザクションを「ロールバックのみ」に設定しない例外がこの EJB によって送出される場合は、トランザクションの動作はアプリケーションによって定義されます。一方で、BPM 呼び出しが正常に終了した場合は、トランザクションが外部アプリケーション（または EJB）によってコミットされるという保証はありません。その結果、例外またはその他のエラー条件が発生することがあり、トランザクション全体がロールバックされます。

XML および時間ベースのイベントの場合、トランザクションがロールバックされると、メッセージはキューに戻されます。指定した再試行回数に達するまで、指定した間隔でメッセージの再配信が試みられます。再試行の最大回数および再試行間隔は、JMSTemplate 要素の Redelivery-Limit 属性および RedeliveryDelayOverride 属性を使用して JMS 送り先ごとに設定できます。たとえば、WebLogic Integration サンプル ドメインの場合、WLI_JMSTemplate は次のように定義されます。

 
<JMSTemplate ErrorDestination="WLI_FailedEvent" 
	Name="WLI_JMSTemplate" 
	RedeliveryDelayOverride="60000" 
	RedeliveryLimit="10"/>

これらの属性の詳細については、次の URL から、『WebLogic Server コンフィグレーション リファレンス』に掲載されている 「JMSTemplate」の要素の説明を参照してください。

http://edocs.beasys.co.jp/e-docs/wls/docs70/config_xml/index.html

 

新しいトランザクションの強制開始方法

現在のワークフロー インスタンスを静止状態にするダミーの タスク アクションを定義することで、新しいトランザクションを強制できます（ワークフロー インスタンスを静止状態にする方法については、ワークフロー インスタンスが静止状態になる方法を参照）。

たとえば、以下のいずれかの タスク アクションを定義することで、ワークフロー インスタンスを強制的に静止状態にできます。

 

トランザクションのサンプル

ビジネス オペレーションがワークフロー インスタンス内で実行されるとき、そのビジネス オペレーションが単一トランザクションまたは複数トランザクションのどちらとして処理されるかは以下の要素により決定されます。

ビジネス オペレーションを単一タスクから構成されるアクションの一部として指定するか、複数タスクから構成されるアクションとして指定するかを定義するワークフローのサンプルを以下の節に記載しています。各サンプルでは、単一トランザクションと複数トランザクションの両方のシナリオを示しています。

サンプル 1 −アクションが単一タスクとして定義されているビジネス オペレーション

最初のサンプルでは、3 つの EJB を個別のビジネス オペレーションとして、または単一タスクから構成されるアクションの一部として実行すると仮定します。タスク プロパティの定義方法に基づいて、3 つのビジネス オペレーションを単一トランザクションまたは複数トランザクションとして処理できます。

単一トランザクション

指定のビジネス オペレーションを単一トランザクションとして処理するよう [タスクのプロパティ] ダイアログ ボックスの [アクティブ時] タブで タスク アクションを定義する方法を次のサンプルに示しています。

図7-1 トランザクション サンプル−単一タスク、単一トランザクション


 

このサンプルでは、すべてのビジネス オペレーションがタスクのアクティブ化時に呼び出され、単一トランザクションとして処理されます。

複数トランザクション

指定のビジネス オペレーションを複数トランザクションとして処理するよう [タスクのプロパティ] ダイアログ ボックスの [アクティブ時] および [実行時] タブで タスク アクションを定義する方法を次のサンプルに示しています。

図7-2 トランザクション サンプル−単一タスク、複数トランザクション


 


 


 

このサンプルでは、ビジネス オペレーション（EJB1 および EJB2）のサブセットがタスク アクティブ化時に 1 つのトランザクションとして呼び出されています。Assign task 摘JB1 to user 屠oe アクションが実行されると、ワークフロー インスタンスが静止状態に入り、次の要求を待ちます。最初のトランザクションに完了マークが付けられ、 実行時アクションが実行されます。次に EJB3 ビジネス オペレーションが別のトランザクションとして呼び出されます。

このサンプルでは、EJB3 の処理中に例外が発生すると、関連付けられている是正措置がアクティブな例外ハンドラによって実行され、行われる処置が指定されます。最初のトランザクションは、第 2 のトランザクションで発生した例外による影響を受けません。詳細については、例外の処理方法を参照してください。

サンプル 2 −アクションが複数タスクとして定義されているビジネス オペレーション

第 2 のサンプルでは、3 つの EJB を個別のビジネス オペレーションとして、または 3 つの個別のタスク内のアクションとして呼び出すと仮定します。ここでも、タスク プロパティの定義方法に基づいて、3 つのビジネス オペレーションを単一トランザクションまたは複数トランザクションとして処理できます。

単一トランザクション

このサンプルでは、以下のワークフロー テンプレートを想定します。

図7-3 トランザクション サンプル−複数タスク、単一トランザクション


 

次の文が true であると仮定します。

これらの文が true である場合、いずれかのビジネス オペレーションの実行前にワークフロー インスタンスは静止状態にはならず、3 つのすべてのビジネス オペレーションが単一トランザクションとして処理されます。

複数トランザクション

このサンプルでは、ダミーの Post XML イベントを定義して静止状態を強制（および新しいトランザクションを強制開始）する方法を示します。新しいトランザクションの強制開始に関する詳細については、新しいトランザクションの強制開始方法を参照してください。

このサンプルでは、以下のワークフロー テンプレートを想定します。

図7-4 トランザクション サンプル−複数タスク、複数トランザクション


 

次の文が true であると仮定します。

これらの文が true である場合、EJB1 と EJB2 が単一トランザクションとして処理され、EJB3 が別のトランザクションとして処理されます。

このサンプルでは、EJB3 の処理中に例外が発生すると、関連付けられている是正措置がアクティブな例外ハンドラによって実行され、行われる処置が指定されます。最初のトランザクションは、第 2 のトランザクションで発生した例外による影響を受けません。詳細については、例外の処理方法を参照してください。

 

ページの先頭 前 次