none
Evaluating Relationship Criteria in SR RRS feed

  • Question

  • Hi,

    I have interesting situation, some background:

    Historically when we started with Identity Sysnchronization many years ago, (MMS days), we decided to use the personnel number issued by ou HR system as the unique field amongs all connected directories.  At the time the HR system only housed permanent employees and it worked great beacuse the personnel number or employee ID was unique and remained with you as long as you were in the company.  It never changes...

    Well until the HR system were also used to house some contractors.  Due to some legal requirements this number needs to be changed when a contractor's contract is renewedand stayed on in teh company.  You can just imagine the havoc across all the connected directories when this number is changed.  We are constanly fixing this in the connected directories of which AD is one, and rejoining the objects.

    With us in the process of designing the migtration to FIM 2010 R2, I thought that we will fix this by specifying the ID number, issued by home afairs when a person is registerd in the country, as the second join criteria in the synchronization rule when the employee ID is changed. (this number is also available in the HR system as well as the AD, or can be flowed to the AD as result of the first join condition, which I have done)

    But for some reason the second join condition is ignored when the employee ID is changed which results in a new object added to the connector space of the HR system as well as in the metaverse the original object is removed.

    My questions are this:

    1. Is it because that once a join / projection is established the anchor attribute value cannot be changed?

    2. Has anybody struggled with the same situation, and is there another way to resolve this other than by manual method?

    Some guidance is appreciated

    Regards

    Johan Marais


    JkM6228

    Thursday, May 24, 2012 7:17 PM

Answers

  • Hi,

    You need to understand that there is a differance between your joining logic and keeping the object linked. Once the object is joined and therefore has a link to the metaverse, the join-logic is not processed anymore untill the link with the metaverse-object is severed.

    In you case: when the anchor-attribute (the personnel-number) is changed, FIM detects a 'delete' and an 'add'.

    My advise would be to find an anchor-attribute that stays unique. The personnel-number might not be such a good option anymore.

    Best regards,
    Pieter.


    Pieter de Loos - Consultant at Traxion (http://www.traxion.com) http://fimfacts.wordpress.com/

    • Marked as answer by Johan Marais Friday, May 25, 2012 4:57 AM
    Thursday, May 24, 2012 8:17 PM

All replies

  • Hi,

    You need to understand that there is a differance between your joining logic and keeping the object linked. Once the object is joined and therefore has a link to the metaverse, the join-logic is not processed anymore untill the link with the metaverse-object is severed.

    In you case: when the anchor-attribute (the personnel-number) is changed, FIM detects a 'delete' and an 'add'.

    My advise would be to find an anchor-attribute that stays unique. The personnel-number might not be such a good option anymore.

    Best regards,
    Pieter.


    Pieter de Loos - Consultant at Traxion (http://www.traxion.com) http://fimfacts.wordpress.com/

    • Marked as answer by Johan Marais Friday, May 25, 2012 4:57 AM
    Thursday, May 24, 2012 8:17 PM
  • Pieter,

    Thanks for the advice.  I was sort of expecting an answer like this, but was hoping that there was a way of handling this.  I will relook my anchor attributes

    Regards

    Johan


    JkM6228

    Friday, May 25, 2012 4:59 AM