Multiple consecutive events firing for wiki pages

 

Scenario:

Let’s say we have a wiki library which has a event receiver attached to the “ItemAdded” event. We write some piece of code that is supposed to fire when an item is added. For the sake of simplicity, let’s say we want to audit who created a new wiki page, so we log it in some way. After writing & deploying the code what we observe is that not only is the “ItemAdded” event fired but also the “ItemUpdated” event fires. Why does SharePoint do that?

Well, the cause is pretty obvious “a” wiki page is created and right after it’s created it’s opened in an edit mode, hence the two consecutive events. Nice article by Damon BTW in the context (Managing ItemUpdating and ItemUpdated Events Firing Twice in a SharePoint Item Event Receiver).

Challenge:

We just want to log\track “a” single event, since it’s very much possible that the user may not want to edit the page or may just cancel it out.

Q:how do we conditionally fire the event?

One possible solution:

Before we look at the possible solution, couple of facts:

  1. As you may know that each event (ItemAdding, ItemAdded, etc. check this out for the complete listing of SharePoint Events) generates a new “instance” of the class that extends the base class SPItemEventReceiver.
  2. The ItemAdded event is always going to fire before the ItemUpdated event, irrespective of the Synchronization property.

The issue is to persist the fact that a new wiki page is being added and preserve it between the “ItemAdded” event and the “ItemUpdated” event and then based on that information, conditionally fire the ItemUpdated event. Here is where a “Key-Value” based collection can come to our rescue.

The approach:

Here is a high level mention of the steps…

  1. Create a static variable of a collection type  for e.g. Hashtable
  2. Use the “ListItemId” property from the event args (default name, properties) and store it as the “key” in the variable created in step 1; the value part being a flag or status of some kind…for e.g. I used “new”
  3. In the “ItemUpdated” event use the same variable created in step 1 and then get the flag\status using the same “ListItemId” property from the event args. Once the value if available, we can then do the conditionally processing.

So even though, there are multiple events firing in there(which is technically correct), we can still isolate them and conditionally do some processing. One important thing to remember is that once we have used the value in the “ItemUpdated” event from the collection variable, we need to delete that so that the variable is light-weight and doesn’t cause unnecessary load.

Sample (incomplete) code:

public class EventReceiver1 : SPItemEventReceiver
{

    static Hashtable listItemStatus = new Hashtable();
   
    public override void ItemAdded(SPItemEventProperties properties)
    {
        base.ItemAdded(properties);
        Debug.WriteLine(“wiki – item added at: ” + DateTime.Now);

        EventReceiver1.listItemStatus.Add(properties.ListItemId, “new”);

    }

    public override void ItemUpdated(SPItemEventProperties properties)
    {
        base.ItemUpdated(properties);

        string listIdStatus = EventReceiver1.listItemStatus[properties.ListItemId] == null ?
                string.Empty :
                EventReceiver1.listItemStatus[properties.ListItemId].ToString();

        if (!String.IsNullOrEmpty(listIdStatus) &&
                String.Compare(listIdStatus, “new”) != -1)
        {
            Debug.WriteLine(“wiki – new item added; do nothing at: ” + DateTime.Now);
            //very important to get rid of it – can be moved to finally block as well
            EventReceiver1.listItemStatus.Remove(properties.ListItemId);
        }
        else {
            Debug.WriteLine(“wiki – regular item updated at: ” + DateTime.Now);
        }
    }
}

The same logic can be extended for other lists or libraries as appropriate to their respective behavior for the various events.

Hope this helps…

Advertisements
This entry was posted in SharePoint 2010 and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s