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.

How the CRUD operations can be mapped to the operations of a Service Interface in SAP PI is shown in the following example.

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. 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.

01 ESR Service IF Definition.png

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).

02 Msg Mapping.png

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.

03 Integration Flow.png

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.

04 REST adapter type.png

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.

05 General Settings.png

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.

06 endpoint.png

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.

07 REST Operation.png

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.

08 Operation Mapping.png

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.


09 Chrome browser POST.png


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.

10 XML for customer_create.png

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.

To report this post you need to login first.

5 Comments

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

  1. Trevor Naidoo

    Hi Ivo / Alexander,

    Thanks for the invaluable series on the Rest Adapter. Any chance of samples / blogs related to dual stack PI 7.4 SP9 upwards (since the availability of the rest adapter)? This blog series makes a terrible assumption that everyone is using single stack PO and Integration Flows :-), there are guys out there still running the dual stack.

    Tried exposing a sync bapi as a restful service on the dual stack. The error logging and tracing is a bit mystifying. Managed (only after turning up the traces to debug level) to discover that there was a ‘binding’ error on the Rest sender channel – this threw me off completely. Why do you need to bind this sender Rest channel on a dual stack when you do your operation mapping in the channel itself?   

    Regards, Trevor

    (0) 
    1. Alexander Bundschuh

      Hi Trevor,

      the scenarios should all run on PI dual stack as well, in the blogs I manly focus on configuring the REST adapter channels, the configuration of the channels in the Directory looks pretty much the same

      Alex

      (0) 
  2. Akshay Ruia

    Hi Ivo,

    Blogs are really good and helpful. But all the blogs are explained considering rest adapter as sender and Operation as get.

    Can you please put some light on how Rest Adapter as “receiver” and Operation as “POST” would work with one dynamic custom parameter as header and other in Body.

    Thanks & Regards,
    Akshay Ruia

    (0) 

Leave a Reply