If you made it with me up to this blog post, it’s very likely, that you read the previous 5 blog posts about my learning journey about Microsoft Graph as well – Thank you. If not, this is your chance to catch up here.

The Lap around Microsoft Graph Toolkit is a super cool series initiated by the Microsoft Graph team to empower more developers in working with Toolkit.

I learned so far how to work with Toolkit components, and thanks to the excellent work of our Office development MVPs, I am now able to style and even template components. Never thought this would going to happen, but this super detailed step by step approach made developer tools/toys even accessible and usable for me, a non-developer.

From HTML application to SharePoint Solution

In Day 9 of the #MSGraphToolkitLap MVP Hugo Bernier guides us from writing web applications to writing a SharePoint solution. As usually in this series, we break it down to some (supposed to be) easy to follow steps. We already know these steps from Season 1 of our #MSGraphToolKItLap when we worked on creating our first HTML application. Let’s see how this goes.

1. Register your application

We learned in Day 2, that we needed to register our application in Azure AD and that we needed that Client ID of this application to get access to our Graph APIs. In SharePoint solutions, we can skip this step, because each solution package automatically creates a unique ID which we use to grant access to Microsoft Graph APIs.

2. Create your application

Let’s get our hands dirty! Hugo guides us through creating our web part app with Yeoman SharePoint generator. As I recently dipped my toe into how to make my first Hello World! SPFx web part following these docs.microsoft.com, which Hugo also refers to, it was easy to do that, thanks to super detailed guidance. If you struggle with that, there is also an excellent video about how to set up your dev environment and do these first steps provided by Vesa.

Adding TypeScript 3.7 is a good idea since we can get rid of some error messages. I am not too fond of error messages, not only because I wonder what they mean, but because I always assume that I did something wrong, and then I question my skills. So if a few additional steps can avoid me getting error messages, this is already a good investment of time and effort. For context: I can write some super basic lines of JavaScript and never experienced doing stuff with TS. So I am a little bit insecure about how this turns out. But as the blog post series seems to be a super beginner-friendly end-to-end tutorial, I probably manage that as well.

3. Add Microsoft Graph Toolkit to your application

We did that in our previous HTML application by adding a one-line script, which was just a copy-paste job. (By the way: The more I learn about dev stuff, the more I am convinced that CTRL c and v are the essential keys on my keyboard).

For our SharePoint Solution, all we need to do is installing an npm package, which again is just a one-line command.

4. Add the MSAL SharePoint Provider

As we now deal with SharePoint and not an HTML application anymore, we do want to add a SharePoint provider. Remember part 5 of my series, where I explained that we do not necessarily as makers need to be able to write our providers? As a developer, you can do that, check out Nikola’s sample on this Github repo for reference. It’s just great that there is already a SharePoint provider in place, that we can use. You know, I love LEGO, and this seems to be the SharePoint Lego Set. Installing the SharePoint provider is quite easy, as we only need to add three lines of code. Understanding how providers work on a high level (thanks again to Simon Agren) helped me here.

Wow, the hardest part is already done, and it only took us a couple of minutes!

5. Add the login component

When we still worked on an HTML app, we used the mgt-login component because we wanted to enable the user to log in securely. In SharePoint, things are a little bit different: Users, who consume a SharePoint web part, already need to be authenticated. They did that login already, so we do not need to log in users twice. Nothing to do in this step – you see, stuff gets easier in SharePoint!

6. Add additional components

Again an easy step – we are already familiar with components like mgt-person or mgt-agenda – the only thing we need to do is adding these components in our HTML. Now we can repeat what we learned in the last season, like customizing the components so that they match more our needs or style them like we want it and even use the mgt-get as a placeholder for any data we want to get and even update.

Now that we translated our previous HTML application knowledge to SharePoint, it’s time for

7. Build our solution

First things first, choose the right MSGraph API permissions. When I learned something the hard way in Power Platform and Graph, it’s that permissions comes first. So let’s do this by simply

• changing “isDomainIsolated”: true to “isDomainIsolated”: false

  in a JSON file and

• adding the correct permissions. Don’t you know which permissions you need? I hope that if you follow my blogs that I can’t stress enough, the value that docs.microsoft.com provides. Read the formidable manual is always a good advice. Just look up what you need, it’s not rocket science. Those webApiPermissionRequests always consist of a resource, which is “Microsoft Graph” and a scope like user.Read.All”. As always: Don’t add permissions that are not needed.

After we built the solution with

• gulp bundle –ship
• gulp package solution –ship

Note: Educated by Elio Struyf that I needed to –ship as otherwise only I could use that.

We can find an sppkg package in our solution folder. I mean, how easy was that?

We now want to upload our sppkg file to SharePoint’s app catalog, and we get asked to deploy our solution. It’s a good idea to have a careful look at the permissions again. We need to approve the pending permissions on the API Management page. What you need to know: By hitting this deploy button, we get a list of all permission requests, which we now need to approve. To access that list, we navigate to the SharePoint Admin Center and select ADVANCED -API ACCESS. Now approve all of these pending requests. This step is mandatory; without approved permissions, our web part can’t work.

8. Test our web part

Perhaps you are already familiar with the concept of a local workbench for testing. It runs on your machine. This won’t work here as it is not authenticated, so that we need to switch to a hosted workbench, which runs in our tenant. We now test by adding the new web part in this hosted workbench and see our component for the first time in action

I tried with mgt-agenda and mgt-tasks, and both worked like a charm.

Feedback and what’s next

If you liked this blog post, please let me know with a helpful comment. Also, follow me on twitter. I will surely blog about the upcoming blogs of Microsoft Graph Team using the hashtag #MSGraphToolKitLap.