This part of the appendix is taken from another document that also deals with the creation and use of summarization data and frozen report data. It is necessary to use these methods if you are not using summarization levels for drill-down reporting. The term "report data" used
here refers to the data for a report as it is stored internally at the point of execution. The report may be stored as so-called "frozen report data". To calculate the size of the report data, see section . The example refers to an operating concern that contains, among others, the characteristics WW001,...,WW008.
Reports that contain a large number of characteristics and drill-down levels often result in report data of considerable size. In such cases it may take a long time for the system to display the data, and the memory required can affect the overall throughput of the application server adversely.
We therefore need to develop a technique for reducing the size of the report data.
Looking for the Unexpected
The basis for the method described below is the observation that users are often not interested primarily in seeing the values displayed at the various levels. On the contrary, they are looking more for so-calledexceptions in the report -- values that deviate considerably from what they would normally expect. They then follow these exceptions through the hierarchy of
characteristics to drill down to more detailed information.
Note: For details on exception reporting, see the online documentation Drill - Down Reporting in the section Special Report Settings.
These exceptions generally only make up a small part of the report data. Consequently, we can try to select and display only this part of the report.
48 With Pentium Pro 200 CPUs under Windows NT, performance of about 1.2 million records per hour (about 330 records per second) were observed in customer systems when the aforementioned prerequisites were fulfilled.
In this graphic, the two colored triangles represent two reports with the same layout. The dots represent exceptions to which the user drills down. The red dot at the intersection of the two reports has special significance. The "upper" report is already displayed at its lowest level of detail. Thus the user has to execute the "lower" report, the first level of which is this red dot broken down to the next level (the next characteristic).
Example: This situation can occur in sales analysis when the upper report contains a sales hierarchy, while the lower report shows the individual customers by salesperson.
Stacking Reports
To create this type of situation, one could proceed as follows:
• Define a single report layout by creating a form FORM. For this type of report, it would make sense to use a form with one axis and key figure. Global selection criteria (such as the periods to be displayed) should be specified already in the form (general data
selection.
• Using form FORM, define a report SENDER that contains the characteristics WW001, ...., WW004.
• Likewise, use form FORM to create another report, RECEIVER. This report should contain the characteristics WW001, ..., WW008. For the characteristics
WW001, ..., WW004, define local variables. When you execute this report, the system then displays a dialog box in which you can enter values for these variables.
• Now you can execute report SENDER (also in the background, using program
RKEBATCH, if desired). Let us assume that you drill down to the lowest level, where you have one exception remaining.
• To analyze this exception in greater detail, execute report RECEIVER. In the dialog box
"Enter Variables", enter those characteristic values for WW001, ..., WW004 that led to the exception displayed in report SENDER. You can now navigate in report RECEIVER through the characteristics WW005, ..., WW008.
This procedure obviously involves some unnecessary actions on the part of the user. First, you need to make a note of the characteristic values at the last level of report SENDER. Then you need to enter these for report RECEIVER. These actions obviously could be performed
automatically by the system. The function "Split report" in drill-down reporting makes it easy for you to define this.
The Function "Split report"
Instead of carrying out the complicated steps described above, it would be better to proceed as follows:
• Define the desired report (basic report or form report) and include all the characteristics you want to analyze (WW001, ..., WW008). Call the report SENDER.
• Now choose the function "Information system→Define report →Split" from the Profitability Analysis application menu. Enter the operating concern and report SENDER. In the dialog box that appears, enter the name RECEIVER for the new report, and select the characteristics WW005, ..., WW008 for this report.
• Now execute report SENDER (if desired, in the background using RKEBATCH). When you reach the lowest level of report SENDER, the system now displays an additional icon in the navigation block of the report. This icon lets you execute report RECEIVER as the
predefined receiver report for report SENDER. When you choose this function, the system uses the characteristic values specified in report SENDER automatically as the selection criteria for report RECEIVER. Thus the system automatically displays the right level in the drill-down sequence.
This simple method also gives you a suitable report pair that lets you analyze the desired exceptions. However, in this case the drill-down reporting to ol automatically replaces the variables in the receiver report, so that the person executing the report almost doesn't even see that the report has been split.
Note: For more details on splitting reports and using the report/report interface, see the sections Overview: Report/Report Interface and How to Use the Report/Report Interface in the online documentation. To read about how to use the hotspots that appear on the report screen, see Hotspots in the Report List. All these sections appear in the chapter Special Report Settings in the documentation Drill - Down Reporting.
Possible Variations
Remember that section was extracted from a document not dealing with summarization levels! All read accesses to CO-PA data are therefore considered to run against the segment level.
We have applied the following solution:
A group of characteristics "A" is used for the drill-down characteristics in a sender report. For this report, frozen data is selected and saved in the background. The other characteristics "B" are defined as drill-down characteristics in a receiver report , which can be executed online if desired.
If you use the report/report interface as in the example above, you will notice the following:
Sender report
• The time required to select the data for the sender report does not depend on the
characteristics chosen for this report (since all data has to be read from the segment level).
• The report therefore needs to be built in the background using program RKEBATCH.
• Therefore you will probably make the sender report as large as possible while still making it possible to display the frozen report data in an acceptable amount of time.
• Size limitation: If you want to be able to display the report in no more than one minute, the report data should not be larger than about 12 MB, according to the formula we postulated earlier.
Receiver report
• Frozen report data can pose problems for the receiver report, since the system stores one set of frozen data for each combination of characteristic values in the sender report that could be necessary for the receiver report.
• The critical factor for the receiver report is thus the amount of data that has to be read.
• Size limitation: If you also want to be able to display this report in no more than one minute, the number of sets should be limited to about 3000, according to the formula postulated earlier.
By shifting characteristics between groups A and B, you can vary the size of the sender and receiver reports. If the two size limitations cannot both be met, you need to modify this solution.