Initialize doc as null/Ensure nil tag on null fields

, ,
1

First of all, how do you initialize an entire document as null? I need to ensure that every field is sent to the customer when documenttoxmlstring is run.

Also, I’m working with webMethods 7.1.2 and am struggling mightily with generating a field that looks like this:

After looking around for hours, I see that the answer was supposedly right in my face as there is an optional field associated with documentToXMLstring called generateNilTags, but I can’t get it to work for me for nothing.

I’ve read everything I can in the Built-In Reference concerning this and still can’t get it to work. The field continues to show as and that xsi:nil attribute is a must.

Based on what I read, I checked and confirmed the following:

The document field is set to “allow nulls”

DocumentTypeName is being provided

both generateRequiredTags and generateNilTags are both set to True

Only thing left is me wondering if webMethods is seeing my field as truly being null. I think it is. True, the document field is being mapped to, but there’s no value. went to the top part of the document, set a blank value which I hoped is the equivalent of initialize the doc with nulls, but I do not really know.

Is there perhaps somethng out there whereas after all the mapping is done to the document, I can run something which would convert all blank fields to nulls? This is a little confusing. Is both and considered null?

If anyone has any advice on this, it would be greatly appreciated, even if it’s a workaround. I have just a few more days to get this done for the customer and am totally frustrated, as I am not very experienced with working with namespaces. I need to send that nil attribute. Thanks for your help.

2

An empty string is not the same as null/nil (though some systems treat them the same).

Drop the fields that are empty (or map to them only when the source field is not empty). That may end up creating the nil attribute as you desire, though I’m not sure.

3

Having a similar problem with a document with 4 optional fields, but the document itself is required.

When all the fields are empty, document to xml (in my opinion) correctly creates the document as <ns:MyElement xsi:nil=“true” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”/> when properties generateRequiredTags and generateNilTags are true.

However, the document when sent to the webservice either returns an error (field must exist) or if I manually set @xsi:nil = true, it incorrectly produces: <ns:MyElement xsi:nil=“true xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance””></ns:MyElement> in the SOAP message.

4

For these situations, the only reliable way we have found is to setup the document so Allow null=True and Required=True.

Then we run the documents through a Java service we wrote that removes the empty tags, trim if desired as well. Then run that output through the documentToXMLString service with the generateRequiredTags=True and generateNilTags=True.

5

garyl999, after creating the xml string, do you send it through a wsdl? If so, is it a unary or binary tag in soap?

I am finding that a). sending a document through a wsdl creates SOAP with binary tags instead of unary tags. And b). sending an xml string in the desired format, via http using createSoapData,addHeaderData and addBodyData - just removes the unary tag and replaced it with a binary one again.

6

After those services run we run an xmlStringToDocument and then handle as a document form there through mainly the pub.client:SoapClient service. However, we have used the other steps you mention as well in combination with the steps I described with the pub.client:soapHttp call.

I would check the version of IS and SP including Patches you are running. There were many attempts to correct this nil issue and the SP/patches changed behavior many times from patch to patch. We are on 7.1.2 with Core_Fix33, not the latest core fix but no time to patch the latest at this point.