Problem solve Get help with specific problems with your technologies, process and projects.

Resolving app server connectivity problems for remote users

Remote users on the VPN are having problems connecting to SAP application servers.

Our SAP landscape consists of two SAP application servers -- node 1 and node 2 -- in cluster mode, and the data is stored in a SAN connected to these servers. We are running ECC 6.0 on Windows 2003 x64. We also use SAP Domain Controller (IDES server, which is also our DNS and SAP router.

We have many remote users in different locations who connect to SAP through a wireless VPN. After nearly a week,...

the remote users cannot connect to one node. Then two or three days later, both nodes become inaccessible. The remote user constantly receives the message "Waiting for response." Local users do not have this problem.

The problem gets resolved after the restart of both nodes and the IDES server, but a few days later the same connectivity problem appears. How do I fix this problem?

What you describe is a common issue with SAP. What happens is that the connection between XI and your (slow) remote apps hangs due to some communication error. There are many causes for this, and it is often not the same cause that triggers the effect. Therefore, it is normally not possible to fix this on the communication side. When you reset the server node (or reboot XI), then the connection is cancelled and the node is happy to receive new data.

A quick fix would be to add more server nodes to XI. That will not solve the problem, but it leaves you more time until you need to reboot. A watchdog application that monitors the connection and resets the server node only may do the job as well.

To overcome this problem principally, you need to redesign the architecture of your connection by "galvanically decoupling" data input from data processing. This means that you use a proxy server or proxy application that buffers the connection data before it is processed by XI. The proxy needs to be able to save the data even if the next process step is currently unavailable.

In any case the solution is to work asynchronously with a message queue. Your apps will deliver data to an MQ and then XI takes the data from the MQ at its own speed.

Case 1:
Do you kick off a heavy synchronous process after you received the data? My recommendation is in this case is to start the process asynchronously. The concept would then use the XI built-in message queuing but you still have not the control over the process.

Case 2:
You route all inbound data to a different process that does nothing else than save the data to a file on the XI server (or an MQ or a DB, but files will do in your case perfectly well). Then you start your process with the file data as input instead of processing them directly. This would be an MQ via file.

Case 3:
If the solution in Case 2 still does not solve the problem then I strongly suggest to write a small BSP application in the XI ABAP ecosystem that receives the data and saves it to a file. The ABAP HTTP is much more reliable than the Java stack. It runs independently, so even if you boot your XI Java stack, the data can still be received. Also, if the ABAP HTTP connection hangs up, you can simply kill it with SM50 as usual.

In any case the strategy is like this:

Process 1: WLAN device ---> (HTTP) ---> Gateway application ---> File
Process 2: File ---> Process

Process stack 1 and 2 work completely independently and cannot influence each other, and hence make the full system stable. Since the data input process is simple and quick, the likelihood that there will be major trouble or connection hang-ups becomes very low.

Dig Deeper on SAP and enterprise service oriented architecture