SAP Commerce Cloud architecture overview

SAP Commerce Cloud Architecture

Although we introduced some of the high-level architecture of SAP Commerce Cloud in the article "Introduction to SAP Commerce Cloud", here we will focus on some of the actual architectural decisions that need to be made during your project. When using SAP Commerce Cloud, you may find that there are some limitations that do not exist in the On-Premises project. However, it is not. It's just a matter of designing your solution in a different way.

High-Level Software Architecture

SAP Commerce Cloud contains a combination of mandatory and optional software packages that can be used to create customized commerce solutions. These include:

Cloud automation

• Microsoft Azure-public cloud infrastructure provider
• SAP Business Technology Platform-a business platform for hosting applications/services such as SAP Commerce Cloud Portal, SAP ntegration Suite and SAP Extension Suite
• Kubernetes-used to orchestrate the docker nodes required to run commercial solutions

Customizable software

• SAP Commerce-the core platform combined with your custom code during the Cloud Portal build process
• Accelerator-A customized storefront based on templates provided in SAP Commerce.
• Spartacus JavaScript storefront-a decoupled open source storefront that uses the Omni Commerce Connection (OCC) API to communicate with your SAP Commerce Cloud environment. For more details, see Choosing which storefront to use for your SAP Commerce Cloud solution.
• Industry Accelerator (Document)-Industry Specific Storefront Template
• Data Center (Document)-option to import/export master data for each SAP Commerce Cloud environment. For more details, see Integration options for SAP Commerce Cloud.
• SAP Extension Kit-a microservice extension layer based on the open source project "Kyma". For more details, see Integration options for SAP Commerce Cloud.

Additional Server Hosting & Third-Party Software Applications

Generally, you need SAP Commerce Cloud solutions to interact with third-party applications. If your third-party application needs access to the server or cannot be achieved through a fixed build and deployment process (that is, it needs more than work that can be done through the "ant all" goal), then it cannot be part of your SAP Commerce Cloud code needs to be hosted elsewhere. This section documents some common examples in more detail, but other options might include a third-party CMS or setting up a private repository for binary packages.

When planning your application, carefully consider which applications, binaries, or infrastructure components (beyond Commerce applications and databases) form part of your target architecture. The examples in this section do not rule out a more diverse target architecture, but it does require an architecture design to facilitate the separation of concerns between productive SAP Commerce Cloud subscriptions and other components that a single project depends on (not provided by SAP) Business cloud).

Continuous Integration / Continuous Delivery (CI/CD)

If you are looking for a complex automated pipeline or submit a build every time, you will need 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 it is built/deployed to one of the shared SAP Commerce Cloud environments. You can perform build/deploy remotely using the Commerce Cloud API. Your CI/CD instance should be able to connect to the same Git repository used by SAP Commerce Cloud. The location of the CI/CD application is not important because it does not directly affect the performance of the SAP Commerce Cloud solution. If you find that the delay in extracting code from the Git repository is too long, you can consider changing the hosting location of your CI/CD application. For more information on setting up CI/CD for SAP Commerce Cloud solutions, see Implement Continuous Delivery with SAP Commerce Cloud.

Image Resizing

Image resizing is usually done in Commerce through extensions, which usually rely on third-party software (ImageMagick) installed on the Commerce server. In Cloud Automation version 1912, the image conversion service is provided in SAP Commerce Cloud and can be enabled when the cloudmediaconversion extension is included in the manifest file.

Third Party Application

If your SAP Commerce Cloud solution requires an application that has not been hosted by a third party, you should consider where to host it. It is recommended to try to minimize latency by running it in the same Azure Date Center as the Commerce Cloud subscription. If you don't know which data center you are using, you can find this information through the Cloud Availability Center. If you don't want to use Azure, you can find an equivalent public cloud provider in the same region, although there may be additional delays when the call goes to an external data center. If it is an asynchronous call or an infrequent call, then this additional delay may not be the key to your solution.

