CPI - Cloud Platform - connect External System API to SAP using ODATA Adapter
Venkateswaran Krishnamurthy
SAP Technical Consultant | ABAP | CPI | Database | Techno-Functional
Introduction
In today's interconnected business landscape, seamless integration between external systems and SAP is crucial for efficient data exchange and process automation. Cloud Platform Integration (CPI) emerges as a powerful tool to bridge this gap, enabling businesses to connect to diverse external APIs and integrate them with SAP systems. In this article, we will delve into the key aspects of using CPI to build robust connectivity between external system APIs to SAP, exploring its benefits, functionalities, and best practices.
External System In our case study, the external system is a non-sap system that provides data such as a) Sales details b) invoicing details, c) Payroll data etc.
CPI - Cloud Platform Integration Cloud Platform Integration (CPI) is a cloud-based integration platform that enables your businesses to connect your applications and data sources, regardless of where they are hosted. Meaning Cloud to Cloud, Cloud to on-premises , On Premises to Cloud etc. CPI provides a variety of pre-built connectors and adapters, making the job easy to integrate a wide range of systems, including on-premise, cloud-based, and hybrid environments.
Target System Target system in our case study is a SAP system that accepts data from external in the form of API - (Json / xml) format and process it and Post documents into SAP system.
iFlow in CPI
An iFlow in SAP Cloud Platform Integration (CPI) is a graphical representation of a business process that integrates various systems and applications. It serves as a visual blueprint, defining the flow of data and logic between different components.
Key components of an iFlow:
Our Case Study
In our case study, we are going to develop an integration flow in CPI, that connects an system (non-sap) through an API and gets data in Json format, transforms the data into the receiving system format then connects to the target system SAP and push the data via ODATA Adapter. The following picture illustrates the activities between the start and end events of the iFlow integration process.
Sender
In CPI (Cloud Platform Integration), a sender is an entity that initiates the data flow within an iFlow. It's the starting point of the integration process. The sender is connected to a data source, which can be a variety of systems or services, such as:
A. End Point URL of the iflow
The endpoint URL of an iFlow in CPI (Cloud Platform Integration) is the unique address that can be used to access and interact with the iFlow's functionality. It's essentially the gateway to the iFlow, providing a way for external systems or applications to send data to the iFlow
Example in our case it will be like as below:
https://<your cpi subscription id>/<your iflow id>
Once the sender system sends message payload and hit the above url, the respective iflow - integration process will start.
B. Consume API (External)
This is the first activity in the integration flow, that connects to your external system and fetch the data using the API configured in it. This is configured in the CPI using a pallet called Request Reply in the iflow. It is a pattern used to implement synchronous communication between two systems. In this pattern, one system (the sender or client) sends a request to another system (the receiver or server), and the receiver processes the request and sends a reply back to the sender.
Using the HTTP Adapter settings, we connect to the external system as show in the picture below
C. Json to XML Converter
In CPI (Cloud Platform Integration), a JSON to XML converter is a transformation module that is used to convert data from JSON (JavaScript Object Notation) format to XML (Extensible Markup Language) format. This is often necessary when integrating systems that use different data formats, as JSON and XML are two of the most common formats used for data exchange.
In our case, the connection result that we used in section B, will return data in json format. That will be stored in B1. But further process we need data in XML format, so we need to convert the data to xml hence we used this Converter.
(This is optional and it is depending on your requirement)
D. Split the Payload into individual messages.
A splitter in CPI (Cloud Platform Integration) is a transformation module that divides an incoming message into multiple outgoing messages based on specific criteria. It's often used to distribute data to multiple targets or to process different parts of a message separately.
In our example, the incoming messages contains multiple messages inside it and we need to process it individually. Hence we used the splitter.
Splitter will splits the incoming message based on a Xpath - reference in the incoming payload
领英推荐
E. Message Mapping
Message mapping in CPI (Cloud Platform Integration) is the process of defining the relationship between the structure and content of an incoming message and the structure and content of an outgoing message. It's a crucial step in integration processes where data needs to be transformed or adapted to meet the requirements of different systems or applications.
For doing this you need to have the Schema Definitions of the source and Target. As shown below
The Source Schema
<?xml version="1.0" encoding="utf-8"?>
<!-- Created with Liquid Technologies Online Tools 1.0 (https://www.liquid-technologies.com) -->
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="https://www.w3.org/2001/XMLSchema">
<xs:element name="root">
<xs:complexType>
<xs:sequence>
<xs:element name="zvenues">
<xs:complexType>
<xs:sequence>
<xs:element name="Id" type="xs:unsignedShort" />
<xs:element name="Lat" type="xs:decimal" />
<xs:element name="Lon" type="xs:decimal" />
<xs:element name="Category" type="xs:string" />
<xs:element name="Name" type="xs:string" />
<xs:element name="Created_on" type="xs:unsignedInt" />
<xs:element name="Geo" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
The Target Schema
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="https://www.w3.org/2001/XMLSchema">
<xs:element name="ZVENUESSet">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="unbounded" name="ZVENUES">
<xs:complexType>
<xs:sequence>
<xs:element nillable="false" maxOccurs="1" name="Id">
<xs:simpleType>
<xs:restriction base="xs:string" xmlns="">
<xs:maxLength value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element nillable="false" maxOccurs="1" name="Lat">
<xs:simpleType>
<xs:restriction base="xs:string" xmlns="">
<xs:maxLength value="50"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element nillable="false" maxOccurs="1" name="Lon">
<xs:simpleType>
<xs:restriction base="xs:string" xmlns="">
<xs:maxLength value="50"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element nillable="false" maxOccurs="1" name="Category">
<xs:simpleType>
<xs:restriction base="xs:string" xmlns="">
<xs:maxLength value="50"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element nillable="false" maxOccurs="1" name="Name">
<xs:simpleType>
<xs:restriction base="xs:string" xmlns="">
<xs:maxLength value="50"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element nillable="false" maxOccurs="1" name="CreatedOn">
<xs:simpleType>
<xs:restriction base="xs:string" xmlns="">
<xs:maxLength value="20"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element nillable="false" maxOccurs="1" name="Geo">
<xs:simpleType>
<xs:restriction base="xs:string" xmlns="">
<xs:maxLength value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
F. Call the ODATA Service
This is the final step, where we push the data received from the above message mapping step into ODATA service. The service will save the data inside the SAP z-table.
Pre-requisite for ODATA configuration
Refer to the picture
Now in the ODATA configuration is set up in the ODATA Adapter connection in Section F - F1.
The ODATA configuration are as below: Part 1
The ODATA configuration are as below: Part 2
G. Mail adapter
The Mail Adapter in CPI (Cloud Platform Integration) is a module that allows you to integrate with email systems. It provides functionalities for sending, receiving, and processing emails within your integration flows.
Pre-requisite for Mail adapter
The Final notification to the Agents will be sent out once the message data is arrived in the target system.
In the processing tab, you can setup the Receiver Email address and Body text.
Conclusion
By effectively connecting disparate systems and data sources, businesses can unlock new opportunities for growth, streamline operations, and improve customer experiences.
Please comment your reviews and update me if I can improvise.
Please do connect to me at my Youtube Channel where I am sharing more knowledge.
Learn With Me :-)
Please do subscribe and support. Learn With Me - My Knowledge Share Channel