none
Can I tell why a disconnect is occurring?

    Question

  • Is there a way to programatically detect why a connector is being disconnected?  Specifically, can I tell if it is because the actual connected data source has been deleted, versus a disconnection that is being done manually (as through the joiner)?

    Thanks.


    Ed Bell - Specialist, Network Services, Convergys


    • Edited by Ed Bell Saturday, December 07, 2013 2:47 AM
    Saturday, December 07, 2013 2:26 AM

Answers

  • AFAIK there is no way to distinguish between these two events  when connector is disconnected. Why you want to know that - putting any logic around this in your solution would be a bad practice IMO. 

    If you want to have it done for reporting purposes etc you can drop import logs and have information on which CS objects were actually deleted and then match it vs those disconnected. Some work but should be possible. 


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    Sunday, December 08, 2013 12:37 PM

All replies

  • AFAIK there is no way to distinguish between these two events  when connector is disconnected. Why you want to know that - putting any logic around this in your solution would be a bad practice IMO. 

    If you want to have it done for reporting purposes etc you can drop import logs and have information on which CS objects were actually deleted and then match it vs those disconnected. Some work but should be possible. 


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    Sunday, December 08, 2013 12:37 PM
  • Long story. Due to issues in our HR process, I have to fairly routinely manually disconnect a mventry from its HR csentry in order to connect it to a 'new' HR csentry.  This prevents me from being able to deprovision the AD connector when the HR connector is disconnected.  Hence, I have to do a periodic manual cleanup of AD to remove ID's for people who have been terminated for any length of time.  If I knew that the disconnection had occured because the HR connector had been deleted from the table, I'd be able to automate deprovisioning of AD.

    Back to the drawing board.


    Ed Bell - Specialist, Network Services, Convergys


    • Edited by Ed Bell Thursday, December 12, 2013 4:22 AM
    Thursday, December 12, 2013 4:21 AM
  • Are you using the FIM Service portal? If so, assuming that both the original and the new HR record have corresponding users in the FIM Service portal, as part of your manual disconnection process, could you add a step to set a flag on the user's FIM portal account? Your code to deprovision from AD could then key off of that.

    Making a lot of guesses on your environment here, of course.

    Thanks,

    Sami

    Thursday, December 12, 2013 2:20 PM
  • It looks like you are doing something manually what FIM should be doing automatically for you. That is deprovision user who are removed from HR. We need some more information about the process to able to help you with your problem.

    Friday, December 13, 2013 6:15 PM
  • Ed,

    The answer here is in your object deletion rule for the Metaverse.  You need to code your own so that when an object no longer has an HR connector, it is deleted from the Metaverse and also AD.  

    Cheers,

    Andrew

    Monday, December 16, 2013 10:05 PM
  • Sami, no, alas, we are just using the Synchronization Engine.

    Fer, in an ideal world, I totally agree.  But I am unable to do that as my HR MA uses an anchor that occasionally changes, which means that connector has to be disconnected and a new one connected.  And if I use the automatic function, I lose my mventry.

    Andrew, that is exactly what I have been working on. It would be much easier if I could tell if the disconnection from the HR MA was via the GUI, but I am close to being able to do what I need to do by looking at the mventry attribs, looking at their 'last changed' times and deciding if the mventry should be deleted based upon a retention period.


    Ed Bell - Specialist, Network Services, Convergys

    Wednesday, December 18, 2013 4:20 AM
  • If the anchor changes the management agent sees the object as new. The object with the old anchor is gone, so a disconnect follows. What you need is a join rule which would automatically join to the metaverse object. That should be possible if there is a join criteria which is not based on the anchor of HR.

    If that is possible, you need to create an object deletion rule which takes into account that an object which is deleted will not be rejoined. You will need a delay to avoid a deletion when the rejoining is not immediately.

    Wednesday, December 18, 2013 12:38 PM