Hi Guys,

Just a feature request that I think would bring some useful functionality. I have recently had some scenarios where queued operation lists have execute when the shouldn't have due to the scheduler running throughout a change. Or where I have accidentally queue a long running operation twice. Currently the only way to clear the queue is to restart the service, which then disposes of all other operations that have been queued.

I think it would be beneficial to be able to view and clear specified operations from the operation list queue. Let me know what you think or whether you need any further information.

Thanks,

Hayden

After an operation is demoted, an additional "New Operation" menu appears below the demoted operation.  After using this menu to add a new operation below the demoted operation (sibling), I was expecting to be able to move it up one position above the initially demoted operation - but there is no menu to do this.  For the moment I can, however, select the Move Down menu from the initially demoted item.

UNIFYNow has been observed to invoke operations as soon as UNIFYBroker changes are detected, rather than waiting until UNIFYBroker has completed generating changes.  In a bulk change scenario, this can result in small batches of changes being imported via a MIM run profile (for example), and in the case of changes that may breach a configured change threshold (e.g. UNIFYNow Safety Catch feature), it is possible that the catch won't be tripped because individual batches themselves fall below the threshold.  For example, when 1000 changes are made in HR, and the import threshold is 500, 4 batches of 250 identity import changes could still get through to MIM.

Instead of change detection returning TRUE as it currently does as SOON as there are changes present in the adapter, is there a way of holding these up (queueing them internally within UNIFYBroker) while reflection is still going on.  This way in the above example, change detection would return TRUE only after the 1000th change had been surfaced to the adapter.

There may be multiple ways of looking at this … for example, a result of BUSY could signal to UNIFYNow that changes have been detected but there could be MORE COMING.  Not sure which option would be best, nor the degree of configuration that may be required to throttle this.  Looking for the most elegant solution to achieve the desired result - and suspect this would be best isolated to within Broker rather than surfacing the decision to UNIFYNow.

I have two Operation Lists configured as shown:

Operation List "Incoming":
- Run Profile operation (a delta import)
- Calls Operation List "Sync"

Operation List "Sync":
- Run Profile operation (a delta sync)

Operation List "Sync" is in an exclusion group with various other operation lists that perform Sync run profiles.

When one of the other Sync operation lists are running and Operation List "Incoming" is run, the first operation (Run Profile operation (a delta import)) completes, but since Operation List "Sync" is in an exclusion group, it does not run (which is as expected).

However, I have configured Operation List "Sync" with the "Queue on Blocked" flag, so I'm expecting that it should run soon after the other Sync operation list completes.  However, it does not appear to do so in a timely manner, if at all (I only waited a few minutes).

The desired outcome here is that I can avoid having to put all my "Incoming" operation lists in an exclusion group.  I only want to exclude parallel sync operations - it's fine if delta import operations run in parallel.

Can you please advise how I can get the desired outcome to work?

1/ Priority control flag

According to the documentation, UNIFYNow Exclusion Groups, Priority operation lists execute immediately, even if Normal operation lists are currently running:

(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.

Currently, UNIFYNow only supports the ability to execute one check operation against an operation list. 

It would be good if the ability to run multiple check operations, with an AND or OR clause against them, was made available.

One benefit of this for the MIM product, is the execution of an MA containing multiple adapters, when any of the contained adapters have changes available.