This HowTo blog explains an API-driven integration pattern: We want to create or update an object through an API which DOES NOT provide an UPSERT functionality… First a HTTP GET is performed (read the object) and if a HTTP 404 is returned (not found), we create the object through a HTTP POST, otherwise (HTTP 200 is returned and the object can be read) we update the object through another API call (e.g. HTTP PUT).
Test Scenario:
To simplify the scenario we focus only on the HTTP GET and write the message into the MPL after the call:
Problem:
We have to call a READ API (via HTTP GET) which returns an error (HTTP 404 – not found) and the integration flow fails:
Exception Handling:
So we have to catch the exception, but the processing stops, even when we catch the exception in a local integration processing:
Even worse, all looks good, but the processing simply stops with the Message End event in the “Catch 404” Exception Subprocess. As you can see, there is no attachment written from the Groovy Script. It is designed like this – there is no way to return processing into the main iFlow. Whats even worse: you cannot use the Router in the Exception Subprocess (to handle the HTTP Status differently):
Solution Alternative 1:
To continue the processing after a HTTP 404 (or any other error), we can use the approach below. The HTTP GET is outsourced into a separate integration flow (here in the same iFlow) and called via ProcessDirect adapter. The exception is caught in there and then the processing continues in the “Call PD” Local Integration Process.
The disadvantage of this approach (apart from the increased design complexity) is the fact that you have 2 messages in the monitor (even if they share the same correlation id):
Solution Alternative 2:
The better approach is to continue the processing from the Exception Subprocess where a Local Integration Process is called. Like this, the main Integration Process is not reached, but the goal can be still executed:
The result is a successful call where the MPL attachment is written from the CREATE Local Integration Process:
Solution Alternative 3:
There is even a smarted approach which I learned today (thanks Peter). Since HTTP Receiver Adapter Version 1.10 we can uncheck the following flag in the configuration:
The iFlow looks like in the very inital approach now.
Of course the response can be evaluated in the main process with a router like for all the other solutions.
Summary:
Solution 3 is the easiest approach for sure and this option has been introduced recently by SAP (with adapter version 1.10). In case you might be using another adapter which does not have this flag, you can still go for the other approaches!
