Has anyone actually tried using the XML RPC Server to access a web service from a Natural program runing on OS/390? I’m a bit unclear on how to configure both the server and the mainframe RPC client.
The XML RPC server configuration uses the xmm SOAP mapping resulting from importing the service wsdl into the workbench. Should the “TargetServer” name point to the connection endpoint (url) of the web service itself? What about the soapaction? I know it’s not always required, but what if it is? Can a header be added? The documentation here is very sparse.
In addition, I’ve successfully setup the SYSRPC Service Directory to access the server and can see the calls in the control center. However, I’m unsure of how to setup the SYSRPC Service Directory using the default Library and Program names generated in the idl by the workbench. These names are longer than the 8 characters allowed in SYSRPC. Should I use the alias feature in the workbench to give them short names? I’m getting very strange errors in the Natural client like a NAT0004 ‘Define Data’ error. Also, I’ve tried using both the AUTORPC=ON parm (without the client stub generated) as well as with a stub. Still no luck.
Finally, I’ve tried testing with a SOAP document generated from my xmm by the workbench, but it fails with a ‘500’ error from the web service. So, I can’t even be certain that the SOAP is generated properly.
Again, does anyone have much experience with this scenario?
Ned
Remember to never burn bridges. Unless you drive a Hummer!
Hello Ned,
could you please post the wsdl, xmm and idl files ?
Also, make sure that you are using at least patch level 10 of Communicator version 7.1.1.
Kind regards,
Rolf
Rolf Bahlke
Software AG Research and Development.
I’ve included the files you requested for a simple example that gets a temperature for a given US postal code. I got the xmm to generate a valid SOAP request by modifying the default EntireX namespace on the method to that of the wsdl. Also, rather than use an alias in the idl, I modified the xmm mapping to map the Upper case program name used in SYSRPC Service Directory configuration to the mixed case method name of the service (another potential problem I discovered.) Finally, rather than use the AV format for the zipcode which results from the wsdl import, I changed it to A5 since I know there are issues with variable field lengths on OS/390. Otherwise, it’s all default workbench.
Thanks for taking a look.
Ned
Remember to never burn bridges. Unless you drive a Hummer!
TemperatureService.wsdl (1.5 KB)
idl
Ned
Remember to never burn bridges. Unless you drive a Hummer!
TemperatureService.idl (402 Bytes)
xmm
Ned
Remember to never burn bridges. Unless you drive a Hummer!
TemperatureService.xmm (5.65 KB)
EntireX 7.1.1.10 is being used.
Ned
Remember to never burn bridges. Unless you drive a Hummer!
Hello Ned,
thanks for the files.
What problems do you get now after changing the idl and the namespace ?
In case you still have problems on the Natural side: if the XML RPC Server does not find the xmm mapping, try using the library name SYSTEM. If you still get some sort of parameter errors you need to check the direction of the parameters in Natural because the IDL has an IN and an OUT parameter.
Kind regards,
Rolf
Rolf Bahlke
Software AG Research and Development.
I just keep getting very strange errors of different kinds, depending on what changes I make. Just to let you know, I’ve gotten the calculator example working with the regular java rpc server and a mainframe client. Of course, I had to rename the examplestub and exampleserver to use my Natural library names. I suppose using ‘SYSTEM’ instead would have worked as well?
Anyway, I changed both the idl and the SYSRPC configs to use ‘SYSTEM’ as you suggested. Initially i got an 82 error saying it couldn’t find the object. Then I changed the logon parm in SYSRPC to blank instead of ‘Y’. Now I’m getting error 77 about a READ/WRITE WORK FILE statement! Very strange.
I uncatalogued a stub that I had in SYSRPC to be sure AUTORPC is active. I have also added (AD=O) to my input on the CALLNAT in my client, (AD=A) to the result.
Any other ideas? What’s with the error 77?
Ned
Remember to never burn bridges. Unless you drive a Hummer!
Hello Ned,
it is transparent to the Natural RPC Client to which RPC Server it is talking to. So whenever an RPC Server returns an error number to the Natural RPC Client the Natural interprets this number as a Natural error number.
In your situation the XML RPC Server returned error 77 which of course is not a Natural error.
You need to interpret error 77 (or whatever strange error code you’re getting back) as an EntireX Error. The error class for the XML RPC Server is 2000, the error description for 0077 in the docu says: “The incoming document was not found in the internal repository.”. This means that the library and program name used by the RPC Client are not defined in the XMM file. The posted XMM file contains an entry for library PA0PMSTR and program GETTEMP. I assume Natural uses library SYSTEM. I suggest to regenerate the XMM file using library name SYSTEM.
Kind regards,
Rolf
Rolf Bahlke
Software AG Research and Development.
I’ve done as you suggested and changed the library name to ‘SYSTEM’, but still no luck. Also, to avoid the error code confusion, I’ve switched to trying to get the java test client generated by the workbench itself to work. Now I am getting the error “Broker Error 2000 0004: EntireX Java XML RPC Server / XML Runtime returns: java.io.IOException: Server returned HTTP response code: 500 for URL: http:…” This would appear to indicate that the SOAP message being generated by the XML RPC Server is faulty, even though I have verified a sample input document generated by the workbench using XMLSpy. Or, is it possible that the XML RPC Server isn’t correctly parsing the SOAP response into a valid RPC response? I’ve tweaked the Out mapping to ensure that it looks similar to the response in XMLSpy.
I’ve now tested with several different web service wsdl’s, but none are working. 
Ned
Remember to never burn bridges. Unless you drive a Hummer!
I’ve also started testing with the XMLSpy Debugger in order to examine the SOAP request generated by the XML RPC Server. Unfortunately, the debugger doesn’t seem to be responding to the requests. I’m suspicious that the XML RPC Server isn’t adding the SOAPAction header whenever it’s required. How is the SOAPAction handled/specified by the workbench/XML RPC Server?
Ned
Remember to never burn bridges. Unless you drive a Hummer!
Hello Ned,
we ran the example here, starting from cratch using the original wsdl file from www.xmethods.net.
We did a default soap mapping, which did not run. The web server delivered the 500 error.
We found 2 issues with the default mapping which can be resolve by changing the mapping in the workbench:
1. In the IDL file we used the program name “GETTEMP” to be on the save side regarding Natural. However, the web service requires “getTemp”. We changed the element name in the IN mapping to “getTemp” and the element name in the OUT mapping to “getTempResponse”.
2. We had to change the namespace-uri to “urn:xmethods-Temperature” in both the IN and OUT mappings. Default was something like urn:com-softwareag-entirex-rpc.
After these changes (and don’t forget to yoyo the XML RPC Server) the Java Tester worked. For Atlanta (31141) we see 39 degrees.
The hard issue is that the XML RPC Server currently does not display the fault document delivered by the web server in case of a HTTP error. You need to intercept the HTPP or TPC stream to see the error message.
BTW the soap action (which defaults to GETTEMP in this example) can be changed in the SOAPACTION part of the mapping.
Kind regards,
Rolf
Rolf Bahlke
Software AG Research and Development.
I don’t see any SOAPACTION part in my mapping. Are you talking about the xmm file? Do I need a newer version of EntireX? Again, I am using v. 7.1.1.10.
Ned
Remember to never burn bridges. Unless you drive a Hummer!
OK. I found the mention of the SOAPAction header in the workbench online help and I think I’ve got this working properly. For web services that don’t require the SOAPAction HTTP header (like the TemperatureService), the namespace, proper method name mapping and the use of “SYSTEM” as the idl Library are all the changes required to get the default wsdl>idl>SOAP mapping to work with the XML RPC Server. Otherwise, you will also have to add the SOAPAction element to the SOAP-ENV:Header as described in online help.
As you say, Rolf, the error handling in the XML RPC Server could be a bit better. At the very least, some better logging capabilities might help. A 500 response from the server can be any of a number of issues. Anyway, seems to be working now. Thanks for your help.
Ned
Remember to never burn bridges. Unless you drive a Hummer!
Sorry, I seem to have a mixture of jar files on my machine. The runtime jar is 711.10, but the workbench jar is a newer (internal) version.
The soap action will be available with the next patch level of 711. If you need the soap action header, you can manually insert it in the workbench: just create a new child node named SOAPAction under SOAP-ENV:Header.
I checked the differences of my xmm file and yours.
In your xmm file is a typo, instead of GetTempResponse it should be be getTempResponse. And there are some occurrences of the urn:com-softwareag-entirex-rpc namespace. But there are also some other strange differences which look like an incorrect generation of the xmm file by the 711.10 version. With the 711.21 (which is the latest released patch level for the Java/XML stuff) they do not occur. I suggest that you download the 711.21 version from servline24 and try again with this one.
Hope this helps.
Kind regards,
Rolf
Rolf Bahlke
Software AG Research and Development.
Rolf,
I tried everything that you mentioned in your posting from Jan27th, but keep getting 2000 0004’s (http error 500).
I used the same temperature demo webservice from www.xmethods.net, did the program name changes (actually inserted getTemp (mixedcase) as Alias …) and changed the namespace (where did you get that from, btw.?).
I am running 7.1.1.30
I finally got it working. I still had some wrong namespaces in my xmm file and found out that you have to do a new mapping, if you change the namespave - just saving the xmm file is not enough …
To make it work from Natural it’s also important to change the (AV) input field to a non-variable Alpha field (A5 in this case), otherwise the RPC Server will choke with an 0013 0202 (wrong return length).