This connector module implements an integration of AEM and Salesforce Commerce Cloud (SFCC).

Unlike integrations with other Commerce systems, where AEM is the leading system, in this integration SFCC "owns the glass". That means, that SFCC is the primary system serving content to the customers, where AEM provides pre-rendered content and assets to SFCC to deliver.

Note: "Salesforce Commerce Cloud" previously was called "Demandware" - the AEM code still uses this old name. So when we are referring to names in the source code or the configuration we usually use this name. But basically they are the same product.

Please also refer to this AEM Tutorial Commerce Video to gain a basic understanding of how SFCC content is edited within AEM from a user's perspective. This documentation is about the technical implementation, only. It might be helpful, if you have seen the user's perspective, first.

When a user publishes an asset from AEM, behind the scenes, the following process is triggered:

An editor creates components, configurations and assets in AEM and publishes this content. A dedicated "demandware" replication agent is triggered by this replication event. The replication agent statically renders the content and transmits it to Salesforce.

Salesforce incorporates the content into it's overall shop experience which then is consumed by the visitors.

Note, that this setup uses AEM as a "headless" content editor, only. There is only an Author and no Publish system required in this setup. SFCC takes the part of the Publish system.

Salesforce requires different types of objects to be edited - each one of which requiring a different data structure and API. To take that into account, the replication agent is based on a plugin-architecture. Where each plugin handles exaclty one type of object:

The connector supports different types of SFCC-related content out of the box:

• Content Slot Configurations
• Content Assets
• Assets (images, videos, ...)
• Templates

Processing of the objects is done in two phases:

Phase 1:

Content is prepared for the transport. For Content Assets, the content is pre-rendered statically into HTML according to their Sling resource type. The HTML then is wrapped into a JSON object that is passed on into the next phase.

Different content might require different pre-processing steps. The processing is performed by a number of plugins that are chained together. Each plugin can decide whether it wants to process the content in the processing chain or not. You can chain as many plugins as you want.

Check out the Bundles Overview to find the plugins that ship with the connector.

Phase 2:

In this phase, the actual transmission to SFCC takes place. Depending on the type of the content to be transmitted you the conector needs a different transport handler. Content Assets and Slot Configurations, for example are transmitted using the OCAPI interface provied by SFCC. Assets and Templates are transmitted via WebDAV.

Note: See AEM to SFCC replication for a more detailed documentation of the plugin architecture. The SFCC connector uses the Open Commerce API (OCAPI) please refer to Salesforce B2C Commerce. Look for "Open Commerce API". The connector only implements "Data API Resource" and "Data API Documents". There is no integration into the Shop API

AEM supports several content objects for SFCC. These are briefly explained here. Refer to the SFCC documentation for more detail.

A content slot is an area on a page that can dynamically be populated by content from Salesforce. "Dynamically" means, SFCC decides in the moment the page is requested how to fill this slot. A number of "Content Slot Configurations" can provide rules to fill a certain "Slot". Rules can for example be based upon time, season, segment of the current customer and so on. If more than one Slot Config has a matching rule, the config with the highest priority is chosen.

Content Slot Configurations can be edited in AEM. They are "headless" objects, they just have page properties and no visual content.

If you are familiar with Adobe Target - a Content Slot is similar to an Mbox. The slot configuration is compareable to an Activity.

The major type of content that is provided by AEM probably will be Content Assets. A Content Assets in SFCC basically is what a Component is in AEM - an HTML fragment that can be used on a page in SFCC.

This integration is based on the assumption, that Content Assets are static content pages that take up the major space on the screen.

The Content Asset can contain Content Slots that are filled dynamically by SFCC.

A Content Assets does not contain the header and footer of the visual page. This usually is rendered centrally by SFCC - or substituted by a mockup in AEM.

Content Assets are implemented as a Paragraph System ("parsys") on a dedicated Page in AEM. This parsys actually is what is statically rendered and exported to SFCC, the Page contributes Header and Footer. The parsys can contain either static components or Content Slots that are filled by SFCC upon delivering the content.

To preview a Content Asset that has not been exported to SFCC yet, both AEM and SFCC need to work in concert:

1. AEM renders the main page.

2. Header Navigation and footer can either be "simulated" (or mocked) by AEM or rendered by SFCC. In the former case this is just static HTML that looks like the real header and footer, in the latter case, the page uses a "placeholder" component at the top and bottom and asks SFCC to fill these with the according markup. This results in a request that is sent from AEM to SFCC in the backend. AEM serves as a proxy for the content, only.

3. AEM provides a special component that can be used as a Slot withing the parsys. This is how static AEM-based Content and dynamic SFCC-based Slots are mixed. This Slot-component also works a proxy. When the AEM component is rendered, a request in the background is sent to SFCC to provide the Slot's content, based on the Slot Configs that already have been published.

Note: Some of the preview-functionality require a special Cartridge to be installed into SFCC. This cartridge was build as a community project and published in the Salesfore Partner Marketplace but now seems to have been removed. Please refer to Known Issues for tips how to handle this limitation.