Enhanced control over execution of operation lists in Exclusion Groups
1/ Priority control flag
According to the documentation, UNIFYNow Exclusion Groups, Priority operation lists execute immediately, even if Normal operation lists are currently running:
Priority | When this operation list runs, it prevents other priority and normal members from running. If a priority member begins execution when a normal member is running, it will not be blocked. |
(emphasis added)
Could you please add a flag to the group configuration to control this behaviour, so that the group can be configured to block Priority operation list execution until any currently-running Normal operation list completes.
This would be much more useful in a MIM environment than the current default behaviour.
2/ Multiple priority levels
Could you please add a numeric priority to each member of an Exclusion Group, to allow more refined control over operation list execution scheduling. At any time, the scheduler would select the operation list with the highest priority to execute next.
The "Priority control flag" is desirable in this situation, to control whether or not higher priority operation lists run concurrently or wait for lower priority operation lists to complete first.
Customer support service by UserEcho
Regarding point 1, could you not just configure all of the members as normal?
Point 2 sounds interesting and not something that had been considered before. Currently it evaluates the operation lists in order that they're polled AND return that they're ready to run. So deterministic in a computing sense, but not user visible/configurable. We have had thoughts around timings against groups, so this would probably complement that nicely.
Point 1 - yes, that's what we currently do. The current Priority feature lets us start important things immediately (and hold off from running any more unimportant things until it's done) which is great, but MIM's restrictions on running two syncs at the same time has unfortunately made that feature unusable as it stands :-( This flag would make it usable again (without breaking backwards compatibility for anyone).
The general use case for this request is a system where there are some things that are time sensitive (i.e. that we want to be executed as soon as possible) and other things that are less important and that can be scheduled when there's nothing else already running.
I should clarify that these are not urgent requirements, since we generally try to configure our environments to run very much unloaded which means no operation lists should have to wait for long anyway.
But it would be a nice-to-have option for our tool-belt :-)