What about Infor’s new EDI BOD’s

Many of you might be familiar with Infor’s BODs or Business Object Documents, where system integrations are simplified by pre-defined XML (eXtensible Markup Language) documents supporting specific business processes.

Although these messages will certainly assist in A2A integrations, they are not optimized for the requirements of EDI (Electronic Data Interchange) transactions.

Anyone familiar with EDI knows the complexities, with different standards, versions, configurations etc. and although it is meant to be a standard you will not find two companies that implement the same EDI message, ie a Customer Order, exactly the same way. Not even if the standard and version being used are identical.

The new EDI BODs address this issue and act as a superset for a specific type of EDI message, containing all the possible data requirements any trading partner may have for that particular message type.

So how can we leverage from this in the development of our EDI infrastructure?

Wouldn’t it be great if we could just send the entire EDI BOD a just let our trading partners pick out what data they want to use.

Unfortunately, it is not that simple, as companies have spent a lot of money over a long time to build up rigid systems to send and receive data in their particular EDI format. Fortunately, there are companies that specialize in converting and translating all these different EDI flavors. They provide Message Brokering services, and one of the world leaders in this field is SPS Commerce, who already have established connections with a huge number of trading partners around the globe.

Infor and SPS Commerce has teamed up to offer a turn-key solution where the new EDI BODs are fully supported, meaning that Infor customers can take advantage of SPS Commerce vast network of connected trading partners out of the box.

The benefit for Infor Customers is that the maintenance of the EDI trading partnerships are reduced to a minimum, with only a single BOD document per type of transaction and SPS Commerce handling the maintenance and on-boarding of new and existing partners.  

The new EDI BODs are only available for Infor Multi-tenant customers at this time.

Please let us know if this sounds interesting and if you would like to know more.

Integration Wizards is an Infor Alliance partner how specializes in Infor M3 and Infor LN EDI and integrations. We want to make sure what we develop today will also work tomorrow and the next day, so we strive to keep abreast with the latest technology developments so we can give our clients the best advice and deliver long-lasting solutions. 


Infor M3 customer and considering Multi-Tenant (MT) cloud in the future?

What to consider today regarding your integration strategy.

I decided to write this blog because recently we have been approached by multiple clients who has sought our advice on best options for EDI and integration if it should be compatible with Infor MT cloud in the future.

Naturally MT cloud will put some restrictions on what you can do, as you are sharing the same environment with many other customers. This becomes especially true when developing your interfaces and there are some pretty major changes that you need to consider. However, if you are aware of them you can start today to design any new interfaces accordingly and hopefully avoid having to re-write them when the time is right to move to MT cloud. I am going to try and explain a few important things you will need to keep in mind.

First of all, to put your mind at ease, Infor M3 e-Collaborator (IEC) appears to be here to stay, but there will be some changes. It will be much more tightly integrated with ION and the Partner Agreement tool will disappear in its current form. Initially it will not exist at all and the partner agreements are generated automatically from Meta data within the maps. ION workflow is replacing the communication channels and the traditional IEC Process flow.

However, we are told there will be a “light” version of the Partner Agreement Tool coming out in a phase 2, with most of the functionality currently supported in the on-prem version. The exception is the external communication which will still be handled by ION. Furthermore, any outbound messages are now being triggered by Event Analytics and M3 BOD Processor and not via the traditional Media Management in M3.

In terms of messages and naming, these must now be created as

Custom BODs (Business Object Documents) and follow the standard BOD design and nomenclature.

Finally, when it comes to the development of maps, there will also be some restrictions put in place. As you might be aware, IEC is currently an extremely flexible tool in terms of what you can do in your maps. It supports Java code within custom functions which basically allows you to write any code to be executed within the map when it fires. Examples include sending emails, writing your own database calls, creating external files, executing web services etc. This does not mean that it will be impossible to do these things, but it will become much stricter and limited in MT due to security reasons. You will need to use the tools and procedures provided to accomplish the same results.

I hope you found this article interesting and perhaps it can help you think more strategically in regards to your current integration plans.

Integration Wizards is an Infor Alliance partner that specializes in Infor M3 and Infor LN EDI and integrations. We want to make sure what we develop today will also work tomorrow and the next day, so we strive to keep abreast with the latest technology developments so we can give our clients the best advice and deliver long-lasting solutions.

