EWS create appointment without getting a streaming notification - exchangewebservices

I'm working on synchronization from our application to Exchange and back. I've set up a streamingnotification to the calendar of a room/resource defined in Exchange.
When I create an appointment in the calendar of the room I get a notification in my application, which is great. However, I also want to change this appointment from our application and send these changes to the calendar of the room in Exchange. That is no problem, but then I also receive a notification from Exchange. Basically Exchange is telling me that item 'x' has changed, when I'm the one who changed it, so I already know and don't want to process this change.
Is there a way to determine where the change originated from, or tell EWS to not send a streamingnotification when I edit an item?

Whenever you change an Item in EWS with UpdateItem the lasted ChangeKey is returned in the Response https://msdn.microsoft.com/en-us/library/office/dn605828(v=exchg.150).aspx . This property allows you to track when changes occur on the Item or to validate if no changes has occurred since the last modification.
The PidTagLastModifierEntryId property https://msdn.microsoft.com/en-us/library/gg672131(v=exchg.80).aspx will tell you who last modified an appointment.

Related

In Ews push notification mode, I am getting unwanted unsaved Appointment. How to get rid of them?

I am using Exchange Web Services' push notification mode. I noticed that when I "New an appointment" in Exchange, if I click "attachment" button, it jumps to Attachement page, and push a "Item" notification into the SOAP servlet right away, without me "Save" the appointment. I guess this is probably how it works. But then I need to identify this "Item" as unfinished in my code, such that I can ignore it until I received another notification when the appointment is actually saved. So far, I've tried a number of properties such as isDraft, isDirty, getAppointmentState and etc to identify this "unsaved" appointment, but none of them worked.
So my questions are:
Can I config the exchange server such that it stops pushing notification for "unsaved" appointment?
Failing to do (1), how can I identify the "unsaved" appointment? Which property to check?
Thanks in advance,
Ling
Notifications are basically just telling you that an Item has been created on the server and based on way the UI action is taking place the client is creating an item to cater for the UI interaction so you will get a notification regardless. There is no such concept as a draft appointment and then next notification you get for that appointment should be an update. Multiple notification for an appointment is something that your code you should expect and deal with if you synchronization process is going to work reliably.
One thing you can try is to look at the item that is being created with a MAPI editor like OutlookSpy or MFCMapi as that will tell you if there is a specific extended property that you maybe able to use.

Fields returned from EWS getItem request on Appointment are incorrect

The add-in I'm working on makes an getItem EWS request using Office.js to get certain fields otherwise unavailable. Mainly recurrence data, the all day flag, and the the body for older Exchange versions.
Depending on the environment the fields are incorrect when composing an appointment. Once the appointment is sent (if it has attendees) or saved (if it does not have attendees) then the fields are correct.
The start date and end date are a year ahead, the subject and body are empty when they shouldn't be, and the item class is always IPM.Appointment or null regardless of whether the it's a recurring appointment. Saving the appointment via Office.js before making the ews request does not make a difference. I even tried making the ews request a few minutes after I saved the appointment.
This seems to occur for some Outlook on the web users, but not for users using the Windows clients. I tried Outlook on the web with an Office 365 account, on-premise 2016, and on-premise 2013. Only the Office 365 account seems to have this issue.
My question is, is there something I can check, like the Exchange Server version, to find out if a user will run into this issue? I want to prevent using incorrect data if possible.
This scenario occurs when calling Office.context.mailbox.item.saveAsync on a new Calendar item that has not been sent yet. We are aware of this issue and are looking into a solution to resolve this so that the API can be used as designed. The API should behave as designed in Mail and on Existing Calendar items. Note that for existing Calendar items, an update may be sent out to attendees depending on the changes that the user or the add-in made in the compose form.

Subscribe Orion without receive old entities

