0
Under review

Incorporate UNIFYNow concepts for UNIFYBroker+

Bob Bradley 4 years ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 3 years ago 5

With the increased focus lately on deployments of the UNIFYAssure/UNIFYConnect/UNIFYBroker+ solution set, recent experience has been that at times it would have been handy to still use UNIFYNow to enhance the operations user experience - even without MIM in the picture, the familiar Operation List concept could apply equally to a Broker+ deployment as it can for MIM sync.

While we may consider pursuing this idea, a better outcome would be to incorporate UNIFYNow features in the UNIFYBroker+ product configuration itself (i.e. not only adding the Locker menu, but also an Operations menu ... sharing the existing Agents/Groups/Logs menus I imagine, and using the Groups concept to simplify the UX.

In scenario where pre/post processing is required (e.g. mailbox provisioning, notifications, workflow-like activities, etc.) such a configuration would undoubtedly be more maintainable and operationally easier to handle than it is without the UNIFYNow model we enjoy today for MIM solutions with similar out-of-band integration.

This would also help in UNIFYBroker/Plus solutions where we currently have to use an external scheduler to execute regular Baseline Synchronisations in order to keep downstream systems properly synchronised.

+1
Under review

Hey Bob, 

Thanks for the feedback. Definitely an interesting idea to consider.

As you've pointed out, there's nothing stopping us from running the two products side by side to achieve the same outcome. However, you're right in saying a better outcome would be to incorporate the appropriate feature set into the broker product for more seamless integration. While it wouldn't be a small feat, it's definitely an interesting concept.

To further assist in considering the idea, could you (or others) please provide some expanded details on scenarios you're hoping to cover? Is it just the ability to trigger UNIFYBroker operations from an event based mechanism, or trigger external items seamlessly from UNIFYBroker events? Or the ability to run out of band processes based on existing events (such as provisioning or notifications)? Or perhaps some other tricks that are used on existing UNIFYNow sites? 

I understand that all of those scenarios are likely sought after, but some scenarios would help us gauge the initial drivers to give us a place to start for consideration.

+1

For me, the most immediate benefit would be the ability to ensure timely reset of managed attributes that have been manually changed in an external system.

A Connector import runs, importing changes made in the external system that may include updates to attributes that were previously exported from UNIFYBroker.  The Connector and Adapter entities update with the new values, but since the values are mastered in the Locker so there's no inbound sync to the Locker for those attributes from that Adapter, meaning that Adapter and the Locker now have different values until the next Baseline Synchronisation runs, or the object is re-updated in the Locker via a source Adapter.  Consequently, I want to be able to trigger a Baseline Synchronisation after every Connector import, which would be possible if UNIFYNow-style "operation lists" could be associated with UNIFYBroker scheduled actions.

Obviously you might want to think about a way to make sure bad config doesn't result in recursive processing loops, though...

+1

The most generally useful functionality I can see would be the ability to perform arbitrary external operations before and after Connector operations, to simplify integration with external systems.  I think that's the main thing Bob is talking about.

Happy with all of the above - as Adrian says, its the things we take for granted now in a UNIFYNow configuration that are not possible on a MIM platform otherwise, let alone a Broker+ platform.  I think all the scenarios are covered - the one extra I would like to add is the forced raising of adapter triggers to recalculate changes that may not occur otherwise under some scenarios (where the source data doesn't change - e.g. a temporal scenario).  Main benefit is definitely pre/post processing.