In this half day workshop I´ll pick up real life scenarios and explain how easy and quick you can create, deploy and maintain your SharePoint workflows using Nintex Workflow 2010. You´ll also see how you can enhance your workflow experience with a set of features that are not available when Nintex Workflow is not at hand.

The workshop will take place on Tuesdays, 30^th November 2010. Hope to see you there!

Do not miss this great video he did to promote the product!

You can download the video here
http://nintexdownload.com/video/NW2010Whiteboard.wmv

With former edition of Nintex Workflow it was absolutely impossible to get control of any workflow data within a running external WF instance. You could help yourself out with list columns to store the data and then later look it up manually. Fortunately this has changed now! There´s two new actions we need to take a closer look at: Store Data & Retrieve Data!

With these activities it is possible to look into a running workflow instance and collect data from other workflows. You need to know that you cannot read “classic” workflow variable values, you have to store the value in special property bag with the help of the new Store Data action.

Workflow instance to store to

This parameter defines the workflow instance ID of the workflow where you want to store the data. This can be any instance ID on the same SharePoint Site. You can catch the instance ID when you start another workflow (Action or Webservice).

Store as

This parameter defines the name of the data you want to store within the WF. Imagine this as a hashtable or dictionary like approach where you can add values.

Variable to store

Here you have to pass the variable that holds the data you want to store!

The parent workflow

In this scenario I`m using the Flexible Task Action to let the user decide which child workflow he wants to start (Calculation A, B or C).

The child WF then calculates some values and stores it right in the instance as variable value. From my parent WF I need to look into the child WF – that means I need the instance ID of that child WF. You can easily get that ID in using the Start Workflow action, it returns the ID as a parameter.

The last thing we need to do is to look up the calculated value from the child workflow. This is where we need the Retrieve Data action. Just pass in the workflow ID of the child WF instance and the right key to retrieve and store the value in a variable!

You can then use the “externalValue” variable wherever you need it inside the process!

The child workflow

A child workflow is doing some “complex” calculation and stores the result in an instance variable. Keep in mind that this workflow is started from another (parent) workflow! It could look like this:

I´ll pass a string to the WF instance variable. To keep it simple, I´ll just write “value from calculation WF is…” and store the final string in a new variable called “result”.

The configuration of the Store Data Action is pretty straight forward then. I´ll keep the data inside the current instance and will look it up from my parent “main” workflow! See “The parent workflow”.

That´s it. I´ll write the data to the History Log of my parent workflow. Let´s see if it works as expected J

Yesterday Nintex released the latest version of its workflow product Nintex Workflow 2010! As you know, I´m sort of a Nintex guy and therefore the latest release needs to be mentioned on my blog. There´s lots of new things to discover, I´ll try to keep you up2date and share some experience regularly.

For further information, visit the official Nintex website.

Before you start, you need to configure the Word Automation Services. This is easy using the Central Administration configuration wizard.

Once the services are set up, we can start building the workflow. Let’s create a small workflow that requires a document approval whereas the approver can decide if he wants to convert the document to PDF or XPS format.

I use the Flexible Task activity to create the desired outcomes “Approve to PDF” and “Approve to XPS”.

In the “Libraries and Lists” category you can find a new action called “Convert document“.

Drag in onto the designer and open the configuration dialog. I want the converted documents to be saved in my “PDFs” library. A configuration could look like this.

You have the following converter format options:

• Automatic
• Document (.docx)
• Document -97 (.doc)
• Document – macro enabled (.docm)
• MIME HTML (.mhtml)
• PDF (.pdf)
• Rich Text Format (.rtf)
• Template (.dotx)
• Template -97 (.dot)
• Template – Macro enabled (.dotm)
• XML (.xml)
• XPS (.xps)

The rest works like a charm! Let the workflow run and see the result in the PDFs list J

You have a few options:

1. Use SharePoint’s own web service methods to get control of subsite items
2. Use the PowerActivity and handle subsite items via the SharePoint Object Model

I´ll give you a short introduction to both approaches. Let´s begin with option 1

SharePoint Webservices & Nintex Workflow

In this scenario I´m going to use a master list on a site collection to define meta data for the items I want to create on a list of a sub-site. We need some columns here:

• Sub-Site Listname
• Sub-Site New Item Title
• Add any other metadata field you want to use in your sub-site list

This really easy workflow consists of two actions:

Step 1:

First we need to create the XML to feed the SOAP request in the webservice call. You should use the “build dynamic string” action here. I´m using a reference to the “new item title” field here. To create a new item your XML should look similar to this:

Step 2:

Next we have to configure the webservice call. Let´s assume we want to create a new item, that means we have to use the UpdateListItems method of the lists web service. Keep in mind to use the sub-site url when defining the service url, in my case this is the url:

http://localhost/subsite/_vti_bin/lists.asmx

SubSiteListname is a reference to the fieldvalue in my masterlist and xml is the variable filled in the build dynamic string action (step 1).

Run the WF on any item…

That´s it. In another post I will do the same thing using the PowerActivity!

Markus

This time I`m going to use Nintex Workflow to create a shared network folder and set the folders security on the fly within the workflow. Imagine you have a workflow which has to create a user specific folder on a share. Further, the security settings of the new folder should be inherited from the parent folder plus the specific user needs to have full rights on his newly created folder. You would definitely have a hard time to get this done using Nintex´s default functionality. With the ability to wrap .Net functionality with PowerShell, we can use the .Net framework to handle our security requirements.

