I have a situation where an attribute flow declined with DeclineMappingException does not seem to be yielding precedence.
Here is the scenario:
I have a large Active Directory and a business requirement for FIM to be authoritative for specific accounts in Active Directory. All accounts need to be visible in the FIM Portal, but only certain accounts may be updated from the FIM Portal. The specific
accounts that FIM is authoritative for is arbitrary and is controlled by an attribute in the FIM Service. The desired behavior is that for accounts in which FIM is authoritative, data will flow from FIM to AD and for accounts FIM is not authoritative, data
will flow from AD to FIM.
I have two management agents, one for the FIM Service and one for Active Directory. I have both inbound and outbound flows for my attributes between the FIM Service and the metaverse. I flow the “IsOwnedByFIM” flag from the FIM Service to the metaverse.
On the AD side, I have rules extensions that for exports flow data from the metaverse to AD if the IsOwnedByFIM flag is set and throw a DeclineMappingExecption otherwise; and for imports, the extension flows data to the metaverse if the flag is not set and
throws a DeclineMappingExecption otherwise.
Precedence is set so that AD has a higher precedence than FIM (AD first in the list, FIM second).
What I expect to happen is that for records not owned by FIM, the AD MA will contribute an attribute and since AD is first in the precedence list, the data will flow into the metaverse and out to the FIM Service. This works as expected.
For records owned by FIM I expect that the AD MA will not contribute an attribute due to DeclineMappingExecption being thrown in the rules extension, precedence should yield to the next potential contributor (FIM Service). This works and I see the data flow
from the FIM Service to the metaverse in inbound flow. However, I also expect that on the outbound flow, data should flow from the metaverse out to AD. This is not happening and I get the “Skipped: Not Precedent” status in preview.
I am aware of Export Attribute Flow precedence and get that an attribute value coming from a lower precedence source will not overwrite a target value that has higher precedence. However, in this case since the “higher” precedence MA declined to provide
a value, I find it strange that EAF precedence is blocking the outbound flow.
So my question is: When Export Attribute Flow precedence is calculated, is the sync engine supposed to consider whether or not an attribute wasactually contributed from a target before preventing overwriting of the target or does it only consider if it targetcould have contributed a lower precedence value?
In other words, is the sync engine supposed to consider DeclineMappingExceptions when determining EAF precedence? And subsequently, is what I am seeing a bug or expected behavior?
For readers not familiar with EAF Precedence the following links are useful (but don’t talk about the case of DeclineMappingExeceptions):
http://social.technet.microsoft.com/Forums/en-US/2c4f5c39-de0b-4fed-9cdd-057d0394085b/about-attribute-flow-precedence?forum=identitylifecyclemanager
http://technet.microsoft.com/en-us/library/cc720559.aspx
