Send B2B data with Azure Logic Apps and Enterprise Integration Pack

After creating an integration account that has partners and agreements, we are ready to create a business to business (B2B) workflow for your logic app with the Enterprise Integration Pack.

The covered scenarios will be:

Adatis ->generate 940 x12 ->encrypt that message and send it to ABC as2 and sftp endpoints->

ABC ->receive 940 send by Adatis using As2->decrypt As2 message->Apply xsl stylesheet


The EDI 940 Warehouse Shipping Order transaction set is used to instruct remote warehouses to ship orders. It is commonly used by a seller,

such as a manufacturer or wholesaler, to authorize a warehouse to make a shipment to a buyer, such as a retailer.

Before start with logic apps, we need to create two storage accounts

In every of the storage account will need to create EDI container

Next, we will need to create for the same storage accounts and queues: as listed below:

Format of exported data from our core system will be in xml format:

<?xml version=”1.0″ encoding=”utf-8″?>

<ns0:X12_00401_940 xmlns:ns0=””>










  <ns0:W76 xmlns:ns0=””>







Basically, we can generate xml export from any database type where the only condition we need to met is to be formatted as related edi document type we wish to process. Once the xml is exported in our on premise environment we need to upload it into Azure blob storage. This can be achieved by many ways and we will not cover this topic.

The goal is to have uploaded into Adatis storage account in the edi container our physical data export:

Also, inside the queue we will need to post a message which will trigger our workflow execution

The content of the queue messages is just the name of Customer which is Adatis

physical location inside Azure of our exported xml document:


and the name of the trading partner: ABC


To make the process of send and deliver edi messages more flexible we will split it into two main flows each of it will be created by the combination of two logic apps

First part will cover the case when we need to send edi messages:

  1. Logic app which will convert the xml to edi format – x12-out-abc
  2. Logic app to deliver to as2 endpoint – as2-out-abc or
  3. Logic app to deliver to sftp endpoint – sftp-out-abc

Second part will cover the case when we need to receive edi messages:

  1. Logic app to receive from sftp endpoint – as2-in-adatis or
  2. Logic app to receive from as2 endpoint – sftp-in-adatis
  3. Logic app which will convert the edi message into xml – x12-in-adatis

Queue is used to trigger workflow execution deliver some metadata between the individual logic apps  quick inside information of what has been processed and in which stage is our message as long as and the physical location inside our blob storage of that message.


Our logical app which will process our xml once it has been uploaded into Azure will look like:

First part group of action are triggering the workflow by adding message into the que,

parse the que message and load the data into variables:

The outputs of this actions are as follow:

Next will call the Integration account and get from there some details about the trading partner and construct a couple variables which will be used latter:

The output from the PartnerQuery output is:

Next group of actions will use collected information from storage account from previous step to construct EDI message from the imported xml file:

Once the xml is converted into edi format we will create in our blob store new physical record of our converted edi message.

Reason to keep both formats of the same message is for audit purpose and errors investigation. This will help us if customer has data discrepancy very fast and easy to provide information  of what has been exported from the core system and compare to what his trading partner has been receive and what we have generate as an output message.


Format of our converted from xml into edi message will look like:

ISA*00*          *00*          *ZZ*AdatisEdi      *ZZ*ABCEdi       *220227*1530*U*00401*000000122*1*P*:~
N1*WH*IL-1*9*517~W66*DF*M***ABC MARK*****SEDA~LX*1~


Follow the logic of our first logic app we met the last group of actions which will check what is the type of our trading partner endpoint from the Integration account and call second logic app from our first flow group by post in his message que notification which will trigger his execution.

Here we dynamically choose if it is a as2 or sftp or ftp. For every type of endpoint, we need to have separate logic app because of different logic and settings needs to be applied but only one type can be executed at the same time.

When we set the Integration account, we create one variable under the partners settings called connection-type.

Inside that variable we define the trading partner endpoint if it is as2, sftp, ftp.

Our workflow will check what is the endpoint type and dynamically will chose next logic app needs to be executed:

Last action from current logic app flow is to post in the second logic app message queue message which will trigger its execution and to delete from current logic app the queue message. This will help very fast orient in which stage is our message


To make this workflow re-usable which means that every new trading partner integration will re-use same workflow we can generate ARM template and create a parameter for all dynamic


When new customer requests a trading partner integration we will need only to fulfill Customer name, Trading partner name and the name of the integration account which will be used.

Deployment from ARM template will look like: