The article makes an attempt to demonstrate that Atelier is not just repeating the functionality of Caché Studio on a new IDE platform (Eclipse) but goes far beyond. Due to my personal experience, and challenges in former projects I picked first XSLT Debugging. Is it an ordinary task? Not at all. Who is doing XSLT every day? Probably none of us. Than why XSLT Debugging? Simply because there are solutions in our product portfolio which are using XSLT inside and those solutions require customization. Customizing XSLT without some sort of toolkit is more than challenging. The examples of such solutions starts with HealthShare IHE message, CDA vs. SDA transformations, goes through ZEN Reports, and ends by HealthShare CDA document viewer. Is that enough reason to spend time reading the whole article through not just the teaser?

You made the right decision… First of all, I want to make it clear. All features and functions documented in this article are delivered by third party Eclipse plug-in. That plug-in is available to any Eclipse based IDE not only to Atelier. Furthermore, even if the article tries to describe the use of the plug-in from a Caché developer point of view, the plug-in is not designed for Caché developers, thus it works identically in other Eclipse based IDEs.

So why XSLT Debugging such a big deal? Programmers usually try to avoid using XSLT because of some ugly feature of XSLT programming. One of the main critics is that testing/ debugging of a transformation was (is) kind of nightmare unless you had (have) a very good XSLT tool. So it is the time to discover what we have with Eclipse, and speed up/ ease some activities. Activities like:

n  Maintaining transformation used by HealthShare.

n  Creating, maintaining ZEN Reports display block.

n  Maintaining default document viewer for HealthShare.

Installation

XSLT Debugging is delivered by the “Eclipse XSL Developer Tools” classic plug-in. It requires the “Eclipse XML Editors and Tools” classic plug-in. After completing the installation you should set the default XSL processor to Xalan at “Preferences/ XML/ XSL/ Java processors”.

First step

The use of the Eclipse XSL Developer Tools is very easy. You need to have an XML file to transform from and an XSL file to transform by. You need to have them in your local workspace. Then you can edit those files. When you are in XSL Editor you have several extensions to a text editor.

First of all the editor “knows XSL syntax”.

On right click anywhere in the editor pane a context menu is popping up. It contains XSL specific entries like “Run as”, “Debug as”, “Profile as” and “Validate”. I think the menu points are self-explaining. Once the debugger is activated, Eclipse switches to Debugger perspective. After leaving the debug session you might want to return to Atelier default perspective. You can do it by switching perspective.

Placing break point is as easy as you expect. Run, step in, step over, resume? Watching variable value in a view? All those are available.

I think there is not much to add. It just works.

Debugging Caché/ Ensemble/ HealthShare resources

When the XSL transformation is a static resource (a file), then the debugging is straightforward. Add the XSL file and a sample XML to your Atelier project, and you are ready to debug. Any changes made to the XSL file is synchronized to the server.

But how about ZEN Reports? Both the XSL transformation file and the XML data file are temporary. You need to force the ZEN Reports run-time to publish those intermediate files. You can control it by the $MODE URL query parameter of the report class.

There are two major issues with any report. Is the contents as expected? Is it displayed in the right format? Debugging XSLT can help you to fix issues of the first type. The second type is rather related to XSL-FO which is yet another area of interest. To keep the task easy, I recommend the following.

n  Generate HTML output of the report. It allows you to focus on the data contents rather than interpreting FO.

n  Create two intermediate files: the XML holding the data ($MODE parameter is “xml”), and the XSL transforming the XML to HTML ($MODE parameter is “tohtml”). The intermediate files created at run-time.

n  Download the files in your local file system.

n  Import the intermediate files to an Atelier project by simply dragging the files from the file system to a folder of Atelier.

n  After finishing with the XSL debugger, please do not forget to delete the intermediate files from the project.

 Downloading the intermediate files could be different OS by OS. The less trivial (at least to me) is under Windows. Please find the way I do using Windows PowerShell. Please remember that the command lines below are invoking one standard report from the SAMPLES namespace. The Caché instance using 57780 as Web Server port. You might have something else.

$client = new-object System.Net.WebClient

$client.DownloadFile("http://localhost:57780/csp/samples/ZENApp.MyReport.cls?%24MODE=tohtml&MONTH=2","MyReport.xsl")

$client.DownloadFile("http://localhost:57780/csp/samples/ZENApp.MyReport.cls?%24MODE=xml&MONTH=2","MyReport.xml")

Under UNIX, Linux, OSX you’ve better to use curl or wget.

What kind of errors can you find by debugging? The most common are misspelling, confusing attribute and element, misuse of XPath functions, lost in XML hierarchy (that is report groups).

Epilogue

I hope that you will remember the article next time you have to fix a bug in a message/ document transformation or in a ZEN Report. And I also hope that with this knowledge you will save more time than what you spent on reading and trying out.

Happy XSL debugging.