Overview

Your SAP Commerce Cloud solution does not live in a vacuum. Integration or extensibility can be required just about anywhere–whether it's importing the latest pricing data, to calling a service to calculate loyalty points for a product or notifying a user when a product comes back in stock. The types of integrations can vary, such as payment, shipping, reviews or may require  connecting to other SAP solutions like SAP Customer Data Cloud or SAP S/4HANA. With SAP Commerce Cloud being a Platform-as-a-Service (PaaS) solution, you have many options for extending and integrating your solution. In this article we intend to highlight how you can extend and integrate Commerce Cloud across a variety of common situations. The goal is to move away from "classic", tightly coupled in-app extensions of SAP Commerce and move towards a decoupled, cloud-friendly way of extending and integrating your SAP Commerce Cloud solution. This article will use some of the key aspects covered in Overview of SAP Customer Experience solutions Integration and Extension Options to guide you in your decision on which integration option(s) might be best.

Table of Contents

High Level Architecture

The architecture diagram below outlines the standard high level architecture for an SAP Commerce Cloud solution. For a deeper dive into the architecture, please refer to SAP Commerce Cloud Architecture.

Core Principles

When deciding on integration and extensibility of your SAP Commerce Cloud solution we recommend you follow these principles:

• Side-by-Side extensibility is preferred over In-App extensibility.
• Asynchronous extensibility is preferred over synchronous extensibility.
• Runtime configuration is preferred over build time configuration.

Adoption of these principles will:

• Reduce the need for classic Commerce Cloud extensions - Commerce REST APIs and subscribable events can be consumed and configured at runtime without the need for custom extensions
• Decouple your custom extensions from the core Commerce Cloud - Side-by-side extensibility enables you to develop your customizations using the technologies and platform of your choice and allows you to separate your development teams/cycles.
• Simplify Commerce Cloud upgrades - Customizations done outside of the core Commerce Cloud result in less custom code in classic Commerce Extensions.  Upgrades are greatly simplified when fewer custom classic Commerce Cloud extensions are present.
• Reduce project implementation time - As more customization is done at runtime and outside of Commerce Cloud, the frequency to build, initialize, and deploy Commerce Cloud is reduced, thus reducing implementation time. In addition, you can separate your development teams and project lifecycles to give you more flexibility to deliver features when they are ready.

Extensibility Patterns

Extensibility in SAP Commerce Cloud can be broken into two main patterns: Side-by-Side and In-App.

Side-by-Side Extensibility

Side-by-Side is an extensibility pattern where you extend Commerce Cloud outside of the core application.  The extensions and customizations you create are decoupled from the core applications, which means that:

• Deployments of your side-by-side extensions are independent from Commerce Cloud, permitting independent update and release cycles
• Scaling is independent from the deployed Commerce Cloud solution
• The changes you make can be easily reverted without causing downtime of the production Commerce Cloud system
• You develop your side-by-side customizations on the technology stack of your choice, using the hyperscaler of your choice

In-App Extensibility

In-App Extensibility is a pattern where customizations are done within the core Commerce solution.  Historically, this has been implemented using classic in-app Core Commerce extensions. Aside from these, SAP also provides a number of In-App extensibility options that can be fully configured at runtime without the need for extensions.

Integration Options

When connecting or extending your SAP Commerce Cloud solution, there are many options to choose from. In this section we highlight what is available. The table below summarizes the common integration options, classifying them by the use cases:

SAP Store

The SAP Store is a fully digital, enterprise marketplace where you can discover, try, buy, manage, and deploy trusted partner applications and additional services that extend your existing SAP technology and solutions. By leveraging these existing applications, you can quickly integrate with the vendor without the need to start from scratch. In some cases, you can extend the applications to align with your business requirements, as well as gain additional support. The SAP Store is typically used for common integrations such as payment, tax and enriching the customer experience.

Pre-Built Integrations

SAP provides many pre-built integrations between Commerce Cloud and other SAP products.  This includes pre-built integrations with SAP S/4HANA, SAP ERP, SAP Marketing, SAP Customer Data Cloud, and many others. For available integrations see this page.

