Martijn Dull
Read all my blogsSpartacus: a different configuration per environment on SAP Commerce Cloud
Martijn Dull, 19 January 2022
Spartacus is a great storefront to use in combination with your SAP Commerce Cloud solution if you want to be able to set up a storefront in a short time frame or if you want your storefront to be flexible for customisation.
However, during one of our recent projects we ran into a limitation with the current version of Spartacus. In our software development life cycle, we make use of different environments during different parts of the development process. Code is first written by the software developers on their own system using a local Development environment. Their work is then tested by test engineers on the Test environment. After testing, the changes are deployed to the Acceptance environment, which is followed by a deployment to the Production environment where the customer visits the store.
These four different environments all have some differences in their configuration. For example, the URL to the API in SAP Commerce Cloud is unique for every environment. This means that for every environment, the storefront needs to make network requests to a different URL to communicate with the correct API. Otherwise, the data in the Production environment might for example be overwritten by data meant for the Test environment.
Since Spartacus is based on Angular, we tried the official approach mentioned by SAP that involves creating a different configuration file per environment and including the correct file during the build process. This would have worked if we only had two environments, with one of those two being the Production environment, but since we have four environments this didn’t solve the problem for us.
Searching online, it seems that many other developers have the same problem and they all seem to use a different solution to solve it since there is no official solution from SAP. For our project, my colleague Wilco Menge came up with the following solution:
First we changed our configuration file (config.json) from a JSON file to a JavaScript file (config.js), which would look like this:
[abap]
let config =
{
backend: {
occ: {
baseUrl: "api.example.com",
}
}
}
export {config}
[/abap]
Of course you could also include other configurations in this file, but for this example we’ll leave it at the baseUrl that is needed to communicate with the API.
One copy of this file exists in the assets folder of the project and has the configuration that is required for the local Development environment.
A JavaScript file needs to be created for every other environment that is used, with the values changed to match what is needed for the configuration of that environment. Since the configuration file was locally located in the assets folder of the project, a ZIP file needs to be created with the same structure. So in this case, a ZIP file with a folder called “assets” that contains the file “config.js”.
After creating these files, they need to be added to the environments themselves. This is done through the SAP Commerce Cloud Portal. In the Portal, a new Static File needs to be created for every environment by uploading the ZIP files. The Static Files can then be linked to a specific environment by editing the storefront endpoint of the environments in the Portal and selecting the relevant Static File set.
After this is done, the configuration files need to be added in a script tag in the index.html file in the Spartacus project, so the configurations are actually used by the storefront. This was done by including the following script tag:
[abap]
<script type="module">
import { config } from ‘./assets/config.js’;
window.config = config;
</script>
[/abap]
The reason that we added this tag in the index.html file instead of importing it in a JavaScript file is that the build process bundles all files, including the version of the config.js file that is located in the project itself. When this file is bundled, the import in the JavaScript file would use this file instead of the version added as a Static File. By importing the configuration file through a tag in the index.html file, the Static File will be used.
Following this, the spartacus-configuration.module.ts file can now access all data from the config.js Static File, which in this example means that the storefront can now communicate with a different API per environment and there is no longer any risk of data being sent from the storefront to the wrong SAP Commerce Cloud environment.
We still hope that SAP will provide an official solution in the future, but in our projects the problem is solved.
Receive our weekly blog by email?
Subscribe here:
One response to “Spartacus: a different configuration per environment on SAP Commerce Cloud”
Hi Martijn,
Thanks for posting this solution. I have tried it, but the only issue I am facing is that ti throws an error on the server that it’s unable to find a reference to the window object. I am a Backend Dev, so not too sure about how angular works, but just wondering if you faced a similar issue and how did you fix it.