Disable pretty printing when using pub.xml:documentToXMLString in webMethods

, ,
1

Hi,

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.

Thanks in advance!

1 Like
2

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.

-NP

1 Like
3

Hi Nagendra,

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.

Example for formatted:

<?xml version="1.0"?>
<catalog>
    <book id="bk101">
        <author>Gambardella, Matthew</author>
        <title>XML Developer's Guide</title>
        <genre>Computer</genre>
        <price>44.95</price>
        <publish_date>2000-10-01</publish_date>
        <description>An in-depth look at creating applicationswith XML.</description>
    </book>
</catalog>

Example for unformatted (desired result):

<?xml version="1.0"?><catalog><book id="bk101"><author>Gambardella, Matthew</author><title>XML Developer's Guide</title><genre>Computer</genre><price>44.95</price><publish_date>2000-10-01</publish_date><description>An in-depth look at creating applicationswith XML.</description></book></catalog>

I hope this makes sense. Thanks again!

4

This is nice to have but I not sure if this capability exists.

5

Does sound useful, tagging @Venkata_Kasi_Viswanath_Mugada1 , @John_Carter4 for any thoughts.

7

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?

KM

2 Likes
8

Thanks Kasi

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.

-NP

1 Like
9

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.

KM

1 Like
10

Thank you for your support. I will file a feature request as suggested. I think this will be a useful feature.

11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.