Hi, I’m a relative newbie with webMethods, but I know that this should be completely doable.
I have a flow service that is mapping an OAG canonical file. It has a mapping step that calls pub:dateTimeFormat to transform a date value.
The input string is specified as ‘yyyy-MM-dd HH:mm:ss.SSSS z’ (no quotes, natch.)
The output string is specified as ‘yyyyMMdd’.
The inString value in the pipeline is ‘2007-04-18 14:13:26.0131 -0500’.
And yet, no matter what I do, it is throwing an exception.
Now, here’s the bizarre part: if I define a string variable in the previous step and set the value to 2007-04-18 14:13:26.0131 -0500, and use that to input to the inString value in the signature, the transformer works.
So what on Earth could be wrong that it’s choking on the canonical, yet munching away on the string?
Can you show a screenshot of the assignments to the inputs of the dateTimeFormat service?
For the document from which you’re mapping the timestamp, is it a String? Sometimes, it appears that fields in a document are strings but they are really an object of some sort. Developer can add to the confusion by showing some objects in the results pane as strings. Thus a field looks like a perfectly acceptable string when debugging but at run-time its really an object of some sort, say a java.util.Date. Fields masquerading as strings that are actually java.lang.Boolean objects are another common ‘gotcha.’
OK, the screen shot is attached. I checked, and the data element that I’m using as the input is most certainly a String.
Another developer here has the same issue, so we’re thinking that Something Bad has happened to the (remote) development IS. We are taking it up with the custodians of that server.
Bear with me for a bit. Can you show what the document looks like at run-time?
While the design-time definition indicates a string, it’s possible that it is something else at run-time. How is docAdvanceShipNotice being created in the pipeline? Is it the result of a web service RPC call? The IS doc type may have been created as a String when importing the WSDL or XSD, but the content-type of the field is possibly causing the RPC handler to convert the timestamp to a java.util.Date object.
Given that the service works when given explicit inputs, I doubt that “Something Bad” has happened to the server. I still suspect that the run-time representation of the data is not as you expect it to be. But I may be wrong…
docAdvanceShipNotice is created by a companion service that I wrote that converts from an IDoc to a canonical. I’ll have to run the service to see what the runtime looks like. Not sure how you want to see the data; pipeline file or something else? Like I said, I’m kind of a newbie, especially to debugging webMethods code.
I’ll do it tomorrow; it’s way past going home time now. Thanks.
To verify that you actually dealing with String rather than some Timestamp or Date object all you need to do is run this fow in Developer adn before executing tranformer map step open this document and check the feild Icon. NOrmally in Developer 6.1, 6.5 if document field is a string it shows small icon [ABC]. But if it is a Date then you will see some Clock/Calendar icon next to your field name. NOTE that in both cases Developer may show correct String represenattion of your Date string so looking at data you may not tell. That should give you some way to investigate further.
OK, here’s the attachment showing the canonical in the pipeline. I’m trying to map the field os: DATETIMEANY right in the center of the pipeline display.
We’re kind of stuck here, but we welcome any input. screenshot2.doc (85.5 KB)
Update - if I take the field and copy it to a string field, then run the service against this field, it works. It’s a workaround, but we’re going to research further.
Looking at the screenshot, it seems like an issue with the xml namespace assosiated with your field “os:DATETIMEANY”. When the field has xml namespace with prefix, it has the datatype defined in somewhere at the location where the field prefix points to. Do you know what is the namespace for the prefix ‘os’ and where is the schema in which this particular field is defined ?
Why would the namespace part of the name be an issue at this point in the processing? After the XML doc is converted to an IS doc, the namespace and name prefix are meaningless. Those are applicable only when the XML doc is being converted to an IS doc. After the conversion, and by the time of this screenshot, the field is simply a field with a colon in the name and isn’t treated differently than any other field.