Integration APIs

SAP Commerce Core includes a set of OData Services, as well as the ability to create your own custom integration objects and RESTful APIs for importing/exporting data. An Integration Object(IO) describes the structure of a business-level entity. Integration objects are the foundation for an EDMX schema and for the APIs used for Process Integration and Master Data Synchronization of SAP Commerce.

When you need to send or retrieve data from your Commerce solution, OData Services should be the first consideration. At a high level it works as follows:

1. Define the model the third party system will need and then create an internal representation of this model using the Integration APIs. If an attribute is missing, consider defining a Runtime Attribute. If your model requires data formatting, payload enrichment or payload flattening consider defining a Virtual Attribute.

   Virtual and Runtime attributes are configured at runtime and will not persist across environments or after an initialization.

2. If using the Backoffice, view the EDMX schema, example json payload, and the visual composition of the IO in the Meta modal window.
3. Create an Inbound Channel Configuration in order to specify the authentication of your API.  The available options are Basic or OAuth2 security. 
4. Assign the correct access rights for authorization purposes.
5. Test your Integration Object returns the right data by calling the corresponding Integration API. 

Extensibility

Highly extensible. You are able to create any integration object to represent your model and have OData Services that can be called to perform CRUD operations

Scalability

If you notice issues with your aspect resources being over consumed due to the OData Service calls, please open a ticket with SAP Support. Typically the Integration APIs are highly performant, but the aspect may need to be scaled.

Audit and Control

Monitoring and control of the services can be done in SAP Commerce Cloud (for example, Inbound).

Testability

If you're just looking at testing and monitoring the inbound-outbound services, you can look at some examples here.

Ease of Deployment

No deployment is required. A business user can model their own integration object in backoffice, via ImpEx or the MetaAPI.

Reliability & Stability

As long as your SAP Commerce Cloud solution is running your Integration APIs will be available. You can use the SAP Commerce Cloud Backoffice UI Tool to monitor and troubleshoot issues as shown in this example.

Examples

Numerous examples exist for Integration APIs, including the pre-built integrations mentioned above that leverage SAP Business Technology Platform Integration Suite for connecting to S/4HANA, Cloud for Customer or Marketing Cloud. It's also used for replicating data directly for Customer Data Cloud. The OData Services are used by the SAP BTP Integration Suite as covered below, but middleware isn't always required. The OData Services can be used to directly import/export data from SAP Commerce Cloud. Some other examples include:

• Import physical store inventory updates to SAP Commerce Cloud
• Update an external cache (e.g. Redis) with required data, like price, inventory, cart
• Export order details for curbside pick-up

Recommendations

• To minimize the number of Integration Objects to maintain, determine if you can reuse existing objects. If your third party systems can receive additional data you may be able to reuse an existing integration object that has all the fields you require, but may contain additional fields as well.
• Leverage MetaAPI to keep integration objects consistent across local and cloud environments.
• Limit access to Integration UI perspective in backoffice to admins and owners of the integrations.
• Integration APIs are not exposed automatically. You need to ensure you have configured Authentication first.
• Configure access rights for each of your defined Integration Objects.

SAP Business Technology Platform (BTP) Integration Suite

Data integrations via BTP Integration Suite are the strategic way forward for the whole SAP Customer Experience solutions portfolio. With each new release of SAP Commerce Cloud Integration Extension Pack, additional integrations are being added. As mentioned above, the SAP Integration APIs are used along with SAP Integration Suite to connect to other solutions, including SAP Solutions like SAP S/4HANA. You can check the SAP API Business Hub, SAP Customer Experience solutions for the latest integration packages available to be used by SAP Integration Suite. It is important to remember for an integration to work, both the inbound and outbound services need to exist. An integration flow may be available in SAP Integration Suite, but the corresponding inbound or outbound service might not be delivered until the next Commerce Cloud Integration Extension Pack release.

Extensibility

 If you're not satisfied with the pre-built integrations, you can create your own custom Integration Objects as per of the product documentation tutorials. You can then use these custom Integration Objects by making them available as part of an integration API as outlined here. You can also customize your SAP Integration Flows (iFlow) to transform and load your data in the required format.

