Commerce Connect abstract service layers

Version: 8.1

The Commerce Connect core framework contains a number of generic, extensible abstract service layers that work with different external commerce systems.

The Commerce Connect service layers:

  • Carry essential e-commerce information between the webshop solution and the back-end e-commerce system(s).

  • Encapsulate and provide an abstraction of the business logic of the external commerce system(s).

  • Track and follow-up visitor behavior. They provide new goals, page events, engagement plans, and reports.

When you build an e-commerce solution using Commerce Connect, you should use the APIs in the Commerce Connect service layers instead of directly accessing the APIs in the external commerce system. The reasons for this are:

  • The customer engagement is built into the service layers. If the service layer APIs are not used, the built-in commerce scenarios for personalization, reporting, and engagement automation are not triggered or deployed.

  • Some external commerce systems do not support all the scenarios that Commerce Connect supports. Therefore, you should use the Commerce Connect APIs to benefit from the fallback functionality built into Commerce Connect.

  • If you make customizations and extensions to the APIs to accommodate unique features in one external commerce system, the features will not necessarily be supported in another commerce system. Using the standard Commerce Connect APIs lets you replace the external commerce system with a minimum of effort.

  • In case multiple external systems are integrated using the Connect pipelines, you only have to call the Connect APIs as a single point of entry, rather than calling each external system individually.

Note

Only call the external commerce system API directly if the functionality that you want does not exist or is out of the scope of Commerce Connect.

Events

The service layers handle the events that occur in e-commerce scenarios. Events are represented by a service method and corresponding Sitecore pipelines and they can be divided into front-end and back-end events.

The following are examples of front-end events that are triggered by an action on the website:

  • Create a customer account

  • Update a wish list

  • Update a shopping cart

  • Place an order

The following are examples of back-end events triggered by an action in the commerce system:

  • Update product information

  • Update an order status

  • Update a product price

Commerce Connect service layer pipelines

Commerce Connect includes pipeline processors that interact with Sitecore. Commerce Connect connectors modify or overwrite the Commerce Connect pipelines.

Pipeline example

The following is an example of a pipeline that adds products to a shopping cart and has been modified for a specific external commerce system:

RequestResponse
<Sitecore.Commerce.Cart.AddProductToShoppingCart>
  <processor type="CommerceSystem.Cart.ValidateProduct" />
  <processor type="CommerceSystem.Cart.CheckInventory" />
  <processor type="CommerceSystem.Cart.PutHoldOnProduct" />
  <processor type="Sitecore.Commerce.Cart.RecordPageEvent" />
</Sitecore.Commerce.Cart.AddProductToShoppingCart>

In this pipeline:

  • The processor in bold type is specific to Sitecore and provided by Commerce Connect as part of the default pipeline definition. Developers can modify or remove the processor, but the pipeline must not be removed or renamed.

  • The other processors are specific to the external commerce system that is integrated with Sitecore. They are part of what constitutes the connector to the external commerce system and they are merged into the Connect pipeline from a separate configuration file that is part of the connector.

Customizing the service layers for an external commerce system

Each service layer consists of an API, one or more pipelines for each API call, and an extensible domain model:

  • Each service layer has a default API that you can customize. Each service layer method takes a Request object and a Result object, either or both of which can be customized to satisfy the needs of the external commerce system. You can create an extended Request object by inheriting the default Request class and replacing it by configuration. Similarly, you can create an extended Result object by inheriting the default Result class and replacing it by configuration.

  • Each service layer method executes a pipeline that can call one or more pipelines. Each pipeline can be customized by injecting, removing, or replacing processors within the pipeline.

  • All domain model objects and nested domain model objects can be inherited and extended with custom properties. You can create an extended domain model object or extended nested domain model object by inheriting the default class and replacing it by configuration.

    All service methods keep the existing defined signature, even when used with customized domain model objects.

Implementation details

Each service layer contains its own configuration file that defines the entities that make up the domain model, pipelines, factories, repositories, and the service layer API implementation:

  • Sitecore Factory is used to instantiate the domain model objects, so you can customize, configure and instantiate the individual entities.

  • The Repository design pattern is used in processors that read and write data to Sitecore. This means that you can easily replace or customize the repository if needed.

  • The default pipeline configuration in Commerce Connect contains placeholder processors in the places where processors for external commerce systems are expected. Some service layers contain comments instead. The placeholder processors are empty and do not execute any code.

  • An external commerce system connector consists of processors that interact with the commerce system and a configuration file that patches the Commerce Connect configuration file, replacing the placeholder processors in the pipelines.

Do you have some feedback for us?

If you have suggestions for improving this article,