Blog 2: Request-Reply Pattern in Integration Flows (SAP Cloud Platform Integration)
Hello Integration Community !
In this blog, I shall explain the request-reply pattern of SAP Cloud Platform Integration (f.k.a.HCI) and how you can use it in your integration project.
What is Request-Reply?
In this pattern, a sending system sends a message to an external system or service and then waits for a reply. For example, SOAP messages come in Request-Reply pairs. A SOAP request message indicates a service the sender wishes to invoke on the receiver, whereas a SOAP response message contains the result of the service invocation. The response message either contains a result value or a fault–the SOAP equivalent of an exception.
In SAP Cloud Platform Integration, the request-reply flow step sends the request message, waits for the reply message, then processes the reply. This pattern is one of the common patterns used in integration projects.
How can you enable Request-Reply in SAP Cloud Platform Integration?
Request-Reply pattern is categorized as a Service Call. You can choose Service Call from the palette and select the Request-reply pattern (By default, the request reply pattern is chosen).
You can use the request-reply pattern in two ways:
1. In the integration pipeline, you send a request message to a 3rd party system.
See the example below. An ERP system is communicating with an HR system. However, we need the data from a SuccessFactors (SFSF) system. In the content modifier step, the request message that is to be sent to the SFSF system is formulated. The response is fed to a mapping step and then sent to an ODATA endpoint in the HR system.
2. You want to send the response back to the requesting sender
This is a frequently-used scenario. In the example below, the reply from the HR system is modified and sent back to the ERP system.
Note:
- I have not configured the channel for the system because it is already configured in the request direction.
- An “End Message” flow-step should be configured to represent the message termination in the process.
Characteristics of the Request-Reply Pattern
- Request call has must be to an external system
- The Quality-of-Service depends on the channel configured (for example, how many times the request attempt should be made)
- Headers and body of the message are available in the Reply side. You can modify any of them.
- Default replies or responses (for example, SOAP responses or SOAP faults) from the receiver are always sent back to the sender. You do not have to configure an explicit request-reply for sending the default responses.
Hi Sujit,
For second Scenario , if there is an operation mapping having request and response mapping, I think operation mapping can serve the purpose instead of request reply right ?
In other words can we use Operation mapping instead of request reply pattern for synchronous call ?
Regards
Rajesh
Hi Rajesh,
We do not natively support Operation Mapping in HCI. By natively, I mean - you cannot create a new Operation Mapping in HCI. An already existing operation mapping in PI can be imported and run in HCI.
But, you got it right when comparing with PI. This feature is an equivalent to the Operation mapping of HCI.
Best Regards,
Sujit
Hi Sujit,
Is MTOM supported in the HCI SOAP Adapter? If so, is there documentation on the settings for enabling this or an example using this?
Regards,
Vipin
Hi Sujit,
Is it possible for you to take a look into my scenario? Async-Sync Bridge (Request-Reply) in HCI
Appreciate any feedback.
Thanks,
Mark
I know this is quite an old blog but trying anyhow: Do I get this right that in case I have a simple synchronous soap (request --> response / fault) call which I want to handle via SCPI, I then do not have to configure request-reply at all?
Will I then be able to map the response or would I then need a requst-reply step?
Many thanks and kind regards
Jens
Hi Jens,
Did you get an answer for this question somewhere?
Thanks,
V.
Hi,
I am having a request-reply that receives a soap fault which is always handled as an exception. However, I would like to have the iFlow to proceed as it would not be an exception. Reason is that upfront I do have set of records (coming from an SFTP) that is split into single messages so I have one soap call per record and then I need to gather all results and send it by mail in case there is an error. Any idea how that can be solved? I am a bit lost.
Cheers,
Daniel