Does SharePoint Online expose metrics on number of Api calls made against a tenant? - microsoft-graph-api

Is it possible to get information on the number of REST API calls made to a SPO tenant, and who made these calls (app registrations, sp's, users, etc.,)? If not available directly within SPO, can this stats be extracted from the Microsoft Graph (gateway)?

Related

How to use the omniauth gem to set up oauth access to the Power BI API

We have a Ruby on Rails application and we use the Omniauth gem to set up OAuth access for our users to several APIs. The Microsoft Graph API is one of these. Now we want to add the Microsoft Power BI API.
We usually use a Omniauth "plugin" gem specific to the API. These gems facilitate the process specific for that API by calling specific API methods and using specific attributes in the data provided but the process is the same for all these API's. For Power BI no such plugin gem is available.
The generic process that Omniauth uses to create OAuth access (create an access token) for a user is
request the access token from the API and
request information of the user (using that access token)
create a user specific record containing an identifier for that person (uid), general information of the user (email/name) and the access token
The problem we run into occurs because the Power BI API does not seem to have a method to retrieve user information. This method is available on the Microsoft Graph API (https://graph.microsoft.com/v1.0/me) so we tried using that. This leads to the following two problems:
You need to specify a scope on the API requests and that scope has to also be defined on the app on the Microsoft Azure Portal (AAD). The key and secret of that app is also used on the request to the API. It is possible to add a scope for the Graph API and PowerBI API on the app. However, when combining the scopes of these API's when calling the PowerBI API leads to exceptions
After getting an access token from the Power BI API using a scope that is limited to the Power BI API it is not possible to request user information from the Graph API with that access token
So we see no possibility to finish the Omniauth process to create user specific records with all the data that is needed to do subsequent Oauth authorised API calls for those users.
How can we
either get user identifying information from the Power BI API,
or get the required information from the Graph API using the access token granted by the Power BI API
or is there another way that we can get the Omniauth approach to work for the Power BI API?
I have no experience with either the Microsoft Graph API or the Microsoft Power BI API, so these are general thoughts on how to solve this using OAuth.
How can you get user identifying information from the Power BI API?
You can't. As you said, it doesn't exist: "the Power BI API does not seem to have a method to retrieve user information"
How can we get the required information from the Graph API using the access token granted by the Power BI API
Again, you can't. This is a dead end as the the PowerBI API will not accept a token with the combined scopes.
Is there another way that we can get the Omniauth approach to work for the Power BI API?
Since you can't combine the scopes, I think you will need to request two access tokens, one for each API. So, the thing to be solved here is how do you execute two OAuth sequences in the context of one request? Writing a custom OmniAuth strategy is one approach, but then you lose all the value in the "plugin" gem. I would try to still use the "plugin" gem, but in your callbacks controller, execute a redirect to the second OmniAuth route to step through the OAuth sequence for the Power BI API. You'd need to find an OmniAuth OAuth2 gem that's generic enough to use for the Power BI API (this could use the skip_info option since an info endpoint doesn't exist). You'd also need to persist the OmniAuth hash from the Graph API authentication in a different location, so it's not overwritten when you authenticate to the Power BI API.

List mail transport rules of Admin using Microsoft Graph API

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).

MS Bookings Graph API send to multiple participants

We have been extensively using graph API's and Bookings and have a request for scheduling group sessions through Bookings. Currently, we think we can only do this by recursively generating a booking for each person. We would like to be able to specify a list in the JSON when creating it.
Use Case is for a group therapy session that will have multiple people.
Part two of the request is to be able to publish a booking event and allow multiple external users to sign up to attend.
All tips and guidance welcome.
Thanks!
Create an Azure AD based application and choose the Identity flow suits you
Get the access token from Azure AD
With the token make Graph API calls (Bookings/Calendar) based on your application logic and send to multiple participants...
In addition, even you can think about considering Azure A2C scenario as well, so that you can allow multiple external users to sign up to attend.
You confirmed that you're trying the BETA version of the Bookings graph API Batch calls
and that seems to be working.

Identify shared folders with Graph API

Is there a query or data element accessible using the Graph API that will allow you to distinguish a shared mailbox from a normal user in o365? I normally want to only sync users if they have certain licenses but also include shared mailboxes (which do not require a license).
A User and a Mailbox are two different things. A User is an account managed by Azure Active Directory, a Mailbox is an email destination managed by Exchange Online.
If you're asking how to determine which users have access to a given mailbox, this is not available through Microsoft Graph. You would need to use a different mechanism to determine a mailboxes configuration; the most common being Exchange Web Services or PowerShell (which is most likely using EWS behind the scenes).

How to create organizational contact using MS Graph or Office 365 REST API

Office 365 administration center allows to create organizational contacts which are shared with all users in organization.
In MS Graph documentation API of this functionality is badly documented and located in BETA section. Moreover, there is no command to create such a contact: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/orgcontact
It looks like in Graph this functionality was not implemented. Using typical POST request to the /beta/contacts ends with an error response in Json structure: Unsupported resource type 'Contact' for operation 'Create'.
Note 1: I don't have any user logged in. My application uses service/daemon authentication.
Is there any other way to create organizational contact?
At this time, creating new orgContact objects isn't supported by the Graph API. You also cannot create organizational contacts with the Azure AD Graph API. For more information about organizational contacts, including how they are created in your tenant, see the Contact Entity documentation.
Organization Contacts are documented in the beta section because this API is in fact still in beta. I'm sorry you ran into issues here but with any beta endpoint there is always likelihood of missing/broken features and sparse documentation. There is also a substantial likelihood of breaking changes being rolled out to beta endpoints. As such, we do not recommend using them in production scenarios.

Resources