Project

General

Profile

Actions

Task #2788

open

Retry mechanism doesn't handle unavailable systems that use target objects in provisioning context (errors in entity events instead of the provisioning queue)

Added by Alena Peterová almost 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
Vít Švanda
Category:
Provisioning
Target version:
-
Start date:
04/30/2021
Due date:
% Done:

0%

Estimated time:
Owner:

Description

Tested on 10.8.2 and 11.0-RC2

  • A system uses provisioning context with "Add an object from the target system". E.g. AD created by the MS AD wizard
  • The system is unavailable, e.g. broken connection, wrong address, ...
  • Add some system role to a user, or update some of their attributes
  • The error is in the failed entity event, instead of a failed operation in the provisioning queue
  • => the role is not assigned at all
  • => current retry mechanism doesn't handle the situation, so even if the system is available again after several minutes, the operation isn't retried

I'm not sure if this is defect/task/feature, but it's very unfortunate that provisioning context can break otherwise robust retry mechanism in IdM. And because it will be used by default for AD now, it can easily happen often. We didn't think about this when we implemented the scripts, where we load connector objects from the system.


Files

mapping_context.png (26.4 KB) mapping_context.png Alena Peterová, 04/30/2021 05:05 PM
context_entity_event.png (81.2 KB) context_entity_event.png Alena Peterová, 04/30/2021 05:12 PM
Actions #1

Updated by Alena Peterová almost 3 years ago

  • Subject changed from Retry mechanism doesn't handle unavailable systems with provisioning context (errors in entity events instead of the provisioning queue) to Retry mechanism doesn't handle unavailable systems that use target objects in provisioning context (errors in entity events instead of the provisioning queue)
  • Description updated (diff)
Actions #2

Updated by Vít Švanda almost 3 years ago

This exception cannot be part of provisioning queue, because system GET is running in "script" phase. So the result is same as if the get would be in a separate script.

For solve this we need some kind of provisioning queue for GET operation, but I'am not sure, if it is good way (we can consult this).

Actions

Also available in: Atom PDF