Disclaimer: The information in this blog is to the best of our knowledge at the time of writing and based on our understanding from reading publicly available material, working on MT integration projects and speaking to various people. I am not an Infor employee, nor do I have access to Infor internal documents or information. Therefore, we take no responsibility for any actions taken based on this article alone. For more in-depth information you should speak to your Infor Account Manager.

EDI and Blockchain – A match made in heaven?

Blockchain technology has quickly become a major Buzzword, spurred on by the recent media attention on Cryptocurrencies. In fact, Blockchain technology has been around since the early 1990’s, originally proposed as a way to handling documents securely, but only with the advent of Bitcoins did it reach the hype that it has today.

I am often asked if Integration Wizards works with Blockchain technology, since we specialize in data integration and electronic transactions.
It is a valid question and no doubt would block chain technology make significant improvements to electronic B2B transactions, some of which I will discuss in this article.
However, I do not believe it will happen overnight, because EDI (Electronic Data Interchange) technology is a slow-moving ship and there are no benefits for a single company in a partner network to change, unless other trading partners also follows. This was one of the main reason XML (eXtensible Markup Language) never really took off, although it was (and still is) a far superior format for electronic business transactions than the clunky 30 year old flat file formats used by traditional EDI standards, such as EDIFACT and ANSI X12.

So how could blockchain technology benefit EDI?
Before I answer that question, let’s take a look how it actually works, without getting too technical.

At the heart of blockchain technology is a public distributed ledger, through which all the transactions or “blocks” of information passes. Think of it as similar to the transaction feed that shows up on you online banking account. The ledger is replicated and preserved on multiple servers in a P2P (Peer-to-Peer) network and all participants authorized to a specific blockchain receives a copy of it. This means that you’ll have a very high level of data redundancy, no central point of failure and very low risk of losing any data.

The “blocks” of information are organized in a chain and each has a unique ID, through which it is linked to the next block. If any information in any particular block is changed, this unique ID also changes and breaks the chain,  so much like a bank transaction, a single block cannot be changed, without also changing all the blocks/transactions that follows. This means the whole chain of blocks would need to be re-calculated and also approved by 51% of the participants in the chain, so making changes to an existing transaction is very difficult. Instead in a B2B scenario, changes would be added on as a new “corrective” blocks. This immutability and required consensus, together with strong encryption of the data are some of the corner stones of the block chain’s security characteristics.

Another feature is something called  “Smart Contracts”, which allows the participants of a particular block chain to agree on a set of specific rules, which are automatically executed when a certain condition is met. These will come to play a significant role, especially in electronic trading to eliminate exceptions and validating the data.

So without further ado, let’s take a look at what Block Chain technology can do for EDI.

In contrast to current EDI transactions, which are one-way and point-to-point messages, with a blockchain you would have a shared information flow with transparency, auditability and visibility by all participants in a supply-chain process. This would eliminate the need for functional acknowledgements, used extensively in EDI today, to confirm that a particular transaction have been received or not. It would also safeguard the sequence of the transactions in a particular business process. Furthermore, any new transactions would be validated in real-time by smart contract rules, which would reduce or maybe eliminate any exceptions altogether.


Since the ledger is distributed on multiple servers and shared by all trading partners in a particular business process, the risk of losing any transactions would be next to none.
The inherent nature of the blockchain, with its immutability, encrypted data and consensus of changes across all participants would make it next to impossible for hackers to fraudulently manipulate the data, which is also one of the reasons banks are adopting the technology.

Looking ahead it would also be possible to add on additional non-traditional EDI information to the block chain in real-time, such data from various IoT (Internet-Of-Things) devices, such as scanners and delivery trucks, to further improve real-time visibility across the Supply Chain.

It is definitely an interesting technology and expect to hear more about how this will improve B2B transactions in the coming years.

About the Author
Mathias Wallgren has worked with data integration for the past 15 years, both overseas and locally.
He currently works with Integration Wizards, an Infor Partner specializing in Infor M3 MEC™, Infor ION™ and Infor Cloverleaf.

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.


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.


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.


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.


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.

EDI and Integrations – What you need to consider when upgrading Infor M3 ERP

In this blog I will touch on a few things to consider when upgrading Infor M3 ERP in regards to integrations. I apologize if this article is a bit technical. It is hard to do it any other way.

