PI REST Adapter – Map CRUD operations to Service Interface Operations
This blog is part of a collection of blog entries that shows architectural concepts and configuration of the SAP PI REST Adapter. We also added some sample scenarios to make it easier for you to understand how your scenario can be implemented using the PI REST Adapter.
If you haven’t done so far, best is to start with the very first blog PI Rest Adapter – Don’t be afraid within the blog series covering the concepts of the REST adapter. A complete list of all blog entries can be accessed from here PI REST Adapter – Blog Overview.
How the CRUD operations can be mapped to the operations of a Service Interface in SAP PI is shown in the following example.
We would like to maintain customer data in an ERP backend system, and expose this interface as RESTful service whereas the http methods POST, GET, PUT, and DELETE are mapped to the corresponding create, read, update, and delete (CRUD) operations. For the create, update, and delete operations, the connection between SAP PI and the ERP system is done by posting an IDoc of type DEBMAS via IDoc adapter. The customer data should be provided in JSON format. Previously, we only supported one Quality of Service within one channel, so we haven’t taken into account the read operation here.
With 7.31 SP16 / 7.4 SP11, we have introduced a new feature that allows you to dynamically set the Quality of Service either by HTTP operation or interface operation. This way, we are able to handle all operations with one channel and one end point. This is shown in PI REST Adapter – Map CRUD operations to Service Interface Operations with dynamic setting of Quality of Service.
In the Enterprise Service Repository (ESR), we have defined an outbound Service Interface customer_OB with the corresponding CRUD operations.
For each operation, a different mapping needs to be carried out. In figure below for instance you can see the message mapping from source message type customer_create to target message type DEBMAS05. For creation of IDocs, the IDoc field MSGFN needs to be mapped to the value 5 (for update it is mapped to 9, for delete to 3).
In the SAP Process Integration Designer perspective of the NetWeaver Developer Studio (NWDS), I have defined an Integration Flow with operation-specific receiver determination, as seen below. The receiver is always the ERP system however we determine via the operations which mapping is carried out.
Let’s take a closer look at how the sender channel of adapter type REST needs to be maintained.
Configuring the REST sender channel
Double-click on the sender adapter to open the channel editor, and choose adapter type REST. The transport protocol HTTP and message protocol REST are automatically set.
Switch to the Adapter-Specific tab. On the sub-tab General, select the data format JSON from the drop down menu. In general, you have two options, either XML or JSON. Within PI we need the payload being in XML format, especially since we need to run mappings. So, select the Convert to XML check box. Note, do not add any wrapper element, i.e., root element, to the payload (see also blog “PI REST Adapter – JSON to XML conversion” where this was required). A root element with the name of the message type of the corresponding Service Interface operation is added to the XML payload based on the operation settings, see further below.
Switch to tab Channel Selection. Here, you can specify a custom end point. Select Specify Endpoint check box and enter the Endpoint field, here /demo/maintain/customer.
Switch to tab REST Operation. Here, you can define how the adapter specific attribute operation is set. Select HTTP Operation from the drop down menu. This will assign the http operations POST, PUT, and DELETE to the attribute.
Switch to tab Operation Determination. Here you map the http operations to the Service Interface operations. Note that you have to enter the message type name of each operation, and not the operation name.
Running the scenario
For testing the scenario you can use the Advanced REST Client Application in your Google Chrome browser. The endpoint URL of your RESTful service starts with http://<host>:<port>/RESTAdapter with host and port of the SAP PI system, followed by what you have defined in the channel, here /demo/maintain/customer.
From the PI message monitor, you can display the message payload on PI. As can be seen from figure below, the wrapper root element customer_create has been added to the converted XML.
I hope this blog was helpful to understand how to map the CRUD http operations of a RESTful service to the operations of a Service Interface in SAP PI. If you like to learn more, check out the other blogs in the series, accessible from the main blog PI REST Adapter – Blog Overview.