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.
MidPoint 4.3 and later
Until now, the live synchronization task supported only two ways of handling an error:
- stop processing, until the error is not fixed;
- ignore the error and continue processing.
The former option is safe but can result in unnecessary delays in processing, mainly if errors occurs relatively often. The latter eliminates delays, but results in missing updates and therefore resource ↔ midPoint state inconsistency.
In 4.3 we experimentally implemented a third option: delayed processing of erroneous objects.
It works like this:
- An error is encountered during live sync task.
- If appropriate configuration is set, the task does not stop processing nor ignores the error. Instead, a trigger is created on the respective resource object shadow, reminding midPoint that the shadow should be re-processed. The time interval for the trigger is configurable and can be e.g. a few hours.
- After specified time arrives, the shadow is re-processed.
- If the repeated processing is successful, the process ends here. If not, another trigger (with an interval that may be the same or different) is set up, and the process repeats.
- If the process is not successful even after specified number of repetitions, the process ends.
An example of configuration:
After an error is encountered, the retry is attempted after 30 minutes. The next retries are done after 1 hour. The process stops after 4 attempts.
The configuration is driven by
LiveSyncErrorHandlingStrategyType, that consists of one or more entries (
LiveSyncErrorHandlingStrategyEntryType). Each entry contains:
- a situation describing when the entry applies,
- a reaction that should be applied.
The situation is currently described simply by set of operation statuses:
FATAL_ERROR, or both (this is the default).
The reaction is either:
|Error is ignored.||The synchronization token is advanced to the next change, effectively ignoring the failed record.|
|The processing is stopped.||The synchronization token is unchanged, or set to the current record. (Depending on resource setup.)||This is the default strategy.|
|The processing is retried later.||A trigger is created, as described above.|
Besides these options, you can specify also
stopAfter property (applicable to
retryLater reactions) that cause the task to be stopped after seeing specified number of error situations. (This option is even more fragile than the other ones. It will be most probably replaced by the thresholds mechanism.)
retryLater reaction has the following properties:
|Initial retry interval.||30 minutes|
|"Next" retry interval, after initial attempt.||6 hours|
|Maximal number of retries to attempt.||unlimited|
To conclude, this mechanism is experimental. Most probably it will be replaced by something more general, applicable e.g. to other kinds of synchronization tasks, like import or reconciliation.