Reduce the size and complexity of reports

Report Application Server .NET SDK Developer Guide

Your reports can be optimized to lessen the impact of report processing on the scalability of your application.

Use smaller reports

One way to optimize scalability in a RAS for .NET project is to reduce the size of your reports.

When possible, keep your reports to less than 15 pages. In Web applications, users often want to see only a few key pieces of data rather than pages and pages of data.

Reports used in desktop applications may no longer be appropriate for web-based applications.

To make reports smaller, use the record selection formula to limit the number of records returned to the report. This can be implemented in one of the following ways:

If you are creating a report using Crystal Reports for Visual Studio, the record selection formula can be hard-coded into the report with the Crystal Report Designer.
You can further filter the records that have been retrieved into the report programmatically.

If you use the CrystalReportViewer object model, use the SelectionFormula or ViewTimeSelectionFormula property of the CrystalReportViewer class.
If you use the ReportDocument object model, use the RecordSelectionFormula property of the ReportDocument class.
If you use the ReportClientDocument object model, use the RecordFilter property of the DataDefinitionClass class.

Use smaller graphics

Another way to optimize scalability in a RAS for .NET project is to use smaller graphics on the report.

Graphics do not need to be eliminated from reports when scalability is a factor, but they should be used sparingly due to their use of system resources.

When a report is displayed in a CrystalReportViewer control and the report contains a graphic (a chart or an image), the report engine must create a temporary JPG file (in the dynamic_images folder) and the browser must make a separate request to the Web server to retrieve it.

The CrystalReportViewer control also periodically searches through the dynamic_images folder for old images and deletes them. This disk access can reduce report performance. Using charts and images sparingly keeps the disk access to a minimum.

Redesign subreports to reduce demand

While subreports can often be used to create complex reports, they add considerable overhead. This doesn't mean that subreports shouldn't be used, but they should be used sparingly.

Also consider that when subreports are placed in sections that are repeated, such as group headers or the details section, each instance of that subreport requires its own report job. This means that a 100-record report with a subreport in the details section actually runs 101 report jobs.

Refactoring subreports as a .NET DataGrid control linked to reports

Subreports are frequently used in a summary/detail model:

The main report displays summary rows.
Each row links to a subreport that contains a detail report.

For summary data that does not need to be printed, consider presenting the summary data in a row list rather than a report. In other words, rather than use a report as your summary that links to multiple subreports for detail, use a .NET DataGrid control as your summary that links to multiple regular reports for detail. Using the .NET DataGrid control as your summary offers a simpler, more scalable solution.

To build this, bind a result set of data to a DataGrid control, with a link on each row id to the report. Only a single report is then used (with a parameter that accepts a unique id passed to it from the DataGrid row id's URL) for each row.

In this scenario, no report processing occurs when the DataGrid displays. Report processing occurs only when one of the links within the DataGrid is selected.

Don't use fields that block on-demand processing

RAS processes reports on-demand. For example, if the first page of a report is to be displayed, it only processes that first page, not the whole report.

However, inserting fields or formulas onto the first page of a report that depend upon the completion of the report processing prevents on-demand processing.

For example, if the Crystal Reports "Page N of M" special field is placed on the first page, the entire report must be processed to determine the page count before this field can be rendered. This causes the first page to wait until the whole report was finished processing before it can be displayed. The same behavior occurs when you use a percentage of summary calculations.

Consider not using these types of fields.

http://www.sap.com/sapbusinessobjects/

Support services

http://service.sap.com/bosap-support/

Created with the Personal Edition of HelpNDoc: News and information about help authoring tools and software