$sharepath = "\\server\share";
$folderName = "userfolder";
$path = $sharepath + "\" + $folderName
$exists = [System.IO.Directory]::Exists($path)
if(!$exists)
{
$dir = [System.IO.Directory]::CreateDirectory($path)
$security = $dir.GetAccessControl()
$filesystemright = [System.Security.AccessControl.FileSystemRights]::FullControl
$inheritflags = [System.Security.AccessControl.InheritanceFlags]::ContainerInherit -band [System.Security.AccessControl.InheritanceFlags]::ObjectInherit
$propagationflags = [System.Security.AccessControl.PropagationFlags]::None $controlType = [System.Security.AccessControl.AccessControlType]::Allow
$fsa = new-object -typename System.Security.AccessControl.FileSystemAccessRule("domain\username";, $filesystemright, $inheritflags, $propagationflags, $controlType)
$security.SetAccessRule($fsa)
$dir.SetAccessControl($security)
}

We can use the PowerActivity to determine if the folder already exists as well! The final workflow may look like this to get this done:

You see the combination of Nintex, PowerShell and .Net Code can be very powerfull. In these two posting I did the following things and they work like a charme:

• Update properties on Active Directory accounts
• Checked for existence of network folders
• Created network folders
• Set permissions on network folders

Greetz,

Markus

So this is where PowerShell and the Power Activity for Nintex Workflow kick in! You could script down a complex algorithm to determine the correct “AccountExpirationDate” value – that looks sort of tricky, so I decided to go the easy way: the .Net way PowerShell can basically do anything that you could do with a .Net application.

A lightweight version of the workflow looks like this:

As I mentioned before, I decided to use .Net objects to get this done. To do operations against an Active Directory we need to load in the “System.DirectoryServices.AccountManagement.dll” assembly.

The script came out like this. $var1 is mapped to a username field and $var2 is mapped to a date field of the corresponding SharePoint list.

$path = $env:ProgramFiles + "\Reference Assemblies\Microsoft\Framework\v3.5\System.DirectoryServices.AccountManagement.dll"
[System.Reflection.Assembly]::LoadFile($path)
$ctxType = [System.DirectoryServices.AccountManagement.ContextType]::Domain
$ctx = new-object -typename System.DirectoryServices.AccountManagement.PrincipalContext($ctxType)
$identity = $var1
$user = [System.DirectoryServices.AccountManagement.UserPrincipal]::FindByIdentity($ctx, $identity) $user.AccountExpirationDate = $var2
$user.Save()

This went really quick! Another cool way to use the Power Activity


• Intro
• Part I (connecting external system, webservices with Nintex Workflow)

In this part I´ll create a list structure within SharePoint. Let´s recapture what I´m trying to do. When this is done I want to have a sort of a, let´s call it “marketing machine” which will find Twitter users that are “tweeting” about specific keywords. To find the right users we need something like a search list where we will store the hashtags (=keywords) we are looking for. I´ll create a list called “Twitter Search” and add some fields to manage the search behavior of the workflows.

