Wednesday, June 13, 2012 3:58 PM
Using the released version of FIM 2010 R2. (Don't know if FIM 2010 functions the same or not.)
I have a scenario that reads If MVattribute1 = "somevalue" then flow MVattribute2 otherwise flow NULL to MAdestinationAttribute. NULL means <not set> if viewed in ADSIEdit.
I understand the functioning of the Null() function that it doesn't flow a null value. I have created a nullString attribute bound to the person object in FIM Metaverse. I am using only declarative sync rules with outbound scoping filters.
As reference http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/9c0ac6ee-4795-4aef-96f1-663cb50dc7d2 contains a similar discussion about FIM 2010 that suggests IIF should work.
In the sync rule I created a function IIF(Eq(MVattribute1,"somevalue"),MVattribute2,nullString) -> MAdestinationAttribute
This rule works just fine when the condition is met, and MVattribute2 will flow to the destination. However when the condition ceases to be met it will not flow the nullString attribute to the destination; the previous value from MVattribute2 remains. I know the rule is constructed correctly because if I actually put a value in the nullString attribute, that value will flow. But that obviously defeats the purpose of needing to flow a NULL value.
So why isn't IIF flowing the nullString attribute simply because nullString happens to have no value? If I do a direct flow of nullString to destination it will also succeed. It's just when IIF is being used that the NULL value won't flow.
- Changed Type Markus VilcinskasMicrosoft Employee, Owner Sunday, March 17, 2013 5:56 PM
Thursday, June 14, 2012 5:08 PM
I've ran into this in the past. I believe the hack that I found to work was to add an empty string to the nullString in your custom expression. For whatever reason, that seemed to actually flow a Null ...
So, try changing the flow to IIF(Eq(MVattribute1,"somevalue"),MVattribute2,nullString+"") -> MAdestinationAttribute
Marc Mac Donell, VP Identity and Access Solutions, Avaleris Inc.
Thursday, June 14, 2012 6:46 PMThanks for the suggestion, but adding the + "" doesn't make a difference on FIM 2010 R2. It still won't flow the null MV value as a CS attribute delete. It generates no export at all so whatever happens to be the previous value remains in the CS.
Monday, June 18, 2012 12:02 PM
I know a few PFEs who are saying this is likely a regression error in R2 RTM.
Friday, July 20, 2012 1:31 PM
I ended up finding some other threads (http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/da35429d-935a-4abe-85ed-a5d13e8df1a0/) from before that discuss the same behavior for FIM 2010 (RTM). So it looks like IIF has never been able to export a null value in an outbound flow. There go my hopes for this being a quick bug fix. :(
So I see three possible solutions to this.
1. Classic coded sync rules for attributes with conditional export logic.
2. Denormalize the metaverse so that all calculations can be performed inbound and the result stored in the metaverse, then use only direct export flows.
3. (And the one I'm choosing at the moment) Perform a direct flow of a NullString attribute in the outbound flow to ensure that nulls are written. Then add dependent sync rules for each condition that flow the calculated value when the condition is met. This can be a bit messy to look at in FIM Service as dependent sync rules can only use logical AND when constructing the scope filters, so OR must be expressed as additional dependent sync rules, which can greatly increase the number of rules required. In outbound flows, the last writer wins. The null value in the parent rule is first. If the condition is met, the dependent rule will write its value second, thus becoming the winning value that is exported. When the condition ceases to be met the direct null value flow from the parent is allowed to win again and becomes the exported value.