There are of course different ways in which you can integrate applications and EDI with Infor M3 and I will touch on the following areas.

– M3 ERP
– M3 e-Collaborator (MEC)
– Application Programming Interface (API)
– Web Services
– Direct to Database

I will do this in a point form to make it easier to find information which is relevant for your specific case.

1. Infor M3 ERP

The first thing is of course to try and find out what has changed between the old and new version of M3. The best source for this information is the net change report for the new version.
Depending on how old your current M3 version is, there could be minor changes or completely new programs. I recently completed a project where we integrated a mobile service solution to the old Service module. As you might know this was complete re-written in version 13, not even using the same programs or workflow, so when the company upgraded, the integration had to be re-written from ground up. This is an extreme example, but it could happen to you too.

2. MEC

MEC remained mostly unchanged between version 1.6 and 9.0, but with 9.1 there were some major changes. The Administration was moved into Lifecycle Manager (LCM) and the old MEC mapper was replaced by an Eclipse based mapper (although the old Mapper was initially still made available).
However, the database structure is not significantly different and Infor provides upgrade scripts to make life easier.
These scripts also converts the tables for the Partner Admin tool, so with a little luck your agreements will not need to be re-entered.

3. Application Programming Interfaces (API)

Using the standard M3 API’s are a great way to integrate to Infor M3. It is safe and always applies the correct business logic, so it’s a safe way to ensure
data integrity. It is also rare that an API is removed between version, instead new API’s are constantly added. Furthermore, if an interactive program is changed the API is also modified (or should be).
If existing API’s input or output fields are updated, the new fields are always added to the very end of the return text string, so it normally does not affect your integration. If you have used MEC for your integration and want to use some of the new fields there is a way to easily update the API meta-data in your map by right-clicking the API symbol in MEC Mapper tool and select “Update External API Function”. This will bring in the updated API metadata and the added fields.

4. Web Services

If you have been using the M3 Web Services Framework (MWSF) and you upgraded to a later version using the grid, you may need to re-create your web services in the new framework.
The easiest way to achieve this is to copy the location of your metadata file and then import this to the Web Services framework. Then deploy the web service
as you would with a new one. However, with the simplicity of creating web services it may be almost as fast to simply re-create the web service.

5. Database

This approach is generally not recommended for other purposes than extracting data, and then it should be pretty straightforward to figure out the possible
implications that could occur. The libraries will most certainly have changed and in the case a major re-write of the program has occurred (as with the example
of the Service module above) there may be completely different tables containing the data you need.
I hope you enjoyed this blog and maybe it can save you some headaches.

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

10 simple ways to ensure your integration projects run on time and budget


In this article I will present 10 easy points to keep in mind to ensure that your integration project is a success. There is no research, statistics or other metrics behind this list. Just my personal experience after 15+ years of integration work with Infor M3 and MEC (M3 Enterprise Collaborator). The list is in no particular order.
Please feel free to leave a comment if you think I have missed something.

Let’s get started.

1. Write a detailed project specification

This may seem like common sense, but often as an integration consultant you are left with very little information to start with and you are expected to fill in the blanks. However, the fact is that as an integration consultant you work with all the different processes in the ERP system and it is impossible to be an expert in everything. Besides, every company have different process flows and configurations, making this task even harder. The integration will get done…eventually, after a lot of questions and requests for clarifications, which could have been avoided if the information in the initial specification had been more detailed.

2. Define the roles and responsibilities of the people in the integration project

Usually there is a person in every company that is responsible for the EDI and integration maintenace and might have been so for many, many years. This person may even have developed some of the interfaces way back.
Naturally this person will feel threatened by an external consultant coming along and proposing changes to his or her domain. He or she may even in extreme cases act as a gatekeeper to critical information, thus working against the success of the integration project.
It is important that the roles and expectations of the different people in the project are well-defined by the project leader or the project sponsor.
Everyone needs to pull in the same direction and in most cases all it takes is re-assurance that no ones job is on the line and that the change is ultimately for the better.

3. Provide support to the project from the top level management

Sometimes there is a lack of support by the business and the top level management. Although the integrations may have significant impact on how the business is run, it has quite low priority from management and may even be pushed aside or postponed due to the need to put out fires or to attend to tasks that are quite insignificant.

4. Prepare your IT infrastructure before the project

