Remember how we have always been told to avoid the circular group references because systems can sometimes get lost in the loop of endlessly trying to resolve the total membership? A similar scenario exists when working with MPR’s as well (and yes, I learned this the hard way).
The easiest way to illustrate this is to use a situation with two MPR’s (my scenario was with 5 of them so it made it fun to trace).
- Request MPR
- Create/Modify Attribute <RandomData> by All Objects
- Fire workflow that updates attribute <OtherData>
- Request MPR
- Create/Modify Attribute <OtherData> by All Objects
- Fire workflow that updates attribute <RandomData>
Looking at the two examples, we can easily see how MPR 1 will always result in the calling of MPR2 which will result in the calling of MPR 1 and the cycle continues indefinitely.
There are ways to mitigate this by limiting who makes the change for the updates to occur (for example MPR 1 may only happen if the synchronization engine makes the change to RandomData and then when the FIMService does update as part of MPR2, MPR1 won’t be triggered). However, each scenario is different and there may need to be an examination of the overall process that resulted in the “circular” reference to see what can really be done to effectively remove the issue.
Symptomatically, I saw the following:
- FIM Service performance started to degrade over time as more objects were added to the system.
- FIM Service request search showed numerous recursive changes to each single entry that was added and in a loop. A refresh of the request showed that the changes continued to occur.
To break the loop I had to disable one of the MPRs and ultimately restart the FIM service which certainly isn’t desirable but it allowed me to recover the environment so that I could fix the problem and continue working.