HTTP timeout during synchronous processing through non-central AE

[Former Member]

Hi Gurus,

we're running a synchronous interface through a non-central adapter engine, and the receiver adapter is Primavera (based on JDBC), which shouldn't be relevant, but the point is: processing in the target will take up to 20 minutes, so the message in the integration server keeps timing out.

here's the error:

"Error while sending by HTTP (error code: 500, error text: Internal Server Error) (See attachment HTMLError for details)"

the attachment looks like this:

"500 Connection Timed out

Error: -5

Version 7010

Component: ICM

....

Detail: Connection to partner timed out after 600s"

This seems easy, right? I thought so too, so I went and set the parameter

icm/server_port_0 = PROT=HTTP,PORT=5$$00,TIMEOUT=3000,PROCTIMEOUT = 3000

now the timeout should be 3000 seconds instead of 600 seconds, but I still get the same error.

other timeout parameters I've set trying to fix this (all are still set now but the error persists) :

gw/reg_keepalive = 3000 (was 300)

rdisp/max_wprun_time = 1200 (was 600)

and in the non-central adapter engine, I set this parameter:

xiadapter.inbound.timeout.default (service XPI Adapter: XI) = 18000000 (was 180000)

when I view the communication channel monitoring, I see that the message successfully finishes processing in the non-central AE, but it takes about 17 minutes. By the time it's finished, the Integration Server has already cancelled the synchronous message due to this timeout.

I'll award points to whoever can uncover the missing timeout parameter for me.

Thanks,

Peter

[former_member4985]

Hi Peter,

Increase the values (TIMEOUT AND PROCTIMEOUT) as seen below example for the R/3 parameters (via SMICM):

icm/keep_alive_timeout

old value: <your_old_value>

new value: 900

You will also see the parameters where PROT=HTTP. Change the values here too similar to as seen below:

icm/server_port_0

old value: PROT=HTTP,PORT=<your_port>,HOST=<your_host>

,TIMEOUT=<your_old_value>, PROCTIMEOUT=<your_old_value>

new value: PROT=HTTP,PORT=<your_port>,HOST=<your_host>

,TIMEOUT=900,PROCTIMEOUT=900

.

.

.

icm/server_port_<n>

old value: PORT=<your_port_value>,PROT=HTTP

new value: PORT=<your_port_value>,PROT=HTTP,TIMEOUT=900

,PROCTIMEOUT=900

Also, change the icm/host_name_full to full qualified host name.

You could also take a look into these notes:

#824554 - ICM and SAP Web Dispatcher Timeout Parameter

Afterwards, restart the system for the new values to take effect.

Best regards,

Caio Cagnani

[Former Member]

Hello,

yes, I've already set the TIMEOUT and PROCTIMEOUT parameters for my HTTP service in rz10 and restarted the machine. Just to be safe, I included the HOST and icm/host_name_full as you recommend, but this doesn't change the situation at all.

Is it possible that 600 seconds is a hard-coded maximum for sync messaging? Has anyone ever successfully done a sync call longer than 10 minutes in XI?

This thread is still unsolved...

[Former Member]

Hi Peter,

I think you have to use the 8000 port over there instead of 50000, for the ICM time out.

icm/server_port_0 = PROT=HTTP,PORT=80<xx>,PROCTIMEOUT=3600

Regards,

Francis

[Former Member]

Hi Francis,

this is a 7.11 system, so the ICM is actually listening on the 50000 port (not the java dispatcher like in 7.0 systems). In the transaction SMICM -> GoTo -> Services I see that the HTTP port is 50000.

Thanks for the thought though.

any more?

[Former Member]

Hi Peter,

I think you would have already seen this document.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c059d583-a551-2c10-e095-eb5d95e03...

Is the parameter ServletInputStreamTimeout in secion 2.2.3 is checked?

Also there is a parameter called ServerReadRequestBodyChunkTimeoutMillis

in the HTTP provider service of Java dispatcher. The default value of this parameter is 600,000(10minutes)

Regards,

Francis

[Former Member]

Thank you all for your helpful responses, I have now found the solution (my own statement about the Java dispatcher not existing in PI 7.1 is what caused me to realize it):

The ICM parameter I set above was set with RZ10 in the INTEGRATION SERVER, but I did not try to set it in the non-central ADAPTER ENGINE. Because the ICM controls HTTP communication in the non-central AE for 7.1 systems, the same parameter applies (icm/server_port_0=...)

It is difficult to check the value of this parameter on a stand-alone engine like the non-central AE, but this is how I did it:

I opened the SAP Microsoft Management Console (sapmmc) instead of the SAP Management Console (sapmc) which I usually use. In the MMC when I clicked on the Instance -> ICM, it opened an administrative web interface. Logged in as webadm and then I could see the parameters just like in a WebDispatcher web admin. I saw there that the icm/server_port_0... parameter was set with default TIMEOUT and PROCTIMEOUT values.

To fix it, I had to manually alter the instance profile (/sapmnt/<SID>/SYS/profile/...) and add the above parameter. Then the 600s timeout finally ended.

my problem was that I forgot that TWO ICMs were involved in this scenario, and both had to have the parameter changed.

I hope this helps someone else who sees the same situation. I'm awarding helpful points to everyone who responded, thanks for your ideas!

Regards,

Peter

[Former Member]

Thank you for this feedback, had same issue. And I had to change the ICM under abap side and under java side in both profiles.

[Former Member]

By the way, when I use a smaller selection criteria and the message doesn't read from the DB for over 10 minutes, this interface is successful end-to-end. This is the last piece I'm stuck on.

System details for those who are interested:

Integration Server: Netweaver PI 7.11 SP05

decentral AE: Netweaver 7.10

Adapter: Oracle Primavera

[baskar_gopalakrishnan2]

Here is my few cents.

Adjusting the time parameter to deviate normal values just for the target system's response delay is not better practice. SAP does not recommend that. We need to see the cause of delay. Apparently this is synchronous scenario. You might have to get the response within few mins.. Waiting up to 20 minutes means something problem with target db system or network slowness or so.

Questions:

Are u running a select query to provide large volume of resultset data? If so, try to tweak your SQL Query to return smaller volume of data. Or prepare a small interface test using a simple select query to return few rows of record and see the response time. Even for the small resultset, if you see delay. You might have to modify your design or work on the oracle adapter. This problem does not seem to be at PI side.

Optimum message size for processing is 5mb.

[Former Member]

Hi Baskar,

I understand your point but unfortunately this is a situation where tuning the SQL statement is not an option. I have to enable long-lasting synchronous processing. The interface will only be run once per day anyway.

Regardless of best practice, SAP documentation indicates that the parameters I set above should increase the timeout in this scenario, but it hasn't worked. I'm still looking for the parameter that will actually increase the time allowed for synchronous communication.

[baskar_gopalakrishnan2]

If your message size is too large, You can do in integration engine configuration area using sxmb_adm

Category : Tuning

Parameters: EO_MSG_SIZE_LIMIT

current value: give max value what you are looking for like 20480 or so..

This might help during message processing.

[Former Member]

Nope, it's not a message size issue. The message is 4 MB in size. The issue is the time it takes to process. I need to know how I can stop the ICM from throwing a timeout after 10 minutes. The parameters above should have solved this, but have not (unfortunately).

after some research I found that SXMB_ADMIN -> Integration Engine Configuration -> Runtime -> HTTP_TIMEOUT will override the icm parameter icm/server_port_0 if it is set, so I changed its value to 0 (according to the help text, this will de-activate it), but the error still persists.

Anyone know another timeout parameter I may be missing?