Compartilhar via

MAPICDO and Long-Term Entry IDs

  • Artigo

When I wrote the other day about the 8211 version of the MAPICDO download, I mentioned there a new notification flag. Here’s more information on that flag.

The new flag is fnevLongTermEntryIDs:
#define fnevLongTermEntryIDs ((ULONG) 0x20000000)

This flag is not a new notification type and should not be used on its own. Instead, pass this flag in the uLEventMask parameter of IMsgStore::Advise to change the way fnevNewMail and the various fnevObject* notifications behave. Normally, when you get these notifications from the Exchange provider, the NEWMAIL_NOTIFICATION and OBJECT_NOTIFICATION structures contain Short-Term Entry IDs. With the addition of this flag, these will be Long-Term Entry IDs.

We added this flag to help with a common performance issue: MAPI clients which are tracking changes to messages will typically index their current view of messages by the Long-Term Entry ID. When they get a notification that an item has changed, they would call OpenEntry to open the item and from there request the Long-Term Entry ID so they can match the notification to the item in their index. They’d have to do this even if they don’t need any other properties from the message. These repeated OpenEntry calls can be expensive. By implementing the fnevLongTermEntryIDs flag, we’re giving them a way to avoid most of these calls.

Some notes:

  • This flag is only available in the MAPICDO download, version 6.5.8211 and above. It will not work in earlier versions of the download and will not work with Outlook’s MAPI. Attempting to use this flag on those versions of MAPI will give MAPI_E_UNKNOWN_FLAGS.
  • This flag will only work with the Exchange provider, emsmdb32.dll. It will not work with other providers, such as the PST provider, mspst32.dll.
  • This flag will only work with IMsgStore::Advise. Do not attempt to use it with other implementations of Advise.
  • There is a (very small) performance cost to this flag, as the conversion from Short-Term Entry ID to Long-Term Entry ID may require an RPC to the server. The performance cost is far less than an OpenEntry call though. If you can remove any OpenEntry calls by passing this flag, then do so.
  • A side effect of this flag: If one advise sink is registered with this flag and another is registered for the same events without the flag, both will get Long-Term Entry IDs.

Enjoy!

Comments

  • Anonymous
    March 02, 2011
    Even if the long term Entry IDs are returned by the notification, isn't the CompareIDs method is still needed to match the notification to an item? If so, is there a benefit to this approach compared to using CompareIDs on a short term Entry ID from a notification to a list of long term Entry IDs in an index?

  • Anonymous
    March 02, 2011
    Certainly, you could do that. Some applications want to queue the notifications as they come in and defer processing until later (or even hand it off to another process). This can make using Short-Term Entry IDs difficult since they may no longer be valid when you get around to processing them.

  • Anonymous
    March 02, 2011
    This is most welcome Steve! Currently we have to maintain a list of long term ids and use a table notification to process messages that are deleted. This is because with a short term id you can't open the entry to get its long term id (as its been deleted!). As we use the long term id to link entries in our system and exchange, this will be of huge benifit to us as we will no longer need to maintain this list. Or so I hope anyway.

  • Anonymous
    November 19, 2018
    Steve,I know this is a very old post, but is there something similar to this for IMapiFolder::GetHiearchyTable? There is not a property (that i'm aware of) of PR_PARENT_LONGTERM_ENTRYID. When pulling the subtree table, it'd be nice to always get longterm IDs from it as well.Regards,Eriq