{"id":4533,"date":"2020-05-04T08:11:50","date_gmt":"2020-05-04T15:11:50","guid":{"rendered":"https:\/\/officedevblogs.wpengine.com\/?p=4533"},"modified":"2021-08-31T14:39:42","modified_gmt":"2021-08-31T21:39:42","slug":"a-lap-around-microsoft-graph-toolkit-day-7-microsoft-graph-toolkit-providers","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/microsoft365dev\/a-lap-around-microsoft-graph-toolkit-day-7-microsoft-graph-toolkit-providers\/","title":{"rendered":"A Lap around Microsoft Graph Toolkit Day 7 \u2013 Microsoft Graph Toolkit Providers"},"content":{"rendered":"

Author:<\/strong> Simon \u00c5gren, Microsoft Office Development MVP<\/p>\n

Welcome to Day 7 of the Microsoft Graph Toolkit blog series<\/a>!<\/p>\n

So far in this series, you have gotten acquainted with many important pieces of the Microsoft Graph Toolkit. Today we will talk about the last remaining piece of the puzzle, the piece that makes everything magically work \u2013 the provider.<\/p>\n

The fundamental role of a Microsoft Graph Toolkit provider is to enable all the components to call Microsoft Graph to retrieve and render data. The provider takes care of getting the necessary access token with the requested scopes.<\/p>\n

Today you will get a high-level overview of the Microsoft Graph Toolkit Providers, the architecture and even how we could use it outside of the components to make Microsoft Graph calls.<\/p>\n

What\u2019s in the box?<\/h3>\n

Microsoft Graph Toolkit offers ready-to-go providers that are useful in the most common scenarios.<\/p>\n

Providers\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Description<\/p>\n

Msal<\/a>\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0Uses MSAL.js to sign in users and acquire tokens to use with Microsoft Graph.<\/p>\n

SharePoint<\/a> \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Authenticates and provides Microsoft Graph access to components inside of\u00a0 SharePoint web parts.<\/p>\n

Teams<\/a>\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Authenticates and provides Microsoft Graph access to components inside of Microsoft Teams tabs.<\/p>\n

Proxy<\/a>\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0Allows the use of backend authentication by routing all calls to Microsoft Graph through your backend.<\/p>\n

Custom Provider<\/h3>\n

All the ready-to-go Microsoft Graph Toolkit providers have been created in the same way that you could create providers yourself. They are reusable and are created for the most common scenarios. When would you create your own custom provider then?<\/p>\n

You\u2019d want to create your own provider if you find yourself in a scenario where you have an application with existing authentication code and want to hook into that mechanism. The question you want to ask yourself here is if it makes sense to create a reusable provider. Is this likely a recurrent situation? If the answers are yes, you are at the right spot to learn how to create your own providers. There are two ways to create custom providers:<\/p>\n

SimpleProvider<\/h4>\n

For non-recurrent situations you can use the simple provider. Basically, the role of the simple provider is to return the token from your own authentication code. Instantiate a SimpleProvider <\/strong>class by passing in a function that will return an access token for passed-in scopes.<\/p>\n

Here is a sample that Nikola Metulev<\/a> built with the SimpleProvider and MSAL.js: Simple Provider Sample<\/a><\/p>\n

IProvider<\/h4>\n

For resusability in recurrent situations you can create your own provider. All Microsoft Graph Toolkit Providers (including SimpleProvider) extend the IProvider <\/strong>abstract class. You can also extend IProvider <\/strong>to create your own provider.\u00a0 We suggest you read more here: IProvider Documentation<\/a><\/p>\n

The Architecture<\/h4>\n

\"architecture<\/p>\n

The image above is an attempt to visualize the Microsoft Graph Toolkit provider architecture at a high level. The image is divided vertically into two sections: Provider Initialization<\/strong> and Provider Consumption<\/strong>. There is actually more going on behind the scenes than shown in this diagram – these are the important things to understand.<\/p>\n

The Providers<\/strong> namespace is very central, as it holds the global provider reference that is being used by the components when calling Microsoft Graph.<\/p>\n

Provider Initialization<\/h4>\n

The first thing we need to do is initialize a new provider. Then we need to set the newly initialized provider as the \u201cglobal provider\u201d in the Providers namespace. You can do this process in two distinct ways.<\/p>\n

\"top<\/a><\/p>\n

By a developer in code<\/h4>\n

Simple enough, we initialize a new provider instance with the configuration properties we need and set it to be the global provider.<\/p>\n

Providers.globalProvider = new MsalProvider({\r\n\u00a0\u00a0\u00a0 ClientId: \u2018[CLIENT_ID]\u2019\r\n});\u00a0<\/strong><\/pre>\n
Another example could be in a SharePoint Framework Web Part, where we use the Web Part Context to initialize a new SharePointProvider<\/strong>.<\/p>\n
protected async onInit() {\r\n\u00a0\u00a0\u00a0 Providers.globalProvider = new SharePointProvider(this.context);\r\n}<\/pre>\n
Using a Component Provider<\/h4>\n
In the last post regarding the The Power of mgt-get<\/strong><\/a> you saw the usage of the Component Provider mgt-msal-provider<\/strong><\/a>.<\/p>\n
<mgt-msal-provider client-id=\u201d[CLIENT_ID]\u201d><\/mgt-msal-provider><\/pre>\n
Behind the scenes the component provider initializes a provider in code and sets it as the Global Provider, in a similar fashion as the developer would have done.<\/p>\n
this.provider = new MsalProvider(config);\r\nProviders.globalProvider = this.provider;<\/pre>\n
Provider Consumption<\/h4>\n
Microsoft Graph Toolkit uses the Microsoft Graph JavaScript SDK<\/a> for all calls to Microsoft Graph. The IProvider has been designed to work with the SDK and its AuthenticationProvider class.<\/p>\n
\"bottom<\/a><\/p>\n
Each provider implements an instance of the SDK which enables the provider to call Microsoft Graph APIs either from inside of a component or outside. More on this later\u2026<\/p>\n
Another cool thing is that the provider keeps track of the user\u2019s authentication state, which is either loading<\/strong>, SignedIn <\/strong>or SignedOut<\/strong>. When the state changes the components gets an update via event handlers, so they know when it’s time to call the Graph.<\/p>\n
Each component checks to see if there’s a provider present and if the state is SignedIn <\/strong>before using the SDK to call the Graph.<\/p>\n
if (provider && provider.state === ProviderState.SignedIn) {\r\n\u00a0\u00a0\u00a0 const graph = provider.graph.forComponent(this);\r\n}<\/pre>\n
Extending the mgt-get scenario<\/h3>\n
In the previous post Cameron Dwyer<\/a> created a great scenario in order to show you how to use mgt-get<\/a> to displaying items from a SharePoint list. But what if we would like to do another operation that is not about getting data, what if we want to create or update something?<\/p>\n
We will build upon the scenario from the previous post, by grabbing the initialized global provider from the Providers namespace and use it to update the list items in the SharePoint list.<\/p>\n
Let\u2019s look at some of the code… (You can also look at this sample in Try-It-Out repo here<\/a>.)<\/p>\n
const provider = mgt.Providers.globalProvider;\r\nlet graphClient;\r\nif (provider && provider.state === mgt.ProviderState.SignedIn) {\r\n\u00a0\u00a0\u00a0 graphClient\u00a0 = provider.graph.client;\r\n}<\/pre>\n
After grabbing the Global Provider, we check the state to see if the user is considered signed in. If that is the case, we create a reference to the SDK Graph Client.<\/p>\n
I have made some small changes to the HTML code as well:<\/p>\n
\"code<\/p>\n