Hello,
We receive the following exception in our integration script while performing GetParametersForElement() on some DMS elements.
The root cause are those characters in the XML response:
Those characters are not valid XML and cause an exception on the Java library on which we don’t have much control. In my opinion, Dataminer should sanitize those characters on the API layer.
Can you do something on your side to filter out those characters in the XML response?
Thank you.
Regards,
Simone
Hi Simone,
This is indeed likely a software issue, I think it's best to create a software issue task for us (possibly through your Skyline contact).
A possible workaround may be to use the JSON API instead of the Soap API. For more information see the web services API reference.
Might also be worth investigating how these null characters end-up in the value of this parameter, which gets stored in the database and might give issues in various places of DataMiner. I think the protocol should have trimmed the value before setting it on the parameter, or there might be an encoding issue.
Hi Jens and Wim
This is for a serial device/protocol and specifically for a parameter with a fixed length of 16. The param value is f.e. “DEVICE”, so less than 16.
So for me it’s logical that a param with a fixed 16 chars would return 16 chars. Please let me know if this is still a SW issue.
+ the param isn’t stored in db.
At the very least, the API should return valid XML
Filling it up with null characters seems like a hacky way to avoid the fixed length.
If it is needed for a device (or serial communication) then I think the protocol should add/remove null characters as needed when sending/receiving values of the device, but these null characters shouldn’t be stored in the DataMiner parameter.
It’s not just null characters, several other characters are not valid in XML 1.0 standard (almost everything below 0x20, see https://www.w3.org/TR/REC-xml/#charsets). Note that these characters might not always be at the end of the string, they could also be in the middle. So a simple trim() won’t fix this. We could just remove them, or replace them (question is then with what), but this might be completely unexpected. Especially when doing a parameter set with a received value from the API, then the parameter value gets changed unexpectedly.
So I think the API should return the value as-is. The JSON and SOAP API share the same code base, and there is no issue with the JSON API. The SOAP API is generated by Microsoft .NET, and Microsoft also chose to keep the value as-is.
Don’t use the SOAP API on parameters containing characters which can not be stored in XML 1.0. So either: use the JSON API, or avoid the invalid characters to be in the parameter, or as a hacky workaround you could remove them yourself from the received SOAP message before deserializing it.
Hi Jens,
Thanks for the answer. I’m going to ask the support team to open a ticket.