パイプライン パターン
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
製品ドメインモデルを構成する各タイプのアイテムは、分割統治戦略に従って個別に管理されます。Connectの他のすべてのサービスレイヤーと同様に、ロジックはパイプラインを使用して実装されます。これは、モデル内のすべての製品エンティティに1つ以上のパイプラインが関連付けられていることを意味し、エンティティは製品、製造元、部門、分類などである可能性があります。
Connectは、エンティティの種類ごとにパイプライン内のプロセッサに対して、ブリッジ デザイン パターンと同様のパターンを使用します。製品ドメインモデルは、外部コマースシステム (ECS) やSitecoreでの実装を隠すデータ抽象化として機能します。各エンティティは、ECSとSitecoreの両方から読み取られます。
同一のインスタンス間の値の比較が実行され、結果がECSとSitecoreの両方に書き戻されます。つまり、各パイプラインには、エンティティごとに同じプロセッサのパターンがあり、エンティティは製品、製造元、部門、または分類である可能性があります。
双方向同期は、次の順序で行われます。
-
エンティティはECSから読み取られます。
命名規則: ReadTypeOfEntityFromSC
-
エンティティはCMSから読み取られます。
命名規則: ReadTypeOfEntityFromECS
-
エンティティが比較され、相違点が解決されます。
命名規則: ResolveTypeOfEntityChanges
-
結果はECSに書き込まれます。
命名規則: SaveTypeOfEntityFromECS
-
結果はCMSに書き込まれます。
命名規則: SaveT7ypeOfEntityFromSC
外部システムとの統合を実装する場合、実装に関連するのはプロセッサ番号1と4です。他のものはConnectに付属しています。プロセッサ番号3のカスタム バージョンが必要ですが、必要なロジックのほとんどを提供するベース プロセッサが提供されます。
Directionパラメーターの値によっては、前にリストされたプロセッサの一部が実行をスキップします。たとえば、Directionパラメーターがinbound (ECS->CMS) に設定されている場合、CMSからエンティティを読み取ったり、ECSに書き戻したりする必要はありません。
次のスニペットは、メイン製品アイテム (ProductEntity) を同期するための既定の構成を示しています。基本パターンは、作成と更新のケースを処理します。製品の場合、製品が外部コマースシステムに存在しなくなり、コンテンツから削除する必要がある場合に、製品を削除するために追加のプロセッサが挿入されます。
図1は、メインSynchronizeProductsパイプラインが他のパイプラインを内部的に実行して完全同期を行う方法を示しています。

図1: パイプライン間の呼び出し階層
パイプラインと名前付け規則
パイプラインは、通常、次の2つのタイプに分けられます。
-
実際の製品リポジトリとは別の、関連する製品リポジトリで動作するパイプライン。
これらの個別のリポジトリは、製品リポジトリからの参照として使用されます。Manufacturers、Classifications、Types、Divisions、Resources、およびspecificationsのリポジトリがあります。パイプライン名の先頭にはSynchronizeが付きます。たとえば、すべての製造元の同期を担当するSynchronizeManufacturersパイプラインです。
-
個々の製品で動作し、製品から個別のリポジトリへの参照を同期するパイプライン。
パイプライン名SynchronizeProductには、リポジトリ全体ではなく個々の製品を扱っていることを示すためにproductという単語が追加されています。たとえば、SynchronizeProductManufacturersパイプラインは、特定の製品と、別のManufacturersリポジトリに格納されている関連メーカーとの間の接続/参照を同期する役割を担います。
Runという単語で始まるプロセッサは、別のパイプラインを呼び出し、必要なパラメーターを転送する役割を担います。たとえば、SynchronizeManufacturersパイプラインを実行するRunSynchronizeManufacturersプロセッサなどです。