...
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/ 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 global properties settings must be set to appropriate values. The values specified below are the defaults that will be used if no configured global property 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:
| Code Block |
|---|
to=someone@hashaiti.org
from=openmrs@hashaiti.org
content=Please see the report attached.
subject=Ward Audit Report
addOutputAsAttachment=true
attachmentName=wardaudit.xls
|