Using BizTalk Services from a Windows 8 Application

We now have a tutorial and sample on how to send messages from a Windows 8 application to BizTalk Service. The tutorial and sample are built around an end-to-end business scenario. The business scenario covers most of the facets of a real-life situation.

Business scenario

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 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 puts in the order.
  • The Fourth Coffee Restaurant is notified of the customer order, processes it, and sends the invoice back to Contoso, Ltd., which in turn sends it to the customer via e-mail.

Implementing the Business Scenario

To implement the business scenario, Contoso, Ltd. decides to use Microsoft integration offerings, especially, Windows 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-premise 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

Comments (0)

Skip to main content