I’ve been struggling lately with poor SQL performance in a Test environment and I’m pretty sure that has been causing an intermittent problem with objects not transitioning in to Sets and Groups straight away. They all get sorted out when the FIMTemporalEvents job runs overnight – but that’s not very comforting to the testers who are expecting immediate results.
Unfortunately improving the SQL platform hasn’t been an available option to date, so I’ve been looking at other ways I can improve performance around Sets, and started using a “transitional TransitionIn set” in a couple of places. While it’s been very hard to measure the actual impact of this particular change, and I have been making various other refinements as well, the reported incidence of “my object didn’t go active” does indeed seem to have dropped off.
We often have sets that describe when an object is “Active” or “Inactive”. The set criteria to determine this may actually be quite complex. Workflows will typically be triggered on transition in to these sets, probably including one which actually flags the objects as “Active” or “Inactive”. The Active set in particular may be very large and I was seeing multiple incidences of failure to transition in to this set, hence also failure to get marked as Active at the expected time.
So what I’ve done is moved all that complex logic into the following sets:
- “Objects that should be flagged Active”: Active criteria + Status not ‘Active’
- “Objects that should be flagged Inactive”: Inactive criteria + Status not ‘Inactive’
Transition in to these sets triggers the “flag as Active” or “flag as Inactive” workflows, at which point the objects transitions straight out, keeping these sets empty most of the time.
The criteria for my actual Active/Inactive sets is then nice and simple:
- “Active Objects”: Status = ‘Active’
- “Inactive Objects”: Status = ‘Inactive’
There’s another thing I like about this approach, and it’s kind of hard to explain, but here goes: Various workflows, which may well include notifications, will typically be triggered off those Active/Inactive sets – however the criteria of what makes an object Active or Inactive can change. It can be dangerous to mess with the criteria of large sets – you can inadvertently set off large numbers of set transitions and accompanying workflows. Sure I’d be doing this first in dev/test – but triggering tens of thousands of set transitions in an underperforming dev/test environment isn’t much fun either!
So I like the fact that my big sets here have an unchanging rule, and the only place I need to modify criteria is on the small, “should be flagged” sets. Yes the end result is the same, but starting from modifying a zero-member set is certainly an easier position to predict the size of the change – just preview the set membership before committing!
I’m definitely not saying this is a generally applicable approach but it is something I plan on using now whenever a set has complex criteria, it’s expected membership is very large, and it is used to trigger workflows.
