Differences with the Java Reporting Engine | Crystal Reports XI Official Guide

Although there are clear advantages to having a 100% pure Java reporting engine, the developers at Business Objects had to rewrite it from scratch. Anytime a large software component such as the Crystal Reports engine is rewritten, there are bound to be some differences, at least in the first version. Some of those differences are conscious decisions made by Business Objects to limit the scope of the development to meet the target release date. Other differences surface because of development platform differences: Java versus native Windows. The result is that some features are not currently supported by the report processing engine included with the Java Reporting Component. The following sections address some of these issues.

Supported File Formats

The first and most important limitation is that only version 9, 10, and 11 report files are supported. This doesn't mean that reports designed in version 8.5 or earlier are useless, but it does mean they have to be converted to version 9. To make this process easier, you can download a Report Conversion Utility from the Business Objects website. It can open up reports in batch, make any necessary changes, and save them into a version 9/10/XI file format. New reports can be created using the standard Crystal Reports XI designer.

Tip

The file format has not had any major changes between version 9, 10, and XI of Crystal Reports. If you have report files created in version 11, you can generally use them in version 9 applications.

Support for User Function Libraries in Version XI of the Java Reporting Components

Historically, the ability to define your own functions that extend the power of the Crystal Report's formula language has been available through the ability to write your own COM libraries that can be utilized within the report's formula designer. Such functionality could be implemented by writing your own dll in any COM development environment, such as C++ and Visual Basic.

As of version 11 of the report designer component, this functionality can now be built and leveraged inside the Java report engine api. This is accomplished by implementing a class that exposes methods consumed by the Crystal Report.

Note

Keep in mind that inside one report there can only be one flavor of the UFL implementation, meaning you can not utilize both COM and Java user function libraries.

Example creating a user defined function:

public class UserFunction1 implements FormulaFunction import com.crystaldecisions.reports.formulas.*; import com.crystaldecisions.reports.common.value.*; public FormulaValue evaluate (FormulaValueReference[] arguments) throws FormulaFunctionCallException {     String strArg0 = ((StringValue)arguments[0].getFormulaValue()).getString();     String string1 = "Input entered: " + strArg0;     FormulaValue formulaVal = StringValue.fromString(string1);     return formulaVal; } }

In the preceding example, the function simply returns a string value supplied as an argument to the calling function inside the formula workshop. All user defined functions appear under additional function tree items inside the formula editor.

The Java Reporting Engine Uses JDBC

Another difference related to the Java platform is the way queries are run against the database. Although the Windows world has many different data access technologies, Java has just one: Java Data Base Connectivity (JDBC). Previously, Crystal Reports did not support JDBC, but a new JDBC driver is available for version 11 as a website download.

Note

At the time of this writing, the version 11 JDBC driver was not yet available but should be available for download shortly from the Business Objects Download Center found at http://www.businessobjects.com/products/downloadcenter/. Check the website for a status update.

For any new reports that you develop, choosing JDBC is generally the best approach. You will save yourself time and effort this way. The Crystal Reports JDBC driver shows up as "JDBC (JNDI)" in the Crystal Reports data explorer when creating a new report. It has two ways to connect to a data source: through a JDBC URL or a JNDI reference. This can be problematic at times because there are several steps involved in setting up your environment for JDBC access. Make sure you take your time going through the steps and double-check the changes you are making.

When connecting via a JDBC URL, you need to specify two items:

Connection URL a standard JDBC URL that specifies a data source
Database classname the fully qualified classname of the JDBC driver

The best way to figure out what these two values should be is to consult the documentation for the JDBC driver you'd like to use. The following bullets provide sample connection information for connecting to SQL Server using the SQL Server JDBC Driver. Figure 28.1 shows this information being used from the Crystal Reports designer.

Connection URL jdbc:microsoft:sqlserver://abc:1433 (where abc is the name of the server running on port 1433)
Database classname com.microsoft.jdbc.sqlserver.SQLServerDriver

Figure 28.1. Connect to a JDBC data source through the Crystal Reports designer.

Before you try to connect, you need to modify a configuration file. This file, CRDB_JavaServer.ini, can be found at the following location:

\Program Files\Common Files\Crystal Decisions\2.5\bin\

You should make the following changes:

Set PATH to where your Java Runtime Environment (JRE) is, for example, C:\jdk1.4\bin.
Set CLASSPATH to the location of the JDBC driver you want to use, and also include C:\Program Files\Common Files\Crystal Decisions\2.5\bin\CRDBJavaServer.jar.
Set IORFileLocation to a location where the driver can write temporary files; make sure this location exists.

The other method of connecting to JDBC is through a JNDI reference. JNDI (Java Naming and Directory Interface) is a Java standard around resolving names and locations to resources in complex environments. In the case of the Crystal Reports JDBC driver, it is used to store JDBC connection strings. Connecting via JNDI has a few key benefits. First, the person creating the reports doesn't need to know the exact server name; he only needs to know an "alias" given to it in JNDI such as "FinanceData". Second, if that connection information were to change, no report change would be needed, only a change in the JNDI directory. Lastly, JNDI supports connection pooling which the Crystal Reports JDBC driver can take advantage of. As a recommendation, if you have an available JNDI server, use it to define all your database connections; this will save you time and effort later on.

Any existing reports you deliver through the Java Reporting Component will be converted on-the-fly to JDBC. This conversion is configurable using JNDI. To set up a configuration mapping, register a JDBC connection in a JNDI directory under the same name as the existing report's data source. For example, an existing report is connecting via ODBC to Oracle. With the same name as the ODBC DSN name, create a JNDI entry for a JDBC connection to the same Oracle server. When the report is run, it looks to JNDI and resolves the connection to the Oracle server.