Custom Workflow Activity for Getting Managed Metadata Field Values

I’ll start with a quick run through of the arguments and variables I’ve used in the activity. First the arguments:

The activity will get the value of a managed metadata field from the current list item, so we only need the caller to provide one argument value – the name of the field (mmsFieldName). We want to return two values to the caller: the term GUID (termGuidOut) and the term label integer (labelOut).Now the variables:

We’ll use listItemFields to store a JSON representation of the list item. The DynamicValue type is perfect for storing and manipulating JSON data. We’ll use fieldPathTermGuid and fieldPathLabel to build the XPath expressions we need in order to isolate and extract the term GUID and the term label from the list item JSON.

Activity Design

1. Get the current list item.
2. Build an XPath expression to find the TermGuid property of the specified managed metadata field value.
3. Build an XPath expression to find the Label property of the specified managed metadata field value.
4. Add a try-catch block so we can catch any errors when we parse the list item.
5. Within the try block, use the XPath expression we created earlier to get the TermGuid property from the managed metadata field value.
6. Within the try block, use the XPath expression we created earlier to get the Label property from the managed metadata field value.
7. Within the catch block, catch invalid operation exceptions and log the details to the workflow history list. (Invalid operation exceptions occur if the specified field does not exist or is not a managed metadata field.)

Let’s walk through each of these in turn.

Step 1 – Get the current list item

I’ve used a LookupSPListItem activity to do this. The activity returns the JSON representation of the list item as a DynamicValue instance, which I’ve assigned to the listItemFieldsvariable.

Step 2 – Build an XPath expression to find the TermGuid property

I’ve highlighted the bits we’re interested in. In this case, we can figure out that the XPath expression to get to the TermGuid property is as follows:

Note that the results property actually contains an array of one result, so we use results(0)to get the first object in the array.We can use an Assign activity to create our XPath expression and assign it to the fieldPathTermGuid variable. If we replace Customer (the MMS field name in this example) with a placeholder for our mmsFieldName variable, the activity looks like this:

Remember that we’re not using the XPath expression at this stage – we’re just building an XPath expression from the workflow variables to use in a later task. Step 3 – Build an XPath expression to find the Label property

Step 4 – Add a try-catch block

When we come to actually parse the list item, there’s quite a lot that could go wrong. If the list item doesn’t contain the specified field name, or the specified field is not a managed metadata field, the XPath expressions will fail and the workflow will throw an InvalidOperationException. As such, we want to build the parsing logic within a TryCatch activity:

Here you can see that we attempt to get the salient managed metadata field properties within a Try block, and we look for an InvalidOperationException in the Catch block. We’ll look more closely at the activities within the Try and Catch blocks in the next step. For now, notice that the activities within the Try and Catch blocks are wrapped in Sequence activities. In a production scenario you will probably want to implement a more comprehensive error handling strategy, but for this proof-of-concept scenario I’m mainly interested in catching the common invalid operation exceptions.Steps 5 and 6 – Get the TermGuid and Label property valuesWithin our Try block, we can use generic GetDynamicValueProperty<T> activities to get the TermGuid and Label property values:

In each case:

• The Source property is the JSON representation of our list item.
• The PropertyName property is the XPath expression that finds our TermGuid or Label property.
• The Result property is the output argument that exposes each property to SharePoint Designer workflows.

The Actions File

The next stage is to build the actions (.actions4) file for the workflow activity. The actions file defines the sentence that appears in SharePoint Designer when you add the custom activity to a workflow, together with the arguments (inputs and outputs) for the custom activity. I’ll assume you know the basics of actions files – if not, check out my first post on custom workflow activities. In my case, the actions file looks like this:

As you can see from the Sentence attribute in the RuleDesigner element, we require the workflow designer to specify the name of the managed metadata field, and we return the term GUID and the term label integer value. Note that in the parameter definition for the mmsFieldName argument, we specify a DesignerType of FieldNames. This enables the workflow designer to select the name of the managed metadata field from a list of all the fields in the current list item.In the SharePoint Designer workflow designer, the custom activity looks like this:

In this case, I’ve created a really simple SharePoint Designer workflow to test my custom activity. I use the custom activity to get the term GUID and term label integer properties from a managed metadata field named Customer, and I write the values to the workflow history list.

In the next post, I’ll look at the other half of the problem – using these managed metadata field properties to update a managed metadata field in another list.

This post was originally posted on Jason Lee’s Blog – http://www.jrjlee.com/2015/01/custom-workflow-activity-for-getting.html