Skip to Content

Consuming Synchronous RESTful Web Service with PI – I

As mobility and cloud become the most prominent drivers for the IT investments today, the need for compact, light-weight integration is immensely felt, leading to  emergence of alternatives to conventional SOAP-based web-services. RESTful web services is one such option that is poised to replace conventional web service calls in many areas. In this blog, I wish to describe our journey through a successful implementation of a RESTful web service scenario using SAP PI.  I am borrowing the example web service from a popular blog by Michal Krawczyk on static RESTful web service via sender SOAP adapter; however our problem definition is different – a synchronous web service call with dynamic request message.

Since we are using PI 7.11, we only had the below choices when greeted with a challenge to consume a RESTful web service using SAP PI –

1.       Develop custom adapter module to address the peculiarities of RESTful web service calls

2.       Purchase third party adapter  that provides  out-of-the-box REST capabilities

Both these options obviously have their own limitations. However, Axis framework (Refer to SAP Note 1039369 for details) turned out to be an economical, fast and yet elegant option to fulfil the requirement.  It helped us address the two major challenges in implementing dynamic RESTful web service calls.

1. Dynamic Request  message:

An important difference between RESTful web service and SOAP-based web-service is that the former does not depend upon request XML message to deliver the response. The RESTful web-server extracts the request parameters from the URL used to call the service.  Since the parameters are to be taken from user inputs to the source application, it follows that the URL is to be  constructed dynamically at runtime based on these parameters. As the request XML message does not matter at the web-server end, a dummy message type  with a single node is sufficient to be used as target message in request mapping.  This is just to complete the design in ESR. The target server does not care about the request message at all !

The request message mapping is important as it gives us the handle to run a UDF that would collect the parameters from source message and build them into a meaningful URL. Once the URL is prepared, it is set into the dynamic configuration during mapping.


Finally the module chain is augmented with additional calls to Axis Handler Beans. A working combination for setting the URL in a RESTful call is shown below.


The Axis documentation accompanying SAP Note 1039369 implies that any arbitrary values for the namespace and parameter name should serve the purpose. However it has been observed that the adapter disregards the dynamic URL unless the exact key pair ( TServerLocation) is used.

Make sure that you check the ‘Keep Header’ checkbox in the communication channel parameters. This will ensure that the dynamic configuration is still available in the message header by the time the adapter framework invokes the Dynamic Configuration Handler for Axis. The URL entered in the communication channel is just for namesake.


The steps taken so far ensured that the request message (in the form of a URL) is constructed dynamically.

The remaining story to be continued in the next blog. Till then, REST assured !!

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