注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
ワークフロー全体をモジュール化し、Marketplace ストア内のリンクされた製品に分割できます。これにより、小規模な製品を個別に反復改善し、アップグレードできます。
リンクされた製品を使用すると、次のことを実現できます。
たとえば、ワークフローにデータクレンジング用のパイプラインと、クレンジング済みデータに基づいているオブジェクトタイプが含まれる場合、パイプラインとオブジェクトタイプを別々の製品にパッケージ化できます。パイプライン製品とオントロジー製品を接続すると、両方を同時にインストールでき、パイプライン製品のクレンジング済みデータセットのコンテンツが、オントロジー製品の必須入力に自動的にマッピングされます。
インストールの手順については、製品をインストールする > リンクされた製品を参照してください。
DevOps は、いくつかの異なるソースからリンクされた製品を生成します。
DevOps は、パッケージ化するソースエンティティを検査して、製品間のリンクを特定します。デフォルトでは、DevOps は同じストア内でリンクされた製品を探しますが、ストア間でリンクされた製品を設定して、複数のストアにまたがって製品をリンクすることもできます。以下の仮想的な例では、データセットを出力するデータパイプラインと、そのデータセットに基づいているオブジェクトタイプがあります。

パイプラインとオブジェクトタイプは個別の製品としてパッケージ化でき、DevOps は Pipeline 製品の出力データセットが Ontology 製品のデータセット入力要件を満たすようにします。このリンクはソースエンティティから導出されます。
たとえば、製品に Airplane オブジェクトタイプに依存する Workshop アプリケーションが含まれているとします。DevOps は、コンテンツとして完全に同一の Airplane オブジェクトタイプを含む製品のみを自動的にリンクします。

DevOps は、下流の製品をパッケージ化するときに製品リンクを作成します。上の画像の Ontology 製品は、その例を示しています。つまり、DevOps は、公開する製品ドラフトの入力を満たすコンテンツを持つ製品を探します。デフォルトでは、同じストア内の製品のみが対象になりますが、ストア間でリンクされた製品を使用すると、リンクされたストアの製品も対象に含められます。上流の製品が再パッケージ化されて新しい出力が生成され、その出力を下流の製品で使用できる場合は、下流の製品も再パッケージ化してリンクを再生成し、ワークフローを最新の状態に保つ必要があります。
製品のパッケージ化中に、どのほかの製品がパッケージ化ドラフトに入力を提供できるかを確認できます。リンクされた各製品を開くと、2件の製品間のマッピングを確認できます。

また、入力パネルのリンクされた製品でグループ化オプションを使用すると、上流のリンクされた各製品から提供される入力をプレビューできます。

上流の製品の出力が、保留中の製品の入力として必要なリソースと完全に一致する場合、DevOps はその上流の製品へのリンクを自動的に作成します。別の製品が異なるリソースを参照する対応可能な出力を提供する場合は、その出力を製品の入力に手動でマッピングできます。これにより、自動的にリンクされた製品と同じインストールエクスペリエンスを利用できます。
すでに自動生成されたリンクがある上流の製品に対して、手動でリンクされた製品を定義すると、その生成されたリンクがオーバーライドされます。自動生成されたリンクとは異なり、手動でリンクされた製品のマッピングは、バージョン間で製品定義が変化しても動的には更新されません。つまり、製品の変化に合わせてマッピングの出力を追加または削除する責任は、DevOps ユーザーにあります。
手動リンクを定義するには、入力を満たしたいドラフトのリンクされた製品ページに移動します。次に、手動リンクを追加を選択します。

ダイアログで、まずドラフトの入力を満たすために使用する上流の製品を選択します。次に、ドラフトの各入力を、その製品の上流の出力にマッピングします。以下の例では、Supply Chain Resilience 製品は仮想的なデータセットを使用して開発されました。このユースケースをデプロイする際には、Restock Ingest Pipeline の出力データセットを使用したいと考えています。

