Introduction/ Question / Hypothesis

So earlier today Marc D. Anderson [http://www.sympmarc.com or @sympmarc] sent out a tweet regarding a SharePoint Designer Workflow not firing and pointed us to a post he added in StackExchange here SharePoint Designer Workflow Not Always Firing so I wont belabor this post with the details, he spells it out quite excellently.

So, a few of us Scott @ciphertxt Hoag, myself, Tasha @tashasev Scott chimed in and offered approaches to solving the problem, notwithstanding the great suggestions, and they were great suggestions, my bias as a SharePoint developer [ignoring that you should seek Out of Box solutions first] commented ad-nausium that it could be handled quite easily with an event receiver, assuming that you were allowed to write code as a solution to the issues faced.

Materials/Methods

Schooled as I am from the British educational system in the commonwealth, I approach everything through a scientific method. So, my approach was going to be

1. Create an Environment adhering to the same boundaries as the test case
2. Create an Empty SharePoint Solution in Visual Studio 2010
3. Create two Projects
   1. Project 1: A Console App to Prove out the work
   2. Project 2: The actual event receiver with the (hopefully) working code
4. Test, Re-Test, Brag about it J if it works

Creating the Environment

First thing to do was create an environment for the Managed Metadata Service with my own nomenclature but adhering to the test case

 

 

 

 

 

 

 

 

 

 

 

            

 

<p>

Next we create a list to consume the information

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configure the MMS Column to get data from the Term Set under the MarcDAnderson Group

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Creating the Visual Studio Solution

Next we have to create a blank SharePoint Solution in Visual Studio. I do this because I don't want any of the extraneous things that come with a predefined project as well as, I plan to have a tester project as well as an Event Receiver Project, its easier and cleaner to control that yourself.

You will notice the Tester Project is set as Startup, we will change that for the Event Receiver time to deploy. So, since we will be working with Managed Metadata Service (MMS) you will need reference not only to the standard SharePoint dlls, but also Microsoft.SharePoint.Taxonomy as well, in both your Console App and the actual Event Receiver.

 

As this was an empty project, when you click on the project and do "New Item" and select Event Receiver, it will add the Microsoft.SharePoint and Microsoft.SharePoint.Security, but you will have to manually add the .Taxonomy

When you have done that, its time to code out the Tester Console App, which is quite simple, and after I was done I realized I could have just gone straight to the Event Receiver because it wasn't that complicated, in fact, its more lines of code in the tester than there will be in the production deliverable.

Testing out that code yielded the below.

Next I coded out the Event Receiver, since the context of the Item is inside the SPItemEventProperties, no need for a SPSite, SPWeb ect. I just needed an SPListItem object to bind to the Event Properties as in Line 21 and we are off to town. MMS Fields are in value pairs, Label and Guid, so you use the TaxonomyFieldValueCollection to bind to the field holding the MMS value and then split it base on the Pipe [|] character that separates the named values. As you can see on line 27 I have the pair commented out, that is because Marc only needs the Label, as shown in line 28. After that its just setting the Text Columns named "ValueStringFromCategory" with the values from the MMS Field and calling the Update Method.

 

That's it, now time to Deploy and Test..

 

Results

Once deployed, you can just add a new item as you see below

Select the MMS field or fields, I did set mine to multi-value, it wasn't called out in the Test Case, but I wanted to be complete.

Click OK, leaving out the third field because that WILL be filled out by the Event Receiver. Click Save when done.

You will notice that the field is blank when you click save, but when you refresh the list, as seen below, the item appears.  If you did this in the ItemAdding Event of the Event receiver then you would not need to refresh. But i didnt, so…

 

 

Discussion/Summary Findings

 

So, lessons learned. Marc says that this is ok, but doing a Custom Workflow activity would take this to the next level, so will tackle that on the plane ride to #SPS12

Cheers all.. See you in VEGAS!!