Infor Event Analytics – What’s the Hype?

I’m currently involved in an Infor M3 integration project using Event Analytics extensively and I thought I would share some of my thoughts and experiences.
For those of you who have not come across Infor Event Analytics, it is an application within the Infor GRID for subscribing and filtering database events
created by Infor M3 Event Hub.

Event Analytics uses a rules language by JBoss called Drool to create these filters. Events such create, update or delete of a database record, or start, exist or fail of a program will trigger a rule and when defined field values (such as an item status) within the rule are met, it will fire off another user-defined event
to be picked up by MEC (M3 Enterprise Collaborator) or IPA (Infor Process Automation) or any other application that can act as a subscriber to these events.

I guess it sounds like a glorified database trigger, which listens to certain database conditions and executes a piece of code when those conditions are met, but it is much more than that.
The strengths of Event Analytics is the standardized approach, the framework to maintain these rules and the ability to pass on standard Business Object Documents (BOD’s) containing not only the current values of the file or program that triggered the event, but also the previous values of each field. This opens up enormous possibilities. Especially when combined with MEC.

So what are some real-world scenarios?
Imagine an M3 to Salesforce.com integration where current stock data replicates in real-time as they change in M3.
Or maybe an M3 3PL integration where item master data flow through automatically when the item status changes to Active (20) in M3.

However, I think a word of caution is in order. As always with great power comes great responsibility.
At this point I am not actually sure what impact on the database it could have.
One must be careful how these rules are defined, because there are literally millions of updates happening in M3 and one wrong step and you may have
hundreds of events triggering hundreds of messages in MEC, calling thousands of API’s and potentially bring the whole system down.

So my final advice is to be very specific in your rules and when you want them to trigger. One way to achieve this is to use a before and after values (ie. when item status changes from 10 to 20), thereby avoiding multiple triggers every time any field in the file is being updated.

Leave a Reply

Your email address will not be published. Required fields are marked *