Resource Object Set Specification

Last modified 01 Dec 2021 10:37 +01:00

Here we describe how sets of resource objects are specified in activities. (Represented by ResourceObjectSetType type.)

This configuration is used mainly for synchronization activities. (The shadow cleanup activity uses it as well, although this may change in the future.)

Item Meaning Default

resourceRef

Resource against which we want to execute the activity.

No default (value must be specified).

kind

Kind of objects to be processed.

See below.

intent

Intent of objects of given kind to be processed.

See below.

objectclass

Class of objects to be processed.

See below.

query

Object query used to refine/replace the default query stemming from the above parameters.

None.

queryApplication

How should be resource object set query applied to the basic query stemming from resourceRef / objectclass / kind / intent specification.

Depends on activity. E.g. replace for import from resource.

searchOptions

Search options to use.

No options.

failedObjectsSelector

Used for activities intended to re-process objects that failed to be processed by a "regular" activity that was run before. See here.

No failed objects selection. (Processing all objects.)

Object Set Determination

Import and Reconciliation

The set of resource objects that are to be synchronized using import and reconciliation activities is determined like this:

  1. First, a query is formulated, using the specified parameters.

  2. Then, each object that is provided by the query, is re-checked against the parameters, and skipped if it does not match.

This two-step process is needed because the query itself is executed on the resource, so it cannot check for kind and intent for individual objects returned. Only object class is relevant for resource-based searches.

The query is determined from kind, intent, and objectclass like this:

  1. If kind is specified (with or without object class), then the object class is found by looking at kind and intent values. No intent means that we match either unspecified intent or that is set as a default one for the given kind. (There may be problems with object type definitions without explicit intent specified.) The object class is ignored at this moment.[1]

  2. If kind is not specified but objectclass and intent are, then the behavior is not quite well-defined. We suggest avoiding this case.

  3. If only objectclass is specified (i.e. both kind and intent are not present), then it is used.[2]

  4. If none of them is specified, then an error is thrown. Import and reconciliation cannot proceed without specific object class.

Each object to be processed is then checked if all the kind, intent, and objectclass match. (The algorithm ignores potential hierarchical relations between object classes, like that inetOrgPerson is a subclass of person. Exact match is required.)

Therefore, to avoid any misinterpretations, we suggest using one of the following combinations when specifying import or reconciliation activity:

  1. either both kind and intent (preferred),

  2. or objectclass.

Live Synchronization

For live synchronization, the object class is what is important. Currently, no kind/intent filtering is done, nor custom query is supported.

The object class is determined in a way similar to the import and reconciliation case:

  1. If kind is specified (with or without object class), then the object class is found by looking at kind and intent values.

  2. If only objectclass is specified (i.e. both kind and intent are not present), then it is used.

  3. If only objectclass and intent are specified (i.e. kind is not present), then the objectclass is used.

  4. If none of them is specified, all object classes are processed. (If the connector supports this mode of operation.)

Asynchronous Update (Experimental Functionality)

Only the resourceRef is used. All other parameters are currently ignored.

Query Application Mode

Value Meaning

append

Specified query is "appended" to the default query that results from the resourceRef/kind/intent/objectclass tuple. This is the most reasonable option, to be used in almost all cases.

replace

Specified query replaces the default query that results from the resourceRef/kind/intent/objectclass tuple.


1. The implementation is a bit convoluted in this case. First, the so-called refined object class is determined. Then it is used to formulate a query for provisioning, using kind+intent pair from the resource definition (i.e. not from the activity specification). Finally, the provisioning module determines the object class back from this kind+intent pair. This is something that should be probably reworked in the future.
2. However, for import and reconciliation activities even this is currently a little tricky: The object class name is used to find resource object type definition (objectType item in schemaHandling). In particular, the default type definition with given object class name is selected. The objectClass is then taken from this definition, along with other parameters like baseContext. So, it is possible (although rare) that even by specifying the object class name in the activity definition we won’t get all objects of that class for import/reconciliation. See also MID-7470.