[CPI] HTTP "Don't Throw Exception on Failure" doesn't work properly on XI Sender Synch

[miguel_motta]

Hi experts,

I have a synch XI Sender scenario, where the ERP sends a message to the CI, which makes an HTTPS request (with the option "Don't Throw Exception on Failure" enabled), and receives an HTTP Code 400 with a payload informing the reason for the error. I need delivery this message to ERP.
Analyzing the flow in the CI monitors, I don't see any errors, everything occurs as it should. However, when delivering the return message in the XI channel, an exception is generated on ERP, on proxy call.
This happens for example for HTTP Codes 400 and 404, but works perfectly for HTTP Code 500.
The payload received on 400 and 404, is shown on SXI_MONITOR as HTMLError, and no as MainDocument, as expected.

I think this is not happening as expected.
Has anyone noticed this behavior? Any known solutions?

Thanks,
Miguel Motta

[miguel_motta · Accepted solution]

Hi all,

To whom it may concern...

After several tests, I managed to solve the problem with a tip from a colleague.

After the HTTP call that returns the code 400, I created a content modifier eliminating header CamelHttpResponseCode.

Thanks to all!

Regards,
Miguel Motta

[Ndubuisi_PALMER]

Dear Miguel

Yes, this is a known behavior in SAP Cloud Integration (CPI) when dealing with synchronous XI proxy scenarios and non-200 HTTP responses.

In synchronous scenarios, SAP expects a well-formed XML response in the MainDocument. When the target system returns an HTTP 400 or 404 response, even though you have set “Don’t Throw Exception on Failure,” the CPI runtime still considers these responses as technical failures unless the body is explicitly treated and mapped.

The reason HTTP 500 appears to work better is because in many cases, the target system might still return an XML-formatted error message, whereas 400/404 responses often come with HTML payloads. Since these HTML responses are not valid XML, the XI runtime in ERP cannot parse them, and this results in an exception at the proxy layer.

Possible Solutions:

1. Convert HTML Error Payload to XML: Before sending the response back to ERP, use a content modifier or a script to wrap the HTML error payload inside a proper XML structure. This way, ERP receives a valid MainDocument.

2. Check and Force MainDocument in CPI: Ensure that you use a Groovy script or XML modifier to create a valid MainDocument explicitly, even in the case of 400/404.

3. Use Exception Subprocess: In your IFlow, handle non-2xx responses using an exception subprocess. Extract the payload and code, wrap it in XML, and set it as the message body for the response.

4. Content-Type Transformation: Set the Content-Type header to text/xml in the response to make sure ERP interprets the message correctly.

5. Backend Proxy Enhancement: If feasible, adjust the ABAP proxy logic to handle “HTMLError” payload types and parse them accordingly (less preferred).

Best regards

[miguel_motta]

Hi Palmer,

Thank you for your attention.

Note that in my example, I performed a controlled test, where the two messages are exactly the same, alternating only the HTTP Code between 400 and 500.
In CPI I receive the response, and just convert it to XML, in the same way in both scenarios.

For HTTP 500, I receive the payload on the ERP proxy without any problems. However, for 400, I receive the error.
It seems to me that the XI adapter performs different treatments depending on the HTTP Code.
I have tried to manipulate the headers, changing the HTTP Code, but the behavior is the same.
The only way I have found at the moment to successfully deliver the message to the proxy was to make a dummy HTTP request after the original, to obtain an HTTP Code 200, and then recover the original payload and deliver it to the ERP. I wouldn't want to have to do that.

Regards,
Miguel Motta