Make a wishing wand - why we need a MicrosoftFlow Custom Connector for MSGraph $Batch

/

A question that has been in the back of my mind since my late night demo of building a Microsoft Flow Custom Connector for Microsoft Graph is this.

I focused on the "how" - because I wanted to show that the whole thing can be done in about 10 minutes.  And I didn't want to skip steps like "oh here's how you register an Azure AD app".

 

But (and this is my fault, I did only ask for 10 minutes) I should have spent some time to talk about the "why"

Why do we need this?  What problem does this solve?

Why does John think this is super special?

This is special because, a $Batch connector is a "Send HTTP Request to MS Graph" as me.

It is a wishing wand that grants wishes. Creating MSTeam is a wish. We didn't build a wish. We built a wishing wand. Then we waved it around.  MS Teams API currently is delegate permission only, so we call it through a $batch connector.

Planner API is delegate only.  Any time you see a delegate permission MSGraph you remember you have a wishing wand.

The Ingredients:

Microsoft Flow and Logic Apps has concept of connectors (these are essentially API definitions) and connections (these are instances of connectors bound to a resource as well as cached automatic authentication)

A Flow is a JSON description of how actions and triggers on the connection are chained together to perform automation.

We do have a general purpose HTTP action, and it works very well for app-only permissions that needs client-id/client-secret or client-cert.  But HTTP action is not backed by a connectors framework so it can't remember credentials.

To build a general purpose tool and remember credentials for Microsoft Graph, we have to build a custom connection.  This is basically a swagger API file that tells Flow and LogicApps what APIs exist on the resource.  In the case of MSGraph, that list is enormous.

The Recipe:

The crazy part though, is MSGraph provides a $batch endpoint, so the recipe for building the magic wand is simply this:

  1. Build a custom connection with one method - $batch - this is a POST
  2. Pre-authenticate it with a delegate permission
  3. Wrap requests (1 or many) as a JSON array and call them via the $batch connection.
  4. We have a magic wand

Agenda for the September community call included Microsoft Graph updates, Microsoft Graph and Microsoft Teams, and custom connectors for Microsoft Graph $Batch

Where do we go from here?

I demoed this with a Manual button trigger.  Jeremy mentioned (in the video) that this can easily be a SharePoint trigger.

This can also be a HTTP Request trigger, turning your Teams Provisioning into one simple HTTP Webservice.  You can hook that up to external systems, PowerApp or a bot.

A technical note

Sometimes you discover you need extra permissions on that Azure AD app.  We do this by going back to Azure AD portal and add the extra permissions.  You can "grant permission" through the AAD portal.

If the cached connection in Flow refuses to work, I find that we may need to right-click on the custom connection and re-authenticate.  Sometimes this requires us to switch to a different user then switch back.  Because Azure AD dynamic consent is just so hard to do.

But it will work.  Just need to toggle a few times.  I do this a lot.

Resources

 

Office 365 Saturday Adelaide - 2018 September 15

/
sps-adelaide.png

So it is said - there's always a SharePoint or Office 365 Saturday every Saturday around the world.

 

O365 Saturday Adelaide / SPS Saturday Adelaide

In less than two weeks, we'll converge in Adelaide Australia for September 15 2018 SharePoint and Office 365 Saturday.

This is a free event (held at Microsoft Adelaide this year) for Office 365 and SharePoint experts, developers, admin and powerusers to converge and talk about Office 365.

https://www.meetup.com/O365-Saturday/events/254139366/

This year I'm presenting an ever evolving talk around Microsoft Flow and what it can (and SharePoint's old Workflow platform can't do).

Hope to see you in Adelaide!

A small favour - share this with two people

Every year we reach out and people that come to the event tells us it's a great event but they wish they know about it earlier.  So here's our small ask:

If you are in Adelaide, please come, and please tell two other colleagues about this.
If you aren't in Adelaide - but you have colleagues in Adelaide, please tell them about this event.

 

 

 

Microsoft Graph Community Call September 2018 - $Batch and Flow

/