The example above contains an application running on a self-hosted server and exposes REST services that can be called by one or more aspects of your SAP Commerce Cloud.

E-mail Service

SAP Commerce uses the Web Content Management System (WCMS) module to define and generate emails, thereby leveraging the WCMS components presented in the email text. Behind the scenes, the Apache Commons e-mail library provides all the necessary software infrastructure, linking the solution with the Simple Mail Transfer Protocol (SMTP). SAP Commerce Cloud acts as a client, but requires an SMTP server/service.

SAP Commerce Cloud does not provide an SMTP server, which means you must provide an alternate SMTP policy.

Cloud Hot Folders (Extended Hot Folders)

Hot Folders has evolved into a file-based integration strategy for SAP Commerce Cloud and is now called Cloud Hot Folders.

The following figure shows in a nutshell how the solution evolved from the SAP Commerce Cloud on the SAP infrastructure to the new SAP Commerce Cloud. The main updates are as follows:

• Remote storage support (Azure cloud storage)
• Supports ZIP files (core data, sample data and original ImpEx files)
• Support URL media files
• File sorting
• Improved monitoring

In SAP Commerce Cloud, the Hot Folders module has been expanded to include the above improvements. Since SAP Commerce Cloud uses temporary disk storage, it no longer provides an SSH file transfer protocol (SFTP) server (for uploading media) or data files (for importing). Instead, you have a cloud hot folder that uses Azure Blob storage as the file source.

Caching

Content Delivery Network

Get the IP of the endpoint to be cached (for example, storefront, backend). To do this in Cloud Portal, select the environment and click the endpoint link for the endpoint. When the Edit Endpoint screen opens, find the domain field in the basic configuration section. The DNS name of the endpoint is the domain address. You can try to use NS lookup to get the IP.

During your environment, the IP of your endpoint is static. If your environment is reconfigured, the IP is likely to change. Therefore, you also need to update through the CDN provider.

Provide these IPs to your CDN provider.
If your endpoint is not publicly accessible, make sure you have added the CDN to the IP filter list.

Region Cache

SAP Commerce Cloud utilizes SAP Commerce's existing regional cache. However, since the SAP Commerce Cloud build process controls the Java heap size, which may vary from environment to environment, the cache area needs to be configured in a flexible way, rather than setting a fixed value internally.

Cronjobs Execution

A key consideration when preparing to use SAP Commerce Cloud is to ensure that any batch processing job runs reliably within the fixed resource footprint of "backgroundProcessing" when processing data sets that represent production. This is especially true if you are migrating from SAP Commerce Cloud or on-premises instances on SAP infrastructure. The'backgroundProcessing' aspect will run any automatically triggered cronjob; if you manually trigger the job from the "background" aspect, it will run on the node that triggered it.

For example, you can develop a batch processing job for loading price information, and load the entire price line file into the memory for processing. This is generally considered bad practice when dealing with file import. The reason is that although this may work reliably in a development environment when testing with a small data set, in a production environment, the actual price line file size may be hundreds of megabytes, and the allocation to Only the resources of the Java virtual machine can reliably load files into memory. If this happens on SAP Commerce Cloud, the resources allocated to a single "background processing" node cannot be expanded.

Therefore, all batch processing jobs should be developed as:

• Effective use of allocated resources, batch import and active release of references, in order to achieve a consistent memory configuration file throughout the import process.
• Avoid unnecessarily loading large data sets into memory.
• Distribute large batch processing tasks in the "backgroundProcessing" aspect.

Customers migrating to SAP Commerce Cloud using existing projects should check their batch processing jobs to verify that they have complied with these guidelines.

Conclusion

Although SAP Commerce Cloud provides most of the infrastructure with a consistent architecture, there will always be external systems that need to interact with your business solutions. A proper understanding of the features and advantages of the existing SAP Commerce Cloud architecture will help you design new integrations.

More original articles by Jerry, all in: "Wang Zixi":