Report Bursting

Starting with the QAD 2012 Enterprise Edition, the Reporting Framework includes an infrastructure to facilitate the mass-running and distribution of reports: report bursting. A report burst is a special way that a report can be run that involves the following aspects:

• A report burst can be configured to automatically split a report into many smaller reports, relieving end users of the burden of manually running numerous reports. Any field in the top-level table of the report’s data set can be chosen as the split field (for example, a report could be split to output one report per customer ID, or one report per item number).

• A report burst can be configured to dynamically route each of the split output reports to different e-mail, file, and printer destinations. The logic can be based on data values (for example, the customer ID in each of the output reports could be mapped to an e-mail address for that customer to send the report to).

The report bursting mechanism is a general capability that can be used with any report developed using the QAD Reporting Framework, but not for any other type of report. In addition to dynamic setting of output destination, the infrastructure allows for most of the report settings to be set dynamically based on the data; this includes such settings as language for translated labels, date and number formats for internationalization, output file type (PDF, Excel, RTF, and so on) and layout type (for example, different form layouts of the same data for different countries).

Report bursts internally schedule each of the split output reports to be asynchronously (but immediately) run by a report server using the QAD Reporting Framework Service. This leverages the many benefits of the report server architecture such as robustness, scalability, and failover.

Although the new bursting capability is included in the QAD Enterprise Applications 2012 – Enterprise Edition release, this release does not contain any QAD application programs that take advantage of it. You can, however, set up your own desired scenarios for bursting using the following mechanisms:

• The Scheduled Report API can be used to write programs to schedule report bursts to be run on the server at desired times. Special burst settings are used to configure the burst run. These programs can be written in the Progress or .NET languages. They could be either simple script-like utility programs for administrators to run, or could be fronted with user-interface logic to expose the functionality to end users if desired.

• The .NET Run-Report API can be used to write programs to initiate report bursts immediately within a QAD .NET UI process. The programs could be fronted with user-interface logic to expose the functionality to end users if desired.

• Administrators can use a new Burst Settings tool button from the report viewer program to run an immediate ad-hoc burst of that report, and also to choose settings and then schedule the report to be run as a burst in batch on a report server.

The logic that controls the dynamic routing settings is completely configurable. However, the QAD Enterprise Applications 2012 – Enterprise Edition release contains no default routing logic. If dynamic routing is desired, it is necessary to first codify the needed rules using the Progress programming language in a special dynamic-routing program that can be invoked during report bursts.

If you want help with creating report burst programs or setting up the desired routing rules, please consult QAD Services.

Prior to the introduction of QAD report bursting technology, third-party solutions were required. Those products typically process a plain text report output file, parse it, split it into multiple files, transform it to alternate output formats, and route the output files to destinations such as document storage and e-mail. They typically allow dynamic routing logic to be configured based on the data in the document.

The introduction of the QAD Reporting Framework posed new challenges as well as new possibilities for such report bursting approaches. Its ability to output rich, graphical reports in binary formats such as PDF eliminate the need for third-party post-rendering, and also create a more challenging file format to feed into those products that cannot be parsed as easily as plain text.

The QAD report bursting capability now provided with the QAD Reporting Framework solves these challenges in an out-of-the-box manner that eliminates the need for third-party technology. It uses a fundamentally different approach that does not involve post-processing of report output files. Instead, report bursting is implemented internally as the report is run. It is important to understand the basic process used in order to be able to configure and administer report bursts.

When a report is run in burst mode, it operates as a driver report, which, during its processing, spawns one or more target reports, each of which performs the rendering of the final output documents. The driver report first queries the dataset for the overall burst and splits this into a smaller dataset for each target report. The target reports are not directly run in the driver report process but instead are scheduled to be run in the QADSVC batch that is processed continuously by the QAD Reporting Framework service running on one or more report server machines. This provides benefits including robustness, scalability, and increased throughput. It also records a permanent record of the report burst results, which can be viewed using Scheduled Report History Browse.