Object Set Specification
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 |
|
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 |
---|---|---|
|
What states to select. |
|
|
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 |
|
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.)