Migrating an EDI solution from BizTalk to Logic Apps – Part 1

The good thing about working in a consulting company like Theta is that you have the opportunity to work with all kinds of clients and projects with varying degrees of complexity. You can design an application from scratch or you just have to deal with the handover of an application built by someone else and needs to maintain, or better yet, you need to improve it.

We have a client that has been using BizTalk 2010 to process all their EDI documents for quite some time. The solution developed works, but is quite complex and requires a lot of maintenance (it’s not BizTalk’s fault, it’s just the way the solution was designed). The simple addition of a new EDI document or a new partner takes hours and hours of configuration, testing, and troubleshooting when things go South (almost always). We also don’t have much logging available to help us when things go wrong. We have been looking into improving the solution to require less maintenance and with more monitoring capabilities, so we came up with the design to implement it in Logic Apps with Integration Account and Log Analytics. So, in a series of 4 posts, I’ll be talking about migrating an EDI solution from BizTalk to Logic Apps and improving monitoring capabilities using Log Analytics.

BizTalk Solution

In this first post of the series, I’ll be talking about how is the design of a solution in BizTalk for inbound and outbound processing of EDI documents.

The BizTalk solution we have in place today is composed of two main parts. One part that sends EDI documents out and another part that is receiving EDI documents in. For the outbound part, we are receiving data from a SQL Server database table and for the inbound part, we receive EDI documents by email.

There are several EDI messages that are being received today, but for the sake of this post I’ll be using only two message types:

• ORDER as the inbound;
• INVOIC as the outbound;

BizTalk EDI configuration

To work with EDI in BizTalk, we need to configure the Parties and Agreements between the Parties in BizTalk. These Parties and Agreements will dictate how the EDI documents received and sent by this solution will be recognized and properly translated to the correct version.

First thing we need to do is to create the Parties and Business Profiles of the companies that we will handle in the solution. For this post I create the host company (the one that has the BizTalk servers) called CompanyX with the identification code as COMPANYX. I also created the client company called Client1, with the identification code as CLIENT1. (very creative by the way…)

Once I have the Parties, I can create the agreement between them. You can see that in the agreement below that I have several properties to define how they will understand each other. This one was created to handle the inbound processing in the configuration of the sender and the receiver.

And in the configuration below, I’m defining the outbound process where the CompanyX will send an EDI document to the Client1.

Inbound EDI Process

Now that we have the Parties and Agreements in place, we can start developing our process.

For the inbound process, we will receive the EDI document coming from one of the configured parties (clients) and after recognizing from where it came from, we will transform it to a WCF-SQL adapter XML, so we can send the information received to a database.

Let’s take as an example the ORDER EDI document with the content as below (this EDI document is much bigger, but for the sake of simplicity in this post I’m using only the mandatory fields):

This EDI document is represented in BizTalk by an XML schema as the picture below shows. I highlighted the segments that are present in the sample EDI document above.

Once the solution receives the EDI document, we need to identify the parties and agreements (more of that in a while) and then store the data in the database. For that, we are working with the WCF-SQL BizTalk adapter and sending data directly to the table as the picture of the XML schema below shows:

With the two XML schemas, we can map the EDI document that we are receiving to the SQL table we want to send the data as the picture below shows.

Once everything is deployed in BizTalk, we can make a test and see that a message is being recorded in the table we intended it to be as below:

Outbound EDI Process

For the outbound EDI process, I’m using the INVOIC EDI document represented with the content below. (only mandatory fields here)

And this EDI document is represented in BizTalk by the XML schema with the fields used highlighted below:

In this process, we are retrieving data from the database and to do so, we need a schema representing the table we want to query as you can see in the picture.

Once we have the data from the database, then we can generate the EDI document making the proper mapping.

If you remember well in the configuration of the agreement between the host company and the client, we have the configuration of the send port, and this is where the EDI document will be sent. Note that I have a record in the OutboundEDI table as below, and in the INVOIC EDI document you will see that the information is matching.

Summary

There is plenty of documentation explaining how to create an EDI solution with Microsoft BizTalk Server, and I just showed a little bit of how to work with that to set the things that I’ll need to create the same solution but using Logic Apps. If you want more information about handling EDI documents in BizTalk, have a look at the Microsoft documentation here: https://docs.microsoft.com/en-us/biztalk/core/edi-processing-in-biztalk-server

This concludes the first part of this series, and I just wanted here to set the tone for the next posts. I’ll be explaining in detail how to develop the inbound process, the outbound process with Logic apps and the Integration Account and the monitoring part with Log Analytics, stay tuned.