SALES: 1-800-867-1380
This topic has not yet been rated - Rate this topic

Using Custom Code in Bridges

Updated: November 21, 2013

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. Hence, to enable such scenarios, bridges include the option of executing custom code at some key stages of the bridge.

Which stages in the bridge can include custom code?

In an XML One-Way Bridge, the following stages can include custom code:

  • Decode

  • Validate

  • Enrich

  • Transform

  • Enrich (post-Transform)

  • Encode

In an XML Request-Reply Bridge, the following stages can include custom code:

  • Request side

    • Validate

    • Enrich

    • Transform

    • Enrich (post-Transform)

  • Response side

    • Enrich

    • Transform

    • Enrich (post-Transform)

In a Pass-Through Bridge, the only stage, the Enrich stage, can include custom code.

How do the bridges include custom code?

The stages of the bridges that can include custom code provide two properties, On Enter Inspector and On Exit Inspector. For each of these properties you must provide the assembly-qualified name of the type that includes the custom code you want to execute as part of the bridge. The type that defines and includes the custom logic must implement the base type of the custom handler, which is described under Message Inspectors. For instructions on how to include the custom code in the bridge configuration, see How to Include Custom Code in Bridges.

Message Inspectors

To enable including custom code as part of bridge processing, BizTalk Services provides the IMessageInspector interface as part of the Microsoft.BizTalk.Services namespace. The type that includes the custom code must always implement this interface. For more information, see API Reference for Windows Azure BizTalk Services.

Passing Configurable Values to the Custom Code

On most occasions, the custom code you include as part of the bridge processing might need to work on/with data that is available at runtime, as the bridge is processing the message. For example, there could be a scenario where you need to promote a property on the message but the value for that promoted property is dynamically available only at runtime, and cannot be set while you are writing the custom component. This calls for a way of using configurable properties as part of the custom code component. BizTalk Services provides a PipelinePropertyAttribute property attribute, that can specified for a publicly settable string property within the class that implements the IPipelineMessageInspector interface. The property that has the attribute specified can be set in the inspectors in the bridge configuration surface at design time. For more information on how to use configurable properties with custom components, see How to Include Custom Code in Bridges.

See Also

© 2013 Microsoft Corporation. All rights reserved.
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.