Report Processors

What are report processors?

Report Processors are components which can be enabled and configured to process the results of a rendered Report. For example, let's say you have designed a particular data quality report, which you want to run every week, output the results into Excel, and email the results to a data manager. Report processors fulfill the final step in that process - adding the ability to manually or automatically email the rendered Excel report to a configured list of users whenever it is run. Although the number of built-in report processors is currently limited - supporting only Email Processing at this time (the Logging Processor is for a lightweight proof-of-concept only), more can easily be added into the framework as ongoing requirements dictate.

Configuration

Report Processors must be associated with a Report Design, not with a Report Definition directly. The reason for this is that the type of processing is often directly related to the type of output produced. For example, you may well want to have an electronic submission report processor available when you have rendered your report into an SDMX-HD message to send to a 3rd party, but this kind of processor would not make much sense if you are rendering the same report to the Web. So the first thing that you will need to do - even if the type of renderer that you want to use has not previously required a ReportDesign to operate - is to create a new Report Design that points to the renderer of your choice. Once that is done, you can go to the Manage Report Processors page, and create a new Report Processor, taking care to associate it with your Report Design.

All Report Processors has a series of common properties. Name and description allow you to provide information that allows you to recognize and retrieve the appropriate Report Processor at a later time. Report Processor Type allows you to choose the type of processing you wish to perform. Currently, the only useful processor is the Email Report Processor. Run on Success and Run on Error allow you to indicate whether the processor should operate when the report runs and renders successfully, fails to do so, or both. Processor Mode allows you to control when and whether your processor fires - AUTOMATIC means that it will run every time the report runs and renders, with no manual intervention. ON_DEMAND means that it will be available to run when the report completes, but is optional and may be manually run zero, one, or several times. DISABLED means that it should not be used in any capacity yet - useful if you are still designing the feature, but not ready to make it fully available yet. Finally, the Report Design indicates which specific Report Definition + Renderer combination this Processor should be associated with.

In addition, a "Configuration" box enables for each specific Report Processor type to take in additional parameters to control it's behavior. These are described below for each processor type:

Email Report Processor

Email Report Processors have 2 types of configuration settings needed to work - they need global settings (stored in global properties) in order to configure the actual ability to send emails. Then, each Processor needs to be configured with the content of the email message.

Global Settings

The following global properties must be set to appropriate values. The values specified below are the defaults that will be used if no configured global property value is found:

• mail.transport.protocol=smtp
• mail.smtp_host=localhost
• mail.smtp_port=25
• mail.smtp_auth=false
• mail.debug=false
• mail.from=
• mail.user=
• mail.password=

For each configured instance of the Email Report Processor, the following properties are supported in the "configuration" text area: