Skip to Content

PI REST Adapter – Blog Overview

Do you look for a way of integrating your SAP PI landscape with other REST services or to publish a REST service yourself using an SAP PI Endpoint?

If yes, then this blog could be of interest for you.

Do you have already had a look at the SAP PI REST Adapter and its configuration and now you feel “a bit overwhelmed” by the amount of settings?

If yes, then this blog is also the right one for you.

We have prepared a collection of blog entries for the REST Adapter that shows architectural concepts and configuration of the SAP PI REST Adapter and explain the internal processing steps. 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.

Let’s get started.

The first Blog in this series is about the REST Adapter concept and its configuration capabilities. It is a good ramp-up start for working with the REST adapter. It is called

PI Rest Adapter – Don’t be afraid

The next blog in the series deals with a simple scenario that shows how to consume a synchronous RESTful service. In the example, the target URL is set dynamically by using variables.

REST Adapter – Consuming synchronous RESTful service

A useful scenario is the next one that shows how to call a SAP function module via PI’s RFC adapter, and expose the same as a RESTful service.

PI REST Adapter – Exposing a function module as RESTful service

If you like to know more about JSON conversion within the REST adapter, take a look here:

PI REST Adapter – JSON to XML conversion

In case of the provisioning of RESTful services using a REST sender adapter, you have full flexibility for defining the endpoint of the service. An example of a dynamic endpoint can be seen here:
PI REST Adapter – Defining a dynamic endpoint

Within the REST adapter we have shipped a set of pre-defined adapter specific atributes that can be used to control the message flow. Furthermore, you have the possibility to define own custom attributes. An example is shown here:

PI REST Adapter – Using dynamic attributes

A new concept in PI which is unique to the REST adapter is that you are able to expose one and the same endpoint for addressing multiple Integration Flows. Besides the dynamic endpoint definition explained above, this gives you one more option in the definition of endpoints and your routing rules.

PI REST Adapter – Same endpoint for multiple Integration Flows

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

In previous releases, we were limited to one Quality of Service per channel. So, in PI REST Adapter – Map CRUD operations to Service Interface Operations we stick to the POST, PUT, and DELETE operations which are all of asynchronous mode, and omitting the GET operation which is of synchronous mode.

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 expose all operations as a single end point. An enhancement of the scenario is described in PI REST Adapter – Map CRUD operations to Service Interface Operations with dynamic setting of Quality of Service

If you like to learn more about the various options that the REST adapter supports for handling error situations, check out the following blog.

PI REST Adapter – Custom error handling

Some RESTful services require specific http headers. The following blog shows you along a use case how you can add custom http header elements to the receiver REST adapter.

PI REST Adapter – Define custom http header elements

If you like to poll REST APIs, check out this example: PI REST Adapter – Polling a REST API.

Learn how to access Concur travel and expense management solutions via its REST API, particularly focusing on the OAuth authorization at PI REST Adapter – Connect to Concur.

Still not found what you were looking for?

No problem! Just let us know what kind of information is missing and how we can help.

87 Comments
You must be Logged on to comment or reply to a post.
  • Is there any plan to fix the REST sender communication channel “Error Handling” tab to support more than 10 expressions? For most of our services we need more than 10 expressions.

     

    In addiditon it should be possible to set the http status code refering an ASMA varaible.

     

    You also expected the REST receiver communication channel to put the http status code into ASMA.

     

    SAP implemented note 2793556 which is an improvement

    2793556 – REST Adapter: Support more than 10 result HTTP headers

    A pitty the the “Error Handling” tab wasn’t fixed at the same time.