Best Practices for Designing Reports
Applies To: Microsoft Dynamics AX 2012 R3
This section provides best practices and guidance for creating Microsoft Dynamics AX reports, including how to make a sequence of decisions on the data access, controls, and design for the report.
Elements of Report Design
Data access determines the source of the report’s data set. The data access options for a report include:
AX Query – A modeled solution for data access.
X++ Business logic – Use Report Data Provider (RDP) classes to produce a data set.
Controls determine how inputs (parameters) are passed to the report. Controls include:
Query Ranges – data set filters defined on the AX Query.
Data Contract – filters for data sets generated from X++ Business logic.
UI Builder – fully customizable dialogs
Design determines the document layout template of the report. Options for the design include:
Auto Design – modeled solution for basic layouts
Precision Design – flexible solution for advanced layout
.png "Elements of a report")
Sequence of Report Design
A report’s data access type determines which controls can be used, and the controls chosen affect the layout of a report, so the elements of a report should be chosen in this sequence.
Data Access
Controls
Design
.png "Report Development Sequence")
General Best Practices
The following table provides additional general best practices for developing Microsoft Dynamics AX reports.
Best practice |
Additional information |
|---|---|
Use query based reports when possible, for best performance. |
A query to access data has the following advantages:
|
Return a TempDB based temporary table when appropriate. |
In-Memory tables are not a SQL based concept so the performance is slower than when you return a TmpDB temporary table. This is especially true for large datasets. |
For calculated fields, use a view wrapped in a query. |
Views provide the ability to add calculations. For more information, see View Overview. |
Keep business logic as close to the data as possible. |
This promotes reuse of business logic. When the business logic filters data, less data is moved through the system and demands fewer resources. |
Use a precision design for all reports. An auto design is a good start point to create a precision design for a report. An auto design will not create medium or complex reports. |
For more information, see How to: Create a Precision Design for a Report and How to: Create an Auto Design for a Report |
Do not define a sort or a group in a Microsoft Dynamics AX query. |
The dataset returned to SQL Server Reporting Services will be flattened. Use sort and group in the Reporting Services report definition. For more information, see Working with Data Regions. |
Use RDP class based reports when calculated fields in a view perform poorly. |
In reports where there is reuse of one or more expensive calculated fields, performance might improve when you use temporary tables to cache data. For more information, see How to: Use a Report Data Provider Class in a Report. |
Avoid using RDP classes when the data for the report is in a table and the report dataset can use the table. |
RDP classes provide extra flexibility but also introduce complexity and potential performance degradation. Use an RDP class when the report data needs to be calculated and complex business logic is required to define the data for a report. When the report data is accessibly in Microsoft Dynamics AX tables, then use a query and display methods or use a view. |
Additional details
The following topics, which provide further details on choosing the data access, controls, and design for reports, are found in this section:
Considerations for Creating a Report
Guidance for Choosing the Data Source Type
Best Practices for Report Performance
Coding Guidelines for Reporting
Announcements: New book: "Inside Microsoft Dynamics AX 2012 R3" now available. Get your copy at the MS Press Store.