How I fooled myself for 5 years…

I’m working quite a long time at a customer now. In August 2013, I was (re)hired to help on a migration from Dynamics AX4 to Dynamics AX 2012. As I had worked at this customer before, I know about some issues related to performance of the ledger balances. Now in AX2012 the update of balances were different. During posting of accounting entries, records in a table called “Dimension set unprocessed transactions” are inserted. A batch job will take care of updating the balances. Now how did I fool myself?

The background

I have written about this topic in the past as well. That post was related to performance which can be read here: “Rebuild balances in ax 2012 – Do you have a minute or more…”

Update of balances should be scheduled as a batch job to have the dimension set balances updated. When opening e.g. the Trial balance list page, the update balances job is also run for the dimension set selected on the list page. This is real-time processing and the user has to wait for this job to be completed.
The reason for this is to ensure that the report is mentioning the latest actual amounts. I had checked the behavior and noticed that the records related to the selected dimension sets were indeed processed and updated in the balances. Other unprocessed transactions did remain in the table. Now closer to the point where I got a wrong assumption…

When you plan for scheduling a batch job, you will be prompted with a Financial dimension set. At this customer we do have more than 20 dimension sets active. We decided to plan the 10 most used dimension sets to run every 10 minutes. Effective it did start one each minute. Sounds logical, right?

The clue

There were some blockings on the balance tables and I started the investigation where it came from. I thought, we possibly also had to schedule additional sets. But then also consider available threads, avoid possible deadlocks, etc. During measurements, I noticed that all unprocessed transactions were picked up by one single batch job which was (I thought) set to run only one dimension set. This appeared to be true. I also have checked the coding of the class which handles this batch job. Indeed, it is NOT using the parameter when running in batch. Even the default task description of the batch job is giving you the idea that it runs for a single dimension set. It is only used when you run the update balances manually on the client. So, in fact, we did already run every dimension set for every minute… Now we changed the batch settings to run only one batch job with a given recurrence which gives the batch jobs form a better overview with less tasks.

What about the blockings?

Well, we have to find out if the blockings were caused by a full rebuild due to a consolidation or year-end process. Possibly there will be a need to be able to not only rebuild for a given company or dimension set, but also a given fiscal year or even a shorter period. But this will be part of a further analysis…

That’s all for now. Till next time!