Book Image

Developing SSRS Reports for Dynamics AX

By : Mukesh Hirwani
Book Image

Developing SSRS Reports for Dynamics AX

By: Mukesh Hirwani

Overview of this book

<p>SQL Server Reporting Services is the primary reporting platform for Microsoft Dynamics AX. Nowadays every business demands reports ranging from showing an aggregate view of their business performance to the transactional data formatted in a way that can be easily filtered, printed, and emailed. SQL Server Reporting Services allows you to do all this and more, quickly and easily.</p> <p>Developing SSRS Reports for Dynamics AX 2012 covers all the technical aspects of AX 2012 reporting, taking you through various step-by-step guides to quickly develop reports. It encapsulates various real-time scenarios and walkthroughs which will guide you step-by-step to develop reports. You will then go on to learn about various performance-related measures to help you develop or customize reports for Dynamics AX 2012 more efficiently.</p> <p>Developing SSRS Reports for Dynamics AX 2012 is completely based on Microsoft Dynamics AX 2012 report development. Developing SSRS Reports for Dynamics AX has been written in a way to make reporting complex components quicker and easier. You will come across day-to-day scenarios to perform report development.</p> <p>Learn various mechanisms of developing reports in Visual Studio for Dynamics AX 2012. Develop reports using various types of data sources like AOT Query, external data source, and Report Data Provider class. You will also learn various performance enhancement techniques that will help you to manage complex reporting requirements.</p>
Table of Contents (17 chapters)
Developing SSRS Reports for Dynamics AX
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Common SSRS Expressions
Index

Best practices for AX 2012 report development


In this appendix, we will learn about the best practices followed for all reporting objects.

Report table

The following points must be kept in mind while developing reports:

Do's

  • While using the SrsReportDataProviderPreProcess class as RDP, use the Regular table to insert data in the reporting table. Also, set the CreatedTransactionId property to Yes.

  • Use TempDB tables when dealing with a large amount of data.

  • Use Extended Data Types (EDT) for the temp table fields so that the labels and other properties would be automatically handled by the report framework when the report is rendered.

  • Provide proper labels to the fields, in case EDT is not used for a field.

  • Provide proper indexes.

  • Provide table relations to the foreign key fields, to enable Auto links to the report. It helps to drill-through to the master form.

Don'ts

  • Use the TempDB or InMemory table as the reporting table while using the SrsReportDataProviderPreProcess class as RDP

  • Use the Regular table when extending to SrsReportDataProviderBase

The RDP class

The following points must be kept in mind while developing reports:

Do's

  • When dealing with a complex query involving multiple joins, use the RDP class to insert data into the temp table and render data onto the report.

  • When dealing with a large amount of data, use the SrsReportDataProviderPreProcess class.

  • Use a user connection at the beginning of the processReport() method while using the SrsReportDataProviderPreProcess class as RDP.

  • Perform database related functions to be executed on the server only.

  • Use the processReport() method to process business logic. Also, set SysEntryPointAttribute at the beginning of processReport().

Don'ts

  • Use RDP if a dataset can be generated by a query

  • Use client based operations like printing information, warnings, or errors

The Contract class

The following points must be kept in mind while developing reports:

Do's

  • Use the contract class to add parameters to the report

  • Perform a validation to check if all parameters have correct values, or to check the mandate parameters

Don'ts

  • Provide labels if they can come from EDT

The Controller class

The following points must be kept in mind while developing reports:

Do's

  • While dealing with multiple designs, use the controller class

  • Use the controller class to modify contracts

Don'ts

  • Process business logic in the controller class

  • Send the dataset to the RDP class

The UI Builder class

The following points must be kept in mind while developing reports:

Do's

  • Use the UI Builder class when a specific UI is required to be rendered before the report generation.

  • Use the build method to add all dialog fields to the report dialog.

  • Use the postRun() method to override dialog fields behavior. For example, providing lookups and modified events

Don'ts

  • Modify contracts in the UI Builder class

  • Control visibility of parameters in the UI Builder class

Report design

The following points must be kept in mind while developing reports:

Do's

  • Use templates for designing reports to provide a report presentation across the system

  • Use labels in Caption and Description properties for report controls

  • Use Auto Design for all simple reports

  • Use a proper report name, so that it can be easily referred back in AOT

Don'ts

  • Use Auto Design for form based reports like Invoice or Confirmation reports, where a field's position has to be set to a value, instead of Auto

  • Include a report design in the report which is not used

AOT queries

The following points must be followed while developing reports:

Do's

  • Provide a field list while creating a query, so that only required field values are selected

  • Provide proper relations when joining data sources

Don'ts

  • Use Query directly in a report which has multiple joins and grouping, instead use the RDP class