プラグイン可能なアクティビティタイプ

フローはノードのグラフです。ほとんどのノードはプロセス内で WASM コンポーネントを実行しますが、一部のノードは作業を別々のランタイム — SoRLa、OperaLa、そして(将来は)その他 — に引き渡し、結果を待ちます。これらがアクティビティタイプです。役割は外部ランタイムへメッセージングバス経由でディスパッチすることであるネイティブフローノードです。

現在、プラットフォームは次のディスパッチアクティビティタイプを提供しています。

ノード	ディスパッチ先	ステータス
`sorla.call`	SoRLa ランタイム	稼働中
`operala.call`	OperaLa ランタイム	稼働中
`telco-x.call`	telco-x ランタイム	配線済み、ランタイムが存在するまで不活性

ディスパッチの仕組み

ディスパッチノードは、それ自体ではビジネスロジックを実行しません。ノードの入力をパッケージ化し、NATS 経由でランタイムにリクエストを発行し、次のいずれかを行います。

レスポンスを待機する(フローは一時停止し、結果が到着すると再開する)、または
ファイアアンドフォーゲットする(フローは即座に継続する)。

すべてのディスパッチノードは 1 つのメカニズム — 同じリクエスト / レスポンス契約と同じ相関処理 — を共有するため、どのランタイムをターゲットにするかにかかわらず一貫した動作をします。

これが Designer にとって重要な理由

Designer のフロービルダーは、そのパレットをケイパビリティカタログに基づかせています。各アクティビティタイプは、そのカタログにディスパッチ可能なケイパビリティとして表示されます。これは、ユーザーがそれらのランタイムのいずれかに属する作業を記述したとき、AI フロービルダーが他のどのノードを配置するのと同じように sorla.call や operala.call ノードを配置できることを意味します。

新しいアクティビティタイプの追加

設計上の目標は、まったく新しいアクティビティタイプの追加にほとんどコストがかからないことです。

Designer のベースラインケイパビリティカタログ内の1 つのカタログエントリで、ディスパッチケイパビリティとしてマークします。これにより、ノードが AI フロービルダーから発見可能になります。
ランナー内の1 行で、そのノードをネイティブのディスパッチ操作として認識させます。

ランナーは任意のディスパッチノードを汎用的に実行する方法をすでに知っているため、新しい実行コードは不要です。ノードは単に異なるランタイム名をターゲットにするだけです。そのランタイムが後でデプロイされると、それまで不活性だったノードがそれ以上の変更なしに稼働します。