I am using ews-java-api and having a lot of problems
I create appointments and also listen for appointments created elsewhere.
My problem is I create the appointment with
new Appointment(exchangeService).save(notificationMode)
I also save the appointment details including uniqueId, lets call it x, to my db
I see the appointment appear in exchange no problem, I then see a notification that it has been autoaccepted (I can turn off auto accept for the room and still get the same problem below.
Then I see my exchange subscriber kick off as it receives the notification events from exchange that a new appointment has been created. I seem to get 4 events each time, a created event, two modified events and move event.
The problem is each of these events have a uniqueId of y not x as I would expect.
This means that I cant check to see if this is an appointment I have already created.
I never get an event with the original uniqueId x as I would expect. I know that unique ids can change, and that sucks, but there does not seem to be any other field I can use.
Any ideas what I can do to work around / fix this?
A given id for an item will change when the active directory in which it resides changes. It sounds like your auto accept is moving the item. I have not tested this scenario.
If you do a simple .save() you will get a create and a modify event back from exchange on your next push/pull. There doesn't appear to be a way to prevent this. They should have the same id as the one that you got from your save. You just need to check to see if you already have the item for the create. For the modify, well I can't speak for Microsoft as to why we get a modify but it should be exactly the same as the create.
You are then getting a modify, and a move event when the item changed directories. These 2 items will have different ids than the one that you received during the original save. The ItemEvent has an oldItemId that I believe you can use. It's also possible to parse out the GUID from these ids which doesn't change but no real need to do that I think. Best approach might be to use the OldItemId and process the move event.