The SSRS warmup class in Dynamics AX

Thanks to my colleague Frankie Zhao for giving me this one.

We’ve all noticed that the first time you do something in Dynamics AX it takes a bit longer than normal – and in the case of an SSRS report that bit longer can be quite a bit longer, so I was pleased to come across the SSRS warmup class a while ago.

See the TechNet details here.

Unfortunately, I didn’t carefully read the whole article, because the first two sections talk about how to setup a batch group and a batch job – and I didn’t think that that was particularly complex:

In Dynamics 365 for Operations: System administration > Setup > Batch group In AX 2012: Systems administration > Setup > Batch group
In Dynamics 365 for Operations: System administration > Inquires > Batch jobs In AX 2012: Systems administration > Inquires > Batch jobs > Batch jobs

File > New:

Batch job > View tasks:

View tasks:


Ctrl-N / File > New:

And add the row:

Note the name of the class is SrsReportServerWarmup.

And add the row:

Then define a recurrence, (for instance run on each working day at 7:45am).

Batch job > Recurrence:


And finally change the batch job’s status to ‘Waiting

Batch job > Change status:

Functions > Change status:

(Just click on the required status).

So, imagine my disappointment that after setting this up in a brand shiny new Dynamics AX implementation, I logged in first thing in the morning and noticed that the main report that the users were going to use didn’t actually open any faster than normal.

And the reason is staring us in the face in the TechNet article:

When the SRSReportServerWarmup class runs, it prepares the report server for use by running a sample report that is named SRSReportServerWarmup. You can customize the SRSReportServerWarmup class so that it runs additional, specific reports.

For example, assume that Phyllis, the Accounts Payable manager in your organization, runs the Vendor Aging report every morning. To ensure that this report renders quickly for Phyllis, you can customize the SRSReportServerWarmup class so that it runs the Vendor Aging report every morning. To do this, you’ll need to create a new method that runs the Vendor Aging report and then configure the SRSReportServerWarmup class to call this new method.”

What this job does is to save a copy of the report ‘SRSReportServerWarmup.AutoDesign’ to a PDF file in the system’s temporary directory, but your user’s won’t really derive any benefit from this job unless you customise the class to run those reports that the users actually run. However, beware that you aren’t exposing any sensitive data by creating a file in a folder that everyone has access to, so give some thought to the parameters that you use to run your warm-up reports.

2 thoughts on “The SSRS warmup class in Dynamics AX

  1. That class should not be used anymore
    Ax2012, introduced class SrsReportDataProviderPreProcess class as the solution for long running SSRS reports that cause SSRS time out. The approach is to process data in Ax session before calling SSRS. The preprocessed data stored in a regular SQL table shared by all user sessions, only to be striped by session id. That approach creates a bottleneck in case of many concurrent user sessions.
    R2, introduced this new class to allow use of the tempDB to carry the report data across sessions, from the Ax data processing session to the SSRS data retrieval session.
    The AOS kernel will not purge tempDB table when a session ends and leaves that it to application code to clean up the tempDB table.In case of reports, this base class will take care of the clean-up.
    You should stop use of the old SrsReportDataProviderPreProcess class and use the new base class instead for long running reports. You will see a performance gain in case of multiple concurrent sessions on the same report.
    Currently there are many OOB Ax2012 R3 reports already take advantage of this feature.
    You can check out how those leverage the feature. One typical example is TaxListDP class.
    This R3 feature is implemented in the kernel. The usage is not limited to reporting.


Comments are closed.