I am trying to move from EWS to Microsoft graph and facing problem while implementing syncFolderItems flow.
I need to track and update changes of all created, modified and deleted events using Microsoft graph apis.
I went through Microsoft documentation and found they have delta Api which returns only the changes which occurred from last sync. But I am not sure how recurring events should be handled using delta queries api.
Please help. Thanks in advance.
The current behavior is that only the master event (the one with the recurring pattern) will show up in the delta feed, not the other instances. Only instances that have been updated will then show up in the delta feed.
You would need to use the calendar view API to get all the occurrences of a specific master event (with a recurrence pattern) you see in the delta feed.
Additionally you can ask for recurring events instances to be added to the delta feed on Microsoft Graph uservoice.
Related
We're looking for a way to get a list of all currently active PSTN calls being made into MS Teams. We've tried this:
https://learn.microsoft.com/en-us/graph/api/callrecords-callrecord-getpstncalls?view=graph-rest-beta
That's almost exactly what we need except records do not seem to appear here until the call has ended. What we need for the app we're trying to build is live call records.
We've also tried it by creating subscriptions and getting the ID of specific calls then looking up call records, but this data also appears to be delayed.
Is there a method we're missing here, or equally, is this something that may be added to the API some point soon?
Currently there is no graph API to get a list of active PSTN calls in Teams.
Microsoft will always focus on customer’s feedback and experience, some new features would be added to the services based on customers' feedback in the future, we also recommend you give your new idea in Teams UserVoice here.
They clearly mentioned in the document, we can not fetch the details directly. But you can fetch the records from your application. Using app side bearer token.
This is with reference to Microsoft Graph calendar events – iCalUId Update, And I would like to have an update on whether it has been rolled out to all 365 accounts or Is it underway? If so, please provide the timeline for the same.
Recently I've got a response from Microsoft on this, https://developer.microsoft.com/en-us/office/blogs/deferred-icaluid-update-on-ms-graph/?_cache_bypass=1586319170.
In addition to details on the link, they also mentioned followings:
MSFT has put iCalUid change on hold and doesn't have any plans to change it in the near future,
they are introducing new fields to identify occurrences in a series of master events. These fields will be supplementary to existing properties while iCalUId continue to exist as it is.
I hope that this will be helpful for someone else who's looking within this regard.
I am migrating from EWS to Microsoft graph and having problem in replacing flow "ExchangeService.syncFolderItems".
ChangeCollection<ItemChange> changedItems = exchangeService.syncFolderItems(calendarFolder.getId(),
FirstClassProperties, null, 512, NormalItems, syncState);
This gives me all the changes since last sync state with change type.
Now I need to replace this with Microsoft graph.
I saw Get delta api in Microsoft graph and also how to call it recursively using stale token. My query is, Get delta api is not returning the change Item type. Could someone suggest me the best way to implement this in Microsoft graph? Maybe the Apis that I need to use for this?
Note:This flow will be called by my service to get changes after fixed interval of time. Also I saw subscriptions ( https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0 )but not sure that could be used in my case as my service will be making a call to get changes for a meeting room after a fixed scheduled interval of time.
I am stuck here. Please help. Thanks in advance.
Deleted events will have a #removed property and only provide the id of the object as denoted here https://learn.microsoft.com/en-us/graph/delta-query-overview#resource-representation-in-the-delta-query-response
Updated objects will only include the updated properties and added objects should include all the data available. It's up to the 3rd party application (your app) to maintain a state on it's side to be able to differentiate between updated and created objects when using Delta queries.
Combining webhooks with Delta to trigger the sync instead of relying on a timer is a good approach to provide an end user experience that feels more real time
Currently, there is no way to create a subscription for change notifications that track changes to all /groups WITHOUT group membership changes. I know this functionality is available using delta queries with the $select parameter, but that is a pull operation rather than the automatic push notification that is available via webhook notifications/subscriptions. Having this functionality can cut down on the number of notification messages received for groups where membership changes are NOT desired or wish to be tracked by this method - for which in that case, delta notifications could be substituted for that purpose as previously indicated.
Please advise. Thank you!
Currently change notifications for groups do not support $filter or $select odata query parameter to narrow down notifications. The solution in that case would be to use a combination of change notifications and Delta query where the change notification triggers requesting Delta changes which allow you in turn to determine the content of the change and whether it was "interesting" for your application.
If this is not a satisfying solution, you could look at change notifications with resource data (preview), however this is not implemented for groups today so you'd have to request it on uservoice. That or support for odata query parameters.
We recently updated the profile information in Azure active directory. when we use People API in graph explorer, it is not returning the latest information. How much time does it take normally to return the updated information?
The /me/people API is actually returning from a search index, not a real-time fetch from Azure Active Directory directly. The search index update depends on many characteristics of your AAD. It is safe to say you should see this reflected within 24 hours.
Obviously there is value in the people API with its underlying logic. If you wish to have the data updated instantly. You should use the /users/ to fetch the latest content.