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.

The current blog describes how the full set of CRUD operations can be mapped to the operations of a Service Interface in SAP PI. It enhances the scenario in PI REST Adapter – Map CRUD operations to Service Interface Operations by adding the read operation. Previously, we were restricted to one Quality of Service (QoS) per channel, and hence it was not possible to mix asynchronous (create, update, delete) and synchronous (read) communication in one single Integration Flow. This however is now supported. Since release 7.31 SP16 / 7.4 SP11 it is possible to dynamically set the QoS by either HTTP operation or interface operation.

Scenario

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. For the read operation, a remote function module is called. For the setup of the asynchronous operations, refer to PI REST Adapter – Map CRUD operations to Service Interface Operations. For the setup of the synchronous scenario, refer to PI REST Adapter – Exposing a function module as RESTful service. Here, I focus on the enhancements in respect to the dynamic setting of the QoS. As you can see in the figure below, I have added a new operation read, and mapped to the function module.

Configuring the REST sender channel

Double-click on the sender adapter to open the channel editor, and switch to sub-tab General below tab Adapter-Specific. Two options are supported to define the QoS, either by HTTP operation or by interface operation. In our case we use a service interface with multiple operations, so both options work. If you have a service interface with one single operation or a stateless XI 3.0 compatible service interface, use the by HTTP operation option.

Option 1

From the Quality Of Service drop-down menu, select By HTTP Operation. For each operation, select the appropriate QoS. Here, for GET BestEffort, and for the rest ExactlyOnce. Since we have added a synchronous operation, we also need to specify the output message format, i.e., the format for the response. Here, the data format should be JSON.

Switch to the Operation Determination tab, and add the operation mapping for the read operation. Note that the last column can be left empty, see also option 2 below.

Option 2

Another option would be to choose the entry By Interface Operation from the Quality Of Service drop-down menu.

In this case, in the operation mapping table, we need to maintain the QoS. Here, EO for PUT, DELETE, and POST, and BE for GET.

For both options, we need to enhance the URL pattern by adding an ID part that holds the customer ID for the GET operation. Note, that for the other operations POST, PUT, and DELETE we do not have to specify an ID in the URL. So, select the check box Optional. This way you can call the endpoint either with or without ID.

I hope this blog was helpful to understand how to use the dynamic setting of the QoS in order 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.