Using BizTalk WCF LOB Adapters within WF

BizTalk 2010 will include functionality which will allow .NET developers to more easily leverage the WCF LOB adapters as well as the BizTalk Mapper.  In this post I will focus on how to build a simple WCF Workflow Service which leverages the WCF LOB Adapter for SQL to query the database.

There may seem like there are a lot of steps, however, once you know what the steps are, this takes about 3-5 minutes to get up and running and requires very little code.  After you have walked through the process, try creating a new project and building it again without following the steps below.

You will need to create a database named ‘Test’ with a table named ‘Customers’.  The table should have three columns, ID, First, and Last.  Fill the table with some sample data and we are ready to start.

Here is an overview of what we are going to do.

1. Create a new WCF Workflow Service Application.
2. Generate a WCF LOB Adapter Service Reference which created our Activity.
3. Change the default data variable and added a new response variable.
4. Wire up the activities to use our variables.
5. Tested our application.

To get started, create a new WCF Workflow Service Application.

Once your project loads, you should see the Service1.xamlx workflow.

Next, lets add our adapter service reference.  Right click on the project and select the ‘Add Adapter Service Reference’ option.  This will open the WCF LOB Adapter dialog.

The Add Adapter Service Reference dialog give you access to all of the WCF LOB adapters installed on the Server.  This is the same dialog you will use to generate a .NET proxy class, a BizTalk Schema, or in this case, a WF Activity.

Once you have picked the sqlBinding, click the Configure button.  This will open the Configure Adapter Dialog.  This allows you to set the security and URI properties.

For security, we are going to select ‘Windows’ as our credential type.

 

Next we need to set the URI properties.  We need to set the InboundId, the InitialCatalog, and the Server.  The InboundId is used to differentiate one receive location from another and can be anything as long as it is unique.  The initial catalog is the name of your test database and the server name is simply the name of the server where your database lives.

After you click OK, you will need to click the ‘Connect’ button.  This will query the database and pull back meta data.  You browse through the meta data and select the operations you would like to include in your proxy.  In our case, we are going to leverage the select operation on our Customer table.

Before we click OK, we need to select an advance option.  We need to have the wizard generate message contracts.

The process may take a little while to generate the appropriate artifacts, so be patient.  When the process is complete you will see the following message.

You will see two new files within your solution.  A Adapter Binding class file and a xaml file.  The class file contains all the proxy classes, the xaml file contains the activity.

To see the activity in the toolbox, you will need to rebuild the project.  Once rebuilt, the SelectActivity should appear.

Drag the activity onto the WorkflowService and drop it in-between the ReceiveRequest shape and the SendResponse shape.

At this point, we have generated everything we need.  We need to modify a variable, create a new variable, and then wire everything up.  Almost done.

If we take a look at the default variables, we have a handle variable for correlation and a data variable.

First we need to change the data variable.  We want to rename the variable to ‘Query’ and change the type to String.  This will cause some errors to appear on our workflow which is expected.

To fix the ReceiveRequest error, we need to click on the ‘view message…’ text within the ReceiveRequest activity.  This will open the content definition dialog.  We need to change the message data expression from pointing at the data variable to the ‘Query’ variable and change the message type from int32 to string.

This will correct the problem with the ReceiveRequest activity.  Now lets edit the properties on our SelectActivity to leverage our ‘Query’ variable so we can pass the Query we receive from the ReceiveRequest activity to the SelectActivity.

To do this, simply view the properties on the SelectActivity and change the Query property to be Query which is our variable.

Also, set the columns property to “*”.  This will tell the adapter to retrieve all the columns in our table.

Time to create the variable which will contain our results from the SelectActivity and be the response message back to the client.  Create a new variable called QueryResult.  Set the Type as Array of [T]. This will open another select types dialog, pick browse for types as your option.

This will open a list of available types, we want to pick the Customers Type.  This will set the QueryResult variable as an array of customers.

When done, here is what our variables should look like.

Go back to the properties on the SelectActivity.  We need to set the SelectResult property to our QueryResult variable.  This will take the response we get from the WCF LOB adapter and pass it into our QueryResult variable.

Last step.  We need to change the SendResponse activity to use our QueryResult variable.  To do this you need to click the ‘View message…’ text within the SendResponse activity.  This will open the Content Definition dialog.

We want to set the message data to QueryResult and the Message type to an array of customers.

You should be done and your screen should look like the following.

If you start the project in debug mode your service will start.  When you browse to the service you should see the following.

I typically like to use WCFStorm to test my services.  Once you have opened the service in your test tool of choice, you should see a GetCustomers operation which takes a string as the input. 

We want to enter our where clause as our string.

After you invoke the service, your response will contain the matching records.

Again, lots of steps, but in reality this takes only a few minutes to setup and get working once you know where everything is.

A quick recap.

1. We created a new WCF Workflow Service Application.
2. We generated a WCF LOB Adapter Service Reference which created our Activity.
3. We changed the default data variable and added a new response variable.
4. We wired up the activities to use our variables.
5. we tested our application.

In my next post I will show how to package the service and deploy it to AppFabric and show you some of the manageability features provided by AppFabric.

‹ BizTalk Server 2010 Public Beta now available!

Deploying a WCF Service to AppFabric ›

Posted in BizTalk, WCF, WF