Nintex Workflow – Workflow Re-use without Templates and Snippets – Part 2
From our previous article – Nintex Workflow – Workflow Re-use without Templates and Snippets – Part 1, we have a SharePoint List that has a text field with semi-colon delimited colors, a multi-value lookup field to a colors SharePoint List, and we have also create another list called “Reusable Workflow List”.
The Key to a Reusable Workflow
Start Data.
Each workflow you design can have Start Data.
When you start your workflow manually, you can input the values to these Start Data fields, and the workflow will treat them as Workflow Variables. The advantage here, is if another workflow uses the Nintex Workflow Web Service (StartWorkflow or StartWorkflowOnListItem web method), it can put in the values for these Start Data fields via the “associationData” parameter.
How do we use the Start Data variables?
We design our workflow so that it takes all the input data it needs, to be able to perform is logic.
In the case of converting the semi-colon delimited string to a lookup text string, we need the following information :
1. The Lookup List name – the list where we will find the text values
2. The Lookup Field name – the field in the lookup list to look at
3. The Semi-colon delimited text string – our input text string
4. The Destination List we want to update
5. The Destination Item ID of the item we want to update
6. The Destination Field Name in the Item we want to update
If we are provided with the information above, then our workflow will be able to perform a query on the lookup list to get the ID’s of the items it needs to build up the the Lookup field text string. It will also know which item it needs to update once we have built up this string.
When I create my Start Data variables, I will usually use a naming convention that will help me in my workflow design.
In this case, I use “sd” to let me know I am dealing with a Start Data variable, and the next part lets me know whether it’s a Text, Number or Collection variable, and then I have the name that describes what I will be using it for.
I’ll reiterate, that I won’t go into the complete logic of this workflow, but I will go through the specific actions where I use the Start Data.
Actions that use the Start Data
The first action is the Call Web Service action, where we are calling the SharePoint Lists web service, and specifically the GetList web method, to get information about it. We will then extract the ID out of the response from the web service as we will need it later.
Our next action of interest, is the Query List action that is inside our For Each loop. We are looping through each value in the original semi-colon delimited text string, and we need to query the given lookup list, to find that values Item ID.
In normal workflow design, you would configure the Query List action, by selecting the list from a drop down, and then selecting the field you want to get back, based on some filter information.
But in a reusable workflow, you don’t have this luxury. You have no idea what list you will be looking up, and also what the field name is. But given that this information is passed to us as Start Data, we can build our CAML Query around that data.
The Query List needs a List ID (not a List Name). Hence the reason for the previous web service call to get that ID. In the “FieldRef Name=”, rather than typing in a name, or selecting it from a drop down, we pass in the Start Data field name that we have been given, by clicking on the Insert Reference button and selecting the sdTextLookupFieldName variable. Then for the “Value Type” XML node, we insert the value of the text that we are up to in our For Each loop.
The advantage of configuring the Query List action this way, is that at design time, you have no idea what Lookup List you will be querying. Designing your workflow in such a way, allows any workflow to call this workflow, and give it instructions as to what list to query.
The For Each action will loop through, getting the information it needs, and building up the appropriate formatted text string that will be used to update a Lookup field.
The last action in your workflow is a Call Web Service action.
Here we want to update the lookup field in the destination list, and destination Item ID that we have been given through the Start Data.
Again, we are using the SharePoint Lists web service and calling the UpdateListItems web method. We are using the Start Data destination List Name that we will be given. We also need to pass in the updates (xml) field. This can be found on MSDN here : Lists.UpdateListItems Method (Lists)
We build up the updates xml, using the information we have been given through Start Data, and also information we have obtained throughout our workflow.
In our situation, the “{WorkflowVariable:sdNumDestinationItemToUpdate}” is the Start Variable that we have been given which tells us what the Item ID is, of the item we want to update.
“{WorkflowVariable:sdTextDestinationFieldNameToUpdate}” is Start Data we are given, that tells us what Field we need to update.
“{WorkflowVariable:textResult}” is the text variable we have build up throughout our workflow to the appropriate format that is required when you want to update a Lookup field.
Conclusion
We now have a workflow, that can be called by any other workflow, and given the required information, we can update query any lookup list, build up a lookup value text string, and update the list given. None of which we know during the design time of this reusable workflow.
In the final article, I will go through how we call such a workflow to do this work for us.
