Skip to Content

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.

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.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Ashutosh R

    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.

    regards

    ashutosh

    (0) 

Leave a Reply