Resource Object Set Specification
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 |
---|---|---|
|
Resource against which we want to execute the activity. |
No default (value must be specified). |
|
Kind of objects to be processed. |
See below. |
|
Intent of objects of given kind to be processed. |
See below. |
|
Class of objects to be processed. |
See below. |
|
Object query used to refine/replace the default query stemming from the above parameters. |
None. |
|
How should be resource object set query applied to the basic query stemming from
|
Depends on activity. E.g. |
|
Search options to use. |
No options. |
|
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:
-
First, a query is formulated, using the specified parameters.
-
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:
-
If
kind
is specified (with or without object class), then the object class is found by looking atkind
andintent
values. We strongly recommend specifying theintent
. Please see how the default is handled. -
If
kind
is not specified butobjectclass
andintent
are, then the behavior is undefined. Please do not do this. -
If only
objectclass
is specified (i.e. bothkind
andintent
are not present), then it is used. -
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:
-
either both
kind
andintent
(preferred), -
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:
-
If
kind
is specified (with or without object class), then the object class is found by looking atkind
andintent
values. -
If only
objectclass
is specified (i.e. bothkind
andintent
are not present), then it is used. -
If only
objectclass
andintent
are specified (i.e.kind
is not present), then theobjectclass
is used. -
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 |
---|---|
|
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. |
|
Specified query replaces the default query that results from the resourceRef/kind/intent/objectclass tuple. |