The BizTalk Adapter Pack 2.0 now contains five system
and data adapters including SAP, Siebel, Oracle databases, Oracle
applications, and SQL Server. What are these adapters and how are they
different than the adapters available for previous version of BizTalk?
Up until recently,
BizTalk adapters were built using a commonly defined BizTalk Adapter
Framework. This framework prescribed interfaces and APIs for adapter
developers in order to elicit a common look and feel for the users of
the adapters. Moving forward, adapter developers are encouraged by
Microsoft to use the new WCF LOB Adapter SDK. As you can guess from the
name, this new adapter framework, which can be considered an evolution
of the BizTalk Adapter Framework, is based on WCF technologies.
All of the adapters in the
BizTalk Adapter Pack 2.0 are built upon the WCF LOB Adapter SDK. What
this means is that all of the adapters are built as reusable,
metadata-rich components that are surfaced to users as WCF bindings. So
much like you have a wsHttp or netTcp binding, now you have a sqlBinding or
sapBinding. As you would expect from a WCF
binding, there is a rich set of configuration attributes for these
adapters and they are no longer tightly coupled to BizTalk itself.
Microsoft has made connection a commodity, and no longer do
organizations have to spend tens of thousands of dollars to connect to
line of business systems like SAP through expensive, BizTalk-only
adapters.
This latest version of the
BizTalk Adapter Pack now includes a SQL Server adapter, which replaces
the legacy BizTalk-only SQL Server adapter. What do we get from this SQL
Server adapter that makes it so much better than the old one?
|
Feature
|
Classic SQL Adapter
|
WCF SQL Adapter
|
|---|
|
Execute create-read-update-delete statements on tables and views;
execute stored procedures and generic T-SQL statements
|
Partial (send operations only support stored procedures and updategrams)
|
Yes
|
|
Database polling via FOR XML
|
Yes
|
Yes
|
|
Database polling via traditional tabular results
|
No
|
Yes
|
|
Proactive database push via SQL Query Notification
|
No
|
Yes
|
|
Expansive adapter configuration which impacts connection management and
transaction behavior
|
No
|
Yes
|
|
Support for composite transactions which allow aggregation of operations
across tables or procedures into a single atomic transaction
|
No
|
Yes
|
|
Rich metadata browsing and retrieval for finding and selecting database
operations
|
No
|
Yes
|
|
Support for the latest data types (e.g. XML) and SQL Server 2008
platform
|
No
|
Yes
|
|
Reusable outside of BizTalk applications by WCF or basic HTTP clients
|
No
|
Yes
|
|
Adapter extension and configuration through out of the box WCF
components or custom WCF behaviors
|
No
|
Yes
|
|
Dynamic WSDL generation which always reflects current state of the
system instead of fixed contract which always requires explicit updates
|
No
|
Yes
|
Needless to say, the WCF SQL
Server Adapter offers significant benefit over the previous SQL Server
adapter and introduces a range of new capabilities that are well overdue
in the realm of database interaction. In this section, we will look at a
few use cases and patterns for this adapter, which best demonstrate the
capabilities it provides.
Solution set up
Before we get started
building a series of different scenarios, we need to prepare our
environment with the database tables and schemas that will be reused
over and over again. All of our demonstrations in this article deal with
batches of biologic materials that we use in our drug making process.
These batches of material go through different stages before being ready
for shipment.
To get started, I
created a SQL Server 2008 database named
BizTalkSOA, which houses our relevant
tables. In all, there are four tables that we will use throughout this article:
Next, we need a new BizTalk project to hold our enterprise schema that
represents a batch of materials. While messages about material batches
may arrive to (or depart from) BizTalk Server in diverse formats, this
canonical schema is what BizTalk should use internally to represent this
enterprise object.
Now we're ready to start
building solutions on the SQL Server WCF adapter.
