Queue on Blocked didn't run the blocked operation in a timely fashion

Hi Adrian,

Do you have check operations configured? They still run and need to pass before the list will run.

If not, could you please run again with verbose logging? A number of the blocked and waiting messages only raise on verbose to reduce the noise.

Thanks.

There's no Check operation on Operation List "Sync", and it's unscheduled since the only time it should run is when called from the Operation List "Incoming".

Working on the verbose logging now...

I've just noticed that the "Sync" Operation List is being run (and failing, since MIM won't allow parallel sync run profiles) despite the fact that another operation list in an exclusion group with it is already running.  So the core issue might be that the exclusion groups don't apply when an Operation List is invoked from another Operation List.  Is that correct?

Hi Adrian

You are correct, the exclusion group an operation list is part of are not considered when run by other operation lists. What you can do place the outer operation list in the exclusion group and run the inner operation list as Blocking as a potential work-around.

I've added this information to the Operation List Execute Operation documentation page.

This has significant performance implications for UNIFYNow implementations, since it effectively means that more coarse operation lists are forced to run sequentially, rather than having appropriate aspects of them run in parallel (which MIM is happy to allow).  It feels a little like you've taken the easy road and changed the documentation to describe the behaviour of a bug, rather than fix that bug :)  Could I please ask that you reconsider this decision?

To put this into context - we have a support customer right now who has eight external systems from which data must be imported into MIM in near real-time, and not being able to schedule parallel import operations for the incoming operation lists for those systems adds significant latency to their processing cycle.

It's not a bug, it's how it was designed. The documentation was updated to describe this more clearly.

If you'd like to request that it works this way, let me know and I'll add it to the backlog.

Thanks Adam.

This functionality is important and having a negative affect on our customers so please add it to the backlog.

Given my current experiences with UNIFYNow it would help me out a lot if I could read the design and/or requirements document for UNIFYNow/Event Broker so I don't keep having expectations that it doesn't meet.  Is this something you could share with me?

Also, could you please direct me to the backlog list of possible future UNIFYNow features, so that I can avoid asking for things you already have planned, and so that I can see what features might be made available in the future?

Thanks,
A.

I've added it to the backlog.

I'm not saying it follows some document, it's by design by definition. If we thought about it working the way you describe then it would, there would be a backlog item to make it so, or we might have rejected that thought and told you so when you raised the ticket. We are working on improving this process such that there is a register of these sorts of decisions (as opposed to the heavy handed nature of documentation).

The backlog is currently not visible outside our team. Besides, the search is better in Voice and we're happy to link between new tickets that happen to already be on the backlog.