Easily manage content in Salesforce Commerce Cloud

Published on 26 Mar 2019

Salesforce Commerce Cloud is a great shop environment and FirstSpirit a great content management system. Combined they provide editors the possibility to create great content for the shop with ease.

Dr. Max Möllers

CEO and Project Management

ContentConnect Integration

Ansicht einer Startseite für des FirstSpirit Starter Pakets für Salesforce Commerce Cloud

Salesforce Commerce Cloud ( SFCC) has a lot to offer: various payment options, reliable hosting and scaling, sophisticated management of products and categories, and varied discount and campaign options.

However, when you want to do more than a pretty product catalog but rather a shopping experience, you need more sophisticated content editing tools.

FirstSpirit is such a content management system and it easily integrates with SFCC. Instead of forcing the editor to learn HTML, he can create content with an intuitive user interface and publish to the shop with the click of a button.

We will take a look at how the ContentConnect integration works. Many concepts are similar in other integrations of FirstSpirit with a shop or portal.

Architecture

Architectural sketch of the FirstSpirit module

The integration consists of two parts:

On the FirstSpirit side, we export managed content via XML files to the shop. This data is imported by the shop, which turns them into genuine shop content. Apart from the technical names, the content from FirstSpirit does not differ from content that was managed in the shop. Still, FirstSpirit is the leading system for the managed content, the shop always gets the current version after its release.
On the SFCC end, the shop provides information about products and categories to the CMS. This way editors can for example easily link products without rememebering cryptic product IDs or URLs. Although the data is used by the CMS, the shop is always the leading system for the product catalog.

Content delivery is always performed by the shop. The FirstSpirit servers are only involved in the creation and can thus be hosted either on-premise or in the cloud without any additional connection to the internet. This has various benefits for security and reliability. Additionally, the CMS does not have to scale with the number of shop visitors, but only with the number of editors which allows for a lot simpler server setups.

Deployment

In contrast to a web-CMS, the shop does not use pages and sections as a core unit, but rather snippets of conted called "assets". An example would be a banner image with a link to a product. Those assets can be used on any number of actual webpages in the store. These assets are exported from FirstSpirit via an XML file.

<content content-id="fs-homepage-301721">
    <display-name xml:lang="x-default">Homepage</display-name>
    <online-flag>true</online-flag>
    <searchable-flag>true</searchable-flag>
    <custom-attributes>
        <custom-attribute attribute-id="body" xml:lang="default">
            <![CDATA[ 
            <img class="top-banner" src="https://img.shop.com/i/banner.png">
             ]]>
        </custom-attribute>
    </custom-attributes>
    <folder-links>
        <classification-link folder-id="fs-global"/>
    </folder-links>
</content>

The CMS generates a second XML file with metadata that tells the shop where to use the assets exported in the first file. Optionally, you can tell the shop to only show the assets for specific target groups, only during a campaign, etc.

<slot-configuration assigned-to-site="true" 
                    configuration-id="fs_slot_configuration_301721" 
                    context="global" default="true" 
                    slot-id="home-main">
    <template>slots/content/contentassetbody.isml</template>
    <enabled-flag>true</enabled-flag>
    <content>
        <content-assets>
            <content-asset content-id="fs-homepage-301721"/>
        </content-assets>
    </content>
</slot-configuration>

There are various options for transferring content from the CMS to the shop. An easy setup is to use WebDAV; SFTP is also quite common.

Note: SFCC uses a classic setup with a staging and a production environment. Thus content that was changed in the CMS needs to go first to the staging environment and is then replicated to production. Usually, the replication step is the bottleneck for updates with respect to organisation and time. You can circumvent this by installing a second delivery tier such as FirstSpirit CaaS or elasticsearch in parallel that provides the CMS content, whereas the shop still provides the product information. Using such a stack and delta deployments makes it possible to push content updates to production in a matter of seconds. A delta deployment calculates the changes since the last publication and only transfers the elements that have been changed instead of all elements in the CMS.

Setting it up

The following five steps are necessary to make use of the integration:

Install the ContentConnect integration in SFCC.

Configure access rights in the shop so that the content can be imported and the CMS can retrieve product information.

Tell FirstSpirit about the shop and the credentials.

Update page templates in the shop.

Update page and section templates in the CMS.

The first three steps only need to be performed once and only take about an hour. They are also explained well in the official documentation. Thus, we will focus on steps 4 and 5 on how to update the templates.

Template modification in the CMS and the shop

Why do we have to modify the templates at all?

As the content from the CMS should match the design of the shop content, we obviously need to adapt the CMS templates to create the correct HTML.

However, we also need to do some (small) change to the shop templates. To understand this, let's take a look on how the CMS creates the content preview for the editing environment.

As the shop delivers the content, only it knows the final layout and design of all elements. FirstSpirit only knows about its content and how those snippets look. This means that for previewing a page, the CMS needs to retrieve the webpage from the shop and then place the content from the CMS "on top".

As an example, let us consider the banner of a page and assume that there is an update for it in the CMS.

The preview filter, which is part of the integration:

retrieves the webpage and its HTML from the shop
identifies the banner in the HTML
retrieves the current version of the banner from the CMS
exchanges the old version in the HTML with the updated from the CMS.

But how does the filter identify the banner? We make it easy for it to identify by encapsulating the banner with HTML comments such as  and . We do this in both the shop and the CMS, so it can easily search for those kind of comments and exchange appropriately.

<!-- CMS-BANNER-START -->
    $CMS_VALUE(#global.page.body("cat_landing_slotbanner"))$
<!-- CMS-BANNER-END -->

This is the whole reason we need to adapt the shop templates.

We now have a content preview with the layout of the shop that also includes the latest CMS content.

<isdecorate template="common/layout/page">
    <isscript>
        var assets = require('*/cartridge/scriptsassets');
        assets.addCss('/css/search.css');
    </isscript>
    <!-- CMS-BANNER-START -->
    <isslot id ="cat-landing-slotbanner" context="category"
               description="Banner at the top of the CLP" 
               context-objects="${pdict.category}" />
    <!-- CMS-BANNER-END -->
</isdecorate>

We can use this search-and-replace functionality not only for updates of content, but also to fix some technical issues that might come up in "reusing" the shop page for editing content. For example, if the page contains links to shop functionality, e.g. a language selector, we can replace that HTML with our own language drop-down that allows the editor to switch the language in FirstSpirit. Another example would be to remove JavaScript libraries that track the user - we do not need that when editing content.

Summary and next steps

In this article we showed the architecture and main components of the integration of FirstSpirit with Salesforce Commerce Cloud.

It is a lightweight integration on the shop end that can be introduced with low risk. The integration contains a starterkit and a sample project that allows very simple first steps. With a competent partner you can have the first page type manageable and production-ready (!) in the CMS on the first afternoon.

Following that you can use more and more of the powerful content editing options of FirstSpirit. These allow you to reduce multi-site or multi-brand projects with dozens of editors to managable complexity. Thus, everyone can focus on creating better content, better campaigns and thus increase the conversion rates of the shop.