SAP Crystal Dashboard Design 2011 - Portfolio Update #4

SAP Crystal Server 2011 - Update #6

Question: How do you execute a complete rewrite of the worlds leading reporting tool to ensure it's viable for another 20 years?

Answer: Very carefully.

The Crystal Reports codebase has proven to be very reliable and valuable to our customers over the last 19 years since we released version 1.  I'm sure there's code in there today that was first released in that original version back in 1992 for 16-bit Windows.

However this is software, and development standards evolve, get better, and help developers be more productive.  Products stuck on older code bases cannot keep up with new entrants on more modern and productive code bases.  These products simply fade away as they fail to keep up with the rate of innovation that's possible with more modern development standards.

We are determined not to let that happen with SAP Crystal Reports.

The 'Small Ball' Strategy

So over the last 7 years, we've been effectively building 2 versions of SAP Crystal Reports - the C++ stack with all the bells and whistles that's sold to our valued customers, while investing in our 'next gen' stack.  We used a strategy I called 'small-ball' - in reference to how baseball teams can be effective using singles, stolen bases, and bunts.  We wanted to avoid a risky big-bang migration where we might get something to market early, but spend the next 3 years issuing service packs to address issues instead of innovating.

With small-ball, we used smaller releases like SAP Crystal Reports for Eclipse and the Crystal Reports Viewer to validate our engineering, learn from real-world experience, and always move forward toward that goal of bringing next generation Crystal Reports to market.

Now that our next gen product (SAP Crystal Reports for enterprise) is surfacing publically on blogs and in products like BI 4.0, I thought it was time to share some of the interesting roadmap decisions that have happened behind the scenes.

The Evolution of Next-Gen Crystal Reports

The next-gen stack is based on Java, and got its start in 2004 with the Java Runtime Component (JRC) that was part of version 10.  At that time, it was a simple runtime engine to execute reports authored with CR 10.

In 2006 we built on that base and created Crystal Reports for Eclipse 1.0.  This took the JRC and added a basic report design tool.  It was this release where we adopted the SWT programming model in Eclipse for our next get stack, and the fabulous Eclipse plugin architecture.  We got the confidence that we could efficiently build a report designer using this technology.

In 2008 we delivered CR for Eclipse 2.0, adding editable preview.  We also delivered the Crystal Reports Viewer as a free download.  This was a key milestone as we got confidence that we can render RPT files just as accurately in the next gen stack as we do in the C++ stack.  We used these products to improve the performance and compatibility aspects of the next gen stack.

SAP Crystal Reports in SAP BusinessObjects BI 4.0

Finally we had the confidence in the next gen stack that we could make the jump to our paying products.  In the design stage of the BI 4.0 release, we knew that the jump from CR for Eclipse 2.0 to a product that does everything that CR 2008 does for both the volume and enteprise market was too big. So we focused on the needs of Enterprise customers because we have a better ability to service them through our maintenance offerings.  Plus there's a natural way to narrow the scope of the release if we're going to focus on enterprise-only solutions.  We'd limit data access in the BI 4.0 release to Universes only.  This would allow our developers to focus on creating great Universe based data access and correcting a longstanding weakness in Crystal Reports.  Direct to data access would not be going away - we'd still have Crystal Reports 2011 for that, plus we'd plan to restore it on the next gen stack in a point release.

Along the way we got important validation of our early design choice of SWT/Eclipse as the platform for our next gen stack, as the new Information Design Tool (for editing next gen Universes) also adopted the same architecture.

