It is highly recommended to run the standard Dynamics AX data consistency check from time to time, that is located in System administration | Periodic | Database | Consistency check, to check the system's data integrity. This function finds orphan data, validates parameters, and does many other things, but it does not do everything. The good thing is that it can easily be extended to match different scenarios.
In this recipe, we will see how we can enhance the standard Dynamics AX consistency check to include more tables in its data integrity validation.
Before we start, we need to create an invalid setup to make sure we can simulate data inconsistency. Open Fixed assets | Setup | Value models and create a new model, for instance, TEST:
Open Fixed assets | Setup | Fixed asset posting profiles and under the Ledger accounts group, create a new record with the newly created value model for any of the posting types:
Go back to the Value models form, and delete the previously created value model.
Now, we have a non-existing value model in the fixed asset posting settings.
Carry out the following steps in order to complete this recipe:
1. In the AOT, create a new class
AssetConsistencyCheckwith the following code:class AssetConsistencyCheck extends SysConsistencyCheck { } client server static ClassDescription description() { return "Fixed assets"; } client server static HelpTxt helpText() { return "Consistency check of the fixed asset module"; } public Integer executionOrder() { return 1; } public void run() { this.kernelCheckTable(tableNum(AssetLedgerAccounts)); }2. Open System administration | Periodic | Database | Consistency check, select the newly created Fixed assets option in the Module drop-down, and click OK to run the check:
3. Now the message displayed in the Infolog should complain about the missing value model in the fixed asset posing settings:
The consistency check in Dynamics AX validates only the predefined list of tables for each module. The system contains a number of classes derived from SysConsistencyCheck. For example, the CustConsistencyCheck class is responsible for validating the Accounts receivable module, LedgerConsistencyCheck
—for
General ledger, and so on.
In this recipe, we created a new class named AssetConsistencyCheck, extending the SysConsistencyCheck class for the fixed asset module. The following methods were created:
description()provides a name on the consistency check form.helpText()displays some explanation about the check.executionOrder()determines where in the list the check is located.run()holds the code to perform actual checking. Here we use thekernelCheckTable()member method, which validates the given table.
The classes we just mentioned can only be executed from the main Consistency check form. Individual checks could also be invoked as stand-alone functions. We just need to create an additional method to allow running of the class:
static void main(Args args)
{
SysConsistencyCheckJob consistencyCheckJob;
AssetConsistencyCheck assetConsistencyCheck;
consistencyCheckJob = new SysConsistencyCheckJob(
classidget(assetConsistencyCheck));
if (!consistencyCheckJob.prompt())
{
return;
}
consistencyCheckJob.run();
}