Reporting framework

The reporting framework provides generic, customizable reporting functionality for almost any aspect of your site. The reports are accessible by any of the roles that use the WebSphere Commerce Accelerator. Access for a particular report can be defined and limited within the report. WebSphere Commerce Accelerator users can request the reports at any time.

The framework generates reports using data contained in the production database, and displays the reports in real time. The framework consists of a generic controller command, a data bean, and a generic view which displays the result. You can customize the framework by adding valid SQL queries, and defining JSP files used to request and display the generated reports.

Reports are accessible from the WebSphere Commerce Accelerator. Consequently, each report requires a number of associated assets. The report consists of data represented in a tabular format, the underlying assets consist of the report identifier, an SQL query, access control elements, and so on. The report request launches a controller command on the server. The controller command calls tasks to set the generic view, unless the report specifies a particular view. The command also sets a number of required variables, and returns this data to populate the ReportDataBean in the target JSP file. Access control for the reports is set on the views which request (input) and display (output) the report. The results returned from the database are stored in the data bean as a vector of hash table. Finally, the JSP file displays the report. If the report is empty, the JSP file displays a generic text string instead.

You can customize the reporting framework by adding new reports. These reports can use helper JSP files.

All input and output report JSP files use Reports.properties to resolve multilingual issues. Thus, properties files map all titles and keys used in the XML and JSP files.

For performance reasons, it is a best practice to replicate the database and run reports on the replica. Ideally, do not run SQL statements against the production database.