Scalability

The use of Integration Objects and integration APIs combined with SAP Integration Suite allows for a fully scalable integration solution. Both SAP Commerce Cloud and SAP Integration Suite provide scalability features. If you are noticing performance issues, try to narrow down to either SAP Commerce Cloud or the SAP Integration Suite and open a Support ticket.

Audit and Control

As mentioned above, monitoring and control of the odata services can be done in SAP Commerce Cloud (for example, Inbound). In addition, the logging of messages can be configured in SAP Integration Suite. Authentication and authorization to both SAP Commerce Cloud and SAP Integration Suite can be configured through multiple ways. Please see the respective product documentation.

Testability

You can easily test the various flows created in SAP Integration Suite as well as through the SAP Commerce Cloud back-office application. If you're looking to isolate the testing and monitoring to the inbound/outbound services in SAP Comemrce Cloud, you can look at some examples here.

Ease of Deployment

You need to connect both SAP Commerce Cloud and SAP Integration Suite as well as configure the iFlows you'll be needing. Please consult the documentation for your specific integration to determine how to configure.

Reliability

The integration is decoupled from the front-end, so if your processing nodes or SAP Integration Suite instances go down, your SAP Commerce storefronts will continue to operate, though your data will no longer be refreshed.

Stability

Unexpected results are logged. You can review both the integration flows in SAP Integration Suite and the messages that are being sent back and forth, to determine where the issue occurs. You can also use the SAP Commerce Cloud Backoffice UI Tool to monitor and troubleshoot issues as shown in this example.

SAP Business Technology Platform Extension Suite (Kyma Runtime)

SAP Business Technology Platform, Kyma runtime is a fully managed Kubernetes runtime based on the open-source project "Kyma". This cloud-native solution allows the developers to extend SAP solutions with serverless Functions and combine them with containerized microservices. The offered functionality ensures smooth consumption of SAP and non-SAP applications, running workloads in a highly scalable environment, and building event- and API-based extensions.

SAP BTP, Kyma runtime can be used to create and subscribe to services through the Service Catalog, including SAP Business Technology Platform and other third-party services such as Amazon Web Services, Google Cloud Platform or Azure.  Extensibility with an SAP Commerce Cloud solution can be achieved through the Application Connector, which provides an event model and API access for connected applications. See the documentation for more details on how to configure this connection.

The SAP Extension Suite allows you to leverages the concepts and innovations from project "Kyma" and will be an integral part of SAP Business Technology Platform (SAP BTP) itself, facilitating the management of connected systems and their respective extensions. If you're looking to get started, you will need to be on version of SAP Commerce 1811+. Please see the below video as well as the product documentation:

Extensibility

The SAP BTP, Kyma runtime is set up to be fully extensible. You will be able to create and subscribe to services through the Service Catalog, including SAP BTP and other third-party services such as AWS, GCP or Azure.  Commerce extensibility can be achieved through the Application Connector which provides an event model and API access for connected applications.

Scalability

The SAP BTP, Kyma runtime is an integral part of the SAP BTP. Therefore, it is fully scalable to meet your demands. The platform is based on Kubernetes which supports a wide variety of configurations to scale your extensions and services.

Audit and Control

The SAP BTP, Kyma runtime leverages the monitoring, tracing and logging features of project "Kyma". Security is also built-in, leveraging the Kubernetes Role Based Authentication and Dex, an open-source OpenID identity provider.

Testability

The SAP BTP, Kyma runtime leverages the testing mechanisms of the underlying Kubernetes and Helm components. In addition, namespaces (based on Kubernetes namespaces) allow you to partition your runtime cluster in a flexible way to define distinct environments such as development, test, performance, and production.

Ease of Deployment

If you do not want to use the The SAP BTP, Kyma runtime and all the support and improvements that come with it, you're still free to deploy the open-source project "Kyma" code on your own infrastructure. The connections are part of SAP Commerce and need to be enabled and configured to point to the right instances as per the documentation.

