This page covers aspects and considerations regarding the installation of Report Formatters and Print Agents used to format and print operational reports that use Report Designer layouts. Towards the end of this section, there is also a shorter section covering some important multi-site aspects. The Report Formatter is the server side process responsible processing/formatting print jobs using Report Designer layouts. Technically a Report Formatter is a background job in IFS Connect. This means it's a multi-threaded component executing inside a J2EE container, IFS Extended Server. The Print Agents handles the specific task of printing the reports formatted by the Report Formatter. This is a stand-alone component deployed on the same, or on a separate server, as the Report Formatter. Both the Report Formatter and the Print Agent can be set up in several instances for one single environment.
This page describes important considerations necessary to take into account when setting up such an environment. We'll deal with load balancing, redundancy, fail-over, printing to remote printers over WAN, increasing the formatting/rendering capacity (ability to process print jobs and create PDF documents by adding hardware) and so on.
The picture below shows an overview of the architecture. The middle tier is where the Report Formatter(s) reside. The Report Formatter will fetch print jobs and report data from the storage tier and process/render these print jobs into PDF documents. These documents are stored in the database and used to both preview and print the report. The actual printing of the formatted PDF document is handled by the Print Agent. The reason for separating these steps is that the printer(s) might be located on a different LAN (local area network) connected to the central LAN through a WAN (wide area network) connection. The spool jobs sent to the printer(s) are significantly larger than the PDF document(s), so this is a performance optimization that reduces the network load. The other reason for moving the printing outside the J2EE application server is that the printing is a native task (non Java) and as such it could render the J2EE application server unstable if terminated unexpectedly. In a production environment there should always be at least one separate Print Agent installed.
The above picture also shows that we can have several Report Formatters on the same application server as well as on different application servers. These application servers can reside on multiple physical servers, making the Report Formatter very scalable. Furthermore, each Report Formatter executes in a configurable number of threads making it possible to process several print jobs simultaneously.
In a minimal installation there is one single Extended Server installation (J2EE application server), running one or several Report Formatters. The same J2EE application server used for the rest of the application is also used for the Report Formatter. A Print Agent is installed on the same or a separate machine as the application server.
The Report Formatter polls the print queue for print jobs, fetches the report data, applies the layout and produces the formatted PDF document. This document is stored in the database and used for both previewing and printing. When the document is printed, it's fetched from the database by the Print Agent and printed/spooled to the printer. For additional information about the Report Formatter, the Print Agent and Info Services in general, please refer to the links section above.
This basic/minimal installation also serves as a starting point for a larger installation as it can be expanded to deal with load balancing, redundancy/fail-over and sites/printers connected through a WAN. The sections below describe how to expand the installation/environment to address these type of scenarios/issues.
Formatting reports can be quite resource intensive (CPU and memory) when printing large reports or a large amount of smaller reports. Most production environments need to be scaled up a bit compared to the minimal production environment described above. The following sections describe a number of scale-up options and how to deal with different performance and scaling options.
All report processing is done in the Integration (INT) node of the middleware server. The only way to scale this is now by clustering of servers. Simply add a new node to the INT-cluster and you will have more processing power available for reporting.
A Report Formatter is technically implemented as a background job in IFS Connect. Cuncurreny of print jobs is controlled by the queue that handles these background jobs. The printjob queue is set to handle multiple job at tthe time by default. There is no way to configure the presice number of reports that can be formatted simultaneously by one singe Report Formatter. This is handled by the internal threading settings for the applicaitonserver. However you can configure a queue to act in a single or multithreaded way.
In the same way as dealing with load balancing, setting up multiple instances of Report Formatters on different nodes (clustering) is a way to achieve redundancy and fail-over. Several Report Formatters and/or Print Agents running on separate hardware will make printing operations less vulnerable if for instance one server goes down.
In a multi site scenario where the different sites are connected through a wide are network (WAN), the key factor to minimizing the network load and maximizing the performance is to make sure to set up the the Print Agents close to the printers (i.e. on the same LAN). The schematic below shows how this could be setup in a scenario where the central environment is located in UK, but there are operations in both the US and China.
The Report Formatters should still be kept centrally since they interact heavily with the database. But since it's far more effective to send a PDF document over the WAN compared to spooling the print job the Print Agents should be installed on site.
For the Report Formatter and Print Agent there aren't really any Unicode considerations, it's fully Unicode compatible. One needs to set up several Report Formatters in order for dates and numbers to get formatted correctly depending on the locale and the font used. The layouts need to contain the glyphs/characters used but otherwise there's nothing strange about running this in a Unicode environment.
For an overview as well as some in-depth information about the different concepts and components referred to on this page, please have a look at the following links.