In the previous two articles of this blog post series, we have seen how to utilize Azure API Apps to connect to external data sources, and how to utilize the same app to extend limited PowerApps expression language with additional value controllers.
But sometimes, if we really want to do something simple, an Azure API App can be an overkill, from development, deployment and management perspective. If we remember that use case from the last post, where our only goal was to check if the beer name contains the word “Heineken”, we obviously don’t need an Azure Api APP for that. It’s just one IF clause, after all. For that, Azure Functions might be a way to go.
Azure Functions are a great vehicle for hosting small, single-tasked pieces of code. Since they run on hamsters, we will call it the “serverless computing”. Basically, you can log in to your Azure portal, or go to functions.azure.com and start writing your code in a web editor. There is a number of programing languages, plus JavaScript, available to use. If you are not into web editors for writing code, you can use anything you wish, and store your function code on GitHub or VSTS, with continuous integration. Since recently, there are also Visual Studio Tools for Azure Functions available. Those Visual Studio tools are at the moment still in preview and they they require VS2015 U3 with Azure SDK installed. There are quite some bugs still there, but – this is only a preview, and it will, probably, get better with the time.
In this blog post, we’ll make a walk-trough using Visual Studio 2015 Update3 and VS Tools for Azure Functions, to create and deploy a function, and to reuse it in the PowerApp that we have built in the previous two articles.
So let’s start with creating a Visual Studio project! After installing all the prerequisites, you should have the “Azure Functions (Preview)” project available among the Cloud projects.
After creating an empty Azure Function project, you’ll need to add a new Azure Function from the “Add” context menu in the solution explorer:
The next you will need to choose the programming language, and the function type. I’ll choose C# (there are many other choices), and “HttpTrigger” function trigger. Note that functions can be triggered on many different ways – we have webhooks, queues, integration with Azure Service Bus, timers, and many, many other possibilities. In our case, HttpTrigger is what we need.
Choose the Authorization level. I’ll take “Anonymous” here, for the sake of simplicity. You can of course choose “Function”, “Admin”, and provide function or master admin keys which you can create in Azure Portal (later about it). Furthermore, since Azure Functions are based on Azure App Service platform, you can also choose some of the supported Authentication mechanisms there, like AAD, Microsoft Account, Facebook etc, which might be a valid scenario when you want to fetch some SharePoint data, but I will cover that in another article, since PowerApps are anyway not (yet) able to pass authentication tokens, and cannot be used for that scenario.
Once we’re done with that, let’s code our function. We’ll make the same use case as in the last article – check if the name parameter (from the request) contains string “HEINEKEN”, and we’ll return our result in the response variable.
You can build, and publish your function.
If you go to your Azure portal, and open that same function there, you will se that you can even edit your code manually inside the portal. Be aware that there is no version control, or rolling back of your code there, so whatever you do in the portal will change the previously published function.
In the “Integrate” tab, we can change the authorization level here, from Anonymous to Function or Admin.
If we do, we can get our default keys, or create new ones, in the “Manage” tab.
OK, once we’re done with that, let’s try the function. If we pass the the value “Heineken” to the name parameter in the query string, we see that our function works as expected:
If we go to the “Monitor” tab of our function, we can see all the details about it’s invocation and results:
The next we need to do is to create the swagger definition for our function. You remember: PowerApps want swagger. My preferred swagger creation tool (no, I do not like creating it manually) is:
You can even try you function there, and everything. My operation is called “RunThis”, this is what I will be calling in PowerApps.
Pay attention, that if you have used any other authorization than anonymous (Function, Admin), you’ll have to pass another parameter in your GETter operation:
{
“name”: “code”,
“in”: “query”,
“description”: “code”,
“default”: “[enter function/admin code]”,
“type”: “string”
}
NOTE: I am not a fan of storing keys in the configuration files which are uploaded some management portal. I don’t think that is a good security solution, from all many reasons. One of the major reasons is that a connection created on such a way can be reused by everyone who has rights to create apps in this environment, so that authorization looses its purpose immediately. But, for the moment, its either that, or no authorization at all.
Once we’ve created the swagger definition, let’s upload it to the PowerApps (with or without key), the same way we have uploaded swagger for Web APIs published as Azure API Apps:
Here we have no other choice but to select “No Authentication”:
There is our custom API:
We can add it as a data source in the PowerApps designer:
And use it in the PowerApp itself, the same way we have used it for the API Apps:
UpdateContext({BeerQualityAzureFunction:BeerQualityAzureApp.RunThis(txtBeerName.Text)})
With the expected result for the given beer: 
