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.

Recurring batch job import in AX 2012 R3

I was reading an article about the Data import export framework in the new Dynamics AX (AX 7) and it mentioned that the DIXF can be setup with an input folder. Any file placed in the input folder is processed and imported. Then it was pointed out to me that that function is also available in Dynamics AX 2012 – I’d just never noticed the setup options.

Mostly when we’re using the DIXF we’re setting up a new system, and most of our imports are “one-off’s” (although if you get away with as few as three data import cycles you’re doing well). But there are some business processes that rely on fairly regular data imports – for instance sales forecasts and sales prices are routinely imported into Dynamics AX and count as a ‘business as usual’ BAU import. So you might want to set these BAU imports up based on recurring batch jobs.

I’m doing this example based on a Price discount journal.

First I’ll check/setup my Target entity. Data import export framework > Setup > Target entity:

I’m going to do this example using a CSV file format import – but just a reminder that the DIXF can also import from XML or Excel files.

So next I need a processing group. I create a new processing group and use the Entities button to setup the target entity and import format. Data import export framework > Common > Processing group > Entities:

Next I’m going to define my import format and customise it slightly to simplify the import using the techniques I’ve described before ( here and here ).

I end up with mapping which looks like this:

And an input file which looks like this:

And when I preview my source file I see:

Excellent – my journal number and line number and Relation have defaulted correctly.

Now we are going to set this up as a recurring batch job – and that is done back on the processing group when you Get staging data:

Although you are offered a default Job ID you can enter your own, and a description:

Then click OK:

Now for the clever bit – we have ‘Processing directory’, ‘Completed directory’ and ‘Error directory’ parameters, but to make these active we first have to change the import Type from ‘File’ to ‘Directory’, that changes our ‘File path’ field to be a ‘Folder path’. I’ve got an input folder ready to use, and Processing, Completed, and Error directories:

And just to save another processing step I’m going to tick ‘Execute target step’, so that after my data is imported to the staging table, it’ll be copied to the target table automatically.

Now let’s set this up as a recurring batch job, and put it through its paces. Click Run and the familiar batch job setup form appears – you know what to do:

And of course when we click OK we get:

Incidentally you’ll notice that I’ve got into the habit of embedding the Company name in the job description – just makes it easier to search for. Systems administration > Inquires > Batch jobs:

First, let’s see what happens when the batch job runs and the input folder is empty:

I’m not sure that an error message is called for here, I would have thought an Information messages would suffice, and it looks like there’s already a fix available on LCS for this (KB3161169).

Although in my example the batch job history logs an error, the job keeps recurring, so now let’s place a file in the input folder, and wait patiently for the batch job to run again:

With a file to process we get a nice Infolog. And we can also see that in the Execution history of our Processing group:

The processing group execution history is cleaner than the batch job history, because here we’re only seeing the recurrences which processed files. Incidentally I did another test where I placed two files in the import folder, and both were processed exactly as I would have expected, but I don’t think you can rely on the DIXF processing the files in any particular sequence if you have multiple files.

Finally let’s just go and check that our sales price trade agreement journal got imported and is ready to post.

Sales and marketing > Journals > Price/discount agreement journals:


And of course we have our original input file now sitting in our ‘Completed directory’:

In order to make this a fully finished business process you’ll want to add in another job which will delete the staging data – you could do that as a second task in this batch job; and also you’ll want to tidy up the batch job execution history log by deleting those records after a few days. Housekeeping has become a bit of a hot topic in our office recently, and we’re all paying more attention to keeping the system neat and tidy.

Housekeeping in AX 2012. Alerts

Once in a while I find myself logging on to a customers site and notice that a huge number of Alerts have built up in the Notifications inbox.

If you have ‘Show alert status’ enabled in your status bar you see the number of Alerts like this:

This example’s nice and tidy, and it’s because there’s a very simple clean-up job that you can use.

Systems administration > Period > Notification clean up:

You’ll see that I’m using an Advanced filter query to delete Alerts that are more than 10 days old, obviously you can setup whichever queries meet your needs.

Then it’s a simple matter to set this up as a recurring batch job (don’t forget to disable the Alerts option on the job) and bingo your Alerts are under control.