Project

General

Profile

Actions

Task #976

closed

Remove comparison by account and entity ids during synchronization

Added by Marcel Poul almost 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Vít Švanda
Category:
Synchronization
Target version:
Start date:
02/20/2018
Due date:
% Done:

100%

Estimated time:
Owner:

Description

Today I came across a situation that the first synchronization of contracts (identities would work too) ended with 500 objects in the state LINKED. Which is of course weird, since it is the first run of synchronization.
The source of the problem is not easy to find.

how to reproduce:

identificator of the synchronization is different from the identificator of the connector - e.g. PersonalNumber (sync) and UID (connector). Even though each attribute values are unique in their scope, they are not unique globally (some UID == PersonalNumber).

Behaviour:

During synchronization, IdM tries to look for Account object in IdM with id of Entity object. If it does not exists and also Contract is not found by Correlation attribute it ends with MISSING ENTITY state. ok then you usually make Create entity operation and thus create those objects:

IdM entity (login=pers. number) | Account (pers. number) | Entity (uid)
1000 | 1000 | 100

Then the synchronization comes to the point when it get object with uid 1000 and found no Entity, so create one. Then the crucial and a little bit tricky part of synchronization takes part: IdM tries to find some Account with id of the same value of current object which is 1000. (Without correlation attribute! just based on chosen id attributes). And voila there is one already created before. Then IdM end this turn with LINKED state.

Thus you can get many LINKED states for the first run of your synchronization. And thus effectively remove from you the option of choosing the id of the synchronization different from connector id (which can be sometimes hardcoded and not much user friendly)

This is from my point of view very confusing behaviour. I discussed this with Vítek and get the point why it was implemented. But thinking of it again and again, it is more confusing that of some benefit. Taking into account that also Provisioning can have its own id, this is very user/admin unfriendly. I would rather remove this comparison from synchronization (as well as we did before with "UPDATE operation instead of CREATE if ids are the same for account and entity").


Related issues

Related to IdStory Identity Manager - Task #977: Account management in GUINewVít Švanda02/20/2018

Actions
Actions #1

Updated by Marcel Poul almost 7 years ago

  • Related to Task #977: Account management in GUI added
Actions #2

Updated by Vít Švanda almost 7 years ago

  • Status changed from New to In Progress
  • Target version set to Hematite (8.0.0)
Actions #3

Updated by Vít Švanda almost 7 years ago

  • Status changed from In Progress to Needs feedback
  • Assignee changed from Vít Švanda to Ondřej Kopr
  • % Done changed from 0 to 90

Searching AccAccount by UID (when SystemEntity or AccAccount for found SystemEntity does not exists) is correct.

  • Problem was in searching AccAccount by UID from the IC object. In this case could be found AccAccount for "different" account.
  • I fixed this. If SystemEntity is not found, then is AccAccount searched by UID. But this UID is generated from the mapped attribute (marked as Identifier) now.
  • UID generating is time consuming. For optimization I added generated UID to SynchronizationContext. All others places use this value now.
Next fixies:
  • Cancel of sync (after IdM reset) didn't filled the time of end. - Fixed
  • Table of mapped attributes showed use of transformation, even if the transformation scripts contained only an empty string. - Fixed
Actions #4

Updated by Ondřej Kopr almost 7 years ago

  • Status changed from Needs feedback to Resolved
  • Assignee changed from Ondřej Kopr to Vít Švanda
  • % Done changed from 90 to 100

I made review, it's little bit harder than I except, but described behavior works well, thank you for your explaint this problem.

  • main fix = works (hardest things to testing :(),
  • cancel sync = works,
  • correctly filled checkbox = works.

Thank you for fixes! You are so awesome.

Actions #5

Updated by Vít Švanda almost 7 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF