Tutorial: Configuring B2B Messaging Using BizTalk Services Portal and Bridges


Updated: November 27, 2015


Microsoft Azure BizTalk Services (MABS) is being retired, and replaced with Azure Logic Apps. If you currently use MABS, then Move from BizTalk Services to Logic Appsprovides some guidance on moving your integration solutions to Logic Apps.

If you're brand new to Logic Apps, then we suggest getting started here:

Microsoft Azure BizTalk Services provides two key integration possibilities – enterprise application integration (EAI) and business-to-business (B2B) messaging using EDI. Using EAI, you can create BizTalk Services bridges that are deployed on Microsoft Azure. Using B2B, you can create trading partners and agreements to process EDI messages on the cloud. You can then route the EDI messages to the already deployed BizTalk Services bridges for additional processing. This tutorial provides step by step instructions to create, deploy, and test an end-to-end BizTalk Services scenario.

Contoso and Northwind are two business partners. Contoso (the retailer) sends sales order messages to Northwind (the supplier). Northwind maintains all the sales order data in table called SalesOrder, which is housed in a SQL Server database within Northwind’s premises. Contoso can send either XML messages or EDI messages to Northwind. So Northwind has to implement a solution to enable the following:

  • Contoso can send either an X12 message or an XML message for sales order.

  • Contoso must send messages that conform to the schema for the sales order message expected by Northwind.

  • Contoso can also send XML messages to directly insert sales order data in the SalesOrder table in Northwind’s SQL Server database.

To enable this scenario, Northwind does the following:

  • For Contoso to send XML messages, Northwind configures an XML Request-Reply Bridge on BizTalk Services to enable message validation and transformation. This bridge takes an input XML message, validates it against the sales order schema required by Northwind, and transforms the message to that schema. Northwind also uses BizTalk Adapter Service to enable connectivity to the on-premises SQL Server database from the XML Request-Reply Bridge deployed on the Service Bus.

  • For Contoso to send EDI X12 messages, Northwind uses the BizTalk Services Portal to configure and deploy an agreement in which Contoso can send an EDI/X12 message to Northwind.

The following illustration summarizes the scenario:

Tutorial scenario

The scenario used for this tutorial helps us showcase the following integration capabilities of BizTalk Services:

  • Message transportation: The retailer and supplier can be present in different platforms and conform to different transport protocols and message formats. The BizTalk Services implementation helps bridge these differences by understanding the different protocols and message formats.

  • Message validation: While the incoming purchase order might be in different message formats for different retailers, the incoming purchase orders should conform to one of those defined message formats. This is achieved through message validation.

  • Message transformation: The supplier adheres to a common purchase order format. Therefore, the incoming purchase orders have to be normalized to this common format. This is achieved through message transformation.

  • Hybrid connectivity: The supplier's data store is an on-premises Microsoft SQL server. The normalized purchase order received through the cloud application has to be persisted in the on-premises data store. This is achieved through Hybrid connectivity.

To prepare a BizTalk Services environment, see Administration and Development Task List in BizTalk Services. To set up the EDI message transfer, you need to access the BizTalk Services Portal.

This tutorial is written around a sample, EAIEDITutorial.zip, which is available to download at MSDN Code Gallery. You could use the sample and go through this tutorial to understand how the sample was built. Or, you could use this tutorial to create your own application. This tutorial is targeted towards the second approach so that you understand how this application is built. Also, as much as possible, the tutorial is consistent with the sample and uses the same names for artifacts (for example, schemas, transforms) as used in the sample.