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

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

In my previous post I briefly described what the workflow tool from Nintex looks like and how to use it within the SharePoint environment.  Now, let’s see how to actually perform our first system integration scenario through the use of web services.

One big caveat before I start: Nintex currently only has support for consuming ASP.NET Web Services, not Windows Communication Foundation.  I consider this a pretty big gap, but for now, let’s work with what’s available.

In this demonstrated scenario, I have a SharePoint 2007 list which holds all the vendors a company uses to provide IT services.  Because core vendor data is stored in a different CRM system, we want to store a minimum of information in the SharePoint list and retrieve critical data from the CRM system via a web service.  So, once I add a record to the SharePoint list, I want to look up the details for that vendor in the CRM system and put the vendor “contact name” into the SharePoint list.

I start out with a simple ASP.NET service which fronts the CRM system.  Because I’m writing a blog post and not a real system, I simply hard coded a response object.

In my SharePoint list, I added a new Nintex workflow and dragged a “Call web service” and “Set field value” activities to the flow.  On this first pass, I’m just going to dump the entire web service XML response value into a SharePoint list field.

Note that the web service response has to go somewhere, so I first set up a workflow variable (VendorDetails) to hold the XML data.  I’ll use the other variable later to hold a specific value from the XML response.

The “Call web service” activity has a pretty comprehensive set of configuration options.   First you specify the endpoint URL.  The available service operations are then auto-populated in a list.  For dictating the service payload, you have two choices.  First, for services with simple type parameters, you can enter in each value from either list values or workflow variables using the SOAP Builder.

The other option, which is handy, is the SOAP Editor where you can shape the SOAP content yourself.  Note that you can still insert values from either lists or workflow variables into this interface.

As for the service response, you can choose to apply an XSLT transform and then select a workflow variable to stash the value.   You also get the option to catch exceptions and store those messages.

After using the “Set field value” workflow activity to take the service result and copy it into the SharePoint list field, we’re ready to publish the workflow.  I added a new row to the list and kicked off the workflow.

As we’d hope for, the full XML payload from the service is thrown into the SharePoint list field.

Note that XML payloads are wrapped in an “<xml>” node by the workflow activity.  It’s great that we can call a service, but just dumping the XML result is not particularly friendly to someone who is viewing this information.  What we want to do is parse the XML response and yank out JUST the “VendorContact” node.  So, I went back to our existing workflow and added a new “Query XML” activity to the process.  This activity lets me parse XML content stored either in a URL, workflow variable or list field.

You can process the XML via either XSLT or XPath.  In my case, I want to do an XPath query to find the node I’m looking for.  I then took the result of that query and stored it in a workflow variable.

Finally, I have a “Set field value” activity which takes this new workflow variable and copies its data to the SharePoint list.  After once again publishing the workflow and kicking it off, we can see that not only do we have the XML blob, but now we have another field that just stores the name of the vendor contact person.

Summary

The ability to punch out to external systems is a valuable aspect of a full featured business process.  The Nintex workflow product does a fine job making service invocation a fairly straightforward task.  Now, the lack of WCF integration is a concern, but hopefully one being actively addressed.  However, because the “Query XML” activity can accept a URL, it seems possible that I could mash up RESTful services via this toolset.  I’ll have to try that.

The final post in this series will cover the native BizTalk Server integration in the product.  Stay tuned.

Technorati Tags: SharePoint