How to handle exceptions in Odata receiver adapter in SAP CPI

[pavankalyan_racha]

Hi All,
We have a requirement to make multiple calls to an SAP EAM OData API. We would get a request with a set of Ids from source system then we have to split those ids into batches and make call to SAP EAM OData API with each batch so here the issue is if the data doesn't exist for any one of the batch the OData  API is throwing exception and the entire flow is getting failed and not getting proceeded for the next batch.
Let us assume we get 10 Ids from source and we are splitting them into a batch of two ids each so we have to make 5 calls to the OData API. Here for the first two batches there are details in OData API and it returned the details for those Ids, for the third batch of Ids there are no details in OData Api so its throwing exception with 400 Bad request and the flow is not getting failed and not getting proceeded for the next 2 batches where the data exists in OData API for those set of Ids.

In HTTPS adapter we have an option to handle the failures as shown below

If we uncheck this we can route the exception messages to a different route and we can handle 

Can someone help me how to handle the above-mentioned exceptions in OData receiver Adapter

Thanks & Regards
Pavan Kalyan

[fl-ma]

Hi,

unfortunately, there seems to be no easy configuration for the OData adapter.

The obvious answer would be to use a HTTP receiver instead of OData.

If, for whatever reason, Odata is required for your use case, Irvinrufus described a possible solution in this blog post: https://community.sap.com/t5/technology-blogs-by-members/sap-cpi-exception-handling-tips-return-to-m...

In the example below, I implemented an iFlow that is similar to your requirement:

There are 2 OData calls:

• First call (Request Reply 1) determines if the iFlow is relevant to this use case.
  If not, the OData will return 404. This must not fail the message processing but is considered a "regular" termination of the process.
• Second call (getProductDetails) shall only be executed if the iFlow is relevant.
  Any error here (or later in the iFlow) should lead to the CPI message failing.

In an ideal world, you would use a Router to determine if an exception should lead to failure or not.

Unfortunately, Router is not supported within the exception flow. That’s why I used process call to handle further processing outside the exception sub process.

See below for the configuration of the router to achieve this behavior:

Hope this helps.