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.

In the current blog, I would like to show you along a sample scenario how you can expose one and the same endpoint for different scenarios, i.e., Integration Flows.

Scenario

Referring to the flight scenario that we have introduced and enhanced in the previous blogs PI REST Adapter – JSON to XML conversion, PI REST Adapter – Defining a dynamic endpoint, and PI REST Adapter – Using dynamic attributes we will do a further enhancement. We would like to route the service requests to different Integration Flows depending on which travel agency does the call, however the endpoint URL should be the same. The right channel and Integration Flow should be determined based on the content of the request payload.

In the SAP Process Integration Designer perspective of the NetWeaver Developer Studio (NWDS), I have copied the existing Integration Flow, and changed the sender component of the copied Integration Flow to the second Agency.

04_01 Integration Flows.png

Configure the REST sender channel

We would like to determine the channel based on the agency. A sample payload from agency 110 looks as follows:

{

    “Agency”: “110”,

    “FlightDetails”: {

          “AirlineID”: “LH”,

          “ConnID”: “0400”,

          “Date”: “2014-09-13”

    },

}

Double-click on the sender channel of the first Integration Flow to open the channel editor, and switch to the Channel Selection tab below the Adapter-Specific tab. Select the Limit to JSON Element check box. As JSON Element enter Agency, and as Expression the value 110.

04_02 Agency 110.png

Open the second Integration Flow, and proceed accordingly. Here, enter 221 as expression.

04_03 Agency 221.png

Run the scenario

For testing the scenario you can use the Advanced REST Client Application in the Google Chrome browser. Enter the following URL: http://<host>:<port>/RESTAdapter/demo/flight/getdetail?mode=info

Enter a sample JSON payload like the one above with Agency equals 110, and select the Send button.

04_04 Browser Agency 110.png

Call the same service another time, this time with Agency equals 221.

04_05 Browser Agency 221.png

In the PI message monitoring, you get both messages displayed. From the entry in the sender component column, you can see that the requests have been routed to different Integration Flows.

04_06 Message Monitor.png

Let’s call the service again, this time we enter an agency that has not been maintained in the configuration, here XXX.

04_07 Browser Agency XXX.png

This results in an http 404 service not found.

04_08 Browser Agency XXX Response.png

I hope this blog was helpful to understand how to use the “limit to JSON element” capability of the SAP PI REST adapter. 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.

2 Comments

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

  1. Vijendra Singh Bhanot

    Great Concept. This is helpful in logically achieving URL pattern {*}.

    Question: I had to use different service Interface names per iflow. Is there a workaround to avoid creating different service Interfaces?

    (0) 
  2. Holger Neub

    Hi Alex,

    is there a way (available or planned) to use HTTP Header Fields for the channel selection? I am thinking more of an API Approach, where the consumer just provides his API key which then PI uses to determine the communication channel.

    I know about the possibilities  to do XPATH or JSON queries on the payload. However I want to avoid to place consumer/Sender Information in the payload, as this is not relevant to the actual REST ressource but rather to the Routing.

    Using the HTTP Headers for processing Information is the suggested Standard (e.g. in the x-api-key field).

    Looking forward to your answer.

    Regards
    Holger

    (0) 

Leave a Reply