I generated the IDL and XMM file for a web service and also started the XML RPC server.

When I tried to test using XML Tester, I got below error.

XML Tester Error: Broker Error 2000 0079: Transport error. Caused by: org.apache.axis2.AxisFault: The input stream for an incoming message is null.

I think XML RPC server is waiting for a response from web service and reporting an error beacuse it did not get any reply back from the web service. However, web service is an asynchronous service with no reply. Further, I verified that web service did receive the request xml payload which I used in my test and completed successfully. but still we got an error in XML tester.

I’m not sure if I’m missing any step to make my call as asynchronous with no reply. I tried to search but could not find where to specify if I’m expecting a reply from web service or not.

Another thing which I noticed that EntireX generated the parameter in IDL file as InOut while I think it should have generated as In. I tried to modifly the property of parameters in XMM file as In but still got same error.

I’m also attaching wsdl, xmm and IDL file.

Kindly advice. Thanks.

When you use XML RPC server, it means you call an external Web Service (elsewhere outside EntireX domain).
In such case - this is not the use case for XML tester, rather you should use Java Tester under workbench.

On IDL - click Test Software AG IDL, specify Broker and RPC service of XMLRPC Server ( example RPC/XMLSERVER/CALLNAT).
Click PING - to check connectivity to XMLRPC server.

Enter INput parameters, and issue Call; this will cause XMLRPC server to send SOAP to extenal Web Service.

