1       Introduction

If you use SAP Commerce Cloud (CCv2), you can leverage the SAP S/4HANA Order Management integration capabilities to integrate directly with SAP S/4HANA Cloud Private Edition. This enables order management through API-based communication between SAP Commerce Cloud and SAP S/4HANA Cloud Private Edition.

This article describes the available integration options for connecting SAP Commerce Cloud to SAP S/4HANA Cloud Private Edition using the SAP Connectivity service and Cloud Connector. The following approaches are covered:

• Application Router on SAP Business Technology Platform (SAP BTP)
• SAP API Management on SAP Integration Suite

2       SAP Commerce Cloud

2.1      Backoffice Configuration

To configure the SAP Commerce Cloud Backoffice consumed destination for SAP S/4HANA Order Management, follow the steps in the integration implementation document. For more information, see SAP S/4HANA Order Management Integration Implementation

Note: Use the Application Router or SAP API Management hosting URL when you configure the Backoffice consumed destinations.

3       SAP Application Router

3.1      Introduction

The Application Router is a Node.js library used as a single point of entry to an enterprise application. The Application Router serves static content, authenticates users, rewrites URLs, and forwards requests to other microservices (acting as a proxy) while propagating user information.

For more information on Application Router and its implementation, see Application Router

3.2      Architecture

Process Flow
The following steps describe the process flow for connecting SAP Commerce Cloud to SAP S/4HANA Cloud Private Edition via the Application Router:

1. SAP Commerce Cloud Backoffice sends an HTTP request to the Cloud Foundry-hosted Application Router URL with a Bearer <token> in the Authorization header.
2. Custom middleware (first in the pipeline) copies it to x-approuter-authorization.
3. Application Router reads the token from x-approuter-authorization, validates it against SAP Authorization and Trust Management service (XSUAA), and matches the URL path against xs-app.json routes.
4. The SAP BTP resolves the named destination to the actual backend URL.
5. The SAP BTP Connectivity service tunnels the request through Cloud Connector to the SAP S/4HANA Cloud Private Edition.
6. SAP S/4HANA Cloud Private Edition responds with the OData payload (sales order data or attachment).
7. The Application Router forwards the response to SAP Commerce Cloud.    

3.3      Implementation

The Application Router runs as a Cloud Foundry application on SAP BTP. It is the central piece, handling authentication based on SAP Authorization and Trust Management service (XSUAA), destination resolution, and routing to the right SAP S/⁠4HANA Cloud Private Edition OData service.

Challenge: Limitation in the Backoffice Custom Header

SAP Application Router uses a special header called x-approuter-authorization to accept a pre-existing Bearer token and pass it through to the backend. This allows SAP Commerce Cloud to supply its own OAuth token for authorization of API calls.

The Backoffice in SAP Commerce Cloud does not support sending tokens in custom headers. It only uses the standard Authorization header.

Solution Proposal: A custom middleware that runs before the Application Router logic and transparently copies the Authorization header value into the x-approuter-authorization header.

 Solution Components

• Server/Application Entry Point
  // server.js

