Using BizTalk Services from a Windows 8 Application


Updated: December 7, 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, with its REST and .NET interfaces, can be used from a variety of applications, such as Windows 8 applications, to create an end-to-end integration solution. This tutorial demonstrates how trading partners can onboard themselves onto their partner’s BizTalk Services environment, and how end users can use modern Windows 8 applications to send messages to bridges deployed on BizTalk Services. For better understanding, this tutorial uses an end-to-end business scenario that showcases how different personas involved in a business process can be integrated using BizTalk Services.

Contoso, Ltd. is a car manufacturing company looking to build a system, Cloud Car, that provides rich experience to their customers by enabling connectivity to cloud and the rich set of services that are available via the cloud. To start with, Contoso, Ltd. envisions a modern application that enables customers to search for available services in the surrounding areas on the go (gas stations, restaurants, etc.), browse through the service catalogs they offer (fuel prices, restaurant menus, etc.), and then order the service they wish to use. As a first step, Contoso, Ltd. plans to start this service with a restaurant, Fourth Coffee. Contoso, Ltd. intends to build an end-to-end system that is scalable to easily onboard more and more partners, while also providing rich end-user experience to the customers that will be using the service. At a high-level, Contoso, Ltd. wants to enable the following end-to-end application experience for its customers:

  • A customer of Contoso, Ltd. launches the Cloud Car application from the car, and chooses to look at the nearby dining options.

  • The Cloud Car application determines the car’s location and suggests the nearest location of Fourth Coffee, a dine-in/drive-in restaurant.

  • After selecting the Fourth Coffee restaurant, the customer is presented with the menu available at the restaurant. The customer selects the items of interest and places the order.

  • The Fourth Coffee Restaurant is notified of the customer’s order, processes it, and sends the invoice back to Contoso, Ltd., which in turn sends it to the customer via e-mail.

To implement the business scenario, Contoso, Ltd. decides to use Microsoft integration offerings, especially, Microsoft Azure BizTalk Services. For the end-user application, one the customer can use from their cars, Contoso, Ltd. decides to use a Windows 8 modern app.

Before understanding the application flow, let us assume that one of the prerequisites for the application flow is already completed, which is Fourth Coffee must have already registered itself as a partner in the BizTalk Services portal. Fourth Coffee uses the Trading Partner Management OM REST API to onboard itself as a partner. It also uses the REST API to register the menu options it provides for dining.

After this one-time task is completed, this is how the application flows:

  1. A customer of Contoso, Ltd. uses the Cloud Car application, which is a Windows 8 modern app. Using the app, the customer selects the nearest location of the Fourth Coffee restaurant, looks at the menu, selects the items of choice, and places the order.

    The order request, which is in the form of an XML message, is sent to a BizTalk Services bridge (purchase order bridge) that Contoso, Ltd. deploys as part of its BizTalk Services subscription.

  2. The bridge processes the message (validates the message against the expected message schema, transforms it to an X12 purchase order (850), etc.), and then routes it to an Azure blob (purchase order blob). The bridge also inserts the purchase order message into an on-premise SQL Server database.

  3. An Azure worker role continually polls the Azure blob and reads the 850 purchase order message from the blob.

  4. The worker role routes the purchase order from the blob to an EDI Send bridge, also deployed under Contoso, Ltd.’s BizTalk Services subscription.

  5. The EDI Send bridge processes the purchase order and routes it to another Azure blob for the supplier, Fourth Coffee.

  6. Using an application, the Fourth Coffee restaurant reads the message from the blob, accepts or rejects the order, and generates an X12 810 invoice.

  7. The Fourth Coffee restaurant application sends the EDI X12 invoice back to the EDI receive bridge deployed by Contoso, Ltd.

  8. The EDI receive bridge, processes the incoming X12 810 invoice, and then routes the message to another EAI bridge (invoice bridge) deployed by Contoso, Ltd. to process the invoice messages.

  9. The EAI invoice bridge does the following:

    • Processes the message and routes it to an Azure blob storage.

    • Inserts the invoice data into an on-premises SQL Server database.

    • Sends an e-mail to the customer with the order details.

The following illustration depicts the end-to-end scenario.

CloudCar application flow

Contoso, Ltd. aims at delivering an end-to-end Cloud Car solution, which can be used by the partners (such as Fourth Coffee to easily onboard themselves and list their item catalogs) as well as end users to access the different services as they are on the move. To deliver this experience, Contoso, Ltd. must create four different, but connected applications.

  • A self-service application to onboard partners, such as Fourth Coffee, that enables partners to register them with BizTalk Services portal for Contoso, Ltd., and enter the details for the services that they offer.

  • An integration layer that accepts customer request messages, processes the purchase order and invoice messages, and sends communication out to the end users. This integration layer is created using BizTalk Services and other Azure technologies.

  • An application for the Fourth Coffee restaurant to receive purchase order message, generates invoice, and send it back to the Azure integration layer.

  • And finally, a Windows 8 application that the customers can use to browse the service, place orders, etc.

To map the tutorial to these personas, this tutorial is divided into four parts, with each part focusing on a specific persona.

Before you start with this tutorial, make sure you have provisioned Microsoft Azure BizTalk Services. For instructions, see BizTalk Services: Provisioning Using Azure classic portal.

This tutorial is written around samples which are available to download from the MSDN code gallery. You can either use the samples and go through this tutorial to understand how the sample was built or just use this tutorial to create your own end-to-end solution. Because this tutorial aims to showcase the capabilities of BizTalk Services, for components based on BizTalk Services, the tutorial provides steps on how to create those components in your environment. For other components used to set up the end-to-end solution, such as partner onboarding application, console application to process customer orders, and Windows 8 application to place orders, the tutorial uses the components provided with the sample and does not go into the details of how to create those applications from the start. Also, to be consistent with the sample, the names of artifacts (e.g. schemas, transforms, etc.) used in this tutorial are same as that in the sample.

The samples available from the MSDN code gallery contain different components, representing the different personas involved with the tutorial. The sample cannot include the configuration that you must do on the BizTalk Services Portal on Azure. For that, you must follow the steps in this tutorial to set up your EDI agreement. This is how you should use the sample to set up the end-to-end solution.

  1. Use the PartnerOnboarding sample application from the sample package to onboard a partner. Make changes to the application as described in Set up the application to onboard partners to use the application in your BizTalk Services environment.

  2. The CloudCar_Integration component represents the integration layer for the sample. You could either follow the instructions in the tutorial at Set up the integration layer to create your own integration component, or use the one provided with the sample and make relevant changes to use it in your BizTalk Services environment. The changes required to use it in your environment are provided as part of the instructions at the sample download location.

    The integration layer also uses an Azure worker role. You can use the code BlobPollerRole component, make changes to the configuration values, and deploy it under your Azure subscription.

  3. Use the SupplierAppConsole sample application from the sample package to represent the Fourth Coffee application to approve or reject orders. Make configuration changes to the application, as described at Create the Fourth Coffee application to receive orders and return invoice, to use it in your Microsoft Azure and BizTalk Services environment.

  4. Use the CloudCar Windows 8 sample application to look for Fourth Coffee restaurants, pull up their menu, and place an order. Make changes to the application, as described at Create the Windows 8 customer application, to use it in your environment, and then follow the instructions at Test the solution to test the end-to-end solution flow.


Information about all the samples available as part of this tutorial is available in the Download the samples topic.