During major AX version upgrades it is possible to lose a couple of EDTs, Enums, Relations, Fields on the way. We need a way to verify any missing or incorrect fields on Tables and Views and get them corrected, and the following job can help to find them:
Recently we have decided to merge two AX models sitting in different layers with overlapping objects as part of our code cleanup exercise, thus the requirement came to export AX model from code in a specific AOT layer only.
The following 3 object types has to be exported:
By providing the name of the model and the export path for the XPOs and labels, the following job can be executed to export AX model from code if you log on to the layer where the model is sitting:
As part of our code cleanup exercise we have discovered that there were menu items pointing to objects which no longer exists in our environments, ie. legacy reports which were upgraded to SSRS but their menu items were never removed.
The following job could be used to identify such missing objects for any of your menu items. I would also recommend to double-check the xRef references to find connected objects, like security privileges/roles, to completely remove whatever you do not need.
With so many new AX 2012 R3 implementations and upgrades and the soon-to-be-released AX 7 (Rainier) around the corner I thought it is time to get back in business to publish interesting articles, now using a new home for hosting my blog:
It is always recommended to write best practice error-free code, however in some cases Microsoft forces our hands to fall back to hardcoded values. This is the case with today’s topic as well, when we would like to override values in a SysOperation Framework Data contract.
The SysOperationServiceController.getDataContractObject() method has an optional parameter, where they expect the value of ‘_dataContract’ in the example below. However we can choose to refrain from hardcoding and extract the value with Reflection.
When we use the Microsoft Dynamics AX command line parameters to trigger a startup command with running the client, it is a very common situation that our metadata is altered.
There could be many scenarios where the metadata change requires user interaction (like a possible index violation, removing fields, etc) on a form, where you could review the changes before it is permanently committed to the database. This is not ideal if you would like to do automated tasks, like running a workflow step on a Team Foundation Server build controller (code / metadata synchronization, XPO import).
Fortunately there is a way of suppressing this user interaction, by setting a global variable.