I work for SAP Business Objects in Technical Customer Assurance.  My speciality is the Software Development Kits (SDKs) that we provide with our Business Intelligence products - BusinessObjects Enterprise, Web Intelligence, Desktop Intelligence, Crystal Reports and Crystal Xcelsius. 

In my blog, I discuss subjects that I personally find interesting - little known or not-well-documented corners of the SDK, new functionality or new SDKs, or interesting issues that I've come across in a SAP Incident or SAP Developer Network forums. 

You're more than welcome to suggest any topic (SAP Business Objects SDK related, of course...) that you'd like me to discuss - I have a dozen or so items on my blog to-do list, but I'm always on the hunt for anything interesting with our SDKs.   

I'm keeping this blog entry short, since I find the subject matter pretty straighforward and simple. 

Crystal Reports for Eclipse Version 2 is now out!  Check it out here.

Driven by requests for more functionality in the Java Crystal Reports development sphere, the Java Reporting Component (JRC) SDK was deprecated and replaced with the Crystal Reports Java (CRJ) SDK.  "Deprecation" here means that the JRC is still supported with the CR4E Version 2 runtime, but that there's no guarantee of support for future versions.

So you need not immediately migrate your JRC code to CRJ, but I do encourage you to do so when you have the opportunity for the following reasons:

1. Take advantage of the new features of the CRJ SDK, a few of which I describe in my previous blog entry.
2. Ensure forward code migration to future versions.
3. The migration itself - I personally found - to be simple and straightforward.

Re-Package the Controllers

What makes the migration straightforward is that both the JRC and CRJ are based on the Report Application Server (RAS) SDK.  The JRC is a thin wrapper around the RAS classes, and CRJ is pretty much the RAS classes. 

Aside: you cannot use the CRJ SDK to connect to a RAS server - there's sufficient differences in the SDK and backend report processor to make the CRJ and RAS incompatible.  Any migration is purely code-level, and not binary level. 

The controller classes in the JRC API have identical names and methods to their CRJ equivalents, but they reside in separate packages.  Specifically, change the JRC package:

    com.crystaldecisions.reports.sdk

to the CRJ package:

    com.crystaldecisions.sdk.occa.report.application

for the interfaces IDataDefinition, IReportClientDocument, ISubreportClientDocument, and the classes DatabaseController, DataDefController, ParameterFieldController, PrintOutputController, ReportClientDocument and SubreportController.

 That's pretty much it for what I had to do when I migrated my sample code base.

Jar File Upgrades

The CR4E Version 2 runtime jar files have been repackaged - classes have been moved to different jars, and some jar files have been replaced.  There's no one-to-one correspondence between older JRC jar files and CR4E Version 2 jar files.

When upgrading your Java application, ensure you remove all older JRC jar files, and update them with all the CR4Ev2 runtime jar files.

From experience, leaving older versions around after upgrade will lead to breakage.

Web Application Environment

If you're using the DHTML viewer (CrystalReportViewer) that comes with CR4E Version 2, then you'd need to modify some environment configs.

In older versions, any user actions on the DHTML viewer would result in a postback to the Servlet of JSP generating the CrystalReportViewer class instance.  Any embedded images or charts in the reports would post back to the crystalimagehandler.jsp page in the crystalreportviewers web folder. 

With CR4Ev2, the crystalreportviewers folder no longer contain dynamic content but just static files: JavaScript (.js), style sheets (.css), Flash (.swf, for parametre prompting), image files, HTML, and the ActiveX Print Control. 

Dynamic image retrieval and most user actions now activate client-side JavaScript to invoke the CrystalReportViewerServlet.   This simplifies the deployment of the crystalreportviewers folder - since it's pure static content - and issues related to having dynamic binary content streamed from a JSP pages are now eliminated.

There's a few implications from the introduction of this new servlet:

Register the CrystalReportViewerServlet in the web.xml file

You have to specify the viewer servlet in web.xml, and register the URL that the viewer writes out to be handled by the servlet.  Here's a copy of my web.xml file:

The web.xml with CrystalReportViewerServlet registered
<?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <display-name> CRJWebPreview</display-name> <context-param> <param-name>crystal_image_uri</param-name> <param-value>/crystalreportviewers</param-value> </context-param> <context-param> <param-name>crystal_image_use_relative</param-name> <param-value>webapp</param-value> </context-param> <servlet> <servlet-name>CrystalReportViewerServlet</servlet-name> <servlet-class> com.crystaldecisions.report.web.viewer.CrystalReportViewerServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>CrystalReportViewerServlet</servlet-name> <url-pattern>/CrystalReportViewerHandler</url-pattern> </servlet-mapping> </web-app>

You can no longer trap client actions in the CrystalReportViewer

With previous versions, some coders used to trap user actions on the DHTML viewer by inspecting the HTTP Request coming into the CrystalReportViewer instance (one example were people trapping the request to see if the event target contained the string 'tb=crprint' to see if printing was requested). 

Such code will no longer work, since postback no longer goes back to the CrystalReportViewer instance, but to the CrystalReportViewerServlet.   The new workaround is to wrap the CrystalReportViewerServlet, and trap requests going to that servlet.

Report Clean-up

There's no changes to report clean-up workflow, as described in my blog entry here.  You still need to close every opened ReportClientDocument instance, and dispose every ReportSource.

Note that the CrystalReportViewerServlet does cache a reference to the ReportSource object in HTTP Session - however, what's cached is a reference to the ReportSource assigned to the CrystalReportViewer, so caching your copy of the ReportSource in  HTTP Session and retrieving and disposing it as described in the previous blog still works to clean up the report.

Summary

Migrating from JRC to CRJ is relatively simple - a change in a package name and change in web.xml configuration.  Although the JRC SDK is still supported with CR4Ev2, I do recommend migrating when you have the opportunity, to take advantage of the new API.

One of the cool new API's is DatabaseController.replaceConnection(....) - the old setTableLocation(...) method could be a bit of a pain to work with, especially with stored procedures or subreports, and replaceConnection is much friendler.  I'll try blogging about it in the near future.