Integration Options for SAP Commerce Cloud
33 min read
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
- Core Principles
- Extensibility Patterns
- Integration Options
- Classic In-app Customization
- How to Choose?
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.
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 in SAP Commerce Cloud can be broken into two main patterns: Side-by-Side and In-App.
A word about classic extensions
For the reasons described above, our strategy encourages Commerce Cloud customization using cloud native features like RESTful APIs and subscribable events. The 2011 release of SAP Commerce delivers new features (e.g. Webhooks) and a maturity of existing features (eg. Integration APIs) that can be used for many use cases. However, we recognize that some use cases still require the classic extension mechanism. We will continue to support the classic extension mechanism in Commerce Cloud, even as we focus on delivering more cloud native features. This provides you with the flexibility to extend Commerce Cloud using the strategy that best suits your use case and preferences.
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 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.
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||Pre-built Integrations||Integration APIs||BTP Integration Suite||OCC||BTP Kyma Runtime||Webhook||ImpEx||Cloud Hot Folder|
|3rd Party Systems|
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.
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 or view the following video:
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:
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.
- If using the Backoffice, view the EDMX schema, example json payload, and the visual composition of the IO in the Meta modal window.
- Create an Inbound Channel Configuration in order to specify the authentication of your API. The available options are Basic or OAuth2 security.
- Assign the correct access rights for authorization purposes.
- Test your Integration Object returns the right data by calling the corresponding Integration API.
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
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).
If you're just looking at testing and monitoring the inbound-outbound services, you can look at some examples here.
Ease of Deployment
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.
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
- 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.
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.
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.
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.
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.
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)
Here we reference Kyma Runtime, but SAP Commerce Cloud has provided an open best-in-class ecosystem that’s seamless to consume on any technology stack. You can choose to use the Kyma runtime or any other microservices or third party functions.
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:
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.
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.
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
- 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
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.
Defining a new event requires an event class, which requires defining a Java class. This will require a build and deploy for the event to become available.
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).
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.
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 . 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.
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.
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.
- Back in stock text message notification.
- Adding loyalty points information to customer account when order is
- Keep a 3rd party wishlist up to date.
- Notify account manager when a B2B order is rejected for a particular reason.
- Not useful for massive data transfer & replication.
- Low throughput, low latency, not reliable delivery.
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:
- Configure an integration object defining the fields you wish to import/export
- Define the consumed destination for where the data will be coming from/going to
- Configure the outbound channel through which the changes are sent
- 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
- Configuring a cron job that runs periodically and collects the changes since previous runtime and sends them out to an external system.
- 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
- High throughput, high latency, reliable delivery.
SAP Commerce, data hub
Data hub is no longer the strategic direction for data integration in SAP Commerce Cloud and is not receiving any new features. SAP BTP Integration Suite covered above is the strategic data integration solution for SAP Commerce Cloud. Data hub is covered here because there are still some solutions that are leveraging it.
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.
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).
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.
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.
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.
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.
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 ImpEx User Guide) and Backoffice Wizard (see
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 process (see SAP Data Hub example above) or as part of data
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.
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.
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.
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.
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.
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
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.
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.