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?
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.
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.
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.
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.
This was first published in January 2009