I’ve run into an issue with some code written way back in webMethods 2.x using WIDLs (recently removed from webMethods support), hopefully I can find some help here:
When running an XML document through the WIDL transformation, whitespace within text elements are being trimmed, where for example, if there’s 4 concurrent whitespace characters, the resulting text element will have 1 whitespace character.
Has anybody here been able to work around this behaviour (short of migrating to flows)?
What is the exact query that you are executing?
It would be a WQL query, which is still supported in the pub QueryDocument service. In the case of attributes, I believe special trimming whitespace rules are specified in some XML spec. If you are requesting data within an element is it a mixed data element? ie. are there child elements and multiple text parts within the element you are querying?
Eric,
I knew of WIDL way back when, but never got to use it. Anyway, it sounds like your issue may have more to do with the XML spec (as Fred suggests) than with WIDL. By default, XML parsers compress whitespace (in compliance with the specification), resulting in the behavior you described. Try adding the attribute declaration “xml:space=preserve” to the element(s) in question and see if that helps.
Hi guys, thanks for the responses. The query is this:
GET_PARTNERINF[0].PARTNERINF[0].PARTNER.PARTNRTYPE[‘CUSTOMER’].^.PARTNRIDX[0].TEXT
The element is not a mixed data element. Querying the document elements in flows using wql and xql was not a problem, but migrating the problematic code to flows is not an option I have available.
I just now tried the ‘xml:space=preserve’ suggestion, but I still ended up with the same trimmed result.
The whitespace is being trimmed even when the data element is enclosed in a CDATA tag, is this proper behaviour? For example, an encoded or cdata enclosed string of ‘ABCD[sp][sp][sp][sp]1234’ would result in ‘ABCD[sp]1234’.
I ended up writing a hack that first parses the the source document, encodes any multispace characters as escape characters, run the document through the WIDL mapper, then decode the escape characters back to space characters. Not pretty nor efficient, but it’s working now.
There are a couple other query options that return the selected data is a variety of formats.
rather than .TEXT, try these:
.SRC
.CSRC
.ETEXT
One might return something more easily hackable.
HTH,
Fred
I tried them out, the .SRC/.CSRC kept the whitespace but gave me element tags:
[lt]PARTNRIDX[gt]ABCD[sp][sp][sp][sp]1234[lt]/PARTNRIDX[gt]
And the .ETEXT gave me the same trimmed result as .TEXT:
ABCD[sp]1234
Oddly enough, while testing I noticed that while the middle spacing was being trimmed, the outside spacing is not.
Anyways, thanks fred. I’ll just leave my current hack in place, it works until I can replace the code with newer technologies.
Eric