locked
What actually "triggers" provisioning and what does "trigger" mean? RRS feed

  • Question

  • Hi,

    We were trying to get a new test ILM environment working today.  More precisely, it's an old test environment, that hadn't been used in awhile, and the folks who set it up awhile ago are long-gone.  This environment was suppose to have been working before, and part of what it was suppose to be configured to do was to provision users into an AD..

    I checked the MV Extension, and confirmed that there was code there to provision the users into the AD MA CS, but, for awhile, we just couldn't get any outbound synchronization to occur to the AD MA.

    Finally, I checked under ILM Options, and found that the checkbox for "Enable provisioning" was unchecked!

    I checked that checkbox, and then when we ran a full import full synch profile on one of the contributing MAs, and I had the MV Extension running under Visual Studio debug, I started seeing my breakpoints getting hit.

    We were able to get things working after that (we then saw Outbound Synchronizations on the AD MA), but, thinking about it, I have some kind of general questions about ILM and provisioning and outbound synchronization:

    1) I was wondering:  When that Options checkbox is unchecked, does that effectively tell ILM never to call the Provision() method in the MV Extension code?

    2) I always thought that, aside from that Options checkbox, the way that the Provision() method got called was only if an MA was synched, and if a projection rule was triggered, i.e., I thought that if all joins failed, then a projection rule would get fired, and that ONLY that (projecting into the MV) would cause the Provision() method in the MV Extension to be called by ILM.

    Is that correct, or not?

    The reason for the question is that, by the time we had enabled the "Enable Provisioning" checkbox the user objects would have already been created in the MV, via the projection rule, and yet the MV Extension Provision() still got called, after we enabled that Options checkbox. 

    So, I guess that I'm now (again) left to wondering, exactly when (under what conditions) is the MV Extension Provision() method called by ILM?

    Thanks,

    Jim

     

     

    Thursday, March 3, 2011 2:31 AM

Answers

  • Hello Jim

    1) I was wondering:  When that Options checkbox is unchecked, does that effectively tell ILM never to call the Provision() method in the MV Extension code?

    Correct.
    You could also look at it differently. If you disable that option, you're just synchronizing data without provisioning, which is usually the first step when starting up the MIIS/ILM/FIM Sync operations.

    2) I always thought that, aside from that Options checkbox, the way that the Provision() method got called was only if an MA was synched, and if a projection rule was triggered, i.e., I thought that if all joins failed, then a projection rule would get fired, and that ONLY that (projecting into the MV) would cause the Provision() method in the MV Extension to be called by ILM.

    The provision method is called every time a MV object is 'touched' by the sync engine.
    So it's not only triggered when a projection is executed, but also on regular attribute flows...
    This means that the provision code is run on high frequency.
    Which makes the the provision / MV extension code block very interesting, not only for provisioning but also for certain deprovisioning actions.

    HTH,
    Peter


    Peter Geelen (Traxion) - Sr. Consultant IDA (http://www.fim2010.be)

    [If a post helps to resolve your issue, please click the "Mark as Answer" of that post or "Helpful" button of that post.
    By marking a post as Answered or Helpful, you help others find the answer faster.]
    • Proposed as answer by Peter GeelenMVP Friday, March 4, 2011 7:56 PM
    • Marked as answer by jimcpl Friday, March 4, 2011 9:32 PM
    Thursday, March 3, 2011 7:27 PM

All replies

  • Hello Jim

    1) I was wondering:  When that Options checkbox is unchecked, does that effectively tell ILM never to call the Provision() method in the MV Extension code?

    Correct.
    You could also look at it differently. If you disable that option, you're just synchronizing data without provisioning, which is usually the first step when starting up the MIIS/ILM/FIM Sync operations.

    2) I always thought that, aside from that Options checkbox, the way that the Provision() method got called was only if an MA was synched, and if a projection rule was triggered, i.e., I thought that if all joins failed, then a projection rule would get fired, and that ONLY that (projecting into the MV) would cause the Provision() method in the MV Extension to be called by ILM.

    The provision method is called every time a MV object is 'touched' by the sync engine.
    So it's not only triggered when a projection is executed, but also on regular attribute flows...
    This means that the provision code is run on high frequency.
    Which makes the the provision / MV extension code block very interesting, not only for provisioning but also for certain deprovisioning actions.

    HTH,
    Peter


    Peter Geelen (Traxion) - Sr. Consultant IDA (http://www.fim2010.be)

    [If a post helps to resolve your issue, please click the "Mark as Answer" of that post or "Helpful" button of that post.
    By marking a post as Answered or Helpful, you help others find the answer faster.]
    • Proposed as answer by Peter GeelenMVP Friday, March 4, 2011 7:56 PM
    • Marked as answer by jimcpl Friday, March 4, 2011 9:32 PM
    Thursday, March 3, 2011 7:27 PM
  • Peter,

     

    Thanks.  That clarifies things.

     

    Also, I found this:

    http://msdn.microsoft.com/en-us/library/ms696017(v=vs.85).aspx

    where it says:

    "When you project, join, or disconnect a CSEntry object to the metaverse or import attribute flow changes to the attribute values on the metaverse, the IMVSynchronization.Provision method provides you with the opportunity to react to those changes."

     

    Thanks for the info!

     

    Jim

    Friday, March 4, 2011 9:32 PM