Skip to Content
Technical Articles
Author's profile photo Alexander Bundschuh

PI REST Adapter – Map CRUD operations to Service Interface Operations with dynamic setting of Quality of Service

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.


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.

01 iflow.png

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.

02 General.png

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.

06 Operation Mapping.png

Option 2

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

02a General.png

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.

06a Operation Mapping.png

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.

04 REST Resources.png

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Ashutosh Rawat
      Ashutosh Rawat

      Hi ,

      we also have a same scenario, we have 2 different types of incoming messages  1 REST sender Endpoint channel, we want to use the Operation Determination tab, functionality to work for us. we are using the incoming XML messages content value as variable value.

      but inplace of Operation name( where we need to enter Message Type name)

      we are using XSDs, which do'nt have namespace it, will it work for to..?

      Operation Determination:-

      Variable |  expression | Operation | namesapce

      "{id}"   |  ordered |  PO xsd                 | blank

      "{id2}" |  pending |  POchange xsd  | blank

      here orderd and pending are field values that channel picks  in  XI attributes section.

      PO xsd name and  POchange xsd  are  2 xsd names.

      and since XSDs have no namespace, we kept balnk or *  etc.

      anyone could tell us , what we need to do ,  to make it work.

      created a  thread also for this.



      Author's profile photo KARUNAKAR ADAPA

      Hi Alexander,

      How to send a query to SFDC rest api using Rest adapter.


      Ex :- Below query is working fine in Soap UI but when i am using in Rest adapter Fatal error is receiving in Rest adapter. Please guide me to resolve this issue.

      Thanks in Advance for your help.
      Best Regards,