In a large enterprise reporting deployment, it is important to handle both a large amount of data and a large number of users. Imagine a scenario where a single report such as a monthly statement needs to be delivered to thousands of users. The same queries are run multiple times, taxing the database, and the same report is regenerated for each user to ensure data security.
‘Report Bursting’ is a feature that forces a report to run only once yet provides the appropriate output to each consumer of the report, thus greatly reducing the load on the database and the reporting server, while still ensuring data security. For example, in the case of a monthly statement, one query can be executed to return the data for all users. When the report is distributed to users, it is “burst” into parts, and each user receives a partial report containing only the information pertaining to them. Each user thus receives a report personalized with information relevant to their needs.
More Dashboard Examples
The are two stages to implement ‘Report Bursting’:
The next section explains the first stage, creating a report with customized bursting settings. The second stage, executing the report, is performed through the Enterprise Manager.
Report bursting relies on the action of report partitioning, or splitting, a report based on a username (or role)/data value pair. A report can only be partitioned on one data element (table or section). The person designing the report must perform the partition mapping using the Report Designer. Partitions are created by running a query against a live data source and retrieving a list of unique rows, then mapping that data set to another query result set. The users and roles are defined in the Enterprise Manager and cannot be changed in the Report Designer.
You will now implement a simple example report and set its bursting conditions.
Copyright © 2024, InetSoft Technology Corp.