Applying changes and client readiness

In the best practice of development in MS Dynamics AX™ you would normally work on a development environment, test your customizations on a test environment and eventually apply the customization on the production environment.

It is obvious that following the best practice minimizes (I dare say eliminates) the risks involved in making changes to the system. However, two small issues should be kept in mind when you apply the changes to the production environment:

1. The client object cache.
2. The client usage data.

These two issues are related to changes to classes and to changes to the packed objects respectively. To further explain, when you apply changes to forms for example, you can make the client ready to use these changes by simply closing the client and running it again. But when your changes involve:

1. Changes to classes.
2. Changes to the CurrentList local macro (used when packing report or query parameters).

you need to do some extra work to make the client ready (i.e. get the client to “know about” the new changes).

Symptoms of the problems caused by applying such changes are:

1. The system gives results on the client as if nothing have changed (or even sometimes issue an error message which indicates that your code is missing).
2. You get a run-time error in the pack/unpack methods of a report or a class.

To resolve these issues you need to do the following:

1. Clear the client’s object cache: Go to the users application data folder (C:\Users\<User Id>\AppData\Local) on Vista, Windows 7 or Windows Server 2008, (C:\Documents and settings\<User Id>\Local Settings\Application Data) on XP. Delete the file ax_{GUID}.auc, where GUID is some system generated alphanumeric Id. Note: If you are using terminal services, this folder will be found on the terminal server.
2. Clear the client’s usage data: On Dynamics AX, go to the user options (Dynamics menu –> Tools –> Options). Find the usage data button, click on it and another form should appear. In the “All usage data” tab, find the object that you changed and delete its corresponding usage data. Or you can simply go to the “General” tab and reset all usage data (which I don’t recommend).

One remark that I have to point out here is that these issues (to the best of my knowledge) should be dealt with one client at a time. I currently don’t know how this solution can be mass-deployed. Luckily I didn’t need to do that for more than a few clients.

A tip on BI in MS Dynamics AX™

Recently I’ve been working more closely on BI concepts and SSAS analysis cubes. One thing I can tell you is that when working on analysis cubes it is a good idea to test your cubes (or process it) using a small sample of the data.

Working on a large database (similar to those we find in production environments) can give you a feeling of how the performance would really be. However, in development, this can give you a hard time, because every time you process a cube it takes considerable time during which you’d mostly be idle.

Luckily in MS Dynamics AX™ we have a very easy way to delete the transactions of the system (keeping the master data intact). So, you can export some of the transactions on which you’re going to do your analysis (preferably data whose results are already know to you) , delete the transactions and import the data back in to the system.

For those who haven’t yet used this class, you can find it in the AOT, expand classes and locate the class SysDatabaseTransDelete. Right click on it and click on open on the context menu.