I am getting the following error:
<soap-env:body>
<pathname>/RFQ:RFQResponse/RFQLINES/INT_RFQLINE_TYP[0]/CONVERSION</pathname>
<errorcode>DT-001</errorcode>
<errormessage>[B2BCORE.0082.9447] Value does not conform to datatype</errormessage></soap-env:body>
</soap-env:envelope>
Conversion is setup to NOT be required. It is of String type, is not required at run-time (box not checked) and has a content type of decimal specified.
If a decimal value is present the validation works. If the value is null:
<conversion></conversion>
I get the above error. Any ideas why this would be the case?
In my flow I map the fields of my canonical document (fields are optional on the canonical) to the webService connector input (the fields are also marked optional on the webService connector input document).
when there is no field present in the canonical, the corresponding field value for the webService connector input document contains ‘null’ value inside it.
when I look in the SOAP message that is generated by the connector, The field is represented as .
Because of this we get a error message from the webLogic server
I think webMethods assign a empty value instead of null for the optional fields.
Is there any way to make the webMethods generate a null
() instead of empty (). This would make the webLogic deserialize it as ‘null’ rather than empty(‘’).
Please check if your webserviceConnection input documentReference is letting field () when it mapped from null fields.
And i see this behaviour only if the fields are mandatory in the schema which documentToXMLString will show the empty open and close tags even if the value is null/empty.
Are you using documentToXMLString and posting this xmldata to a webservice?
When I Look in the properties of the webservice input document, created while we create the webService connector, the properties for the ‘Order’ field shows ‘Allow nulls’ set to ‘false’
I am Using SOAP RPC method to invoke the webService. If i look inside the connector flow service It uses ‘documentToXMLString’ and the xml data is converted to SOAP format and posted to webService.
When I look at the xmlstring generated during debug the ‘order’ field is set as instead of .
If I do a field to field mapping from my cannonical to the webservice Input document, and the canonical does not have the ‘order’ field (as it is optional) then in the xml string created has the
If I do the Document to Document mapping then, when the field is absent on the cannonical side no entry is created in the xml string.
It Looks like when field to field mapping is done, for missing fields the input document to webservice gets ‘null’ inside it and during the 'documentToXMLString ’ mapping it creates the entry for the field as .
I bet documenToXMLString behaves based on the schema mandatory element even if it is null the field tags should show in the output as per the documentTypeName.
Please check the documenttype signature it might be the root cause.
In my case the ‘documenToXMLString’ takes the document that has the ‘null’ values in the fields and produces a xml string with the element as
…
What I am expecting is if there is a null value it should create the xml element as …
This is my requirement, may be it not the case as webMethods does…
… The webservice input document types actually has all the fields as optional…
So when I do a field to field map from internal canonical document to web service input document… then these ‘null’ are introduced in the webservice input document,for the corresponding fields that are not present on the canonical doc(as fields may be optional)…
So what i think is if there is some work around to somehow restrict not to pass ‘null’ … then the documenToXMLString would not generate any empty tags…
If the value in field is ‘null’ then the documenToXMLString creates the empty tags ()… even though the fields on the weservice input document are marked optional…
May be I am not completely correct… But this is what it looks for me from debugging point of view…
Before you map documentToXMLSting,do you see the null value being mapped to the document in the pipeline.If yes put a conditional mapping for the order field to not exist in the document with null or empty tag.
Strange that that is a “requirement” since semantically and mean exactly the same thing.
AFAIK, the style of an empty tag is not doable out of the box. You’d need to resort to custom facilities of some sort, which would be of questionable value.