Now there at least two ways to see the SOOAP exchange between XMLRPC server and external SOAP server.
One way -, is to open ADVANCED trace in XMLRPC server, see here:
[url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_ga/EntireX/8-2-SP1_EntireX/adminWin/tracing.htm#traceXmlRuntime_sho[/url]rt
In the trace you should notice the SOAP Request and Reply.

Another way is to use Apache TCPMON - to sniff SOAP exchange.

Please note EntireX fix 8.2.1.19 on Empower - fix for both entirex.jar and Designer. This is best level for working with external WSDLs.

Last - you are invited to open incident to Global Support.

Shmuel Coller

RPC is generally a request/reply protocol. To use asynchronous requests that are not expecting a reply, you have to use the “Reliable RPC” options. The EntireX RPC Server that you are calling must support Reliable RPC.

A key requirement for Reliable RPC is that the IDL must have “IN” elements only. You need to change the “Data-Area” to IN only and regenerate your wrapper.

Hello Shmuel,

Thanks a lot for your response.

I tried to test using Java Tester but got the same error message. I was using ADVANCED trace level and was able to see the request payload but not response beacuse web service is asynchronous with no reply and my server is expecting a reply and I think this is the reason I’m getting the error.

Hello Douglas,

I have no experince working with reliable RPC and would appreciate if you can provide any documentation reference or example of reliable RPC.
Not sure, If I need to change some option for my broker / XML RPC server. If yes, what option do I need to specify to make it reliable RPC. IF i need to make changes to my broker, Will it affect my other xml rpc server which are used for synchronous communication.

Any guidance/help will be much appreciated.

Yogesh

Start with the documentation
http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_ga/EntireX/8-2-SP1_EntireX/rpc/intro.htm#intro

When you have further questions, please include the complete scenario you are working with. For example, using EntireX Designer 8.2.1, you import a WSDL into the workbench, which generates an IDL and XMM mapping. You have an XML RPC Server running on Windows 7 and deployed your aar files to there using the Designer deployment.

Thanks a lot for your response.

Please see the below steps which I performed.

1. I generated the IDL and XMM files by importing the external web service WSDL file using EntireX Designer 8.2.1.

2. I’m running XML RPC server on Windows XP.

3. I tested the XMM file using XML tester by using Reliable RPC option and did not see any error on the designed workbench. However, I could see the error “SendReceive Exception: com.softwareag.wsstack.client.API.WSClientException: org.apache.axis2.AxisFault: The input stream for an incoming message is null.” in the XML RPC server log file exx.sdk.xml.runtime.log.

4. I also executed a test from Natural and got the Natural error (NAT6977 EntireX RPC error on Server, reason 10010007). I checked the log file and found the same error ((SendReceive Exception: com.softwareag.wsstack.client.API.WSClientException: org.apache.axis2.AxisFault: The input stream for an incoming message is null.) for my test from Natural.

5. I checked the external web service and found that message was received by external web service and processed the message successfully.

I’m attaching the IDL, XMM and log files.

Please advise what step am i missing.

Thanks,
Yogesh
processinvoiceresponseentirexprovabcsimplv2_client_ep.xmm (14.2 KB)
processinvoiceresponseentirexprovabcsimplv2_client_ep.idl (705 Bytes)
exx.sdk.xml.runtime.log (36.2 KB)

I am jumping into this conversation as I am working on this with Yogesh. He has done a fine job of researching the leads that Doug has provided, and I think we are close to having this work. Yogesh has tried the Reliable RPC approach and has generated RPC Client modules from the workbench. However, we are now getting errors back saying that the XML RPC Server is not a high enough ACI version to support Reliable RPC.

Please advise what we need to do to overcome this problem.

Thanks,

Brian

Never mind… I am passed that now and onto the next error, which is NAT6971 Connection error on Client, reason 9.

(IV5000P1 in TATALIB, line 0620).

reason 9 indicates an RPC error (often a Broker error) was returned. Issue the RPCERR command to get more details. Also check the server log.

ERR 6971
CLIENT-PARMS C-BIKE
B C-NODE
ETB103 C-NAME
DOOPROCESSINVOICE C-ERROR-TEXT
00200134 Logon required C-CON-ID
-1 C-CON-OPEN X C-ENTIREX-RPC-ERROR-TEXT

SERVER-PARMS S-BIKE
B S-NODE
S-NAME
S-ERROR-TEXT
99999999 No server environment S-CON-ID
0 S-CON-OPEN

I have a feeling this “Logon required” is something else required of Reliable RPC?

Am investigating…

Is USR4371N something that can be used to issue this LOGON?

documentation for Reliable RPC for Natural is in the Natural documentation: http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat427mf/rpc/reliable_rpc.htm#reliable_rpc

not sure of 4371, but USR2071N should work.

Ok I am getting confused. We issue this call first:

CALLNAT ‘USR2007N’ WS-PROFILE-VIEW.USR2007N-FUNCTION
WS-PROFILE-VIEW.USR2007N-NODE
WS-PROFILE-VIEW.USR2007N-SERVER
WS-PROFILE-VIEW.USR2007N-LOGON
WS-PROFILE-VIEW.USR2007N-BIKE
WS-PROFILE-VIEW.USR2007N-NOSERVDIR

Then this:

CALLNAT ‘USR4008N’ WS-PROFILE-VIEW.USR4008N-P-FUNC
WS-PROFILE-VIEW.USR4008N-P-LIB

Then we do this:

IF WS-PROFILE-VIEW.RELIABLE-RPC
P-FUNC := ‘G’
CALLNAT ‘USR6304N’ USING USR6304-PARMS
IF P-STATE NE 1
P-FUNC := ‘P’
P-STATE := 1
CALLNAT ‘USR6304N’ USING USR6304-PARMS
IF P-RC NE 0
#PDA-CR0720A1-ERROR-CODE := 4 /* error in reliable rpc
ESCAPE ROUTINE IMMEDIATE
END-IF
END-IF
END-IF

It’s after that we get the Logon Required error.

Doesn’t make sense to me since the USR2007N is the LOGON, yes?

Please advise.

We’re cross-posting.

OK I can see how USR2071N is different. What are the requirements of this routine? Are these RACF ids? Natural Security ids? Something new specific to EntireX (and if so, where do I set up these ids?). Guess I am uncertain as to where this is being authenticated to.

And depending on what kind of user ids these are, I could have problems if we want the user’s *USER value populating the USER_ID field since I am not sure how we populate their password. Is password required?

Thanks for providing the keys to resolving this. Reliable RPC seems to be implemented correctly now, including issuing the LOGON.

I assume your approach will not work. You cannot have a HTTP server which does not send back a reply.

The HTTP specification clearly states that HTTP is a synchronous request/reply model, see HTTP/1.1: Introduction

A HTTP client has to wait for a HTTP response from a HTTP server, and this what the XML RPC Server does. If no reply is coming back it will wait forever and stop responding to other requests (Brian, does this sound familiar … ?)

You can set a HTTP wait timeout to avoid freezing the XML RPC Server, see http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_ga/EntireX/8-2-SP1_EntireX/adminWin/xmlRpcServer_admin.htm#d0e49234

And if you really want to continue with your special HTTP request logic feel free to do so. http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_ga/EntireX/8-2-SP1_EntireX/adminWin/xmlRpcServer_admin.htm#javaApiForXmlRpcServer describes how you can use the XML RPC Server so that it does not do a HTTP call but instead it calls a custom Java class. And in this Java class you can implement the required “HTTP” logic without waiting for a reply.

It’s a lot to absorb. Looking at the documentation block, it makes reference to a parm called httpConnectionTimeout which isn’t part of the default enitrex.xmlrpcserver.properties file.

So, I have a block that shows this:

Security and encryption

entirex.server.password=
entirex.server.security=
entirex.server.encryptionlevel=0

The documentation seems to point there with this block:

TargetServer Block

The section

specifies a Web service address (currently only http(s) is possible)
contains the IDL-XML mapping files (XMM)
allows specification of basic authentication with a fixed user/password within the tag :
attribute user : Name of default user
attribute password : Password of default user
optional attribute password-encryption; possible values: base64, plainText (default). Specifies how the password is encrypted.
attribute httpConnectionTimeout : HTTP connection timeout in seconds
See Reference - HTTP and Java Interface for explanation of attributes.

Is this where I add this timeout parm?

I am also a bit confused because Douglas seemed to explain how the use of Reliable RPC would allow us to make these asynchronous web service calls. Now you are saying that you can never make asynchronous web service calls directly. Possibly if I can figure out how to do this I can call some code in Java that hides this from me so I call THAT from the XML RPC Service instead of the service itself to simulate a put-and-forget scenario.

Please advise if I seem to understand this at the most microbial level.

Regds,

Brian

Looks like there is some confusion about the relationship of web services and HTTP. HTTP is a transport protocol which has nothing to do with web services (it has been invented for browser to web server communication). HTTP can be used as a transport for web services (“SOAP over HTTP”). So you can still have asynchronous web services using (synchronous) HTTP. To achieve this either the web server (which receives the HTTP call) or the web service stack (which processes the web service) have to send back a reply to the waiting HTTP client before actually executing the web service.

But as I have already mentioned you can bypass the standard HTTP logic of the XML RPC Server and use your own one in a custom Java class which could look similar to the following (very basic and completely untested):

import java.net.HttpURLConnection;
import java.net.URL;
import java.util.Properties;
import com.softwareag.entirex.xml.rt.XMLRPCServerInterface;
import com.softwareag.entirex.xml.rt.XMLRPCServer;

public class MyXMLRPCServer implements XMLRPCServerInterface {
private XMLRPCServer xmlRpcServer;

public MyXMLRPCServer() {
xmlRpcServer = new XMLRPCServer();
// register your implementation of XMLRPCServerInterface
xmlRpcServer.registerXMLRPCServerClass(this);
}

private void start(String[] args) throws Exception {
xmlRpcServer.start(args);
}

public byte[] invoke(byte[] requestDocument, Properties properties)
throws Exception {
String url = "http://myserver:8001/soa-infra/services/default/myservice";
HttpURLConnection http = (HttpURLConnection) new URL(url).openConnection();
http.setDoOutput(true);
http.getOutputStream().write(requestDocument);
http.getOutputStream().close();
return new byte[0];
}

public static void main(String[] args) throws Exception {
MyXMLRPCServer myServer = new MyXMLRPCServer();
// start XML/SOAP RPC Server with arguments (same as command line)
myServer.start(args);
}
}

That’s an attribute of the TargetServer tag:

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.