I have a number of XML files stored for testing purposes. I am currently trying to find a way to convert these XML files in a Java service to IData objects so that a test client can connect and invoke a service which takes the IData object as one of its inputs. I have looked into XMLCoder and IDataXMLCoder but both of these seem to operate only on XML files structured according to webMethods… is there any way to take a general purpose XML file and convert it to an IData object similar to the behavior of the stringToDocument/documentToRecord combination from within a Java client?

Good question. AFAIK, you can’t convert an XML string to an IData record in a java client (without manually building the IData structure) so you could write a wrapper flow service that takes your xml string, converts it to a record and then invokes the actual service you want to test. Then call your wrapper service from java instead.

Or from your java client you could connect to IS, invoke the built-in conversion services (stringToDocument, documentToRecord) and then pass this IData result record to your service to be tested.

I was afraid you were going to say that. I had it working with the second method listed (invoking sTD and dTR from the client) but it seemed like a bit of a hack, and I figured I’d ask to see if there was a more elegant approach.

This is a part of a little project to put together JUnit based unit testing for our development process.

I have another problem. It seems that IS is not properly taking the Object input (node) for the recordToDocument service from my Java client. Does anyone know if you can in fact invoke a service which has an Object as an input from a Java client?

Regards,
-Dave

I am slightly confused by your question. You are asking if a service can take a node but the recordToDocument service you mention takes an IData record (not a node). Since the generic ‘invoke’ method takes a IData as input and gives IData out it is possible.

You can pass an Object to a service but you’d have to have the class in your java client’s classpath and the object would have to be serializable. For XML, I prefer to send the XML as a string to IS. Or create test services in IS using JUnit (java services) and run them from within IS. (or trigger it from the java client but the tests exist on IS). Just some suggestions…

David,
[url=“wmusers.com”]wmusers.com
The above is an article discussing what are you interested in. It’s very helpful.

Nick F

Will - My bad. My question was concerning the documentToRecord service not the recordToDocument service. I have been unable to execute this service from a client because I’m unsure of what to retrieve the node from stringToDocument as and what to put the node back into the pipeline as for the invoke of the documentToRecord service.

Basically the client is following this procedure:

1. Read in the input XML file.
2. Prepare it as a string for input into stringToDocument.
3. Invoke stringToDocument.
4. Retrieve node from the output.
5. Prepare it along with the strings makeArrays and recordName as inputs for documentToRecord.
6. Invoke documentToRecord.
7. Retrieve the boundNode from documentToRecord.
8. Rename the boundNode and prepare it as input to a map step that converts the record to a Mainframe FLR file.
9. Read in the expected FLR file.
10. assertEquals(flr_file_generated,flr_file_actual) //A JUnit method for assertions.

Hope that clears things up. At this point I am really looking for an example of invoking a service like documentToRecord from a Java client, or information on how to avoid invoking stringToDocument and documentToRecord and just convert from XML to IData completely within the client code.

Nick-
Thanks for the link, but I have been using JUnit for quite some time, I was really trying to find out how to get certain transforms done in IS in order to make testing more complete.

Regards,
-Dave

Dave,
No prob.s - next time I won’t just do a quick skim on your post.

Nick

Dave,

If you’re willing to do some pre-processing to generate the files, you can accomplish your goal.

You’ll need to create a service that does the following:

• do a loadDocument of some URL
• invoke documentToRecord on the resulting node
• execute your custom Java service that utilizes the IDataXMLCoder to persist the IData to a file as XML

With the XML file, you can now create your client to reconstitute the IData instance and invoke your test services.

Just make sure that you prune the pipeline on the last service to only what you need.

If your service takes a node, you could pass the service a string, but set the parameter name to $xmldata and IS will parse this string into a node for you.

My philosophy is usually ‘Keep it simple’. Part of the issue is to write services that make them ‘testable’. Strings as input/output are easy to test for example. For you to be returning a node you must be converting the record to a node before finishing the flow. You could keep the record in the pipeline and have the calling service convert it to a node (if necessary). I know I definitely don’t want to be building an IData record from scratch or parsing a node in java. You could think about testing your flows using flow services and invoking them from a client, writing helper services that convert the parameters for passing them back to the java client.

Will,

Atleast part of what you are trying to is doable on the client. The client API includes a class com.wm.lang.xml.Document. This is the class the node object is created from ? So if you have a string and want to create a node object from it you can just use :

com.wm.lang.xml.Document node = new Document(xmldata, null, null, null);

There is nothing to create the actual IData from the node. For that you will have to use the server services.

Eduardo-

Thanks for the heads up, I'm taking the time to convert the file now for my test cases.  I was really trying to set things up so that other developers at the company could make use of things without much rework.  I appreciate the information. 

Will-
Thanks for your update as well. Thanks for pointing out the shortcomings in the designs. We are trying to graft a testing framework on to existing services/packages. I will be taking these design philosophies under consideration for future integrations that we create. Thanks for the tip about $ in the parameter name, I’ll give that a try and report back so that others who try this will be able to make use of my learning experiences.

Regards,
dave