プロセストークン
Process Token は BPMN の理論的な概念で、Activity の魂を呼び覚ますようです。
元
各プロセス トークンは開始ノードから生成され、プロセスを開始すると、そのプロセス トークンが作成されます。
本人認証のトークンとは異なり、プロセストークンには情報が含まれていません。下の図に示すように、Start Process の後、タスク A の左下隅に青い 1 が表示されます。これは、 Process Tokenに対して Camundaによって作成された視覚化です。
アクティビティ
簡単に言えば、ワークフロー内の角の丸い四角形はそれぞれアクティビティを表します。Process Token が到着する前はすべてInactive状態ですが、Process Token が到着すると下図のタスク A のようにReady状態に活性化されます。
ユーザー タスクの完了
Camunda の TaskList パネルでユーザー タスクを終了し、一連の変数を後続のプロセスに渡すことができます。
Price が 50 に設定されている場合、Process Token は専用ゲートウェイを介して Task C に到達し、この時点で Task C は Ready 状態にあることがわかります。
同じ操作を使用してタスク C と E を完了することができます。その後、プロセス トークンの終焉とともに、このプロセス インスタンスも終了します。
プロセストークンの分割と同期
上の図の専用ゲートウェイを並列ゲートウェイに置き換えると、Process Token 分割の結果を確認できます。
パラレル ゲートウェイの特性により、タスク B、C、D が同時に起動され、このときプロセス トークンは 3 つになりました。
実際、プロセストークン自体には情報が含まれておらず、分割トークンがアクティビティを起動できるため、分割という言葉は正確ではありません。したがって、並列ゲートウェイの実際の機能は、現在のプロセスを fork することであると考えることができます。
上の図では、パラレル ゲートウェイは 3 つのプロセス トークンすべてが到着するのを待ってから続行します。
パラレル ゲートウェイはプロセス トークンの数を待機していることに注意してください。ワークフローにループがあると、タスク B が 2 回起動されて完了し、タスク C が完了します.このとき、タスク D は完了していませんが、パラレル ゲートウェイはトリガー条件を満たしており、下流のタスク E が実行されます。受信プロセス トークンによってアクティブ化されます。
パラレル ゲートウェイと プロセス トークン
タスク B の後、インクルーシブ ゲートウェイを追加し、ループを追加しました。Price <= 50 の場合、タスク B が再びアクティブになり、何があっても、包含ゲートウェイはトークンを下流のパラレル ゲートウェイに毎回フォークします。
次に、最初にタスク B を完了し、価格を 50 未満にしてから、タスク C を完了します。
下の図ではっきりとわかるように、下流のパラレル ゲートウェイは、タスク C とタスク B からそれぞれ 2 つのプロセス トークンが到着したことを示しており、価格が 50 未満であるため、タスク B が再びアクティブ化されています。
プライス = 60 でタスク B を 2 回目に終了すると、パラレル ゲートウェイが 3 つのトークンを受け取るためトリガーされ、下流のタスク E もこれによりアクティブ化され、タスク D はまだ準備完了状態にあることがわかります。 . 未到達のトークンがあっても、並列ゲートウェイは気にしません。
ライフサイクル
前の例の助けを借りて、プロセス トークンとプロセス インスタンスのライフ サイクルの間の関係を観察することができます。
プロセス トークンは開始イベントで生成され、終了イベントで消滅します。
タスク E を終了しても、タスク D がまだ生きているため、プロセス インスタンスは終了しません。
タスク D を完了すると、この時点でのプロセス インスタンスは崩壊状態に陥ったと考えることができます。
パラレル ゲートウェイは引き続き 3 つのプロセス トークンの到着を待機するため、明らかにここでの条件は満たされなくなります。
このインスタンスを手動で破棄する必要があります。
開始イベントがプロセス トークンを作成するたびに、プロセス インスタンスが作成されることを意味します。プロセス トークンは分割されて同期されますが、プロセスの境界を離れることはなく、あるプロセスから別のプロセスにジャンプすることもありません。
インクルーシブ ゲートウェイと プロセス トークン
インクルーシブ ゲートウェイの発信戦略は非常に理解しやすいので、ここでは繰り返しません。その着信戦略とパラレル ゲートウェイの違いに注目しましょう。
示されているように、ダウンストリーム パラレル ゲートウェイを包括的ゲートウェイに置き換えます。
同じ手順でタスク C を完了し、価格 = 20 でタスク B を 1 回実行します。並列ゲートウェイと同様に、包含ゲートウェイもプロセス トークンの同期を待機することがわかります。
タスク B を再度完了すると、タスク E がアクティブになります。これは、十分な数のプロセス トークンが到着した場合にのみ、包括的ゲートウェイがトリガーされることを証明します。
しかし、タスク E を完了した後、タスク D を完了した後。インクルーシブ ゲートウェイは、パラレル ゲートウェイのように 3 つのプロセス トークンの到着を待ち続けるのではなく、プロセス トークンを下流に渡すように直接トリガーされます。
要約する
Parallel Gateway は、受信シーケンス フローの数に応じて、待機する必要があるプロセス トークンの数を決定します。
Inclusive Gateway は、プロセス トークンを持つ着信シーケンス フローの数に基づいて、待機する必要があるトークンの数を決定します。
持続する
もう一度、タスク C とタスク D が先に完了し、タスク B が完了せず、結果がわからない場合、包含ゲートウェイはどうするでしょうか。
インクルーシブ ゲートウェイは、この不確実なプロセス トークンの到着を待ち続けます. Price = 20 のパラメータでタスク B を終了し、そのプロセス トークンも上記の終了イベントに変わり、終了します.
では、待機しているプロセス トークンの終焉により、ダウンストリームの包括的ゲートウェイがトリガーされるのでしょうか?
答えはノーです。ワークフローは再びクラッシュします。. .