Code zealot in a connected world
It is the year 2017 - watch out, because O365 customizations are full speed ahead.
This is a MS Australia Ignite 'lightning talk' for Meetup Madness (sorry, I took twice the amount of time than I should) to convince a room full of people that loved O365 to become developers.
MS AU Ignite Meetup Madness - O365 Customizations in 2017
Much laughter was had. But I stand by what I said - you are now all developers, now go build something amazing!
In a previous blog post, I wrote about connecting to Microsoft Graph with Resource Owner grant.
That particular authentication scheme is for delegate permissions. So the function, utilizing an account's username/password, is performing actions as that user.
I'm revisiting that post today and instead talk about App-Only Permissions, and the steps are very similar, and to some may be easier.
Head into the New Azure Portal.
Add "Read and write all groups" permission under "Application Permissions"
You should see this:
"1 Application Permission"
Hit the Grant Permission button here.
And set up a Client Secret
Nearly there, one more step we need to make the registered app allow implicit flow.
Hit the Manifest button, change oauth2AllowEmplicitFlow property to true, hit save.
Copy the Application ID - this is the Client ID.
On the first page of Azure AD properties, grab the Directory ID
You now have:
$tenant_id = "26e65220-5561-46ef-9783-ce5f20489241";
$client_id = "44da3f20-fc0b-4f90-8bb1-54b1d50e3ecf";
$client_secret = $env:CS2;
$resource = "https://graph.microsoft.com";
$authority = "https://login.microsoftonline.com/$tenant_id";
$tokenEndpointUri = "$authority/oauth2/token";
$content = "grant_type=client_credentials&client_id=$client_id
&client_secret=$client_secret&resource=$resource";
$response = Invoke-WebRequest `
-Uri $tokenEndpointUri `
-Body $content `
-Method Post `
-UseBasicParsing
The small difference between this time and the previous blog is now we are using AppOnly permissions. The grant_type is client_credentials. And you don't need to supply username/password. The clientid/clientsecret pair is sufficient.
$name = "group-name-here"
$client_id = "44da3f20-fc0b-4f90-8bb1-54b1d50e3ecf";
$client_secret = $env:CS2;
$tenant_id = "26e65220-5561-46ef-9783-ce5f20489241";
$resource = "https://graph.microsoft.com";
$authority = "https://login.microsoftonline.com/$tenant_id";
$tokenEndpointUri = "$authority/oauth2/token";
$content = "grant_type=client_credentials&client_id=$client_id&client_secret=$client_secret&resource=$resource";
$response = Invoke-WebRequest -Uri $tokenEndpointUri -Body $content -Method Post -UseBasicParsing
$responseBody = $response.Content | ConvertFrom-JSON
$responseBody
$access_token = $responseBody.access_token
# GET https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/group_list
# $body = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/groups" -Headers @{"Authorization" = "Bearer $access_token"}
# $body | ConvertTo-JSON
# POST - this creates groups https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/group_post_groups
$body = @{"displayName"= $name; "mailEnabled"=$false; "groupTypes"=@("Unified"); "securityEnabled"=$false; "mailNickname"=$name } | ConvertTo-Json
$body = Invoke-RestMethod `
-Uri "https://graph.microsoft.com/v1.0/groups" `
-Headers @{"Authorization" = "Bearer $access_token"} `
-Body $body `
-ContentType "application/json" `
-Method POST
$body | ConvertTo-JSON
There are no other dependencies - authenticate and calling MS Graph is really that simple - two web requests!
Usually, the user that created the group becomes the Owner of the group.
In the Delegate Permission example in the last blog, the group is created with my user account and I'm the owner.
In the Application-Only Permission example in this blog, the group is created with the app account and there is no user owner!
I'm actually pretty terrible at gambling the future of Technology. But I like writing these posts because it makes me sit down and think.
The user experience is dominated in 2016 with the news of SharePoint Framework (SPFx). Which shifts development and toolchain to a more modern JavaScript Stack: NodeJS, Yeoman. WebPack. There are component libraries like Office UI Fabric, but we explored options such as Kendo UI and UI Bootstrap and there are many benefits too. In 2017, SPFx should come down to On-Premises too, we'll have to wait and see what that looks like.
Sure - there are still plenty of gaps where SPFx can't cover - many of us are looking to a solution that allows us to do a site-level script injection or something that will let us do a Single Page Application override. But I'm very bullish on the SPFx. I think 2017 will rock.
https://github.com/SharePoint/sp-dev-docs
React continues to better suit component development, and Angular might catch up, but we'll see. In SPG, we are divided into both camps, and for people that aren't familiar with Angular, I am not opposed to them learning React.
I am however, dead serious that no one should try to learn both Angular and React at the same time. One need to pick one, master it, then the concepts of the other framework will map in the mind and come naturally. Learning both at the same time without mastering either of them will screw one's learning path. Don't risk this.
Have an ASPNET MVC background? Angular will make more sense. Want a more code / component based approach? Then React will make more sense. Pick one and run with it.
I have picked up Angular now and am quite happy with it. Feel free to reach out with Angular+SharePoint questions. I can't help with React questions.
I have high hopes that PnP-JS-Core will continue to gain popularity and wrap around the SharePoint REST Services well. I can totally see a few blog posts in the future using NodeJS, PnP-JS-Core inside an Azure Function to manage SharePoint Online.
As a bonus, it works really well with On-Premises too. Congrats on hitting 2.0.0 Patrick!
Pick up webpack - do it now. gulp and grunt are no longer the right tools that manage the build process. Use them to automate the tasks around the build.
The rise of command-line-interface CLI tools will be the theme of 2017. We have angular-cli, create-react-app, SharePoint Framework has its own yeoman template.
CLI is just a command line's way of "new file wizard"
We did a bit of work with embedding Power BI dashboards into SharePoint, and with the rapid pace of releases of upcoming Power BI SPFx, Push data with Flow to PowerBI and PowerBI Streaming Datasets - it will become increasing no brainer to use Power BI to build your reporting dashboard and embed them into your sites. With a local gateway, Power BI works for on-premises data too.
I would like to say Power Apps is the thing. But it's not, not yet. The reason I say this is that business wants Forms. They want forms to replace paper processes. They want forms to replace older, aging digital forms (InfoPath).
Power Apps isn't trying to be a Form. It is trying to be a Mobile App-Builder. It might get there one day. But I'm not sure if that's the course they have set.
I was thinking Angular-Forms for heavy customizations and Power Apps for simple ones.
I'm open to suggestions.
Several products hit the scene - Flow, Logic Apps are fairly basic. But once you pair them up with an Atomic Hammer (Azure Functions), then everything will look like a nail and everything's easy.
The way I see it, Flow is better for single events and Logic Apps is better for sets of data.
And don't get me started on the dirt cheap price point too.
You've probably seen from my recent posts where I rant on and on about Azure Functions. I truly see it as the ultimate power to do anything that we need a server to do.
We can't escape this. As soon as we begin to connect to various APIs we'll need authentication bearer tokens.
We seem to have better and better helper libraries as time goes on. But regardless, in 2017 - we will need to be able to auth to the Microsoft Graph in any language that we use.
Julie Turner has an excellent series:
And these are my picks for 2017. Do let me know what you think - I'm really interested in points where you disagree with my choices, because I want to learn.
This is apparently a computer story, but is actually also very much a human story. In which we explore the relationship between Azure Functions and Punch Cards.
It's been very warm in Sydney in this blistering summer. My mother comes over to visit and relax and enjoy my air cond. I'm preparing for Microsoft Ignite Australia on Azure Functions, and I was thinking about a human story.
I looked up at mum, this is the frail, little Chinese grandma that plants funny herbs in the garden. We had a chat. I then went online and found this picture.
By ArnoldReinhold - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=16041053
I sometimes talk of my parents who met as comp science students in the 70s. My mother, who sometimes can't remember how to restart her iPad. Well, she cut her teeth on these punch cards. She tells me how big they are - gesturing with her hands - the box of cards would be nearly the size of A4 - much wider and longer than I thought.
I ask, so you need to pass the cards to an operator to run them and wait.
Of course.
What if you have an error in your code?
She pretends she spends a lot of time checking before submitting the cards. But later admitted actually, the code would crash. I think she figures out that it's a funnier story to tell the truth.
And since the output is a printout (the cards are input, there is no keyboard/screen) she'd get pages and pages of invalid instructions handed to her by the operator.
Imagine Developers, if your OPs is responsible to read to you all your compile errors. Every time.
She will have to resubmit her program.
It'd be quite embarrassing she says.
I sat back, and tell her of @AzureFunctions and how I now submit code to be run in the cloud.
And how first few runs, my code would spit back rows of errors. we laughed.
Some things never change.
By NARA - http://www.archives.gov/75th/photos/1950s/20.html[dead link], Public Domain, https://commons.wikimedia.org/w/index.php?curid=17413686
I end this story with this picture. This warehouse stores punch card programs for US National Archives 1959. Equivalent to 4Gb.
While my mother will have a second chance to resubmit her program in the afternoon, I can repeat as many execution as I'd like in the cloud.
The mainframe computer my mother used when she worked in Statistics Bureau of Taiwan is worth hundreds of thousands of dollars, and she has to wait with other programmers to use it.
The Azure Functions that I can write and deploy today, cost me less than $0.01 and most of the time the compute is free.
Bonus: I told her future datacenters will be underwater and completely unmanned #ProjectNatick
Her eyes are full of wonder
In this post, we talk about how to get an access_token in PowerShell to talk to the Microsoft Graph, so we can run automated non-interactive scripts in Azure Functions.
I'm so sorry for butchering the title every time. But this blog post is cool.
I've written previously about creating SharePoint sites via PnP-PowerShell. Which is very powerful and very popular - thank you for all the nice discussions and comments. Soon, people asked - can we do the same for O365 Groups?
The PnP-PowerShell cmdlet for Connect-PnPMicrosoftGraph works, but it raises an login dialog, which makes it a show stopper for non-interactive scripts or Azure Functions. I took it upon myself to find a workaround over my December holidays but alas the solution didn't come until January.
The problem is to authenticate with Azure AD and get an access token that we can use to talk to the Office 365 Graph. The trick, is a little not-well known thing called Resource Owner grant.
grant_type=password
I have a few links about the Resource Owner grant type at the end. Basically, this grant_type lets you use username/password to obtain an access token.
You are probably familiar with these steps by now. Today's screenshots came from the new Azure AD Portal.
Navigate to the Azure Active Directory portal, before we go further, grab the Directory ID - this is the tenant ID you'll need. The tenant ID isn't a private value - it appears in URLs often when you are signing into Office 365. But it's handy, right here, so take a copy.
Create our app.
Add Delegate Permission to Read and Write all groups. Note this requires admin permissions.
Click the awesome Grant Permissions button at the top of the permissions registration, this grants it for users in your Active Directory.
You will need some clientsecrets - create them from Keys. I like them not expiring for a long time. So I pick the Never expires option. It'll expire when I'm long gone.
Copy down your ClientSecret
One final check. Copy the Application ID. This is your app's Client ID.
First, we create another HttpTrigger-PowerShell.
Because we aren't using PnP-PowerShell this time, there is no extra modules dependency. This example is going to be simply Invoke-WebRequest and Invoke-RestMethod
Start with this code:
$requestBody = Get-Content $req -Raw | ConvertFrom-Json $username = "[email protected]"; $password = $env:PW; $client_id = "9308c103-8208-40cd-85e2-37a994b3578d"; $client_secret = $env:CS; $tenant_id = "26e65220-5561-46ef-9783-ce5f20489241"; $resource = "https://graph.microsoft.com"; # grant_type = password $authority = "https://login.microsoftonline.com/$tenant_id"; $tokenEndpointUri = "$authority/oauth2/token"; $content = "grant_type=password&username=$username&password=$password&client_id=$client_id&client_secret=$client_secret&resource=$resource"; $response = Invoke-WebRequest -Uri $tokenEndpointUri -Body $content -Method Post -UseBasicParsing $responseBody = $response.Content | ConvertFrom-JSON $responseBody $responseBody.access_token Out-File -Encoding Ascii -FilePath $res -inputObject $responseBody
Change to your own username/password/clientid/clientsecret/tenantid - note my password and clientsecret are stored in Function App Settings.
When this Azure Function runs -
You'll see the $responseBody and specifically, the $responseBody.access_token
We now have a key.
$access_token = $responseBody.access_token
# GET https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/group_list
$body = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/groups" -Headers @{"Authorization" = "Bearer $access_token"}
$body | ConvertTo-JSON
Out-File -Encoding Ascii -FilePath $res -inputObject $body
Call graph, attach access_token in Header.
My Office 365 groups in JSON. Notice the function took about 1 second between start, obtain access_token, and retrieve graph.
The Graph is not a read-only datasource, and our App has Group.ReadWrite.All
# POST - this creates groups https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/group_post_groups
$body = @{"displayName"="ps-blog"; "mailEnabled"=$false; "groupTypes"=@("Unified"); "securityEnabled"=$false; "mailNickname"="ps1" } | ConvertTo-Json
$body = Invoke-RestMethod `
-Uri "https://graph.microsoft.com/v1.0/groups" `
-Headers @{"Authorization" = "Bearer $access_token"} `
-Body $body `
-ContentType "application/json" `
-Method POST
$body | ConvertTo-JSON
Out-File -Encoding Ascii -FilePath $res -inputObject $bodyHere we go. A new O365 group "ps-blog" is created. Note the function took 3 seconds.
This part is an exercise for the reader. Make an PowerApps app that will call this function - passing in a parameter for the group name. Hook up the Azure Function as a connection and bind it to a textbox and a button press.
Come and see me present all these cool techniques and more at Ignite Australia!
We'll talk about the Azure Functions story for today's Office 365 Developer, IT Pro and Power User.
Azure Functions has an amazing place from microservices to Swagger to the BotFramework!
If you liked this post - please leave a comment below. Please also try the code and let me know how it goes for you. I love reading about people taking my brief demo code further to solve real problems.
I look at how a small team can build amazing things with the latest tools we have in Office 365 & SharePoint. I'm a coder, developer, Office SharePoint MVP. I dream, then I rant.
Founder @ Flow Studio App
A poweruser tool to help every maker write better Microsoft Flows and manage them.
MVP Alumni Office Apps and Services: SharePoint
MVP Alumni Business Applications: Flow
This work by John Liu is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available at /about-me/.
