FYI: DeleteItem behavior, Exchange 2010 SDKs, EWS performance and SyncFolderItems, and Named Property Mapping in Exchnage 2007+
Fellow developer support engineer, Patrick Creehan, has any interesting post about the delta between the documentation of DeleteItem calls and the actual behavior involving including the ChangeKey in the ItemId of the item you want to delete. In theory the ChangeKey would be required for DeleteItem requests to ensure that you know you have evaluated the latest version of the item and decided to delete it. If you pass an ItemId with a stale ChangeKey, you should get a error indicating this isn’t the latest version of the item and you can retrieve it to make sure you still want to delete it. This is how an UpdateItem request works. As Patrick’s post indicates, DeleteItem doesn’t work the same way UpdateItem works – it just ignores the ChangeKey and does the delete no matter what. Patrick has a workaround to provide similar functionality in case you need it.
…
The Exchange API team announced, they’ve posted a beta SDK for Exchange 2010 on MSDN. In their post they highlight the most notable change in the structure of this SDK:
“…For earlier product releases, all Exchange developer documentation is included in a single SDK. For Exchange 2010, documentation for each technology area is published in a separate SDK, making it quicker and easier for you to find information that you need. The following SDKs are available online for Exchange 2010 Beta:
…
Henning Krause posted a couple interesting articles that go along with my earlier, performance themed EWS posts (part 1 & part 2). His first post is about processing items in a folder using the EWS Managed API, he walks through some of missteps I see customer make when they complain about how “slow” EWS is – as he points out it often comes down to choosing the right tool for the job and synchronization is often over looked by novice EWS developers who choose to loop through an entire folder looking for changes instead. His second post is more about limiting the requested PropertySet to increase the performance of your EWS code – something I have pointed out earlier with GetItem and FindItem calls but it is good to reinforce this concept in SyncFolderItem calls as well.
Speaking of GetItem vs. FindItem calls – Henning has a third post which shows you how to get the message body with a FindItem request even though technically you can’t request the “item:body” schema property in a FindItem’s PropertySet. His post points out an important concept which is that schema properties (or “first class properties” as they are sometimes called) are tied back to extended properties which are the “raw values”. Often times certain limitations are applied to the schema properties because they calculations can be expensive or unavailable at a certain time – however in some cases you can get around this by using and understanding the correlating extended properties.
…
Jason Nelson posted a couple items (round 1 and round 2) on the Exchange team blog about named property mapping detailng the history and problems with this mapping and upcoming changes in Exchange 2007 SP2 and Exchange 2010. Most notable from the “round 2” post is that in Exchange 2007 SP2 and Exchange 2010 “…no x-headers are ever promoted to individual properties if a client has not already requested (and mapped) them. Not even authenticated submissions can create new named property mappings.” This could pose a problem if your application relies on these headers to do processing, if you are using an Exchange API with property access like EWS, MAPI, CDO 1.21, WebDAV, or Outlook 2007+ object model then fear not, “…x-headers are still stored in PR_TRANSPORT_HEADERS and still accessible to MAPI clients but they are not individual properties.”
However, if your application uses IMAP the story is different…
“Exchange2007 does not contain an STM file - it doesn't save the original mime content. Messages are converted to MAPI. IMAP has the ability to search based on header values, but if these are not promoted, the result is that the message is not contained in the results. If a client has previously mapped t he header in question (a MAPI client) then messages delivered after this will have the x-header promoted as an individual property.”