There is some way to subscribe to Orion (e.g. Car entity), without receive the old entities?
Example:
Orion has -> Car A, Car B.
I do onchange subscription and Orion sends me at same time:
Car A notification and Car B notification.
We need the following:
Orion has -> Car A, Car B.
I do onchange subscription but don't receive nothing at this moment. If in a future Orion receives Car B, or changes some attribute of Car A or Car B, then send the notification.
Is that possible?
The behaviour is explained in the the user manual:
You may wonder why accumulator-server.py is getting this message if you don't actually do any update. This is because the Orion Context Broker considers the transition from "non existing subscription" to "subscribed" as a change.
We understand that for some uses cases this is not convenient. However, behaving in the opossite way ruins another uses cases which need to know the "inicial state" before starting getting notifications corresponding to actual changes. The best solution to make everybody happy is to make this configurable, so each client can chose what it prefers. This feature is currently in our roadmap (see this issue in github.com).
While this gets implemented in Orion, in your case maybe a possible workaround is just ignore the first received nofitication belonging to a subscription (you can identify the subscription to which one notification belongs by the subscriptionId field in the notification payload). All the following notifications beloning to that subscription will correspond to actual changes.
EDIT: the posibility of avoiding initial notification has been finally implemented at Orion. Details are at this section of the documentation. It is now in the master branch (so if you use fiware/orion:latest docker you will get it) and will be include in next Orion version (2.2.0).

Getting rename event from Box webhook, also are events preferred to webhook in Box?

I'm trying to use webhooks to get notifications for changes in a user's Box account. One thing I don't see is an option to get a webhook notification when an item is renamed. Is it possible to get a notification for rename? I see that RENAME is available via the event API, is it preferable to use the event API? I saw another stackoverflow question asking about webhook vs event (Box webhooks deprecated in favor of long polling?) and the answer said webhooks are still valid, but didn't really comment on webhook vs event.
I'd prefer webhooks since they are a close fit to how I get changes for Dropbox accounts but it appears from the docs that event has more information/options. Also, it seems it's possible to miss a Box webhook notification which could create an inconsistent state between Box the model in my application.
Which to choose?
Many thanks!
I don't believe it's possible to get a WebHook notification when an item is renamed.
The choice between WebHooks and events really depends on what you're building. WebHooks are generally easier to use, but the events stream can give you more power. In your case, you'll probably need to use events so you can be notified of a renames.
It's also worth noting that if your application really depends on staying in sync with the state of Box, you're better off using the events stream. It lets you specify a last known position in the stream so that you can catch up on any missed events if your application goes offline.

Exchange Web Services: Access proposed date and time through Appointment

When a meeting invitee proposes a new meeting time, in outlook this information can be found in the "Scheduling Assistant" (outlook 2007):
Is there any way to access this information programmatically through the EWS API? The RequiredAttendees and OptionalAttendees collections of the Appointment allow me to find out whether and when the attendee has responded, but how can one access the actual proposed new time?
I haven't tried this before but here is how I think you'd go about getting this information. The EWS service and the EWS Managed API don't have this implemented as first class functionality. To be more precise, the propose new time functionality is currently available as first class functionality with Exchange Online. For Exchange Online, you will need to inspect the meeting response message XML for the ProposedStartTime and ProposedEndTime elements. So if you are using Exchange 2007, 2010, and currently 2013, you will need to do what I state in the next paragraph. You should be able to access this information by using extended properties.
An attendee that proposes a new meeting time will always result in the organizer getting a meeting message. When the organizer performs a GetItem request for the meeting message sent by an attendee, the request should request the PR_RECIPIENT_PROPOSED property. A value of true indicates that the recipient proposed a new time. This should trigger a request to get the PR_RECIPIENT_PROPOSEDENDTIME and PR_RECIPIENT_PROPOSEDSTARTTIME property values.
Here is an example of getting this type of property with the EWS Managed API;
Here is a quick property definition:
ExtendedPropertyDefinition PidTagRecipientProposed = new ExtendedPropertyDefinition(0x5FE1, MapiPropertyType.Boolean);
You cannot get this information using the EWS from the Appointment, I'm afraid. It's part of the PR_MESSAGE_RECIPIENTS property, which is a MAPI table (or Object, if you will), and EWS does not support retrieving this. Technically, you could probably get it if you want to build out the ExportItem functionality (a supported function serverside that is not built into the EWS Managed API) and pick through a massive binary stream to find the information, but that's hardly feasible. I haven't tried it myself. The other alternative would be to use something other than EWS to access the data.