WCF LOB Adapter SDK and BizTalk Adapter Pack : SQL

Using the WCF SQL Adapter to submit messages to SSB queues from BizTalk

SandeepP — Wed, 07 Oct 2009 07:11:00 GMT

This post is a follow-up to http://blogs.msdn.com/adapters/archive/2008/06/30/using-the-wcf-sql-adapter-to-read-messages-from-ssb-queues-and-submit-them-to-biztalk.aspx and explains how to push a message using the WCF SQL Adapter from BizTalk to a SQL Service Broker (SSB) queue.

Scenario

1. An XML message is dropped to a file share

2. This XML message is made available to the WCF SQL Adapter by using the File Adapter

3. The WCF SQL Adapter then pushes this XML message to a preconfigured SSB queue by invoking a Stored Procedure

Create the database artifacts required for the SSB conversation

1. A message type, which denotes the format of the message in the queue

2. A contract, which denotes the conversation between a sender and a receiver and also includes the type of message flowing between them

3. The Initiator & Target queues, where messages are stored

4. The Initiator & Target services, which utilize the above queues

USE master;

ALTER DATABASE <your db name here>

SET ENABLE_BROKER;

USE <your db name here>;

CREATE MESSAGE TYPE

[//SqlAdapterSSBSample/RequestMessage]

VALIDATION = WELL_FORMED_XML;

CREATE CONTRACT [//SqlAdapterSSBSample/SampleContract]

([//SqlAdapterSSBSample/RequestMessage]

SENT BY INITIATOR

);

CREATE QUEUE InitiatorQueue1DB;

CREATE SERVICE

[//SqlAdapterSSBSample/InitiatorService]

ON QUEUE InitiatorQueue1DB;

CREATE QUEUE TargetQueue1DB;

CREATE SERVICE

[//SqlAdapterSSBSample/TargetService]

ON QUEUE TargetQueue1DB

([//SqlAdapterSSBSample/SampleContract]);

5. A stored procedure, say InitiatorSP, that will take the message as an argument and push it to the SSB queue. Let’s use the name RequestMsg for the argument.

SET ANSI_NULLS ON

SET QUOTED_IDENTIFIER ON

CREATE PROCEDURE [dbo].[InitiatorSP]

@RequestMsg xml

BEGIN

DECLARE @DlgHandle UNIQUEIDENTIFIER;

BEGIN DIALOG @DlgHandle

FROM SERVICE

[//SqlAdapterSSBSample/InitiatorService]

TO SERVICE

N'//SqlAdapterSSBSample/TargetService'

ON CONTRACT

[//SqlAdapterSSBSample/SampleContract]

WITH ENCRYPTION = OFF;

SEND ON CONVERSATION @DlgHandle

MESSAGE TYPE

[//SqlAdapterSSBSample/RequestMessage]

(@RequestMsg);

END

Create the BizTalk artifacts

1. Start the BizTalk Server 2009 Administration Console

2. Create a new BizTalk application, say SSBSendApplication

3. Create a new Receive Port, say FileReceivePort and add a new Receive Location, say FileReceive

a. Set the Type to File and configure the Receive Folder to point to a local share, say c:\in

4. Create a new Static One-way Send Port, say SqlSendPort

a. In the General tab,

i. Set the Type to WCF-SQL

ii. Click Configure and set the properties as follows

1. In the General tab, set

a. Address – the format is “mssql://<servername>/<instancename>/<databasename>”. For example, on my machine (using the default instance of SQL server), mssql://localhost//SSBTestDb (where SSBTestDb is the name of my database)

b. Action – the format is “TypedProcedure/<schemaname>/<storedprocedurename>”. For example, in my case, it is TypedProcedure/dbo/InitiatorSP

2. In the Messages tab, select Template and fill in the XML box with the following

<InitiatorSP xmlns="http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo">

<RequestMsg>

<bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="string"/>

</RequestMsg>

</InitiatorSP>

*Note that this approach requires that the xml encoding is string.

iii. Leave the other properties as is

b. In the Filters tab, add a filter BTS.ReceivePortName == FileReceivePort

5. Create a new Static One-way Send Port, say FileSendPort

a. In the General tab, set the Type to File and configure the Receive Folder to point to a local share, say c:\out

b. In the Filters tab, add a filter BTS.SPName == SqlSendPort

6. At this point the configuration of BizTalk application is completed, so start the application.

Send the message to SSB queue

1. Drop a request file to the c:\in share (one that file receive port is using). Note that this exact message will show up in the SSB queue. Here’s a sample message

<RequestMessage>Hello World</RequestMessage>

Consume the message from SSB queue

1. You can now consume the message from the SSB queue. On running the below query, you will see the above message.

DECLARE @DlgHandle UNIQUEIDENTIFIER;

DECLARE @RecvMsg XML;

RECEIVE TOP (1)

@DlgHandle=conversation_handle,

@RecvMsg = CAST(message_body as XML)

FROM TargetQueue1DB;

IF NOT (@DlgHandle IS NULL)

BEGIN

END CONVERSATION @DlgHandle;

SELECT @RecvMsg AS ReceivedMessage;

END

Multiple ways to Poll (Receive Location in BizTalk) in the SQL Adapter

mdoctor — Mon, 06 Oct 2008 20:53:00 GMT

In this post, I outlined the ways in which stored procedures can be executed using the SQL Adapter. Similar to the methods described there, are very similar methods for polling on the inbound side. (I won’t mention the advantages/limitations/workarounds here, since there are very similar to those mentioned in the other post).

1. The first method for polling, manifested as the “Polling” operation in the Metadata Search/Browse tool. At runtime, the SQL statement specified in the “PollingStatement” binding property gets executed, and the result sets returned (we support multiple result sets being returned) are surfaced as System.Data.DataSet[] (an array of datasets).

NOTE – in order to let the adapter know that you want it to perform this operation at runtime, set the InboundOperationType binding property to Polling.

2. The next approach was to try and expose the result sets as “strongly typed”. For this purpose, we added the “TypedPolling” operation which you can see in the Metadata UI. Metadata is obtained (at design time + runtime) using ADO.NET’s CommandBehavior::SchemaOnly option (which translates to SET FMTONLY ON).

NOTE – in order to generate the metadata, setting the InboundId property in the Connection Uri is mandatory – since in a single BizTalk application, you can have multiple receive locations with different PollingStatement values, and in order to differentiate the XSDs, the InboundId value is used in the XSD namespace (thus, the InboundId should be different for different Receive Locations)

NOTE – in order to let the adapter know that you want it to perform this operation at runtime, set the InboundOperationType binding property to TypedPolling.

3. In CTP4 (releasing end of October 2008), we’ve added one more mechanism. This was mainly done for backward compatibility.

In this method, the PollingStatement you specify should return data in XML format (e.g., SELECT Col1 FROM Table1 FOR XML AUTO). At runtime, the XML data returned is enclosed within the root tag defined by the values in the binding properties XmlStoredProcedureRootNodeName and XmlStoredProcedureRootNodeNamespace.

NOTE – in order to let the adapter know that you want it to perform this operation at runtime, set the InboundOperationType binding property to XmlPolling.

Multiple ways to generate metadata / execute Stored Procedures in the SQL adapter

mdoctor — Tue, 30 Sep 2008 14:05:00 GMT

If you’ve used the SQL Adapter in CTP3 of the BizTalk Adapter Pack V2, you’ll notice that there are two nodes in the Metadata Hierarchy for Stored Procedures – one is named “Procedures”, and the other is named “Strongly-Typed Procedures”. What’s the difference, and what are the scenarios which they are meant to solve? What are their limitations? I’ll try to explain all this, in this post.

1. The first method of executing Stored Procedures which we added in the adapter, manifested as the operations under the “Procedures” node in the Metadata hierarchy. The operations here have the action “Procedure/<database_schema_name>/<procedure_name>”. For these operations, the adapter reads the System Tables in SQL Server, finds out the parameters to the procedure, and exposes them as IN or INOUT parameters in the WSDL. However, we yet need a way to return the result sets which the Stored Procedure can return at execution time. The adapter exposes these result sets as a return parameter, of type System.Data.DataSet[]. Being an array, multiple result sets can be returned.

At runtime, the adapter executes the Stored Procedure using the ADO.NET function SqlCommand::ExecuteReader(). Each result set returned by executing the Stored Procedure is serialized into its own DataSet; hence all of them together appear as DataSet[]. The response XML message contains both, the schema for each result set / DataSet, as well as the actual data in that result set / DataSet. When used in a .NET application, the schema + data together are used when deserializing the SOAP message into a DataSet object.

Advantages: Works for all stored procedures.

Limitations: The result sets are loosely typed (being a DataSet[]), and in BizTalk, are not helpful if you want to use the Mapper.

Workarounds: What you could do is, execute the procedure once, dump the XML message to a file location, and open it in notepad. Select the <schema> node within the result set section in the return parameter, copy-paste it into a new file, and save it with the .xsd extension. You now have a schema which you can deploy in your BizTalk orchestration/project. Also, use the Message Template feature in the WCF-Custom/WCF-SQL port configuration, using a XPath query to only select out the data (at runtime) for that particular result set (matching the XSD which you deployed); ignoring the other result sets (if any) and out parameters. You now have a XML blob being submitted to BizTalk, which conforms to the XSD which you deployed.

2. The next approach we took, was to try and expose the result sets as “strongly typed”, instead of the loosely typed DataSet[] above. These operations manifest as the operations under the “Strongly-Typed Procedures” node in the metadata hierarchy. The action is of the form “TypedProcedure/<database_schema_name>/<procedure_name>”. For these operations, the adapter reads the System Tables in SQL Server, finds out the parameters to the procedure, and exposes them as IN or INOUT parameters in the WSDL. In order to expose the returned result sets in a “strongly typed” fashion, the adapter needs to know what the metadata for the returned result sets will look like. For this purpose, at design time, the adapter executes the Stored Procedure using the ADO.NET function SqlCommand::ExecuteReader(CommandBehavior::SchemaOnly). This translates to the SET FMTONLY ON option being used. However, in order to execute the Stored Procedure, the adapter needs to pass in values to the parameters. For this purpose, the adapter uses DBNull.Value for each parameter. Upon execution, the adapter gets back multiple (empty) result sets, and from these, the adapter can obtain the metadata for the result sets which can potentially be returned at runtime.

Note – I use the word potentially. This is because, at runtime (FYI – the adapter uses the ADO.NET function SqlCommand::ExecuteReader() at runtime), a Stored Procedure can return different result sets based on the input values. For example, if an input parameter has the value 1, the Procedure could return a result set by performing the operation “SELECT * FROM TABLE1”. If the input parameter has the value 2, it might actually execute “SELECT * FROM TABLE2”. At runtime, only one of the two result sets will be returned, depending on whether the input parameter is 1 or 2. However, at design time, when the SET FMTONLY ON statement is used, both the (empty) result sets are returned. The adapter exposes them both as complex out parameters (and names them in the metadata as TypedProcedureResultSet1, TypedProcedureResultSet2, etc). At runtime, one will be null, while the other will have the appropriate data filled in.

Note – The current design of the WCF LOB Adapter SDK (on which the SQL Adapter is based) is that metadata is also required at runtime. Hence, at runtime too, the adapter executes the Stored Procedure using SET FMTONLY ON (just once) to obtain the metadata. Then, for every message being passed to the adapter, the adapter executes the Stored Procedure, and based on the result sets returned, tries to determine whether it should be serialized as TypedProcedureResultSet1, or TypedProcedureResultSet2, etc (for example) (based on the metadata it obtained earlier by using SET FMTONLY ON).

Advantages: Strong typing of the result sets.

Limitations:

These operations cannot be used to execute “complicated” Stored Procedures – for example, a hypothetical procedure which returns multiple result sets (from potentially different tables) within a loop. This is because the adapter won’t be able to figure out which result set (at runtime) needs to be serialized as which complex type (TypedProcedureResultSet1, or TypedProcedureResultSet2, or something else).
These operations won’t work for Stored Procedures, when in the procedure code, a temporary table is created, and then, one of the returned result sets is obtained by doing a SELECT on that temporary table. The reason being, when the SET FMTONLY ON option is used, no temporary tables are created. However, when the SQL execution engine comes across the line SELECT * FROM #temptable, it throws an error, (something to the effect of it not finding an artifact named #temptable), since it never created this artifact in the first place (since SET FMTONLY ON is not supposed to make any changes on the server).
I mentioned above that during metadata retrieval time, the adapter needs to pass in values for all parameters to the Stored Procedure, and for this purpose it passes in DBNull. Now, if the Procedure internally calls a System Stored Procedure, and passes in one of the input parameters (which in our case is NULL), and if the System Stored Procedure returns an error if it sees the value as NULL, the adapter will get an exception at metadata retrieval time. NOTE – this won’t happen in your custom procedure if your code itself throws an error if it sees an input parameter having the value NULL, since for user procedures, when SET FMTONLY ON is true, the execution engine skips the evaluation of the if statements (this evaluation only happens in system stored procedures).

Workarounds:

Use one of the other Stored Procedure execution methods.
For working around the issue where temporary tables are used, you can modify the Stored Procedure code - http://www.sqlservercentral.com/articles/FMTONLY/64130/ has an example of what you can do.

3. In CTP4 (releasing end of October 2008), we’ve added one more mechanism to execute Stored Procedures. This was mainly done for backward compatibility.

The earlier SQL adapter required result sets returned from Stored Procedures to use the FOR XML syntax. This was because the old adapter used SQLXML; using FOR XML would instruct the SQL Server to return the result set as a single XML value, and the SQLXML code on the client would then parse the XML returned.

In methods 1 and 2 above, you’ve seen that the new adapter used the ADO.NET SqlCommand::ExecuteReader() function. If this function was used to execute a Stored Procedure which returned a result set using FOR XML, all the adapter would see is a single XML value (exposed as a string) – i.e., the adapter thinks that the returned result set only has one column. Even worse, if the XML value was large, it would get split into multiple rows. This is of course extremely cumbersome to work with.

For this purpose, a third mechanism was added, what I call “XML Procedures”. The action for such operations is “XmlProcedure/<database_schema_name>/<procedure_name>”.

There is no design time experience for such procedures. Generating metadata involves the following:

Generate metadata for the same procedure under the “Procedures” node – this generates the metadata for the request message as well as the response message. Here, we are only interested in the request message schema, since that’s the format in which the request message needs to be sent (though you need to use the “XmlProcedure” action).
In SQL Server Management Studio, edit your Stored Procedure, and add the XMLDATA keyword at the end of the FOR XML statement (similar to what you would have done if using the older SQL Adapter).
Execute your Stored Procedure from SQL Server Management Studio. Before the actual data, you should see a <schema> node which has the metadata for the result set. Copy-paste the schema into a .xsd file. Also, add a root node (with namespace) to encapsulate the nodes in the data/schema (you’ll see why later).
This .xsd file will serve as the schema for the response message in BizTalk.
Remember to remove the XMLDATA keyword from the Stored Procedure code after you're done with the above steps.

At runtime, you need to do this:

Specify values for the XmlStoredProcedureRootNodeName (mandatory) and XmlStoredProcedureRootNodeNamespace (optional) binding properties. The XML obtained by executing the “FOR XML” Stored Procedure will be wrapped within this root node, with this namespace.
Use the “XmlProcedure/<database_schema_name>/<procedure_name>” action during execution (instead of “Procedure/<database_schema_name>/<procedure_name>”).

When the adapter sees the XmlProcedure action, it uses the ADO.NET SqlCommand::ExecuteXmlReader() function.

Advantages: You can continue using FOR XML Stored Procedures side-by-side with the old SQL Adapter. Can work with all stored procedures which return XML.

Limitations: There is no way to generate the metadata using the adapter, since the WCF LOB Adapter SDK does not have a way to accept input parameter values during design time. The adapter cannot use NULL for the parameter values (unlike how it did in 2 above), since obtaining metadata involves actual execution of the Stored Procedure, and therefore all the Stored Procedure logic comes into play, which might throw an error if an unexpected value is seen for an input parameter.

Workarounds: Use one of the other Stored Procedure execution methods.

Using the WCF SQL Adapter to read messages from SSB queues and submit them to BizTalk

mdoctor — Mon, 30 Jun 2008 17:58:00 GMT

In this post, I’m going to demonstrate how the Polling feature in the WCF SQL Adapter can be used to read messages from SQL Service Broker (SSB) queues and publish them in the BizTalk MessageBox. And to make it really simple, we’re going to do it without an orchestration.

(Note – most of the SSB portion in this post has been based on the SSB tutorial available at http://msdn2.microsoft.com/en-us/library/bb839489.aspx).

The scenario:

An external source publishes messages into a SSB queue.
At fixed intervals (the polling interval), the adapter checks the SSB queue to see if a message is available.
If a message is available, the adapter performs the actual RECEIVE operation to remove the message from the SSB queue and publish it in BizTalk – these operations are performed within the same DTC transaction.
A filter is used to send the data to a folder on the file system (using the File Adapter)

Creating the database artifacts required for the SSB conversation:

The artifacts which we need to create are:

A message type, which denotes the format of the messages in the queue
A contract, which denotes the conversation between a sender and a receiver (the contract also specifies the type of the message which will flow between them)
The Initiator and Target queues, in which the messages are stored
The Initiator and Target services, utilizing the above-mentioned queues.

I’m not going to explain the SQL statements below in detail, mainly because this post is not meant to be a tutorial on SSB – you can refer to SQL Server Books Online for more information on SSB.

USE master;
GO
ALTER DATABASE <your db name here>
SET ENABLE_BROKER;
GO
USE <your db name here>;
GO

CREATE MESSAGE TYPE
[//SqlAdapterSSBSample/RequestMessage]
VALIDATION = WELL_FORMED_XML;

CREATE CONTRACT [//SqlAdapterSSBSample/SampleContract]
    ([//SqlAdapterSSBSample/RequestMessage]
    SENT BY INITIATOR
    );

CREATE QUEUE InitiatorQueue1DB;

CREATE SERVICE
[//SqlAdapterSSBSample/InitiatorService]
ON QUEUE InitiatorQueue1DB;

CREATE QUEUE TargetQueue1DB;

CREATE SERVICE
    [//SqlAdapterSSBSample/TargetService]
    ON QUEUE TargetQueue1DB
    ([//SqlAdapterSSBSample/SampleContract]);

At this point, we’ve created the main database objects required for the SSB side of things.

Creating the BizTalk Artifacts

Start the BizTalk Server 2006 Administration Console.
Create a new BizTalk application – let’s call it “SSBPollingApplication”.
Create a new 1-way Receive Port – call it “SqlReceivePort”. Create a new Receive Location – call it “SqlReceiveLocation”.
Choose the Transport Type (in the Receive Location Configuration dialog) as “WCF-Custom”. Choose “PassThruReceive” for the Receive Pipeline.
Click configure, the WCF-Custom adapter configuration dialog pops up.
In the General tab, enter the URI denoting your SQL Server. The format is “mssql://servername/instancename/databasename”. For example, on my machine (since I am using the default instance of SQL Server, the uri I entered is “mssql://localhost//SSBTestDb” (my database is named “SSBTestDb”)).
In the Binding Tab, choose the binding as “sqlBinding”. In the configuration properties which are displayed below, set these:
1. pollingIntervalInSeconds = 2 (or whatever you're comfortable with)
2. polledDataAvailableStatement = SELECT COUNT(*) FROM TargetQueue1DB WITH (NOLOCK)
3. pollingStatement = (note, multi line statement follows):
  DECLARE @DlgHandle UNIQUEIDENTIFIER;
  DECLARE @RecvMsg XML;
  RECEIVE TOP (1)
  @DlgHandle=conversation_handle,
  @RecvMsg = CAST(message_body as XML)
  FROM TargetQueue1DB;
  IF NOT (@DlgHandle IS NULL)
  BEGIN
  END CONVERSATION @DlgHandle;
  SELECT @RecvMsg AS ReceivedMessage;
  END
4. A brief explanation of the 2 SQL blocks above:
  1. In the polledDataAvailableStatement, we’re checking if there are any rows in the SSB queue. It is this statement which is going to execute every “pollingIntervalInSeconds” seconds. If a non-zero value is returned, the adapter interprets it to mean that data is available, and only then proceeds to execute the pollingStatement.
  2. In the pollingStatement, we are selecting (and removing – the RECEIVE syntax removes the message, while SELECT would just peek at it) the first message in the SSB queue. We’re also selecting the conversation handle for that message. Also, if we did indeed successfully pick up the message from the queue (maybe someone got to it first?), we end that specific conversation.
In the Behavior tab, right click on the ServiceBehavior, and choose “Add Extension”. Add the “sqlAdapterInboundTransactionBehavior” behavior. You can control the transaction isolation level (the default is ReadCommitted). It is this transaction isolation level which will be applied to the DTC transaction spanning the BizTalk Message Box and your SQL Server (from where you’re pulling messages from the SSB queue).
In the Other tab, choose None for credentials (if you want to use Integrated Security) – or specify a username + password.
Click OK as many times as required to close the Receive Port configuration dialogs.
Create a new static 1-way send port named “FileSendPort”. Configure the transport type as FILE, and configure the port to drop messages to a valid folder on your file system. Select PassThruTransmit as the Send pipeline. Also, click on “Filters” in the left pane. Add a filter condition:
1. Property = BTS.ReceivePortName
2. Value = SqlReceivePort
Click OK to complete the configuration of the Send Port.

At this point, the configuration of the BizTalk application is complete. Start the application.

We’re now going to send messages to the SSB queue (I’m using SQL Server Management Studio – you could also use osql.exe). I used the following SQL block to send a message to the queue:

DECLARE @RequestMsg XML;
SELECT @RequestMsg = N'<TestMessage>Hello, World</TestMessage>';
DECLARE @DlgHandle UNIQUEIDENTIFIER;
BEGIN DIALOG @DlgHandle
FROM SERVICE
[//SqlAdapterSSBSample/InitiatorService]
TO SERVICE
N'//SqlAdapterSSBSample/TargetService'
ON CONTRACT
[//SqlAdapterSSBSample/SampleContract]
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @DlgHandle
MESSAGE TYPE
[//SqlAdapterSSBSample/RequestMessage]
(@RequestMsg);

Once you send the above message to the SSB queue, within a short while, you should see it in the folder specified in the FileSendPort. The message I see is:

<Polling xmlns="http://schemas.microsoft.com/Sql/2008/05/Polling/">
<PolledData>
    <DataSet xmlns="http://schemas.datacontract.org/2004/07/System.Data">
      <xs:schema id="NewDataSet" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
        <xs:element msdata:IsDataSet="true" name="NewDataSet">
          <xs:complexType>
            <xs:sequence>
              <xs:element minOccurs="0" maxOccurs="unbounded" name="NewTable">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element minOccurs="0" name="ReceivedMessage" type="xs:string"/>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
      </xs:schema>
      <diffgr:diffgram xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
        <NewDataSet xmlns="">
          <NewTable>
            <ReceivedMessage><![CDATA[<TestMessage>Hello, World</TestMessage>]]></ReceivedMessage>
          </NewTable>
        </NewDataSet>
      </diffgr:diffgram>
    </DataSet>
</PolledData>
</Polling>

As can be seen above, the adapter has returned the message in System.Data.DataSet format. You could ofcourse use an XPath query to extract only the body of the message. Here’s how -

Navigate back to the SqlReceivePort configuration. Bring up the WCF-Custom configuration dialog (the dialog which contained the General tab, the Binding tab, the Behavior tab, etc).
Navigate to the Messages Tab.
In the “Inbound BizTalk Message Body” section

Select “Path”. Enter this XPath query: /*[local-name()='Polling']/*[local-name()='PolledData']/*[local-name()='DataSet']/*[local-name()='diffgram']/*[local-name()='NewDataSet']/*[local-name()='NewTable']/*[local-name()='ReceivedMessage']
For the Node Encoding, select “String”.

The data in the file should now just be:

<TestMessage>Hello, World2</TestMessage>

Address should be unique for Receive Location – error when creating a Receive Location in BizTalk

mdoctor — Sat, 28 Jun 2008 09:40:18 GMT

Assume you’re using the WCF SQL Adapter (part of the BizTalk Adapter Pack 2.0). You decide to create 2 Receive Locations (RL), in order to poll the database. Each RL polls a different table (e.g., the “PollingStatement” binding property in the first RL is “SELECT * FROM T1”, while the “PollingStatement” binding property in the second RL is “SELECT * FROM T2”).

Since the tables are present in the same database on the same SQL Server instance, the URI which you enter is the same in both RLs (e.g., something like “mssql://servername/instancename/databasename”).

However, BizTalk doesn’t allow you to create multiple RLs in the same BizTalk application with the same URI. From the BizTalk point of view, it’s like having 2 RLs competing in the same BizTalk application for the same incoming messages. Even though in this (the WCF SQL Adapter) case, both RLs are pulling in messages from different sources (the “PollingStatement” controlling the message source).

There is a pretty simple workaround for this. You can use the following (different) URIs in each ReceiveLocation:

“mssql://servername/instancename/databasename?SomeUnusedQueryParameter=1”

“mssql://servername/instancename/databasename?SomeUnusedQueryParameter=2”

“mssql://servername/instancename/databasename?SomeUnusedQueryParameter=etc”

The new "WCF LOB Adapter SDK"-based SQL Adapter - Limitations

mdoctor — Sun, 23 Mar 2008 14:34:00 GMT

As mentioned in this post, we're developing a new SQL Adapter, which will be available in the next release of the BizTalk Adapter Pack. The list of features which we're supporting is mentioned in that blog post.

As for the features/items/etc which we've decided NOT TO SUPPORT, they are:

The ability to have multiple transactional blocks within the same XML message. All the operations within a message all take place within the same transaction; and this is actually a distributed transaction which spans these operations on your SQL Server, as well as the operations performed by BizTalk on the MessageBox database.

If the above point(s) are absolutely critical to your scenarios, please get in touch with us.

The new "WCF LOB Adapter SDK"-based SQL Adapter - Features

mdoctor — Mon, 04 Feb 2008 20:00:00 GMT

The current release of the Adapter Pack contains the SAP, Siebel and Oracle adapters (written using the WCF LOB Adapter SDK).

For the next release of the Adapter Pack, one of the adapters which we're adding is a SQL Adapter. Some of the features which we're addressing are:

SQL 2005 and SQL 2008 datatypes (XML, VARCHAR(MAX), VARBINARY(MAX), Date, Time, DateTime2, DateTimeOffset, Geometry, Geography, HierarchyId)
User Defined Types (UDTs - these can be defined in .NET assemblies)
Table Valued Parameters in Functions and Stored Procedures
Native 64 bit support (the adapter can run in a 64 bit BizTalk host)
Enterprise SSO (courtesy of the WCF adapter)
User-defined schemas (schemas other than dbo)
Specifying the transaction IsolationLevel to use during polling
An ExecuteReader() operation which can be used to execute arbitrary SQL statements at runtime
Executing any stored procedure - FOR XML is no longer required.
Supporting multiple resultsets in the response - either from stored procedure execution, or from arbitrary SQL statements, and for both - outbound as well as polling scenarios
Streamed operations for reading/writing from/to VARCHAR(MAX) and VARBINARY(MAX) columns
Dynamic Ports (i.e., specifying the endpoint information within an orchestration)
Ability to perform multiple operations (INSERT, UPDATE, DELETE, Execute Stored Procedure) in the same transaction.

Are there any other features which you would like to see in a new SQL Adapter? Please do let us know.

We're looking for TAP customers to try out and validate the features in the new adapter. An alpha release of the adapter (having all the above features) is also currently available, so if you're interested, please do let us know and join the TAP program.

Getting LOB metadata from SAP, OracleDB and Siebel adapter using svcutil

Jayanthi S — Tue, 23 Oct 2007 11:56:00 GMT

The WCF based adapters that ship in the Biztalk Adapter Pack are WCF bindings. The svcutil tool can be used to get metadata for a LOB method using these bindings. The scheme in the URI determines which adapter binding is loaded by svcutil. However when using the svcutil tool, there is no easy way to specify the LOB credentials that should be used to get metadata from the LOB. One way to specify the LOB credentials to our adapters is to set it in the URI. However, by default (for security reasons) the adapters do not accept credentials in the URI.

To get around this, you need to set the binding property acceptCredentialsInUri to true and then specify the LOB credentials in the URI. To be able to set binding properties or other custom settings when using svcutil.exe, you should use the svcutil.exe.config file. This article describes how to use it.

Attached is a sample svcutil.exe.config which has the endpoint and binding configurations for all the three adapter bindings. Place this in the same folder as svcutil.exe.

The following are sample command lines to use to get metadata from our adapters.

SvcUtil.exe "sap://user=youruser;passwd=yourpassword;Client=800;lang=EN@A/adapsap47/00?op=http://Microsoft.LobServices.Sap/2007/03/Rfc/RFC_GET_FUNCTION_INTERFACE"

SvcUtil.exe "oracledb://User=MYUSER;Password=MYPASSWORD@ADAPTER/?op=http://Microsoft.LobServices.OracleDB/2007/03/SCOTT/Table/AEMP/Insert"

SvcUtil.exe "siebel://Username=MYUSER;Password=MYPASSWORD@mssebldemo:2321?SiebelObjectManager=SSEObjMgr_enu&SiebelEnterpriseServer=ent771&Language=enu&op=http://Microsoft.LobServices.Siebel/2007/03/BusinessObjects/Account/Agreement/Query"

Note the quotation mark around the URI. In the configuration for Siebel (in the attached config file) also note the idleConnectionTimeout without which it will take the default 1 minute for svcutil to terminate. Look for more details on the idleConnectionTimeout in a separate post on Siebel.

Note also that if you use the Add Adapter Service Reference tool (that gets installed with the WCF LOB Adapter SDK) to get metadata for a LOB method for use in a C# or VB project, the AcceptCredentialsInUri binding property will not be visible or settable. You can set the LOB credentials using the credentials tab in the tool.