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. For convenience there's a Print Agent built into the Report Formatter, but this is only for demo and development purposes. 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.
For convenience there's a Print Agent built into the Report Formatter. In a development or demo scenario an environment can be set up where the Report Formatter handles both the formatting an the printing. In a production environment this is not a recommended setup. This kind of setup doesn't handle printers connected to the corporate server network through a WAN connection. Furthermore, the nature of the native printing process can render the J2EE application server unstable in certain circumstances (as always when mixing native code with Java). For this reason, the installation scenario depicted below should not be used in a production environment. For a production environment, one or several Print Agents are recommended.
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.
The central application server often running IFS Web Client, IFS Connect, BixAPI's and more can be offloaded from the report formatting task by installing the Report Formatter in a separate J2EE container (i.e. a separate application server on a different or the same physical machine as the central application server). If using a separate server the load will will be distributed over two machines rather than one. If installing the second application server on the same physical machine, the total load on the server will not decrease but since each application server instance allocates it's own memory this can still be beneficial. As a scale-up option it's obviously better to add another physical server than installing a second application server on the same machine as the first one.
In order to enable parallel processing of print jobs, the number of threads in which a certain Report Formatter executes needs to be configured. A Report Formatter is technically implemented as a background job in IFS Connect. The way to configure the number of reports that can be formatted simultaneously by one singe Report Formatter is to configure the number of threads of the queue in which it executes. If several background jobs and/or Report Formatters share the same queue the number of threads will be shared. The easiest way to control this is to make sure each Report Formatter executes in it's own queue. This is all controlled by managing what queue the background job / Report Formatter is executed by and setting the number of maximum processes for that queue, as shown below.
In the above sample only one thread is used in by the batch2 queue, which is the queue used by the Report Formatter. This means that there will be no parallel processing of print jobs for this particular Report Formatter, it's single threaded. Increasing the number of threads to for instance 4 would mean that 4 reports can be formatted simultaneously by this Report Formatter. If creating and using new queues for newly added Report Formatters, one must not forget to add those queues to a Batch Server. Otherwise they will never be triggered.
The ability to set up multiple Report Formatters on multiple servers and have them execute in any number of threads makes the Report Formatter very scalable.
In the same way as dealing with load balancing, setting up multiple instances of Report Formatters on different servers 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.