第2章
この章では、第1章に示した抽象的な概念をより具体的に説明します。まず、Composer Process Serverによって実装されるランタイムフローのしくみを検証し、次に、さまざまな使用ケースと設計パターンをProcess Designerでどのように実装できるかについて説明します。
Process Serverの基本的な実行アルゴリズムを理解することは、プロセスの設計方法を理解するために必要です。
Process Server (またはランタイムエンジン)では、次のようにプロセスインスタンスが実行されます。
プロセスがスポーンイベントから非同期的に呼び出された場合、Process Serverは、新しいプロセスをインスタンス化すると、ProcessID (「受信者反応」)を呼び出し側にただちに返します。それ以外では、プロセスがコールによって呼び出された場合、呼び出し側はそのプロセスが終了するまでブロックすることが想定されます。
アクティビティ(開始アクティビティであるかどうかにかかわらず)が終了すると、Process Serverにより、アクティビティの「終了条件」が確認され、関連付けられているXPath式が評価されます。終了条件がfalseと評価された場合、(前回と同じ入力で)アクティビティが再実行されます。タイムアウトに達するか終了条件がtrueと評価されるまで、実行が繰り返されます。これについては、次の図を参照してください。
完了したアクティビティの終了条件がtrueの場合、Process Serverでは、アクティビティの発信側に接続されているコントロールリンク(存在する場合)が特定され、そのコントロールリンクのトランジション条件が評価されます。
トランジション条件がtrueである各コントロールリンクに対して、Process Serverによりリンクターゲットの結合条件が評価されます。この評価は、結合が延期モード(デフォルト)になっている場合、すべてのリンク条件が評価された後で1回だけ行われます。結合が即時モードの場合、結合条件は複数回評価されます(リンクの真の値が計算されるたびに1回)。つまり、リンク条件が評価されると、値がfalseである場合でも、エンジンによってただちに結合条件が評価されます。
結合条件がtrueと評価された場合はターゲットアクティビティが起動され、trueでない場合は起動されません。
注記: 同期モード(即時/延期)にかかわらず、結合のターゲットは、結合条件がある時点でtrueにならない限り起動されません。
リンクのターゲットアクティビティの実行が完了すると、手順5からサイクルが再び開始されます。実行は、処理対象がなくなるまで続行されます(つまり、終了アクティビティの終了条件すべての真の値がわかるまで)。
次の図は、「スポーン」で呼び出されたプロセスインスタンスの一般的なプロセス起動のしくみを示します(呼び出し側は、「実行後削除」するという方法でプロセスを呼び出すことを選択しています)。
ランタイムエンジンは、特定のプロセスモデルによって使用されるアクティビティや、これらのアクティビティ間のリンクおよびデータマッピングなどを認識する必要があります。これらの情報は、すべてプロセスグラフで設計時に指定する必要があります。これにはProcess Designerを使用します。
Process Designerは、プロセスのグラフィック表現を作成したり、プロセスのアクティビティ間のデータ関係を指定したりするための視覚的な編集環境です。これを実行するためのツールとして、マウス操作による「レイアウトツール」とテキストベースの「プロパティシート」(モードレスダイアログボックスのように機能します)を組み合わせて使用します。Process Designerに固有なこれらのGUI機能の他に、Composerのコンポーネントやサービスを作成する場合にも同じく使用するComposerの標準のメニューコマンド、ナビゲーションフレーム、マルチドキュメントコンテンツフレーム、および出力フレームがあります。つまり、Process Designerは、完全にComposer内で動作します。
単純な2つのアクティビティのプロセスのProcess Designerビューは、次のようになります。
この場合、アクティビティアイコンはComposerコンポーネントを表しています。2つのアクティビティはリンクによって接続されています。菱形のリンクは、カスタムのトランジション条件がリンクに指定されていることを意味します(カスタム条件がないリンクには菱形のアイコンは表示されず、単に「Link」という語が表示されます)。
この図におけるActivity1はソースアクティビティ、Activity2はターゲットアクティビティと呼ばれます。
このグラフを見ると、Activity1にカスタムの終了条件があるかどうか、再試行プロトコルがいずれかのアクティビティに適用されるかどうか、マッピングポリシー(Last Writer Winsなど)がActivity2への入力に適用されるかどうかなどが明確ではなく、メッセージパートがアクティビティ間で実際にどのようにマップされているか判断できません。このグラフでは、制御フロー関係は明確率直で直感的に示されていますが、データ関連情報は表されていません。
データリンク情報は、次の図に示されているように、コンポーネントベース、メッセージベース、およびUIベースの情報用にタブが含まれている、モードレス(およびドッキング可能)な［オブジェクトプロパティ］パレットから取得できます。
このグラフでは、Activity1に焦点が置かれているため(周りにハンドルが示されています)、［オブジェクトプロパティ］パネル(または「プロパティシート」)には、Activity1に該当する情報が表示されています。(マウスで［Activity2］をクリックすることによって) Activity2に焦点を置いた場合、［オブジェクトプロパティ］パネルが更新され、このアクティビティに固有な情報が表示されます。同様に、［Link1］をクリックすると、パネルにはこのリンクに固有な情報が表示されます。これらのパネルはリアルタイムで自動的に更新されるため、いつでも任意のグラフ要素の情報を確認できます。ただし、情報は単なる読み込み専用ではありません。［オブジェクトプロパティ］パネルのフィールドは、データ関連およびアクティビティレベルの属性値を指定する場所です。
［コンポーネント］タブ（前の図を参照）では、アクティビティレベルの情報を表示できます。このような情報には、アクティビティの名前とタイプ、コンポーネントのタイプ（この場合は「Webサービス」）、コンポーネントの名前、その終了条件と結合条件（存在する場合）、再試行情報、およびマップポリシーが含まれます。これらの値の一部は、正しい選択肢がすでに入力されているドロップダウンメニューを使用して設定できます（前の図を参照）。他は、パネルに直接値を入力できるテキストフィールドです。
［メッセージ］タブをクリックすると、焦点が置かれているアクティビティのデータ関連情報を表示できます。
このパネルの上部には、アクティビティの入力メッセージと出力メッセージに対するプロセス固有の「名前」だけでなく、サービス(つまり、アクティビティの実装)についてWSDLで指定されたタイプとメッセージの具体的な説明も表示されます。つまり、［タイプ］および［メッセージ］フィールドには、WSDL portTypeセグメントから取得された値が自動的に入力されます。
パネルの下部では、(XPathを使用して)どのソースメッセージパートをどのターゲットメッセージパートにマップするかを正確に指定できます。直前の図は、以前に示したフローグラフのActivity2に適用し、Activity2に対する入力がどのように構成されるかを示します。この場合、ソースXPathは、Activity1の出力メッセージパートがActivity2の入力パートに直接マップされることを指定しています。これは、Activity2が起動されると、Activity1出力がその入力として使用されることを意味しています。これは明らかに単純なケースですが、Activity1の出力メッセージパートからActivity2の入力パートへの複雑なXPathマッピングが多数存在する場合もあります。
［オブジェクトプロパティ］パネルについては、後で詳しく説明します。ここでは、［オブジェクトプロパティ］パネルで次の情報を指定できるということを理解していれば十分です。
アクティビティタイプ(Webサービス送信、Webサービス受信、Composerコンポーネント、サブプロセス、またはサブプロセスの同期化)
複数の着信ソースからのデータが同じターゲットメッセージパートにマップされる状況におけるマップポリシー(または上書きポリシー)
WSFLモデルは、(フロー意思決定を「XOR分割」のようにさらに高レベルの構成要素に集約するのではなく)リンクと結合のレベルでフローロジックを「細粒化」しようとするため、(Composer Process Managerが後に続くように)WSFLベースの方法を使用して条件付きブランチや他の一般的な制御フローパターンを指定する方法は必ずしも明確ではありません。ただし、Composer Process Designerを使用すると、実質的には、考えられるすべてのフローロジックをモデリングすることが可能です。
この節では、より一般的なフロースタイルの一部と、それらをProcess Designerでどのように実装できるかについて説明します。
多くのワークフロー専門家は、ブランチロジックおよび結合ロジックを考慮することを習慣としています。この節ではまずブランチパターンについて説明し、結合パターンは次に説明します。
WSFLには、それ自体では条件付きブランチの概念はありません。つまり、アクティビティは、アクティビティの発信側に複数のリンクがある場合、使用するリンクを独自に決定することはできません。代わりに、使用されるリンクは、「リンク自体」によって決定されます。ただし、各リンクは、他のパラレルリンクのトランジション条件を認識することはできません。リンクからは、前のアクティビティの出力に基づいて、そのパスをたどる必要があるかどうかということのみ決定されます。
ただし、条件付きブランチをモデリングするためには、このフロー制約メカニズムで十分です。たとえば、次の図のようになります。
このシナリオでは、ある会社の見積もり情報を含む出力がActivity1により生成されます。Aのリンク条件は、/Bidが1000未満の場合にリンクAが使用されることを指定しています。また、Bの条件は、/Bidが1000以上の場合にリンクBが使用されることを指定しています。当然のことながら、1つのリンクが使用されるともう1つのリンクは使用されないため、これは排他的OR分割(またはXOR分割)という条件付きブランチを表しています。
AND分割ケース(常に「すべての」発信リンクが使用される)は、Process Managerモデルのデフォルトの動作を表します。
ここで定義されているAND分割は、各発信リンクによってそのターゲットアクティビティが「起動」される場合です。これは、各リンクの値がtrueであることを意味しています。
複数の発信リンクがあるアクティビティが、(出力データに基づいて)任意の数のターゲットアクティビティを起動できる場合があります。例えば、「何かがtrueの場合はActivity1を起動し、別の何かがtrueの場合はActivity2も起動し、さらに別の何かがtrueの場合はActivity3も起動する」というような条件が挙げられます。ランタイム時に実際に起動されるアクティビティの数は、0、1、2、または3です。
このケースも、分配されているリンクロジックによって簡単に処理されます。各リンクは、ソースアクティビティの出力を「参照」し、起動するかしないかについての決定に達するために適切なXPathロジックを適用することができます。そして、最後には、適切な数のターゲットアクティビティが起動されます。
前述のパターンを組み合わせることにより、「リンクA、B、およびCは常に使用し、Dは条件を満たす場合に使用し、EはDが使用されなかった場合にのみ使用する」というような複雑なケースを処理できます。このケースを実装するには、次のように設定します。
擬似コードでは、最終的な結果(ターゲットアクティビティを起動するリンクに関して)は次のようになります。
(A AND B AND C) AND (D OR E)
他の複雑なケースを実行することも可能です。ただし、複合ブランチ方法に深入りする前に、このような複雑な構成は全体的にできるだけ使用するべきではない理由について、一歩下がって理解することが重要です。
プログラミングでは、複雑なものは、プロシージャまたはコードブロックがさらに小さなロジック単位に分解される必要があります。Javaコードでは、多くのANDやORが連結された条件はまれです。これは、必要なアクションは通常、単一のswitch/caseブロック、または単純な条件の一連のif/elseで実行できるためです。データの従属性が複雑すぎるために実行できない場合、従属性自体を分解してロジックを単純化する必要があります。複雑なデータによって入り組んだロジックが決定されないことが必要です。
米国取得税法には、複雑なデータの従属性に関して入り組んだロジックの適例が多数あります。内国税歳入庁では、誰でも正しく入力できる納税申告用紙を毎年作成しなければなりません。内国税歳入庁は、まず主な従属性をサブジェクトグループに分解し、それぞれに個別の専用用紙(または「スケジュール」)を用意します。各用紙内には、計算をグループ化する主な区分(部分)があります。この主な部分は、単純なif/elseステートメントにさらに分解されます。if/elseステートメントの一部は、評価される前に完了する必要のある他のスケジュールを参照します(これらの各スケジュールは、部分ごとにグループ化された一連のif/elseステートメントです)。当然のことながら、各納税申告用紙では、理論上、用紙の上部で「単一の複合式」としてif/elseロジックをすべて示すことができます。ただし、このような単一ステートメントプロシージャは納税者は読むことができません。
複雑なブランチが必要な場合、作成しているモデルをより単純なロジック単位に分解する必要があることを表します。
リンクロジックは、ターゲットアクティビティが実際に起動されるかどうかについてではなく、ターゲットアクティビティを起動できるかどうかを決定します。アクティビティが起動されるどうかは、結合条件によって最終的に決定されます。
延期モード(デフォルト)では、結合条件は評価されません。このため、結合アクティビティは、アクティビティの着信リンクの「真の値」がすべてわかるまで起動できません。すべてのリンク値が認識されると、結合条件が評価されます。ターゲットアクティビティは、結合条件がtrueの場合にのみ起動できます。
即時モードでは、結合条件は、ランタイムエンジンによってリンクの真の値が決定されるたびに評価されます。このため、1つのターゲットアクティビティに対して着信リンクが4つある場合は、アクティビティの結合条件が4回別々に評価される可能性があります。結合条件がtrueであること(および変更できないこと)が明らかになるとすぐに、ターゲットアクティビティが呼び出されます。
注記: 前の章で説明したとおり、結合ロジックは、XPathが使用されない、プロセスモデルにおける唯一のロジック接点です。リンクと終了条件は、アップストリームデータにアクセスでき、意思決定はXPath評価に基づきます。結合条件では着信リンクの真の値のみ認識されます。また、XPathを使用することはなく、データ駆動型でもありません。
結合条件は、次のようになります。
(Link1 OR Link2)
これは、単純な非排他的OR条件で、1つのリンクまたは両方のリンクがtrueの場合に結合がtrueであることを意味します。
排他的OR条件(つまり、1つのリンクのみがtrueの場合に条件がtrueになる)は、次のようになります。
(Link1 AND NOT Link2) OR (NOT Link1 AND Link2)
この場合、「いずれ」のリンクからもアクティビティは起動できますが、両方のリンクがtrueの場合、アクティビティは起動されません。この条件が目的どおりに機能するには、結合は延期モードである必要があります。
結合条件は、ターゲットアクティビティを起動するために必要なリンク値の数(およびその正確な組み合わせ)を決定するためのメカニズムとして考慮できます。リンクは、他の(兄弟)リンクが存在しているかどうか、またはどの兄弟がtrueと評価されるかを認識できないためこれは重要です。この知識は、結合にのみ存在します。
場合によっては、特定の条件を満たすまで、あるアクティビティを繰り返す必要があります。たとえば、ある種のバッチ操作を実行するとします。一般的な傾向として、ターゲットからソースの1つに戻るリンクを描画します。ただし、このような制御フロー(再入可能フロー)は、WSFLでもProcess Designerでも許可されていません。サイクリックグラフを作成しようとすると、次の警告が表示されます。
アクティビティの繰り返しは、プロセスロジックレベルにおいてではなく、アクティビティの実装(または、呼び出しアクティビティの実装)によって行う必要があります。
プロセスモデルでループが許可されていない理由は、ループすると、管理が困難なあいまいな状況を導いてしまうためです。たとえば、DからBに戻るループリンクがある次の制御フローグラフについて考えてみるとします。この場合、ランタイムエンジンは、いくつかの難しい決断を下す必要があります。
Bは、AおよびとDという2つのアクティビティの入力がある結合ノードです。 延期モードの場合、Bは、その結合条件が評価される前に、「両方」の着信リンクが真の値を持つまで待機する必要があります。ただし、DではBとCが先に実行されることを必要とするため、Dが実行されない限りBは実行できません。Dが実行されるのをBが待機している間、モデルはハングします。Bの結合は、即時モードでのみ機能します。
Cは、B-C-Dループの一部として、複数回実行します。Cが実行するたびに、CからEへのリンク(およびCからDへのリンク)が使用され、Eは、そのリンクがtrueと評価された場合は繰り返し起動されます。このため、Eは、自動的にループの一部になる場合があります。これを避けるには、Eの入力リンクに対するリンクロジックが、ループの繰り返しステータスを認識している必要があります。
Eが複数回実行されると、Gが複数回実行される可能性があります。このため、Gも、ループについて認識している必要があります(Eのダウンストリームの全アクティビティも同様)。
これらの問題が解決しても、このようなモデルの「テスト」(および、その後のデバッグ)は困難である場合があります。
Process Managerでは、いくつかのループのパラダイムが考えられます。WSFL固有の「終了条件がfalseの場合に再試行する」というメカニズムに依存するものもあれば、アクティビティ実装にループを委任するものもありますが、非同期ファンアウトに役立つ特別なProcess Managerアクティビティがあります。
Process Managerでは、ループにコントロールリンクを使用することは許可されていませんが、アクティビティの「出力」をデータソースとして指定し、再試行イベントで「入力」に使用することはできます。WSFLおよびProcess Managerの標準の動作は、アクティビティの終了条件がfalseである場合にアクティビティを試行することであるため、これはループの1タイプです。出力を入力にマップすることによって、アクティビティは、終了条件がtrueになるまで、必要に応じて独自の出力をループできます。終了条件がtrueになると、ループは停止し、制御は配信リンクを下へと順に進みます。このシナリオは、次のように図式で表すことができます。
Activity2には、Activity2InOutという名前の入力メッセージの他に、入力メッセージと同じ名前の出力メッセージがあります。Activity2は、falseという終了条件で終了した場合、Activity2InOutを使用して再実行します。ただし、Activity2InOutのデータは、ループの一部としてアクティビティの最初の実行で変更されています(データベースルックアップの新しい情報がDataドキュメントに追加されている可能性があります)。 どのような場合においても、Activity2の終了条件は、出力DOMのフラグ値を検査するXPath式である可能性があります。フラグ値は、再び繰り返すかループを切るかのいずれかの必要性を示します。
このようなマッピングを実装するには、ループアクティビティの出力メッセージと入力メッセージに同じ名前を付ける必要があります(次を参照)。
Activity2の最初の呼び出しでは、Activity2InOutにActivity1Output/Outputのデータが入力されます。終了条件がfalseであるためにActivity2が再実行すると、Activity2InOut (データがすでに入力されている)は単にアクティビティに返されます。
注記: このようなマッピングをセットアップする際には、ループアクティビティに終了条件(ループを正常に終了する条件)を忘れずに適用してください。適用しない場合、無限ループが発生する可能性があります。
前に説明したループのタイプは、ループを通じた各トリップで新しいデータが出力に追加され、ループ結果を含む出力ドキュメントが段階的に作成され必要がある場合に便利です。ただし、ワークアイテムをキューから取り出し、最終出力ドキュメントのデータが「それ自体で」統合されることなく、一度に1つずつ(ループ内のトリップごとに1つのワークアイテム)処理する必要がある場合もあります。
出力としてワークアイテムのバッチを生成する開始アクティビティがプロセスにあるとします。各アイテムは、この目的のために設計された特定のアプリケーションによって「個別に」処理される必要があります。これは、処理アプリケーションが複数回(ワークアイテムごとに1回)呼び出される必要があることを意味します。考えられるプロセスモデルは、次の図のとおりです。
このシナリオでは、Activities2およびActivities3はComposer JMSコンポーネントですが、キューの代わりにデータベースを使用するJDBCコンポーネントでも可能です。他の外部ストアにも同じ概念を適用できます。要点は、Activity2が(WSDLメッセージとしてパッケージ化された)データのバッチを入力として受信するということです。Activity2は、入力を切り離し(および可能性として入力に何らかの事前処理)を実行します。また、各ワークアイテムをメッセージキューにプッシュします。Activity3がそのキューを検査します。
この例では、Activity2からの出力には(メッセージパート内の要素に)JMSDestinationが含まれます。これは、Activity3が操作すべき対象のキューの場所を表します。「ワークアイテムカウント」はActivity3に渡される必要はありません(Activity3は、1つのワークアイテムを取得して処理するように設計されています)。
Activity3では、次の処理が実行されます。
1つのJMS受信アクションが実行されます。このアクションにより、待機中のメッセージがキューからプルされるか、キューが空であることが認識されます。
メッセージがキューから正常にプルされると、そのデータが処理され、アクティビティは、再び実行されるように終了条件がfalseとして終了します。
メッセージが取得されなかった場合(つまり、JMSMessageIDが空で返された場合)、アクティビティは条件がtrueとして終了します。
Activity3の終了条件は、JMS受信が成功したかどうかに基づきます。メッセージが処理された場合、Activity3が再び実行されるように終了はfalseになります。メッセージが処理されなかった(つまり、キューが空であるためにアクティビティは何もすることがない)場合、条件はtrueになり、Activity3はプロセスフローの次のアクティビティに制御を渡します。
このパターンはサイクリックグラフを必要とせず、後方リンクに対するWSFLの制限に違反することもありません。これは、「間違った方向を指す」コントロールリンク、つまり再入可能性は存在しないためです。Activity3の「終了条件」は、特定の条件を満たすまでfalseとなるため、Activity3の実行は繰り返されます。「JMS送信」および「JMS受信」というラベルの付いた矢印は、プロセスモデル外のデータフローを表しています。データは、どのメッセージマップにも入りません。
前述の方法の代わりとして、アクティビティの実装内のループ動作を非表示にすることができます。たとえば、「コンポーネントの実行」アクションと「Repeat While」アクションを使用するComposerサービスを作成して、Whileループで特定のコンポーネントを繰り返し呼び出ことができます。この方法では、ループ繰り返しのいずれの部分もProcess Serverで管理する必要はありません。
図に示されているとおり、このフローグラフは、Composerコンポーネントに呼び出されるInventoryLookupが、プロセスエンジンではなくActivity2のアクションモデルによって呼び出されるということ以外は、前と同じです。
ワークアイテムは、一度に1つずつ処理するのではなく、「パラレルに(並行して)」処理すると効率的です。同時処理では、パフォーマンスが大幅に向上することがよくあります。
複数の同時プロセスをスポーンすることと「ファンアウト」と呼びます。設計パターンは、次のようになります。
ファンアウトアクティビティは、ワークのバッチを受け取ると、ワークアイテムを切り離し、適切なターゲットサブプロセスの複数のインスタンス(ワークアイテムごとに1つのインスタンス)をスポーンします。サブプロセスは「DetermineQuantityOnHand」のように呼ばれ、バッチはSKU番号の集合である場合があります。各SKU番号に対して、DetermineQuantityOnHandのインスタンスが1つ作成されます。
サブプロセスの各インスタンスは、WSFL定義の「スポーン」メカニズムによって呼び出されます。つまり、各インスタンスが独自のスレッドで実行されることを意味します(パラレルインスタンスは同時に実行され、別々に終了します)。
このシナリオが正しく機能するためには、サブプロセスの各インスタンスから出力を収集し、プロセスグラフの次のアクティビティに制御を渡する前にすべてのインスタンスが終了するまで待機する「ファンイン」アクティビティが必要です。これを行うアクティビティは、前の図でConsolidatorアクティビティとして表示されています。
サブプロセスの各インスタンスはが終了すると、データがマージコンポーネントに渡されます。マージコンポーネントでは、渡されたデータが収集され、(通常は)1つの最終ドキュメントにマージされます。サブプロセスのインスタンスがすべて取得されると、マージコンポーネントの終了条件はtrueになり、グラフ内の次のポイントに制御が渡されます。
このパターンをフローグラフに実装する場合には、2つの問題点があります。1つ目の問題点は、ランタイム時に任意の数の発信リンクを作成するためのネイティブメカニズムがWSFLにはないことです。2つ目の問題点は、ランタイム時にのみ認識される数のリンクを作成できると想定したとしても、同期の処理に必要となるこのような遅延バインディング結合ロジックを指定するためのネイティブ機能がないことです。
幸いにもこれらの問題は解決することができます。
1つの方法は、コンポーネントの実装でファンアウトを非表示にすることです。コンポーネントのアクションモデルに、バッチで繰り返す「Repeat While」ループが含まれており、各ワークアイテムで「プロセスの実行」アクションが呼び出されるとします。「プロセスの実行」アクションで「スポーン」の実行メソッドを指定すると、各プロセスは独自のスレッドで起動され、実行後削除されます。役立つプロセスインスタンス(「faneeプロセス」)は、結果をデータベース、JMSメッセージキュー、または他の外部ストアにポストするように設計できます。同期は、2番目のコンポーネント(「consolidator」)によって処理されます。「同期コンポーネント」は、リスナ例または定期ポーリング例のいずれかに従うことができます。後者のパターンを使用する場合は、連続ループで、またはデータのクエリ間にコンポーネントがスリープする時間ベース(CPUへの負荷が少ない)でポーリングを実行できます。一方、リスナ例は、JMSサービスを使用して簡単に実装できます。
ファンアウトは、再帰的グラフを使用してWSFLでモデリングできます。つまり、ファンアウトは、適切な数の「fanee」アクティビティが呼び出されるまで(呼び出されると、結果が結合によって累積されます)「それ自体を呼び出す」プロセスとしてモデリングできます。再帰的なファンアウトプロセスは、次のような図式で表されます。
アルゴリズムは、次のように要約できます。
ワークのバッチを取り込みます。「バッチ」に複数のワークアイテムが含まれている場合は、さらに小さな2つのバッチに分割され(つまり、前の図に示されているLink5が使用される)、これらの小さなバッチを入力として使用して新しいインスタンスが起動されます(つまり、Link3とLink4が使用され、DoBatchの2つの新規インスタンスが起動されます)。DoBatchの新しいインスタンスのこの再帰的な呼び出しは、着信バッチが分割できなくなるまで続行します。
着信バッチに「1つ」のワークアイテムが含まれている場合は、Link1を使用します。Link1のターゲットは、このワークアイテムを実際に処理するコンポーネント(ProcessWorkItem)です。
ProcessWorkItemアクティビティの出力は、その後必要となる処理や戻りを行うOutputBatchに渡されます。
DoBatchインスタンスの戻りが再帰的に呼び出される場合は、その発信リンク(Link6またはLink7のうち該当する方)が使用されます。その後、遅延結合がMergeBatchで行われます。
MergeBatchコンポーネントでは、Link6およびLink7から到着したデータを、OutputBatchに送信される1つの出力メッセージに累積します。戻り/マージ/戻り/マージのサイクルは、処理済みのワークアイテムがすべて累積されて1つのメッセージ(ドキュメント)にまとめられるまで続行します。
グラフの一番上にあるリンクロジックは、TakeInBatchからの分割を効果的に排他的OR分割にします(これにより、Link2およびLink8も互いに排他的になります)。アルゴリズムは、基本的に「分割またはワーク」のうちの1つです。ProcessWorkItemアクティビティには、バッチが個々のワークアイテムに分割されるまで到達しません(このアクティビティに到達すると、対応する数のProcessWorkItemインスタンスが起動されます)。出力ドキュメントは、最初に2x2、次に4x4のように、プロセスの最終出力が1つのまとめられたドキュメントになるまでマージされます。
これは、単純な個別の操作を使用してダイナミックなサイズのタスクを実現する、十分に分解された設計の例です。フローは、通常のWSFL構成要素を使用して明示的に図式で表すことができ、アクティビティレベルの実装では(ビジネスロジック以外は)すべて表示されます。すべてのデータは、通常のデータリンクを通って移動します(外部ストアを通した特殊な「グラフ外」の通信はありません)。処理はすべて同時で、結合はすべて同期です。
Composer Process Managerのネイティブアクティビティタイプの1つは、「サブプロセスの同期化」と呼ばれる専用のアクティビティです。このアクティビティは、「ファンイン」機能(非同期サブプロセスからの戻りの同期および統合)を提供するために存在しています。
「サブプロセスの同期化」アクティビティを使用するグラフでは、次のパターンが実装されます。
Activity1は、コンポーネントの実装の一部として、「Repeat While」ループ内に複数のサブプロセスインスタンスをスポーンすることによってファンアウトを実行するComposerコンポーネントです(これは、「スポーン」モードと「コール」モードがある「プロセスの実行」アクションによって実行できます)。Activity1はファンアウトを構成します。そして独自のアイコンを持つ「サブプロセスの同期化」アクティビティであるActivity2は、ファンインを構成します。
サブプロセスがスポーンによって呼び出されると、Process Serverにより、フローインスタンスIDが呼び出し側に返されます。Activity1は、呼び出した各サブプロセスのフローインスタンスIDを収集して、「サブプロセスの同期化」アクティビティにIDを渡します。
「サブプロセスの同期化」アクティビティの実装は、Composer XMLマップコンポーネント、JDBCコンポーネント、または他のコンポーネントから構成されます。このコンポーネントでは、前述のフローインスタンスIDのリストおよび照合ドキュメントが入力として受信されます。後者は、「fanee」サブプロセスによって返されたデータを累積するために、ランタイム時に使用されます。このProcess Serverのしくみについては後の章で説明しますが、主要な概念は、faneeが戻るたびにファンインコンポーネント(ランタイムエンジンによって呼び出される)が通知を受け、関連付けられているワークアイテムデータが照合ドキュメントに追加されるということです。faneeがすべて取得されると、コンポーネントは条件がtrueとして終了し、その出力(ワークの完了したバッチ)はモデルにおける次のアクティビティ(複数の場合もあります)にマップされます。
主要な概念の簡潔な要約は、次のとおりです。Process Designerでモデルを作成する際には、これらの概念について考慮する必要があります。
アクティビティには、次の5つのタイプがあります。
Webサービスアクティビティには、2つの種類があります。Webサービスの「送信」タイプでは、WSDLの依頼-応答パターンと通知パターンが処理され、Webサービスの「受信」タイプでは、WSDLの要求-応答操作と一方向操作が処理されます。
サブプロセスの同期化は、ファンアウトの同期に備える(Process Managerに固有な)アクティビティの専用タイプです。
サブプロセスは、任意のComposerプロセスであり、より大きなプロセス内でアクティビティとして使用されます。アクティビティとしてプロセスを使用すると、ビジネスワークフローの「階層型モデリング」が可能になります。
プロセスモデルは、データの流れを調整し、ローカルおよびオフサイトのアプリケーション(ビジネスパートナーによって管理されるWebサービスを含む)の異種混合間を制御します。
開始アクティビティには、着信リンクはありません。また、終了アクティビティには、発信リンクはありません。他のすべてのアクティビティには、1つまたは複数の着信リンクがあり、発信リンクは存在する場合と存在しない場合があります。
アクティビティ間のデータの従属性は、「データリンク」により実装されます。Process Designerでは、データリンクはユーザによって描画されません。データリンクは、あるアクティビティの出力メッセージパートを別のアクティビティの入力メッセージパートにマップすると、自動的に作成されます。
アクティビティ間の時間順の従属性は、「コントロールリンク」により実行されます。コントロールリンクは、ソースアクティビティとターゲットアクティビティを接続します。このリンクにより、ターゲットがソースよりも先に実行されないことが保証されます。この結果、サイクリックグラフパターン(ダウンストリームアクティビティからアップストリームアクティビティに戻るリンクがある)は許可されません。
ワークの同期は、「結合」によって実現されます。
データの条件付きフローは、「リンクロジック」(トランジション条件)によって制御されます。
「フィーダ」アクティビティの完了に基づくアクティビティの条件付きトリガは、「結合ロジック」(結合条件)によって制御されます。延期モードでは、結合条件は、すべての着信リンクの真の値がわかるまで評価されません。即時モードでは、結合条件は、ソースリンクが評価されるたびに評価されます。
データ上書きは、「マップポリシー」を使用することによって制御できます(2つのソースアクティビティが次のアクティビティに対する入力で同じXPathの場所をターゲットにする可能性がある場合)。ポリシーは、Last Writer Wins (着信順の上書き)、First Writer Wins (最初のマッピングは不変で、遅延データは無視)、およびリテラルマップ順のいずれかになります。
再試行の動作は、アクティビティの「終了条件」またはタイムアウト値、あるいはその両方によって制御されます。終了条件がfalseの場合、アクティビティは元の入力を使用して再実行します。アクティビティは、終了条件がtrueになるか、タイムアウトが発生するまで、再実行し続けます。
リンク条件および終了条件は、XPathを使用して指定される必要があります。結合条件にはXPathを使用できません。リンクの真の値に関するブール式によって指定されます。
Process Serverは、プロセスインスタンスの実行を管理するランタイムエンジンで、プロセスのライフサイクルのあらゆるポイントにおける状態の情報やインスタンスのデータなどを保持します。
プロセスは、Process Serverコンソールから監視および管理(一時停止、再開など)できます。
WSFLによって定義されProcess Managerによってサポートされるライフサイクルイベントは、「スポーン」、「コール」、「一時停止」、「再開」、「照会」、および「終了」です。
「一時停止」、「再開」、および「終了」イベントは、Process Serverコンソールから管理的に制御できます。「照会」イベント(ステータスクエリに対するイベント)は、コンソールではそのようにラベルは付けられていませんが、完了ステータス情報がプロセスステータスビューに常に表示されます。「スポーン」および「コール」は、プロセスイニシエータによって制御されます。イニシエータは、要求に応答するSOAPサーバや、「プロセスの実行」アクションを実行したコンポーネントなどである場合があります。
WSFLベースのプロセスモデルの主な特徴は、実装の詳細について互いに知ることなく、認識されているインタフェースに基づいて協力的に通信できる作業単位に依存していることです。このタイプのシステムでは、作業の単位(アクティビティ)には、これらが使用されているコンテキストについての知識はありません(また、このような知識を持つ必要はありません)。アクティビティが認識している必要があるものは、アクティビティに対する「入力メッセージ」にすべて含まれています。
最適なプロセスモデルでは、実装からインタフェースを分離するというこの原則が利用されます。これは、効率的なコードを再使用できるようにするだけでなく、技術、プラットフォーム、パートナーなどの間で相互運用を可能にします。また、トラブルシューティング、テスト、および保守が簡単になります。
適切に設計されたプロセスモデルには、次のような特徴があります。
十分に分解されたアクティビティ層。単一のアクティビティで「やり過ぎ」になることはありません。また、機能的な要件において一体型であるアクティビティはありません。
すべてのアクティビティは、隣接するアクティビティに関する特別な知識なしで、スタンドアロンで実行するよう設計されています。
ビジネスロジックは、アクティビティ実装内で完全に非表示になっています。メッセージマップに使用されるビジネスロジックはありません。
注記: アクティビティ間のメッセージマッピングでは、ある程度の詳細が表示されるべきです。基盤となるXMLの要素レベルでの変換(つまり、非常に詳細なドキュメントの操作)は、プロセスモデル内ではなく、クティビティ実装内で実行される必要があります。
フローグラフは、わかりやすく読みやすいものです。処理できるアクティビティまたは結合の数を超えてグラフが大きくなった場合は、関連アクティビティをサブプロセスに分解することが推奨されます。分割、結合、アクティビティなどが多数含まれているモデルは、テストやデバッグが非常に困難になる場合がありますが、同じモデルでも3つか4つのサブプロセスに分解し、各サブプロセスでアクティビティを3つか4つのみに限定できる場合は、サブプロセスはスタンドアロンでテストし、最終的に統合された1つの強力なモデルに結合することが可能になります。
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...