Sitecore Experience Accelerator Creative Exchange Import

Photo by Matthieu Comoy on Unsplash

The Traditional Front End Web Static Assets Flow

Traditionally, a Front End Developer will run whatever tooling they desire, to build and output the final compiled CSS and Javascript files as distributed. During this process, it may involve:

• using a lot of NodeJS modules
• different types of task runners (eg, Grunt, Gulp, WebPack etc)
• running unit tests, code scanning (eg. SonarQube, Sonar Cloud, Veracode), test coverage reporting or other reporting
• different ways to minified / uglified / obfuscate the output
• finally putting those output distributed files into a folder structure of some sort, to be finally copied, or deployed to the web site.

As of SXA 1.7, this traditional flow can now be achieved, especially from CI / CD pipelines.

Sitecore Experience Accelerator Creative Exchange Import

There are already existing methods to compile and import JS and CSS when working on a local developer instance of Sitecore. Experience Accelerator provides Gulp tasks to stream those into Sitecore.

However this method does not work in other environments that are not local developer instance. In SXA 1.7, Sitecore introduced a way to trigger Creative Exchange Import via a URL request from Content Management instance.

Trigger Creative Exchange from your CI server

My personal preference is to create a service account user, which has admin access, with a random password that is stored as a secret variable to be used in a non local Sitecore instance. Here is an example config patch to enable RestfulV2 for Sitecore Powershell Extensions.

Here are two samples Powershell Script that can be called to invoke any Sitecore Powershell Extensions scripts that is inside /sitecore/system/Modules/PowerShell/Script Library, with any parent folder that is inherited from template
/sitecore/templates/Modules/PowerShell Console/PowerShell Script Module with “
Enabled — Enables the module for all integration points” checkbox checked.

Using Sitecore Powershell Extensions 5.0 Restful API v2 using Query String Authentication

Using Sitecore Powershell Extensions 5.1 and above Restful API v2 using Basic Authentication

Setting up the Full Import Process

To start off, perform a full Creative Exchange Export with Agency drop as an option, and Export to Folder on server.

Sample Creative Exchange Export Settings

Clean up all the folders that are not required for the front end build produced assets, you should end up with something like below. The front end build should produce all the distributed files into a folder structure that can easily be dropped into App_Data/packages/CreativeExchange/FileStorage/<Site>/-/media/Themes/<Tenant / Site>/<Theme Name>

An example of the theme structure for Habitat Home Platform

Sitecore provides a sample Creative Exchange Import script located at /sitecore/system/Modules/PowerShell/Script Library/SXA/SXA — Creative Exchange/Web API/ce-import

I have enhanced it to be more generic, which is way more extensive than what is provided out of the box from Sitecore Experience Accelerator.

Sitecore Powershell Extensions Script that handles the Creative Exchange Import process

I will quickly step through my process.

1. Both the Site item path and Device ID can be passed into the script
2. There is a simple logic to determine whether asset optimisation is enabled for the site and globally on the Sitecore instance.
3. Delete all the Styles, Scripts, Fonts and Images under the specified Theme folder from the Site Theme Folder setting, but leaving the folder structure in tact (Styles, Scripts, Fonts, Images). If Asset Optimisation is used, the optimized files will not be deleted.
4. Runs the Creative Exchange import process
5. Publishes the entire theme folder to all publishing targets, for all languages that are available to the site. Utilising PublishingManager which will work for traditional publishing, as well as Publishing Service.

Triggering Front End Build and Import

The following script is used for both our local development machines, as well as the CI / CD pipelines. This ensures that the script is used so extensively that any enhancements or defects can be picked up early on. As it is just a simple Powershell script, it can easily integrate into any build process, be it MSBuild, Gulp (vomit), Helix Publishing Pipeline, or the latest fancy task runner Cake. The following is a sample, it should be straight forward enough to understand from the code documentation and comments.

The Front End Build Powershell Script

Something to keep in mind with Security Hardening the Content Management instance, where CM is blocked off from public access. When using Azure DevOps hosted agents for the release pipeline, additional tasks are required to allow for the hosted agent IP to be temporarily whitelisted, so that the Invoke-WebRequest to CM can be reached. In the case where there is no public IP at all for CM (eg. Azure App Service Environment), provisioning an ephemeral agent into the same network / VNET / subnet may be required. For more details, have a look at this wonderful GitHub repo from Microsoft.
https://github.com/microsoft/azure-pipelines-ephemeral-agents

Some Additional Front End Build Enhancements

On top of the provided gulp tasks from Sitecore Experience Accelerator, there are a few more enhancements specifically cater for Front End Developers who also has a Sitecore instance running on their PCs, to streamline their process.

Aside from using watch tasks to automatically import front end static assets into Sitecore, the watch tasks should also extend to cover publishing the imported assets to all publishing target databases. The watch tasks should also cover razor views CSHTML files modification, and automatically copies them to the web site folder, rather than waiting for a full MSBuild to build / deploy those files.

To support the above, I have introduced an environment for local developer instance, which I shall call “LocalDeveloper”. Then using Sitecore Role-Based / Environment Require configuration, the precompilation of Razor Views can be slightly modified for LocalDeveloper environment.

Razor Views Precompilation configuration for Local Developer environment

Conclusion

I hope what I have demonstrated in this blog post will help development team streamline the SXA Front End Development process somewhat. Finally avoiding serialising and source controlling the final output into the solution. I have rolled this out to a Sitecore Commerce 9.1 solution, which utilises both SXA and Commerce Experience Accelerator, where both front end and back end developers have a full Sitecore Commerce setup in all their PCs.

I am also rolling this same process out to another development team, which consists of front end developers who do all their development in Macs.

At a quick glance with Sitecore SXA 9.3 documentation, which has not changed since 1.7, I believe this same process should also work. When I eventually find some time, I will evaluate this process for SXA 9.3 and make the necessary adjustments.