Object Set Specification

Last modified 27 Oct 2021 12:21 +02:00

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

Item Meaning Default


Type of objects to be processed.

Depends on the specific activity. Usually ObjectType.


Query to use.

Depends on the specific activity. Usually none, i.e. all objects of given type are processed.


Search options to use.

No options.


Whether to go directly to repository (bypassing e.g. authorizations).

Depends on the specific activity.


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

No failed objects selection. (Processing all objects.)

Failed Objects Selector

This data structure is used to select objects that were failed to be processed in previous run(s) of this or other (compatible) activity. It is basically a specification of a filter against operationExecution records, looking for ones that indicate that a processing of the particular object by particular task failed.

Item Meaning Default

status (multi)

What states to select.


taskRef (multi)

What task(s) to look for?

The current task.


What is the earliest time of the record to be considered?

No limit (take all records).


What is the latest time of the record to be considered?

If explicit task OID is not specified, then it is the last start timestamp of the current task root. (Just to avoid cycles in processing; although maybe we are too cautious here.) If the task is different one, then no limit is here (i.e. taking all records).


How are failed objects selected. This is to overcome some technological obstacles in object searching in the provisioning module. Usually there’s no need to change from the default.


Failed Objects Selection Method

Value Meaning


Default processing method. Normally narrowQuery. But when searching for shadows via provisioning, fetchFailedObjects is used.


Simply narrow the query by adding failed objects filter. It works with repository but usually not with provisioning.


Uses original query to retrieve objects from a resource. Filtering is done afterwards, i.e. before results are passed to the processing. This is preferable when there is large percentage of failed records.


Failed objects are selected using the repository. Only after that, they are fetched one-by-one via provisioning and processed. This is preferable when there is only a small percentage of failed records.

For more information about handling failed objects, please see Task error handling page. (It is a bit obsolete, though. It will be updated eventually.)