イベント サブプロセス

概要

イベント サブプロセスを使用すると、プロセスまたはサブプロセスのスコープでイベントに反応できます。イベント サブプロセスはメインのシーケンス フローには接続されません。

その代わりに、包含するスコープがアクティブな間に、設定されている開始イベントが発生した場合にトリガーされます。

イベント サブプロセスは、以下が必要な場合に使用します。

• 関連するエラー処理ロジックを一元化する
• エラー境界イベントが複数のタスク間で重複するのを避ける
• 動作をプロセスまたはサブプロセスのスコープで制御する
• 実行時に外部メッセージに反応する
• 回復、ログ、または通知のロジックを一貫して実行する

Maestro では、イベント サブプロセスは以下で開始できます。

• エラー開始イベント
• メッセージ開始イベント

エラー開始イベント

エラー開始イベントによってイベント サブプロセスがトリガーされるのは、BPMN エラーが発生してそのエラー コードが一致する場合か、イベントが「すべてのエラーをキャッチ」として設定されている場合です。

BPMN エラーがスローされた場合、エンジンは、同じスコープ内の一致するイベント サブプロセスを評価してから、エラー境界イベントを評価します。このような評価順序であるため、イベント サブプロセスが優先されます。

実行動作

エラー開始イベントは常に「中断あり」です。

エラーが発生すると、エンジンは以下を実行します。

• イベント サブプロセスをトリガーします。
• 包含するプロセスまたはサブプロセスのスコープをキャンセルします。
• そのスコープ内のアクティブなパスをすべて停止します。

エラー開始イベントは、エラーによって現在の実行が無効になる場合に使用します。

実際の例

• 不正が検出されたために支払いの認可が失敗した
• オンボーディングの際に、必須のコンプライアンスの検証が失敗した
• 重要なシステム依存関係が利用できない

イベント サブプロセスがない場合とある場合のエラー処理

イベント サブプロセスがない場合	イベント サブプロセスがある場合
エラー境界イベントを個々のタスクにアタッチする	1 つのイベント サブプロセスをプロセスまたはサブプロセスのスコープで定義する
多くの場合、類似するエラー ロジックを複数のタスクで繰り返す	関連するエラー処理ロジックを 1 か所に一元化する
タスク専用のエラー処理を各タスクで制御する	スコープ内のすべてのタスクのエラー処理をスコープで制御する
モデルが大きくなると、保守が難しくなる	エラー ロジックを 1 か所で更新するため、保守が容易になる

既存のモデルへの影響

イベント サブプロセスを同じスコープに追加した場合にのみ、エンジンは動作を変更します。

• エラー境界イベントのみを使用するモデルは、引き続き以前と同様に動作します。
• イベント サブプロセスを追加した場合、そのイベント サブプロセスは、同じスコープ内のエラー境界イベントによって処理されない一般的なエラーを処理します。
• スローされたエラーに一致するエラー境界イベントがない場合、エンジンはイベント サブプロセスを評価します。

エラー境界イベントとイベント サブプロセスの両方を、同じスコープ内の同じエラー参照を処理するように設定しないでください。

設定ルール

特定のスコープ (プロセスまたはサブプロセス) に対して設定する場合

• 1 つのエラー コードにつき 1 つのイベント サブプロセスだけを使用する
• すべのエラーをキャッチするイベント サブプロセスを 1 つだけ使用する

特定のタスクに対して設定する場合

• 1 つのエラー コードにつき 1 つのエラー境界イベントだけを使用する
• すべのエラーをキャッチするエラー境界イベントを 1 つだけ使用する

メッセージ開始イベント

メッセージ開始イベントによってイベント サブプロセスがトリガーされるのは、包含するスコープがアクティブな間に、設定されているメッセージをエンジンが受け取った場合です。

実行動作

エンジンは、包含するスコープがアクティブな間、設定されているメッセージをリッスンします。メッセージを受け取ると、エンジンは「割り込みあり」または「割り込みなし」の設定に従ってイベント サブプロセスをトリガーします。

メッセージ開始イベントによって他のメッセージ イベントが上書きされたり、メッセージ開始イベントが他のメッセージ イベントより優先されたりすることはありません。各メッセージ イベントは、そのスコープと設定に基づいて個別に反応します。

イベント サブプロセスがない場合とある場合のメッセージ処理

イベント サブプロセスがない場合	イベント サブプロセスがある場合
メッセージの処理をメインのシーケンス フロー内でモデリングする	1 つのイベント サブプロセスをプロセスまたはサブプロセスのスコープで定義する
メイン フローをメッセージ中間キャッチ イベント経由でルーティングする必要がある	スコープがアクティブな間、エンジンがメッセージをリッスンする
メイン プロセスが明示的にメッセージ イベントに到達して反応する必要がある	スコープがアクティブな間、いつでもイベント サブプロセスをトリガーできる
メッセージ処理ロジックはメイン フローの構造に緊密に結合されている	メッセージ処理ロジックはメインのシーケンス フローから独立している
メッセージの動作を変更するには、メイン フローの再構築が必要になる場合がある	メイン フローを変更せずにメッセージ処理を更新できる
メイン フローは常にメッセージ イベントで一時停止する	メッセージ開始イベントを「中断あり」または「中断なし」として設定できる

既存のモデルへの影響

メッセージ開始イベントをイベント サブプロセス内に追加した場合にのみ、エンジンは動作を変更します。

• イベント サブプロセスを使用しないモデルは、引き続き以前と同様に動作します。
• メッセージ開始イベントを追加すると、エンジンは、包含するスコープがアクティブな間、設定されているメッセージをリッスンします。
• メッセージ開始イベントを「中断あり」として設定した場合、エンジンは、メッセージを受け取ると包含するスコープをキャンセルします。
• メッセージ開始イベントを「中断なし」として設定した場合、エンジンはイベント サブプロセスを並列に開始し、メイン フローは処理を続行できます。

同じスコープ内の同じメッセージ参照を使用して複数のメッセージ開始イベントを設定しないでください。

「中断なし」と「中断あり」の比較

メッセージ開始イベントは、「中断あり」または「中断なし」として設定できます。

中断中

メッセージを受け取ると、エンジンは以下を実行します。

• イベント サブプロセスをトリガーします。
• 包含するプロセスまたはサブプロセスのスコープをキャンセルします。
• そのスコープ内のアクティブなパスをすべて停止します。

「中断あり」のメッセージ開始イベントは、メッセージが、現在の実行を停止する必要がある外部シグナルを表している場合に使用します。

実際の例

• 注文の処理中に顧客が注文をキャンセルした
• レギュレーターが処理停止命令を送信した
• 親システムが終了コマンドを送信した

中断なし

メッセージを受け取ると、エンジンは以下を実行します。

• イベント サブプロセスをトリガーします。
• 包含するスコープをアクティブな状態に保ちます。
• イベント サブプロセスを並列に実行します。
• メイン プロセスの続行を許可します。

「中断なし」のメッセージ開始イベントは、メッセージによって、メイン フローを中断することなく追加のロジックをトリガーする必要がある場合に使用します。

実際の例

• オンボーディングの続行中に顧客が連絡先の詳細を更新した
• パートナー システムから追加のメタデータが送信された
• 通知メッセージによって監査ログがトリガーされた