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
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
- SAP Managed Tags:
3 Comments
