BizTalk Legacy Adapter Overview

BizTalk Server 2004 features a revamped BizTalk Utilities Adapter Framework. The premise is that existing Adapters developed for BizTalk Server 2002 cannot be used within this new Framework and would have to re-developed.

If we look at the fact that almost 45% of existing Adapters have been developed by customers themselves this could leave quite an effort when planning to migrate to BizTalk Server 2004.

The BizTalk Utilities Legacy Adapter allows you to use your existing Adapters developed for BizTalk Server 2002 within BizTalk Server 2004, without having to re-develop them for the new BizTalk Utilities Adapter Framework.

System Requirements

The following are the minimum software requirements for the BizTalk Utilities Adapter:

•  Microsoft Enterprise Instrumentation Framework
•  Microsoft BizTalk Server 2004
•  Microsoft BizTalk Server 2002

BizTalk Server 2002 can be installed after installing BizTalk Server 2004. However, BizTalk Server 2002 Services do not need to run in order for the BizTalk Utilities Adapter to function.

Enterprise Instrumentation Framework (EIF)

The BizTalk Utilities Adapter utilises EIF for writing event and tracing information to the Application Event Log and Windows Trace Files.

The Microsoft Enterprise Instrumentation framework provides unified management, eventing, and diagnostic tracing services for enterprise applications in a production environment. Enterprise Instrumentation enables developers to consistently instrument enterprise applications, which are increasingly decoupled and distributed, and enables support staff to use a "white-box" approach to monitoring and diagnosing application health, faults, or other internal conditions.

Every released software application, regardless of size or complexity, imposes a common requirement on the business that the application serves: it must be managed to ensure that the application provides its services correctly and reliably during its operational lifetime. Instrumentation plays a key role in application manageability, allowing a particular software or hardware element to publish - or be queried for - relevant information. Examples of common instrumentation mechanisms include performance counters, event logs, Windows 2000 Event Trace, and Windows Management Instrumentation (WMI). These mechanisms are often complementary, as in the example of querying an event log through a WMI provider.

Achieving consistent instrumentation across all enterprise applications is a difficult task. Today, enterprises that build applications on Microsoft platforms must instrument their applications by directly writing to event logs, performance counters, third-party instrumentation APIs, or their own common instrumentation wrappers and libraries. Implementing and supporting the various forms of instrumentation brings additional challenges, given the distributed nature of today's n-tier, Web-enabled applications.

Operations staff must be able to trace specific paths through the system, not just monitor individual events and event sources. Logically related events from physically different servers need to be correlated. The instrumentation itself must be suitable for a production application; instrumentation overhead must minimally affect application throughput. Finally, organizations must be able to leverage as many existing management tools and infrastructure as possible, to monitor and troubleshoot the enterprise applications they support.

Key features of this framework are:

•  Unified programming model, suitable for both enterprise developers and system developers.
•  Structured WMI event schema, which acts as a supportability contract between Development,   Test, and Operations teams.
•  Scriptable configuration layer, allowing operations teams to configure how events are raised or logged from an application.
•  Support for raising or logging events through WMI, Windows Event Log, and Windows Event Tracing, a high-speed kernel-mode tracing system.
•  Correlation of events to business processes or operations with Request Tracing, which allows operations staff to troubleshoot requests across a distributed application.
• In Addition, the BizTalk Utilities Adapter incorporates the following enhancements to EIF:
• The Level of Tracing and Eventing for the BizTalk Utilities Adapter can be set by running a Wizard in Administration Microsoft Management Console (MMC) Snap-In. Levels that can currently be set is for Production, Testing/QA and Development.
• Tracing Sessions can be enabled or disabled from the MMC Snap-In.
• Trace Files can be viewed and exported from the MMC Snap-In.

Any BizTalk Utilities Adapter that implements the following BizTalk Server 2002 interfaces:

•  IBTSApp Integration Interface.

•  I Pipeline Component and I Pipeline Component Admin Interfaces.

Note: BizTalk Utilities Adapters developed in the .NET Framework should be installed in the Global Assembly Cache (GAC).

BizTalk Utilities Adapters can either be hosted in COM+ or are required to have Affinity assigned within the Windows Registry.

Configuring the Adapter

BizTalk Utilities Adapters are configured when defining a Send Port in the BizTalk Server Explorer in Visual Studio .NET 2003. The Process has 3 simple steps to it.

The First Step is to select which BizTalk Utilities Adapter you want to use.

During the Second step you will select which Interface to use on the BizTalk Utilities Adapter.

If you opted to use the I Pipeline Component Interface you will be prompted to enter Parameters for the BizTalk Utilities Adapter. These parameters were traditionally set in the Advanced Channel Properties in BizTalk Server 2002.

Note: Some Parameters may automatically default to True or False, usually these need to be reset to 0 (False) or 1 (True).

Other Adapter Configuration Parameters

The BizTalk Utilities Adapter supports Batching and the size of batches can be specified.

The Fields option allows you to add or override the Global Filed Mappings for the BizTalk Utilities Adapter.

BizTalk Server 2004 requires that a Schema incorporates a default Target Namespace, this Namespace also needs to be present with an instance of the Document. The Remove Namespace option will remove the Target Namespace from an XML Document before it is submitted to an Adapter. When a response is received from the BizTalk Utilities  Adapter the Target Namespace will be re-attached to the Response Document.

This would then require that the Inbound and Outbound Schemas of XML Documents have the same Target Namespace.

Field Mappings

The Mapping of fields in BizTalk Server 2004 to fields in BizTalk Server 2002 can be specified on 2 Levels, namely the Port Level or the BizTalk Utilities Adapter Level.

Fields specified on the Port Level, override Fields on the BizTalk Utilities Adapter Level.

In BizTalk Server 2004, a Message Box contains a Context with various Field values; these values contain a Namespace and Property Name/Value.

When the BizTalk Utilities Adapter is executed it will map the Namespace/Properties specified to BizTalk Server 2002 Fields.

For instance in the picture above, the Tracking ID value will be retrieved from the Namespace http://schemas.microsoft.com/BizTalk/2003/system-properties and the Property Transmit Work ID within that Namespace.

If no value is found or the Namespace/Property does not exist, the BizTalk Server 2002 Field will contain an Empty String value.

To learn more about these and other features, download an evaluation copy of BizTalk Utilities