IBM Business Process Manager ships with the system data toolkit where you can find a number of useful Java connectors including a few XSL connectors. Those XSL connectors are:
- Transform XML Document to Document using XSL Document
- Transform XML Document to document using XSL File
- Transform XML Document using XSL Document
- Transform XML Document using XSL File
- Transform XML file to Document using XSL file
- Transform XML file using XSL file
In this blog post, I will review these stock connectors from a performance efficiency standpoint.
System data XSL connectors using Java-based IBM XSLT processor
The IBM XSLT processor has two modes: Interpreter and Compiler. Interpreter is used by default, and, in some cases, it might be more expensive than the Compiler mode. Unfortunately, there is no way to switch the mode for the transformation in the system data toolkit. However, you can always write your own connector for your transformation. You can test both modes using the command line to see which one performs best for you. Here are some examples:
WAS_APP_SERVER\bin> executeXSLT.bat -outputfile d:\temp\result.xml -input d:\temp\rawdata01B.xml d:\temp\test.xsl
WAS_APP_SERVER\bin > executeXSLT.bat -outputfile d:\temp\result.xml -useCompiler -input d:\temp\rawdata01B.xml d:\temp\test.xsl
- The number of instances that you run in parallel to do the transformation
- The size of the XML file
- The number of users doing the transform
If you find out that the stock XSL connector does not perform as you would expect, then consider the following options:
Use the XSLT processor compiler mode (non-default) as shown in the previous example and see if it performs better for you. If it works better, write your own connector that uses the compiler mode instead of interpreter mode.
- Write a custom connector that uses a third-party XSLT processor like Saxon. You might want to consider using Saxon when, or if, your XSL template is too large (with over 10000 lines in a single template). This size exceeds the Java method limit, which does not make pre-compilation possible. Or, consider using a a third-party XSLT processor if you have an atypical usage pattern in the sense that you generate the XSL template dynamically, and then run it only once. The IBM XSL engine is designed with the assumption that a user will pre-compile the template first as part of the initial setup and then run the templates multiple times. If the template is only run once, the time it took to prepare and compile the template will make the overall time much longer than Saxon.
Sergii Malynovskyi, who is based Kyiv, Ukraine, is a Team Lead for the WebSphere Lombardi Edition and IBM Business Process Manager Level 2 Support Team.
We encourage you to leave feedback on this article below.