SAP Commerce Cloud Architecture
14 min read
Although we have covered some of the high-level architecture of SAP Commerce Cloud in our article "Getting Started with SAP Commerce Cloud", here we will focus on some of the practical architectural decisions that will need to be made during your project. When working with SAP Commerce Cloud, you might perceive that some constraints exist that didn't exist during on-premise projects. However, this isn't the case. It is just a matter of designing your solution differently, which we will cover below.
Table of Contents
- High-Level Software Architecture
- Web and Network Tiers
- Additional Server Hosting & Third-Party Software Applications
- Cloud Hot Folders (Extended Hot Folders)
- Cronjobs Execution
High-Level Software Architecture
SAP Commerce Cloud consists of a combination of mandatory and optional software packages that can be used to create a tailored commerce solution. These include:
- Microsoft Azure - provider of public cloud infrastructure
- SAP Business Technology Platform - business platform used to host applications/services like SAP Commerce Cloud Portal, SAP ntegration Suite and SAP Extension Suite
- Kubernetes - Used to orchestrate docker nodes necessary to run a commerce solution
- SAP Commerce (release notes) - the core platform which is combined with your custom code during the Cloud Portal build process
- Accelerator - customized storefront based on templates provided in SAP Commerce.
- Industry accelerators (documentation) - Industry specific storefront templates
- Data Hub (documentation) - an option for importing/exporting master data for each of your SAP Commerce Cloud environments. See Integration Options for SAP Commerce Cloud for more details.
- SAP Extension Suite - the microservices extensibility layer, based on the open-source project "Kyma". See Integration Options for SAP
Commerce Cloud for more details.
Web and Network Tiers
If you're looking to configure your Commerce Cloud website, including bringing your own Content Delivery Network or Web Application Firewall, as well as VPN/NAT configurations, please see our article SAP Commerce Cloud Architecture - Web and Network Layers. We do not post detailed network diagrams, because network infrastructure changes frequently depending on new features and security and application requirements.
Additional Server Hosting & Third-Party Software Applications
Often you will need your SAP Commerce Cloud solution to interact with a third party application. If your third party application requires access to a server or can't be achieved through the fixed build and deployment process (i.e. requires more than what can be done through "ant all" target) then it can't be part of your SAP Commerce Cloud code, and will need to be hosted elsewhere. This section documents some common examples in more detail, but other options may include third-party CMS or setting up a private repository for binary packages.
When planning out your application, think carefully about which applications, binaries or infrastructure components (beyond the Commerce application and database) form part of your target architecture. The examples in this section do not rule out more diverse target architectures, but do require an architectural design that will promote a separation-of-concerns between the productive SAP Commerce Cloud subscription and additional components that the individual project relies on (not provided by SAP Commerce Cloud).
Continuous Integration / Continuous Delivery (CI/CD)
As per the documentation (link), if you're looking for complex automated pipelines or per-commit builds, you're going to want to set up your own CI/CD instance. This will give you flexibility and control to ensure that your code is built and tested before you build/deploy to one of your shared SAP Commerce Cloud environments. You can remotely execute a build/deploy using the Commerce Cloud APIs. Your CI/CD instance should be able to connect to the same Git repository used by SAP Commerce Cloud. The location of your CI/CD application does not matter as much since it doesn't directly affect the performance of your SAP Commerce Cloud solution. If you find the latency for pulling down the code from your Git repository is too long, you may consider moving where your CI/CD application is hosted. For more on setting up CI/CD for your SAP Commerce Cloud solution see Implement Continuous Delivery with SAP Commerce Cloud.
Image resizing is typically done within Commerce through an extension that usually relies on
a third-party software (ImageMagick) installed on the Commerce server. With
the Cloud Automation 1912 release, an image conversion service is available in SAP Commerce
Cloud, and can be enabled when the
cloudmediaconversion extension is included in your manifest
file. For more information please see this page in the product documentation.
Third Party Application
If there is an application that your SAP Commerce Cloud solution requires that isn't already hosted by a third party, you should consider where to host it. The recommendation is to try to minimize latency by running it in the same Azure Date Center as your Commerce Cloud subscription. If you don't know which data center is being used you can find this info via the Cloud Availability Center. If you do not want to use Azure you can look for equivalent public cloud providers in the same region, though there likely will be additional latency as the calls go to an external data center. If it's an asynchronous call or one that is not happening often this additional latency may not be a showstopper for your solution.
The example above consists of an application running on a self-hosted server and exposing REST services which can be called by one or more of your SAP Commerce Cloud aspects.
Scalability (Horizontal scale: Add more nodes)
Latency can become an issue. We recommend hosting it (with your own subscription) in the same data center as your SAP Commerce Cloud solution
Decrease CPU/Memory usage on the Commerce aspect
Requires additional infrastructure (Cloud/On-premise)
For other potential integration options please see our article covering the Integration Options for SAP Commerce Cloud.
SAP Commerce uses the web content management system (WCMS) module to define and generate e-mails, thus leveraging the WCMS components that are rendered within the e-mail text. Under the hood, Apache Commons Email library provides all the required software infrastructure, which ties the solution to the simple mail transfer protocol (SMTP). SAP Commerce Cloud acts as a client but an SMTP server/service is required.
SAP Commerce Cloud does not provision an SMTP server which means you must provide an alternative SMTP strategy.
The article "Integrating an Email Service with SAP Commerce Cloud" provides more information on how to design and implement an e-mail service using one of the two recommended approaches:
- Customer Hosted SMTP Server
- Third-Party SMTP Service
Cloud Hot Folders (Extended Hot Folders)
Hot Folders have evolved to be the file-based integration strategy for SAP Commerce Cloud and are now called Cloud Hot Folders.
At a high-level, the following diagram shows how the solution has evolved from SAP Commerce Cloud on SAP Infrastructure to the new SAP Commerce Cloud. The major updates are:
- Remote Storage Support (Azure Cloud Storage)
- Support for ZIP Files (Core Data, Sample Data and Raw ImpEx Files)
- Support for URL Media Files
- File Sorting
- Improved Monitoring
Within SAP Commerce Cloud, the Hot Folders module was extended to include the above improvements. As SAP Commerce Cloud uses ephemeral disk storage, an SSH file transfer protocol (SFTP) server (for uploading media) or data files (for importing) is no longer provided. Instead, you have a Cloud Hot Folder that makes use of the Azure Blob Store as a file source.