Agentry Work Manager 6.2 transmit error, timout when fetching functional locations?

[Marçal_Oliveras]

Hi,

I'm not able to finish the Work Manager 6.2 initial synchronization due to an error "Communications Error (14)" when fetching functional locations.

With production data I have a huge amount of functional locations. Executing the The BAPI in the backend takes around 400 seconds, and I can see that when I do it using the iPad, it always fails around 300 seconds, which indicates some kind of timeout.

I increased the timeout values in SMP (SP09) for the backend connection from 300 to 600 and the problem is still happening. I think it is a problem between the client device and SMP 3.0 (not with the backend) because I can see the BAPI continues to be executed even after the iPad has been disconnected with the error.

In NGINX reverse proxy I increased all the timeouts at minimum 10 minutes and didn't change anything, see the values below:

http {

.

.

.

client_header_timeout  10m;

client_body_timeout    10m;

send_timeout           30m;

.

.

.

proxy_connect_timeout 1800;

proxy_send_timeout 1800;

proxy_read_timeout 1800;

.

.

.

server {

.

.

.

proxy_connect_timeout 1800;

proxy_send_timeout 1800;

proxy_read_timeout 1800;

.

.

.

}

}

[Marçal_Oliveras · Accepted solution]

Good news.

The network team detected that a timeout setting for the Hardware Load Balancer was not set at all and its default value is 300 seconds.

After setting it to a higher value the issue has been solved. Now I'm facing another time out if the call takes more than 600 seconds but this is probably a setting in NGINX. I will keep investigating to solve it myself and anyway I will post a question in a separate thread if I need help.

Thanks to , and for your very highly appreciated help.

[mark_pe · Accepted solution]

Marcal,

While you still have access to the Network team, get a picture of where the 300 to higher seconds settings was modified in the load balancer and add the picture in this thread so that we can at least show the community where it is. Just in case their Network team do not know where it is set up in.

Please do share.

Best Regards,

Mark Pe
SAP Platinum Support Engineer

[prashanthi_vangala2 · Accepted solution]

This message was moderated.

[bill_froelich]

You mention that you are using iPad.  Have you tried using another device type (WPF for example).   The engineering team is looking into some reported issues around iPad connection drops under iOS9 especially when using a VPN.  Not sure if this situation applies to you or not but something to test from another device type to confirm.

--Bill

[Marçal_Oliveras]

Hi Bill,

I tried with Windows desktop client and Android tablet with the same result. It is not related to the platform then.

[bill_froelich]

Have you tried directly connecting the client to the SMP server (i.e. not through NGINX) to see if you are still experiencing the timeout?  That would help isolate if the problem is related to the proxy connection or not.

--Bill

[Marçal_Oliveras]

The timeout does not happen when connecting directly to the server skipping NGINX.

I already tried before connecting our SMP Development server (works with VPN) to our SAP Backend test environment (with real data that causes timeout) and it failed.

Now I finally got access through VPN to SMP Q&A environment (the one that can be also accessed via NGINX) and I proved that the timeout only happens when accessing from outside through the reverse proxy, not when accessing directly to the host.

But as I said in the initial post, we increased all the known NGINX timeouts to 10 or more minutes... therefore we don't know how to proceed.

Is there some parameter in the SMP server that defines the timeout when communicating through reverse proxy?

-Marçal

[mark_pe]

Marcal,

Hi. We may need to see the log at the point of failure. You said that it didn't finish. Where in the transmit did it not finished.

Would it be related to this thread: https://scn.sap.com/thread/3872260​ ?  We are working with another issue that the first initial sync didn't work out but it is a timer issue tied to the port 8081 here.

We would like to see your log part at the point of failure.

You said above " I do it using the iPad, it always fails around 300 seconds, which indicates some kind of timeout."

If yours is related to the link above then we have an open discussion with development.  If this is an issue internally in Agentry most of the 5 minute setup are as follows:

- Look at the SMP 3.0 Cockpit for both Backend and App Application Setting (as indicated by Steve Above) - look for anything that has 300 seconds or so.

- If you have a custom application and you are not using Push or Background sending the default connection of a time out of the client is 5 minutes.  But if you stated that the disconnection occurs in the server and not the client then you may be related to the thread above.

- We may need to see the log file closely please share the same way that the thread above shared to see if yours is related.

We will try to see if anybody in the community may know the answer.

Best Regards,

SAP Mobile Support Team

[Marçal_Oliveras]

Hi Mark,

It doesn't seem to be the same problem than the mentioned thread. My synchronization problem fails during complex table fetch of data and only if the backend RFC needs more than 5 minutes to fetch all the necessary data.

