• Skip to main content
  • Skip to primary sidebar

Technical Notes Of
Ehi Kioya

Technical Notes Of Ehi Kioya

  • About
  • Contact
MENUMENU
  • Blog Home
  • AWS, Azure, Cloud
  • Backend (Server-Side)
  • Frontend (Client-Side)
  • SharePoint
  • Tools & Resources
    • CM/IN Ruler
    • URL Decoder
    • Text Hasher
    • Word Count
    • IP Lookup
  • Linux & Servers
  • Zero Code Tech
  • WordPress
  • Musings
  • More
    Categories
    • Cloud
    • Server-Side
    • Front-End
    • SharePoint
    • Tools
    • Linux
    • Zero Code
    • WordPress
    • Musings
Home » SharePoint » Converting asynchronous SharePoint event receivers to synchronous

Converting asynchronous SharePoint event receivers to synchronous

By Ehi Kioya Leave a Comment

SharePoint event receivers are of two types: synchronous and asynchronous. Synchronous event receivers will fire before the event is completed (for example, event receiver for the ItemAdding event). Whereas, asynchronous event receivers will fire after the event has completed (for example, event receiver for the ItemUpdated event).

You can think of SharePoint events as “…ing” vs “…ed” events.

  • Synchronous (Before events)
    • ItemAdding
    • ItemUpdating
    • ItemDeleting
  • Asynchronous (After events)
    • ItemAdded
    • ItemUpdated
    • ItemDeleted

The above is just a small sample. There are many other events available to you: ItemAttachmentAdding, ItemAttachmentAdded, etc.

Here’s some more detail about how synchronous events work compared to asynchronous ones:

Synchronous event:

  • Fires before the event.
  • Blocks the flow of code execution until your event handler completes.
  • Provides you with the ability to cancel the event so that the asynchronous/after (“…ed”) event will not be fired.

Asynchronous event:

  • Fires after the event
  • Does not block the flow of code execution.

So, why would we ever want to make an asynchronous event synchronous? Why not just use its synchronous counterpart?

The problem…

Let’s say you want to update the Title field value of a document with the actual file name (the Name field) every time a file is added to a certain document library. To do this, you have created an ItemAdded event receiver and attached it to the library. The Elements.xml file of your event receiver should look something like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Receivers ListUrl="TheUrlOfYourDocumentLibrary">
      <Receiver>
        <Name>SyncEventReceiverItemAdded</Name>
        <Type>ItemAdded</Type>
        <Assembly>$SharePoint.Project.AssemblyFullName$</Assembly>
        <Class>SyncLists.SyncEventReceiver.SyncEventReceiver</Class>
        <SequenceNumber>10000</SequenceNumber>
      </Receiver>
  </Receivers>
</Elements>

Now if you upload multiple documents to the library in one shot, everything works as expected. The edit screen does not come up. After the documents are uploaded, your event receiver fires and uses your code to update the Title fields of each document as required. No problems there.

The problem appears when you attempt to upload a single document. This time, after the document has been added to the library, the edit properties screen will come up. Let’s assume that the initial version of the document at this point is version 1.0. When we press OK on the edit properties screen, our ItemAdded event will fire. Since we’re updating the Title field of our item within the ItemAdded event, the document version will change to say version 1.1 after the update. Because the version number at the beginning of the upload operation is now different from the version number inside our ItemAdded event handler, we will get a save conflict error.

Note: This problem only occurs if the edit properties page comes up when single documents are uploaded. If you don’t have any required fields on your document library, the edit properties page may not come up at all (in which case, this problem may not exist).

Anyways, if you encounter the edit properties box on single document uploads and still want to run custom code in the ItemAdded event receiver, here’s an approach to solving the problem.

Making asynchronous SharePoint event receivers synchronous

To solve this problem, we need to make the ItemAdded event receiver behave synchronously. So that, by the time the edit properties page is loaded, our ItemAdded event receiver would have already completed its operation and the edit properties page will be loaded with the updated list item.

To do this, we just need to modify our Elements.xml file to include a Synchronization element.

Like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Receivers ListUrl="TheUrlOfYourDocumentLibrary">
      <Receiver>
        <Name>SyncEventReceiverItemAdded</Name>
        <Type>ItemAdded</Type>
        <Assembly>$SharePoint.Project.AssemblyFullName$</Assembly>
        <Class>SyncLists.SyncEventReceiver.SyncEventReceiver</Class>
        <SequenceNumber>10000</SequenceNumber>
        <Synchronization>Synchronous</Synchronization>
      </Receiver>
  </Receivers>
</Elements>

Found this article valuable? Want to show your appreciation? Here are some options:

  1. Spread the word! Use these buttons to share this link on your favorite social media sites.
  2. Help me share this on . . .

    • Facebook
    • Twitter
    • LinkedIn
    • Reddit
    • Tumblr
    • Pinterest
    • Pocket
    • Telegram
    • WhatsApp
    • Skype
  3. Sign up to join my audience and receive email notifications when I publish new content.
  4. Contribute by adding a comment using the comments section below.
  5. Follow me on Twitter, LinkedIn, and Facebook.

Related

Filed Under: Backend (Server-Side), C#, Programming, SharePoint Tagged With: CSharp, Programming, SharePoint

About Ehi Kioya

I am a Toronto-based Software Engineer. I run this website as part hobby and part business.

To share your thoughts or get help with any of my posts, please drop a comment at the appropriate link.

You can contact me using the form on this page. I'm also on Twitter, LinkedIn, and Facebook.

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

23,726
Followers
Follow
30,000
Connections
Connect
14,568
Page Fans
Like
  • Recently   Popular   Posts   &   Pages
  • Actual Size Online Ruler Actual Size Online Ruler
    I created this page to measure your screen resolution and produce an online ruler of actual size. It's powered with JavaScript and HTML5.
  • WordPress Password Hash Generator WordPress Password Hash Generator
    With this WordPress Password Hash Generator, you can convert a password to its hash, and then set a new password directly in the database.
  • How To Execute PowerShell Scripts From PHP How To Execute PowerShell Scripts From PHP
    We can now perform PowerShell magic right inside Linux boxes. For example, here's how to execute PowerShell scripts from PHP code on Linux.
  • About
  • Contact

© 2022   ·   Ehi Kioya   ·   All Rights Reserved
Privacy Policy