Technical Articles
PI REST Adapter – Same endpoint for multiple Integration Flows
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.
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.
Open the second Integration Flow, and proceed accordingly. Here, enter 221 as expression.
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.
Call the same service another time, this time with Agency equals 221.
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.
Let’s call the service again, this time we enter an agency that has not been maintained in the configuration, here XXX.
This results in an http 404 service not found.
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.
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?
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
Hi Alex,
I have the same question as Holger.
Is there a way to select the REST channels based on HTTP header?
Regards,
Prasanna