I wanted to write a quick blog post letting everyone know I've put my hands up to present a 10 minute demo on using a Custom Connection for Microsoft Graph $Batch in Microsoft Flow.

Custom Connection = Swagger = WSDL

In Microsoft Flow, Power Apps or Logic Apps, a Custom Connection is a Swagger/Open API definition that allows these low-code solutions access to a well defined API, so it knows what to call and how to call them.

For old API guys that knew what a SOAP Webservice looked like, this is the WSDL that tells other systems how to use this service.

In general, calling Microsoft Graph with App-Only Permissions requires only a client-id and client-secret pair, and we can do it directly via the HTTP action without needing a custom connection.

When we do need to create a custom connection, that's usually because we need to call something with Delegate permissions

Why Flow - Connectors Framework

One of the hidden supper power of Flow and Logic Apps is the connectors framework, which cache, renew and manages connections across various different APIs and auth methods.  

This means - you actually don't need to write any of this code.  Repeat - as a developer, you don't have to write code to manage auth.  Auth is encapsulated away and auth code is no longer your concern.

Why $Batch

You'll have to see the demo (I'll update this later).  Hey, I can't spill all the beans in one blog post.  This is a tease.

The result

If you want to automate any delegate-permission API calls on Microsoft Graph, then Microsoft Flow is the easiest way to do it - far easier than writing code, and this is considered a low-code solution, it's crazy nuts.

Resource

Link to the recording will be updated here once presentation is done and uploaded.

The simplest No-Code Solution to Save Picture Files from PowerApps to Flow

/
pexels-photo-1028624.jpg

Today, we are going to talk about a new technique (hack) to send any pictures from PowerApps to Flow.

We will do this with a modified Flow Button trigger.

Update 2019-04 Save Picture Files from PowerApps to Flow via unused Outlook Connector

I’ve came up with an EVEN EASIER hack that you should check out. The 2019 April method is the best one so far.

http://johnliu.net/blog/2019/4/flowninja-hack-87-lock-microsoft-flow-powerapps-trigger-to-upload-images-to-sharepoint-with-ease

Update 2019-03 there’s some JSON definition changes to the PowerApps trigger. See note below.

Update 2019-01 - I did a YouTube recording of this blog post

Quite possibly the easiest way to let us upload an image from PowerApps into SharePoint - from the Add Pictures control (not the low res camera control). Without having to write a custom connection. By hacking a Flow Button into a PowerApps trigger.

Why John, what is the problem? 

Why do you repeatedly write the same post?

The problem is that we want to use PowerApps to collect binary files (mainly images, but also documents, video, anything) and send them to Flow - Flow can then decide where to send the pictures.  To SharePoint, to Email, to Cognitive Services etc.

This is a problem that isn't out of box, and has several good workarounds - some choices more difficult (or limited) than others.

 

What have we got so far?

This is the first method - we can send PowerApps' Camera to Flow via a built in dataUriToBinary() expression.  But it doesn't work for Add Picture from device gallery.  We also can't use this method for sending files - documents, zip, sound, movie clips.

This method lets us use Add Picture from gallery and we can send any binary file formats.  But the input parameter is specialized multipart formdata bytes, so this method needs a Custom Connection (need a Swagger definition file) to work with PowerApps.

 

What is this new method?

We are going to take a Flow Button and hack it into a PowerApps trigger to send Files from PowerApps to Flow.

It will be magical.  Because there will be no Swagger.

 

1. Build a Button-triggered Flow

We start with a Flow Button trigger - which lets us specify which parameters we want as part of the button click.  Flow Button let us select File.

Create FileName and FileContent compose actions to extract the value from the File trigger parameter.  Then use SharePoint's create file to create this file.

Test this Flow - upload a picture of LEGO 10234 - success.

 

2. Examine this Flow Button trigger and switch it to a PowerApps trigger.

Next, we need to check the Flow button trigger and convert it to a PowerApps trigger.

This can be done via Exporting the Flow, open up the export in ZIP file, and change the JSON definition of the trigger.manual.kind from "Button" to "PowerApp".  But here I'm using a simpler way by opening the Flow using Flow Studio's Edit Flow JSON capability.

