I am coming from a more java-centric development world where XSLT was the norm for XML transformation. There are tools for debugging XSLT transformations. XSLT is fairly easy to read and works well with a version control system in terms of diffs and merging.

The webMethods flow language offers non of that. I have had difficulty maintaining it. I have had problems finding where variables are set and whether there are map steps that will overwrite them. It is harder to see what is going on with the bird’s nest of lines running back and forth making connections. I have been unable to use standard conditional syntax in order to express the logic. Most of all, I have not seen a good way to do diffs on the code, branch it in a version control system, or merge those branches back to the main code.

I am leaning toward using XSLT within webMethods. Is that a bad idea?

Hi David,

which variant to use (Flow vs. XSLT Transformation) depends on several factors.

Please check out for the WmXSLT package for XSLT Transformations (services are described in the IS Built-In-Services Reference).

From webMethods 9.12 onwards it is possbible to Local Service Development within Designer which allows access to version control systems via Eclipse Plugins.
Additionally Designer 9.12 also offers a Flow Service Diff Tool.

For Flow Services you might want to check the “Working with Designer” and “Service Development Guide”.

Regards,
Holger

I’d say yes, it’s a bad idea. In some rare cases, XSLT might be the right tool. This would e.g. be the case if you have an XML document (string) that you want to transform into another XML document (string) using some easy rules. Then I wouldn’t transform it to documents, do the transformation, and transform back to XML. Doing a direct XSL is easier in this case.

But as a general engine for data transformation, I’d prefer the flow language anytime. It’s built in into wM, it’s natural there. Flow is a general purpose programming language while XSLT is not. General programming in XSLT is a pane.

You are right that flow code is not easy to diff and to merge. This is a major drawback, and I fail to understand why the flow code isn’t stored in some “predictable” way so that small changes in the code result in small changes in the flow.xml file.

But even then, if you have coding discipline, some coding rules, and maybe some assisting tools (SCA, unit tests, etc.), it’s quite possible to do programming with flow code at a modern level of software engineering.

It’s just so that the vendor does not provide the tools to do all of this, and many companies (including the one I work for) have created their own tools and methods. Which they don’t share with the world for some obvious reasons. There is no such worldwide community like e.g. for Java.