Category Archives: EventHub/EventAnalytics

Infor M3 EventAnalytics

Harnessing the Power of Events

This is my second post on this subject, but I think it’s worth mentioning again, because still when I speak to many of my clients they have not yet realized the potential of using the EventHub and EventAnalytics modules in Infor M3. This post will be more focused on different use cases for Events.

I’ll begin with a short explanation of the EventHub and EventAnalytics for those who missed my previous post.

The EventHub is part of Infor M3 and is basically listening for changes to any field in the Infor M3 database and triggers events, similar to a database trigger. It can also be setup to trigger events on batch programs, when it is started, exits, fails etc.

EventAnalytics works as a filter to analyze these events and lets you decide what specific events you are interested in. This could be a combination of multiple field values, to target a specific state and you can make it as granular as you wish with logical expressions. It also allows you to capture the field value before it was changed for even more precision.

An example could be to capture the event of an order allocation for a specific item. Perhaps for some reason you would want to log whenever item “ABC123” is allocated in warehouse 200. Then a rule could be defined in EventAnalytics to fire an event when the Item equals “ABC123”, Warehouse equals 200 and the order line status goes from 22->33 (allocated).

The next step is to define a subscriber to handle this event, and that is where M3 Enterprise Collaborator (MEC) comes in. EventAnalytics will produce an XML file containing Event Data. In this case the values of all the fields for the specific M3 file and record in which the change took place, including their values prior to the change. MEC can easily be configured to pick up this message and use these values to accomplish whatever tasks you wish to happen. Needless to say this opens up a host of opportunities and I’ll mention a few below, but only your own imagination sets the limits.

Automation

Anything that does not need any human intervention or evaluation could be automatically entered updated using the data supplied by an event.
If you for example enter an order for a specific customer, you could automatically populate any customer specific fields in the order and extract that information from the customer master file.

Integration

I always found that one of the limiting factors of creating integrations in M3 to be the reliance of the Media Management and the responsibility of the user to print a document to generate an MBM initiator message to MEC, which then triggers the outbound document.
With the EventHub you now have an alternative, and if you wish you can make the outbound message trigger by a specific field update, such as a status change. An invoice could be sent automatically when an order reaches status 66 (invoiced), and you could also log the information in a separate file of when, what and by whom the invoice was created.

Logging/Traceability

A few customers have asked me how they could easily log a change in a specific M3 field, without turning on the audit functionality in M3.
One example could be an address change for a customer, to log what the address was changed from and to, what date and time and by whom.
This is easily accomplished by setting an EventAnalytics filter on the Customer address lines and trigger whenever any are changed, then use a map in MEC to log this information in a database table.

Approval

Perhaps you wish to extend the approval functionality in M3 and you need a Manager to approve any purchases from a specific supplier, group of suppliers or a specific item. Using EventAnalytics to define this rule, you can setup MEC to put a hold on the order, then send an email message to the person responsible with an external link to M3 to complete the approval.
These were just some applications that I can think of right now, but hopefully by reading these you can come up with many more and I would love to hear about them. Please share how you have made use of EventHub in your enterprise.

If you need any help or assistance we are always willing to help. We work on Infor M3 EDI and integration projects around the world. Contact Mathias or visit us at www.integrationwizards.com.

Infor M3 Integration alternatives

Infor M3 Integration Toolkit. What to use and when?

If you are planning a new integration project with Infor M3, there are a lot of different options available and in some cases it can be difficult to select the best option. In this article I aim to give some direction and hopefully make the decision easier. Let’s have a look at each of the options and provide some examples of use cases for each.

Infor M3 API’s

Infor Application Program Interfaces (API) have grown significantly in numbers over the past 10 years.
They provide the same business logic as the interactive programs, but as a set of functions, which vary by M3 program. These functions can be called programmatically and include Add, Delete, Update, Get and List functionality.
The M3 API’s are the preferred way to interact with M3, as the business logic is followed and the database is not exposed in any way. That is why most of the other methods I will discuss later use these API’s internally for invoking M3 functions.
The downside with the API’s is that they are quite cumbersome to connect to directly, unless you use propriety classes, and are not well suited for calling M3 remotely over the web.
If you have a local application, which needs to be very tightly connected to M3, and performance is extremely important, then perhaps you could consider building an interface directly to the API’s. This approach would most likely cost more to develop, test and maintain than using any of the standard methods below. Also be aware that the API’s may change between M3 versions, which could easily break the interface.

Infor MEC

M3 Enterprise Collaborator (MEC) was developed as a response to the increase of B2B transactions over the internet about 15 years ago. I was on the first development team and later Product manager for this application, when it was still owned by Intentia in Sweden.
I am very excited that it is still around, and although there has been a lot of improvements over the years, the basic functionality is still very much the same.
MEC allows any application to securely communicate with Infor M3 via XML messages over a range of different protocols.
The M3 Enterprise Collaborator uses API’s to safely update data in M3, but with the ability to write custom java-functions, you can call web services, extract data from other sources or anything else you wish to do.
MEC comes with a complete framework, which includes the ability to setup Partner Agreements for individual configurations by the partner or application with which you wish to integrate. It also comes with a flat-file parser to process text-based files.
An extensive admin interface includes the ability monitor each message and a has a full range of other useful functions to maintain your transactions.
If you have a B2B/EDI type integration, typically over the internet, where visibility and control is important, then MEC is the preferred alternative. It can also be used for A2A integrations and is particularly useful to replicate reference data between disperse systems.

Infor M3 Web Services

Infor M3 Web Services uses the traditional web services SOAP protocol and allows for synchronous communication with Infor M3 over http. Web services methods can be based on API transactions, but can also be based directly on most interactive programs, which makes it very useful for updating data when a suitable API function is missing.
Infor M3 Web Services makes sense for A2A integration, when a remote application, which also supports web services, is pulling the strings and controlling M3.
This could be a web shop which is calling a web service to retrieve information about whether an item is in stock or not.

Infor M3 REST interface

The Infor REST interface is a fairly new development and allows M3 API’s to be called remotely by virtually any programming language, without using the propriety classes required when calling the APIs directly. Compared with Web Services, REST is much more light-weight, can be called from pretty much any tool. It is a great for loosely coupled applications with a many-to-1 connection, where updates on the server side should not break the client.
It is a welcome addition to expose the API functionality to a greater range of possible integration scenarios.

M3 ION/EventHub

M3 ION and EventHub are also relatively new additions and are based on an event driven publish and subscribe service based communication. Infor M3 produces events for any type of update in the database and other applications can subscribe to specifically defined events and retrieve data from the files producing these events.
This type of integration is typically used for internal applications where M3 is the master. However, it can also be used to trigger MEC transactions, that could forward the information to external destinations.

Direct Access via ODBC or OLE/DB

It comes without saying, but if you decide to access Infor M3 directly via ODBC, it should only be to extract data, and NEVER to update data. Being a relational database, the tables in the M3 database have a lot of interconnected records and unless you know exactly what you are doing, it would be very easy to jeopardize the integrity of the database by removing or adding data.
However, there are still applications where direct access makes sense. I am thinking of data warehousing(ETL) and business intelligence tools for example, such as QlikView or Cognos where you need to extract large amounts of data.
There are also situations where none of the previous methods are available, and there is no other option than to extract the data directly.

If you would like more information, please contact us at Integration Wizards or get in touch with me directly (Mathias Wallgren). We can assist you at any stage of your integration project, from planning and execution to training and documentation.

Infor M3 Event Analytics

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.