You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using suds to communicate with our Polarion Server to read/write Polarion Work Items (Work Item: Polarion object).
The Work Item data structure contains a custom field which is of type "ArrayOfCustom".
This array contains elements of type "Custom" as shown below:
For "Custom.value", no type is defined as it can be different for each custom field entry.
This was no problem so far as the types used for "value" were strings or enums.
Now, I added the custom field "lastTestRunDatetime" of type "xsd:dateTime".
When I read the Work Item form the server, I get the following SOAP data transfer:
i.e the value for "lastTestRunDatetime" changed from
"2021-04-07T09:00:00.000Z"
to
"2021-04-07 09:00:00+00:00".
which results in the server error "java.lang.NumberFormatException: Invalid date" (The " " instead of "T" is causing this error).
As this works for other fields that have the "xsd:dateTime" in the WSDL description, I did a bit of debugging:
As value has no type specified in the WSDL description, the lastTestRunDatetime value is serialized via the regular Python data type "dateTime.dateTime" string conversion. For fields that are specified as "xsd:dateTime", the data type "suds.sax.date.Datetime" is used for the string conversion which calls .isoformat() to do the string conversion.
Is there a way to change this behavior at application level, e.g. by setting the type for value from "xsd:anyType" to "xsd:dateTime"?
If not, what would be the best way to patch the suds library? After a bit of debugging, I see the following possibility:
Patch class Xany (in sxbuiltin.py):
Add a translate() method which does the XDateTime() processing in case "isinstance(value, datetime.datetime)".
But this looks like a brute force approach. I would rather prefer to change the "type determination" when node "lastTestRunDatetime" is processed.
Any ideas how to solve this in a clean way without breaking other suds based applications?
Regards,
Oliver
The text was updated successfully, but these errors were encountered:
Short update: I just tried this with zeep. It handles this without problem. It looks it has a more advanced "xsd:anyType" handling. Probably time to switch to zeep....
Hi,
I am using suds to communicate with our Polarion Server to read/write Polarion Work Items (Work Item: Polarion object).
The Work Item data structure contains a custom field which is of type "ArrayOfCustom".
This array contains elements of type "Custom" as shown below:
For "Custom.value", no type is defined as it can be different for each custom field entry.
This was no problem so far as the types used for "value" were strings or enums.
Now, I added the custom field "lastTestRunDatetime" of type "xsd:dateTime".
When I read the Work Item form the server, I get the following SOAP data transfer:
i.e. the value for "lastTestRunDatetime" is transfered in the "xsd:dateTime" format.
Sending the same data back to the server, results in following SOAP data transfer:
i.e the value for "lastTestRunDatetime" changed from
"2021-04-07T09:00:00.000Z"
to
"2021-04-07 09:00:00+00:00".
which results in the server error "java.lang.NumberFormatException: Invalid date" (The " " instead of "T" is causing this error).
As this works for other fields that have the "xsd:dateTime" in the WSDL description, I did a bit of debugging:
As value has no type specified in the WSDL description, the lastTestRunDatetime value is serialized via the regular Python data type "dateTime.dateTime" string conversion. For fields that are specified as "xsd:dateTime", the data type "suds.sax.date.Datetime" is used for the string conversion which calls .isoformat() to do the string conversion.
Is there a way to change this behavior at application level, e.g. by setting the type for value from "xsd:anyType" to "xsd:dateTime"?
If not, what would be the best way to patch the suds library? After a bit of debugging, I see the following possibility:
Add a translate() method which does the XDateTime() processing in case "isinstance(value, datetime.datetime)".
But this looks like a brute force approach. I would rather prefer to change the "type determination" when node "lastTestRunDatetime" is processed.
Any ideas how to solve this in a clean way without breaking other suds based applications?
Regards,
Oliver
The text was updated successfully, but these errors were encountered: