You can automate the process of generating routine reports by scheduling them to automatically run at specified times or intervals and have the reports sent to a specified destination, such as a printer or the document service on the report server.

To schedule reports to run at a specified time or interval, on the report server, you create a Windows scheduled task for a batch and group the reports in the batch.

The Windows Task Scheduler should be configured to launch the Report Batch Processor, which is a non-GUI instance of the QAD .NET UI launched from the command line, for a specific batch as scheduled and runs all the scheduled reports grouped in the batch. If already set up, the report outputs are sent to the QAD .NET UI document service and/or server-side printer as configured.

Multiple report servers can be set up for increased throughput and failover. The different servers can be configured to process different batches, or can even jointly process reports in the same batch. The Report Batch Processor coordinates the processing of scheduled reports with different priorities in the correct sequence across multiple report servers.

To set up e-mail notifications, add the following entries to client-session.xml on the home server:

Use the following settings as a reference:

When a scheduled report is run by the report server, the system sends an e-mail notification if any e-mail addresses were specified when the report was scheduled. The email can optionally contain the report output file as an attachment if this was specified at the time of scheduling.

The system uses an e-mail template to determine the subject and body of the report notification e‑mails. This template is stored in a special file called report-email-template.txt on the QAD .NET UI home server. The file can be modified if administrators want to change the default content.

The file is located on the home server as follows:

The default content of report-email-template.txt is as follows:

The structure of the e-mail template consists of two parts:

Both the subject and body text can contain both literal text portions as well as dynamic variable references. The dynamic variables get resolved at run-time and are specified using the same syntax as for dynamic variables in scheduled report file routing. In addition to the variables allowed for file routing, there is another variable used only for e-mail templates: $REPORT_FILE_LINK, which gets resolved at run-time to a URL string that points to the report output file on the home server (if file linking or attaching was specified at the time of scheduling).

You can choose the default printer for the Schedule Report screen from Tools|Options. The list of printers displayed in the Options window is the same as the list in the Schedule Report screen—the list specified in the client-session.xml file. If no default is chosen, the Windows default printer is used as the default if the Windows default printer is one of the printers specified in the client-session.xml file.

The format to specify the default printer in client-session.xml is to set default=”true” in the <Printer> tag, as shown in the following example:

Administrators can now configure flexible, dynamic routing rules to control report output file names and path. The rules can be set up with defaults to handle most general types of reports, as well as specific alternatives based on the report type and layout. For example, a certain type of report containing sensitive data could be funneled to a special folder that has Web access disallowed.

In addition to configuring such report routing rules on a system-wide basis, administrators can also override the file name and path rules for any specific scheduling of a report. For example, for a certain report that gets run every month in batch, a special naming convention and folder path can be assigned for that per-month batch run of that report, overriding any general rules that may have been configured for the same report type.

In client-session.xml, you specify the file routing in the <ReportServer> section.

The <ReportOutputFileRoute> element’s reportCode and layout attributes specify the report codes and layouts to which the file routing is applied. If reportCode and layout are both blank, the specified file routing is applied to all reports and layouts. If additional <ReportOutputFileRoute> entries are added that specify report codes and layouts, these entries override the general entry for reports matching the more specific entries.

The rules that govern output file naming and directory path are specified in two child elements of <ReportOutputFileRoute>:

Both of the above entries allow dynamic variable substitutions, which get resolved at run-time. The syntax {$variable_name} is used, where variable_name includes the following:

Any report setting can also be used as a variable name, in which case the run-time value of that setting is dynamically substituted. If no setting is found that matches the variable name, a blank is substituted.

REPORT_FILE_LINK — (only available for the e-mail template)

Additionally, there is a special dynamic variable that can be used with the output file name entry that resolves to a date-time stamp. This is very important to use for file naming, since a file name that matches one that already exists in the same directory from a previous report run results in a file overwrite. The format of this date-time variable is:

where <format_specifier> is a .NET date-time format string. For example,

will specify the date-time including year, month, day, hour, minutes, seconds, and fractions of a second to six digits. (It is important to include the fractions of a second portion to prevent file name conflicts in cases where multiple report servers are running.)

An example output file name is: 20120209101213083857.pdf.

You can specify DATE_TIME without a format specifier. In this case, it defaults to the yyyyMMddhhmmssffffff format.

Both file path and file name specifiers can mix any combination of literal text and dynamic variables. For example,

will create output files whose names always start with daybook- followed by a dynamic time stamp.

The following example, which includes three <ReportOutputFileRoute> entries, illustrates how the routing rules can be applied:

In the above example, the first entry’s routing rules will be applied to all reports other than QAD_DaybookSetReport. The second entry’s routing rules will be used for QAD_DaybookSetReport, except when the layout is layout1, in which case the third entry’s rules will be applied.