| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Integration > BPM トピック > WebLogic Integration Studio ユーザーズ ガイド > アクションの定義 |
|
WebLogic Integration Studio ユーザーズ ガイド
|
アクションの定義
この章では、WebLogic Integration アクションを使用して各種ワークフロー アクティビティを遂行する方法について説明します。
アクションの概要
ビジネス プロセスの論理的順序と制御を指定するにはノードとコネクタが使用されますが、ワークフロー定義の実際の作業を実行するのはアクションです。アクションは、何らかのアクティビティを実行できる最も基本的なワークフローの単位です。このアクティビティには、変数の初期化のような単純なものから、クライアント システム上でカスタム アプリケーションを呼び出すような複雑なものまであります。アクションは、すべてのタイプのノード（結合ノードを除く）、例外ハンドラ、および他のアクションに追加できます。
以下の節では、ワークフローでアクティビティを実行するためにアクションを使用する場合の重要な基礎情報を示します。構成は以下のとおりです。
アクション カテゴリ
Studio では、アクションはいくつかのカテゴリに分類されます。ただし、このガイドでは、実行できる主要アクティビティにアクションを分類します。次の表に、カテゴリ、カテゴリに含まれるアクション、実行されるアクティビティおよびこのガイドで詳細に説明されている節をリストします。
アクション タイプと配置を理解する タスク、ワークフロー、統合、例外処理、その他の Studio により表わされるアクション カテゴリだけでなく、アクションとその動作の間に存在する以下のような区別も知っておく必要があります。
これらは、ワークフロー オペレーションが実行される順序に影響することがあるため、その区別は重要です。それぞれの区別の詳細について、以下の節で説明します。
端末アクションと非端末アクション
大部分のアクションは端末アクションです。つまり、アクションの中に他のアクションを含めることはできません。一方、一部のアクションは、その内部にサブアクションを定義できます。サブアクションは、親アクションの性質に応じて特定の条件に従って実行されます。以下のアクションは、その内部で定義されるサブアクションを持つことができるため非端末アクションです。
このような非端末アクションの場合、サブアクションは [プロパティ] ダイアログ ボックスにのみ表示され、フォルダ ツリーには表示されません。
非端末アクションに関する特記事項として、大部分の端末アクションは常に同期方式で実行される、つまりワークフローは端末アクションの実行が終了するまで待機しますが、非端末アクションは同期方式または非同期方式のどちらでもオペレーションを実行できます。非端末アクションの非同期的実行とは、ワークフローがアクションまたはそのサブアクションのオペレーションの完了を待たずに先に進み、並行して処理を続けることです。以下で、この区別について詳しく説明します。
アクションの同期的実行と非同期的実行
すべてのアクションは同期的です。ワークフローは現在のアクションにより実行されているオペレーションが完了するまで次のアクションに進みません。ただし、以下の例外があります。
ただし、以下のアクションと、それに含まれるすべてのサブアクションは、アクションがどのように配置されているかに応じて同期方式または非同期方式のいずれかで実行できます。
上記の非端末アクションとそのサブアクションは以下の条件で非同期的に実行されます。
図6-1 [タスクのプロパティ] から完了マークを付けられたタスクを持つタスク ノードの非端末アクション
上記の場合、アクションのオペレーションおよび指定されたサブアクションは、ワークフロー内の後続のノードで並行実行されます。これを次の図に示します。
図6-2 ワークフロー アクションの非同期的実行
一方、非端末アクションとそのサブアクションは、アクションのプロパティでそれらのアクションの置かれているタスク ノードに完了マークが付けられている場合、同期的に実行されます。これを次の図に示します。 図6-3 [アクションのプロパティ] で完了マークが付いたタスクを持つ非端末アクション
つまり、ワークフローは次の図に示すように、すべてのオペレーションとサブアクションが完了するまで待ってから次のノードに進みます。 図6-4 ワークフロー アクションの同期的実行
アクション設計問題に関する詳細については以下のトピックを参照してください。
タスクに完了マークを付ける方法の詳細については以下の節を参照してください。
タスク ノードにアクションを置く
タスク ノードを使用する場合、特定のアクティビティを実行するために、アクションをどのように置くことがよいか知っておく必要があります。そのためには、まず、[タスクのプロパティ] ダイアログ ボックスの適切なタブ（[アクティブ時] または [実行時]）にアクションを置き、次に適切なポイントでタスクに完了マークを付けます。[タスクのプロパティ] ダイアログ ボックスの各タブの詳細については、タスクの状態を理解するを参照してください。
[アクティブ時] タブと [実行時] タブを使用する
タスクは以下の方法でのみ実行されます。
したがって、一般的にはアクション配置を考える場合に以下のガイドラインに従います。
[タスクのプロパティ] ダイアログ ボックスの各タブを使用して、このガイドで説明する主なアクティビティを実行する場合のガイドラインをまとめた詳しい表は、タスク ノードでのアクション配置に関するガイドラインにあります。
タスクに完了マークを付ける
すべてのタスクには完了マークを付ける必要があります。これは、タスクに対して実行せずに完了マークを付けるパーミッションが割り当てられている場合は Worklist またはカスタム クライアント ユーザにより手動で（詳細についてはタスク パーミッションについてを参照）、あるいはタスクに完了マークを付けるアクションを使用することにより設計時に明示的に行います。
タスクに完了マークが付けられていない場合、ワークフローはタスク ノードから先に進みません。逆に、[タスクのプロパティ] ダイアログ ボックスでタスクに完了マークを付けるアクション以降にリストされたアクションは、[タスクのプロパティ] ダイアログ ボックスの [完了マーク時] タブに置かれている場合を除き実行されません。
注意: 同様に、非端末アクションの場合、[アクションのプロパティ] ダイアログ ボックスの [タスクに完了マークを付ける] アクション以降に置かれたアクション（アクションの同期的実行と非同期的実行に説明）は実行されません。
タスクに完了マークを付けるために使用できる一般的ガイドラインは以下のとおりです。
図6-5 実行されないタスクに完了マークを付ける
図6-6 実行されるタスクに完了マークを付ける
[タスクのプロパティ] ダイアログ ボックスの各タブを使用して、このガイドで説明する主なアクティビティを実行する場合のガイドラインをまとめた詳しい表は以下の節にあります。
タスク ノードでのアクション配置に関するガイドライン
通常はタスク ノードにのみアクションを置き、他のタイプのノードでアクションを使用することは避けてください。また、少数のタスク ノードに長いアクション リストを置くよりも、短いアクション リストを多数のタスク ノードに置くようにしてください。浅いまたはフラットな設計アプローチを使用すると、グラフィック表現の中で、ワークフローのロジックやトランザクション単位を一目で把握できます。
ただし、場合によっては、同じノードに複数のアクションを指定しなければならないこともあります。たとえば、ユーザに割り当てられるタスクにさまざまなプロパティを指定する必要がある場合などです（詳細については、手動タスクの設定を参照）。同様に、タスク以外のノードにアクションを追加する方が効率的な場合や、新たなタスク ノードを作成してグラフィカル フローを複雑にするよりも、1 つのタスク ノードにアクション リストを置く方が効率的な場合もあります。たとえば、変数値の設定、タスクまたはワークフローのコメントの設定、監査エントリの作成のような単純なアクティビティの場合が該当します。
次の表に、主な一般的アクティビティを実行する再利用可能なノード パターンを設計する場合の参考となるガイドラインを示します。
アクション定義タスクの概要
ワークフローを作成し、必要なリソースをコンフィグレーションした後、ノードなどのオブジェクトにアクションを追加できます。アクションの追加と定義は反復的プロセスです。新しいノードを追加する、新しい変数を作成する、データとリソースを再コンフィグレーションする、XML ドキュメントを定義するなどのタスクが必要です。アクションの定義には次のタスクが関係します。各タスクはどの順序で実行してもかまいません。
注意: 大部分のアクションでは、ダイアログ ボックス フィールドに式の入力が必要になるため、アクションの定義を開始する前に、ワークフロー式言語および Studio のツールである Expression Builer と XPath Wizard の学習も必要です。ワークフロー式に関する詳細については、ワークフロー式の使用法を参照してください。
アクションの操作
アクションの追加および更新は、[タスク]、[分岐]、[イベント]、[完了]、[開始のプロパティ] の各ダイアログ ボックス、ならびにカスタム例外ハンドラ、および端末アクションと非端末アクションにリストされた [アクションのプロパティ] ダイアログ ボックスで行います。各ダイアログ ボックスには、アクションの配置と保守のために使用する [アクション] タブがあります。この節では、すべてのアクションに共通な機能について説明します。
アクションを追加する
アクションを追加する手順は、以下のとおりです。
アクションを更新する
アクションを更新する手順は、以下のとおりです。
アクションを削除する
アクションを削除する手順は、以下のとおりです。
アクションをコピーする
ワークフロー ノードの内部または相互間で、あるいはワークフロー テンプレート定義（およびテンプレート）の内部または相互間でアクションをコピーすることにより、再利用可能な設計パターンを作成できます。アクション内で定義されたプロパティもコピーされるので、アクションをわずかに変更するだけで済み、時間を節約できます。
注意: テンプレート定義間でアクションをコピーする場合は、そのアクションが参照する変数がコピー先のテンプレート定義内にすでに作成されていること、およびその他の参照オブジェクトであるロール、ユーザ、ビジネス カレンダーなどが、そのテンプレートと関連付けられているオーガニゼーションについて定義されていることを必ず確認してください。
ノード内またはノード間でアクションとそのプロパティをコピーする手順は、次のとおりです。
アクションの順序を変更する
アクションは実行される順序で表示されます。アクションの順序を変更するには、[プロパティ] ダイアログ ボックスのリストからアクションを選択し、上矢印または下矢印を押してリスト内での位置を移動してください。
アクションへコメントを追加する
すべてのアクションの [プロパティ] ダイアログ ボックスには、アクションに関するコメントを入力できる [メモ] テキスト ボックスがあります。これは、同じワークフローにアクセスする他のユーザが、そのワークフローのロジックや設計を理解する必要のある場合に役立ちます。
図6-8 [メモ] テキスト ボックス
変数値の設定
どのタイプのノードについても、ワークフローのどこかのポイントで既存のワークフロー変数に値を割り当てるには、ワークフロー変数を設定アクションを使用します。たとえば、ループを設計するには、このアクションを使用してカウンタをインクリメントできます。変数の定義方法の詳細は、変数に関する作業を参照。
変数に対して割り当てる値は、式または定数にできます。式は、アクションの実行時に評価され、結果は指定された変数に割り当てられます。
このアクションを使用して、既存の XML ドキュメントの作成やインポートおよび XML または文字列型の変数への定数の格納を行うこともできます。この後、その変数を再利用して XML イベント アクションのポストなどのために、ワークフローのさまざまな場所でこの XML の内容を参照できます（JMS トピックまたはキューへの XML メッセージのポスト参照）。
注意: 非 XML 変数の場合、開始ノード、イベント ノード、[XML をクライアントに送信]、[例外ハンドラのプロパティ] の各ダイアログ ボックスの [変数] タブを使用しても変数値を設定できます。
図6-9 [ワークフロー変数を設定] ダイアログ ボックス
プログラム フローの制御
通常は、プログラム フローを制御するにはノードとコネクタを使用してください。ただし、場合によってはノード内から代替実行パスを指定しなければならないこともあります。たとえば、ワークフローの特定のノードまでに限ってトリガを許可し、それ以降は禁止するようなイベントを定義することがあります。あるいは、条件に応じて別のノード内から自動的にタスクを実行しなければならないこともあります。最も重要なことは、タスクに完了マークを付けるアクションの位置により、サブアクションあるいはサブワークフロー全体を同期的に実行するか、非同期的に実行するかを制御できることです。
したがって、以下のアクションをプログラム制御のために使用できます。
タスクに完了マークを付ける
ユーザに割り当てられたタスクの定義で、ユーザが実行時にタスクに手動で完了マークを付けることを許可されている場合を除き（タスクのプロパティを定義するを参照）、すべてのタスク ノードには、その [タスクのプロパティ] ダイアログ ボックス、または非端末アクションの [アクション] タブのいずれかでタスクに完了マークを付けるアクションを指定しておく必要があります。このアクションの使用法の詳細については、アクション タイプと配置を理解するを参照してください。
図6-10 [タスクに完了マークを付ける] ダイアログ ボックス
タスクから完了マークを外す
タスクの完了マークを外すアクションは、タスクが完了していないものとしてマークします。このアクションを割り当てられたタスクは、Worklist でアクティブになり再度実行できます。ループや並行ワークフローなどで、タスクを再度実行できるようにするには、このアクションを使用してください。
注意: 完了していないものとしてマークされたタスクは、再度トリガされて起動状態にはなりません。タスクを起動状態にトリガするには、ワークフローでタスクを再度開始する必要があります。タスク状態の詳細については、タスクの状態を理解するを参照してください。
図6-11 [タスクの完了マークを外す] ダイアログ ボックス
ワークフロー イベントをキャンセルする
ワークフロー内で定義された 1 つまたは複数のイベント ノードをキャンセルする場合は、ワークフロー イベントを取消しアクションを使用してください。このアクションは、ワークフローの特定のポイント以降イベントがトリガされないようにするため、イベント ノードの終了メカニズムとして使用できます。たとえば、注文処理ワークフローで、顧客からのキャンセル通知を待つイベントがあり、その結果に応じて何らかのアクションを実行するとします。出荷後に注文のキャンセルを発行できないようにするには、ワークフローで出荷タスクが実行されるポイントでワークフロー イベントを取消しアクションを定義し、注文キャンセル イベントのトリガを禁止できます。
図6-12 [ワークフロー イベントを取消し] ダイアログ ボックス
ワークフローに完了マークを付ける
ワークフローに完了マークを付けるアクションは、現在のワークフローに完了マークを付け、ワークフローが完了ノードに到達したのと同じ状態にします。これは分岐ノードにおいて、完了ノードより前のすべてのアクションをスキップし、そのポイントでワークフローを終了したい場合などに使用できます。
図6-13 [ワークフローに完了マークを付ける]
ワークフローを中断する
ワークフローを中断アクションは、現在処理中のワークフローを恒久的に停止します。このアクションは、インスタンスを終了しなければならない例外的な状況で使用できます。
注意: 中断されたワークフロー インスタンスは、データベースから削除され、モニタできなくなります。ワークフローを終了させてもインスタンスのレコードは保持したい場合は、完了ノードまたは [ワークフローに完了マークを付ける] アクションを使用してください。
図6-14 [ワークフローを中断] ダイアログ ボックス
タスクを自動実行する
タスクを実行アクションを使用して、ユーザではなくワークフローにワークフロー内のタスクを明示的に実行させることができます。このアクションによって、タスクのステータスは実行済みになり、[タスクのプロパティ] ダイアログ ボックスの [実行時] タブに一覧表示されているすべてのアクションが実行されます。タスク状態の詳細については、タスクの状態を理解するを参照してください。
このアクションを使用して、たとえば、例外ハンドラ内から例外ハンドラのアクションの完了後にタスク ノードのアクションを再実行させることができます。あるいは、グラフィックに表現するのが難しいループを作成するためにも使用できます。
図6-15 [タスクを実行] ダイアログ ボックス
プレースホルダ アクションを追加する
処理なしアクションはワークフローには影響しません。後でアナリストがアクションの追加を忘れないようにするためのプレースホルダとしての役割だけです。
図6-16 [処理なし] ダイアログ ボックス
時限オペレーションの使用法
以下のアクションにより時限オペレーションを設定できます。
時限シーケンスを埋め込む
時限イベント アクションを使用して、正確な日時にトリガされる時限アクションのシーケンスを作成できます。必要に応じて指定されたスケジュールに従って再実行することもできます。
実行スケジュールについて
時限イベントを再スケジューリングする場合、2 つのオプションに従って実行停止メソッドを指定する必要があります。
非同期的および同期的にトリガされたアクションを実行する
時限シーケンスに指定されたアクションは、同期モードまたは非同期モードのいずれでも実行できます。非同期モードではサブアクションは並行実行され、その間にワークフローは次のノードに進みます。この方法でアクションを設定するには、タスク ノードで時限イベントを使用し、タスク ノード自体で、または他のタイプのノードで、アクションの入っているタスクに完了マークを付けます。
同期モードでは、このアクションを使用してワークフローで時間遅延の作成ができます。ワークフローは、トリガ日時に達するまで待ってからサブアクションを実行し、その後、先に進みます。この方法でアクションを設定するには、タスク ノードでアクションを使用し、[時限イベント] ダイアログ ボックスの [トリガ時のアクション] タブに[タスクに完了マークを付ける] アクションを追加します。
どの場合でも、時限イベントを再スケジューリングするには、ワークフローが完了した場合に限り実行を停止してください。
図6-17 [時限イベント] : [イベントのトリガ] タブ
時限イベントを定義する 時限イベントを定義する手順は、以下のとおりです。
サブワークフローの使用法
一部のアクションではサブワークフローを指定できます。これは設計領域に表示されません。そのようなサブワークフローについて以下で説明します。
注意: イベント トリガされたワークフローを開始する XML メッセージを内部 JMS キューに対してポストすることにより、サブワークフローを呼び出すこともできます。詳細については、JMS トピックまたはキューへの XML メッセージのポストを参照してください。
サブワークフローを呼び出す
大きく複雑なワークフローを複数の部分に分割するために、プロセスを複数のワークフローで構成したい場合や、特定の条件に従ってのみ呼び出されるプロセスのためにサブワークフローを使用する場合があります。
ワークフローを開始アクションを使用することにより、現在のワークフローから別のワークフローを開始できます。開始されるワークフローはサブワークフローと呼ばれます。呼び出されるワークフローまたは子ワークフローと呼ばれることもあります。サブワークフローを開始する側のワークフローは、呼び出し側のワークフローまたは親ワークフローと呼びます。
ワークフローを呼び出すには、Called Start ノードを含み、アクティブとしてマークされ、現在有効な開始日および終了日を指定しているテンプレート定義が、ワークフロー テンプレートに少なくとも 1 つ入っている必要があります。そのワークフロー テンプレートの中の 1 つのワークフロー テンプレート定義のみを開始できます。これは、アクティブなワークフロー テンプレート定義の中で最も有効的な定義だからです。詳細については、テンプレート定義に関する作業を参照してください。
パラメータを引き渡す
サブワークフローに入力パラメータとして定義された変数がある場合、その変数には親ワークフローから受け取った値が入れられます。したがって、ワークフローを開始アクションのプロパティで、サブワークフローに入力パラメータとして渡す値を指定する必要があります。通常、値は親ワークフローに定義された、対応する変数から取られます。
同様に、サブワークフローに出力パラメータとして定義された変数がある場合、サブワークフローの取得または計算した値が親ワークフローに戻されます。この場合も、ワークフローを開始アクションのプロパティで、結果の値を受け取る親ワークフロー変数を指定する必要があります。
サブワークフローを非同期的または同期的に実行する
ワークフローを開始アクションは、同期モードおよび非同期モードのいずれでもワークフローを開始するために使用できます。同期モードでは、呼び出し側ワークフローは、サブワークフローの処理完了を待ってから次のノードに進みます。この方法でアクションを設定するには、開始ノードまたは分岐ノードでワークフローを開始アクションを使用するか、またはタスク ノードにおいて、タスク ノードではなくワークフローを開始アクションのサブアクションとしてタスクに完了マークを付けます。
非同期モードでは、呼び出し側ワークフローは呼び出されたワークフローの完了を待たずに次のノードに続くため、両方のワークフローが並行実行されます。この方法でアクションを設定するには、タスク ノードでアクションを使用し、タスク ノード自体でタスクに完了マークを付けるか、または分岐、開始、イベントのような他のタイプのノードでアクションを使用します。
注意: 内部 JMS キューに XML メッセージをポストして、イベント トリガされるワークフローをトリガすることによっても、別のワークフローを非同期的または同期的に実行できます。パラメータの引き渡しなど、2 つのワークフロー間の相互作用は、XML/JMS メッセージングにより行われ、実行の制御は、親ワークフローのイベント ノードを使用して、サブワークフローから戻される応答を受け取ることにより行われます。実際、クラスタ化環境で WebLogic Integration を実行している場合、この方法の方が負荷バランスをよく制御できます。詳細については、JMS トピックまたはキューへの XML メッセージのポストを参照してください。
親ワークフローがサブワークフローの完了を待ってから先に進むかどうかにかかわらず、呼び出されたワークフローの完了時に実行する任意のサブアクションのセットを定義しておくこともできます。
サブワークフローをトラッキングする
呼び出し側ワークフローで定義された変数に、呼び出されたワークフロー インスタンスの ID を割り当てることができます。インスタンス ID は文字列として戻されるため、文字列型として定義した変数を作成してください（その手順については、変数に関する作業参照）。呼び出し側ワークフローは、WorkflowVariable() を使用して式の中で参照変数を使用することにより、呼び出されたサブワークフローから変数を取り出すことができます。WorkflowVariable() 関数でのインスタンス ID の使い方の詳細については、実行時のワークフロー データを収集するを参照してください。
図6-19 [ワークフローを開始] ダイアログ ボックス
図6-20 [パラメータを設定] ダイアログ ボックス
図6-21 [結果から変数を設定] ダイアログ ボックス
条件付きシーケンスを埋め込む
条件を評価アクションは、分岐ノードと同じ方法で機能します。つまり、実行時に条件式を評価し、その結果に応じてサブアクションの代替シーケンスを実行します。通常、このタイプのフローを実行するには、分岐ノードを使用してください。ただし、そのワークフローの独立したノードとしてではなく、別のノード内にアクションの条件付きセットを指定することにより行われる方法で、メイン ワークフロー内に条件付きサブワークフローを埋め込む場合もあります。これは、例外ハンドラの中など、条件を指定する他の方法がない場合に必要となります。
条件が True と評価された場合に実行する一連のアクション条件が False と評価された場合に実行する一連のアクション、またはその両方を定義します。
図6-22 [条件を評価] ダイアログ ボックス
実行時状態のモニタリング
ワークフロー モニタリングのために 2 つのアクションを使用できます。
監査エントリを作成する
WebLogic Integration には、主要なすべてのユーザとのやりとりおよび変更を、JMS トピック、およびサーバ上のアクティブな WebLogic Integration ドメインのログ ディレクトリにある myserver.log に対して記録するデフォルト監査機能があります。
ワークフローのどのノードでも、監査エントリを作成アクションを使用して、ワークフローの実行中に監査ログに記録する実行時ワークフロー情報を追加定義できます。各エントリの日時が記録されるため、ユーザは実行時に記録したいデータを提供する式を定義します。それには、変数、関数、定数を含めることができます。たとえば、ロールに対して割り当てられたタスクで CurrentUser() 関数を使用することにより、それを実行したユーザを記録できます（実行時ワークフロー情報を戻す関数については、実行時のワークフロー データを収集するを参照）。
注意: このアクションを有効にするには、ワークフローの [テンプレート定義のプロパティ] ダイアログ ボックスで監査をオンにする必要があります。詳細については、ワークフロー テンプレート定義を作成するを参照してください。
図6-23 [監査エントリを作成] ダイアログ ボックス
ワークフロー コメントを設定する
ワークフロー コメントを設定アクションを使用すると、ワークフロー インスタンスにコメントを指定できます。コメントは、アクションが実行された際に、Studio の [ワークフロー インスタンス] ダイアログ ボックスの [コメント] カラムに表示されます（詳細については、ワークフロー インスタンスの操作を参照）。一般的に、このコメントは情報の提供を目的とするもので、その時点でのワークフローのステータスを示します。
図6-24 [ワークフロー コメントを設定] ダイアログ ボックス
手動タスクの設定
手動タスクを割り当てるため、または WebLogic Integration Worklist あるいはカスタム クライアント アプリケーションのユーザと対話するために、以下のタスク アクションを使用できます。
タスク アクションの配置に関するガイドライン
手動タスクを割り当てる場合、アクション配置について以下のガイドラインに従ってください。
タスクをユーザに割り当てる
個々のユーザに指定されたタスクを割り当てるにはユーザにタスクを割り当てアクションを使用します。ユーザにタスクを割り当てると、Worklist またはカスタム クライアント アプリケーションからタスクをビューおよび実行するユーザに通知が送信されます。Worklist アプリケーションの詳細については、『WebLogic Integration Worklist ユーザーズ ガイド
』を参照してください。タスクを割り当てる特定のユーザの指定、あるいはロール メンバーの指定ができます。その場合、システムにより、実行時に特定のロールに属するすべてのユーザの中で保留中タスク数が最小のユーザが決定されます。その後、そのユーザにタスクが割り当てられます。ユーザまたはロールは、定数として指定したり、実行時に提供されるワークフロー式から取得したりできます。
図6-25 [ユーザにタスクを割り当て] ダイアログ ボックス
ロールに対するタスクを割り当てる
特定のユーザに対するタスクの割り当てを希望しない場合は [ロールにタスクを割り当て] アクションが使用できます。ロールに対してタスクを割り当てることにより、そのロールに属するどのユーザでもタスクをビューおよび実行できますが、Worklist でのタスクの明示的通知はありません。
ロールに対してタスクを割り当てるには、ロール名を指定するか、実行時にロールを決定する式を指定します。
図6-26 [ロールにタスクを割り当て] ダイアログ ボックス
ルーティング テーブルによりタスクを割り当てる
条件のセットに応じて、別のユーザまたはロールにタスクを割り当てることができます。ルーティング テーブルは、任意の数のルーティング条件のシーケンスからなっています。ルーティング条件には、タスクを割り当てるユーザまたはロールの候補、および割り当てが行われる条件を指定します。実行時にこのアクションが実行されると、True という結果が得られるまで条件が 1 つずつ評価されます。True という結果が得られると、該当するユーザまたはロールにタスクが割り当てられて、後続の条件は無視されます。
注意: どのルーティング条件も満たされない場合は、実行時例外が発生します。
特定の条件によって行う代わりに、一定期間だけ特定のユーザまたはロールにすべてのタスクをルーティングする場合は、オーガニゼーションのためのルーティング仕様を作成します。詳細については、タスク ルーティングの管理を参照してください。
注意: ルーティング機能では、ユーザに割り当てられたタスクのみ再ルーティングされ、ロールに割り当てられたタスクは再ルーティングされません。再ルーティングされたタスクは、別のユーザ、ロールのユーザ、またはロールに送ることができます。ロールに割り当てられたタスクの再ルーティングについてはロールに対するマッピングを変更するを参照してください。
図6-27 [ルーティング テーブルを使用してタスクを割り当て] ダイアログ ボックス
ルーティング テーブルを使ってタスクを割り当てる手順は、次のとおりです。
図6-28 [ルーティング条件を定義] ダイアログ ボックス
タスク期日を設定する
タスク期日を設定アクションを使用してタスクの実行期日を設定できます。期日は、タスクが割り当てられた Worklist またはカスタム クライアント ユーザに対して表示されます。期日は、分、時、日、週、または月の単位で表わすことができます。あるいは、実行時に日時が決定される式として表わすこともできます。
非手動タスクに対してこのアクションを使用することにより、ユーザにタスクを割り当てアクションを使用せずに、特定の日付以降に並行実行させるアクションを指定したり、ワークフローに時間遅延を導入することもできます。
期日超過アクションを非同期的および同期的に実行する
タスクが期日まで実行されない場合、期日後に実行すべきサブアクションを、同期モードまたは非同期モードで指定できます。非同期モードではサブアクションは並行実行され、その間にワークフローは次のノードに進みます。この方法でアクションを設定するには、タスク ノード自体で、アクションの入っているタスクに完了マークを付けます。これは、通常、アクションを手動でタスクに割り当てるために使用される方法です。
同期モードでは、このアクションを使用してワークフローで時間遅延を作成できます。ワークフローは、期日に達するまで待ってから期日超過アクションを実行し、その後、先に進みます。アクションをこの方法で設定するには、ユーザに割り当てられているタスクまたは割り当てられていないタスクまたは割り当てられていないタスクにアクションを置き、[タスク期日を設定] ダイアログ ボックスの [期日に実行するアクション] タブにタスクに完了マークを付けるアクションを追加することにより、アクションの入っているタスクに完了マークを付けます。
図6-29 [タスク期日を設定] ダイアログ ボックス
タスクのコメントを設定する
タスク コメントを設定アクションを使用して、タスク インスタンスに関するコメントを設定できます。コメントは、アクションが実行される際に、Worklist または Studio でタスクをビューするユーザに対してテキスト メッセージとして表示されます。通常、このテキストは、ユーザに実行を求める手動での作業に関する情報または指示を提供します。テキスト メッセージは、Worklist アプリケーションのタスク リスト、または Studio の [ワークフロー インスタンス] ダイアログ ボックスまたは [Worklist] ダイアログ ボックスで、タスクの横の [コメント] カラムに表示されます（詳細については、ワークフローのモニタリングを参照）。
図6-30 [タスク コメントを設定] ダイアログ ボックス
タスク優先順位を設定する
タスク優先度を設定アクションを使用して、タスク優先順位を低、中、または高に設定できます。この優先度は、実行時におけるノードまたはノードのアクションの実行方法には影響を与えません。単に、Worklist に合わせてタスクを実行やソートを行うことができる Worklist ユーザに対して表示されるだけです。
[タスクのプロパティ] ダイアログ ボックスで現在のタスクの優先順位を設定できるため、ワークフローのどこかでタスクの優先順位を指定する条件の結果としてこのアクションを使用できます。
図6-31 [タスク優先度を設定] ダイアログ ボックス
タスクの割り当てを解除する
タスクの割り当てを解除アクションを使用して、現在のタスク割り当てを削除できます。タスクはユーザまたはロールに対する割り当てを持たなくなります。条件の結果としてタスクの割り当ての解除もできます。
図6-32 [タスクの割り当てを解除] ダイアログ ボックス
クライアント アプリケーションに対し XML メッセージを送信する
ユーザにタスクを割り当てた後、XML をクライアントに送信アクションを使用して XML ドキュメントをクライアントに送信することにより、ワークフローと、Worklist またはカスタム クライアント アプリケーションとの間の通信を行うことができます。この場合、クライアント アプリケーションが XML ドキュメントを識別し、該当するアクションを実行し、ワークフローに応答して XML ドキュメントを返すようにプログラムされている必要があります。Worklist アプリケーションの場合、XML メッセージを送信して、メッセージ プロンプトやフォームをユーザに表示したり、クライアント システム上でカスタム コンポーネントや実行可能プログラムを呼び出したりできます。カスタム クライアント アプリケーションの開発方法については、『BPM クライアント アプリケーション プログラミング ガイド』を参照してください。
XML をクライアントに送信アクションは、XML の送信先のクライアント マシンまたはアプリケーションを実際に指定するわけではありません。したがって、まずタスクをユーザまたはロールに割り当てておく必要があります。すると、XML メッセージがタスクを実行するクライアントに送信されます。詳細については、手動タスクの設定を参照してください。
メッセージを非同期的または同期的に送信する
XML メッセージは、クライアント アプリケーションに対して、非同期的または同期的に送信できます。同期モードでは、ワークフローはクライアントからの応答を待ってから次のノードに進みます。この方法でアクションを設定するには、タスク ノードではなく、[XML をクライアントに送信] ダイアログ ボックスの [コールバック アクション] タブ上のサブアクションとして、アクションの入っているタスクにマークを付けます。
非同期モードでは、ワークフローはクライアントからの応答を待たずに次のノードに続くため、クライアント上のオペレーションは並行実行されます。この方法でアクションを設定するには、タスク ノード自体で、タスクに完了マークを付けます。
データを抽出する
XML メッセージを返信することにより、アプリケーションがワークフローに応答する場合、応答ドキュメントにより戻されるデータを格納するための変数を作成する必要があります（手順については変数に関する作業を参照）。また、応答 XML ドキュメントからデータ値を取り出すために、XPath 式（またはドット（）表記）を使用して変数を初期化しておく必要があります。そのメッセージの JMS プロパティがアプリケーションにより使用される場合、EventAttribute() 関数を使用してこのデータを検索することもできます（詳細については、実行時のイベント データを抽出するを参照）。
XML をクライアントに送信アクションを定義する
以下のプロシージャが、非 Worklist アプリケーションのために生成されます。Worklist に XML メッセージを送信する方法の詳細については、Worklist アプリケーションに対する XML メッセージを送信するを参照してください。タイプ指定された XML ドキュメントを使用する方法の詳細については、タイプ指定ドキュメントを操作するを参照してください。
図6-33 [XML をクライアントに送信] ダイアログ ボックス
クライアントに XML メッセージを送信する手順は、次のとおりです。
図6-34 [ワークフロー変数の割り当て] ダイアログ ボックス
を使用して XPath Wizard を呼び出し、このウィザードを使ってサンプルの着信ドキュメントから XPath の式を自動的に生成できます。詳細については、XPath Wizard を使用する XPath 式の作成を参照してください。Worklist アプリケーションに対する XML メッセージを送信する
注意: Worklist クライアント アプリケーションは、WebLogic Integration のこのリリースでは廃止になっています。置き換えられる機能の詳細については『BEA WebLogic Integration リリース ノート』を参照してください。
Worklist クライアント アプリケーションは、事前定義された DTD (Document Type Definition: ドキュメント タイプ定義) ファイルの 4 つのペアに準拠する XML ドキュメントに対する応答によってアクションを実行するように設計されており、これらのファイルにより以下のことを行うことができます。
事前定義された DTD ファイルの 4 つのペアは、WebLogic Integration サーバ インストレーションの次のディレクトリにあります。
WLI_HOME¥docs¥apidocs¥com¥bea¥wlpi¥common¥doc-files
このパスでは、WLI_HOME は WebLogic Integration をインストールしたディレクトリを表します。多くの場合、ディレクトリは、c:¥bea¥weblogic700¥integration となります。
各ペアは、Worklist クライアントに対する要求のための DTD ファイルと、Worklist クライアントからの応答のための DTD ファイルで構成されます。次の表に、事前定義された DTD ファイルと、要求 DTD ファイルの 1 つに準拠する XML ドキュメントを受け取った際に Worklist アプリケーションにより実行されるアクションをリストします。
注意: これらの DTD に頻繁にアクセスする場合、取り出しやすいようにリポジトリにインポートしておくこともできます。その手順については、リポジトリにあるエンティティの管理を参照してください。 クライアントから受け取る各応答について、応答により戻される値を置くための変数を作成する必要があります。大部分は文字列型変数です。変数作成の手順については、変数に関する作業を参照してください。 以下の節では、各 DTD ペアに必要なドキュメント構造について詳しく説明します。 ユーザに対してメッセージ プロンプトを表示する 次のサンプルのように、ClientMsgBox DTD を使用することにより、Worklist ユーザに対してメッセージ ボックスを表示できます。 図6-35 メッセージ プロンプトのサンプル
要求 DTD では次の構造を持つドキュメントが必要です。 コード リスト 6-1 ClientMsgBoxReq XML ドキュメントの構造 すべての要素と属性は必須です。これらについて以下で説明します。
<message-box title=“text” style=“{plain|information|question|warning|error}”
options=“{ok|ok_cancel|yes_no|yes_no_cancel}”>
text
<actionid> provided by default </actionid>
</message-box>
応答ドキュメントは、選択されたボタンに従ってユーザの応答をメッセージ ボックスに表示します。応答 DTD には次の構造が必要です。 コード リスト 6-2 ClientMsgBoxReq XML ドキュメントの構造 要素と属性は必須です。それらについて、ワークフロー変数に値を戻すために必要な式と共に、以下で説明します。
<message-box option=”{ok|yes|no|cancel}” />
ユーザに対してフォームを表示する 次のサンプルのように、ClientSetVars DTD を使用することにより Worklist ユーザに対してフォームを表示できます。 図6-36 フォームのサンプル
要求 DTD では次の構造を持つドキュメントが必要です。 コード リスト 6-3 ClientSetVarsReq XML ドキュメントの構造 すべての要素と属性は必須です。少なくとも 1 つの <variable> 要素が必要です。さらに、任意の数の <variable> 要素を指定できます。要素と属性について以下で説明します。
<set-variables title=“text”>
text
<actionid>provided by default </actionid>
<variable name=“variable name” prompt=“text” />
[<variable name=“variable name” prompt=“text” />]
</set-variables>
応答ドキュメントは、ユーザの応答をそれぞれの入力フィールドに表示します。応答 DTD には次の構造が必要です。 コード リスト 6-4 ClientSetVarsResp XML ドキュメントの構造 すべての要素と属性は必須です。<variable> 要素の数は、要求ドキュメントで使用された数に対応させてください。要素と属性は必須です。ワークフロー変数に値を戻すために必要な式について以下で説明します。
<set-variables>
<variable name=“variable_name_1”>response_1</variable>
[<variable name=“variable name_2”>response_1</variable>]
.
.
.
</set-variables>
クライアント上の実行可能プログラムを呼び出す ClientCallProgram DTD を使用して、Worklist クライアント上のプログラムを呼び出すことができます。要求ドキュメントには次の構造が必要です。 コード リスト 6-5 ClientCallProgramReq XML ドキュメントの構造 すべての要素と属性は必須です。ただし、<parm> 要素と <env-var> 要素は省略可能です。<parm> 要素と <env-var> 要素は、指定しないことも、あるいは複数指定することも可能です。
<call-program name=“name” mode=”{sync|async}”>
<actionid> provided by default </actionid>
[<parm>parameter_1</parm>]
.
.
.
[<env-var name=”name”>environment variable
definition_1</env-var>]
.
.
.
</call-program>
応答 DTD には次の構造が必要です。 コード リスト 6-6 ClientCallProgramResp XML ドキュメントの構造 要素と属性は必須です。これらについて以下で説明します。
<call-program exit-value=“value” />
クライアント上でのカスタム Worklist 拡張を呼び出す ClientCallAddIn DTD を使用して、Worklist クライアントに対してカスタム拡張を呼び出すことができます。要求ドキュメントには次の構造が必要です。 コード リスト 6-7 ClientCallAddInReq XML ドキュメントの構造 すべての要素と属性は必須です。ただし、<parm> 要素は省略可能です。<parm> 要素は、指定しないことも、あるいは複数指定することも可能です。
<call-addin name=“name” mode=”{sync|async}”>
<actionid> provided by default </actionid>
[<parm>parameter_1</parm>]
.
.
.
</call-addin>
応答ドキュメントの指定は省略可能です。要素は省略可能で、任意の数のカスタム要素と属性を定義できます。 コード リスト 6-8 ClientCallAddInResp XML ドキュメントの構造 これらの要素について以下で説明します。
<call-addin>
[<tag_name_1 attribute_name_1=”attribute_value”
. . .>value</tag_name_1>]
.
.
.
</call-addin>
電子メール メッセージを送信
電子メール メッセージを送信アクションを使用して、WebLogic Integration システムのユーザまたは外部パーティのユーザにも電子メール メッセージを送信できます。メッセージの伝送には、インターネット標準の SMTP が使用されます。
設計時にオペレーティング システムがサポートしている文字セットであればどれでも電子メール メッセージを作成できます。また、メッセージを送信するために実行時にサーバにより使用される文字セットを指定できます。英語ロケールでは、サーバにより使用されるデフォルト文字セットは、Java Virtual Machine により使用されるデフォルト文字セットである cp1252 ですが、Java 言語によりサポートされるどの文字セットでも指定できます。文字セットのリストについては、http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html を参照してください。
注意: このアクションには、WebLogic Integration サーバのインストレーション プロセス中またはその後で、電子メール サーバが正しくコンフィグレーションされている必要があります。インストレーション後にメール サーバ プロパティをコンフィグレーションする方法については、『WebLogic Integration の起動、停止およびカスタマイズ』の「WebLogic Integration のカスタマイズ」にある「メール セッション プロパティのカスタマイズ」を参照してください。
図6-37 [電子メール メッセージを送信] ダイアログ ボックス
図6-38 [電子メール メッセージを送信] ダイアログ ボックスの [To] タブ
図6-39 [メールの宛先] ダイアログ ボックス
コンポーネントの呼び出し
以下のアクションを使用して、EJB、Java クラス、実行可能プログラムなどのソフトウェア コンポーネントを呼び出したり、ワークフローとコンポーネントの間で入力パラメータや出力パラメータを直接受け渡すことができます。
サーバ上の実行可能なプログラムを呼び出す
プログラムの呼び出しアクションを使用して、WebLogic Integration サーバ上の実行可能プログラムを呼び出すことができます。このアクションは、常に非同期的に実行されます。つまり、ワークフロー内でこのアクションの後に続くアクションは、呼ばれた側のプログラムが完了するのを待つことなく同時に実行されます。
注意: XML をクライアントに送信アクション内でプログラムの呼び出しアクションを使用して、cmd.exec などのシェル プログラムへのアクセスを許可する場合は注意してください。これによりクライアント コンピュータへの完全なアクセスが可能になるため、アプリケーションのセキュリティが低減します。
図6-40 [プログラムの呼び出し] ダイアログ ボックス
サーバ上の実行可能プログラムを呼び出す手順は、以下のとおりです。
ビジネス オペレーションを呼び出す
ビジネス オペレーションを実行アクションを使用して、EJB や Java クラスなどの Java コンポーネントで、ビジネス アクティビティを実行するメソッドを呼び出すことができます。
開始したいビジネス オペレーションは、あらかじめ定義しておく必要があります。さらに、Java オブジェクト、セッション EJB、エンティティ EJB の各変数が、ビジネス オペレーションによって呼び出されるメソッドを持つ Java クラスまたは EJB インスタンスへの参照を保存するように、あらかじめ定義しておく必要があります。ビジネス オペレーションを定義する方法の詳細については、ビジネス オペレーションのコンフィグレーションを参照してください。変数の定義方法の詳細は、変数に関する作業を参照してください。
また、EJB 上のメソッドまたは Java クラス上の非静的メソッドを呼び出すビジネス オペレーションを実行できるようにするには、その前に、以下のルールに従って、WebLogic Integration サーバで Java クラスまたは EJB のインスタンスを作成するビジネス オペレーションを呼び出す必要があります。
インスタンスを作成するビジネス オペレーションを実行する場合、インスタンス変数と呼ばれる変数に対してインスタンスへの参照を割り当てます。その後、同じ EJB またはクラスに入っているメソッドを表わす他のビジネス オペレーションを呼び出す際に、EJB または Java クラス インスタンスを参照するインスタンス変数を識別します。詳細については以下の節で説明します。
EJB または Java クラス インスタンスを作成するためのビジネス オペレーションを呼び出す
EJB または Java クラス インスタンスを作成するビジネス オペレーションを呼び出す場合、以下のように、インスタンスに対する参照を同じデータ型の変数に対して割り当てる必要があります。
図6-41 [ビジネス オペレーションを実行] ダイアログ ボックス
EJB または Java クラス インスタンスを作成するためにビジネス オペレーションを呼び出す手順は、以下のとおりです。
他のビジネス オペレーションを呼び出す
EJB または Java クラスの create() またはコンストラクタ メソッドのためのビジネス オペレーションを実行をノードに追加した後、同じクラスまたは EJB 上のメソッドを呼び出す他のビジネス オペレーションを追加できます。
合計価格の計算のような、パラメータを取って結果を戻すメソッドの場合、ビジネス オペレーションにより戻される値を格納する変数も作成する必要があります。この変数は、メソッドにより指定された変数と同じタイプにしてください。
図6-42 [ビジネス オペレーションを実行] ダイアログ ボックス
他のビジネス オペレーションを呼び出す手順は、以下のとおりです。
JMS トピックまたはキューへの XML メッセージのポスト
イベントをトリガする目的で、指定された宛先に XML メッセージを送信するには、XML イベントをポストアクションを使用します。このアクションにより、新しい XML 文書を作成またはワークフローの既存の XML 型変数の内容を使用します。いずれの場合でも JMS メッセージ内に XML コンテンツを埋め込みます。この XML コンテンツは、外部アプリケーションで処理するために外部 JMS キューまたはトピックにポストすることも、あるいは、別のワークフローで処理するために内部キューにポストすることもできます。
注意: クラスタ化環境で WebLogic Integration を実行している場合、ワークフローを開始アクションで直接ワークフローを呼び出すより、別のワークフローを開始する XML イベントをポストするほうが、負荷バランスをよりよく調整できます。
送信する XML ドキュメントの作成もできれば、XML リポジトリ、ディスク上のファイル、または URL から既存の XML ドキュメントのインポートも可能です。また、XML コンテンツを実行時に指定できる変数として送信されるドキュメントを指定することもできます。
XML イベントをポストアクションは、XML メッセージ コンテンツだけでなく、アクションのプロパティに指定されたオプションに従って、JMS ヘッダと値をメッセージに挿入します。WebLogic Server サーバの標準 JMS ヘッダ フィ-ルドの詳細については、次の URL にある『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の基礎」を参照してください。http://edocs.beasys.co.jp/e-docs/wls/docs70/jms/fund.html
JMS メッセージング オプションについて以下の節で説明します。
イベントを非同期的または同期的にポストする
発信メッセージを作成するようにコンフィグレーションされたワークフローまたは他のコンポーネントに関連して、XML イベントを、非同期的にも、あるいは同期的にも機能するよう設定できます。そのためには、受取側ワークフローから戻される確認メッセージを受け取るための通信を開始するワークフローでイベント ノードを使用します。
デフォルトでは、XML イベントをポストアクションは「発信後削除（fire and forget）」方式でメッセージをポストするだけの非同期的なものであり、その間にワークフローは次のアクションに進みます。したがって、並行して実行される他のワークフローまたはアプリケーションをトリガする場合、および呼び出し側ワークフローは、呼び出されたワークフローまたはアプリケーションからの返信を受け取る必要がない場合には、そのままそのアクションを使用してください。
呼び出し側ワークフローと呼び出されたワークフローまたはアプリケーションとを並行して実行し、呼び出し側ワークフローが呼び出されたワークフローまたはアプリケーションからの返信を期待している場合、「適時（just in time）」方式でメッセージを受け取るように、呼び出し側ワークフローでイベント ノードを設定できます。つまり、ワークフローの中で、呼び出されたワークフローまたはアプリケーションにより戻されるデータを必要とするポイントにのみイベント ノードを設定できます。次の図に 2 つのシナリオを示します。
図6-43 XML イベントの非同期的ポスト
XML イベントを純粋に同期的方法でポストする場合、つまり、呼び出されたワークフローまたはアプリケーションが実行を完了するまで、呼び出し側ワークフローが先に進まずに待つようにする場合、呼び出されたワークフローまたはアプリケーションが実行を終了した際にメッセージを送信するように設定し、呼び出し側ワークフローの XML イベントをポストアクションの直後にこのメッセージをリスンするイベント ノードを置きます。この設計を次の図に示します。 図6-44 イベントの同期的ポスト
JMS メッセージング オプション 以下の節では、[XML イベントをポスト] ダイアログ ボックス内から利用できる各種 JMS メッセージング オプションについて説明します。 送り先 内部 JMS キューを指定することにより、現在のワークフローまたは別のワークフローでイベント ノードをトリガしたり、イベントによりトリガされる開始を定義した別のワークフローを開始したりできます（開始ノードとイベント ノードでイベントをトリガする方法の詳細については、イベントおよびイベントトリガ型開始のプロパティを定義するを参照）。デフォルトのメッセージ送信先である内部 JMS キューの JNDI 名は、com.bea.wlpiEventQueue です。WebLogic Server で他にもキューがコンフィグレーションされている場合、代替キュー名を指定できます（WebLogic Integration のための代替メッセージ キューを設定する方法の詳細については、『WebLogic Integration の起動、停止およびカスタマイズ』の「WebLogic Integration のカスタマイズ」にある「カスタム Java Message Service キューのコンフィグレーション」を参照）。 また、指定した JMS トピックにサブスクライブする外部アプリケーションや、JMS キュー受信者である特定のアプリケーションと通信するために、外部 JMS トピックやキューに XML メッセージを送信することもできます。 ヘッダ JMS メッセージは、メッセージと共に常に伝送されるヘッダ フィールドの標準セットを含んでいます。[XML イベントをポスト] ダイアログ ボックスで利用できるオプションにより自動的に挿入される JMSDeliveryMode、JMSDestination、JMSPriority、JMSExpiration (存続時間) の各ヘッダに加え、アプリケーション固有の情報のプロパティ フィールドや値を発信メッセージに追加し、メッセージ本文には適していない情報の指定もできます。たとえば、別のワークフローをトリガするために XML メッセージングを使用する場合、ワークフローを開始するオーガニゼーションの名前を指定するためにプロパティ フィールドを使用できます。 JMS メッセージ プロパティは、名前と値の組み合わせです。名前には、Java 言語で有効な識別子ならば、ほとんどの文字列を使用できます。値は、ブール、バイト、ショート、整数、ロング、フロート、倍精度、または文字列にできます。 JMS ヘッダおよびプロパティ フィ-ルドの詳細については、次の URL にある『 WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の基礎」を参照。http://edocs.beasys.co.jp/e-docs/wls/docs70/jms/fund.html 順序指定メッセージまたはアドレス指定メッセージが使用された場合、[XML イベントをポスト] ダイアログ ボックス オプションの [アドレス指定] タブに入力された値に基づいて、順序指定メッセージの場合は指定された順序キーのためのプロパティ フィールドが、アドレス指定メッセージの場合は指定されたワークフロー インスタンス IDのためのプロパティ フィールドが、WebLogic Integration により挿入されます。ただし、さらに 2 つのプロパティがサポートされており、手動で挿入できます。
この機能は、現在のワークフローとの会話に入力されたワークフロー インスタンスまたはテンプレート名のリストを統合して、単一のメッセージにより外部アプリケーションに渡す必要がある場合に便利です。
メッセージが別のワークフローにより受信されるようにする場合、受信側ワークフローは、開始ノードまたはイベント ノードのイベント キー式または変数初期化で EventAttribute() 関数を使用することにより、プロパティ フィールドに指定された情報を検索できます。複数のインスタンス ID またはテンプレート名を指定する場合、Java オブジェクト データ型として定義された変数に関数の結果を割り当てる必要があります。
イベント キー式の詳細については、イベント キーのコンフィグレーションを参照してください。イベント データから変数を初期化する方法の詳細については、イベント データからの変数を初期化するを参照してください。EventAttribute() 関数の詳細については、実行時のイベント データを抽出するを参照してください。
配信モード
メッセージは、永続または非永続のいずれかとして指定できます。永続メッセージは、データベース表に書き込まれ、JMS サーバが失敗した場合でも失われません。このメッセージは、サーバが回復した後に再度配信される。非永続メッセージは、JMS サーバが失敗すると失われることがあります。このメッセージは、サーバが回復しても再配信されない。デフォルトの配信モードは永続です。
存続時間
メッセージを永続とするか、非永続とするかは、メッセージの期限により指定できます。消滅時間までに配信されない場合、メッセージは破棄されます。このオプションは、株の指し値のように、ある時刻以降には配信してはならないメッセージの場合に便利です。存続時間はミリ秒単位で表わされます。たとえば、メッセージを 1 時間有効にする場合は、3600000 (60 分 × 60 秒 × 1000 ミリ秒) という値を指定する。デフォルト値の 0 (ゼロ) は、メッセージに期限がないことを示す。
アドレス指定されたメッセージに対して消滅時間を指定した場合、指定されたすべての受取人にメッセージが正常に配信されるか、あるいは消滅するかのいずれか早い方のイベントが発生するまでメッセージは存続します。
優先度
0 から 9 のレベルの優先順位を割り当てることができます。レベル 0 から 4 は通常の優先順位です。レベル 5 から 9 は迅速を求める優先順位です。優先度が至急のメッセージは、通常の優先度のメッセージよりも先に配信される。一般に、アラーム メッセージやシャットダウン メッセージに対して迅速順位を使用します。デフォルト優先順位はレベル 4 です。
優先順位は順位付きメッセージングをオーバーライドするため、同じ順位キーを持つメッセージに対しては、すべて同じレベルの優先順位を指定する必要があります。推奨設定は、デフォルトの 4 のままにすることです。
他の優先順位レベルを使用するには、まず、WebLogic Server で宛先キーをコンフィグレーションする必要があります。詳細については、次の URL にある『WebLogic Server 管理者ガイド』の「JMS の管理」を参照してください。http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/jms.html
トランザクション モード
メッセージを直ちに送信するか、XML イベントをポストアクションの入っている現在のトランザクションがコミットする際に送信するかを指定できます。メッセージを直ちに送信すると、トランザクションが完了したかどうかにかかわらず、メッセージは送信されます。コミット時にメッセージを送信すると、トランザクションが正常に完了し、コミットが発行された場合に限り、メッセージは送信されます。トランザクションが正常に完了せず、ロールバックされた場合、メッセージは送信されません。デフォルトは、トランザクションのコミット時です。ワークフロー トランザクション境界の詳細については、『BPM クライアント アプリケーション プログラミング ガイド』の「BPM トランザクション モデル」を参照してください。
アドレス指定メッセージング
インスタンス化されたワークフローの受信側イベント ノードがフローでアクティブ化されていない場合でも、現在のワークフローとの会話を開始した（ワークフローを開始アクションでワークフローを呼び出すことにより、または以前に送信された XML メッセージにより、ワークフロー内の開始ノードまたはイベント ノードをトリガすることにより）特定のワークフロー インスタンスに確実に応答メッセージが配信されるようにするには、アドレス指定メッセージングを使用できますノードのアクティブ化の詳細については、『BPM クライアント アプリケーション プログラミング ガイド』の「BPM トランザクション モデル」を参照してください。
アドレス指定メッセージングを使用する場合、通常は、メッセージの配信先のワークフロー インスタンス ID のリストを用意します。このリストは、XML メッセージに埋め込まれた WorkflowAttribute(“InstanceID”) 式により、またはワークフローを開始アクションによりワークフローに渡されるパラメータとして、発信元ワークフローから送信され、現在のワークフローの前のノードにより抽出され、変数に格納されます。インスタンス ID のリストは、通常、対象の ID の入ったカンマ区切りの変数のリストです。メッセージは、このリストに指定されたインスタンスに対してのみ配信されます。
注意: ワークフロー インスタンス ID は文字列として格納されるため、インスタンス ID 値を入れる変数を作成する場合は、文字列型として作成してください。ワークフロー属性関数の詳細については、実行時のワークフロー データを収集するを参照してください。
存続期間を指定した場合、メッセージが指定されたすべての受取人に配信されるか、消滅するかのいずれか早い方のイベントが発生するまで、メッセージは存続します。
順序指定メッセージング
同じイベントのリスナに、メッセージを受け取った順序どおりに処理させるには、順序キーを指定します。たとえば、注文処理システムが注文を作成する要求と、注文の更新またはキャンセルを行う要求を受け取った場合、作成要求メッセージを先に処理させることができます。
順序キーは整数値でなければならず、その値は受け取った順序で処理させたいすべてのイベントで同じでなければなりません。たとえば、2 つのイベントが同時にポストされ、受け取った順序で処理されるようにする場合、各イベントに対して、整数値の 8 のような同じ値の順序キーを入力します。また、順序指定メッセージは、同じ JMS キューに送信する必要があります。
順序指定メッセージングは、メッセージ優先順位と互換性がないため、順序キーを使用する場合は、同じ順序キーを持つすべてのメッセージに対して同じレベルの優先順位を設定する必要があります。推奨設定は、デフォルトの 4 のままにすることです。
XML イベントをポストアクションを定義する
XML イベントを定義する手順は、以下のとおりです。
図6-45 [XML イベントをポスト] ダイアログ ボックスの [XML メッセージ] タブ
図6-49 [XML イベントをポスト] ダイアログ ボックスの [アドレス指定] タブ
XML ドキュメントの変換
XSLT (Extensible Stylesheet Language Transformations: 拡張可能スタイルシート言語変換) は、XMLドキュメントを他の XML ドキュメントまたは非 XML ドキュメントに変換するためのルールを定義します。XSL テンプレート ドキュメントは、変換する入力 XML ドキュメントの要素と、その要素をどのように変換するかを指定します。
XSL 変換アクションにより、変換する入力 XML ドキュメント、変換の詳細を指定する XSL テンプレート ドキュメント、変換されたドキュメントを入れる出力変数を指定できます。実際の変換は実行時に行われ、WebLogic Server 付属の XSL 変換エンジンにより実行されます。
入力ドキュメントにはワークフロー式を入れることができます。その場合、式は変換を行う前にプロセス エンジンにより解決され、結果の入った式に置き換えられます。同様に、XSL テンプレート ドキュメントにはワークフロー変数に対する参照を入れることができます。その場合、参照は変換を行う前にプロセス エンジンにより解決され、適切な値の入った参照に置き換えられます。
入力ドキュメントは、実行時にドキュメントの場所を指示する式として指定されることに注意してください。この式には、XML ドキュメントを格納したワークフロー変数の名前を含めることができます。この場合、XML タイプ変数を作成し（変数に関する作業参照）、あらかじめワークフローで既存または着信 XML ドキュメントを割り当てておく必要があります。これを行う方法の 1 つは、ワークフロー変数を設定アクションです。その手順については、変数値の設定を参照してください。
XSL テンプレート ドキュメント（変換ドキュメント）は、リポジトリに格納されたエンティティにできます（詳細については、リポジトリにあるエンティティの管理を参照）。あるいは、実行時にドキュメントの場所を示す式を使用することもできます。リポジトリにある XSL エンティティまたは実行時に場所指定される XSL ドキュメントがパラメータを取る場合、実行時にパラメータの値を提供する式を指定することもできます。
出力ドキュメントは、事前に作成できる XML または文字変数に格納する必要があります。その手順については、変数を作成するを参照してください。
図6-50 [XSL 変換] ダイアログ ボックス
図6-51 [XSL パラメータ] ダイアログ ボックス
例外処理
例外の処理に関係するアクションは、すべてワークフロー例外の処理で説明します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