Reliability and Stability

The SAP BTP, Kyma runtime is subject to the SAP BTP Services Level Agreement. There may be additional items that are specific to the runtime, these will be listed as part of the services description.

Examples

• Save for later feature for items in the cart
• Price by fractional unit (weight, length, etc.)
• Geo-location (localization, restricted goods, etc)
• Ad-hoc language translation

Asynchronous Extensibility Using Events

Events are an  asynchronous  way for external systems to receive notifications about changes in SAP Commerce Cloud. Many common events are defined in SAP Commerce (see here), but you can also define your own events. Once the events are defined you can use webhooks or outboundsync to act upon the event.

Webhooks

Webhooks are the canonical way to subscribe to Commerce Cloud model events. They can be configured at runtime through Backoffice and the scripting engine (to define filters).

Extensibility

If you're not satisfied with the pre-built events, you can configure your own. You can create as many webhooks at runtime as you want via backoffice.

Scalability

The cluster your events and webhooks are tied to is defined when you export the event. In most solutions the Backoffice application is accessed via the backoffice aspect, so when you define an event for a whole cluster, this will assign it to the backoffice aspect. If you notice the nodes in your backoffice aspect are not performant and you can tie it to the events, please open up a ticket with SAP Support to scale up your backoffice nodes.

Audit and Control

The API Registry module provides a dead letter queue for exported events that cannot be delivered. You access the dead letter queue in Backoffice under System  API  Event Dead Letter Queue . In the dead letter queue, you see the details of all events that could not be exported, for example, the payload and the error that occurred. You can also add additional logging on the desitination side.

Testability

You can easily test your webhook by triggering one of the delivered events.

Ease of Deployment

If the events are already defined then no new deployment is required. You can configure a new webhook via backoffice to act on the pre-defined event.

Reliability

As an asynchronous process that is dependent on a particular event, hook and destination working perfectly means this is not a solution to depend on for reliable delivery.

Examples

• Back in stock text message notification.
• Adding loyalty points information to customer account when order is complete.
  
• Keep a 3rd party wishlist up to date.
• Notify account manager when a B2B order is rejected for a particular reason.

Recommendations

• Not useful for massive data transfer & replication.
• Low throughput, low latency, not reliable delivery.

OutboundSync

This is the canonical way to subscribe to massive data transfer & replication. There are multiple ways to configure outboundsync (model own integration object in backoffice, via ImpEx or the MetaAPI), but in general it comes down to the following steps:

1. Configure an integration object defining the fields you wish to import/export
2. Define the consumed destination for where the data will be coming from/going to
3. Configure the outbound channel through which the changes are sent
4. Configure change streams, which determine what changes should be processed and sent outbound. This can leverage delta detection to only send the data that has changed since the last run
5. Configuring a cron job that runs periodically and collects the changes since previous runtime and sends them out to an external system.

Examples

• Import/export inventory updates to third party OMS
• Send analytic data to reporting systems
• Import product data from external systems/resellers
• Send pricing data to a Redis cache

Recommendations

• High throughput, high latency, reliable delivery.

SAP Commerce, data hub

The SAP Commerce, data hub  ("Data Hub") was first introduced in SAP Commerce 5.2 to provide a flexible, scalable, and service-oriented solution to simplify and speed up data integration efforts (import and export) and Master Data Management between SAP Commerce and external data storage solutions and systems, such as Enterprise Resource Planning (ERP), Product Lifecycle Management (PLM), Customer Relationship Management (CRM), and more.  We recommend that you minimize extensive customizations of data hub and monitor the progress of the pre-built integrations on the Roadmap. When they meet your needs, you should include in your solution roadmap the task of migrating over to the integration APIs and BTP Integration Suite. Existing customers and those just starting on their project should be confident that the SAP data hub will still receive support. Any future deprecation will follow the process outlined in the deprecation status page.

For a video on how to use the SAP Data Hub, please consult the following Microlearning video.

To learn how to set up Data Hub for your SAP Commerce Cloud solution, consult this page.

Extensibility

