REPORT TIMEOUT TROUBLESHOOTING

TIMEOUT TROUBLESHOOTING

SSRS report timeouts in AX 2012 are often caused by inefficient code/query design in AX. To identify where the bottleneck is, we need to debug and explore the SSRS logs.

DEBUGGING

Before we get started, you need to make sure you have the right components to debug.

To debug Report Data Provider (RDP) classes, you must be on the Application Object Server (AOS) machine and that same machine must have the SSRS instance installed. Also the AOS must be setup for debugging.

SSRS reports in AX can get data from one (or more) places:

• AX query
• AX Report Data Provider
• An outside data source

Debugging a Query can be tough, as it simply pulls data from the AX database from an AX query object in the Application Object Tree. See the section below on query optimization for techniques on improving query performance.

To debug a report based on an RDP, set 

a breakpoint in that report’s processReport method.

Observe the behavior of the RDP class using the same parameters as your report users to see where your bottlenecks are.

SSRS LOGS

You can view the logs on the SSRS server to get more details on a timed out report. The logs can be found on the SSRS Server at \Program Files\Microsoft SQL Server\MSRS10.<Instance Name>\Reporting Services\LogFiles.

Reviewing SSRS logs will provide more information than AX infolog dialogs in many cases.

If the log doesn’t provide enough information, you can increase the DefaultTraceSwitch setting in theReportingServicesService.exe.config file. The file can be found at \Program Files\Microsoft SQL Server\MSRS10.<Instance Name>\Reporting Services\ReportServer\bin.