Binding asynchronous event handlers as synchronous

In SharePoint, we know, there are two types of event receivers, asynchronous and synchronous, for example, the ItemUpdating and ItemUpdated. The ItemUpdating is synchronous while the ItemUpdated is asynchronous. The obvious difference is, the synchronous event is raised before committing the changes so that we have the opportunity to cancel whatever the the operation but not in the asynchronous event as that is raised after successfully committing the changes requested.

With that simple description I will dive direct to the specifics as there are plenty of information available about event handlers in SharePoint out there. From here on, I will make a safe assumption that you know about the event handler in SharePoint and also how to write simple event handler.

With that I will explain my finding on how to bind the asynchronous event handler as synchronous as this will help us in some scenarios.

By default, using the object model, we can register the event handlers by,

parentList.EventReceivers.Add(SPEventReceiverType.ItemAdded, Constants.AssemblyName.EventManagement, className);

parentList.Update()

This will bind the event handler to the list using the default binding depending on the type of the event, for example, if it is ItemAdding, binding is synchronous and ItemAdded the binding is asynchronous.

Another way of registering an event handler to a list is by creating an empty handler and setting the values separately,

//Create the event handler
itemAddedEventReceiver = parentList.EventReceivers.Add();

//Set the values for the item added event receiver
itemAddedEventReceiver.Name = NameOfItemAdded;

//Set the binding
itemAddedEventReceiver.Synchronization = SPEventReceiverSynchronization.Synchronous;

itemAddedEventReceiver.Type = SPEventReceiverType.ItemAdded;
itemAddedEventReceiver.Assembly = Constants.AssemblyName.EventManagement;
itemAddedEventReceiver.Class = className;
itemAddedEventReceiver.Update();

parentList.Update();

Main advantage of registering event handlers in the second way, is, probably obvious by now, we can change the binding, so we can register the asynchronous event handlers such as ItemAddeded with binding set to synchronous as below.

itemAddedEventReceiver.Synchronization = SPEventReceiverSynchronization.Synchronous;

This way it is guaranteed that both ItemAdding and ItemAdded are completed synchronously. The main advantage I found here is, consider the document library and if you need to perform an automatic operation whenever a new document is added, you can do that in the ItemAdded event handler and modify the the list item and save it with the modified data within ItemAdded event handler, this works well with the multiple document updated as the multiple document update raises only ItemAdding and ItemAdded, but in the case of single document upload, as a standard feature in document library, just after the document is uploaded, SharePoint opens the list item in property edit page to enter the new property values, now since we modify the list item in ItemAdded asynchronously, the version of the list item in the property edit page is not the one we saved in ItemAdded event handler as a result when we attempt to save the new properties, we will get the unfortunate save conflicts.

So this can be avoided by registering the ItemAdded event handler to work synchronously, then the property edit page will be opened with the updated list item and not the original one.

We must use internal names.

Recently I was testing the application we designed and developed in SharePoint 2007, on SharePoint 2010, the main and least expected  problem that I discovered was the usage of display names to retrieve the values of the some fields. During the development, of course we had a common understanding to use the internal name whenever we deal with the fields as that is the unique  for the SPField but we have slipped few places and never  used the internal names, these retrieves were happened to be in the workflow module where we retrieve the field values from the workflow task list items, to edit  the respective tasks. Fortunately, the display names of some fields of the task list are changed from 2007 to 2010, I said, fortunately, because, if it is not for this, the bug will stay dormant in our production code for bit longer time.

Even this is a well know fact, I decided to share this finding with the development community to re-emphasize the usage of internal names and also to highlight the changes  in task list.

The problem I encountered is, in the task list for work flows, some of the display names are differrent in 2010. For example, we had a "Link" field in 2007 and the same field is renamed to "Related Content" in 2010, but the good thing is, the internal name remain the same  "WorkflowLink".

For the help of the beginners, this probably the way to go.

private object GetFieldValueByInternalName(string internalName)
{
              object rawValue = null;
              SPField fieldToExamine = null;

              if (null != TaskListItem)
             {
                   //Get the field by the internal name
                   fieldToExamine = TaskListItem.Fields.GetFieldByInternalName(internalName);
                 
                  if (null != fieldToExamine)
                 {
                         //Field does exist, get the value
                         rawValue = TaskListItem[fieldToExamine.Id];
                  }
             }
             return rawValue;
}