EAI – Sources - Bridges – Destinations (as of OCT-2014 release)

The EAI can be divided into Sources, Bridges and Destinations. BizTalk Adapter Service (BAS) – can be considered as a special type of destination - relay end point.

Source is from where you want to receive the message (equivalent to Receive Port in BizTalk on premise)

Destination is where you want to send the message (equivalent to Send Port in BizTalk on premise)

Bridge connects Source and Destination and provides various stages to modify, transform, enrich the message (equivalent to Pipeline in the BizTalk on premise)

Sources-Bridges-Destinations

Following type of sources, bridges and destinations are available. Sources and Destinations have typical properties to be set as part of their configuration.
Note that currently only XML type bridge can be used for two way operations.

 

A connector is used to connect Source and Bridge / Bridge and Destination. The properties set on the connector help in defining the conditions to route the message to a correct destination in case there are multiple destinations available.

 

Configuring Bridges

When you double click on the bridge in design mode, it shows the following respective configuration screen. You can configure those various stages to manipulate the message / properties as per your requirements.

 

Message Types

A single BizTalk Service project can have multiple bridges and multiple schemas. For ease of use and to save on processing time, you can associate schemas with bridges. In other words, you can require that a specific bridge can only process messages that conform to a specific schema or a set of schemas.

Decode

This stage applies to XML One-Way Bridge only. It does not apply to XML Request-Reply Bridges.

The Decode stage decodes an incoming text message to an XML message and passes it on the Validate stage in the XML One-Way Bridge bridge. Unlike other stages in the bridge, the Decode stage does not have an IsEnabled property. The IsEnabled property for a stage defines whether the stage processes the message passing through the bridge. The Decode stage does not include this property because whether the message is decoded or not depends on the content type of the incoming message. If a bridge receives a message of ‘text/plain’ content type, the decode stage decodes the message and converts it to an XML message. Rest of the processing at each stage within the bridge happens on the XML message and not the flat file message. However, if a message with the any of the other content types is received by the bridge, the decode stage is not activated and the message is simply passed over to the next stage.

Validate

As part of the Validate stage, you can specify whether the stage does any schema validation on the incoming request message and whether the validation warnings can be propagated back to the client as exceptions.

Enrich

As the name suggests, the Enrich stage enables message enrichment by defining properties, the values for which can be derived from the message header (standard or custom), through default properties promoted by BizTalk Services, from an external data source (only Microsoft Azure SQL Database tables supported in this release), or from an element within the message body. These properties can then be used to either route the message to a destination endpoint or for further processing by the message receiving entity.

Transform

As part of the Transform stage, you can specify the transforms to be used by the bridge. You can also specify whether you want to enable or disable the stage.

Encode

This stage applies to XML One-Way Bridge only. It does not apply to XML Request-Reply Bridges.

As part of the Encode stage, you can specify the flat-file schema to use for converting an XML message into a flat-file message. By the time a message reaches the Encode stage, it is already in the XML format. Depending on how the Encode stage is configured, the message is either encoded to a flat-file format or sent out as an XML message.

Reply Action

This stage applies to XML Request-Reply Bridge only. It does not apply to XML One-Way Bridges.

While Reply Action is technically not a ‘stage’ in an XML Request-Reply Bridge, it plays a key role in ensuring that any protocol mismatches between the message sender and message receiver are bridged right before the response message is finally sent back to the message sender. See Reply Action.

Using Custom Code in Bridges

While the fixed pattern of bridges (Validate, Enrich, Transform, and Enrich) provided with 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. To enable such scenarios, bridges include the option of executing custom code at some key stages of the bridge.