April PnP JavaScript special interest group call and Azure Functions demos

/

Shortly after the March Azure Functions demo, I reached out and asked Patrick about coming back to do a follow up focused on JavaScript - specifically PnP-JS-Core.  As I've completely skipped it in the March call/demo that was focused on PnP PowerShell (and C#).  When I first started playing with Azure Functions I was doing everything in JavaScript - so it was nice to return to be able to do this demo. 

Uploaded by SharePoint / Office 365 Dev Patterns & Practices on 2017-04-13.

I'm a bit more mindful of the time, but this whole demo is on PnP-JS-Core.

We focused on a few things that people asked in the PnP-PowerShell call in March:

  • What about JavaScript - can you show JavaScript in Azure Functions
  • Isomorphic PnP-JS-Core - running on NodeJS - if you are going to use JavaScript on the client, might as well use the same code on the server.
  • Authentication using Sergei's node-sp-auth (congrats on MVP award!)
  • How to test your Azure Functions locally via azure-functions-cli
  • Live debugging with VSCode (locally)
  • How to pack your JavasScript AzureFunctions so that you don't need to deploy the massive node_modules (which is both costly for storage, and has a higher startup time).  We use azure-functions-pack

SharePoint's Future is full of JavaScript

Lots of quick little demos that makes a nice introduction scenario - but if you have not seen Azure Functions before, this is best viewed as a supplementary follow up to the first PnP Call in March.

Related Links

http://johnliu.net/blog/2017/4/march-pnp-special-interest-group-call-and-azure-functions-demos

 

If anyone asks is Microsoft still investing in SharePoint - show them this.

/

I was attending an MVP community event, and a few non-office MVPs asked me, hey is Microsoft still investing in SharePoint?  Is there anything new coming next?  There hasn't been a product for a few years right?  (This is so odd, we just had SP2016...  and SPO hasn't stopped having new features every month.)

I was also working at a client when one of our advanced users rushed over and asked John - what's going on with this new Teams thing - is Microsoft scrapping SharePoint.  (I was pretty shocked at this one).

Realizing that I'm probably directly connected to the flood of news regarding SharePoint - it is surprising people aren't aware of many of the best and greatest of SharePoint is still to come.  I decided to write this post.

April - SP Tech Con (lastest info as of this post)

This is the latest info as of this post.  Follow Mark Kashman - PM SharePoint. 

This was the SPTechCon keynote. 
https://www.slideshare.net/markkashman/reinventing-content-collaboration-the-future-of-sharepoint-is-now-sptechcon-austin-ms-keynote

 

Feburary - Internal Demo Day

Is there still a SharePoint team?  YES - and they are legion.

Directly from Jeff Teper the father of SharePoint

May - What's next?

2017 May 16 is the SharePoint Virtual Summit.  This is the big one.  Especially if we look back to 2016's May the 4th event when we first embarked on the next step of the Future of SharePoint, and now we see what the team has delivered within just one year.  It's been nothing but awesome. 

So no matter where you are in the world - you should register for the Virtual Summit.

In Australia

The Office 365 Saturday is upon us really soon.  The annual free community event will be coming to a city near you!  You need to sign up.  This helps us plan our catering needs.

O365 Customizations in the year 2017

/

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!

 

Where is SharePoint Customization going in 2017

/

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.

User Experience: SPFx is king

 

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

 

Frameworks: Angular or React

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.

 

SP Helper: PnP-JS-Core

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!

 

Build tool: Webpack

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"

 

Dashboards: Power BI

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.

 

Forms: ???

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. 

 

Automation: Flow / Logic Apps + Azure Functions

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. 

 

Server Code as a Service: Azure Functions

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.

  • Any Elevate Permissions task - in Workflow, Flow, Logic Apps or JavaScript Front-End Application
  • Any long running task
  • Any scheduled task
  • Any event response task - especially combined with the newly released SharePoint Webhooks
  • Any task that requires you to build a set of microservices for your power user to build complex Flows or Power Apps
  • Choose any language you like: C#, NodeJS or PowerShell, in fact, mix them in your microservices - nobody cares how it runs, and it's great.

 

Auth Helper: ADAL, MSAL

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:

 

Summary

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.

 

 

 

 

Interact with Graph and make O365 Groups with AzureFunctions PowerShell

/

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. 

What is the Trick?

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.

Setting up Azure App Registration

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.

To Azure Functions!

 

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.

Calling Graph - Get Groups

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

Calling Graph - Post Group

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 $body

Here we go.  A new O365 group "ps-blog" is created.  Note the function took 3 seconds.

Why I like PowerShell to demo Functions

  1. Code looks simple.  Cmdlets compresses a lot of functionality. 
    Take for example ConvertTo-Json or ConvertFrom-Json.  In C# we'd have to call a JsonSerializer and in NodeJS we'd need double promises just to get a json from fetch()
  2. PowerShell wraps C# and .NET libraries so they can be fairly powerful without a lot of code
  3. Not everyone understand JavaScript, or NodeJS JavaScript
  4. Suitable for IT Pros that may only know PowerShell
  5. Developers should learn more languages - and you can convert this in your head to C# or NodeJS anyway.

Bonus

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.

Ignite Australia

Come and see me present all these cool techniques and more at Ignite Australia!

https://msftignite.com.au/sessions/session-details/1988/serverless-in-office-365-build-services-with-azure-functions-prod324

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!

 

Summary

  • Use PowerShell
  • Get access_token via username/password
  • Get our graph
  • Make O365 Groups

References

 

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.