|
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.
|
