Tag: Integration

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. 

www.integrationwizards.com

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.

blockchain

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.

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.