An old problem has reared its ugly head, and I am under a lot of pressure to fix it. I have an SR open on this and don’t want to divert away from the efforts there, but because it’s an old problem we fixed, maybe I am overlooking something.
We have three web services we call from Natural through EntireX and the XML RPC servers. We had these working after some previous issues, but we have made changes to two of those services which changes the WSDL, the IDL and the XMM for them. I cannot generate the IDL and XMM from the WSDL. This is what SAG R&D is looking into right now, because if we could, I could also generate the Natural Client program. We have had to attempt to edit these objects manually in order to add the new paramters. I think we’ve done a pretty good job of taking these files and understanding the format string, the buffer length, the mappings and the variables defined in the client program and PDA, but as all the warnings say not to attempt to edit these objects, I am sure we are not 100% accurate in having these manual adjustments work.
In one changed service, the CheckAvailability one, they changed the XML payload on return to pass back an error type and message (A1 and A240 respectively) instead of a code (A4). The rest of the XML response maps well and is available to the program, but the newly added fields do not get returned to Natural.
The other changed service, PubSalesOrder, had some parameters added to the XML request, and as this is meant to be asynchronous, we do not have an XML response applicable. The changes to our objects allow for five successful calls, but upon making the sixth call, the XML RPC Server hangs, which is the behaviour we saw before. Sometimes we can deregister and re-start the XML RPC Server for this service, and other times we have to reboot the whole Windows instance. Then we are good for another five successful calls and the sixth one hangs consistently. When we had this problem before, it was solved when we implemented Reliable RPC and generated and used the Natural client stub, and after deploying a fixed entirex.jar file on the Windows instance running the XML RPC Servers. As far as I can tell, we still are using those, so I don’t know why we would hang unless there is something not right with the stub. Since I can’t generate this from the current WSDL, I can’t be certain the objects are correct.
Hence,this is why I am focused on this issue with generating the IDL from the WSDL as a means of solving the problem where the call fails to reach the XML RPC Server and why I think CheckAvailability is also failing in a different way but from the same root cause. But if I am missing something easy, perhaps I can resolve it faster.
Please advise as soon as possible since Eaton is putting a lot of pressure on me to resolve it.