The SAP Commerce, data hub is extensible. You're free to create a new extension for your new items. The biggest challenge typically comes when you need to manipulate existing items, like the target system. An example would be if you would like to change the exportcodes for the ImpEx header or the ImpEx column name (target item exportcode).

Scalability

Vertical scaling of the SAP Data Hub can be completed by creating additional pools. Horizontal scaling is possible by setting up a cluster. Each instance would have its own data partition in the database. All data loaded into a pool must be directed to the same node. Furthermore, only one node can be active for a pool. If you have multiple nodes for the SAP Data Hub, you would need to ensure that all of the same data types go to the same node. For more details, consult Scaling and High Availability.

Concurrency is only available when there are no dependencies between the data items across the data pools or instances.

Audit and Control

The SAP Data Hub provides complete transparency as well as a full history of data transformations, which are stored in the database attached to the SAP Data Hub instance. Aside from the history, there is a pre-built XML file that allows you to have control over what is being logged. See Configuring Logging in the SAP Data Hub for more information.

When it comes to using the main features of the SAP Data Hub, including analyzing errors, we recommend using the Backoffice Data Hub perspective. Within the user interface, there is a section that allows you to analyze the errors and failures, split by load, composition, and publication. See SAP Data Hub UI - Errors and Failures for more information.

Testability

A set of unit tests come with the SAP Data Hub code, as well as an example of an integration test. The scripts and steps to confirm your instance is working, as part of testing your local installation, can be used as a foundation for developing your own tests, and to confirm your instance is working correctly.

Ease of Deployment

The SAP Data Hub is deployed and monitored as part of your SAP Commerce Cloud subscription. Consult this page and its child pages to learn how to configure your code repository and manifest files to ensure your SAP Data Hub instances get deployed with your customizations.

Reliability

Calls are made asynchronously. Therefore, front-end performance won't be affected if the SAP Data Hub node(s) go down. The integration is decoupled from the front-end.

Stability

The configuration of raw, canonical and target items cannot be done at runtime. Modification of the XML should trigger a redeployment and restart of the SAP Data Hub instance(s). We recommend to turn off the processing as part of the deployment process, as any in-progress actions would need to be manually restarted post-deployment. You can perform many different tasks in the Backoffice Perspective, including loading, composing and publishing data, as well as creating new pools and feeds.

ImpEx

Import and export scripts (ImpEx), provided by the ImpEx module, can be used to get data in and out of your SAP Commerce Cloud solution. Although ImpEx was originally implemented to simplify the data setup in the system during development and this is the purpose it is still primarily used for, however it is also used by Data Hub and hot folders.

ImpEx can be executed in a variety of ways:  

• Admin Console (HAC)
• ImpEx API
• Service Layer
• Import/Export Cronjob and Backoffice Wizard (see ImpEx User Guide)

Custom generated ImpEx is typically run manually but sometimes it is run as part of a script or through hot folders. More often, the ImpEx is generated and executed as part of a middleware process (see SAP Data Hub example above) or as part of data migration.

Extensibility

ImpEx is one of the core foundations of data import-export in the SAP Commerce Cloud. There is extensive documentation on how to use ImpEx and many options to extend it. The syntax is based on comma-separated values (CSV). Aside from changing the "csv.fieldseparator" property, there isn't a lot that can be changed. That said, your ability to import or export is limited by what you've defined in your type system. Depending on what you put in your header and value rows will determine what gets imported.

Scalability

The execution of ImpEx can be distributed in many cases. Consult this page to understand how to configure and run distributed ImpEx.

Audit and Control

Running an import or export ImpEx creates a cronjob. Any errors will be captured against this job, as well as in the server logs.

Changes to data from ImpEx execution will not be recorded for audit purposes, as they are typically run using the administrator user. It is important to lock down access to the sections within the Backoffice and Admin Console (HAC) that allow a user to execute an ImpEx, as it can be used to alter any data in the system.

Testability

