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 ). In some cases even the XSL-FO file can be 'static' (created outside of the ZEN Reports framework). 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.

ZEN Reports calls out to a 3 rd party rendering engine (like Apache FOP) to generate the final PDF document from the XSL-FO file.

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).

From your ReportDisplay XData block a temporary XSLT file is created, which describes how to transform your data into a document.

From your ReportDefinition XData block a temporary XML file is created, containing your data.

The default (and simplified) way of generating a PDF document with ZEN Reports is this: Is it possible though to ensure thread-safety under certain circumstances, and this is what the Render Server delivers.

And thread-safety is a cardinal question, as FOP doesn't claim itself completely thread-safe. 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. 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. The HotJVM Render Server is a great way of boosting ZEN Reports performance, when it comes to generating PDF documents. This article is little explanation to a GitGub project.

Xsl fo pdf