Repair
On the Security configuration form, there is a menu in the top action bar called Data. One of the menu options is called Repair. The help on the tooltip mentions: “Rebuild indexed data for optimal runtime performance“. Now, what is the purpose, and what happens in the background?
To fully answer this question, it would require help from the Microsoft engineers who worked on this feature. I will share some details I was able to find by digging into the details. The first attempt to get more information is looking at the technical details. I opened Visual Studio and looked at the details of the button Repair on the Security configuration form. This is a button with a clicked() method having the next statements.
As the OptimizationDataManager is a platform class, it is not possible to drill down to the actual coding without reverse-engineering the platform. When I started to work with Dynamics 365 Finance and Operations in the time it has the code name “Rainier” and later “AX7”, I researched a lot to understand how the configuration of security was managed as there is no embedded development environment in this version of the application.
I found out that there are various tables in the AXDB database which are not listed in the application tree; even not as part of the System Documentation node. These tables are used for the Security configuration form and publishing them as runtime security components. In a development environment, you can start the Microsoft SQL Server Management Studio to see the tables. Some of these tables, like SecurityRoleCustomizedDiskObject, SecurityRoleDiskLabels, SecurityRoleParentReferences, SecurityDutyDiskLabels, SecurityPrivilegeDiskLabels are used to build the contents on the SecurityConfiguration form and interact with them. Note that the tables I mentioned here are not the full list of security-related tables which are hidden in the SQL database. It is not intended to change data in these tables manually yourself as you can easily create inconsistencies and a not correct functioning security framework.
Now, when you click the button Repair, these runtime tables will be rebuilt with the information from the application metadata. This leads to the question of if and when you need to use this option. For sure it will not harm the application when you start the repair action.
When you encounter issues, like getting errors on the Security configuration form and/or when data doesn’t seem to be correct, you can use this option to see if this will correct the data on the form. Note that when you have unpublished objects, the details on the security form and the actual behavior of a particular role will be different. E.g. when you added a new duty to a role and did not publish the changes, the form is having the duty included, but the user will not see the new options part of the duty. The Repair button will not solve this scenario. I’m particularly referring to a scenario where e.g. one or more security objects are listed which are not in your application metadata or missing while they are in your application. An example which I enforced by moving a database from an application where some additional models are installed which are not on the target environment.
As an example, I have a role that doesn’t exist in the application. This can be caused by a database movement or a build where security is added or removed without a database synchronization. The role is listed in the table SecurityRoleDiskLabels, but it is not in my customizations. To correct the data on the form you can click the Repair button. When the job completes, you have to refresh the form to see the new repaired data.
Keep in mind that a database synchronization job will also rebuild (some) of the data in the security runtime tables. So, whenever you move a database or build models ensure you will also perform a database synchronization action to prevent having to use the Repair button on the Security configuration form.
Comments
Post a Comment