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
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.
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.
If you like to know more about JSON conversion within the REST adapter, take a look here:
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:
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.
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.
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.
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.