This is something that should really not be a problem, but sometimes it still is. Some common interuptions to an integration project is integration software which has not been properly installed. Consultant user profiles without the required permissions, unplanned restoring of test systems, wiping all the integration configurations or VPN services that are not working properly.
Individually these may not have a big impact on the project time frame, but many small streams make great rivers (swedish proverb).

5. Try to limit changes during the course of the project

Sometimes you realize things during the project you were not aware of when starting out, therefore it may have been impossible to plan for it. However, these changes can have significant impact on the time frame of the project. As an integration consultant, when reviewing a project specification, you have a general idea of how long time things will take. Especially if you have been doing
it for a while. You know what API’s are available and where you may need to create a web service or make a database call.
However, if these conditions change it is like trying to hit a moving target, and your initial estimate may need to be complete thrown out the window.

6. Clean up your data prior to the project

It is important to understand that garbage in, garbage out also applies in a B2B integration. There is no magical AI (not yet!) that will automatically clean and make sense of the data if it was entered inconsistently or incorrect. A common example are addresses, which can be entered in many different ways, but may have to be in specific defined fields in your B2B transaction. Often causing the transaction to fail at the other end and initially the interface is blamed for not “working” as it is supposed to. Other examples are when reserved fields in the ERP are used for something else than their intended purpose, and suddenly all sorts of strange information is sent in the interface.

7. Prepare for business process change

Often a B2B integration will have significant impact on the business process it supports and sometimes there has not been enough planning ahead for these changes. When it is close to go-live the roles within the process flow and who is responsible for what is still not clear. Even in a fully automated process, there is still potential for errors and exceptions, and it is important that someone is monitoring and taking care of these from day one. This person may not be the one taking action, but is responsible that action is being taken.

8. Provide resources and relevant test data for testing

This is quite common and is always time consuming. You may have finished the integration coding in a day or two, but there is no one available to help with the testing and no relevant data. Often a specific business process flow that needs to be followed (and as mentioned in the first point, every business is different), no one has the time to assist, because they are to busy with their day-to-day tasks. This is where you need the support of the top level management to free up the relevant process owners who understands the business process 100%, knows what to test, how to test it and what results to expect. These people will also play a crucial part in defining the test cases in the test specification and ensure that as many issues as possible are captured before going live.

9. Ask your business partners to respond in a timely manner

This is probably the most common cause of delayed integration projects, which is frustrating, because it is also the point which is the hardest to do something about. You are dealing with people outside the company you are working for, and although the business top-level management may still be able to put some pressure on their B2B partner (depending who the partner is of course) it is still very much out of your hands.
Sometimes it could take days or in extreme cases even weeks before you get a response from a business partner after submitting test data. This can have significant impact on the project time line and also means that everyone involved is getting increasingly disconnected with the project, making it even harder to pick it up again where it was left off.

10.  Keep it simple!

I’ve seen many examples when far too much business logic has been implemented in interfaces. Especially when the functionality is missing in the ERP and it is faster and cheaper to develop it as part of the interface. This is dangerous and after a while the integration becomes a black box and no one really knows what it does.  So my advice is to keep it simple and it’s also good practice to insist on keeping up-to-date documentation on your integrations, so you know down the track what they do, without having to call in external consultants everytime to find out.

I hope you enjoyed reading this article and please feel free to share it if you like it.

If you would like more information or want to discuss an upcoming Infor M3 EDI or integration project, please contact us at Integration Wizards or get in touch with me directly on Mathias Wallgren.
We can assist you at any stage of your integration project, from planning and execution to training and documentation.

Infor MEC – 15 Years on

In this article I am going to talk about Infor M3 Enterprise Collaborator (MEC), an integration platform that has survived for over 15 years and is still as relevant as ever.
It all started at a Swedish software company called Intentia R&D around the turn of the century. As you might remember, this was just about the time when business’ were starting to see the benefits of Internet for more than just static web pages.
At the time I was part of the e-Business team, and it was an exciting period with many new products in the pipeline, such as webshops, e-procurement, web portals and of course M3 Enterprise Collaborator, or Movex e-Collaborator as it was called then.

Our mission was, taken from the original marketing presentation, “to create a solution that enables business-to-business (B2B) e-collaboration in terms of both intra-enterprise and inter-enterprise through Application-to-Application (A2A) integration.

