Skip to content

Report Print Task Templates

Report Print Task Template contain configuration data that is used by the Reporting framework when creating new * Report Application Messages* for report rendering jobs.

##Content - Overview - Configure Report Print Task Templates - Report Formatter Configuration - Queue Management


Report print job processing operations are handled using these task templates. These templates are used on creation of new Report Application Messages when new Print Jobs are created. The new created Report Application Messages are processed directly by the Report Batch Processor.

By default the installation will create one template for print jobs.

Configure Report Print Task Templates

    All jobs are handled equally regardless of queue. The queue is only used for categorizing. DEFAULT queue can always be used if no categorizing is needed.
    Locale used for the Report Application Message execution. Default is set to English(United States).
    Locale used by the Report Formatter.
    Default language used by the Report Formatter.
    List of mappings between logical and physical printers. All available logical printers are shown in a drop-down list.
    Determines to which extent the information should be written in the debug file.

Report Formatter Configuration

Report Formatters are actually just an instance of a Report Print Task Template holding information about the mapped Logical Printers, locale etc.
Read more about the Report Formatter concept.

Report Formatters are typically named something like Processing Print Jobs, and set up to use a separate queue. They could be called anything though. You can have many Report Formatter templates which are mapped different Logical Printers, locales etc.

The Instance Type Specific Parameters and Printers sections are where printers are managed and default locale and language options are set.

The Logical Printers listed in the configuration determines what print jobs the Report Formatter template will process. In a production environment there's no need to map Logical Printers to physical printers in the Report Formatter configuration, this is done in the Print Agent configuration. The ability to map to physical printers in the Report Formatter template configuration is purely a demo/test/development feature where it's possible to run without a Print Agent - this is not supported in production however. When adding Logical Printers bare in mind that two Report Formatter template should normally not be set up to serve the same Logical Printer, but several Logical Printers might very well be mapped to the same physical printer. Physical network printers are referred to using the UNC path, \<server name>\<printer name>. They are mostly used with Zebra Printers and printer plugins, since direct spooling is not possible, the physical printer configuration is instead placed in the configuration of the Print Agent.

When language and locale isn't specified in the print job, the Default Language and Locale values specified for the Report Formatter template are used. This affects things like date and number format. In many, but not all cases, this information if part of the request and the default values are not used.

Queue Management

It is possible to setup any number of Report Formatters and when doing so it's preferred to run them in separate message queues, since that gives the best control and high flexibility. It's easy to create more queues if setting up more Report Formatters templates. Refer to Create/Edit and Delete Message Queues for more details on how to do this. A message queue has a execution mode parameter that determines how many jobs it can process in parallel. In order to have a Report Formatter process jobs in a single thread (i.e. in sequence) this parameter should be set to InOrder or InSequence. In most cases you would like parallel processing though and the way to achieve this is to set the execution mode to InParallel . Each mode has it's own way of processing the jobs. Have a look at Configure Message Queue for more details. Formatting reports is a quite CPU and memory intensive process, so it's important to balance the parallelism against the potential load it can put on the server.