Understanding Custom Data Source Types
If you want to add support for JasperReports data source to JasperReports Server, you need to create or edit the following:
| • | Spring bean definition file – Configures all parts of the implementation with JasperReports Server. |
| • | Java code – Implements the classes JasperReports Server requires to create an instance of your JasperReports data source for used in a report, dashboard, or Ad Hoc view. You must also add the jars for your JasperReports data source to the server. |
| • | Message catalog – Strings used in the implementation, for example, for the name of the data source type in the New Data Source dialog, names for visible properties, and any validation messages. |
| • | Query language configuration (optional) – If your JR data source is created using a query executer and you want the query language to be available in the UI, for example, in input control dialogs, you must register your query language. |
See Files Used by a Custom Data Source Implementation for information about the names and locations of these files.
These files work together to make your custom data source type available in the user interface and to create a JRDataSource for use in reports, Ad Hoc views, and dashboards. The files are used at server startup, when a data source is created, and when a user creates or views a report, Ad Hoc view, or dashboard.
Server Startup
On startup, the custom data source definition registers itself with the custom report data source service factory in JasperReports Server. Users see the custom data source type on the Type menu in the New Data Source dialog, using the name defined in the message catalog.
Create/Edit Custom Data Source
When a user selects a custom data source type from the Type menu in the New Data Source dialog, they must enter values for any visible properties required to create a JRDataSource. Properties are specified in the Spring bean definition file, with strings defined in the message bundle. The necessary properties vary with the type of data source; for example, a JDBC data source needs a JDBC driver, URL, user, and password. There may be additional hidden properties, set up in the Spring definition file. Saving the data source instance creates a persistent object in the JasperReports Server repository. When you create a data source type, you can optionally implement validation for the property values in the New Data Source dialog.
Run Custom Data Source
When a user uses the data source instance to create or run a report, Ad Hoc view, or dashboard, a JRDataSource is generated as follows:
| • | The custom data source instance is read from the repository and its data source definition is looked up by name. |
| • | An implementation of ReportDataSourceService is created and the properties from the repository are used to set the corresponding properties on the data source service. |
| • | A JRDataSource is created in one of two ways, depending on whether the data source uses a query: |
| • | If there is no query, the data source service has to provide the JRDatasource. |
| • | If there is a query, JasperReports Library creates a JRQueryExecuter of the correct class for the query language. The data source service passes any objects that the query executer needs by setting parameters. The JRQueryExecuter reads the parameters and produces the JRDataSource. |
| • | The JRDataSource is used to fill the report and produce a JasperPrint object, from which the server generates HTML or other supported output formats. |
| A JasperReports Library data source is an implementation of the JRDataSource interface that provides data organized in rows and columns to the JasperReports Library filler. Each field declared in the JRXML corresponds to a column in the JRDataSource output. |
The following figure shows the main steps in creating a JRDataSource from a custom data source instance.
JRDataSource Creation from Custom Data Source Instance |
|
Query Executers
A query executer is an implementation of the JRQueryExecuter interface in JasperReports Library. It interprets the queryString in the JRXML and produces a JRDataSource. JasperReports Library (either standalone or running in JasperReports Server) determines which query executer to use by looking at the language attribute of the queryString and looking up a query executer factory registered for that language.
JasperReports Server data sources can use two different methods to create a JRDataSource:
| • | The JasperReports Server data source can create a JRDataSource directly, without a queryString in the JRXML; or |
| • | The server can pass implementation-specific objects to the query executer through the report parameter map. The query executer then uses the objects from the parameter map, as well as the contents of the queryString, to create the JRDataSource. |
Selecting the method to use depends on the nature of the data source, as well as whether you want to use a queryString to control your data source. A good example of a data source using a query executer is the JDBC data source: it passes a JDBC connection to the JDBC query executer, which it uses to pass the SQL queryString to the database.
The samples demonstrate both methods:
| • | The custom bean data source creates a JRDataSource directly, which returns a hard-coded list of JavaBeans. |
| • | The webscraper data source can either create a JRDataSource directly, using the properties supplied by the data source instance, or it can get those properties from a queryString in the JRXML. In this case, a data source instance isn’t required. The sample reports for this data source each demonstrate one of these approaches. |
Recommended Comments
There are no comments to display.