Runtime におけるフロー実行エンジンの仕様
mirel Studio Flow Designer で定義されたフローは、Runtime において 安全性・再現性・一貫性 を担保しつつ実行される。
1つの「フロー定義」に対して 1つの実行単位が生成される。
含まれる要素：
- イベント情報
- グローバル変数コンテキスト
- ノード実行スタック
- エラーハンドラ
- ログコンテキスト
(1) イベントが発火
↓
(2) Flow Execution Unit の生成
↓
(3) Start ノード実行
↓
(4) ノードチェーンを順次評価（BFS）
↓
(5) 条件分岐がある場合は条件を評価
↓
(6) 外部呼出・データ操作ノードを実行
↓
(7) 最終ノードに到達したら終了
- 1フローにつき1実行コンテキスト
- 並列実行（Parallel Split）は将来拡張
- 副作用を局所化しやすくするため
- エッジの優先度順
- arrival-order（定義順）を採用
- IF ノードは true → false の順
Flow Execution Unit は以下のスコープを持つ。
① イベントコンテキスト
② フロー内変数
③ ノード出力
④ エンティティデータ
優先順位：
ノード出力 > フロー変数 > イベントコンテキスト > エンティティデータ
- Modeler のスキーマ定義を参照
- バリデーションは実行前に再評価
- トランザクションは基本シリアライズ
- Entity + 条件式で実行
- 結果は Flow variables に格納
Runtime が提供する HTTP クライアントを利用。
| 項目 | 設定 |
|---|---|
| Timeout | デフォルト 3秒 |
| Retry | 将来実装 |
| Error | Catch ハンドラへ遷移 |
- ノード単位で try 区間を設置
- 例外発生 → Catch へ遷移
- Catch 実行後は「フロー続行」または「フロー終了」を選択
interface FlowExecutionLog {
flowId: string;
executionId: string;
eventType: string;
startTime: Date;
endTime: Date;
nodes: Array<{
nodeId: string;
start: Date;
end: Date;
result: string;
error?: string;
}>;
}データの整合性を保つため、Flow 実行におけるトランザクション境界を明確に定義する。
- 原則: 1つの Flow 実行（Start 〜 End）を 1 トランザクションとする。
- コミット: Flow が正常終了した時点で一括コミット。
- ロールバック: 途中で例外が発生し、Catch されずに終了した場合は全変更をロールバック。
外部 API 呼び出し（副作用のある操作）を含む場合、分散トランザクション（2PC）はサポートしない。 代わりに 「補償トランザクション（Compensating Transaction）」 パターンを推奨する。
- 外部 API 成功後に内部 DB 更新で失敗した場合、Catch ブロックで外部 API の取り消し処理（API 呼び出し）を定義する必要がある。
- すべての実行パスのバリデーションを Builder 側でチェック
- Runtime ではパス実行に特化
- モデルに沿った整合性を常に維持
Powered by Copilot 🤖