locked
Impact of the deprecated features RRS feed

  • Question

  • we are trying to migrate MIIS to FIM 2010 R2.

    In MIIS which is already existed, they were using Transaction Properties.

    I --

    1.As this is deprecated, i wanted to know the overall common purpose of the transction properties why and how we are using.

       2. How can we avoid the transaction proerpteis, is there any similar functionality as like this?

       3. what would be the impact in the FIM 2010 R2  ?

    II - -

    1.what will be the do not recall attributes for the MA which is not selected do not recall option.

    III --

    If the Allow Nulls option is selected always, then what would happen for the attributes which doesnt require to be selected this option.

    Tuesday, April 23, 2013 11:28 AM

All replies

  • I --  As far as I know, TPs are still allowed in FIM 2010 R2 but will be removed in the next version.  You wouldn't be relying on them unless you used them in your provisioning and/or rule extension code.  No one could tell you how you are using them.  I don't know if there is a general use for them, but I have used them mainly for detecting certain kinds of changes are occurring during the inbound synchronization phase (without storing that information permanently in an attribute) and passing that information to my metaverse extension provisioning code to create connectors to a reporting SQL MA or make other certain types of decisions.  They are also used as a flag to coordinate between rule extensions since you cannot control the sequence in which import or export rules are evaluated during a synchronization.  If you have multiple EAFs and they depend on logic that "looks forward" into the connector space before setting a new value, and the value being looked at might change by one of those EAFs, a TP is a decent place to store it for that moment.  There are probably a lot of bad-practice examples using TPs, but they can also really help you out of a coding jam and prevent you from having to write out data to a file during synchronization (which is really terrible for performance).

    I will mourn their loss, but I don't know how much company I have as in my "day job" I'm only using the sync engine portion of FIM at this point and not the portal.  Once you start using the portal, there are a lot of different ways to accomplish some of the same tasks.

    I'm not sure I understand your other questions.  In general, using the "do not recall attributes" option is bad practice and can cause many hard-to-solve problems in data that does not update once a connector is removed.  I've only seen it recommended for use in certain circumstances where an MA needs to be deleted and re-added to clear up some other problem, and only so that the connector space objects can rejoin the metaverse objects after a re-import and sync.  Even in that case I'd hope that your attributes used for joins have another source and aren't completely gone.

    You also might get more responses if you post in the FIM forum.  This ILM forum doesn't get the traffic it once did.

    Chris

    Wednesday, April 24, 2013 9:23 PM