When executing an ImpEx file manually, you can validate the scripts thought the HAC. Be aware that the validation only confirms that things are correct from a syntactical point of view. Whether or not your data is correct or would be accepted (you may have some validation in place) won't be known until the ImpEx is executed. This is the same when executing through the API. You can write tests when using the API, but you would need to ensure the test data being passed in (or mocked) is valid unless you're testing a failure scenario.

Ease of Deployment

Since ImpEx is part of the platform code, it is deployed to all servers as part of your standard deployment. If you've implemented some code that uses the ImpEx API, then you would need to ensure that code is also included in your deployment process.

Executing an ImpEx file manually doesn't require any additional configuration or code changes and is a good option for administrators or those who have access to run them without requiring a code deployment or a restart of the server. This is not true when using ImpEx API for your custom code, as any changes to the execution flow would need a deployment.

Reliability

A correct ImpEx file will run successfully each time. If a server goes down during the ImpEx process, the job can be restarted, or a new import (or export) can be kicked off manually on a different server.

Stability

Any errors in the ImpEx will be logged to the server logs and the cronjob. If using the ImpEx API, you can add any exception handling to react as per your requirements.

When executing manually, there is no way to abort the cronjob. Therefore, if the ImpEx cronjob is taking a long time to complete, the only way to stop it would be to stop the server.

Cloud Hot Folders

In "Get the Most out of Your Cloud Hot Folders and Azure Blob Storage" we cover how Cloud Hot Folders can be used to get data in and out of SAP Commerce Cloud.

Extensibility

You need to define your channels and mapping for the inbound files and how you would like to process them.  

Scalability

Any data loaded into the Cloud Hot folders counts towards the overall data storage limit defined in the cloud services description. If you run out of storage there is an option to purchase more.

Audit and Control

There are a variety of monitoring options available for processing of files via Cloud Hot Folders

Testability

Testing is typically done by loading new files into Cloud Hot folders and seeing if it was processed correctly to the archive folder. If it ends up in the error directory and the mapping was set up successfully, you should see an error in the logs.

Ease of Deployment

Cloud Hot Folders are provisioned as part of a Commerce Cloud environment, but if you need to set up new channels and mappings, it requires development effort and a build/deploy cycle.

Reliability & Stability

Cloud Hot folders are built upon Azure Blob storage and are quite stable. As per the configuration recommendation, processing should be tied to your backgroundprocessing aspect. In production environments there are at least 2 backgroundprocessing nodes for resiliency.

Classic In-app Customization

Having exhausted all the options above, you may find that you need to create a custom extension or extend some existing code that is part of your SAP Commerce solution. You can add or extend logic by adding or replacing Java components in the underlying Spring Framework. Your code is then compiled and packaged in the same artifact as the rest of your SAP Commerce Cloud instance. We have well-documented extension points that we recommend to stick to, but if necessary, albeit not always recommended, you can extend or replace any component, from the API all the way down to the inner workings of the persistence engine.

All changes require a build and a deploy, but most changes don't require downtime.

Although there is nothing inherently wrong with customizations, we often see projects that don't take into account the full cost of a customization. This is why we recommend all the options above to be considered first. They provide simpler forms of integration and extensibility, and they align with the vision for SAP Commerce Cloud. An in-app customization not only requires the time for the developer to code, but also incurs ongoing costs such as:

• Bug fixes and support
• Testing (including performance and regression tests with each release)
• Additional infrastructure (if required)
• Impact on upgrades, if not extended in line with recommended practices

When the only option is for an in-app customization, it may be worth it to re-evaluate the business requirements driving the need for a customization to determine if they can be altered in such a way that any of the other options above can be used.

How to Choose?

With so many integration options, it can be tough to choose which option to move forward with. The first step is to quickly eliminate those options that will not work for you. The flow chart below can help you to understand which options to pursue. You should also be consulting the Roadmap to understand if (or when) a pre-built integration that you require, might be available. If you're looking to integrate another SAP product with SAP Commerce Cloud, you should also consult the Architecture of SAP Integrations page.

Conclusion

When it comes to integrating with SAP Commerce Cloud, there are many options, each with its own pros and cons. With each integration, it is best to go through your requirements and establish, using the guidance above, which integration option might work best to achieve your integration.