Dynamic Creation of Reports with Apache Formatting Objectsby Kevin Hartig
Business workflows require reports to be dynamically generated with current data, potentially from multiple sources. Report content, style and output format are typically user-defined and can be dependent on the requester of the report. Many excellent reporting tools are available today that provide report-generation capabilities but are either costly, use proprietary formats, or don't provide much flexibility to customize the content, style, or final output format. This article describes the architecture, design, and implementation of a reporting tool framework that uses XML standards and tools. The implementation demonstrates how reports are dynamically created using XML, XSL, XSLT, Java, and the Apache XML Formatting Objects Processor (FOP).
Actors are entities that represent external users or systems. They can also represent subsystems within an architecture. The actors defined here are relevant to the reporting framework and are used in the defined use case.
The report requester is the client requesting the report. This actor is also typically the receiver of the final generated report. The
Requester can be a browser, a subsystem, or another service (e.g., a scheduling service that makes regularly scheduled requests for reports).
All of the code associated with this article is available for free and should be included with the distribution. The reporting.zip archive file includes source code, compiled class files, libraries used, documentation, and this article.
Report Content Database
The report content database contains the information that will be used to compile the report content. There may be one or more data sources in the content database for any given report that is generated.
Report Creation Subsystem
The report creation subsystem is the subsystem that performs the function of generating the report. It reads data from various report content databases as necessary to acquire data needed to generate the report. It is also responsible for creating the report in a number of different styles and output formats.
The reporting system is the front end to the whole report-generation system. It manages communications, requests, and responses with other system clients. It delivers the completed report to a designated location. An authentication service is accessed by this subsystem to determine if the requester has access to the reporting system.
The authentication service determines whether or not a requester has access rights to use the reporting system. Requests to use the reporting system must first be authenticated.
The authorization service determines if the requester has access to content in the report being generated. The report creation subsystem uses the authorization service to determine if various content should be filtered from the report. Authorization is determined based on privileges defined for a requester.
A simple use case is defined to describe a basic functional scenario for the creation of a report. It describes the basic flow of events from the perspective of a client requesting a report. This definition defines a generalized report-generation request that can be used as a base for future projects requiring report-generation capabilities. Specific report types, formats, content, security, etc. can be defined for individual projects using the flow of this use case as an example.
Client requests for reports of various types are made with the expectation that a report can be generated either immediately on request and delivered as soon as possible, or on request for access at some later time from a report repository or cache. The client specifies the type of report type desired and report format to be delivered (e.g. PDF, RTF, etc.). Reports can be requested from a thin client (usually a Web browser) or other clients including services, schedulers, batch jobs, etc. Report content may be assembled from one or more data sources.
All requests for reports to be generated are authenticated, validating that the requester has access to the system. Checks are made to authorize content to be included in the report, based on access rights defined for the requester.
Flow of Events
1. Requester selects:
- Type of report to generate.
- Style to apply to report.
- Output format of report.
- Specification defining if report should be delivered immediately back to requester (synchronous) or if notification of report completion is desired (asynchronous).
2. Request is sent to report-generation system.
3. Reporting system receives request. Requests are authenticated based on requester for access to the system.
4. The type of request is determined and is forwarded on to the report-creation subsystem.
5. Report-creation subsystem creates the report in the desired format using the report content database (may be multiple sources) for the report content. Report content creation is based on:
- Type of report requested, which corresponds to a report template.
- Report content classification (text, images, tables, spread sheets, etc.).
- Authorization of requester to access the type of data requested.
6. The completed report is cached for future reference.
7. The reporting system delivers the report back to the requester, or notification of completion is sent, if desired.
Supplementary requirements address what become the systemic qualities of the system. They quantify the desired quality of service in an operational environment. For the purposes of this framework these requirements are lightweight; nonetheless, they are important to consider up front, rather than trying to jam them in late in development.
1. Scalability to add new data sources. Support to incorporate data from a variety of sources must be included. This allows adding new data sources as needed, without changing the architecture.
2. A security interface for authorizing access to data to be included in reports must be included.
3. The framework should be able to function on its own so it can be accessed in a J2EE environment (from servlets) or as a Web service.