EntireX - XML Tester Error: Broker Error 2000 0079: Transport error......

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


Start with the documentation

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.

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.



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
00200134 Logon required C-CON-ID

99999999 No server environment S-CON-ID

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:


Then this:


Then we do this:

P-FUNC := ‘G’
P-FUNC := ‘P’
P-STATE := 1
#PDA-CR0720A1-ERROR-CODE := 4 /* error in reliable rpc

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


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.



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

	private void start(String[] args) throws Exception {

	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();
		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)

That’s an attribute of the TargetServer tag: