Nintex Live: What It Is, Why It Was Created, and How It Works

We have a new product on the way called Nintex Live.  I did a few webcasts about it for Nintex partners a few weeks ago, and I demoed it at the Nintex booth at the SharePoint Technical Conference in San Francisco two weeks ago.  We’re planning to put it into beta late next month, and release it well before the middle of 2011.

If you look at what we have on our website you can see some preliminary content that’s been crafted.  It’s fine.  But I thought I’d talk about it a bit more conversationally…

What is Nintex Live?

“Cloud-hosted ‘air support’ for SharePoint workflows” is my current shorthand way to describe it, although that’s not perfectly on-message.  You can choose any or all of the following as well:

• – A cloud service hosted in Windows Azure that provides value-added services to Nintex workflows running in SharePoint.
• – A way to add new activities/actions to one’s workflow toolbox without installing any extra code on SharePoint servers.
• – A way to make virtually any web service “out there” look and behave like a workflow action.
• – A way to present a catalog of available actions to workflow designers – all of which have been sanctioned by IT.
• – A way to run a workflow that has been created/published in a remote SharePoint farm.
• – A way to publish a SharePoint workflow and allow it to be remotely invoked by a different workflow running in a remote SharePoint farm.
• – A way to make use of many of those data and calculation services published to Windows Azure Marketplace from inside SharePoint workflows.
• – A way to do all of the above very quickly, and very, very easily.

How You’d Use Nintex Live

Here’s how you’d use it from within Nintex Workflow 2010:

From inside of the normal workflow design environment, you’d click the ribbon bar button marked “Catalog”.  In the image below, it’s the button near the upper-right, next to the “Help” button.

If you click that, you get access to a catalog of workflow actions you can add to the design toolbox on the left side of the screen.  The catalog, at the moment, looks like this:

Choose the actions you want, click “OK” and they’ll show up in your toolbox a few moments after that.  Use them in your workflows like you would a local action.  When the workflows run, they’ll call out to the cloud to get the data – and/or perform the instructions – that you’ve requested.

There will be a method for IT to pre-filter which actions show up in the catalog for governance purposes.

What Nintex Live Does Behind the Scenes

If using Nintex Live seems easy, then we did our job.  What’s going on behind the scenes is actually pretty involved, but virtually none of it happens inside SharePoint itself.  We go to a great deal of trouble to avoid adding extra code to any SharePoint environment, and this is no exception to that rule.    We’re communicating with a service we have running in Windows Azure, in several ways, actually:

• – We query its catalog of available services – filtered in accordance with IT-supplied instructions – to present to workflow designers a list of available cloud-brokered workflow actions.
• – We even provide UI instructions to the SharePoint-located Nintex Workflow designer so it can construct the design-time UI out of metadata.  No code is sent to the SharePoint environment at all.
• – We listen to requests made by the SharePoint workflow over Windows Communication Foundation, and respond the same way.
• – We transform the request into the format required by each individual web services or remote workflow, invoke it accordingly, transform the results into a format consistent with a workflow activity’s results, and pass it back to the original calling workflow.  We handle all retry, warning, and error logic in a service-specific way.  If we have to poll for results, we do that.  If we need to wait for and handle a raised event, we do that instead, etc.

What Kind of Cloud Services Are Available?

We’ve already created wrappers for several cloud-hosted services, and we’ll be creating more on an ongoing basis.  Some are SOAP-based, some are Restful, others are, well, any of a number of things. 

So far, in anticipation of next month’s beta, we’ve exposed things like:

• – Services from Bing that check news stories, look up flight statuses, translate text, etc.
• – Services from StrikeIron that handle IP address lookups, check “Do Not Call” registries, etc.
• – Services from social media like Twitter and Facebook for posting status updates, searching for content, etc.
• – Services we created ourselves for reaching out to remote SharePoint sites to get/put content from/into lists and libraries.

It’s Not Just About Connecting/Consuming – It’s Also About Contributing

We have no intention of being the only people who can register services with Nintex Live for easy use within SharePoint workflows.  We’re publishing the API for creating service wrappers for custom Web services, for one thing, but that’s not the fun part.

The fun part is that you’ll be able to publish a Nintex Workflow to Nintex Live, at which point it will be available as a remote workflow (with inputs and outputs) that can be executed by other workflows in other locations.  Effectively, you can turn any workflow into a cloud-brokered service.

And any service publisher can decide who can/cannot use their services.  They can also see who’s using their services and how much.

Why Did We Use Windows Azure?

That part’s actually easy.  Everything else would have been painful.  Queuing?  It’s in there.  Scaling?  We can scale up via multiple threads and/or multiple instances if need be.  We don’t want to operate our own data centers.  We don’t even really want to maintain the OS and the application platform on hosted machines.  Windows Azure let us just write the app, deploy it, and use it. 

What’s more, Nintex Live isn’t a product – it’s an investment.  We’ll build forward from this to do a lot more than act as an action server to SharePoint workflows.  But first thing’s first.  More to follow as it’s ready…