チュートリアル : Worklist アプリケーションの構築
手順 5. タスク所有者からの解決承認の受信
前の手順では、バグの解決を承認するタスクをバグを作成したユーザに割り当てるロジックをビジネス プロセスで設計しました。その設計では、タスク所有者のみに、バグの解決を承認するための期間を 2 日間与えます。この手順では、予想されるイベントを処理できるようにビジネス プロセスを設計する方法について説明します。
このチュートリアルのシナリオのビジネス ロジックでは、予想される複数のイベントの 1 つをタスク コントロールから受信した場合に、その受信をビジネス プロセスで処理することが求められます。WebLogic Workshop でビジネス プロセスを設計する際に、イベント選択グループを使用して、多数のイベントの 1 つを受信するまでプロセスを待機させるロジックを作成することができます。この手順では、このシナリオに合わせてイベント選択グループを設計する方法を学習します。
この手順で実行するタスクは次のとおりです。
解決承認イベントを処理するためのイベント選択グループの作成
WebLogic Workshop でビジネス プロセスを設計する際に、イベント選択グループを使用して、多数のイベントの 1 つを受信するまでプロセスを待機させるロジックを作成することができます。予想されるイベントのいずれかをプロセスが受信すると、ビジネス プロセスのフローが再開されます。受信したイベントを処理するように、イベント選択グループ内の追加ノードを設計します。実行フローは、イベント選択ノードのいずれかのブランチ、つまり最初に発生するイベントを含んでいるブランチに沿って進行します。
イベント選択グループを作成するには
デザイン ビューに解決承認ビジネス プロセスが表示されていることを確認します。
注意 : WebLogic Workshop で設計するビジネス プロセスにロジックを追加するには、ロジックを表すプロセス ノードをパレットからデザイン ビューのプロセスまでドラッグします。
パレットが WebLogic Workshop に表示されていない場合は、WebLogic Workshop メニューから [表示|ウィンドウ|パレット] を選択してください。
(パレットの [Event Choice]) をクリックし、解決承認ビジネス プロセスまでドラッグして、createAndAssignTask (方法 1、3) または setCompletionDueBusinessDate (方法 2) ノードの直後にドロップします。
デザイン ビューでビジネス プロセスが更新され、次の図のようにイベント選択グループが表示されます。
デフォルトでは、イベント選択ノードが 2 つのブランチとともに作成されます。この手順では、タスク コントロールから 3 つのイベントのいずれかが返されるビジネス シナリオを処理するように、解決承認ビジネス プロセスを設計します。したがって、次に説明するように 3 番目のメッセージ イベント ブランチが組み込まれるようにデフォルトのイベント選択グループを拡張する必要があります。
イベント選択グループのいずれかの をクリックします。追加のメッセージ イベント ブランチが作成されます。イベント選択グループは次のようになります。
これで、イベント選択ノードでは、タスク コントロールから 3 つのイベントのいずれかを受信した場合に、その受信を処理することができます。
ビジネス プロセスがタスク コントロールから受信できるイベントの指定
イベント選択グループの各ブランチの最初のノードでは、1 つのイベントの受信が処理されます。実行時は、イベント選択グループのいずれかのブランチ、具体的には最初に発生したイベントを含んでいるブランチに沿って実行フローが進行します。
このチュートリアルでは、次のイベントを処理するようにメッセージ イベント ブランチを設計します。
タスク所有者によってタスクが完了される。つまり、タスク所有者がバグの解決を承認します。
タスク所有者がバグの解決に反対する。反対する場合は、その理由を記述するドキュメントが添付されている必要があります。
タスク所有者が指定された 2 日間の期間内にタスクに対応しない。つまり、タスクの完了期日が過ぎています。このシナリオでは、2 日以内に反対または承認されなかったバグは承認されたと見なされます。
メッセージ イベント ブランチを設計するには、タスク コントロール (taskCtrl) でコールバック メソッドを指定し、それによってイベント選択グループの各ブランチの冒頭にコントロール受信ノードを作成してこのメソッドにバインドします。この手順は、次のとおりです。
必要に応じて、データ パレットの [コントロール] タブで taskCtrl コントロールの隣にある [+] をクリックして、利用可能なメソッドのリストを展開します。
void onTaskCompleted(XmlObject response)
次にこのメソッドをイベント選択グループまでドラッグし、左端にあるメッセージ イベント ブランチにドロップします。これによって、コントロール受信をそのブランチの開始イベントとして指定し、さらに onTaskCompleted コールバック メソッドをそのコントロール受信ノードにバインドします。デザイン ビューでイベント選択ノードが更新され、変更が反映されます。
上の手順をあと 2 回繰り返しますが、今度は次のコールバック メソッドを選択して、taskCtrl コントロールからデータ パレットにドラッグ アンド ドロップします。
void onTaskOverdue(Date time)
void onTaskAborted(XmlObject response)
この手順が完了すると、デザイン ビューのイベント選択グループが次の図のようになります。
これで、タスク コントロールから生成されるイベントの指定が完了しました。
解決承認プロセスによるコールバック イベントの処理方法の設計
実行時に、解決承認ビジネス プロセスはタスク コントロールからイベントを受信するまでブロックされ、イベントを受信すると再開されます。実行フローは、イベント選択グループのいずれかのブランチ、つまり最初に発生するイベントによって開始されるブランチに沿って進行します。
バグの解決が承認されるシナリオに合わせて設計するには
onTaskCompleted ノードまたは onTaskOverdue ノードに追加の設計は必要ありません。実行時にこれらのメッセージ イベントのいずれかが受信されるたびに、ビジネス プロセスがイベント選択グループを抜けてプロセスの次のノードへと進みます。この手順で設計する次のノードは、クライアントに承認メッセージを送信するクライアント応答ノードです。このノードの後にビジネス プロセスの終了をマークする完了ノードが続きます。
クライアント応答ノードを作成するには、次の手順を実行します。
パレットの (Client Response) をクリックし、これを要求承認ビジネス プロセスまでドラッグして、イベント選択グループの直後で、かつ完了ノードの直前にドロップします。
ノードの名前を Client Response
から Resolution Approved
に変更します。
Resolution Approved ノードをダブルクリックし、そのノード ビルダを開きます。
[一般的な設定] タブの [メソッド名] フィールドを clientResponse
から approved
に変更します。
ノード ビルダの右上の [X] をクリックします。ノード ビルダが閉じます。
Resolution Approved ノードについては、それ以上の指定は必要ありません。このチュートリアルのシナリオのビジネス ロジックでは、バグの解決が承認された結果としてドキュメントをクライアントに送信することが要求されません。
バグの解決が反対されるシナリオに合わせて設計するには
SoftCo 社のビジネス シナリオでは、反対する場合にその理由を記述するドキュメントを添付することが要求されるため、onTaskAborted メッセージ イベントが受信された場合の新たなロジックをプロセスで設計する必要があります。この節では、タスク所有者がバグの解決に反対した場合の実行フローを定義するイベント選択グループの onTaskAborted ブランチを設計する方法について説明します。この節で説明する手順は、以下のとおりです。
onTaskAborted メッセージ イベント ブランチを設計するには
onTaskAborted ノードをダブルクリックし、そのノード ビルダを開きます。ノード ビルダを開くと、[一般的な設定] タブが表示されます。コントロール インスタンスとターゲット メソッドはすでに選択されています。
方法 1、2 — TaskCtrl と void onTaskAborted(XmlObjectResponse)
方法 3 — customTaskCtrl と void onTaskAborted(XmlObject response)
実行時にタスク コントロールから返されるドキュメント (反対の理由が記載されたもの) が割り当てられる変数を作成します。
[割り当てる変数を選択します] で、ドロップダウン リストの矢印をクリックし、[変数の新規作成...] を選択します。[変数を作成] ダイアログ ボックスが表示されます。変数タイプとして XML が選択されています。
[変数名] フィールドに appealXML
と入力します。
[OK] をクリックします。新しい変数 (XmlObject 型) が作成され、[データの受信] タブに表示されます。
ノード ビルダを閉じるには、右上の [X] をクリックします。
実行時に、タスク所有者から返されたバグの解決に反対する理由を記述したドキュメントが、appealXML 変数に割り当てられます。
SoftCo 社のビジネス シナリオのロジックを設計する最後の手順は、反対の理由が記載されたドキュメントをクライアントに返すノードをビジネス プロセス内で定義することです。このクライアントは解決承認ビジネス プロセスを開始したリソースと同じです。
onTaskAborted メッセージが発生した場合のクライアント応答を設計するには
パレットの (Client Response) をクリックし、要求承認ビジネス プロセスまでドラッグして、イベント選択グループの onTaskAborted ノードの直後にドロップします。
ノードの名前を Client Response
から Resolution Appealed
に変更します。
次の図のように、デザイン ビューでビジネス プロセスが更新されます。
イベント選択グループの Resolution Appealed ノードをダブルクリックし、そのノード ビルダを開きます。
[一般的な設定] タブの [メソッド名] フィールドを clientResponse1
から appealed
に変更します。
[追加] をクリックします。使用可能なデータ型を示すパネルが表示されます。
前のノード (onTaskAborted) でタスク コントロールからビジネス プロセスに返された反対メッセージは、(未タイプの) XML メッセージです。したがって、このノードには XML を使用する必要があります。
必要に応じて、[未タイプ] の隣にある [+] をクリックして、プロジェクトで利用可能な未タイプの XML オブジェクトのリストを展開します。
[名前] フィールドで、デフォルトのパラメータ名 (x0
) を appealXML
に置き換えます。
[OK] をクリックします。指定したパラメータ設定が、ノード ビルダの [一般的な設定] タブに表示されます。パラメータ型は XmlObject、パラメータ名は appealXML です。
[データの送信] タブをクリックします。デフォルトでは、[データの送信] タブを開くと [変数の割り当て] ペインが表示されます。
[割り当てる変数を選択します] で、ドロップダウン リストから appealXML (XMLObject) を選択します。
ノード ビルダを閉じるには、右上の [X] をクリックします。
この手順で、解決承認ビジネス プロセスによってクライアントにエクスポーズされるコールバック メソッドの指定が完了します。
onTaskAborted ブランチで、Resolution Appealed ノードの直後に完了ノードを追加します。
これによって、実行時に、ビジネス プロセスを起動したクライアントに appealXML ドキュメントが送信された直後にビジネス プロセスが終了するように指定します。
デザイン ビューでは、完成した解決承認プロセスが次の図のように表示されます。
[ファイル|すべて保存] を選択します。作業内容が保存されます。
これで、イベント選択グループおよび解決承認ビジネス プロセスの設計が完了しました。WebLogic Workshop のブラウザベースのインタフェースを使って、作成したビジネス プロセスの機能を実行してテストするには、「手順 6. 解決承認ビジネス プロセスの実行」に進みます。