Clockwork and Projector
Clockwork and Projector are two sophisticated component that work together to compute the changes to objects that midPoint manages and to control the execution of these changes. These two components form a "brain" of the midPoint.
TODO: picture
Projector
Projector is responsible for computing the changes. It is triggered by user changes in GUI, received by service or detected by synchronization. Projector recomputes all the synchronization policies, applies all mappings and expressions, processes RBAC role assignments and so on. However, projector is just computing the values. It is not yet executing them. The result of projector computations are stored in model context.
Projector distinguished objects into two categories: Focus and Projections
Projector reflects data from the focus to projections (using outbound mappings) and also from the projections to the focus (using inbound mappings). This happens as many times as necessary to get a complete computation result.
Clockwork
Clockwork is a controller. Clockwork invokes projector to recompute everything that needs to be recomputed. Clockwork invokes hooks to further process the request (e.g. to route it through approvals). This happens several times. Clockwork then proceeds to execute the changes. This may also happen several times if dependencies are used. Clockwork handles execution errors. And at the end of execution it once again invokes hooks (e.g. to handle notifications).
Clockwork States
The clockwork process goes through several stages:
-
INITIAL state. Nothing has been done yet. The model context is filled with a request. But no recomputation has yet taken place. The hooks can use this state to inspect or change the request even before any serious action takes place.
-
PRIMARY state. Request is recomputed. The Model Context was recomputed and contains the preview of changes. The hooks can use this state to change the original request. Nothing has been executed yet. This is often used to influence assignments by routing the request through approval workflow. E.g. the workflow can remove unapproved role assignments from the request.
-
SECONDARY state. Request is recomputed once again. The model context is recomputed to reflect the changes from the primary state. The changes are executed after this state is completed. The hooks can use this state to inspect the values of projections. E.g. it is sometimes used to let system administrators approve the actual changes of account attributes before they are executed. The hooks can be invoked several times as this state may be processed several times when provisioning dependencies are used.
-
FINAL state. All the changes are executed. The model context reflects the state after the execution. This state can be used by the hooks to inspect the results. E.g. this is often used to send out the notifications about the completed operations.
TODO
TODO: more details
See Also
-
Projector and clockwork internals (only some sketches there - yet)