|
OpenRPT Product Guide |
|
|
OpenRPT Product Guide |
| 3.2. Ad Hoc Reports | ||
|---|---|---|
 | 3. Report Renderer |  |
As we have said, the report renderer can be used to generate miscellaneous reports using data stored within PostgreSQL databases. The report renderer’s miscellaneous or ad hoc reporting capability also extends to xTuple databases, which run on PostgreSQL. For xTuple users, this means you can use the report renderer to generate your own reports—thereby extending your reporting capability beyond the range of standard reports included with the xTuple application.
The report renderer enables xTuple users to extend their reporting capabilities. Use the report renderer to generate ad hoc, or custom xTuple reports.
Before we can demonstrate report renderer functionality, we must first identify a report definition to work with. For this exercise, we created a simple report definition designed to retrieve basic item information from an xTuple database. As the following screenshot shows, we created the report "AdHocItemReport" using the standalone OpenRPT application:
xTuple users can create report definitions using either the embedded report writer or the standalone OpenRPT application. The report renderer then uses these report definitions to generate printed reports.
As you can tell from the figure, this simple "AdHocItemReport" will list items and report on whether they are sold or active. The "AdHocItemReport" report is not one of the standard xTuple reports available in the application’s menu structure. However, we can retrieve this data and generate an ad hoc report when we combine this report definition with the standalone report renderer.
The next screenshot shows the query source the report definition will use to retrieve the data from our database:
As you can see in the query source, the SELECT statement retrieves basic item information from the item table. Then, MetaSQL is used in the WHERE clause to introduce two parameters: sold_param and active_param. The parameters refer to the report must interpret to accommodate two dynamic parameters. These parameters will enable the namely, whether application users have marked the item as sold and/or active.
The report displays whether or not an item is sold and whether it is active. In the next section we see the query source and corresponding SQL query that retrieves the data from the database. As part of the SQL we will assign parameters that, when we generate the report with the renderer, filter data based on user provided values for these two parameters.
Later, using OpenRPT, we will pass runtime parameter values to the report definition when we generate its output and in this way control the nature of the data displayed on the resulting report.
To accelerate the creation of any report definition, use the MetaSQL Editor to verify the accuracy of your SQL queries. Once queries have been validated, you can then copy and paste them into your report definition’s query source.
| |  | |
| 3.1. Connecting to a Database |  | 3.3. Loading Report Definitions |