MidPoint usually executes all resource operations as soon as possible. But this may be quite troublesome for manual resources and slow resources where the operations are costly. Therefore there is a way to change that behavior by using provisioning propagation task. In such case midPoint will not execute operations immediately. Requested changes will get queued for (reasonably short) time. Then midPoint will execute all the changes at once in a single operation.
See Provisioning Propagation page for full introduction to this topic.
Provisioning propagation configuration has two parts. Firstly the resource has to be configured to postpone (queue) the operations. Secondly there needs to be a propagation task that executes the operations.
Resource configuration is a simple matter of enabling operation grouping feature by setting a grouping interval:
<resource oid="f34328fa-f229-11e7-8cc9-e3f77b478e97"> ... <consistency> <operationGroupingInterval>PT10M</operationGroupingInterval> <pendingOperationGracePeriod>PT15M</pendingOperationGracePeriod> </consistency> ... </resource>
When the grouping interval is configured then midPoint will automatically enable operation queuing for that resource. The operations will not get executed immediately. All the operations will be queued in shadow objects in a form of pending deltas. The example above specifies grouping interval of 10 minutes. Therefore the operation will be queued for a maximum period of 10 minutes. When that period is over then the operation will get executed. And the execution will include all the other pending changes queued in the shadow.
Second part of the configuration is the propagation task. This is recurring task that scans for pending operations to be executed. The task looks for any shadow with a pending operation that is older than the grouping interval specifies. If such shadow is found then all the pending changes (deltas) are executed. If there are several pending deltas then they are all merged together and executed in a single operation.
The propagation task definition is very simple. All that is needed is to specify correct handler and to point to the resource:
<task> ... <handlerUri>http://midpoint.evolveum.com/xml/ns/public/provisioning/task/propagation/handler-3</handlerUri> <objectRef oid="f34328fa-f229-11e7-8cc9-e3f77b478e97" type="ResourceType"/> ... </task>
The propagation task is quiet efficient and it can run frequently (every few minutes) - as long as there is a reasonable amount of pending operations in the shadow objects.
It is also a good idea to specify a grace period for pending operations so the executed pending operations will get cleaned up when they are not needed. This is illustrated in the resource configuration example above. Too many pending operations stored in the shadows may affect system performance. The data structure that represents pending operations is quite complex and it is not easily indexed. Therefore the propagation task needs to examine all the shadows that have at least one pending operation. This is more than acceptable approach in case that the pending operations are regularly purged and do not accumulate in the shadows forever. And that is one of the reasons for specifying the grace period.
This feature is experimental. It means that it is not intended for production use. The feature is not finished. It is not stable. The implementation may contain bugs, the configuration may change at any moment without any warning and it may not work at all. Use at your own risk. This feature is not covered by midPoint support. In case that you are interested in supporting development of this feature, please consider purchasing midPoint Platform subscription.
The usual set-up is to have one propagation task for each resource. But it is quite likely that there may be many manual resources which leads to many propagation tasks to maintain. Therefore there is an experimental support for multi-resource propagation task:
<task> ... <handlerUri>http://midpoint.evolveum.com/xml/ns/public/provisioning/task/propagation/multi-handler-3</handlerUri> <objectRef type="ResourceType"> <filter> <q:equal> <q:path>extension/provisioning</q:path> <q:value>propagated</q:value> </q:equal> </filter> <resolutionTime>run</resolutionTime> </objectRef> ... </task>
Please note the difference in task handler URI (
Current implementation of provisioning propagation was designed specifically to work with simple manual resources. Therefore there are some limitations:
This is a limited midPoint feature. This feature currently supports only some specific use-cases. We are perfectly capable to finish the feature, just the funding for the work is needed. Please consider the possibility for supporting development of this feature by using midPoint Platform subscription. If you are midPoint Platform subscriber and this feature is within the goals of your deployment you may be able to use your subscription to endorse implementation of this feature.