We needed something that were flexible enough to both support traditional EDI based B2B transactions, but would also be able to handle XML (eXtensible Markup Language), which was the new document format that everyone was talking about. A separate project was launched to develop business documents for different business processes and these where initially called MBD (Movex Business Documents), but later renamed MBM (Movex Business Message). The rumour was that MBD abbreviation had the unfortunate association with “Minor Brain Damage”, but I’m not sure if that was true or not.

The MBM documents where initially meant to be generic business documents, based on an open standard such as OAG or RosettaNet, since these were thought to gradually replace traditional text based EDI files. However, later they became based on traditional EDI in an XML format, since it appeared EDI was going to stick around for a while. Interestingly the recently launched BOD’s (Business Object Documents) are back on track with Business Process oriented documents, so perhaps we were just ahead of our time?

Although the original MEC was limited in functionality, most of the components were still the same as they are today. There was a Partner Admin tool, a Mapper and of course the runtime server. The server was running in a command window and not as a service, so someone had to always be logged in and he or she better not close that window.
The Flatfile conversion tool was the only part missing, but the functionality was still there. However, you had to manually define the XML files for each XML to flat translation.

I often hear criticism of MEC, but the fact that it is still around 15 years on, must mean that we did something right.
I think it is important to understand what MEC is and what it isn’t. The most common argument is that it is overly complicated and time consuming and that if you are a programmer you could easily write code to connect to any of the available Interfaces directly. However, I think that then you are missing the point. MEC is more than just an IDE for developing an interface.
It is the sum of its parts that makes it so powerful, and if you wanted to add the same functionality in your custom interface, you would essentially need to build another MEC.

I’m going to list some of the benefits of MEC to a custom interface and I am expecting to get some comments in line with  “you can do that with a custom interface too”, but be aware that MEC is meant to be maintained by business people, not programmers, so if it is not intuitive it is not an option.

  • Graphical mapper IDE in Eclipse, with a palette of drag-and-drop functions, such as all the available APIs (Application Programming Interface).
  • Full version control and simple process to switch between different versions of an interface (also referred to as a maps). Unlimited flexibility, since user-defined java-functions can be created within your maps.
  • Re-usable maps, which are independent of M3 ERP version and can be imported/Exported to multiple environments.
  • Complete Administration, Maintenance and Monitoring platform, where the status and content of each transaction can be easily viewed and appropriate action taken if necessary.
  • A Partner Agreement tool that allows you to define specific workflows and communication requirements for individual partners. It also helps you organize and group all your different integrations in a logical manner.
  • A full set of predefined process steps at your fingertips, including but not limited to ION integration, a Document Asset Management integration, XSL transformations as well as multiple communication protocols for receiving and sending.
  • Already used successfully by a large customer base and developed over 15 years for stable and secure High-Availability, High-Performance and High-Throughput.

The list could go on, but I think the benefits above is enough to expected MEC to be here for some time to come.

Hope you enjoyed reading this article and please feel free to comment or contact me if you have any questions.

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

What are the benefits of Cloud based integration?

There is a lot of hype around Cloud Integration at the moment and perhaps most of you already know or have an idea of what it is, but I thought I would write a few words anyway and explain what benefits can be achieved with this approach to data integration.

In the old days (or a few years ago) data integration software was mainly hosted on-premise and external electronic B2B transactions were sent via value-added networks (VANs). For traditional EDI (Electronic Data Interchange) transactions this still seem to be the de facto standard used.

However, with the emergence of more SaaS (Software-as-a-Service) offerings such as Salesforce.com and others, the requirement arose for a simple way to interchange data with other systems, such as internal legacy systems, and cloud based integration was born.

Cloud based integration may not solve all problems when it comes to data integration, but it is definitely a step in the right direction, with many benefits over the traditional in-house approach. Most Cloud integration vendors are offering features such as:

  • Elastic infrastructure that allows for seamless scalability with increase in demand
  • Pre-built Connectors for many software packages means significantly less development
  • Subscription based pricing means you only pay for what you use
  • Secure and encrypted data traffic removes the requirements of VAN infrastructure
  • Highly resilient with built-in redundancy
  • Web based monitoring from anywhere
  • Multiple data centres across the globe for increased performance

With Cloud based integration, better networks and higher transfer speeds, I think we will see a lot more of real-time global enterprise data traffic where geographical boundaries will play a less significant role and diverse applications are instantly exchanging information across the world as changes occur.