Jaa

What am I gonna do with 40 subscriptions to https://Vibe?

  • Artikkeli

So this is a scenario you could easily find yourself in as one of my larger customers did recently. The answer is also one of the less-obvious, more obvious of answers. So imagine the scenario: you have load balanced Exchange FE (front end) boxes serving a myriad of back ends. Or, in a slightly less dramatic scenario, you have a stand-alone box with a few mailbox stores on it....In either case, or several in between, the problem may surface. You are writing an application that uses the WebDAV subscription/call-back notification capabilities of Exchange to monitor for updates to certain folders in certain mailboxes. Your application has a list of paths to subscribe to (https://email.domain.com/Exchange/mailbox1/Calendar, https://email.domain.com/Exchange/mailbox2/Calendar, etc). As it rolls through the subscription list, you notice that the subscription-id header you are returned appears to be a duplicate!

Well this just won't do. How will your application be able to effectively know what folder issued the notification when the subscription-id now seems apparently ambiguous. The answer, my friend, is the OTHER header you are returned...subscribe-group. Subscribe-group is the base64-encoded GUID of your store. Subscriptions are managed per store which means if you have more than one store on a box, or more than one back end Exchange server, you have more than one subscription list being maintained. The only way to distinguish between them is to capture the subscribe-group header in addition to subscription-id. The NOTIFY on callback will provide you with both and so will the response to your SUBSCRIBE request, so you should be good to go. You will already implicitly know what store you are talking to when you POLL, so the subscribe-group does not need to be echoed to the server. Subscribe-group only helps the client application know which subscription it is receiving a call back for.

Comments

  • Anonymous
    January 31, 2007
    Thanks! :-) Just what I was searching for...