| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Integration > BPM トピック > WebLogic Integration Studio ユーザーズ ガイド > ワークフロー テンプレートの定義 |
|
WebLogic Integration Studio ユーザーズ ガイド
|
ワークフロー テンプレートの定義
この章では、ワークフロー テンプレート、テンプレートの定義、ワークフロー変数およびノードの定義と保守に関するコンセプトやタスクについて説明します。構成は以下のとおりです。
テンプレート定義タスクの概要
詳細なワークフロー テンプレートの定義は、テンプレートの作成、テンプレート定義の作成、フローの設計、変数の定義、ノードのプロパティの指定および例外ハンドラの定義（省略可能）で構成されます。ワークフローの定義は、各レベルでリビジョンおよび改良を要する反復的なプロセスですが、新しいテンプレートを定義する場合、これらのタスクの実行は以下の手順をお勧めします。
注意: また、ワークフロー テンプレートの定義を開始する前に、ワークフロー式の言語や Studio の Expression Builder および XPath Wizard ツールについての学習も必要です。テンプレート定義のラベル作成、分岐ノードの条件の定義、イベントの定義など、この節で説明するタスクの多くではダイアログボックス フィールドに式を入力する必要があります。ワークフロー式に関する詳細については、ワークフロー式の使用法を参照してください。
テンプレートに関する作業
ワークフロー テンプレートとは、つまり WebLogic Integration ワークフロー テンプレート定義用のフォルダまたはコンテナです。各ワークフロー テンプレートには、1 つまたは複数のワークフロー テンプレート定義を保持できます。ワークフロー テンプレート定義は、テンプレート定義に関する作業で説明するように、フォルダ ツリーで Effective (有効) および Expiry (終了) 日時によって識別されます。
図5-1 ワークフロー テンプレートとワークフロー テンプレート定義
テンプレートは、オーガニゼーションに対して 1 対複数の関係を持ちます。つまり、テンプレートはそのシステムにおいて固有のものとなりますが、複数のオーガニゼーションに対して定義できます。テンプレートは、定義されている各オーガニゼーションのフォルダ ツリーに、そのすべてのテンプレート定義と共に表示されます。1 つのオーガニゼーションのフォルダ ツリーでテンプレート定義に加えられた変更（削除も含む）は、そのテンプレートが関連付けられている他のすべてのオーガニゼーションのフォルダ ツリーに自動的に表示されます。 Import/Export 機能を用いてテンプレートおよびテンプレート定義をインポートする場合、テンプレートは上書きされますが、テンプレート定義は上書きされません。既存のものと同じ日付のテンプレート定義をインポートする場合、既存のテンプレート定義は上書きされず、別の定義が作成されます（テンプレートのインポートの詳細については、ワークフロー パッケージのインポートを参照）。 ワークフロー テンプレートを作成する 注意: テンプレートを作成するためにはテンプレートの作成パーミッションが必要です。パーミッション レベルの詳細については、ユーザおよびロールへのパーミッションの割り当てを参照してください。 ワークフロー テンプレートを作成する手順は、以下のとおりです。
図5-2 [テンプレートのプロパティ] ダイアログ ボックス
テンプレート プロパティを更新する
[テンプレートのプロパティ] ダイアログ ボックスで、作成後またはインポート後にテンプレートを追加されたオーガニゼーションに割り当てることができます（手順については、ワークフロー パッケージのインポートを参照）。
テンプレート プロパティを更新する手順は、以下のとおりです。
テンプレートを削除する
ワークフロー テンプレートを削除すると以下のことが起こります。
注意: テンプレートを削除するためにはテンプレートの削除パーミッションが必要です。パーミッション レベルの詳細については、ユーザおよびロールへのパーミッションの割り当てを参照してください。
ワークフロー テンプレートを削除する手順は、以下のとおりです。
テンプレート定義に関する作業
フォルダ ツリーのワークフロー テンプレート定義名は、その有効日時および終了日時で構成されます。有効日時および終了日時は、ワークフロー テンプレート定義がインスタンスあるいは実行に有効となる時間の範囲を表します。同じ有効日時および終了日時を持つ複数のテンプレート定義が存在する場合もあります。
インスタンスに有効なテンプレート定義を作成するためには、まずそれをアクティブにする必要があります。設計時に、テンプレート定義を、いくつでもアクティブにできますが、唯一、同じ有効（開始）日時を持つテンプレート定義はアクティブにできないという制限があります。
有効および終了日時の機能の利点は、1 年を通じて異なるテンプレート定義を手動で非アクティブあるいはアクティブにすることなく、ある期間に対して正確に有効なワークフロー テンプレート定義を作成できるという点です。たとえば、特定のワークフロー テンプレート定義を 1 月から 3 月まで実行し、異なるタスクや変数を持つ次のワークフロー テンプレート定義を 4 月から 6 月まで実行しなければならず、さらに次の定義を 7 月から 9 月まで実行しなければならない周期的ビジネスの場合などです。1 つのテンプレート定義を手動で非アクティブにして、別のテンプレート定義を四半期ごとにアクティブにする代わりに、異なる有効日時および終了日時を指定し、それらすべてをアクティブとしてマークすると、サーバがワークフローのインスタンス化の際に正しいバージョンを自動的に選択します。
一方、複数のアクティブなテンプレート定義を持つことは可能ですが、実際に実行時にインスタンス化されるのは 1 つのテンプレート定義のみです。つまり、有効および終了日時は、ローリング方式で設計するよう注意し、日付のオーバーラップを回避する必要があります。日付がオーバーラップするアクティブなテンプレート定義がある場合（たとえば 1 月から 3 月までの定義と 2 月から 4 月までの定義が混在する場合）、プロセス エンジンはデータベースから検索した最初の定義を取り上げます。これは通常、設計時に先に作成された定義です。
注意: 異なるビジネス条件に従って異なるフローを指定する場合、同じテンプレート定義で複数の開始ノードを使用します。詳細については、開始のプロパティを定義するを参照してください。
ワークフロー テンプレート定義を作成する
テンプレート定義を作成する場合、その有効および終了の日付を指定します。
監査エントリを作成アクションを用いて、クライアント アクセスおよび実行時間など、実行時のワークフロー情報のロギングを有効にし、ワークフロー全体を通じて各ポイントにおけるカスタム エントリを可能にする監査を有効にすることもできます（詳細については、監査エントリを作成するを参照）。監査情報は、XML メッセージとしてデフォルトの JMS 監査トピック com.bea.wlpi.AuditTopic にポスティングされ、サーバ上のアクティブな WebLogic Integration ドメインの logs ディレクトリにあるテキスト ファイル myserver.log に書き込まれます。
注意: テンプレート定義を作成するためには、テンプレートを作成パーミッションが必要です。パーミッション レベルの詳細については、ユーザおよびロールへのパーミッションの割り当てを参照してください。
ワークフロー テンプレート定義を作成する手順は、以下のとおりです。
図5-3 [テンプレート定義] ダイアログ ボックス
ワークフロー設計領域ではデフォルトのワークフロー テンプレート定義がツールバーと共に表示されます。このツールバーにはワークフロー テンプレートの定義に用いられる描画シェイプが含まれます。デフォルトのワークフロー テンプレート定義には、開始、タスク、完了の 3 つのシェイプが含まれます。
図5-4 ワークフロー設計領域
ノードに関する作業で説明するようにノードやコネクタを追加し、変数に関する作業で説明する変数を追加してテンプレート定義を行うことができます。 既存のテンプレート定義を開く テンプレート定義の読み取り専用プロパティは、フォルダ ツリーでいずれかのフォルダを右クリックしてポップアップ メニューから [プロパティ] を選択して見ることができますが、テンプレート定義は開かれていない限り修正を加えることはできません。テンプレート定義は開くとロックされるので、他のユーザは読み取り専用モードでしか開くことができません。 注意: テンプレート定義を開くためにはテンプレートを作成パーミッションが必要です。パーミッション レベルの詳細については、ユーザおよびロールへのパーミッションの割り当てを参照してください。 既存のワークフロー テンプレート定義を開く手順は、以下のとおりです。
注意: 実行中のインスタンスを持つテンプレート定義の修正は行わないでください。このような定義を修正すると、これらのインスタンスに予測不可能な例外が発生する場合があります。そのようなテンプレート定義に変更を加える場合は以下を行ってください。
テンプレート定義を保存し終了する
Studio のフォルダ ツリーでは、保存が必要な各ワークフロー テンプレート定義の左側にアスタリスク（*）が表示されます。
テンプレート定義を保存するには以下のいずれかを行います。
テンプレート定義を閉じると、ロックが解除され別のユーザによる使用が可能になります。
ワークフロー テンプレート定義を終了するには以下のいずれかを行います。
テンプレート定義を更新、ラベリングおよびアクティブ化する
テンプレート定義を作成し、開いたら（ワークフロー テンプレート定義を作成するで説明）、作成時に指定したプロパティを更新し、ラベルを追加してアクティブ化できます。
ここで作成するワークフロー ラベルは、実行時にタスク リストのワークフロー ラベル カラムに表示され Worklist ユーザに示されます。また、実行時に Studio の [ワークフロー インスタンス] ダイアログ ボックスの [ワークフロー ラベル] フィールドにも表示されます（詳細については、ワークフロー インスタンスの状態を表示するを参照）。これは、ワークフローのインスタンスを識別するために用いられ、日時、請求書番号、顧客名あるいは他と区別するための関連情報が含まれます。ラベルはワークフロー式言語で公式化され、定数、変数、演算子およびその他の式コンポーネントを含むことが可能です。ワークフロー式機能および構文に関する詳細については、ワークフロー式の使用法を参照してください。
新しいテンプレート定義を作成するとデフォルトで非アクティブな状態になります。現在開発中のテンプレート定義は、不用意に開かれることを避けるため通常は非アクティブとなっています。ただし、ワークフローがインスタンス化される前、あるいは実行環境に置かれる前に、いずれか 1 つのテンプレート定義をアクティブにする必要があります。
ワークフロー テンプレート定義のプロパティを更新する手順は、次のとおりです。
図5-6 テンプレート定義のプロパティの更新
ワークフロー テンプレート定義をコピーする
Studio では、同一テンプレート内の既存のワークフロー テンプレート定義をコピーできます。コピーを行うと、割り当てられたすべてのワークフロー テンプレート定義プロパティもコピーされます。これは、同様のプロパティを持つ複数のワークフロー テンプレート定義を作成する必要がある場合に時間を節約できます。新しいワークフロー テンプレート定義のプロパティは必要に応じて修正できます。
注意: コピーされた（新しい）ワークフロー テンプレート定義はアクティブにマークされていません。これをインスタンス化のために有効にしたい場合は、まずアクティブにする必要があります。詳細については、テンプレート定義を更新、ラベリングおよびアクティブ化するを参照してください。
既存のワークフロー テンプレート定義をコピーする手順は、以下のとおりです。
テンプレート定義を印刷する
Studio から、ワークフロー テンプレート定義ダイアグラムを印刷できます。印刷機構を呼び出す方法は 2 通りあります。
図5-7 ワークフロー テキストの印刷
[テキスト] タブには、タスク、イベント、分岐および完了ノード内のアクション（アクション内のサブアクションを含む）の詳細に加え、アクションおよびノード メモなど、各ワークフロー ノードに関連した情報が含まれます。
[グラフィック] タブにはワークフロー テンプレート定義のダイアグラムが含まれます。
図5-8 ワークフロー グラフィックの印刷
[印刷] をクリックして選択したタブの情報を印刷するか、[すべて印刷] をクリックして [テキスト] タブに含まれる情報と [グラフィック] タブに含まれるダイアグラムの両方を印刷します。 [印刷] ダイアログ ボックスで、ワークフローを印刷するための適切な設定を行います。 テンプレート定義を削除する ワークフロー テンプレート定義を削除すると以下のことが起こります。
注意: テンプレート定義を削除するためには、テンプレートの削除パーミッションが必要です。パーミッション レベルの詳細については、ユーザおよびロールへのパーミッションの割り当てを参照してください。
ワークフロー テンプレート定義を削除する手順は、以下のとおりです。
ノードに関する作業
最初にワークフロー テンプレート定義を作成した後、デフォルトでは、設計領域に開始、タスクおよび完了の 3 つのシェイプ（ノード）が存在します。開始ノードはデフォルトでは手動による開始に設定されており、タスク ノードはワークフローを開始する Worklist ユーザにタスクを割り当てます。これらは、実行可能なワークフローを作成するために必要な最小限のプロパティです。（開始ノード プロパティの編集の詳細についてはイベントトリガ型開始のプロパティを定義するを、タスク ノード プロパティの編集の詳細については、タスクのプロパティを定義するを参照）。
次の表に、ワークフロー シェイプ、そのノード名および目的を示します。
ノードを追加、配置および接続する 設計領域のシェイプを操作するために、以下を行うことができます。
注意: ツールバーに関する詳細については、ツールバーの使い方を参照してください。
設計領域にノードを追加すると、ノードは直ちにフォルダ ツリーにも表示されます。ノードにはデフォルト名が付けられます。この名前は設計領域に配置した順番を示す番号を含み、タスク ノードの場合は T1、T2、T3 のようになります。ノードの名前を変更し、プロパティを編集する場合は、ノード プロパティに関する作業を行うを参照してください。
ノードまたはコネクタを削除する
ノードを削除する手順は、以下のとおりです。
コネクタを削除する手順は、以下のとおりです。
ワークフロー設計のガイドラインとヒント
シェイプを追加、接続、配置する際、以下の設計ガイドラインを覚えておくと便利です。
設計ガイドラインの追加情報については、『BPM ワークフローの設計ベスト プラクティス ガイド』を参照してください。
ノード プロパティに関する作業を行う
ワークフロー設計領域にノード型を配置し、そのプロパティを指定することができます。たとえば、最初のタスクとしてノードの名前を変更し、ワークフローにおけるノードの機能を認識しやすくできます。以下の節では、すべてのタイプのノードに共通するプロパティについての説明、および設定手順について説明します。ノードの各タイプ固有のプロパティについては各ノード タイプについて説明する節を参照してください。
ノードのプロパティにアクセスするには以下のいずれかを行います。
ノードの名前を変更する
結合および完了を除くすべてのノード タイプに有意な名前を付けることができます。また、分岐に対しては識別のための条件式を入力する必要があります。詳細については、分岐のプロパティを定義するを参照してください。
ノードの名前を変更する手順は、以下のとおりです。
サクセサ ノードを指定または更新する
すべてのノードの [プロパティ] ダイアログ ボックスには、現在のワークフローの全ノードを一覧表示する [次] タブがあります。ワークフローにおける次のノードを、ノード名の横にあるチェックによって指定する。このタブを使って、現在のノードに後続ノード（複数可）を指定する、または設計領域で定義された後続ノードを変更できる。タブ内のチェック ボックスにチェックするかチェックを外すと、設計領域内に表示されたノード間をつなぐ線が自動的に引き直される。
図5-9 ノードの [プロパティ] ダイアログ ボックスの [次] タブ
ノードへの注意を追加する すべてのノードの [プロパティ] ダイアログ ボックスには、ノードやノードに含まれるアクションに関するコメントを入力できる [メモ] テキスト ボックスがあります。これは、同じワークフローにアクセスする他のユーザが、そのワークフローのロジックや設計を理解する必要のある場合に役立ちます。 図5-10 ノードの [プロパティ] ダイアログ ボックスの [メモ] タブ
さらに、分岐ノードおよびタスク ノードには、アクションに対して定義されたメモを見ることのできる [アクション メモ] タブがあります（アクションへコメントを追加するを参照）。[タスクのプロパティ] または [分岐のプロパティ] ダイアログ ボックス左のペインでアクションを選択すると、そのアクション定義に対するメモが表示されます。 ワークフロー アクションを追加、更新、並べ替えおよび削除する 結合（AND および OR）を除くすべてのノードでは、そのプロパティ ダイアログ ボックスでアクションの追加、更新、並べ替えそして削除が可能です。 図5-11 ノードの [プロパティ] ダイアログ ボックスの [アクション] タブ
アクションは、ノードがアクティブになった場合に実行する操作を定義するものです。ノードのプロパティ ダイアログ ボックスの [アクション] タブで指定したアクションは、ワークフローが次のノード（およびそれに含まれるアクション）に進む前に実行されます。 タスク ノードではアクションの追加が必須ですが、その他のノードではサクセサ タスク ノードの追加によって同一ロジックが実装される場合が多いため、アクションの追加は任意であり、推奨されません。アクションの追加、更新、削除、並べ替えそして定義についての詳細については、アクションの操作で説明します。 ノードをコピーする ワークフロー テンプレート定義内のノードを表すシェイプをコピーして、現在のワークフロー テンプレート定義、または別の開いているワークフロー テンプレート定義に貼り付けることができます。ノード内で定義されたアクションおよびプロパティもコピーされるため、コピー機能を用いて若干の修正のみで再利用が可能な設計パターンを作成できます。 注意: テンプレート定義間でノードをコピーする場合には、そのノードが参照する変数とそのアクションがコピー先のテンプレート定義内で作成されていること、その他の参照オブジェクトであるロール、ユーザ、ビジネス カレンダーなどがそのテンプレートに関連付けられたオーガニゼーションについて定義されていることを確認する必要があります。 ノード内に定義されているすべてのプロパティとアクションもコピーされます。 テンプレート定義間でノードとそのプロパティをコピーする手順は、以下のとおりです。
タスクおよびイベント用途を表示する
タスク アクションやワークフロー イベントを取消しアクションなどによりイベント またはタスク ノードが参照される別の場所を閲覧できます。詳細については、アクション カテゴリを参照してください。
タスク またはイベント ノードの使用場所を閲覧する手順は、以下のとおりです。
図5-12 [タスクの使用場所] ダイアログ ボックス
変数に関する作業
各ワークフロー テンプレート定義には、関連した一連の変数を割り当てることができます。変数は、ビジネス オペレーションから返された値、XML ドキュメントから抽出された値、あるいはワークフロー アクションにより明示的に設定された値を持つことができます。また、変数は、分岐ノードの条件の評価、Worklist クライアント アプリケーションからのレスポンス結果の保存など、ワークフローにより他の目的に用いられることもあります。
すべてのワークフロー テンプレート定義に変数が必要なわけではありません。しかし、変数が必要な処理を含むワークフロー テンプレート定義については、ノード プロパティやアクションなどの他のワークフロー コンポーネントの定義を開始する前に変数を定義したり、または設計プロセスで変数を追加したりできます。
ワークフロー変数の適用範囲はワークフロー全体です。つまり、単一の変数はワークフロー テンプレート定義インスタンス内のすべてのオブジェクトによって共有されます。よって、変数はフォルダ ツリーのワークフロー テンプレート定義レベルで定義され、ワークフロー変数と呼ばれます。
変数は、次のいずれかのタイプとなります。
注意: 変数タイプに対してplug-inが定義されている場合、追加の変数タイプが選択可となる場合があります。 注意: 上記の表に示した初期値は、サーバのスタートアップ スクリプトの設定によって決められたものです。この設定を修正して、すべてのデータ型の初期値を NULL に変更できます。詳細については、『WebLogic Integration の起動、停止およびカスタマイズ』の「WebLogic Integration のカスタマイズ」にある「Null 変数をサポートする BPM のコンフィグレーション」を参照してください。 さらに、ワークフローが別のワークフローによって呼び出される場合（詳細については、開始のプロパティを定義するを参照）、変数が入力または出力どちらのパラメータとして機能するかを指定する必要があります。入力パラメータは、変数がその値を呼び出し側、つまり親ワークフローから受け取ることを示します。出力パラメータは、呼び出し元のワークフローに返された値を変数が持つことを示します。 さらに、入力パラメータに対しては、このパラメータが必須であるかどうかも指定することもできます。入力パラメータが必須の場合、呼び出し側（親）ワークフローから変数の値が受け取られるまでワークフローは開始されません。値が受け取られない限りワークフローは開始されず、例外が発生します。 呼び出されたワークフローへの値の供給に関する詳細については、サブワークフローを呼び出すを参照してください。 変数の初期値を設定する場合は、ノード内にあるワークフロー変数を設定アクションを用いる（詳細については、変数値の設定を参照）か、開始またはイベント ノードの [変数] タブ、例外ハンドラ、あるいは XML をクライアントに送信アクションを用います（詳細については、イベント データからの変数を初期化するを参照）。 変数がワークフロー式で用いられる場合、変数名の前にドル記号（$）またはコロン（:）、あるいは他の文字が入ります。変数表記の詳細については、変数の使い方を参照してください。 変数を作成する 変数を作成する手順は、以下のとおりです。
図5-13 [変数プロパティ] ダイアログ ボックス
変数を更新する
既存の変数を更新する手順は、以下のとおりです。
変数の用途を表示する
変数がワークフローのどこで用いられるかを閲覧する手順は、以下のとおりです。
図5-14 [変数の使用場所] ダイアログ ボックス
変数を削除する
どのワークフロー ノード、アクション、または式からも参照されていない変数のみ削除できます。参照変数が使用されている場所を閲覧する場合は、変数の用途を表示するの手順に従います。
変数を削除する手順は、次のとおりです。
ノードのプロパティの定義
この節では、特定の各ノード タイプによって、ノードのプロパティを定義する方法について説明します。
開始のプロパティを定義する
各ワークフローには、ワークフローの始まりを示す開始シェイプが 1 つ以上設定されています。開始後、最初のノードは、ワークフローで最初にアクティブになるノードで、タスク、分岐またはイベント ノードのどちらかです。
注意: 開始ノードが指定されていない場合、ワークフローではノードのアクティブ化は行われません。
開始ノードには 4 つのタイプのトリガがあります。
注意: テンプレート定義の作成時、デフォルトの開始ノードは手動開始に設定されています。
以下のような多種の目的で複数の開始ノードを指定することもできます。
注意: シーケンシャルなローリング日時を採用するワークフローを指定して、1 つのフローが終了になると別のフローが開始されるようにする場合は、適切な有効日と終了日を設定して個別のテンプレート定義を行います。詳細については、テンプレート定義に関する作業を参照してください。
最後に開始ノードを用いて、そのワークフローに対して作成された変数を初期化できます。たとえば、開始時の値として 1 を設定したいワークフローにカウンタを設定する場合があります。この値を開始ノードがアクティブになる際にカウンタ変数として割り当てることができます。詳細については、イベント データからの変数を初期化するを参照してください。
開始ノードを定義する手順は、以下のとおりです。
図5-15 [開始のプロパティ] ダイアログ ボックス
図5-16 [ワークフロー変数の割り当て] ダイアログ ボックス
時限開始ノードを定義する
開始日式を指定することで、ワークフローを正確な日時に開始させることができます。ワークフローを開始するには、ワークフローが開始されるオーガニゼーションも指定する必要があります。
たとえば 2 日ごとなどのように、ワークフローが再開されるインターバルも指定できます。この場合、ワークフローのインスタンスはテンプレートの終了日になるまで 2 日 ごとに開始されます。テンプレートの終了日になると、ワークフローはそれ以上開始されません。
図5-17 [開始のプロパティ] ダイアログ ボックス : [時限] オプション
イベントおよびイベントトリガ型開始のプロパティを定義する
ワークフローの開始や、ワークフロー内のノードのトリガはイベントによって行うことができます。イベントは別のワークフローや別のアプリケーションなどの外部ソースからの非同期の通知です。開始ノードはイベントトリガ型として定義され、イベント ノードは外部イベントによってのみトリガできます。
イベント通知は、一般的には JMS (Java Message Service) メッセージに含まれ、JMS キューで受信される XML ドキュメントの形をとります。ただし、プラグインで定義することもでき、その場合イベント通知は XML ドキュメントではなく、カスタムのトリガとなります（詳細については、『WebLogic Integration BPM プラグイン プログラミング ガイド』を参照）。
ワークフローによるメッセージの消費先である WebLogic Integration のデフォルトの内部 JMS キューの JNDI 名は、com.bea.wlpiEventQueue です。ただし、別のメッセージ キューの設定も可能です。詳細については、『WebLogic Integration の起動、停止およびカスタマイズ』の「WebLogic Integration のカスタマイズ」にある「カスタム Java Message Service キューのコンフィグレーション」を参照してください。
XML イベントの型では、実際のトリガは XML メッセージのプロローグで定義された文書型（DOCTYPE）の宣言であるか、または XML メッセージのルート要素であるかのいずれかです。開始またはイベント ノードのプロパティ ダイアログ ボックスで、イベントのトリガまたはワークフローの開始に使用する DOCTYPE またはルート要素を指定します。イベントは、ノードのプロパティ ダイアログ ボックスで指定された DOCTYPE、またはルート要素が着信 XML メッセージのそれと一致しない限りトリガされません。
DOCTYPE またはルート要素の使用に加え、イベント キーやイベント条件で、イベントをさらに修飾できます。そのようなサブワークフローについて以下で説明します。
イベント キーを理解する
イベント キーを使用すれば、開始ノードまたはイベント ノードをトリガすることになる受信 XML メッセージの内容、JMS ヘッダ、またはプロパティの値を指定できます。つまり、特定の DOCTYPE またはルート要素を含むすべての受信 XML ドキュメントにノードをトリガできるのではなく、XML 本体または JMS ヘッダ フィールドに含まれる特定の値に従って受信 XML メッセージのインスタンスをフィルタリングすることで、特定の値を含む XML メッセージ（複数）だけが、実行中のワークフローに含まれるノードをトリガできます。
イベント キーは以下の 2 つの部分で構成されます。
キー値の式は開始ノードまたはイベント ノードの [プロパティ] ダイアログ ボックスで指定します。キー値の式は実行時に評価されるワークフロー式で、そのノードのトリガが可能となるように着信メッセージに含まれている正確なデータを指定します。開始ノードでは、式には一般的に着信 XML ドキュメント あるいは JMS ヘッダに含まれる特定の再帰データを参照する定数が含まれます。イベント ノードの場合、キー式には通常、実行時に一意の値を受け取る変数または関数が含まれています。イベント キーを用いる場合、各イベント ノードは固有のキーを指定します。
キー値の式のサンプルは以下の節で示しており、キー値の式の定義手順は、イベントトリガ型開始のプロパティを定義するおよびイベント プロパティを定義するで説明します。
これは、実行時に着信メッセージのヘッダまたは本文からキー値を返し、それを、開始ノードまたはイベント ノードの対応するキー値の式が必要とするデータ型にコンバートする式です。イベント キー式は、[コンフィグレーション] メニューからアクセスするイベント キー式のダイアログ ボックスで指定します。この式には一般的には、XML ドキュメントを解析するための XPath 言語の式、または JMS メッセージのヘッダから値を抽出するための EventAttribute() 関数の式が含まれています。イベント キー式のコンフィグレーションが行われると、すべてのオーガニゼーションのすべてのワークフローで使用できます。イベント キー式のサンプルは、以下の節を参照してください。また、イベント キー式の設定手順については、イベント キーのコンフィグレーションを参照してください。
注意: ワークフロー式言語の詳細については、ワークフロー式の使用法で、XPath および EventAttribute() 関数の詳細については、実行時のイベント データを抽出するで説明します。
XML コンテンツのイベント キーとして使用する
簡単なサンプルとして、受取勘定アプリケーションから定期的に顧客アカウント情報などを報告する XML メッセージを着信すると想定します。これらのメッセージには他のデータと並んで次の要素を含みます。
コード リスト 5-1 着信 XML ドキュメントのサンプル
<account>
.
.
.
<number>847365</number>
<customer>John Doe</customer>
<balance>
<status>past due</status>
<date_due>7-11-2001</date_due>
<amount_due>5670.85</amount_due>
</balance>
<credit_limit>7500.00</credit_limit>
</account>
残高状態が（「OK」、あるいは「ペンディング」に対し） 「期日到来済み（past due）」である着信ドキュメントのみがワークフローをトリガするよう、期限経過勘定を処理するワークフローがあるとします。最初に、着信ドキュメントのルート要素は、ドキュメントがこのワークフローのトリガとしてみなされるよう、必ず <account> となるよう指定します。次に past due の値に対応するイベント キーを作成します。実行時にイベント プロセッサは、着信 XML ドキュメントの残高状態要素から返された値を、開始ノードで指定した値と比較します。一致した場合、ワークフローがトリガされます。
通常開始ノードは、ワークフローの複数のインスタンスが着信 XML ドキュメントの複数のインスタンスによって開始できるよう、定数をイベント キーとして使用します。一方、ワークフロー内のイベント ノードは、通常、現在のワークフローの別の場所（たとえば、開始ノードの変数初期化時）で取り込まれた特定のデータを含む XML ドキュメントの特定のインスタンスによってのみトリガされる必要があります（イベント データからの変数を初期化するを参照）。この値は設計時には決定できないため、ワークフロー変数または実行時に目的の値を返す関数として表す必要があります。たとえば、イベント インスタンスが正しいアカウント番号（この場合 847365）を含む XML インスタンスによってのみトリガされるように、リスト5-1 のドキュメントを用いてイベント キーがアカウント番号の値を指定することもできます。実行時に、イベント プロセッサは、着信 XML ドキュメントのアカウント番号から返された値を、イベント ノードで指定した式から返された値と比較します。一致した場合イベントがトリガされます。
ここで、キー値およびイベント キー式の構築方法について、このサンプルの状況内で見てみましょう。開始ノードの場合、キー値の式は次のように（ワークフロー式構文で要求されるように引用符で囲まれた）定数で構成されます。
“past due”
イベント キー コンフィグレーションで設定した XML ドキュメントからこの値を返すよう要求されたイベント キー式は次のようになります。
ToString(XPath(“/account/balance/status/text()”))
イベント ノードの場合、キー値の式はワークフロー インスタンスを実行することで早期に設定されたはずの値を持つ（ワークフロー式構文においてドル記号で示される）ワークフローで作成した変数で構成されます。
$AccountNumber
アカウント番号はワークフロー変数の中で文字列として格納され、XML ドキュメントからこの変数を返すためにイベント キー コンフィグレーションで必要になる式は次のとおりです。
ToString(XPath(“/account/number/text()”))
注意: イベント キー式は、開始あるいはイベント ノードでキー値の式によって用いられたものと同じデータ型として評価される必要があります。XPath 式はノード リストのタイプを返すため、通常、正しいデータ型を返すには、ワークフロー式の言語で記述される型キャストを実行する関数を使用する必要があります。これらの関数の詳細については、データ型を変換するを参照してください。返されたデータ型が文字列の場合、XML ドット表記を用いることもできます。詳細については、XML 要素のドット表記を参照してください。
次の図に XML ドキュメントのイベント キーのメカニズムをまとめています。
図5-18 イベント キー メカニズム
イベント キーとして JMS ヘッダまたはプロパティ データを使用する EventAttribute() 関数を用いて、JMS ヘッダまたはプロパティから特定の値を検索することもできます。このメカニズムは XML ドキュメントに対しての場合とまったく同様に機能しますが、XML ドキュメントを解析してターゲット値を探すのではなく、値は JMS プロパティから抽出されます。 たとえば、送信元のアプリケーションがプロパティ フィールドを用いてメッセージの送信元の国を示し（これを Country と呼ぶ）、送信元の国によって開始される複数の異なるワークフローがあると想定します。この場合、イベント キー式は次のようになります。 ToString(EventAttribute(“Country”)) 注意: イベント キー コンフィグレーション式は、開始あるいはイベント ノードでキー値の式によって用いられたものと同じデータ型として評価される必要があります。EventAttribute() 式はオブジェクト型を返すため、正しいデータ型を返すよう、ワークフロー式言語で与えられる型キャスト関数を用いる必要があります。これらの関数の詳細については、データ型を変換するを参照してください。 カナダに関連する情報のみを処理するワークフローの場合、開始ノードのキー値式は次のようになります。 “Canada” このメッセージには、Province と呼ばれるプロパティも含まれているとします。開始ノード内でこの情報を抽出し、これを州名を含むよう変数に保存します。ワークフローがインスタンス化されると、その特定の州向けに送られたメッセージのみがワークフローの別のイベント インスタンス（たとえば、売上税の値を算出するビジネス オペレーションの呼び出しなど）のトリガに用いられるようにします。この場合、州のイベント キーを作成します。イベント キー式は次のようになります。 ToString(EventAttribute(“Province”)) キー値の式は変数名で構成されます。 $ProvinceName イベント条件を理解する イベントまたは開始ノードのトリガをさらに修飾するために評価する必要のある条件を指定できます。これによりイベント プロセッサがイベント キーの一致を識別しても、条件が満たされるまではイベントがトリガされません。 注意: イベント キーなしでイベント条件を用いることはできますが、これは推奨されません。イベント キーのメカニズムでは、メモリに目的の値を格納し、着信 XML ドキュメントにおける DOM 解析が軽減されるため、単純なイベント条件に比べ、はるかに優れたパフォーマンスを提供します。イベント条件は、イベントをトリガする XML メッセージ インスタンスをさらに制限する場合に、イベント キーと共に追加フィルタとしてのみ使用します。 リスト5-1 で示した XML ドキュメントのサンプルを用いて、ワークフロー内に期日到来済みで特定の額（たとえばアカウントのクレジット限度の 75%）以上の残高があるアカウントのクレジット凍結を発行するイベントがあると想定します。ワークフローでは、既に <amount_due> および <credit_limit> 要素から値を抽出し、2 つの変数 Amount_Due および Credit_Limit に格納しています。残高がクレジット限度の 75% を超えた場合にのみイベントをトリガする（および、クレジットの凍結を実行する）ための条件として次の式を用いることができます。 $Amount_Due > .75 * $Credit_Limit リスト5-1 に示すドキュメント インスタンス サンプルの場合、条件は true として評価され、イベントがトリガされます。 また、イベント条件で XPath() および EventAttribute() 関数を用いて、XML または JMS ヘッダまたはプロパティ データからコンテンツを直接抽出して、それを定数、変数あるいは他の関数を含む他のデータと比較することもできます。前出の国の例では、送信元の国が指定した国である場合にのみ、イベントが実行されました。国情報が <country> などの XML 要素に埋め込まれていることを想定すると、条件は次のようになります。 ToString(XPath(“/root_element/child_element/country/text()”)) = “Canada” 国の値が Country と呼ばれる JMS プロパティに埋め込まれている場合は、条件は次のようになります。 ToString(EventAttribute(“Country”)) = “Canada” 注意: XPath() または EventAttribute() などの関数で条件を用いる場合は、両方程式にある式は同じデータ型として評価されなければならず、同じデータ型でない場合、条件が処理できないという点に注意してください。Studio の型キャスト関数の詳細については、データ型を変換するを参照してください。また、文字列値に XML ドット表記を用いることもできます。詳細については、XML 要素のドット表記を参照してください。 イベント データからの変数を初期化する 開始 およびイベント ノードのプロパティ ダイアログ ボックスには、ワークフロー開始時またはイベントのトリガ時に値を設定する変数の追加、更新あるいは削除に用いることのできる [変数] タブがあります（変数の詳細については、変数に関する作業を参照）。 図5-19 開始およびイベント ノードの [プロパティ] ダイアログ ボックスの [変数] タブ
[追加] をクリックすると [ワークフロー変数の割り当て] ダイアログ ボックスが表示されます。ここでは、ワークフローに対し既に定義された変数に値を割り当てることができます。定義済みの変数は [変数] ドロップダウン リストに表示され、ここから初期化する変数を選択できます。 図5-20 [ワークフロー変数の割り当て] ダイアログ ボックス
注意: [アクション] タブのワークフロー変数を設定アクションを用いても同じことができます。実際、開始あるいはイベントを除くすべてのノードに対して、あるいは XML ドキュメントを XML 変数に割り当てる場合は、必ずこのアクションを用いる必要があります（詳細については、変数値の設定を参照）。ただし、ワークフローの実行時、開始またはイベント ノードでは [変数] タブに指定されている変数はアクションが実行される前に [アクション] タブに加えられた順番で初期化されます。 この機能は、開始ノードで用いてワークフローの開始時に変数を定数値に初期化することもできますが、複数の変数値を設定するために用いられる着信イベント データの取り込みに用いることが最も便利と言えるでしょう。たとえば、ノードが JMS メッセージの着信 XML ドキュメントによってトリガされる場合、複数の式を用いて、変数をドキュメントに含まれる値あるいは JMS ヘッダまたはプロパティ フィールドで指定された値に初期化できます。 また、XML ドキュメントや JMS プロパティから現在のワークフローに渡されるインスタンス ID やテンプレート名など、他のワークフローのトラッキング属性を用いることもできます。たとえば、後に対話を開始したワークフローへのメッセージ応答で使用したい場合、これらの値を抽出して、それを変数に格納する必要があります。また、このメカニズムによって JMS トピックまたはキューを通じて外部アプリケーションに配信されるメッセージの単一の JMS プロパティ ヘッダで送ることのできる複数のワークフロー属性を集めることもできます（アドレス メッセージングおよび JMS プロパティとしてのワークフロー属性の挿入に関する詳細については、JMS トピックまたはキューへの XML メッセージのポストを参照）。 変数の値を更新する場合は、リスト内の変数名を強調表示させ、[更新] をクリックして [ワークフロー変数の割り当て] ダイアログ ボックスを開きます。 変数割り当てを削除する場合は、リストから変数名を選択し [削除] をクリックします。 イベントトリガ型開始のプロパティを定義する イベントトリガ型での開始を定義する場合、ワークフローが開始されるオーガニゼーションを指定する必要があります。設計時にオーガニゼーションを指定するか、実行時に、たとえば着信イベント メッセージで指定されたデータを抽出するなどしてオーガニゼーションを決定する式を用いることが可能です。 イベントトリガ型開始ノードを定義する手順は、以下のとおりです。
図5-21 [開始のプロパティ] ダイアログ ボックス : [イベント] オプション
図5-22 [ワークフロー変数の割り当て] ダイアログ ボックス
を使用して XPath Wizard を呼び出し、このウィザードを使ってサンプルの着信ドキュメントから XPath の式を自動的に生成できます。詳細については、XPath Wizard を使用する XPath 式の作成を参照してください。イベント プロパティを定義する
イベント ノードを定義する手順は、以下のとおりです。
図5-23 [イベントのプロパティ] ダイアログ ボックス
図5-24 [ワークフロー変数の割り当て] ダイアログ ボックス
を使用して XPath Wizard を呼び出し、このウィザードを使ってサンプルの着信ドキュメントから XPath の式を自動的に生成できます。詳細については、XPath Wizard を使用する XPath 式の作成を参照してください。分岐のプロパティを定義する
ワークフローでは分岐をいくつでも使用できます。各分岐ノードには条件が指定されています。条件は、分岐ノードに移行するときに評価されます。結果は True または False となり、その結果に基づいて異なるパスに渡されたコントロールのサブシーケンス フローを持ちます。
また、条件の評価の結果が True または False のどちらの場合でも実行するアクションを指定することもできます。[True] タブおよび [False] タブに定義したアクションは、true または false の分岐先に指定されたノードの前に実行されます。また、フォルダ ツリーにおいて、これらのアクションは [分岐] フォルダ内の [True] および [False] フォルダに表示されます。
図5-25 [分岐のプロパティ] ダイアログ ボックス
タスクのプロパティを定義する
タスク ノードは、以下のように定義されます。
タスク ノードはワークフローの基本構成要素であり、フロー内の単一の操作（複数のワークフロー アクションによって実装される必要はある）を表します。
ワークフロー トランザクション モデルでは、ワークフロー ノードは、『BPM クライアント アプリケーション プログラミング ガイド』の「BPM トランザクション モデルの理解」で説明するように、トランザクションがどのように処理されるかを決定するアクティブ化および実行の状態になります。タスク以外のすべてのノードでは、これらの状態は Studio で明示的に表されているものではありません。ただし、タスク ノードでは 4 つのタスク状況のうちのいずれかに従ってアクションを指定する必要があり、フローのコントロールを効果的に操作するには、これらの意味を理解することが重要となります。
図5-26 [タスクのプロパティ] ダイアログ ボックス
タスクの状態を理解する 各タスク ノードは、作成時、アクティブ時、実行時 および Marked Done の 4 つの異なる状態を通じて進行します。各ステータスに対してアクションのリストを指定できる。タスクのステータスが変わると、それに応じて指定したアクションが実行される。次の表では、各タスク状態とそのタスクの到達時に実行されるアクションを示します。
他のノードと異なり、すべてのタスク ノードにノードの完了を知らせるために完了マークを付ける必要があります。マークされない限りワークフローは次に進みません。手動割り当てタスクの場合、実行時にタスクに完了マークを付けることを可能にするパーミッション（以下を参照）を設定できます。ただし、多くの場合、設計時にタスクに完了マークを付けるアクションの追加によって明示的にタスクに完了マークを付けます。 タスクに完了マークを付けるアクションを置くタブは、タスクが 表 5-3 に示されるどの手段によって実行されるかによって異なります。タスクに完了マークを付けるアクションを実行する場合、タスクに完了マークを付けるアクションを [実行時] タブに指定し、実行しない場合は [アクティブ時] タブに指定します。詳細については、タスクに完了マークを付けるを参照してください。 [タスクのプロパティ] ダイアログ ボックスで定義されたアクションは、その配置に従ってフォルダ ツリーの [作成時]、[アクティブ時]、[実行時] あるいは [完了マーク時] フォルダの下に表示されます。 タスク パーミッションについて パーミッションをタスクに割り当て、Worklist (またはカスタム クライアント) ユーザ、あるいは Studio でインスタンスをモニタしている管理者による、実行時のタスクに対して行われる操作の型をコントロールできます。Studio での実行時におけるタスク操作実行に関する詳細については、タスクのパーミッションと優先度の変更およびタスクのステータスと割り当ての変更を参照してください。Worklist での実行時におけるタスク操作実行に関する詳細については、『WebLogic Integration Worklist ユーザーズ ガイド
タスク ノードを作成する場合、デフォルトでは初めから割り当てられているパーミッションはありませんが、次の表に示す有効なタスク パーミッションを有効化できます。
タスクの優先順位について 手動割り当てタスクの場合、優先順位レベルを割り当てることができます。優先度は実行時におけるノードまたはノードの実行方法には影響を与えない。単にタスクを実行したりソートしたりできる Worklist のユーザに応じて表示される。 優先順位オプションは、低、中、および高です。デフォルト値は中です。 タスク ノードを定義する タスク ノードを定義する手順は、以下のとおりです。
結合のプロパティを定義する
結合ノードを使って、タスク、イベント、および分岐ノードの複数の経路を 1 つの経路に結合します。AND 結合の場合、ワークフローはすべてのパスの実行の終了を待ってから次のノードに進みます。OR 結合を使用すると、先行する 1 つの経路の実行が完了した後、その他の先行ノードは実行されずにワークフローは次のノードに進みます。
結合ノードを作成した後で、AND から OR、または OR から AND に変更できます。設計領域内の結合ノードと対応するシェイプは、自動的に更新されます。
図5-27 [結合のプロパティ] ダイアログ ボックス
完了のプロパティを定義する
完了ノードはワークフロー内のプロセス終了ポイントを示します。ワークフロー内の 1 つの完了ノードに到達すると、他の完了ノードに到達したかどうかとは無関係に、ワークフロー内で実行中のインスタンスは完了とマークされます。
ワークフローでは完了ノードをいくつでも指定できます。ワークフローがさまざまなポイントから終了できる場合は、必要に応じてどこにでも個別の完了ノードを配置することが可能になります。
完了ノードにアクションを追加することはできますが、推奨はされません。
完了ノードを定義する手順は、以下のとおりです。
図5-28 [完了のプロパティ] ダイアログ ボックス
例外ハンドラに関する作業
例外ハンドラはサーバの例外の発生によってトリガされ、例外ハンドラの呼び出しアクションによって呼び出されて、メイン ワークフロー内のアクションのサブフローのように機能します。例外ハンドラの定義と呼び出しに関する詳細については、ワークフロー例外の処理を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