• After increasing the Agentry logs to DEBUG I can't really see anything on them indicating the error. In the messages log we can see that the request for ctLocations is done and then when the response comes back it's too late because the client it is already disconnected:

R, 622, 26,   7, 03/16/2016 14:34:28,  71,53820489,  2286,       TESTUSER, ANGEL: 83CD62BB-CE52-4DC0-AB23-BD3BF42136F3

O,   5,  1,  54, 03/16/2016 14:41:29,    ,     0,     0,       testuser, >unknown<

T,   5,  1,  54, 03/16/2016 14:41:29,    ,     0,     0,       testuser, >unknown<

F,   5,  1,  54, 03/16/2016 14:41:29,    ,     0,     0,       testuser, >unknown<

The messages are 14:41 are the response of the RFC, but the device got disconnected at 14:39, 5 minutes after the request...

• In the worker thread log, we can see that the last message is the request of the complex table:

2016/03/16 14:34:28.684:     + WorkFunction=0000000378BCF628

2016/03/16 14:34:28.684:       + User=WorkMgr6.2-TESTUSER

2016/03/16 14:34:28.684:         + Application=WorkMgr6.2

2016/03/16 14:34:28.684:           + Complex Table=ctlocation

2016/03/16 14:34:28.684:             Update BHT 'ctlocation' for 'User': Client last data update 00:00:01 01-01-1900

2016/03/16 14:34:28.685:             Update BHT 'ctlocation' for 'User': Getting back end connections

2016/03/16 14:34:28.686:             client last data update=00:00:01 01-01-1900

2016/03/16 14:34:28.686:             Backend step is configured as a Java Class; using Java class com.syclo.sap.ComplexTable

2016/03/16 14:34:28.687:             Using Java Class com.syclo.sap.ComplexTable for ComplexTable

• In NGINX logs though, something seems to point that SMP is the one who ended the connection

2016/02/25 14:56:01 [error] 2296#3104: *25349 upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond) while connecting to upstream, client: 10.XX.XXX.X, server: testurl.domain.com, request: "HEAD / HTTP/1.1", upstream: "https://10.X.XXX/XXX:8081/", host: "10.XX.XX.XXX"

[Marçal_Oliveras]

Hi Mark a couple of extra things:

• I don't have any timeouts at 300 seconds now in the SMP cockpit for the Work Manager application

• You state that "If you have a custom application and you are not using Push or Background sending the default connection of a time out of the client is 5 minutes.  But if you stated that the disconnection occurs in the server and not the client then you may be related to the thread above." I do have PUSH enabled but since we are talking about initial load, it is not active yet. What is this default time out of a client? How do I change it? In Agentry project In the transmit configuration, session "Inactive Timeout" is set to 8 hours if that's what you mean.

[mark_pe]

Marcal,

I had another customer that has exactly your same problem (The backend needs more time). The resolution that we got from them is documented in our performance troubleshooting of Error 11.

This link: http://service.sap.com/sap/support/notes/2255046

See action 10.  I apologize on the details of Action 10 as I am trying to get screenshot from the customer who utilize the solution and their network team failed to give some sort of details or snapshot of what they did.  The customer proved that most of the calculation in SAP that took longer got disconnected but on query that it was fast enough there is no issue. So Action 10 is from our development team to them which they confirmed that after tweaking the proxy's time out settings (from their network guys) they didn't see the problem anymore.

AgentryClient ---Transmit---> SMP 3.0 ----RFC--->SAP (Processing the query)

The Connection time out is from the proxy settings.

So it may be related to your issue:

"2016/02/25 14:56:01 [error] 2296#3104: *25349 upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond) while connecting to upstream, client: 10.XX.XXX.X, server: testurl.domain.com, request: "HEAD / HTTP/1.1", upstream: "https://10.X.XXX/XXX:8081/"", host: "10.XX.XX.XXX"

Best Regards,

Mark Pe
SAP Platinum Support Engineer

[Marçal_Oliveras]

Hi Mark,

Even though the note you linked has a title that points to a different problem (we get error 14, not 11). It's true that the symptoms described in action 10 are exactly the same. Unfortunately there is no suggested procedure other than "consult your network engineer". I already did so, and he increased all the known NGINX timeouts parameters but it didn't work so far.

[Former Member]

In the SMP Cockpit, go to the application on the "App  Specific Settings" tab.  Here increase the value of "Inactive Timeout"

[Marçal_Oliveras]

Thanks Stephen,

It's not the solution. I can confirm it has to be directly related to the access from the reverse proxy since I accessed directly to SMP Server using the VPN client and then the problem does not happen.

But after increasing all the time outs in NGINX it's still not working.