Making sense of Crystal Reports SDK and APIs

If you are looking to integrate Crystal Reports into your application, you have many ways to go about it. You can find oodles of information about the different options, pros, cons, differences and user guides, tips and tricks galore in the product documentation and over the web. The purpose of this post is to cover some high level differences between some major choices, and explain in simple terms some key factors that I believe will play into your decision into which integration option to use.
First, you will need to take your pick of technology: .net or java. For most people this would be a no brainer since most developers are predisposed to one vs the other. Since my disposition is toward Java, I will cover the choices related to it, although the .net options are pretty much the same, there is an equivalent SDK/API in .net for every java options mentioned here (religious arguments aside…). You will face three major choices on how to integrate Crystal:
– Using openDocument API
– Using the Viewers Java SDK (which in itself contains several choices) or
– Using the RAS (Report Application Server) Java SDK (of course this branches as well)
Here are some high level descriptions of each of those options with some key considerations:
The openDocument API is the simplest and most common way to integrated pretty much any BusinessObjects content into an external web based application. It provides a variety of url query strings that can be used to call content from the BO repository, from webi, to crystal, dashboards and more. This API is simple to use, quick to integrate and develop with, and provide good level of customization and flexibility through the variety of parameters that can be processed over the URL. It requires no programming knowledge, and anyone with basic understanding of web technology can learn how to use it (the only caveat to that can be authentication). However, it does have limitations in terms of ability to customize and control presentation and behavior of the integrated content. For example, using the openDocument API, you will have very limited, or no control, over the many Crystal viewers choices you might want to control, such as control of prompts screens, group tree, or toolbars. You will also be passing all the information you will be feeding into the report (including a session token used for authentication) over the URL, in plain sight, which may pose a security problem for some applications.
So, if you are looking for better control of the viewer, and tighter security control, you might be looking at the viewers SDK next. The Viewers SDK does require some java programming knowledge, and in return provides much more flexibility and control over the report presentation and integration. It provides several implementation, including tag libs and JSF options, so can cater to several flavors. Using the viewers SDK developers can control report dimensions, display different tool bar options, and choose how to present and embed Crystal Reports in their web applications. It is a rich SDK, and can address most presentation needs. However, it too has some limitations in terms of the ability to manipulate more of the “guts” of the Crystal .rpt file. Enter the RAS SDK.
The RAS SDK is the richest and most complex Crystal java SDK, and provides the most flexibility, control and security. For example, using the viewers SDK, you may pass parameter values to the report object, but these would be passed through the viewer itself, making them visible to the client. While using the RAS SDK you can modify the report selection criteria on the fly, on the server side, before the viewer is even initiated and without passing to the client any parameter info. Of course, all this power means more complexity and more code that can be written to accomplish more sophisticated reporting use cases and integration scenarios.
So, which integration option is right for you? Consider your reporting use cases, the level of sophistication you require in your integration and your security requirements to determine if openDoc will suffice, viewer SDK will be needed for tighter integration, or full control is what you need, using the RAS SDK.