Master reports are like dynamic templates that you can design for use with content reports to help your users create consistent reports department-wide or company-wide. You design the master report with report items, code, data sources, and layout properties that cannot be modified in content reports, and add content placeholders in which your users can place their content.

Master Reports differ from templates in that they are loaded each time the report is executed. Therefore, a master report can be modified and the changes to the master report will automatically appear in any reports that reference it.

Advantages

• You can centralize common report functionality within master reports.
• Changes in company information (such as an address change or data source change) can be accomplished more quickly in a single master than if they had to be made to every report.
• You can create code, data sources, themes and page layouts to be shared across the application or enterprise.
• You can hide report complexity from end users who will use the designer application to create content reports.

Designing Master Reports

When designing a master report, you use report items, code, data sources, and layout properties in the same way that you do in a normal report. The major difference you see at design time is one extra report item in the toolbox: the ContentPlaceHolder. Use this report item to designate where users of content reports can add content to the template you've created with the master report. Content placeholders appear as disabled rectangles on the master report at design time. In the master report, you cannot place any content in these placeholders, but you can use the placeholder's Text property to convey to users of the master the intended purpose of each placeholder.

A master report is valid on its own, and can be run without a content report.

To prevent end users from modifying a master report, you can set permissions on the file to Read Only for that user or group.

Creating Content Reports

When the user creates a new report and selects the check box next to Select Master Report and selects your master report, the design view is effectively the opposite of the design view of the master report: everything except the content placeholder is disabled. Users see any report items in the master as disabled. Any report items overlaid by content placeholders are not visible in the content report at design time, but are visible at run time. The only areas to which users can add report items are the content placeholder rectangles.

A content report is not valid on its own, and cannot be run without its specified master report.

While designing the content report the user cannot:

• Modify or remove sections that exist in the master report.
• Modify the disabled (grey) areas in the master report sections.
• Remove a master report data source.
• Remove a master report dataset or modify its query.
• Modify the sort or filter on a master report dataset.
• Remove images from the EmbeddedImages collection.
• Remove parameters from the ReportParameters collection.
• Modify the margins or page settings of the master report.

  Note: Code in the master report is hidden in the content report, so in order to allow content report users to access code, the master report developer must provide documentation.

The user can:

• Add sections that do not exist in the master report.
• Add new data sources that do not exist in the master report.
• Add new datasets from a data source in the master report.
• Add images to the EmbeddedImages collection.
• Add parameters to the ReportParameters collection.
• Add any number of report items into placeholder rectangles designated by the master report.
• Modify the report name and description.
• Add new custom code that does not exist in the master report.

Run-Time Sequence of Events

Here is what happens behind the scenes when you run a content report.

1. Data Dynamics Reports loads the content report.
2. The loader parses the master report tag on the content report and requests the master report from the resource resolver.
3. The master report is loaded into the definition.
4. As each ContentPlaceHolder in the content report is parsed, it finds the corresponding placeholder in the master report and loads the content from the content report into it.
5. Data sources, datasets, and fields are merged. The master report has higher priority if there is a conflict.
6. Themes are merged. The master report has higher priority if there is a conflict.
7. Report properties from the content report are added to those of the master report. In the case of the following properties, the content report has a higher priority in case of conflict:
   • Report Description
   • Report Author
   • Report AutoRefresh
   • Report Custom
   • Report Language
   • Report DataTransform
   • Report DataSchema
   • Report ElementName
   • Report DataElementStyle
   • Dataset filters
   • Report Theme
   • Report Code
   • All content inside the content placeholders

Modifying an Aggregated Report Definition

When you run a content report, the content report and its master combine to form an aggregated report definition. Using the ReportDefinition API, you can save this aggregate at run time as a third report definition which has no master or content report. Once this aggregate is saved as a normal report definition (*.rdlx file) you can edit it as you would any other report definition.

See Also