Whether you choose single or multiple report bursting, eventually you will want to deliver the results to your users, and if you are delivering a custom application solution, that means understanding the object model around publications.

A publication object appears in a BOE folder just like a report does, and like a report, it too has historical instances. But whereas a report instance represents a snapshot of the report with data, a publication instance is a container that further holds (you guessed it) the report instances themselves.

The great thing about BOE publication architecture is that the report instances held in a publication instance are automatically filtered to the report instances the currently logged in user has been “bursted.” In other words, it makes no difference if a user has rights to the folder in which the publication resides; he/she must have been named (or at least the user group to which he/she belongs must have been named) as a burst recipient in the publication. » Read more: Business Objects Bursting SDK – Part 2

If you ask the SAP developer support, they will say it’s not supported. However, there are complex Crystal Reports that renders properly in ActiveX viewer.

The only option right now is to use InfoView’s URL reporting. This is ok but there are a few places where this can get you into trouble. For example, let say your J2EE application is on the DMZ and your BOE server is inside of your corporate network. The firewall will only let certain ports (e.g. 6400) and no http requests. In case of URL reporting, you would have to call <BOE server>:<http port>/businessobjects/viewrpt.cwr from your J2EE applications. This will not work. In most cases, opening http port so that ActiveX viewer would work is not an option.

Here’s how to setup URL reporting as a part of you own application.

1)  copy crystalreportviewers folder from infoview /businessobjects/viewers folder and place it in the root of your J2EE application

2)  copy WEB-INF/lib/reportsourcebridge.jar from InfoView application and place it in WEB-INF/lib folder of your J2EE applicaiton

3)  Edit WEB-INF/web.xml to include

<context-param>
<param-name>crystal_image_uri</param-name>
<param-value>/crystalreportviewers115</param-value>
</context-param>

<servlet>
<servlet-name>viewrpt</servlet-name>
<description>
Reportsource bridge used to support Java applet viewer and ActiveX viewer.
</description>
<servlet-class>com.businessobjects.crystalreports.reportsourcebridge.ReportSourceBridge</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>viewrpt</servlet-name>
<url-pattern>/viewrpt.cwr</url-pattern>
</servlet-mapping>

4)  Restart Tomcat

5)  You should be able to access URL reporting from <your J2EE application>/viewrpt.cwr

At face value this may look like a BOBJ marketing play on words. It is true that by implementing Edge, you can accomplish some of what will be discussed in this article. This is no sales pitch and that is not the point of the title. By taking Crystal reporting to the Edge, we mean:

1. Empowering report users to manipulate and store parameter sets.
2. Eliminating the need to leave applications to get reporting.
3. Delivering reports via web applications to people within and outside an organization.

Let’s address these points one at a time.

Parameter manipulation is one of the more tedious and essential parts of examining data. If you are still delivering reports in a static format, it is time to move to a viewer. Many report viewers including BOBJ’s free viewer allow for parameter sorts and drill downs. This frees up report designers to focus on bigger things than a slight change in product sets or financial categories that as they add up take days out of the year. Another critical thing to look for is the report viewer’s ability to manage complex and dynamic cascading parameter sets.

Once you deliver parameter manipulation prepare for the next expectation. If usually comes within days if not minutes of new empowerment. Users are going to want to store these parameters so they can pull them up on demand. Quickly they learn what it takes for a report to me changed to meet their needs, and just as quickly it is forgotten that someone else used to do it for them. Make sure that any report viewer you deliver allows users to store their parameter sets quickly and easily.

The next point is one of the most challenging both strategically and financially. Users want their reports on demand and in the same program that they use for day to day activity. Sure, most systems have their own reporting, but it is in a silo and, well, what did you buy Crystal for in the first place?

The complication is that you have to develop integration into the application. This can be a costly and complicated process as you struggle to manage the development of a secure connection. There are some third party tools that will work. The Crystal Developer Advantage team did a presentation in February with McManus Software. Their Report Launch product puts Crystal reports in any web application with a single line of HTML code. This eliminates the need to develop and they seem to have a low price.

This brings us to the final point; internet access to reporting is critical as more companies and more consumers expect to have on demand access to detailed business intelligence. To empower external viewers to view data from within systems, security is essential. Either upgrading to CR server or a BOE product will answer these requirements, but often this limits you to licensing within the tools. If you are using 3rd party security or want to use a system that manages permissions at an application level, you will need to develop or find a 3rd party tool like McManus Launch.

As you start moving your reports to the Edge and really begin to enable on demand report consumption, think about these three points. Proper execution will make every report more effective. Missteps will cost you your most valuable commodity…time.