Now that BI 4.0 is done (from a development perspective - it's still in rampup as I write this), we can look ahead to 4.1 and 4.2 where we will be addressing the compromises we had to make in 4.0.  In these forthcoing point releases, we'll be building direct to data access, public APIs, and creating a scalable runtime engine solution that will allow for deployments outside of the BI Platform 4.x.

If you're a volume customer (ie... purchase through resellers or our eStore) and looking at CR 2011 you're probably a bit disappointed that there isn't more.  The reason isn't because we don't place a priority on volume customers - it's actually the opposite. 

The volume market is the most demanding market there is.  Volume customers expect great, intuitive usability, APIs, and fast component runtime deployments without having to go through a big enterprise sales cycle, or pay for annual maintenance.  In the volume business, there isn't a small army of friendly account executives and solutions consultants to talk through product issues.  The product must work the first time.  Its for these reasons that we're starting this rollout with server software that's commonly used by larger customers.

Looking Ahead

The 4.x platform will be the platform of continuous innovation of the next gen stack.  Major features will be added with each point release, and we will deliver next gen technology to the volume market using this 4.x platform as a foundation.  Initially, customers of the BI Platform 4.0, Edge BI 4.0, and SAP Crystal Server 2011 will have access to the next gen report design tool - called 'Crystal Reports for enterprise'.

If you want a taste of the innovation this modernization will provide, check out this great video by our user experience team on the Smart Guidelines feature in the next gen design tool.

I know that things look a little weird right now - with 2 Crystal Reports products in the 4.0 stack - one called SAP Crystal Reports 2011 and the next gen product called SAP Crystal Reports for enteprise.  Be assured this is a temporary situation.

Once we've met the key volume requirements to the next gen tool - like direct to data access, a component runtime engine, and an API - we plan to release next gen Crystal Reports to all our channels and direct 100% of our efforts to innovating on this modern platform for your benefit.  We expect that this release will include an extended beta program to ensure its success.

Once it's GA, we'll then revert to using the next-gen stack as the single version of Crystal Reports for simplicity and clarity.  Whether next-gen Crystal Reports is Crystal Reports 2012 or 2013, I can't say for sure now. 

If we can execute on this (and I have no doubt that we can), we'll have pulled off a rare feat in software - renewing the underlying technology of a market leading product, so we're not just the oldest and best known reporting tool, but also the most modern and innovative.

SAP Crystal Solutions 2011 Portfolio Update #1

SAP Crystal Reports 2011 and Developers - Update #3

Over the years, we've heard about the requirement to protect report designs, and have taken a few, mostly unsuccessful attempts at addressing this.

In SAP Crystal Reports 2011, we've delivered a much more effective solution to this problem.  This is what the new export to RPTR feature is for.

RPTR is a read-only RPT file. It cannot be opened by any report design tool, but it can be opened and executed by most of our viewers.

The objective of this feature is to create a mechanism for partners and developers to share their reports, while preventing downstream users from modifying them. Here's a couple of examples:

1) A reseller wants to promote their report design skills without giving away some of their design techniques, so they export their report to RPTR with saved data to demonstrate to their prospects with SAP Crystal Reports Viewer 2011.

2) An ISV includes with their application some reports, but they don't want end users to modify them for support reasons. So the ISV exports the reports to RPTR and they're viewed with the .NET 4.0 report viewers (Webform, Winform, and WPF alls upport RPTR).

Viewers That Support RPTR Files

These viewers can open and execute RPTR files:

• SAP Crystal Reports Viewer 2011
• Viewers included with the SAP BusinessObjects BI 4.0 Platform (including SAP BusinessObjects Edge BI and SAP Crystal Server)
• All viewers included with SAP Crystal Reports for Visual Studio 2010, including the Winform, Webform, and new WPF viewer.

Data Source Considerations for RPTR Files

While all data sources are supported with RPTR files, there are some special considerations around datasource set location.

Set location is disabled for RPTR files. If you need to modify the datasource location at runtime, we suggest the following techniques:

1. Use ODBC or OLEDB data connection, and ensure the DSN used is exactly the same as the one used at design time.
2. Use an ADO.NET data connection, and push the data into the report.

Other Considerations for RPTR

• Manually renaming the RPTR file to a RPT file won't make it readable.
• There is no way to convert a RPTR file back to a RPT file. It's a one-way trip.
• Data refresh, printing, exporting, prompting all behave the same way as an RPT file.
• In the viewers, you cannot export to RPT if you're viewing a RPTR file.

That's a quick summary of the RPTR feature - give it a try and let us know what you think!