Package com.evolveum.midpoint.model.impl.sync.tasks

Class SyncTaskHelper

  • @Component
public class SyncTaskHelper
extends Object
    Auxiliary methods for synchronization tasks: Live Sync, Async Update, Import, Reconciliation, and - strange but true - Shadow Cleanup). Deals mainly with processing resource, objectclass, kind, intent tuple, i.e. specifying resource object class to be processed. The resource object class determination has the following flow in synchronization tasks: 1. User specifies `ResourceObjectSetType` bean with `resourceRef`, OC name, kind, intent, query (many of them optional). 2. It is then converted to three objects: - ResourceObjectClass that holds resolved resource, object class definition, kind, and intent, see getResourceObjectClassCheckingMaintenance(ResourceObjectSetType, Task, OperationResult). It does _not_ contain user-specified query. - ResourceSearchSpecification that contains precise query intended to obtain resource objects (plus search options). This spec is later fine-tuned by activity run to cover its specific needs (like selecting only shadows that were not updated for given time - see SearchBasedActivityRunSpecifics.customizeQuery(ObjectQuery, OperationResult)), to cater for bucketing, handling errored objects, and so on. This search specification is used only for search-based activities, e.g. not for live sync or async update. - SynchronizationObjectsFilter that filters any object returned by the item source (e.g. search operation in search-based activities). Notes: * SynchronizationObjectsFilter is currently used only for import and reconciliation. In theory, it might be used also for live sync or async update. However, it is a bit questionable, because it would mean that non-compliant changes would be skipped, i.e. in fact thrown away. * The overall handling of object class / kind / intent triple in synchronization tasks (mainly import and reconciliation) is quite counter-intuitive: It works well if kind + intent combo is used. However, when object class is used, the provisioning module gets correct "objectclass = XYZ" style query, but it then looks up first matching refined object definition, and uses it. See ProvisioningService.searchObjects(Class, ObjectQuery, Collection, Task, OperationResult) and MID-7470 for more information.