Is there any documented way to map a message response from Exchange Active Sync to message response from Microsoft Graph?
Currently I'm writing some custom code and mapping them locally.
Exchange Active Sync and Microsoft Graph are two different implementations. Some of the concepts between the two are similar. In general you will need to carefully look over the graph response and adjust the custom code to meet that requirement.
Related
Microsoft Graph API has support to retrieve mail rules for individual mail boxes. Is there any API to get the list of rules configured by Admin for the organization?
https://graph.microsoft.com/v1.0/users/user-id/mailFolders/inbox/messagerules
Not that i am aware of using Microsoft Graph API. At this point Graph API supports only individual mailboxes. The closest one i can see is that you can application permission to query other mailboxes as well. But it won't tell or get you the list of rules configured by admin for the organization. Being said that you can consider filing an uservoice so that it can be considered to be implemented. As an alternate you can use from Exchange PowerShell (something like Get-Trasportrule).
I have a Machine learning model that can classify emails, I'm using GraphAPI to read emails but, model performance is not up to the mark since I'm unable to remove the signature from email for training.
Is there any way to read emails from outlook without email signature?
No, the email's signature is also considered as a body data and you could find that data inside the body's content property. Please raise a feature request in the Microsoft Graph Feedback Forum so that the Microsoft Graph product team may develop it in future.
SharePoint Online can be accessed either using SharePoint's own native REST API, or, using Microsoft Graph API. I have briefly explored both of the APIs and see differences in terms of the capability, for example, SharePoint API has function type method calls (GetByTitle()), whereas the Graph API seems to support identity based access, or, 'site path'. My opinion is that SharePoint makes it easy to access resources through the use of 'function' in URL, however, i am not sure if it is RESTful. It would be helpful to have your views on this aspect.
Given the two options (SharePoint & Graph) which is the recommended way forward, considering below criteria's:
Future proof - in terms of enhancement, support from Microsoft
Performance
Functionality coverage - considering current version of Graph API
Also, I couldn't find any Microsoft recommendations on this, if there is one kindly share the link.
Thanks.
I recommend Microsoft Graph API. I know it is a proxy to actual Sharepoint, OneNote, Planner, and etc API, but the way they are improving graph api day by day makes me think it is going to last for a good time. Let's say if you are writing an app that wants to connect with many Microsoft apps endpoints, having one class that handles all the graph api requests is enough instead of looking for specific apps endpoints.
Performance: I have been using Microsoft graph api for most of SharePoint related work and it works good and fast. I use Graph explorer to check out the graph if it actually works before implementing it in the app.
Functionality Coverage: Obviously graph is a proxy of a real api so it won't cover all the processes you need to do in SharePoint. For example, I had to create a Sharepoint Group which I could not find a way via graph api. But I assume as more people vote on those requests, the graph api is bringing those new possible proxy endpoints too. But again if your app is only working with Sharepoint then I believe I would stick to SharePoint API. In favor of Graph API, they also have something called delta query and subscription notification to see changes in the files and documents.
I was under the impression that the Graph API was meant to centralize things, make one endpoint to connect to all Sharepoint services via API. With that in mind, I wonder if we shouldn't be asking which is the better option but rather we should be asking when the so-called native option will be end of lifed. Graph is more future proof in the sense that this is the direction MS is taking. I can't speak to performance personally. As far as functionality, I can't imagine that Graph is functionally worse than previous iterations of SP. It might be functionally different. But it should expand API functionality.
Following this question :
Microsoft Graph API mail office 365: Is any option create inbox message NOT as Draft?
I want to convert from EWS to Graph API ,
in EWS it is under the section below:
https://msdn.microsoft.com/en-us/library/ms527629.aspx
How can I change/ modify mail message flags with REST ?
I saw in beta version is possible somehow...
Part of the REST is here:
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/mail_api_overview
Any suggestions please ?
#Nicolas is correct. Check out Microsoft Graph API mail office 365: Is any option create inbox message NOT as Draft?
In there there is a link to an MSDN article that explains each of the flags, their integer values, etc...
It's important to remember that while the graph API (for Exchange related foo) looks a lot different than EWS, they actually share a bunch of the same logic underneath and ultimately talk to the exchange Store underneath. What this means is that all of the MAPI goodness (proptags, named props, etc...) can be accessed through the graph API via extended props. Funny bit of trivia - currently the REST API on the server side when it deals with extended props converts them into the EWS internal representation of extended props and calls the server side EWS business logic (in proc) to process them. So not only is it similar, it is exactly the same :)
Using PHP and the Microsoft Graph API I'm fetching a user by querying:
https://graph.windows.net/<tenant>/users/<userId>?api-version=2013-11-08
This works fine, but only returns the standard fields for the user object. According to the documentation I'm supposed to be able to use $select=* to get all the user data, like this:
https://graph.windows.net/<tenant>/users/<userId>?$select=*&api-version=2013-11-08
However this gives me the following error:
{"odata.error":{"code":"Request_BadRequest","message":{"lang":"en","value":"The ability to use the $select query option to define a projection in a data service query is disabled. To enable this functionality, set the DataServiceConfiguration. AcceptProjectionRequests property to true."}}}
How can I enable "AcceptProjectionRequests"? I find nothing about this in the documentation or in other SO-threads.
The APIs you are referencing above are Azure AD Graph which is different than the Microsoft Graph APIs. It might be worth your time to have a look at the Microsoft Graph APIs and consider transitioning away from Azure AD Graph. The general guidance from the Azure AD Graph team recommends using the Microsoft Graph instead of the Azure AD Graph. You can read more about the differences and the Azure AD guidance here.
Having said that, Azure AD Graph does not support $select (as stated in the blog posting I linked to above). Microsoft Graph does support $select for doing query projections (see Microsoft Graph or Azure AD).
Currently (as of 7/8/2016) Microsoft Graph supports most of the directory features that Azure AD Graph supports, but not all. In some cases, Microsoft Graph supports functionality that is not in Azure AD Graph (such as ability to make $select projection queries).
Per OData spec, $select=* can either return all entity properties or a default set of properties (provided the default set contains all key properties). The Microsoft Graph implementation is the latter and it will return a set of key properties. In order to get all the necessary properties you need, you will need to explicitly request the entire list you want unless they happen to be within the default set.