内側のワークフロー
Inner workflowブロックを使って一つのWorkflow定義を別のWorkflow定義の中に埋め込み、コンパイラがそれをどのようにインライン化するか。
この 内部ワークフロー ブロック（roboflow_core/inner_workflow@v1）を使用すると、あるワークフロー定義を別のワークフロー定義内に埋め込めます。 コンパイル時に、エンジンは保存済みワークフローの参照を解決し、 合成 （ネスト制限とサイクル）を検証し、 パラメータバインディングを検証してから、 インライン展開し、 子のステップを親に取り込みます。コンパイル後には独立した「ネストされた実行」は存在しません。グラフは、それらのステップを親レベルで記述した場合と同じです。
このページでは、ブロック、コンパイル時パイプライン、制限、および最小限の Python 例について説明します。一般的なコンパイル段階については、 ワークフロー定義のコンパイル.
この機能は Execution Engine に実装されています v1。内部ワークフローブロックの run() メソッドは実行時には使用されません。ステップはコンパイル中に削除されます。
内部ワークフローブロック
各内部ワークフローステップは、親の steps リスト内にある、次の type: "roboflow_core/inner_workflow@v1".
子定義の指定方法
指定する必要があるのは いずれか:
workflow_definition：完全なネストされたワークフロー JSON オブジェクト（ルートワークフローと同じ形状：version,inputs,steps,outputs), またはworkflow_workspace_idおよびworkflow_id、オプションのworkflow_version_id。これにより、コンパイル時に保存済みワークフロー仕様を読み込みます。
同じステップで してはなりません インラインの workflow_definition と参照フィールドの両方を設定することはできません。
parameter_bindings
parameter_bindings は、その キー が 名前 であるオブジェクトです。対象は 子ワークフローの 内にあるエントリです。 inputs 配列。各 値 は、親の セレクター （またはエンジンが変換できる値）です。対象は 親 スコープで、通常は次のとおりです。
$inputs.<parent_input_name>親ワークフローの入力の場合、または$steps.<parent_step_name>.<output_property>先行する親ステップによって生成されたデータの場合。
ルール：
親からの値を 必要とする すべての子入力は、
parameter_bindings, に含める必要があります。ただし、 型がWorkflowParameter/InferenceParameterで、子定義内に null ではないdefault_valueを宣言している入力は除きます。これらは省略できます。定義がインライン展開される際に子のデフォルトが適用されます。子入力名ではないキーは、コンパイル時に拒否されます。
子ステップは、以下を通じて親データを利用する必要があります。
$inputs.<child_input_name>ネストされた定義内では、コンパイラがインライン展開中にこれらの参照をバインドされた親セレクター（または挿入されたデフォルト）に置き換えます。
親から子出力を参照する
ネストされたワークフローの outputs 配列では、 JsonField を持つエントリが定義されます。 name および セレクター。コンパイル後、親は内部ステップを、それらの JsonField にちなんだ名前の出力を持つ論理ブロックとして扱います。 name 値。
親からは次のように参照します：
ここで <child_output_name> は、子の name 内にある JsonField のフィールドであり、 outputs必ずしも最後のステップ名ではありません。
コンパイル時パイプライン（Execution Engine v1）
次の場合、 compile_workflow_graph が実行されると、内部ワークフローは以下の処理を通過します。 これは、メインの「ワークフロー定義の解析」ステップの 前に行われます：
参照解決（正規化） 以下を使用するすべてのステップ：
workflow_workspace_id/workflow_id（およびオプションのworkflow_version_id）は、インラインのworkflow_definitionに解決されます。これはネストされた定義内でも再帰的に行われます。デフォルトのリゾルバーは Roboflow API と
workflows_core.api_keyをワークフロー初期化パラメータで使用します（ワークスペースが"local"である場合、またはカスタムリゾルバーを指定する場合を除く）。初期化パラメータでオーバーライドします：
workflows_core.inner_workflow_spec_resolver：呼び出し可能な(workspace_id, workflow_id, workflow_version_id, init_parameters) -> dictで、子ワークフロー JSON を返します。
合成の検証 エンジンは次のものを構築します： 合成グラフ：親ワークフローのフィンガープリントから子定義のフィンガープリントへの、各
inner_workflowステップごとに 1 本のエッジ。その後、次を確認します：グラフが 非巡回 であること（A → B → … → A がない）、
ネストの深さ がルートから
WORKFLOWS_MAX_INNER_WORKFLOW_DEPTH,以内であること、 総数 （エッジ）である内部ワークフローステップが
WORKFLOWS_MAX_INNER_WORKFLOW_COUNT以内であること。 「 制限と環境変数 」を以下で参照してください。
インライン展開 各
inner_workflowステップは通常のステップに展開されます。子ステップ名は次の形式になります：{inner_step_name}__{child_step_name}（衝突処理あり）。セレクターは書き換えられ（$inputs/$stepsは子内で使用され、親からの以下への参照：$steps.<inner_step_name>…）、その後、内部ステップは削除されます。残りのコンパイル処理（解析、ワークフロー仕様の検証、実行グラフの構築、ステップの初期化）では、フラットなワークフローのみが扱われます。解析と検証 フラット化された JSON はブロックマニフェストを使用して解析され、
validate_workflow_specificationが実行され、他のワークフローと同様に実行グラフが構築されます。
例（Python）
以下のパターンは、 examples/workflows/inner_workflows/main.py にあるこのリポジトリの例に一致します。ID で保存済みワークフローを解決し、親画像を子が期待する入力名にバインドしてから、下流の親ステップで子出力を利用します。
ワークスペース、ワークフロー、バージョン、モデル、出力セレクター、および画像パスを、保存済みワークフローと親グラフに一致する値へ置き換えてください。重要な要件は、 parameter_bindings キーが 子 ワークフローの inputs[].name フィールドと一致することです。
制限と環境変数
WORKFLOWS_MAX_INNER_WORKFLOW_DEPTH
4
最大 深さ は、ルートワークフローから見た合成グラフの深さです。直接の各 inner_workflow 子は、パスに沿って 1 レベルとして数えられます。
WORKFLOWS_MAX_INNER_WORKFLOW_COUNT
32
最大 数 の inner_workflow ネストされた定義全体にわたるステップ数（各内部ステップは合成グラフ内の 1 エッジです）。
サイクル： 合成グラフは DAGでなければなりません。各ワークフローのステップごとの実行グラフが非巡回であっても、ネストされた参照のサイクル（たとえば、ワークフロー A が B を埋め込み、B が A を埋め込む）は作成できません。
違反すると、コンパイル時エラー（InnerWorkflowNestingDepthError, InnerWorkflowTotalCountError, InnerWorkflowCompositionCycleErrorなど）が発生し、深さ、数、またはサイクルへの関与を説明するメッセージが表示されます。
関連資料
最終更新
役に立ちましたか？