The process of setting up ReportWeaver for use with Java to access a (*database*) consists of 2 steps.

1. Specify the data model (schema) using the schema wizard.
2. Implement triggers that provide data when reports are started.

Once the connection is set up, you can start designing report templates. In a further step you must decide how to deploy your reports. For this you have three alternatives:

• Integrate ReportWeaver in your application and use the runtime API to run reports.
• Run ReportWeaver as a standalone server and run reports from your browser or via the web-service API.
• Run Reportweaver inside an EJB Application Server and use the runtime API to run reports from your browser.

Before you dive into the setup please take a moment to understand the architecture of your ReportWeaver integration:

In the beans mode ReportWeaver does not connect to a database directly. Rather it displays your applications java objects (beans). For this ReportWeaver must access the class files of your beans and loading of the objects must be facilitated by the object environment.

Environments that load objects automatically are either EJB containers, object databases (ODMG or JDO compliant) or object relational tools like hibernate or Top-Link.

Note: The beans api of ReportWeaver always uses the java classes as the basis for its database schema. It doesn't need or use a relational database model.

When you install ReportWeaver with the (*database*) binding you will use the (*database*) connection wizard to connect to a (*database*) database via a schema definition file.

In addition to the class files ReportWeaver needs some additional information that it reads from the schema definition file.

• It needs to know the data entry points (they are called roots in ReportWeaver speak) that retrieve the initial object for a report.
• It needs to know the element type of collections that appear in the classes. This information can be added intractively in the designer, but it is usually more convenient to specify it in the schema.
• It needs to know which fields/methods of a class are relevant for reporting and which fields shall be hidden.
• It needs to know eventual extension methods of the objects that encapsulate specific access patterns.

This information must be supplied in an xml configuration file. (The schema definition file) The usual extension is ".rsd". Depending on your database and configuration, this file may become quite complex. In these cases it is recommended to generate the file form a model like UML.

To design this file you can use the schema wizard.

The schema file supports various extension mechanism, to deal with specific tasks and configurations. These are:

• Class extension methods.
• Application specific data access triggers. These are described in the java api documentation.

The (*database*) Connection Wizard

The Connection wizard consists of two pages. One for the schema definition file and one to extend the classpath.

Please select a schema definition file.

Note:Use the initargs tag in schema definition file to specify the database(s) and open modes.

1. This is the list of your classpath entries from the environment or launcher. Please check, which entries it contains. If the entries for Versant and for your project are missing, then you must add them with the buttons. This inherited classpath cannot be changed here. If it needs modifications, then this must be done outside of ReportWeaver.
2. This is the list of additional classpath entries, that will be used in your reporting project.
3. Add more entries with the add button and select a directory, jar or zip file in the file chooser that pops up.
4. Remove the selected entry from the extended classpath.
5. Change the ordering of the extended classpath.

Once the database is open the schema file and class path are stored in the repository. We recommend, that you save your repository after the database is open. You can then use this saved repository as a template for any work with this database.

If you want to change the schema file location or if your classpath must be modified, please use the command Open template set and reconfigure.

Note:Because there can only be one primary database attached during a session, the new/open action is disabled once you have a database open or after you have loaded a saved repository.