We now have a PowerShell script sitting in the cloud which we can talk to via a HTTP REST call.
This time, we’ll create a Custom Connector in PowerApps so that we can hook our script into an app.
Part 2: Create a Custom Connector
You should first make sure that you can talk to your function with PowerShell:
Open your Function in the Azure console and click Get function URL.
Leave default (Function key)selected and copy the URL. You should get something like this: https://dan-function.azurewebsites.net/api/a_HelloWorld?code=PA1Twlk/anVrchlbKSZSvZcWQCawE5MjY2JcQ3s0/kMYqpnvI2WEMA==
Append &Name=myName to the end and run with Invoke-RestMethod:
Once you’re happy that your function is working, switch over to Power Apps.
Here’s a video demo:
And here are step-by-step instructions:
Start with Custom Connectors → New custom connector → Create from blank
(Create from Azure Service (Preview) doesn’t work with the Azure Functions 2.x runtime – a to-be-expected example of two preview features not working together.)
General screen Host is your Azure Functions domain, in my case: dan-function.azurewebsites.net
Request click Import from sample Verb = POST URL = an example of a full query, including Name=myName Click Import, then delete the block named code, as it is already handled in the Security section.
Response Click Add default response, then run a chunk of PowerShell like this to get an example response that you can paste into the Body field:
$response = Invoke-WebRequest "https://dan-function.azurewebsites.net/api/a_HelloWorld?code=PA1Twlk/anVrchlbKSZSvZcWQCawE5MjY2JcQ3s0/kMYqpnvI2WEMA==&Name=Dan"
# Show response in console
$response
# Copy response body to clipboard
$response.Content | clip
Now save your connector and go to the Test tab.
Under Connections, click New connection. Enter your function key when prompted (the long bunch of characters that appear after code= in a request URL).
When your connection has been created, return to the Test screen, and try out your function. You should hopefully see a familiar and reassuring block of JSON – greetings!
That’s it for now. Next time, we complete the package by adding our PowerShell function to a real life actual PowerApp.
Windows Terminal will accept icon files in .png and .ico format.
But it won’t read the icon from an .exe.
Variable expansion does not seem to work in the icon path (so no %APPDATA%… – it stops Windows Terminal from running entirely!)
I also show a couple of ways to detect that Windows Terminal is in use: the existence of an environment variable called WT_SESSION and the path of the process’ parent. Does anyone have anything else?
Do you know what else is kinda cool, but not very useful?
Hooking PowerShell Azure Functions into PowerApps.
This is part one of a probably-three-part series.
Part 1: Deploy your Function to Azure
Here we go!
The Azure Functions quickstart guide has you create a Function App from VS Code. I’m doing something slightly different, and deploying a function to an existing App, made in the Azure portal.
Remember to remove Wait-Debugger before you deploy!
It’s fun to watch the deployment commands scroll past. It looks like something called KuduScript is being used.
The Preview-ness shows in places. After you deploy a project from VS Code, you’re shown several options – but you can only pick one, because the dialog closes after a click.
And one of the options – Upload Settings – is potentially destructive. (It did warn me, and I did not heed. I had to delete and re-create my App.)
I invoked the function with Invoke-WebRequest,so that we can see the raw JSON. Note that – because of tweaks in the previous post – it’s also written to the log stream.
The Monitor page under your Function in the Azure portal shows similar information:
And you can even open a console in your function’s environment, right from the web interface. Apparently it’s running Windows 10 build 1607. Trippy!
Next time, we’ll create a PowerApps connector that talks to our pointless function – stay tuned!