InfiniTec - Henning Krauses Blog

Don't adjust your mind - it's reality that is malfunctioning

Exchange Developer Roadmap - WebDAV and StoreEvents gone

Microsoft just released a post about the technologies being removed from the next version of Exchange. I'm ok with WebDAV being removed, given that EWS will be extended to support access to hidden messages and providing strong-typed access to mailbox settings. I can also live with the fact that CdoEx and ExOleDB will be remove. But store events are another thing.

Sure, they are not really easy to implement and the whole access using ADO is a terrible mess. CdoEx makes it not exactly better as there is no support for tasks.

The proposed replacement for store event sinks are transport agents and EWS notification. While transport agents are fine when dealing with email messages, they are useless with respect to appointments, contacts and tasks. This leaves the EWS notifications as the sole option here. Why is this bad?

  • Synchronous execution (access to old data as well): Synchronous event sinks (OnSyncSave, OnSyncDelete) provide direct access to the item being modified (the record is directly available). And during the Begin phase, the event sink can even open the old record and execute actions based on how fields where changed. This feature will be lost completely with EWS notifications.
  • Register once, even for new users (storewide eventsinks): Store wide event sinks are registered once on a store and it will be triggered for every mailbox in the store - even new users. EWS notifications must be registered for each mailbox and the application receiving the mails is required to monitor Exchange for new mailboxes.
  • Access to all properties, even during deletion of an object: With a synchronous OnSyncDelete event sink, all properties of an item can be examined before it gets deleted. With notifications I merely get a notification that and item with a specific ItemId has been deleted. The client application is responsible to track the deleted item - whether is was soft-deleted or moved to the recycle bin. The properties can then be accessed from there. But if the item was hard-deleted (in case of the dumpster being disabled on public folders, for example), one is out of luck. The real problem is this: The ItemId is based on the email address of the mailbox owner as well as the MAPI EntryId of the item (see Exchange 2007 SP1 Item ids). Both, the mailbox address as well as the MAPI entry id are not guaranteed to be stable (Since Exchange 2003 SP2, Exchange recreates meeting items under certain circumstances: CDOEX Calendaring Differences Between Exchange 2003 and Exchange 2003 SP2). This has the effect that the ItemId is not suitable as a long term identifier which should be stored in a database. In scenarios where Exchange data is being replicated to a relational databases, this can become a problem.
  • Order of execution: Synchronous event sinks are called in the order the items were changed. With asynchronous notifications, this cannot be guaranteed.
    To clarify this: The order in which notifications are sent to the client application cannot guaranteed to reflect the order in which the changes were made. To work around this issue, the each notification carries a watermark and a previous watermark. This way a client application can restore the correct order. But with synchronous store events, this comes for free.
  • Silent updates: Due to the possibility to modify an item while it's being changed, the synchronous store events allow some sort of silent update. This works like this:
    1. Along with all the other modifications, a client program sets a special user defined field to an arbitrary value.
    2. The event sink checks this field during the Begin phase, and if it's set it won't process the item. Instead it just removes the property from the element.
  • Modify changes made by a user / Block modifications: A synchronous event sink can modify changes while they are being saved. It can even abort the change, thus preventing a user from deleting an item for example.
    Note: Canceling updates/deletions can break synchronization with ActiveSync or Outlook. So don't do this!
  • Performance: In most scenarios, the WebService receiving the push notifications will not reside on the Exchange server (I know a bunch of administrators who even hesitate to install the .NET Framework on the Exchange server let alone software which does not come from MS*). In this case, the push notifications work like this:
    image
    This makes three network hops to get the properties of a changed item. What makes things worse is the fact that the notifications are send for each modified element. With store event sinks, one could specify a filter so that the sink was only triggered for a subset of elements.

So, while store event sinks are certainly no unconfined pleasure to use, they are far more suited for certain scenarios. I would rather see them being replaced by a managed solution (like transport agents) than the stuff that is coming now.

By the way, the OnTimer, OnMdbShutdown, OnMdbStartup event sinks are being removed without any replacement.

Enough ranting for one day...

* Now, one could argue that a store event sink has far more impact on the Exchange server and those administrators would also hesitate to install them... while that is technically true, there is no other option yet, so they have to swallow that pill.


Posted by Henning Krause on Friday, May 23, 2008 4:41 PM, last modified on Tuesday, July 19, 2011 8:58 AM
Permalink | Post RSSRSS comment feed

Comments (4) -

On 5/23/2008 7:50:45 PM Stephen Griffin United States wrote:

Stephen Griffin

You make some good points. I just wanted to address a couple things you said under the performance heading: Exchange 2007 is dependent on the .Net, and EWS code, while convenient to write in .Net, is not. So if they're not installing .Net on their server, their server ain't running. Smile

The picture you give for push notifications is accurate. That's how MAPI's push notifications work as well - the server sends a UDP packet to the client, the client asks the server for the details, and the server sends them over. So if you're comparing this aspect of EWS perf to MAPI, it's a wash.

Reply

On 5/23/2008 8:00:18 PM hkrause Germany wrote:

hkrause

Stephen,

So if they're not installing .Net on their server, their server ain't running
This was with respect to Exchange 2003. Nonetheless, those administrators install the framework because they simply have to do it - not that they like it.

So if you're comparing this aspect of EWS perf to MAPI, it's a wash.
I was comparing them to synchronous store events - which work differently. MAPI is something I've never touched Smile

Reply

On 7/5/2008 8:42:18 PM Marco Netherlands wrote:

Marco

Thanks! Are there currently any other alternatives then Event Sink that have the same functions as the SyncSave and SyncDelete events?

Reply

On 10/1/2008 11:41:30 AM Jesper Fischer Denmark wrote:

Jesper Fischer

I totally agree, currently there is no replacement for synchronous Store Events.

We have developed a solution that uses the Synchronous Store Event on public folders to add some Custom properties to new incoming messages. This is done before the message is committed to the database. However an error exists in the Store Event on Exchange 2007 that will not allow access to any mail properties on plain text messages. Microsoft has so far refused to fix this bug and we are using the OnSave asynchronous Store Event instead. This causes a problem for the RPC communication between the Outlook client and the Exchange Server.

1.  The message is delivered to the public folder
2.  The Outlook clients are notified that a new message is delivered and it uses FindRow to query for the new data
3.  Then the asynchronous OnSave event kicks in and changes the item on the Exchange server
4.  The Outlook client is notified again about a change and uses FindRow again to retrieve the new data
5.  The update on the server triggers a new OnSave event and the StoreEvent code is called again. It also appears that another error exist in the asynchronous OnSave event that causes more than one OnSave event to trigger when you do an update

This means that the RPC communication between outlook and the Exchange server will increase to at lease double the amount that the synchronous Store Event will cause, and the load from invoking the OnSave Store Event code needs to be run at lease twice and increase the load on the server.

If we could use the synchronous Store Event then we could avoid all these problems and I can see the same problems if we need to use the EWS instead.

Reply

Add comment

biuquote
  • Comment
  • Preview
Loading