‘use strict';
const approuter = require(‘@sap/approuter');
const ar = approuter();
ar.start({
extensions: [
require(‘./middleware/tokenValidation')
]
});
​

The custom middleware is registered as an Application Router extension, the officially supported way to inject middleware into the Application Router lifecycle. When deployed on Cloud Foundry, the Cloud Foundry runtime calls npm start, which runs this file.

• mta.yaml file
  This sample .yaml file is generated when you create an Application Router project.

_schema-version: “3.2”
ID: approuter
version: 1.0.0

modules:
– name: approuter-approuter
type: approuter.nodejs
path: approuter-approuter
parameters:
memory: 256M
disk-quota: 256M
properties:
LOG_LEVEL: debug
XS_APP_LOG_LEVEL: debug
requires:
– name: approuter-xsuaa
– name: approuter-destination
– name: approuter-connectivity

resources:
– name: approuter-xsuaa
type: org.cloudfoundry.managed-service
parameters:
service: xsuaa
service-plan: application
service-name: approuter-xsuaa-service
path: ./xs-security.json

– name: approuter-destination
type: org.cloudfoundry.managed-service
parameters:
service: destination
service-plan: lite

– name: approuter-connectivity
type: org.cloudfoundry.managed-service
parameters:
service: connectivity
service-plan: lite
​

• Package.json file
  

  Add the file reference in package.json  scripts section so that it runs on npm start.
  
  

{
“name”: “approuter”,
“description”: “description for approuter”,
“engines”: {
“node”: “>=20”
},
“dependencies”: {
“@sap/approuter”: “14.4.2”
},
“devDependencies”: {
“@sap/html5-repo-mock”: “2.1.5”
},
“scripts”: {
“start”: “node server.js”,
“start-local”: “node node_modules/@sap/html5-repo-mock/index.js”
}
}

• The Custom Middleware
  

  // tokenValidation.js

  The tokenValidation.js file maps the Authorization header to the x-approuter-authorization header.

‘use strict';

async function tokenValidationMiddleware(req, res, next) {
if (req.headers[‘authorization'] && !req.headers[‘x-approuter-authorization']) {
req.headers[‘x-approuter-authorization'] = req.headers[‘authorization'];
}
next();
}

module.exports = { insertMiddleware: { first: [tokenValidationMiddleware] } };

Custom Middleware Requirements

SAP Application Router looks for x-approuter-authorization to pick up a caller-supplied Bearer token. If this header is absent, the Application Router initiates its own OAuth flow (redirecting to SAP Authorization and Trust Management service (XSUAA) login page or returning 401).

The Backoffice in SAP Commerce Cloud can only send the Bearer token in the standard Authorization header. It has no mechanism to set custom headers.

Custom Middleware

• Runs first, before any Application Router logic (insertMiddleware: { first: […] }).
• Checks if Authorization is present but x-approuter-authorization is not.
• Copies the value across, so the Application Router sees the token it expects.
• Calls next() to hand off to the normal Application Router pipeline.

No token is modified, no validation is done here — it's purely a header remapping step.

Prerequisites

Before you begin, ensure the following prerequisites are met:

•  SAP BTP subaccount with Cloud Foundry environment enabled.
•  Cloud Foundry CLI and MTA plug-in installed.
•  Cloud Connector installed and linked to the SAP BTP subaccount.
•  SAP S/4HANA Cloud Private Edition virtual host/port mapped in Cloud Connector.
•  SAP BTP Destinations created for each SAP S/4HANA Cloud Private Edition OData service (OnPremise proxy type).
• SAP Authorization and Trust Management service (XSUAA) service instance with appropriate scopes.
•  SAP Commerce Cloud outbound credentials configured to call the Cloud Foundry Application Router URL with a valid Bearer token.

4       SAP API Management (APIM)

4.1      Introduction

The integration between SAP Commerce Cloud (CCv2) and SAP S/4HANA Order Management requires real-time, secure API access without custom middleware. SAP API Management provides a standardized and, handling OAuth 2.0 authentication, request routing, and security policies centrally.

For more information on SAP APIM, see Classic API Management.

4.2      Architecture

Process flow

The following steps describe the end-to-end process flow for the SAP API Management integration:

1. SAP Commerce Cloud Backoffice sends an HTTP request to the SAP API Management Proxy URL with a Bearer <token> in the Authorization header.
2. SAP API Management receives the request and runs the configured policies.
3. SAP API Management resolves the target endpoint using the configured destination or target system and forwards the request.
4. Cloud Connector establishes a secure tunnel between SAP BTP and the on-premise network hosting SAP S/4HANA Cloud Private Edition.
5. SAP S/4HANA Cloud Private Edition processes the request and returns the required OData payload (for example, sales order data or attachments).

4.3   SAP API Management Components

The following table describes the key components of SAP API Management:

Component	Description
API Provider	Defines backend SAP S/4HANA Cloud Private Edition connectivity, authentication, and discovery.
API Proxy	Exposes backend APIs securely with policy enforcement.
API Product	Bundles APIs and defines access models such as OAuth or API Keys.
Application	Represents the consuming application (CCv2) and generates credentials.

API Management Lifecycle (Design → Publish → Consume)

The following diagram illustrates the API Management lifecycle, from design through to consumption:

4.4      Configuration of Cloud Connector

SAP Cloud Connector enables SAP BTP applications to establish secure, encrypted connections to on-premise systems and remote services without exposing them directly to the internet.

For more information on the SAP Cloud Connector configuration, see Configuration of SAP Cloud Connector

4.5     Implementation

Create API Provider

To create an API provider, perform the following steps:

1. In API Management, go to Configure and choose Create Provider. 
2. On the Connection tab, select the type based on your system, and enter the host and port details.
3. In the Catalog service settings, enter the following:
   • Path prefix
   • Service collection URL
   • Authentication type
   • Username
   • Password
4. To verify the connection, choose Test Connection.
5. Choose Save.

The API provider is created and available for use.

Create API Proxies

To create and activate an API proxy, perform the following steps:

1. In API Management, go to Configure and choose APIs. 
2. Choose Create and select the API Provider you previously configured.
3. Choose Discover to load all backend APIs available in that Provider. Select the API you want to expose.
4. Enter a name, title, and version for the new API proxy.
5. Open the proxy to review or edit the details.
   Note: The Proxy Endpoint is the URL that clients call. The Target Endpoint shows the backend (API Provider) connection details and base URL.
6. Choose Policies to add or edit policies such as security, transformation, and rate limits.
7. Choose Save and Deploy to activate the proxy.

The proxy is activated and appears under Configure → APIs.

Create API Product

To create an API product and make it available for subscription, perform the following steps:

1. In API Management, go to Engage and choose Products.
2. Choose Create to start a new product.
3. Enter a name, title, and optional description.
4. On the APIs tab, choose Add and select the API proxies you want to include.
5. Choose Publish to make the product available in the Developer Hub.

The API product is available for subscription in the Developer Hub.

Create Application

To create an application and subscribe to an API product, perform the following steps:

1. In SAP Integration Suite, open the Developer Hub.
2. Go to Applications and choose Create Application.
3. Enter a name, description, and optional metadata.
4. Go to the Subscriptions section and choose Add Subscription.
5. Select the API Product you want the application to consume.
6. Copy the generated credentials for use in your API calls. Use these credentials in tools like Bruno/Postman to call the API Proxy endpoint.
   Note: The credentials depend on the product's access model: an API key if the product requires API key authentication, or a client ID and client secret if it requires OAuth2.

Once subscribed, the application receives credentials based on the product’s access model.

5       Summary

5.1      SAP API Management and Application Router – Comparison

The following table compares SAP API Management and SAP Application Router across common integration scenarios.

 

Scenario	SAP API Management	Application Router
Internal M2M between trusted systems	Possible	Suitable
External API exposure to multiple consumers	Suitable	Possible with additional setup
SAP Authorization and Trust Management service (XSUAA) token already available at caller	Requires policy configuration	Suitable
Rate limiting / API analytics needed	Suitable	Requires additional tooling
Integration Suite already licensed	Suitable	Either works
No Integration Suite license	Requires procurement	Suitable
Cloud Foundry virtual host already provisioned	Suitable	Either works
Non-technical team managing changes	Possible via SAP Integration Suite UI	Possible via GitHub / BAS
Multiple backend services	One proxy per service	One Application Router, multiple routes
Create project from scratch	Higher setup effort upfront	Lower setup effort upfront
Version-controlled configuration	Requires custom setup	Built-in via GitHub
Enterprise API governance required	Suitable	Requires addition

 

5.2      Conclusion

Both SAP API Management and SAP Application Router are viable approaches for integrating SAP Commerce Cloud with SAP S/4HANA Cloud Private Edition, each with its own strengths. The right choice depends on your existing landscape, licensing, and governance requirements. Customers already invested in Integration Suite will find SAP API Management the more natural fit, while those prioritizing simplicity and version-controlled configuration may prefer the Application Router approach. Both options are supported. Select the approach that best fits your technical landscape and project requirements.

Source link