I would rather not get into writing interface code. Using Web Service standards was supposed to provide this advantage over the traditional use of Message Oriented Middleware (e.g. MQ Series) in that you don’t have to code the interfaces to the middleware. I know EntireX came out in the days of M.O.M. and you can use it that way and many early adopters do, but if at all possible, I want to do what the sales and marketing folks claimed which is that we can generate everything we need to call any web service from Natural and to invoke Natural as though it were a web service.
In our case, we currently expose two services that are Natural subprograms and for that we have no problems. We call out to three web services from Natural, two of them being asynchronous web services which EntireX is claimed to support. Thanks to Douglas Kelly, we know that we need to use Reliable RPC to make that happen, so there must be something wrong with how we are using it because the XML RPC Server still throws messages back that the response is null, and then after a small number of calls the whole thing just locks up as though it has all servers busy (even though no client is waiting for a response and all previous requests were processed by the SOA Server).
We have a support request open on this. Trouble is, I don’t see the likelihood of success in me coding some Java program for every asynchronous web service interface. I don’t know Java and don’t believe I should have to with a product like EntireX.
In the possibility though that the problem stems from these service requests waiting too long to time out which would be fixed with the attribute of the TargetServer tag, where do I set the parm such that it gets placed into the XML document that EXX sends?
Brian, these are 2 different situations. The first calls actually get an HTTP response back but without any payload data. That’s fine, unfortunately the XML RPC Server currently fails to process the empty response. However, a fix for that is on its way over the ocean.
The last call never gets a response from the HTTP / web server and then the XML RPC Servers waits forever.
You only have to set it in the entirex.xmlrpcserver.configuration.xml file. This timeout is handled locally by the XML RPC Server. It’s just the maximum wait time for a HTTP reply from the web server.
Thanks for explaining, Rolf. I was able to find what you meant and added the attribute to say that the request should time out if a response isn’t received in 5 seconds. However, this is not working as I think it does get a response but it’s null.
You mentioned a fix being on its way relating to this and the SR I have open with Denver. I will continue to work that track then since I am not sure there is much else I can do until it is ready, unless you know of something else that might help.
Right now, we still get the 2000 0079 response, and after about 6 successful service calls the whole thing just freezes up.
We don’t have this problem with the one service we call that sends an XML payload back.