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
kindis specified (with or without object class), then the object class is found by looking atkindandintentvalues. We strongly recommend specifying theintent. Please see how the default is handled. - 
If
kindis not specified butobjectclassandintentare, then the behavior is undefined. Please do not do this. - 
If only
objectclassis specified (i.e. bothkindandintentare 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
kindandintent(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
kindis specified (with or without object class), then the object class is found by looking atkindandintentvalues. - 
If only
objectclassis specified (i.e. bothkindandintentare not present), then it is used. - 
If only
objectclassandintentare specified (i.e.kindis not present), then theobjectclassis 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.  |