In order to diagnose and fix specific problems with shadow objects in repository, a new task type was created: Shadow Integrity Check Task.
How to use it: just import the following task (taken from samples/tasks/task-check-shadow-integrity.xml).
There are the following configuration options, in task extension container:
- objectQuery: Specifies which shadows to process. The default is all shadows. Note that for databases that implement iterative searches via paging (taking e.g. records 1-100, then 101-200, etc) it is advisable to define an order-by criterion, which is independent on fixes carried out. E.g. if the fix applied is the normalization of attributes, then the shadow object name is OK, because it is not changed in the process. Such databases are H2 and MySQL.
- diagnose and fix: Specify which problems to diagnose (default = everything except "fetch") and which to fix (default = none).
Currently supported checks are:
|normalization||Checks whether all identifiers in a shadow are in a normalized form with regards to matching rule specified in the schemaHandling section. (Note: before running this, please check that you have consistently specified matching rule for all intents of a given kind of objects. In future, we'll check that setting automatically, but currently we do not.)||diagnose + fix|
|uniqueness||Checks whether there are more shadows (of given resource+kind) bound to specific identifier value, e.g. icfs:name or icfs:uid or whatever.||diagnose + fix (*)|
|intents||Checks whether shadow has intent specified. Issues a warning if it has not. When fixing, fetches the resource object and tries to determine correct intent.||diagnose + fix|
|extraData||Checks for extra data in shadow activation container. As of midPoint 3.3, we store only enableTimestamp, disableTimestamp, archiveTimestamp and disableReason there. All other data (e.g. administrativeStatus) have to be fetched from the resource on the fly. This check ensures that the superfluous data are not stored in the shadows, and removes those data that are there (e.g. after migration from pre-3.3 versions of midPoint).||diagnose + fix|
|owners||Checks whether shadow has at least one owner + if the synchronization situation (LINKED) is consistent with owners found - LINKED shadow has to have at least one owner, not-LINKED shadow has to have 0 owners.||diagnose only|
|fetch||Checks whether the corresponding object can be fetched from the resource. Because of the performance implications, this check is not carried out by default.||diagnose only|
|resourceRef||Checks whether resource pointed to by the shadow really exists, including whether resource reference is set at all. (Actually, these checks cannot be turned off.) Fix is done by removing the shadow, so please use with care.||diagnose + fix|
(*) Note that the test checking for uniqueness is implemented purely in RAM, so it works for shadow sets of reasonable size (e.g. 100K entries, depending on amount of your heap). It is faster and simpler to implement. If necessary, just log a JIRA issue to implement more general solution that would work with shadow sets of any size.
The task produces a report that is written to midPoint log file. It looks like this:
Available as of v3.3devel-118-g2acabd7.