What product/components do you use and which version/fix level?
SAG webMethods Integration Server 10.3
What are trying to achieve? Please describe in detail.
I have created a flow service which defines a pub.xml.xmlNodeToDocument step. My ‘Pipeline In’ links node to node in ‘Service In’. My ‘Service Out’ document links to my Document Type in the ‘Pipeline Out’. When I run in debug I pass in a standard XML format I set up in the debug configuration input tab, but in my MAP step when I link a document type string in the ‘Pipeline In’ to a newly created string variable in ‘Pipeline Out’ called AcctType it does not show up after stepping over the MAP.
I did not create the Document Types from an XML file, just created it in designer. When I took my sample XML file and created a new Flow service and selected XML for ‘Receive an XML document’ it created a docType_{flowservice name} file. In the Flow Service it created the expected step of pub.xml.xmlNodeToDocument. This service works correctly.
What am I missing. Do I have to create an XML file to basically be imported and the designer create docType* files which I already did manually? I am new to webMethods so any guidance is appreciated and needed.
Do you get any error messages? Please provide a full error message screenshot and log file.
No error messages and no variables from the pipeline out coming from MAP other then the document with my document type under it and the document type I linked from document in service out.
Hi. It sounds like your XML is in a String. The input to pub.xml.xmlNodeToDocument is a Node. You will need to first call pub.xml:xmlStringToXmlNode (or pub.xml:xmlStringToEnhancedXmlNode) to convert your String to the expected type.
Debugging a service that accepts a node as input requires additional steps. I don’t recall what they are but perhaps someone else has info – in the old Developer days there was menu choice to “Submit XML to service” (or similar) that would parse the XML string into a node for you. Designer has something similar, possibly in Run | Run Configurations.
What I do in such a case, is define multiple inputs.
node (object)
xmldata (string)
And define this branch:
BRANCH on ‘/xmldata’
/\S/: pub.xml:xmlStringToXMLNode
When called via HTTP (and the client sends the right Content-Type header) IS will parse the incoming body and place a node in the pipeline and invoke your service. The xmldata var will not be present.
When you run it in debugger, you provide your XML string in the xmldata var and the BRANCH step will be executed.
This technique lets your service run in either context easily. Defining and supporting xmldata as an input also provides some flexibility to callers – they can set xmldata as a URL or form parameter (refer to the docs for details).
I thought I would help you out @reamon
Here’s a screenshot from Designer.
To debug a service that takes an XML node input do the following. Designer → Run Menu → Debug Configurations…
Select "IS service in the left hand side and click on the add icon.
Give a name, followed by selecting the service you want from the browse button.
Then click on the input tab and set the “Use XML” radio button like so.
The select the file you want to test with i.e. the XML payload and click debug.
If you want to repeat the test, just choose it from the list under “IS Services”, i.e. you don’t have to set it up each time.
@reamon I like your suggestion, but I still have the same issue after the Node is created if the variable xmldata contains my XML string. I take the document in ‘Service Out’ and link it to my Document Type I created in designer. Everything looks good after stepping over pub.xml.xmlNodeToDocument, but the next step which is a MAP will link a variable within my Document Type to a ‘Pipeline Out’ variable I created. The expected value does not show up and is null.
I’ll include a couple images showing what I am doing.
During my testing with a different Flow Service where I created it based on the XML I was sending then it works fine. Is there a difference in how webMethods handles Flow services with ‘None’ as the option for ‘Receive an XML document’ vs selecting ‘XML’? Basically I spent a lot of time creating Document Types in the designer not based on a XML Schema or XML file. I would expect my Document Types I created in designer to work just like the XML files being imported to automatically create document types. Your insight is appreciated.
Also, the documentation is not fully clear on the $xmldata arguement for me. Would I send http://{service name}:$xmldata in the POST URL? A little brain dead after fighting with this all day yesterday.
@michael6 thank you for your reply. In the debugger configuration which @John_Carter4 shows in this thread, I point to an XML file. This allows IS to do the parsing and place it into a node object from my understanding. From there I should be good to use pub.xml.xmlNodeToDocument as my first step. I see my Document Type being filled with the right values, but when mapping (MAP step) a variable in that Document Type to added variable in the Pipeline Out it is null after the step.
It should work fine, the problem is probably due to a a nesting issue in your document structure. Your document type has a top level structure called ValidateExistingInfo. Does your xml file have the same structure ?
If you look at the debugger variables as you step through your code you will see the document that gets generated following the call to xmlNodeToDocument. Take a screen shot and send it here if it isn’t clear what I am saying.
regards,
John.
Your a genius and observant @John_Carter4. My document type was wrong. Very newbie error and thank you for your help. I thought I would have to scrap all of the work I did prior.
I would like to expand on this topic. Hopefully I can use this topic instead of creating a new one. I have a document type with a Document, Document List, and 2 strings in that order. I also created another document type with a Document, Document List, and 1 string in that order. I send in an XML string based on the first document type and in the Map step link one of the strings in the first document type to a string in the second document type. In my input I only send in one document list value it does not show up, but if I pass in 2 or more it will. How do I keep the Document Type structure but allow 0…n values that would be associated with the Document List? I will at times have no data for the particular section defined as a Document List while at other times I could have 1 or more. This has to be a simple solution.
can you share a screenshot of your DocType definitions as well, please?
If possible, I would prefer creating a XSD first and then create the DocType from there.
By doing so you can define cardinality and types much easier (and it is recreatable in IS if there happens anything weird to your code base).
This is fairly common – the XML syntax is such that one cannot tell that singleton entry is actually array[0]. The parser needs help to know that. There are 2 ways when invoking xmlNodeToDocument:
Set makeArrays to true and specify the element names in the arrays list that are arrays.
Set makeArrays to false and specify a documentTypeName that conforms to the expected structure.
With one of these, the document in the pipeline will always have A as an array.
@reamon I tried to update this topic but I was encountering technical difficulties. I did finally realize I had to set the arrays for my Document List types in order for it to properly convert over. One question I do have is if my Document Type contains Document Lists of the same name will it cause any issues in the array Service In settings? In addition, although I don’t see it with the calling SOAP service I am making but if someone has the same name but one is a Document and the other is Document List will xmlNodeToDocument have a fit?
I’m unclear as to what you mean. Can you clarify “if someone?” The definition of the document type must match what is expected in the XML. Any XML that does not match the doc type would be considered an error.
In your example, you stated A is a document list. Define it that way in the document type. If someone sends a single A element, it will be parsed and treated as a list, with just one entry. Which is what you want.
Is there a different scenario you’re thinking of? If you can, share the document type you’ve defined, an example XML, and the inputs being passed to xmlNodeToDocument. That will make things clear.
Unless there is a specific reason not to do so, you should default to using the second option I listed earlier. Define a document type that defines the document. Mark elements as optional as needed. Typically, you want the document type so that mapping and other processing is easier. As @Holger_von_Thomsen suggests, creating an XSD and importing that to define the document type in IS provides some benefits. But if the document is simple, manually creating works.
A little off-topic – are you create a new SOAP provider? If so, what is driving that? I ask because SOAP is generally a pain (I abhor XML namespaces) and JSON is the preferred format these days.
Apologies for the delayed response. I agree developing a XSD is the better approach. Sadly, due to time constraints and a good tool I chose to take a tougher path. In addition, the vendor I am interacting with has bloated their schema with 4 different products. This has created significant challenges when I only care about 1 product. The provider only supports a SOAP solution at this time. I personally am moving my services towards a RESTful interface. As for XML vs. JSON that is a discussion for another time. I have worked with both formats and will leave it at that for now. Thank you for the help.
That’s what we sometimes face too. If that’s the only thing a partner supports, then you gotta use it. I asked about SOAP only in the context of, generally speaking, probably wanting to avoid creating anything new using SOAP.
No worries about XML vs. JSON. They both are useful and sometimes you gotta use one even if you prefer the other.
Regarding “RESTful interface” – might consider the POV that there is no such thing.
in this case the Provider should be able to provide you a URL, where you can retrieve a WSDL from, which in turn contains the schema definitions for the document types.
Importing this WSDL in Designer as a Consumer WSD will create all the documents, services etc. which you need to invoke their SOAP service.
I asked about SOAP only in the context of, generally speaking, probably wanting to avoid creating anything new using SOAP.