Skip to Content

Running NetWeaver’s XSLT processor from XMLSpy


If you have ever written XSLT mappings with Java extensions, you may have found them difficult to test. You may even have tested them using XMLSpy and then found that they still would not run in XI due to subtle differences in the syntax of calling Java extensions. The easiest way to overcome this is by using NetWeaver’s own XSLT processor when testing transformations in XMLSpy.

Using sapxmltoolkit in XMLSpy

XMLSpy includes a fine XML processor of its own which even supports debugging. But it can also call an external program to perform transformations. This is configured via menu path Tools -> Options, moving to the XSL tab and selecting External XSL transformation program. This is what it looks like in my own XMLSpy 2004:


The path you specify is of the form:
[java_path]\java.exe -cp "[xmltoolkit_path]\sapxmltoolkit.jar";"[java_extensions_path]\[java_extension_jar]" -xsl=%3 -xml=%1 -out=%2

You will, of course, need to substitute your own values for [java_path], [xmltoolkit_path], [java_extensions_path] and [java_extension_jar]. The latter 2 are only relevant if you use Java extensions in your XSLT, in which case you must remember to include them on the classpath when calling SAP’s XSLT processor.

Where to find sapxmltoolkit.jar

This archive can be found under your J2EE engine installation path ...\j2ee\cluster\server0\bin\kernel\sapxmltoolkit.jar.


XMLSpy’s built-in XSLT processor supports step-by-step debugging. Unfortunately, this functionality does not extend to external tools like sapxmltoolkit.

You must be Logged on to comment or reply to a post.
    • Hi Sergio,

      Early on with XI 3.0 I did discover some bugs in SAPs implementation, but these have long since been fixed. I don’t think there are any significant differences. But it’s always nice to know that you are developing using the same tool that will be used at runtime.