This article is little explanation to a GitGub project.
The HotJVM Render Server is a great way of boosting ZEN Reports performance, when it comes to generating PDF documents. It can spare a second or more even on a single execution of a report, but it becomes unavoidable when you have to generate hundreds or thousands (or maybe hundreds of thousands) of reports.
If you don't want to go through the documentation above: the Render Server comes with InterSystems Caché and Ensemble and makes it possible to use FOP in a multi-threaded and yet a thread-safe way. And thread-safety is a cardinal question, as FOP doesn't claim itself completely thread-safe. Is it possible though to ensure thread-safety under certain circumstances, and this is what the Render Server delivers.
The default (and simplified) way of generating a PDF document with ZEN Reports is this:
- From your ReportDefinition XData block a temporary XML file is created, containing your data.
- From your ReportDisplay XData block a temporary XSLT file is created, which describes how to transform your data into a document.
- ZEN Reports applies the XSLT to the XML file, creating an XSL-FO document, which is basically the XML representation of the PDF, which you want to generate (already containing your data, too).
- ZEN Reports calls out to a 3rd party rendering engine (like Apache FOP) to generate the final PDF document from the XSL-FO file.
This is just the default, which you can vary: some parts of or the entire XML can come from different sources (method, other report, stream), and the same is true for the XSLT.
In some cases even the XSL-FO file can be "static" (created outside of the ZEN Reports framework). This can be advantageous when- for example- your XSL-FO contains big chunks of SVG or for whatever other reason it easier to create the FO file on your own, than with ZEN Reports (yes, this can happen ).
The only problem is that however technically possible to create a PDF from an FO file directly in the ZEN Reports framework, the Render Server option is ignored in this case. Which is a pity!
At the same time: it is not too hard to solve this with a little trick and by using a special ZEN Reports class as a wrapper for your XSL-FO document. And before you would run to
Studio Ateliér to implement this on your own, please check out this GitGub project first.