パイプラインパターン

製品ドメインモデルを構成する各タイプのアイテムは、分割統治戦略に従って個別に管理されます。Connectの他のすべてのサービス層と同様に、このロジックはパイプラインを用いて実装されます。つまり、モデル内のすべての製品エンティティに1つ以上のパイプラインが関連付けられ、そのエンティティは製品、製造元、部門、分類などである場合があります。

Connectは、各エンティティタイプごとにパイプライン内のプロセッサに対してブリッジ設計パターンに類似したパターンを使用しています。プロダクトドメインモデルは、外部コマースシステム(ECS)およびSitecoreにおける実装を隠すデータ抽象化として機能します。各エンティティはECSとSitecoreの両方から読み取られます。

同一のインスタンス間で値の比較が実行され、その結果がECSとSitecoreの両方に書き戻されます。つまり、各パイプラインは各エンティティごとに同じプロセッサパターンを持ち、エンティティは製品、メーカー、部門、または分類のいずれかです。

双方向同期は以下の順序で行われます:

1. エンティティはECSから読み取られます。

   命名規則: ReadTypeOfEntityFromSC

2. エンティティはCMSから読み取られます。

   命名規則: ReadTypeOfEntityFromECS

3. エンティティを比較し、違いを解決します。

   命名規則: ResolveTypeOfEntityChanges

4. 結果はECSに書き込まれます。

   命名規則: SaveTypeOfEntityFromECS

5. 結果はCMSに書き込まれます。

   命名規則: SaveT7ypeOfEntityFromSC

外部システムとの統合を実装する場合、実装が重要なのはプロセッサ番号1とプロセッサ4です。他のプロセッサはConnectを搭載しています。プロセッサ番号3にはカスタムバージョンが必要ですが、ほとんどのロジックを提供するベースプロセッサが提供されています。

Directionパラメータの値によっては、前述のプロセッサの中には実行をスキップするものもあります。例えば、Directionパラメータがinbound(ECS->CMS)に設定されている場合、CMSからエンティティを読み取ったりECSに書き戻したりする必要はありません。

以下のスニペットは、メイン商品アイテム(ProductEntity)の同期のデフォルト構成を示しています。基本的なパターンは作成と更新のケースを扱います。製品の場合、外部コマースシステムに存在しなくなった商品を削除するために追加のプロセッサが注入され、コンテンツから削除する必要があります。

<commerce.synchronizeProducts.synchronizeProductEntity>

図1は、メインSynchronizeProductsパイプラインが内部で他のパイプラインを実行して完全な同期を行う方法を示しています。

図1

パイプラインと命名規則

パイプラインは一般的に2つのタイプに分けられます。

• 実際の製品リポジトリとは別の関連する製品リポジトリ上で動作するパイプライン。

  これらの別リポジトリは製品リポジトリからの参照として使用されます。メーカー、分類、タイプ、部門、リソース、仕様のリポジトリがあります。パイプライン名はSynchronizeで接頭辞付きです。例えば、すべてのメーカーの同期を担当するSynchronizeManufacturersパイプラインなどがあります。

• 個々の製品に動作し、製品間の参照を別々のリポジトリに同期するパイプライン。

  パイプライン名にはSynchronizeProductが付加され、「product」という言葉が付加され、リポジトリ全体ではなく個々の製品を扱っていることを示します。例えば、SynchronizeProductManufacturersパイプラインは特定の製品と関連メーカー間の接続や参照を同期し、別個の製造業者リポジトリに保存されます。

ワードRunで始まるプロセッサは、別のパイプラインを呼び出し、必要なパラメータを転送する役割を担います。例えば、SynchronizeManufacturersパイプラインを実行するRunSynchronizeManufacturersプロセッサです。