Resource Object Set Specification

Last modified 28 Mar 2023 12:33 +02: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

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.)

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:

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 at kind and intent values. We strongly recommend specifying the intent, especially for versions before midPoint 4.6. For 4.6 and above, please see how the defaults are handled.
If kind is not specified but objectclass and intent are, then the behavior is undefined. Please do not do this.
If only objectclass is specified (i.e. both kind and intent are not present), then it is used. (There are some issues with this setting present before midPoint 4.6, see MID-7470.)
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 and intent (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 at kind and intent values.
If only objectclass is specified (i.e. both kind and intent are not present), then it is used.
If only objectclass and intent are specified (i.e. kind is not present), then the objectclass 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

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.

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.

Was this page helpful?

YES NO

Thanks for your feedback