Try it: https://flow-studio.azurewebsites.net/welcome

Save the changed definition and this is now a PowerApp trigger.

Note: Have a look at the JSON schema generated for the Flow Button's file trigger parameter.  We'll need to know this later.

 

3. Build our PowerApp

Note - this is the Add Picture control.  Not the camera control.

Because our Flow is now a PowerApps trigger - it appears in the available list without us having to build a Swagger file.

The parameters needed is { file: { name: "x", contentBytes: ... }} 
This matches what Flow Button wants for a file upload.

 

4. That's it.  Done.

Run the PowerApps to test.

And the result - LEGO 851400 cup is uploaded to SharePoint via Binary.  No Swagger.

 

Future thoughts

Eventually, I hope we have a way to officially define the input parameters we want to use in a PowerApps trigger.  The way it currently works is awkward.  It should just use the same way that the Flow Button trigger works.

Until that day - this method is possibly the simplest way to send any binary files from PowerApps to Flow.  Because this method doesn't need custom connections - you might find this useful in not hitting your Flow plan limit of 1 custom connection.

Underneath the hood though, a Flow Button trigger is the same as a PowerApps trigger (they are both HTTP Request Triggers).

 

Download File:

https://github.com/johnnliu/flow/blob/master/FlowNinja-SendFileToFlow_20180728000358.zip

 

Bonus Exercises:

  • Create multiple files first in Flow Button before converting to PowerApps trigger.

  • In the definition, made some (but not all) of the file parameters required

 

Update: adding additional arguments

The converted PowerApps trigger works, but you may find it troublesome to edit the Flow after it was changed.  And attempts to use Ask Parameter in PowerApp Trigger within the Flow Designer will cause the PowerApp trigger to be regenerated, potentially breaking the file argument.

Instead, do this.  First make sure it is a Button trigger again.  

Then, create multiple arguments with the Flow Button

Note the two new arguments have very boring names text and text_1

Note the two new string arguments in addition to the file JSON record object.
Result:

 

2019-03 update

  1. When editing the Button trigger to Powerapp do:

    Change Button to Powerapp
    Rename variables to nicer ones file1 and file2 - rather than file and file_1
    fix up references within the Flow to point to triggerBody()?[‘file1’]?[‘name’] and triggerBody()?[‘file1’]?]’contentBytes’]

  2. In PowerApps - call Flow method with two files

  3. See result

Speaking and Hackathon at Digital Workplace Conference Australia - Melbourne

/
DWCAU-Landscape-Temp.png

In a little less than a month on August 15-16, I'll be presenting in Melbourne at the Digital Workplace Conference Australia 2018.  

www.dwcau.com.au

(I still fondly remember this conference as the previously annual Australian SharePoint Conference - but all things evolve.  SharePoint to SharePoint Online to Office 365, and the workplace evolved from portals to intranet to social platforms to conversational platforms).

Flow and Functions: level up our Serverless Toolkit in Office 365

I will be presenting an amped up talk covering the implementation and automation with Microsoft Flow and Azure Functions.  This is one of several sessions on Microsoft Flow at this conference so I will be covering implementation and mastery at level 200+  (But because it's Flow, it'll still look deceivingly simple!)

John join forces with Paul Culmsee and Ashlee at #DWCAU pre-conf hackathon

I want to also mention that I'm helping out with Paul Culmsee and Ashlee's PowerApps and Flow Workshop/Hackathon on 14 August 2018

http://www.dwcau.com.au/workshops/powerapps-hackathon/

I personally don't know how much PowerApps and Flow raw potential would be in that room in the hackathon.  I really want to find out and I hope you would too.  Space for this is limited - please consider this one day pre-conference workshop.

"Learn PowerApps and Flow from experts and build an app that you need." says John.

"Two MVPs for the price of one" says Paul.  I'll just leave this here.

Whether at the conference, and/or the hackathon, I hope to see you there in Melbourne.