Windows Azure BizTalk Service EAI Overview

Introduction

Earlier today we announced the public preview of our Windows Azure BizTalk Service (WABS). We have collaborated with multiple partners and customers to build a simple, powerful and extensible cloud-based integration service that provides Business-to-Business (B2B) and Enterprise Application Integration (EAI) capabilities for delivering cloud and hybrid integration solutions. The service runs on a secure, dedicated per tenant environment that you can provision on demand, while it is being managed and operated by Microsoft.

Let’s look at a brief overview of our EAI offering in WABS.

EAI in WABS

One of the core requirements for WABS is to bridge the message and transport protocol mismatch between two disparate systems. In cloud parlance, we should think of each system on the cloud as an endpoint. A message exchange between these two endpoints (which are either extensions of on-premises applications or representing an application running on the cloud) happens through Service Bus. Service Bus being a purely relay service, just passes on the message originating from one endpoint to another. However, given that the two systems are disparate and probably follow different messaging format and protocols, it becomes imperative that the Service Bus provides rich processing capabilities between the two endpoints. The processing capabilities could include the following:

• ·         The ability to connect systems following different transport protocols
• ·         The ability to validate the message originating from the source endpoint against a standard schema
• ·         The ability to transform the message as required by destination endpoints
• ·         The ability to enrich the message and extract specified properties from the message. The extracted properties can then be used to route the message to a destination or an intermediary endpoint.

These capabilities are made available through EAI on WABS. WABS Services provides these capabilities as different stages of a ‘message processing bridge’. Each of these stages can be configured as part of the bridge. Let’s overview some of these capabilities.

Feature outline and overview

Bridges

Conceptually, a bridge is a single message processing unit composed of 3 parts – sources, pipelines & destinations. This is the basic building block to design ones integration platform.

Pipelines are message mediation patterns. Message mediation, as the name implies, is an intermediate processing stage of the message as it travels from the originating to the final destination. Mediating the message might involve decoding the message, inspecting the message, transforming the message, validating the message, routing the message, enriching the message, etc. In a stricter sense with respect to WABS, bridges offer one kind of message mediation, which is to bridge message-related mismatches in scenarios where the origin and the destination of the message are heterogeneous but are still part of a message flow. Following are certain characteristics of bridges provided as part of Windows Azure BizTalk Services.

Pipelines are composed of stages and activities where each stage is a message processing unit in itself.

Each stage of a pipeline is atomic, which means either a message completes a stage or not. A stage can be turned on or off, indicating whether to process a message or simply let it pass through.

WABS also provides a rich set of sources and destinations to build ones message interchange platform along with the flexibility of configuring different types of pipelines.

VS Design Experience

WABS EAI provides connectivity to different protocols and applications, and provide message-processing capabilities such as validation, transformation, extraction, and enrichment on the cloud. However, neither of these can be used in isolation and ‘tie up’ with other entities on the cloud like topics, queues, etc. to provide an end-to-end message flow. For example, you could have a scenario where the a client sends a request message that needs to be processed on the cloud, routed to a queue, and then eventually inserted into a SQL Server database. To configure this scenario, you need to use an XML bridge, a Service Bus queue, followed by BizTalk Adapter Service in a sequence. This presents a need for a design surface where you could stitch different components of a message flow together. Azure BizTalk Services provides a design surface called BizTalk Service project that helps you achieve this. The BizTalk Service project design surface is available as a Visual Studio project type and is installed with Azure BizTalk Services SDK.

The project provides a friendly tool-box from which one can drag and drop pipelines, sources, destinations including LOB entities. It allows for easy configuration of all involved entities and once done, also allows deploying this solution into your WABS service. You can also upload artifacts required by your project.

Flat file/XML file support

Flat file message transfer is a key requirement in real world Azure BizTalk Services scenarios. Many enterprise applications receive flat file messages from client applications, such as SAP IDOCs. To enable flat-file processing over the cloud, you can use bridges available as part of Azure BizTalk Services.

Similar to flat files, EAI also supports XML file processing. XML is more of a standard message format and easy to work with.

Custom code

While the fixed pattern of bridges (Validate, Enrich, Transform, and Enrich) provided with Azure BizTalk Services serves the requirements of many integration scenarios, sometimes you need to include custom processing as part of your bridge configuration. For example, you might want to convert a message from a flat-file or an XML format to other popular formats, such as XLS or PDF before sending the message out. Similarly, at each stage of message processing, you might want to archive the message to a central data store. In such cases, the fixed pattern of the out-of-box bridges becomes insufficient. Hence, to enable such scenarios, bridges include the option of executing custom code at some key stages of the bridge.

Tracking

Within a bridge, a message undergoes processing under various stages and can be routed to configured endpoints. Specific details of the message such as transport properties, message properties, etc. need to be tracked and queried separately by the bridge developers to keep a track of message processing. Additionally, while a message is being processed by the bridge, there can be failures of many types. These failures must be propagated back to the bridge developers/administrators or the message sending client so that appropriate actions can be taken to fix these errors.

Bridges now provide support for tracking the messages thereby enabling the bridge developer and message sending clients to track message properties defined during the bridge configuration. You can configure the bridge to track the messages using options available from the Bridge Configuration surface.

Important Links

Please refer to the below links for more information.

Keep a lookout for more blogs in the near future explaining more of WABS capabilities. We hope that the community will continue to invest in WABS as we have and drive its evolution.