we are using webMethods 10.3 and have one interface for which we are generating XML-messages which are then forwarded to another system. To generate the messages we convert the documents using pub.xml:documentToXMLString.
Ideally, we would like to send the messages as unformatted XML-strings to reduce the message size. However, as far as I understand, this service does not offer any possibility to disable pretty printing.
Does anybody know if it is possible to generate unformatted XML-strings from webMethods Documents? Doing a string-replace or any other kind of string manipulation afterwards is not an option due to performance reasons.
I saw an old thread from 2007 where someone asked the same question but there was no real solution mentioned.
Hi @pmk ,
Can you elaborate more about what you mean by unformatted XML-strings? Can you provide some examples of what are you looking for? Are you looking to not have the carriage return, line feed characters or are there more characters that can be avoided? These two characters may not make up a significant percentage of the XML.
You can also share the old thread for more context.
thanks for reaching out. When talking about unformatted XML-strings, I mean no carriage returns or indentation. In our case, the XML-structure includes several levels of nesting meaning that there will be a lot of whitespace due to indentation.
Message size increase should be less than negligible for newline (2 bytes) and whitespace characters. It may become considerable, in the range of Giga-sized messages but it should still be negligible in context, since we’re dealing with a Giga message anyway.
I say “should” because I admit I haven’t explicitly compared the sizes. Do check this out first if you haven’t done this already, @pmk. I’ll give this a check in the morning.
Having said that, I’ve used pretty-print feature for JSON on IS, but it’s unavailable for XML at present.
I don’t suppose there’s any Java method to remove pretty-print, but the question is - is the Java invocation overhead on every single message, worthwhile?
I think not - remember, it’s so easy to over-engineer performance aspects and lose the battle against return on investment, just like how you were opposed to using string manipulation (and rightly so).
Can we introduce a pretty-print flag and/or server property for XML as well, @John_Carter4?
A couple of thoughts ,
Removing whitespaces from an XML seems desirable for large documents only , there should be a size threshold after which the advantage is apparent.
An alternate perspective - Second iteration might not be so bad after all. Is there a data size large enough such that the time lost in running the XML through a formatter for removing whitespace , will be regained because it will take less time to transmit. This should be an interesting set of tests to run.
If we are going this way, I would be in favor of flag as in input to the service over a server property , since it would give greater control on which documents wouldn’t have pretty print and wouldn’t do it for every document.
I did a small test, NP - the whitespaces are not negligible and are adding up, so I stand corrected.
As for the server property vs service flag, both will be required - a default setting set at the server-level, with an override option in the service-level. This is how it is for JSON. Let’s see what @John_Carter4 says about introducing this feature for XMLs.
@pmk, do submit a feature request on Aha! via Empower portal.