Activities
Table of Contents
Introduction
Since the beginning of midPoint, a task represented something that should be done, like importing all accounts from a given resource. Such tasks could be created, executed, checked for the current status and progress, and so on. Gradually, tasks grew rich in features: multi-thread and multi-node processing, the ability to suspend and resume (continuing where the work has stopped), various kinds of statistics, and error-reporting and handling options.
Somewhere around midPoint 4.2, we realized that a task is something that can have a rich internal structure: it can consist of distinct "parts". For example, reconciliation tasks typically consist of operation completion, resource objects reconciliation, and remaining shadows reconciliation.
In midPoint 4.4 we finally have found a suitable conceptual model for the tasks and their work: the activities.
Activities
An activity describes the real work that should be carried out. It can be either simple or composite.
Simple activities consist of a single action, carried out on a set of input items (zero, one, or more ones). Typical examples are recomputation, import from resource, or iterative action.
On the other hand, composite activities consist of a set of other activities - again, either simple or composite. Composite activities can be predefined (like reconciliation or cleanup) or custom. Note that composite activities do not have their own actions nor item sets. They are defined solely by their constituent sub-activities.[1]
A Few Examples
Example 1: User recomputation - a simple activity with a set of input items
This activity runs a recomputation action over a set of all users.
Example 2: Non-iterative action - a simple activity with no input items
This activity runs a nonIterativeScripting action (i.e. non-iterative action).
The action does not expect any input items. It simply runs provided Groovy script (in this case).
Example 3: Reconciliation - a (predefined) composite activity
The reconciliation activity consists of three sub-activities. They are partially dependent: the third one (remaining shadows reconciliation) depends on the second one (resource objects reconciliation).
Each of the sub-activities has a different action, and a different item set.
Example 4: User recomputation + custom action - a (custom) composite activity
The custom activity consists of two sub-activities. Both of them are defined by the user: a recomputation, followed by a custom action.
Configuring the Activities
Configuring Simple and Predefined Composite Activities
A definition of a simple (or predefined composite) activity contains the following sections:
| Section | Meaning |
|---|---|
The work that is to be done. Contains the definition of the activity and the item set. |
|
Defines the overall mode of execution: |
|
Items like prerequisites, preconditions, error handling strategy, and so on. |
|
Distribution of the work executed as part of this activity into threads, buckets, and worker tasks. |
|
How various aspects of activity execution are reported, using logging, tracing, profiling, reporting, and so on. |
|
Tailors the definition of individual sub-activities in a predefined composite activity. |
(More details are provided in the linked documents.)
Configuring Custom Composite Activities
In a current implementation, the custom composite activity definition contains just a single section:
| Section | Meaning |
|---|---|
|
Defines the composite activity as a set of its constituent sub-activities. |
Currently, we do not yet support inheriting the non-functional aspects (executionMode, controlFlow,
distribution, reporting) from the composite to the sub-activities. Neither we do not support specifying
common parts of the work definition for these. (Like object set specification, or some options.)
Therefore, the sub-activities have to be fully defined, independently of each other. We plan to improve
this in the future.
|
Activities and Tasks
As described above, activities represent the work that should be done, while tasks are actual vehicles that make sure that work is done.
Definition of an activity deals typically with:
-
what action should be done, and on which objects,
-
how should errors be treated,
-
how should be the work distributed into threads and worker tasks,
-
how should be the work reported on,
-
and so on.
Definition of a task deals typically with:
-
under what identity should the work be done,
-
should the execution be one-time or recurring - and if the latter, at what time intervals,
-
what should be done when the execution thread stops, e.g. by node going down,
-
what are limitations regarding the node(s) on which the execution should take place,
-
what are specific configurations of e.g. caching or operation result handling,
-
and so on.
(The distinction is sometimes clearer and sometimes not.)
Generally, a single task can contain a single or multiple activities, running in the form of an activity tree. And vice versa, a single activity can be distributed to multiple tasks, when coordinator-workers setup (multi-node processing) is chosen.
Migration from 4.3 and Before
Please see this document.
New Features in 4.4
Please see this document.
1. This is not 100% true, as there may be some auxiliary actions, like recording a starting timestamp for reconciliation, that are built into the predefined composition logic. But those are really minor actions, not visible from the outside. However, in the future we may be able to define custom composition logic for predefined or even for custom composite activities.
Was this page helpful?
YES
NO
Thanks for your feedback