REST Adapter Sender Channel – Customer Error Handling with Response Payload

There are many blogs out there (here for example)  which explain how to use custom error handling but they seem to concentrate on the receiver side. This blog is an example of how to send back the payload as defined in the response mapping along with a non-200 HTTP Status Code

NOTE: SAP Knowledge Base 2259871 implies there should be a “Use Message Payload” option on the sender adapter but in our environment PI 7.5 SP 11 we don’t have this so this blog explains how to still get the response payload sent to the consumer….

Scenario:REST to SOAP (Mock Service)

ESR Objects

Consumer (Sender)

Service Interface:

Request Message Type

NOTE:- As this is a RESTful GET call the element ‘dummy’ is not used

Response Message Type

Target (Receiver)

Service Interface

Request Message Type

Response Message Type

Operation Mapping

Request

Response

Fault

NOTE:- This has been done but we are not interested in fault handling in this blog!

Message Mapping

Request

NOTE:- We use a UDF to retrieve the REST ASMA ‘id’ and set the Id field to this value. The ASMA will be set in the REST sender adapter (under REST Resources tab)

UDF

Response

The response mapping will check the incoming ‘Success_Flag’ from the target (mock service) system and if it does not equal ‘Y’ then we create the Error structure

The ‘Error_Code’ and ‘Error_Desc’ fields are then set to some more helpful values. In a real world scenario we may have more complex logic based on what the target system returns.

Integration Builder

Adapters

REST Sender

The sender adapter is defined as synchronous (‘Best Effort’) and handles the request/response as JSON.

NOTE:- This is where we ASMA ‘id’ is set to the Id passed in the URL request and is then used in the request mapping in ESR.

NOTE:- The message type is based on the GET operation but in future we could set different message types based on the operation (POST, PUT etc)

NOTE:- They key definition for the sender is that we check for the value of ‘N’ in the field ‘Success_Flag’ and then use the placeholder {message_result} which is the payload of the response message AFTER the message mapping.

SOAP Receiver

The SOAP receiver is directed to a SOAPUI mock service running on my laptop.

ICO

The ICO uses the adapters and the ESR OM to bring it all together!

Running the Scenario

Mock Service

SOAPUI is configured with the mock service for the target (receiver) by importing the WSDL for the SI_Mock_Service from ESR.

NOTE: The port and path match the values used in the SOAP Receiver in PI

I have created two mock responses which will be called sequentially (one after the other)

The ‘Success’ mock response sets the ‘Success_Flag’ to ‘Y’ and sets the name field (hard coded for simplicity!) and Id field uses a script to pass back the Id from the request message.

The ‘failure’ mock response sets the ‘Success_Flag’ to ‘N’ and sets the name field (hard coded for simplicity!) and Id field uses a script to pass back the Id from the request message.

Calling the PI REST Service

The first call is to the PI endpoint with a customer Id of 876333 – the screenshot shows the mock service was called and we have returned the customer name. the second screenshot shows the HTP Status Code is 200 as expected!

The next call (customer Id ‘3333’)will trigger the ‘failure’ mock response as the mock service just responds with the next mock response in sequence (we have two defined; the Success and Failure). The second screenhot show the HTP Status Code is set to 404 as we defined this in the error handling in the REST sender adapter!

FEATURE ALERT FEATURE ALERT!

In testing I have noticed that there is some caching in PI when we call the endpoint using the same customer Id in rapid succession. I’m not 100% if this is related to the SOAPUI mock service or with PI itself.

In my test scenario where I have TWO mock responses defined, if I trigger the request for the same customer twice in a row then the cals work