出力から入力へのマッピングを設定したら、保存を選択します。マッピングが有効な場合は保存され、新しくリンクされた製品が表示されます。
マッピングしようとしているリソースが対応していない場合は、入力マッピングダイアログの上部に検証エラーが表示され、解決が必要な具体的な非互換性に関するエラーの詳細が示されます。この例では、関数が同じ引数を受け付けないため、出力を入力にマッピングできません。

製品の破壊的変更とは、その製品のコンテンツに依存するワークフローが正しく機能しなくなる変更です。たとえば、コンテンツの削除やデータセットの列のデータ型の変更が破壊的変更に該当する場合があります。つまり、依存するワークフローは、これらの新しい変更に対応するように調整する必要があります。
破壊的変更がある場合は、製品のコンテンツに後方互換性のない変更があることをインストール担当者に伝えるため、メジャーバージョンを上げること(2.0.0 から 3.0.0 への変更など)を推奨します。下流の製品が公開済みの製品をリンクされた製品として引き続き使用できるようにするには、パッケージ化担当者は下流の製品を更新して破壊的変更に対応する必要があると考えられます。たとえば、データ型が変更されたデータセットの列を正しく使用できるようにするための更新や、提供されなくなった入力の削除が必要になる場合があります。
メジャーバージョンを上げると、製品の公開済みバージョンは、既存の下流のリンクされた製品のいずれにも対応しなくなります。リンクされた製品への対応を復元するには、下流のリンクされた製品をすべて再パッケージ化する必要があります。
破壊的変更があるにもかかわらずマイナーバージョンを上げることを選択した場合、インストール担当者はリンクされた製品を選択できますが、インストール時にエラーが発生する可能性が高くなります。
最も安全な手順は、最近公開された製品の下流の製品をすべて再パッケージ化し、リンクされた製品のマッピングをすべて再生成することです。
大規模な製品には、ワークフローの異なる段階(データクレンジングやアプリケーションなど)が含まれていることがよくあります。このような製品を小規模な製品に分割すると、各部分の反復開発とリリースをより迅速に行えます。
大規模な製品のコンテンツの一部を別の製品に分離すると、製品間の自動マッピングを使用して両方の製品をまとめてインストールできます。ただし、既存のインストールに重複するリソースが生じる可能性があります。
新しく作成した製品をインストールすると、元の大規模な製品のインストール済みリソースを再利用するのではなく、新しいリソースが作成されます。
製品を引き続き利用できる状態に保つために、製品をリンクする際に考慮すべきヒントを以下に示します。
デフォルトでは、リンクされた製品は同じストア内の製品間でのみ生成されます。ただし、ストアリンクを設定すると、複数のストア間でリンクされた製品を有効にできます。これは、共通のデータパイプラインやオントロジー定義など、ほかのストアの製品で使用される共有の上流製品がある場合に役立ちます。
ストアリンクは、ストア内の下流製品から別のストアの上流製品へのリンクを可能にする一方向の接続です。別のストアにリンクすると、DevOps はこのストア内の製品をパッケージ化する際に、リンク先のストアの製品を上流の依存関係の候補として扱います。
ストアリンクを設定するには、別のストアからリンクされた製品を受け取るストアのストア設定に移動します。これには、対象ストアに対する marketplace:link-to-local-marketplace 操作権限が必要です。この操作権限は、デフォルトでストアの閲覧者に付与されます。

デフォルトでは、ある製品の出力のソースエンティティが、別の製品の入力と同じリソースを直接参照している場合に、リンクされた製品が生成されます。インストールに基づくリンクされた製品は、この動作を拡張し、エンロールメント上の既存の上流インストールに、下流製品の入力リソースと同じリソースを参照する出力リソースがあるケースを検出します。
これは、元のソースエンティティを直接使用して製品を作成するのではなく、上流製品からインストールされたリソースに基づいて製品を作成する場合に役立ちます。この場合、下流製品の入力は、上流製品のパッケージ化済みのコンテンツではなく、インストールされたリソースを参照します。DevOps は、インストールされたリソースが上流製品に由来することを検出し、リンクされた製品の関係を自動的に生成します。
