Chapter 28 Java Reporting Components
Overview of the Crystal Reports Java Reporting Component 720
Understanding the Java Reporting Components Architecture 721
Differences with the Java Reporting Engine 722
Configuring the Application Server 725
Delivering Reports in Web Applications 726
Using the Crystal Tag Libraries 730
Exporting Reports to Other File Formats 731
Printing Reports from the Browser 735
Developing with a Visual Development Environment 738
Overview of the Crystal Reports Java Reporting Component
Business Objects has had a commitment to Java developers for quite some time. Crystal Reports version 9 included a Java edition of the Report Application Server Software Development Kit (SDK), and Crystal Enterprise version 8.5 had a Java edition of the Crystal Enterprise SDK. Both of these solutions consisted of a processing tier of non–Java-based services and then an application tier of Java-based objects that acted as the entry point to those services. The theme here was around multi-tier, large-scale, enterprise applications. This might sound quite natural to some Java developers, who would argue that’s what Java is for.
In the version 11 suite of products, the Report Application Server and corresponding Java SDK have been moved out of the Crystal Reports product line and into the BusinessObjects Enterprise product line. This makes it clear that all servers are part of the BusinessObjects Enterprise offering. However, without any other changes this would leave the Crystal Reports product without any Java-based developer components. Because developers have always been important to Business Objects—especially Java developers—the Business Objects folks have spent a significant amount of time building a new offering in version 11 for Java developers: the Crystal Reports Java Reporting Component.
The key word in the name of the Java Reporting Component is “component.” There is a clear distinction between the Crystal Reports–based developer solutions and the Crystal Enterprise–based developer solutions. This is based around the distinction between components and servers. Crystal Reports provides reporting components and BusinessObjects Enterprise provides reporting servers. The following sections describe some of the key differences between components and servers.
Components Run on the Web Application Server
Components are self-contained and reside on the Web application tier. They are single tier in that there is no separation between the programmatic interface and the report processing. Although they can be run on multiple machines in a Web application server farm, they themselves are individual components and have no built-in mechanism to load balance or share state.
Although this kind of deployment architecture is initially attractive to many Java developers, many eventually find that the report processing degrades the performance of the Web application server to an unsatisfactory level. Keep in mind the size of your user audience before deciding to do all report processing on the Web tier.
Components Are Generally Less Scalable
Although the actual report processing of a single report is generally done just as fast with a component as it is done with a server, the capability to scale the components differs. Although a farm can be created, components running on different machines are not aware of each other and thus don’t have the smarts to figure out which component is least busy or has some information that is needed by another server. In general, the servers provide a more scalable, extensible solution for high-volume reporting. Obviously, cost can be a factor because the server solutions have higher licensing costs, so do your research about the product capabilities before you start development.
Components Are 100% Pure Java
Besides product line differentiation, the other reason Business Objects created the Java Reporting Component was so it would have a 100% pure Java reporting engine. Although the server solutions have a pure Java SDK, the Java Reporting Component consists entirely of native Java code. This is attractive to both Java purists and also partners who embed Crystal Reports technology inside Java-based applications, and finally for customers wanting to deploy a reporting component on a Unix platform. Providing a 100% pure Java reporting engine means Business Objects rewrote a portion of the Crystal Reports engine into Java. Because this was not a total port of the functionality, some reporting features are not available. However, in practical terms, most reports off standard relational data will run just fine.
Understanding the Java Reporting Components Architecture
Now that you know why Business Objects created the Java Reporting Component and how it differs from some of the server solutions, you will move on to learning more about the components. The Java Reporting Component has three main pieces to it, as shown here:
- A report engine
- Report viewer controls
- Helper tag libraries
The report engine is the component that processes the reports. Its job is to load the report template (.rpt file), run the query to the data source, process the report’s pages, and communicate with the report viewer controls to provide the information they need to render the reports. The main report viewer is an HTML viewer control that is used to display the report’s output in JSP pages or servlets. The other viewer control is used to view the reports in other formats such as Rich Text Format (RTF) or PDF. Finally, there are helper tag libraries that make the process of using the report viewers easier by wrapping up their logic into a simple tag that can be inserted into JSP pages. Also of note is that the Java Reporting Component has integration with both Borland JBuilder and BEA WebLogic; more will be discussed on what this integration provides later in this chapter.
From an architecture point of view, all these components reside on the Java application server. The officially supported application servers are
If the exact application server or version of application server you are targeting is not listed here, it does not necessarily mean that the Java Reporting Component will not work there. It just means that it was not one of the configurations explicitly tested by Business Objects, and although not “officially supported,” chances are you will be able to use it. If you are unsure, contact Business Objects to see if they are aware of any issues with that particular application server. There are customers using other application servers such as JBoss in production today.
Although the Java Reporting Component comes with some JSP and servlet samples, the actual API is simply raw Java classes. These classes can be used inside of JSPs, servlets, EJBs, or other Web-based technologies. The advantage here is that there is no dependency on any particular version of the J2EE specifications such as servlets or struts. You might have noticed that desktop applications have not been mentioned thus far. This is because there is not currently a desktop viewer control (that is, based on the AWT or Swing frameworks). Because the viewer controls that exist are dependent on a Web framework being in place—they require servlet-based objects in order to work—there is currently no way to view reports in desktop applications. At the time of this writing, Business Objects has expressed interest in producing a desktop report viewer for the Java world at some point in the future. Check back with the company if you’re interested. In the meantime, a good solution for delivering reports inside desktop applications is to host a Web browser applet inside of a Java form.
Differences with the Java Reporting Engine
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.
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.
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:
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.
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 FilesCommon FilesCrystal Decisions2.5in
You should make the following changes:
- Set
PATHto where your Java Runtime Environment (JRE) is, for example,C:jdk1.4in. - Set
CLASSPATHto the location of the JDBC driver you want to use, and also includeC:Program FilesCommon FilesCrystal Decisions2.5inCRDBJavaServer.jar. - Set
IORFileLocationto 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.
Configuring the Application Server
Although building Web applications in Java is meant to be independent of application servers, the J2EE standard tends to be interpreted differently for each vendor’s application server. Because of this, each application server has a different way of performing Web application configuration. The general rule is that there is a folder structure like this:
When setting up the Java Reporting Component for a given Web application, the following steps are required:
- Copy all the Java Reporting Component .jar files from
C:Program FilesCommon FilesCrystal Decisions2.5javalibinto the lib folder. - Copy all the third-party .jar files from
C:Program FilesCommon FilesCrystal Decisions2.5javalibexternalinto the lib folder. - Copy CrystalReportEngine-config.xml from
C:Program FilesCommon FilesCrystal Decisions2.5javato the classes folder. - Copy the crystalreportviewer11 folder from
C:Program FilesCommon FilesCrystal Decisions2.5to the Web application folder (webApplicationFolder in the previous example). - Add the following entry to the web.xml file:
There are two additional steps required if you intend to use the Crystal tag libraries:
- Copy crystal-tags-reportviewer.tld from
C:Program FilesCommon FilesCrystal Decisions2.5javalib aglibto the WEB-INF folder. - Add the following entry to the web.xml file:
Delivering Reports in Web Applications
Report viewing is done primarily through the HTML report viewer included with the Crystal Reports Java Reporting Component. This report viewer is a control that runs inside a JSP or servlet. Its job is to get the information the report engine produces for a given page of a report and render that data to HTML format into the page’s response stream.
The programmatic entry point to the report viewer is a class called CrystalReportViewer. This class is found in the com.crystaldecisions.report.web.viewer package. It can be instantiated as follows:
CrystalReportViewer viewer = new CrystalReportsViewer();
Make sure you add the class’s package name in the import attribute of the page clause like this:
<%@ page import="com.crystaldecisions.report.web.viewer.*" %>
This is the main class you use to render reports to HTML. Its two main methods used to view reports are setReportSource and processHttpRequest. These methods are outlined in the following sections.
The setReportSource Method
This CrystalReportViewer object’s setReportSource method is used to indicate to the viewer which report it should display. Specifically, it accepts an object that implements the IReportSource interface. The Java Reporting Component’s engine supplies this object. There are generally three steps involved in setting the report source.
The first step is to create a JPEReportSourceFactory object found in the com.crystaldecisions.reports.reportengineinterface package. As the name implies, this object’s job is to create report source objects. This object has one relevant method: createReportSource. Its definition is as follows:
IReportSource createReportSource(object reportPath, Locale userLocale)
The reportPath argument should be a string consisting of the filename of the report file (.rpt). With the Java Reporting Component, the path from where the report file should be loaded is configured in the CrystalReportEngine-config.xml file. This XML configuration file has a <reportlocation> element that indicates the location of the report files relative to the location of the config file. The default value for the reportlocation is ...., which (if the config file was in the classes folder as outlined in the previous section) would point to the webApplicationFolder folder. It’s a good idea to create a reports folder inside the Web application’s folder and store all your reports there. Then change the report location setting to ....
eports. Then when reports are referenced in the call to createReportSource, you only need to pass the name of the report, not the folder location.
The second argument to createReportSource is a Locale object. Generally, you should pass in request.getLocale(). This means that whatever the user’s locale is, it is passed down to the report engine so any locale-specific formatting can be applied.
The processHttpRequest Method
After the viewer is told which report it needs to view, the only other method left to call is the processHttpRequest method. This method kicks off the actual report processing and renders the report to HTML. Its definition is as follows:
The first argument passed in is the current servlet’s request object. The report viewer uses this to access the HTTP request’s form data where the viewer holds its state information such as what page it was showing, what level of drill-down, and so on. Also stored in the form data is the piece of data that indicates what action is to be performed. For example, the user might have clicked the Next Page button, or might have also drilled down. You simply pass in the servlet’s request object.
The second argument is the response object. The report viewer uses this object to access the page’s response stream so it can write the HTML output of the report. Here, you simply pass the servlet’s response object.
The third argument is the servletContext, which is used to access the servlets container. Generally, you pass getServletConfig().getServletContext() for this argument. The final argument is a Writer. You generally pass null here unless you want to provide your own Writer.
Listing 28.1 shows these concepts all brought together in a JSP page that displays a report.
Listing 28.1. Viewing a Report in HTML
The output of this page is shown in Figure 28.2. All content for the report consists of HTML elements, keeping all formatting and layout preserved. Every once in a while you will find a discrepancy in the report output between the designer and the HTML viewer, but the advantages of the HTML viewer generally outweigh the disadvantages. Besides drilling down or hyperlinking from the report’s main content, a toolbar along the top provides a way for the end user to interact with the report. Buttons for page navigation as well as printing and exporting are present. When a command is performed by the user such as navigating to the next page or drilling down, the report viewer using a JavaScript function causes a form post to occur back to the same page. Both the current state and the new command are sent as part of the form’s post data. The JSP or servlet reruns and the new state of the report is again rendered back to HTML.
Figure 28.2 This is the HTML report viewer in action.
There is a collection of methods that the CrystalReportViewer object exposes that can be used to customize how the viewer looks and behaves. For the full list of methods, consult the API documentation; however, the following sections cover some of the more useful types of customizations.
Customizing the Toolbar
Each button or set of buttons on the report viewer toolbar can be individually turned off and on. These are done by a set of simple methods that accept a Boolean argument. They are listed here:
setHasToggleGroupTreeButton(boolean)setHasExportButton(boolean)setHasPrintButton(boolean)setHasViewList(boolean)setHasRefreshButton(boolean)setHasPageNavigationButtons(boolean)setHasGotoPageButton(boolean)setHasSearchButton(boolean)setHasZoomFactorList(boolean)setHasLogo(boolean)
Finally, the entire toolbar can be turned off by calling setDisplayToolbar(boolean). If the toolbar is turned off, the user does not have a way to interact with the report such as navigating pages. To facilitate this, there are other methods on the CrystalReportViewer object that can be called to drive the page navigation, including showFirstPage, showPreviousPage, showNextPage, showLastPage, and showNthPage. Similar methods exist to re-create the functionality of most of the other buttons as well. In general, the methods related to toolbar customization are almost self-explanatory.
Customizing the Group Tree
The group tree’s width can be set via the setGroupTreeWidth method. To change the formatting of the group tree’s text, change the CSS styles defined in the default.css file found in crystalreportviewers11/css. Alternatively, the entire group tree can be hidden by passing false to the setDisplayGroupTree function.
Using the Crystal Tag Libraries
Now that you understand how the report viewer works, it’s beneficial to understand some of the ways that it can be used in a more productive manner. Java tag libraries are a great way to accomplish this. A tag library (taglib) is an HTML-like tag that can be embedded inside a JSP page; it has some compiled code logic behind it that knows how to render itself to HTML. The beauty of a tag library is that you don’t need to clog up your JSP page with a bunch of code; you simply need to insert the tag. When Business Objects created the HTML report viewer, they were wise enough to create some Java tag libraries alongside it. This is not to say you could not create your own tag libraries to suit your own needs, but the ones provided with the product will probably meet most requirements.
Refer to the Application Server Configuration section in this chapter for steps to configure the Crystal tag libraries. After you’ve finished the setup, you can start adding the tags to your page. The first step in using the tag is to add the taglib directive to the top of your JSP page. This directive looks like this:
<%@ taglib uri="/crystal-tags-reportviewer.tld" prefix="crviewer" %>
This indicates to the JSP page that any time it finds a tag prefixed with crviewer, it should look in the crystal-tags-reportviewer.tlb file to find out how to work with that tag.
There are two tags that must be added to the JSP page: viewer and report. Listing 28.2 shows a simple page using the viewer and report tags.
Listing 28.2. Using the Tag Libraries
The viewerName and reportSourceType attributes of the viewer tag are required. The viewerName can be set to blank unless there are multiple viewer tags on the same page, in which case you’ll need to name them uniquely. There is only one report source type supported in the Java Reporting Component, which is “reportingComponent.” Inside the viewer tag, you’ll see a report tag. For the reportName attribute, pass in the name of the report you want to display. The output of this page would be exactly the same as the output of the previous code example using inline Java code. The advantage of this page is that it is cleaner and simpler. To customize the viewer, rather than writing code, simply add attributes to the viewer tag. For example, adding the following attribute to the viewer tag hides the group tree:
displayGroupTree="false"
There are many other attributes supported. Consult the documentation for a full list but the general rule is that most methods on the CrystalReportViewer object have a corresponding tag library attribute.
Exporting Reports to Other File Formats
You’ve learned so far how the CrystalReportViewer object can be used either in code or as a tag library to view reports in HTML format. This is useful for having a quick look at a report online, but users often require the capability to save the report to their own machine either for their own reference or so they can send the report elsewhere. Exporting is a perfect solution to this. The Java Reporting Component supports exporting reports to both Adobe PDF and RTF. There are two ways exporting can be done: via the export button on the toolbar and via code.
Exporting via the Toolbar Button
By default, the export button on the report viewer’s toolbar is hidden. To enable it, either set the displayToolbarExportButton attribute to true if you are using the tag library or call the setHasExportButton method if you are using the viewer directly.
Even though you instruct the viewer to show the export button, you might find that it is still now showing up. This is most likely because you have not told the viewer that it owns the whole page. This is done via the setOwnPage method or isOwnPage attribute for the viewer or tag library, respectively.
When the Export button is clicked, a pop-up window appears asking the user which document format she would like to export the report to and which pages she would like to export to. This is shown in Figure 28.3
When the user clicks OK, the browser sends back the report in the requested format. Figure 28.4 shows the Income Statement report from the previous examples, exported to PDF.
Figure 28.3. Export a report through the report viewer.
Figure 28.4. Here is a report exported to the PDF format.
Exporting via Code
There are a few reasons why you might want to export via code. Perhaps you always want to deliver reports in PDF or RTF format instead of using the report viewer at all. Or perhaps you want to control the user interface for exporting. In any case, this section describes how to export using the ReportExportControl.
Although some developers find it attractive to bypass the Crystal Report HTML viewer, and instead use either PDF or RTF as the primary way to deliver reports, this is often not the best way to go. Exporting is one of most processor-intensive operations and thus should be used sparingly if possible. In addition, when you export reports you lose all the interactive functionality like drill-down and group tree navigation. Use exporting where appropriate.
The ReportExportControl is the Java object used to render reports to both PDF and RTF. Because it is derived from the same class as the CrystalReportViewer object, it has many of the same properties and methods. The two main methods used in the report viewer—setReportSource and processHttpRequest—are used in exactly the same way in the ReportExportControl. Also, when exporting there is an additional method that is required: setExportOptions. This method is used to tell the ReportExportControl which export format should be used, and optionally, which pages should be exported.
The argument that is passed into the setExportOptions method is an object of type ExportOptions. This is found in com.crystaldecisions.sdk.occa.report.exportoptions package. With it, you call the setExportFormatType method passing in one of the following values:
ReportExportFormat.PDF(for PDF)ReportExportFormat.RTF(for RTF)
Although the ReportExportFormat object has additional export formats not mentioned here such as MSExcel and Text, these are not currently available with the Java Reporting Component. These show up because the ExportOptions object is a shared object between other Crystal products that do support those export format types.
Listing 28.3 pulls this all together and shows a JSP page that exports a report to PDF format.
Listing 28.3. Exporting via the ReportExportControl
There are a few additional options that you might find useful. The first is the capability to specify which page numbers should be exported. This enables you to export just a small number of pages from a very large report. This is accomplished by creating either the RTFWordExportFormatOptions or PDFExportFormatOptions objects and calling their setStartPageNumber and setEndPageNumber methods. The resulting object is passed into the setFormatOptions method of the ExportOptions object. The code snippet shown in Listing 28.4 illustrates this.
Listing 28.4. Specifying Page Numbers When Exporting
The other option related to exporting is whether the resulting exported report should be sent back to the browser as an attachment or inline. When sent as an attachment, the browser pops up a dialog asking the user if he would like to save or open the file. This is useful if you think most of your users will want to save the file to their machines. The default behavior is for the report to open inside the browser window in either the Adobe or Microsoft Word embedded viewer. This is controlled via the setExportAsAttachment method of the CrystalReportViewer. This method simply takes a Boolean value, which determines whether the file should be an attachment.
Printing Reports from the Browser
Viewing reports in electronic form is very valuable but as much as the “paperless office” is talked about, people still need to print reports to printers. The Java Reporting Component has the capability to print reports via the print button on the viewer’s toolbar. Like the Export button, for the Print button to show, the viewer must be set to own the page via the isOwnPage attribute or setOwnPage method of the CrystalReportViewer object. When this button is clicked, a window opens asking the user which pages they want to print. This dialog is shown in Figure 28.5.
Figure 28.5. Print a report using the report viewer.
When the user clicks the Print button, the report opens in the Adobe PDF viewer, from which the user can then click Adobe’s Print button. This prints the report to the user’s printer.
Common Programming Tasks
The different delivery mechanisms for the report viewer have been discussed. Now let’s look at some of the common programming tasks that go along with delivering reports. This includes passing parameters to the report viewer and setting or changing the data source. The following sections will discuss these topics.
Passing Parameters
One of the most common programming tasks with any Crystal Reports product is to pass parameters to the report viewer. This really isn’t a hard task but developers often find this difficult because of a lack of proper examples in the product documentation. This chapter will attempt to provide concrete examples. Typically, reports are designed to be dynamic and so have multiple parameters that drive how the report functions. There are two ways to handle parameters: either have the report viewer prompt the user for the parameters automatically or pass the parameter values via code. Which method you choose is determined largely by whether you want the users to pick their own parameter values themselves.
Using the automatic parameter prompting requires no extra code or configuration. Simply view a report using either the viewer class or tag library and a default parameter prompting screen is displayed. Alternatively, you can pass the parameter values by code. This involves creating a series of objects as outlined below.
The first step in passing parameter values is to create an instance of the Fields class. This is a container class for parameter fields. This and the other objects are found in the com.crystaldecisions.sdk.occa.report.data package. Next, create an instance of the ParameterField object. To determine which parameter you are setting values for, call the setName method passing in the name of the parameter. Then to set the parameter values, create an instance of the Values class, which is a container for parameter value objects. Finally, create a ParameterFieldDiscreteValue object and call the setValue method to pass in the actual parameter value. This collection of objects is then passed to the report viewer via the setParameterFields method. Listing 28.4 shows a parameter being passed.
Listing 28.4. Passing a Simple Parameter
Because there tends to be a bunch of objects you need to create, a nice way to handle this is to wrap up the parameter logic into a function. Listing 28.5 provides a sample function like this.
Listing 28.5. A Sample Parameter-Handling Function
After you have a function like this in place, passing parameters looks as simple as in Listing 28.6.
Listing 28.6. Calling the Sample Parameter-Handling Function
Setting Data Source Information
Setting data source information works very similar to the way setting parameters works. There is a collection of objects that you create, which then gets passed to the report viewer. In this case, the method used is setDatabaseLogonInfos. This method takes a ConnectionInfos object, which is found in the com.crystaldecisions.sdk.occa.report.data package. The ConnectionInfos class is a container class for any data source information for a given report. Each connection’s information is held in an object called ConnectionInfo. This object has setUserName and setPassword methods for passing credentials. Also, each ConnectionInfo has a collection of properties associated with it called a property bag. The property bag contains information such as server name, database name, connection type, and so on. The property bag stores information in a name/value pair structure. There are variations as to what items are held in the ConnectionInfo, but the best way to figure it out is to look in the Set DataSource Location dialog from the Crystal Reports designer. There you can see which items are associated with a connection. Listing 28.7 shows how to pass logon information for a report.
Listing 28.7. Passing Data Source Credentials
Developing with a Visual Development Environment
Not only has Business Objects delivered a full Java reporting offering with the Crystal Reports Java Reporting Component, but it also provides integration with some of the major Integrated Development Environments (IDEs) in the market to drive developers to build applications with the Java Reporting Component more quickly. The vendors Business Objects is currently working with on IDE integration are BEA and Borland. The integration consists of the following:
- An integrated project item for reports. This enables developers to add a report to their projects easily. It launches the Crystal Reports designer to edit the report automatically.
- A report viewer wizard. This is a visual wizard that walks users through the process of adding the report viewer tag to their JSP page.
Figure 28.6 shows the integration info BEA WebLogic Workshop and Figure 28.7 shows the integration into Borland JBuilder X. There are various other plug-ins to the IDEs as well that can be explored, such as automatically importing the Crystal libraries and configuring the web.xml.
For more information on IDE integration into these and other developer tools, visit the Business Objects website.
Figure 28.6. The Java Reporting Component integrated into BEA WebLogic Workshop.
Figure 28.7. The Java Reporting Component integrated into Borland JBuilder X.
Troubleshooting
Version 11 JDBC Driver
I can’t seem to find the version 11 JDBC driver.
This is not yet available at the time of this writing but should be available soon. You can check for status updates on this by visiting the Business Objects Download Center at http://www.businessobjects.com/products/downloadcenter/.