Pipeline pattern

Current version: 10.2

Each type of item that makes of the product domain model is managed individually by following the divide and conquer strategy. As with all other service layers in Connect, the logic is implemented using pipelines. It means that there are one or more pipelines associated with every product entity in the model, where the entity can be product, manufacturer, division, classification and so on.

Connect uses a pattern similar to the Bridge Design Pattern for the processors in the pipelines for each type of entity. The product domain model serves as the data abstraction that hides its implementation in the external commerce system (ECS) as well as in Sitecore. Each entity is read from both the ECS and Sitecore.

A comparison of the values between identical instances is executed and the result is written back to both the ECS and Sitecore. This means that each pipeline has the same pattern of processors for each entity, where the entity can be product, manufacturer, division, or classification.

The two-way synchronization takes place in the following order:

  1. The entity is read from the ECS.

    Naming convention: Read[TypeOfEntity]FromSC

  2. The entity is read from the CMS.

    Naming convention: Read[TypeOfEntity]FromECS

  3. The entities are compared and the differences are resolved.

    Naming convention: Resolve[TypeOfEntity]Changes

  4. The results are written to the ECS.

    Naming convention: Save[TypeOfEntity]FromECS

  5. The results are written to the CMS.

    Naming convention: Save[T7ypeOfEntity]FromSC

When implementing integration with an external system, it is processors number 1 and 4 that are relevant to implement. The others come with Connect. There needs to be a custom version of processor number 3, but a base processor is provided that provides most of the logic needed.

Depending on the value of the Direction parameter, some of the previously listed processors skip execution. For example, if the Direction parameter is set to inbound (ECS->CMS), there is no need to read the entity from CMS or write it back to the ECS.

The following snippet shows the default configuration for synchronizing the main product item (ProductEntity). The basic pattern handles the cases of creating and updating. For products, an additional processor is injected to delete a product if it no longer exists in the external commerce system and must be removed from the content.

<processor type="Sitecore.Commerce.Pipelines.Products.SynchronizeProductEntity.ReadProductFromSitecore, Sitecore.Commerce">
<param desc="productRepository" ref="productRepository" />
<processor type="Sitecore.Commerce.Pipelines.Products.SynchronizeProductEntity.ReadExternalCommerceSystemProduct, Sitecore.Commerce" />
<processor type="Sitecore.Commerce.Pipelines.Products.SynchronizeProductEntity.ResolveProductChanges, Sitecore.Commerce">
<param desc="synchronizationStrategy" ref="synchronizationStrategy" />
<processor type="Sitecore.Commerce.Pipelines.Products.SynchronizeProductEntity.DeleteProductFromSitecore, Sitecore.Commerce">
<param desc="productRepository" ref="productRepository" />
<param ref="entityFactory" />
<processor type="Sitecore.Commerce.Pipelines.Products.SynchronizeProductEntity.SaveProductToExternalCommerceSystem, Sitecore.Commerce" />       
<processor type="Sitecore.Commerce.Pipelines.Products.SynchronizeProductEntity.SaveProductToSitecore, Sitecore.Commerce" >
<param desc="productRepository" ref="productRepository" />
<param ref="entityFactory" />

Figure 1 illustrates how the main SynchronizeProducts pipeline executes other pipelines internally to do a full synchronization.

Figure 1: Call hierarchy between pipelines

Pipelines and naming conventions 

Pipelines are generally split into two types:

  • Pipelines that operate on related product repositories, separate from the actual product repository.

    These separate repositories are used as references from the product repository. There are repositories for Manufacturers, Classifications, Types, Divisions, Resources and specifications. The pipeline names are prefixed with Synchronize. For example, the SynchronizeManufacturers pipeline, which is responsible for synchronizing all manufacturers.

  • Pipelines that operate on individual products and synchronize references from products to the separate repositories.

    The pipeline names are prefixed with SynchronizeProduct, having the word product added to signal that they are dealing with individual products as opposed to entire repositories. For example, the SynchronizeProductManufacturers pipeline, which is responsible for synchronizing the connections/references between a specific product and its related manufacturers stored in the separate Manufacturers repository.

Processors that begin with the word Run  are responsible for calling a separate pipeline and transferring the needed parameters. For example, the RunSynchronizeManufacturers processor that executes the SynchronizeManufacturers pipeline.

Do you have some feedback for us?

If you have suggestions for improving this article,