Presenting the SAP Commerce Cloud Integration API Module

Objective

After completing this lesson, you will be able to explain how the Integration API module facilitates data transfer between SAP Commerce Cloud and SAP S/4HANA Cloud.

SAP Commerce Cloud Integration API Module

In the earlier lesson, we briefly touched upon the fact that by using the SAP Commerce Cloud Integration API Module, you can send data to and from SAP Commerce Cloud. This lesson discusses how the data transfer takes place. It delves into the important features and functionalities of this module such as Integration Objects and OData services that support this data transfer process.

SAP Commerce Cloud Integration API module uses Integration Objects to define the types of data being sent or received, through the inbound and outbound data flows.

Integration Objects

The SAP Commerce Cloud Integration API module simplifies data integration with SAP Commerce Cloud using Integration Objects. These objects are used in the payload that is sent or received from SAP Commerce Cloud to define data types. A new Integration Object creates an integration. A new integration creates API service endpoints that accept one or more objects, and define the object’s payload. Each Integration Object is specific to its own use case, or purpose. For example, an SAP ERP order object might use all available fields, but an SAP Marketing order object might use only the fields related to marketing needs.

When you install the Integration API extensions in SAP Commerce Cloud, several services are available out-of-the-box, such as the Meta APIs. With these APIs, you can view the provided Integration Objects and the associated Integration Object items using the IntegrationService endpoint.

For example, the following request returns all of the Integration Objects in the Integration API module.​

Code Snippet
1
GET https://localhost:9002/odata2webservices/IntegrationService/IntegrationObjects​

And, to retrieve metadata of an Integration Object, add the $metadata query parameter to the request URL.

Code Snippet
1
GET https://localhost:9002/odata2webservices/IntegrationService/IntegrationObjects?$metadata

For more information, please read About Integration Objects.

To summarize the functions of SAP Commerce Cloud Integration API and Integration Objects:

SAP Commerce Cloud Integration API
  • Exposes a set of RESTful APIs used for data integration
  • Data is passed as Integration Objects
  • Uses and extends OData protocol
  • The APIs are leveraged by SAP Commerce Cloud
Integration Objects
  • Define structure of business-entity
  • Combine multiple item types into a logical unit of work
  • Can be defined at runtime
  • Building blocks for Integration APIs

Apart from the Integration Objects, the other features that the Integration API module supports include:

  • Enhancements to the OData protocol for use with Integration API services
  • SAP Commerce Cloud BackOffice tools for modeling Integration Objects
  • Monitoring of Integration API requests

Note

This lesson discusses only OData services, which helps to build RESTful APIs. Discussion on the remaining features of the Integration API module isn't part of this course.

OData Services

The Integration API uses and extends the OData protocol for building and using RESTful APIs. ​

An Integration Object describes the structure of a business-level entity and is the foundation for an EDMX schema and for the APIs used for Process Integration and Master Data Synchronization of SAP Commerce Cloud.

Creating an Integration Object extends the SAP Commerce Cloud type system and exposes anOData Service (OData API endpoint) that you can call to create, update or get data about that Integration Object.

Why use OData Services

Listed are the benefits of using OData Services:

  • Extensibility: OData services are highly extensible. You can create Integration Objects to represent your business data models and use OData services to perform CRUD operations.
  • Scalability: Typically the Integration APIs are highly performing, but the SAP Commerce Cloud aspect or service may need to be scaled. If you notice issues with your aspect or service resources being over consumed due to the OData service calls, please open a ticket with IT support.
  • Ease of Deployment: No deployment is required. Business users can model their own integration objects in BackOffice using the Integration UI Tool cockpit or perspective, Impex or Meta API.
  • Reliability and Scalability: As long as the SAP Commerce Cloud is running, the Integration APIs will be available. You can use the SAP Commerce Cloud BackOffice Integration UI tool to monitor and troubleshoot integration issues.

Note

Visit the following links for more information on OData services:
Working With OData ServicesThe image outlines the steps to prepare OData services for integration, presented in a sequential flowchart format with blue arrows. The steps are: Define the Model, View the Meta Model Window, Create an Inbound Channel Configuration, Assign the Correct Access Rights, and Test the Integration Objects. Each step is displayed in a blue arrow, showcasing a structured process for configuring and integrating OData services efficiently. This visual guide aids in understanding the key phases of OData service preparation for seamless integration.

There are steps necessary to prepare your OData Services for the integration:

  1. Define the Data Model
    • Define the data model that the other systems expect
    • Create an internal representation of the data model using the Backoffice Integration UI Tool or the Integration API Meta APIs
  2. View the Meta Model Window

    If you're using the BackOffice Integration UI Tool, view the EDMX schema (for example: JSON payload and the visual composition of the Integration Object) in the Meta Model window.

  3. Create an Inbound Channel Configuration
    • Create an inbound channel configuration to specify the authentication of your API
    • Assign the Correct Access Rights

      Assign the correct access rights for authorization purposes

    • Test the Integration Objects

      Testing your integration object returns the correct data by calling the corresponding Integration API endpoint

Recommendations when working with OData services

Follow these recommendations to work effectively with OData Services in your integration project:

  • To minimize the number of Integration Objects that you must maintain, determine if you can reuse existing Integration Objects. If your third-party systems can receive additional data, you may be able to reuse an existing Integration Object that contains required and optional fields.​
  • Leverage Meta APIs to keep Integration Objects consistent across local and cloud environments.​
  • Limit access of Integration UI Tool perspective in BackOffice to Administrators and owners of the integrations.​​
  • Integration APIs are not exposed automatically. ​
  • Ensure that API Authentication is configured first.
  • Configure access rights for each of your defined Integration Object.

Inbound and Outbound Communication

Communication has been mentioned many times in this course. ​Integrating inbound and outbound communications in the scope of the SAP Commerce Cloud and SAP S/4HANA Cloud integration requires knowledge of important practices. Inbound communication flow in the integration of SAP S/4HANA Cloud and SAP Commerce Cloud involves master data and transactional information being received by the S/4HANA Cloud system from SAP Commerce Cloud, such as customer orders and product data. Outbound communication flow involves SAP S/4HANA Cloud system sending information back to SAP Commerce Cloud, such as inventory updates and order confirmations.

Inbound Communication

You can generate OData services by creating Integration Objects. Each service is generated through the BackOffice Integration UI Tool perspective or via ImpEx at runtime. The Integration Object definitions offer a business-world view of the item types defined in the platform, which are better suited to real-world integration scenarios. ​

For example, there are many parts composing products, orders, and customers that the Integration Objects encapsulate into a cohesive unit of work.

Outbound Communication

You can dynamically define the payload of an Integration Object published to an external target. Developers leverage this ability to create skeletal business processes and interceptors (building blocks). ​

If you are less technical, you can dynamically modify the building blocks at runtime using the BackOffice Integration UI Tool.​

Watch this video to understand the inbound and outbound communication flows.

Log in to track your progress & complete quizzes