Report Processors
- Mike Seaton
- sithija thewa hettige
- Hillary Bagiire
- James Arbaugh
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 settings (stored in global properties/ formerly Global Properties from 1.9 downwards) in order to configure the actual ability to send emails. Then, each Processor needs to be configured with the content of the email message.
Settings
The following settings must be set to appropriate values. The values specified below are the defaults that will be used if no configured settings 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:
Property | Description |
|---|---|
from | The email address that the message should come from |
to | The email address(es) that the message should be sent to. Multiple addresses separated by commas. |
subject | The subject line for the message |
content | Any raw content that should go in the body of the message |
addOutputToContent | If the rendered report is text, setting this to true will include it in the body of the email |
addOutputAsAttachment | Any rendered report can be included as an attachment to the email message by setting this to true |
attachmentName | If addOutputAsAttachment=true, this can be used to specify the name of the attachment on the email |
Example Configuration:
to=someone@hashaiti.org
from=openmrs@hashaiti.org
content=Please see the report attached.
subject=Ward Audit Report
addOutputAsAttachment=true
attachmentName=wardaudit.xls