none
EWS: Exchange and my service play ping-pong RRS feed

  • Question

  • Hello.

     

    I wrote a interface to communicate with exchange (EWS).

     

    Now there is a database application, witch manages appointments and other things.

    When a user creates, edit or delete a appointment, this change will be send to exchange, so that the appointments in exchange and in the database of the application are the same.

     

    For the other way (from exchange to the application) i made a windows service, witch receive push-notifications from exchange, when a appointment was created, changed or deleted.

     

    This works fine, but now I have a ping-pong effect.

     

    When a user changes an appointment (for example the location or the subject) in the application, this change goes to exchange. Exchange sends a notification to my windows service and the service sends this “change” back to the application.

     

    I need an idea, how to suppress this unnecessary step, but keep the function to send the real changes (when somebody changes the appointment in outlook, this change have to be send to the application).

    Wednesday, March 16, 2011 8:30 AM

Answers

  • so another approach that may be slightly preferrable to the above:

    you'd still need to maintain some state but it would avoid the Schrödinger's Cat effect:

    instead of making your extended property boolean, make it a long type.

    then have your EWS app increment the value each time it makes a change to the appointment & write that value into a change log.

    when your windows service receives the modified event, it then only reads the extended property value & compares it to records in the change log (this is the state you will need to maintain).

    If the value in the appointment matches a record in the change log, the service can consume the event & remove the record from the change log. Otherwise, your service knows that it's an external change & passes on the event.

    this obviously presupposes that your change log (eg: ur database) is available to both your windows service & your EWS application.

     

     

    • Marked as answer by GambaJo Monday, March 21, 2011 7:08 AM
    Wednesday, March 16, 2011 4:12 PM

All replies

  • if i understand you,

    your windows service receives Exchange notifications when the appointment data held in Exchange is changed. Hence, when your EWS application syncs its changes with Exchange, this fires an unwanted event in your windows service.

    Since there's no way of telling Exchange not to fire events arising from your EWS app syncing activities, you will need to consume the event in your windows service.

    One easy way would be to create an extended property and set this to 'true' in your appointment along with the other changes your EWS app is trying to sync with Exchange. Then, in your windows service, you know that you can consume any Exchange events for appointments that have your extended property set to 'true' ~oh, & don't forget to get your service to clear your extended property flag before it's done consuming the event.

     

    have fun!

    v.

    Wednesday, March 16, 2011 1:37 PM
  • Yes, this is, what i mean.

     

    I had the same idea like you, and tried it already. But this is not the solution, because if the service clears this property, exchange fires an modified event again (often even three or four events in a row), and this time this property is false, so i am on the same point as before.

    Wednesday, March 16, 2011 2:28 PM
  • haha, yes, i forgot about that,,are you using IMAPIAdviseSink?

    i think those other modified events are re-entrant. ie: if you look at your call-stack you'll find that you're still in your first OnNotify() when you receive the subsequent OnNotify() events as a result of you clearing the flag.

    So you need to maintain state in your windows service & ignore all re-entrant calls...


    Wednesday, March 16, 2011 2:55 PM
  • No, i use EWS (Exchange Web Services). So outlook is not installed, where my service runs.

    Exchange sends Notifications with HTTP/SOAP, so i don't think, that this are re-entrant calls.

    Wednesday, March 16, 2011 3:50 PM
  • so another approach that may be slightly preferrable to the above:

    you'd still need to maintain some state but it would avoid the Schrödinger's Cat effect:

    instead of making your extended property boolean, make it a long type.

    then have your EWS app increment the value each time it makes a change to the appointment & write that value into a change log.

    when your windows service receives the modified event, it then only reads the extended property value & compares it to records in the change log (this is the state you will need to maintain).

    If the value in the appointment matches a record in the change log, the service can consume the event & remove the record from the change log. Otherwise, your service knows that it's an external change & passes on the event.

    this obviously presupposes that your change log (eg: ur database) is available to both your windows service & your EWS application.

     

     

    • Marked as answer by GambaJo Monday, March 21, 2011 7:08 AM
    Wednesday, March 16, 2011 4:12 PM
  • just as an aside,,

    often when things get tricky like this, it's an indication that the design could be improved (though granted, in the MS world of mass side-effects, this is more-often beyond the control of the developer,lol) -i suppose you have a good reason for duplicating -& consequently having to keep in sync- the appointments data already held in one convenient place: Exchange Server; instead of say having your app just provide your custom view of that data..

    Wednesday, March 16, 2011 4:49 PM
  • Thx. You are my hero of the day, you saved my weekend.

    Monday, March 21, 2011 7:09 AM
  • np, &btw, on the off-chance you hadn't thought of it, you might want to also add a bit of code to flush stale records; since inevitably, there will be times when you're EWS app makes an appointment change but your service is not running.. -eg: on start-up, your service could remove any/all records already residing in the change-log ;)
    Wednesday, March 23, 2011 5:32 PM
  • Yes, i even thought of it. Thank you for your advice.
    Thursday, March 24, 2011 7:26 AM