Webservice <-> RFC Timeout

[markbernabe]

Hi experts, The scenario is Web Service (REST/POST) RFC. For large messages, it takes more than 60 seconds for SAP to process and send the response back. When this is tested in SOAPUI, I get SocketTimeException. Increasing the socket timeout in SOAPUI would resolve it. But the problem still happens for messages with larger volume of data that takes more than 2 minutes (sometimes 10 minutes) to complete. When it happens in SOAPUI, I usually get 'The proxy server received an invalid response from an upstream server' but when I check the actual message in SXI_MONITOR, it's still getting processed. After some time, it will actually complete. Has anyone encountered this issue before? Appreciate your inputs. Thanks!

[engswee · Accepted solution]

Hi Mark

You can check out the following SAP How To document to assist you in timeout related issues.

For your case, maybe setting the XI.Timeout parameter in the sender SOAP channel might help (as details in section 2.3.1.

Rgds

Eng Swee

[markbernabe · Accepted solution]

Hi Eng Swee, Thank you. I'm actually using REST adapter. After checking further, it seems that the 'The proxy server received an invalid response from an upstream server' error is similar with 'MessageExpiredException' which is caused by very long response from target system. I'll explore more on which timeout parameters in PI can be changed to avoid this error.

[Former Member · Accepted solution]

Hi Mark,

with synchronous messages it is important to consider timeouts from each connection to be established. So soapUI-PI, then PI-BackendSystem plus anything that might be in between. If your timeout soapUI-PI is smaller than the following ones, you'll get that phenomenon. soapUI will cut the connection, but PI will hold it and maybe receive an answer from the backend. This answer will end up in the void, since the original requester (your soapUI) has already disconnected. But for PI, this will be OK and status "successful". PI does not control and monitor the client's connection.

In other words, the cancel of the connection is only performed for that same connection, it is not propagated to any subsequent connections.

Hope that I was clear enough,

Jörg

[Former Member · Accepted solution]

Hi Mark

You need to change the parameter 'xiadapter.inbound.timeout.default'

Change it to the value that may taken for the target system to send back the response.

Detail information is there in the document  mentioned by Eng Swee Yeoh.

[markbernabe · Accepted solution]

Thanks Jörg for the explanation. This is really clear and makes a lot of sense. I figured this so I asked the consumer application to also increase their timeout. But since the Backend System->PI takes a really long time for big messages, their increased timeout is not enough. I may really have to increase 'xiadapter.inbound.timeout.default.

[markbernabe · Accepted solution]

Hi Indrajit, Thanks for the info. Is this parameter relevant to ICO as well?

[Former Member · Accepted solution]

Hi Mark

Yes it is relevant for ICO as well because ICO also executed in adapter engine.

[markbernabe · Accepted solution]

Thanks Indrajit.