Nintex Workflow – Dictionary/Hashtable
The out of the box variable types in Nintex Workflow are great, and they are perfect in almost all situations. But there are times I’ve had a need for something more. This is an example of a situatoin where I felt I needed something like a Dictionary or Hashtable.
I was planning on querying SharePoint to get the internal ID (guid) and the url of subsites in a Site Collection. As my workflow became more complex, with a number of loops, I didn’t want to keep requerying SharePoint for the same data. Instead, to minimize the number of web service calls, I decided to build a Dictionary type variable.
Put simply, a dictionary object allows you to map one value to another.
eg.
Id1 -> Url1
Id2 -> Url2
etc
Unfortunately, there’s no Dictionary variable type. So I found a way to make one using a Text variable and XML.
Build Dictionary
The aim is to create a structure like this:
<dictionary>
<node name=”” value=”” />
<node name=”” value=”” />
</dictionary>
The reason why this is a good structure in Nintex Workflow, is because to add a node, you can simple use an Update XML action, configure to add a node.
To read a value, based on the name, you can use a Query XML action.
Firstly, we create a variable (let’s call it textDictionary). Then we initialize with simple xml ( <dictionary/> ) using a Build String action.
Next, we want add a few nodes. We are going to add, mapping an ID (number) to a Color (text).
1 – Red
2 – Green
<dictionary
<color id=”1″ value=”Red” />
<color id=”1″ value=”Green” />
</dictionary>
To add these nodes, we use two Update XML actions.
Accessing the Dictionary
As your workflow progresses, there will be times where you receive an ID, and you need to get the matching color of that ID.
In this example, we just want to get the color whose ID is 2. To get this, you run a Query XML action, and you use a XPath expression.
The XPath expression for this would look like this:
//dictionary/color[@id=2]/@value
This should return the “value” attribute for the node who “id” attribute = 2.
Conclusion
Although with this simple example, it doesn’t look like an overly useful data structure. But let’s take a more complex example.
We need to build a report which contains a bunch of links. The links contain subsite urls, but all you have is a collection of site ids which can contain duplicates. So in order to translate the ID to a Url, you need to make a web service call to SharePoint. As you process this list of IDs, for each one you have to get the Url.
What if you have a collection of 1000 IDs and they are all the same? You will end up making 1000 web service calls.
If you have 10 subsites, you could make around 10 web service calls instead of 1000. I would much rather make 10 web service calls and 1000 Query XML calls, then 1000 web service calls and a 1000 Query XML calls.
This is where the Dictionary data structure is perfect.
Downloads