Crystal capabilities and real life usage scenarios – The Dos and Don’ts

[Former Member]

There are so many things you can do in Crystal in so many ways; it gives the impression that Anything is possible through it. But due to this very same richness you realize very soon that you will have to do Everything with your own hands. Nothing is assumed by the tool and the report comes out the way you want it- literally. Crystal is a developer tool and thus is not suitable for anyone who wants to create a bunch of reports to carry out his or her own analysis. One has to really know the full capabilities of the tool in order to design the report with the best approach (out of many alternate ways to come up with the same display). Here obviously I am not talking about simple crystal report based on a couple of tables and a simple display. For that one doesn't need an expertise in the tool, one can start creating simple reports after working on the tool for few hours.

Let me now discuss some common usage scenarios and some scenarios which should be avoided with Crystal:

Scenario- We all know that creating formulas, parameters, etc is possible in Crystal but when creating a crystal report on BEx Query try to create the restricted key figures (RKF) and calculated key figures (CKF) in BEx Query itself.

Why- It will help save some time on crystal side when running the report and also makes possible the reuse of CKF, RKF, and the variables already built once in the BEx query.

Scenario- If you want to create a report on ECC tables which involves many tables, it would help if you would first create an Infoset and then create a crystal report on it.

Why- It gives performance benefits as the data collection task has been delegated to the tool which is made for that and crystal does only the formatting and reporting.

Scenario- One should utilize Crystal for creating validation reports to reconcile the data between the ECC and BW.

Why- Crystal can access the ECC tables as well as the BW data through the queries and then can put the data together, thus providing the easy reconciliation report.

Scenario- Crystal can access a BW Cube directly but still the best practice is to create the Crystal report on the BEx query on top of Multiprovider (over the cube).

Why- Using BEx query helps in restricting the objects being looked at (out of all possible characteristics and key figures in a cube) and the information/records being fetched (by putting filters/variables at query level). Also as I have mentioned above one can reuse the objects/elements of BEx query.

Scenario- Crystal can access a BW DSO directly through the DSO driver but use this functionality only if you are comfortable with the restrictions that come with it and the limited utility it offers.

Why- DSO is mostly used for storing detailed and very granular information. It is just a flat reporting structure based on single table (here I mean Active Table). Thus the table is huge in terms of records as well as width. Thus the performance of crystal report will be affected. Also as it stores only the transaction data and the master data is present in separate tables, one will have to link to all the different tables to get the master data attributes and texts. Thus again additional joins will impact the performance.

These are some of the important scenarios to keep in mind when thinking about Crystal in SAP world (Crystal can be used for reporting on non SAP data too).  There are other scenarios too but I will discuss them later when we would have moved little ahead in our understanding of the whole BI-BOBJ integration world. Also for that one would need little more advance knowledge on Crystal. Thus it is a good idea to stop at this point though I promise to visit it at a later stage.

Please feel free to post any scenario you may have to discuss in the context of this post.