Of course there´s a field “Hashtag”, additionally I added a field “Active” of type Boolean. I will use this field as a switch to tell a WF to ignore the hashtag on the next run. Remember that workflows will run scheduled and will never be started manually. To catch the users we find on Twitter I use another list, let´s name it “Following”.

This “Following” list serves as a target list for the search WF hosted in the “Twitter Search” list. The “Search WF” will create items here. There´s also a Boolean field “Following”, I´m using this as an indicator when the username has been added successfully to my Twitter followers. On this list there will be a WF to actually ADD users to my timeline, whereas the WF on the other list will only look them up. I want to split that process because otherwise it would not be possible to use different schedulings for search and add functionalities.

Last but not least I add another list called “Scheduling List”. This list will act as a controlling list, I´m going to define when and how often I want to run the Twitter search here.

You see I have 3 items in this list, each one is packed with a WF schedule. At this point you have to know that any WF schedule is bound to a single SharePoint item. I´m using the “Search Hashtags” item to schedule the search. If you want to look up for Twitter users once per hour, a schedule could look like this. You find the scheduling option in the context menu of the SharePoint item.

The scheduling for the other two listitems looks similar, the only difference is that I´m adding users every five hours. In the next part of this series, I´m going to describe the workflows in detail.

Cheers.

Markus

To get this done, we need to take a closer look at how to use Nintex Workflow to place web requests and how Twitters own search engine is working.

The Twitter Part

Let´s begin with Twitter search. There´s a special search page on Twitter, go here!

If you place a search (i.e. for sharepoint), the url changes to

…and we can see the HTML result for that search

What we need is sort of an XML result, that´s much easier to analyze than plain HTML. Take a look at the right part of the page, I marked “Feed for this query”. If you click on that, you notice a new url:

“search.atom” means we get an XML result, so we hook here and try to make a request to this url with Nintex! Also keep in mind the URL parameters.

The Nintex Part

We use the “Web Request” action to take a first shot. Drag it onto the Workflow Designer and open its configuration dialog.

There´s only a few mandatory fields we need to configure here:

• URL
• Username and password (use a WF constant here)
• Create a WF variable to catch the web result

In the lower part of the action, you will find the “Store result in” option. Here we use a WF variable (of type “Text”) to save the result string from the response.

At this point I publish the WF and let it run manually. In a later post I will describe in detail how we have to design the workflow entirely. If we take a look at the value of our result parameter, we recognize the schema of the xml result.

<feed>
  <entry>
   <author>
      <name>markusalt (Markus Alt) </name>
      <uri>http://twitter.com/markusalt </uri>
    </author>
  </entry>
</feed>

As you can see, the schema is pretty easy. What we need to do next is to extract the username, either from the <name> or the <uri> node. We will need the username later to add a user to the “following” list. Nintex Workflow comes with an action called “Query XML” which fits our purpose.

The beauty here is that you can use XPATH to extract data you need from the xml source. Since we understood the xml schema, we can build a tiny XPATH query to get to the data. A fitting XPATH epxression to the <name> node would be: //feed/entry/author/name

The configuration dialog would look like this

You see I use a new WF variable (of type “Collection”) to store the result. We need to use a collection variable since we will most likely get more than one username from the query. So, at this moment the first WF looks like this

There´s not that much happening so far. We build the query string based on a certain hashtag, post a search request to Twitter and try to get a collection of corresponding usernames into a variable. With the last action I simply “log” the value to the WF history as a comment. If we run the WF there will be no value in the variable (no usernames inside the variable).

Surprised? Not really, because there is a default namespace living inside the XML – Xpath does not like that. We have to use a trick to get rid of that default namespace. If you want to find and replace such values within a Nintex Workflow, you have to use the “Regular Expression” action. In our case, we need to erase xmlns=http://www.w3.org/2005/Atom . Use the following configuration to do that:

With this action, we simply override our “result” variable with the same XML data as before, but without the default namespace! Finally WF looks like this

If we start the WF one more time, we can see that the usernames are listed now within the workflow comments (cut off, because of a 255 character limitation of the comment field) J

You see it´s a little tricky to get to webservice data at hand with Nintex, but if you know how to handle XML with the right WF Action it works like a charme! In the following parts, I will describe how we can create a generic SharePoint structure to handle multiple hashtags and how to use WF scheduling to automatically do searches and add users to the “following” list.

Markus