System Integration with Nintex Workflow for SharePoint 2007 (Part III)

[Series Overview: Part I /  Part II / Part III]

In my first post of this series I looked at what Nintex workflow for SharePoint is.  The second post looked at its web service integration capabilities.  In this final post, we dig into the native BizTalk integration provided by the product.

Let’s start out with the use case scenario.  Let’s say that I’ve got a new consultant on board and want to publish this employee’s information to the ESB and get back employee identifiers provisioned by downstream system.  So our SharePoint 2007 custom data list stores attributes that we’ll capture up front (e.g. vendor name, consultant name, start date) and has placeholders for values (e.g. employee ID, seating location, corporate laptop name) defined by our various onboarding applications.

What we want is a workflow that can fire off once a new consultant is loaded into the SharePoint list.  This workflow shouldn’t be required to coordinate the various user provisioning systems, but rather, should communicate with our ESB (BizTalk Server 2006 R2) through a single interface.   In the previous post I showed how web services could be executed by a Nintex workflow.  While that is nice, I want a set of asynchronous interfaces where we can send a message to BizTalk and get something back whenever the user provisioning process is completed.

My workflow starts out with the “Send/Receive BizTalk” activity that sends a message to BizTalk and is followed by a “Set Field Value” activity which flips the record’s status from “Pending” to “In Progress.”

So what does this BizTalk activity look like?  First, we designate whether this is a “Send”, “Receive” or “Send/Receive” action.  The “Send/Receive” is used for synchronous transactions while the other two are the choices for asynchronous transmission.  Next we specify a “Message ID” which acts as the unique identifier for the message (e.g. correlation).   By default, this activity uses a GUID alongside the ID of the list row, but I changed mine to just be the organization ID (which I realize is not going to be unique to each transaction.  Sue me.).  Note that you can inject any value from the list or workflow variable into this “Message ID” identifier field.

The next section of the configuration pane is the “BizTalk Web Service Endpoint Settings” which we don’t have yet.  That will come later, and is blank for now.  Following that section is the place where we define the data we wish to send to BizTalk.  There are two choices: (a) send the file being acted upon (in the case that this workflow runs from a document library), or (b) choose list properties that contain the relevant message payload information.

Notice the “Export to XSD” link.  This link causes your previous list property selections to be loaded into an XSD file for BizTalk to consume.  So, this becomes your inbound message contract.  What about the response contract?   We configure this by adding another “Send/Receive BizTalk” activity to our workflow.  Because our provisioning action may take awhile, I used an asynchronous publication to BizTalk and now need a way to get the response back in.  The data received back from BizTalk must be stored in workflow variables (as opposed to taking the whole response document and putting it somewhere).  My workflow variables look like this:

Now let’s configure the response.  This time, my “Action” is set to “Receive” from BizTalk and I used the same “MessageID” as the “Send” activity.

This shape also has its “BizTalk Web Service Endpoint Settings” left blank, but unlike the previous activity where we’ll fill this in later, this activity’s value always remains blank.  This is because the Nintex folks provide a single HTTP channel back into their workflow engine from BizTalk.

Finally, we choose which available workflow variables we wish to populate with response data from BizTalk Server.

Just like before, we can export this information out to an XSD.  I’ve gone ahead and exported both the request message (from list values) and response message (put back into workflow variables) and added them to a new BizTalk project in Visual Studio.NET.

Both the request and response message have a header added which includes routing information needed by Nintex to correlation inbound and outbound messages.  In my sample orchestration which coordinates employee provisioning activities, I receive a message in via a one-way port, call a few operations to generate an employee ID, set the office location and establish the laptop machine name, and finally send the message back out via a one-way port.

After building and deploying this orchestration, I need to define the means by which Nintex sends a message into BizTalk.  As I mentioned in the previous post, Nintex does not currently support WCF, so you have to use the BizTalk Web Services Publishing Wizard to produce an ASMX service endpoint.  Once the wizard is complete, you have a valid service endpoint and a receive location that can be bound to the orchestration’s receive port.    What we need to manually create is the send port which sends our response message back to the running workflow.  The HTTP endpoint set up by Nintex is found at:

http://<sharepoint server>/_layouts/nintexworkflow/BizTalkHandler.ashx

Once that send port is bound to our orchestration, we’re ready to roll.  Now we can return to our SharePoint workflow and update the existing “Send to BizTalk” activity with the valid service connection details.

Finally, I included a bunch of “Set field value” activities in the workflow which take the values from the workflow variables (set by the BizTalk response) and put them into the list values for the item.

All that’s left to do is publish, and then trigger the workflow on our existing list item.  Sure enough, after launching the workflow, my item has its status set to “In Progress” and a couple of browser refreshes later, it displays the values returned by my BizTalk orchestration.

Summary

All in all, this was pretty easy to do.  It’s convenient that I can send either list data or entire documents into BizTalk, and it helps greatly that the tool produces valid XSD files (except there seems to be a bug where datetime fields in SharePoint lists don’t properly map to their XSD counterparts).  I’d choose the BizTalk integration vs. traditional web service integration when I want asynchronous interactions with my service or ESB.

It’s a good toolset overall.  Definitely take a look.

Technorati Tags: SharePoint, BizTalk