In the first article in this series, I wrote about building PowerApps from the custom data sources using Azure API Apps. But, since the built-in expression language in PowerApps is not particularly powerful (number of events and methods available is pretty limited), and since there is no possibility of building any kind of code behind, or JavaScript field behaviors within PowerApps (which I see as huge drawback potentially), the only way to extend its functionality is building custom APIs.
Two recommended – and supported – ways, of how to do that, are Azure API Apps, and Azure Functions. While Azure Functions are lighter, easier and faster to develop and deploy, it often makes sense to use API Apps for that purpose, especially if there is already an API App in place, which provides a custom data source (as shown in the previous article). In that case, it is very easy to add an additional controller to that API App, and to use that for extending the expression language.
This is exactly what we are going to do in this article. We want to create a method, which accepts one string argument (name of the beer), and returns the string value, which determines if the beer is good or not.
Let’s open the BeerAPI API App, which we have created in the previous article, and add an empty controller to it:
We will call out controller “BeerQualityController”
And we will add one GET method, with one string argument in that method. In our simplified code here, we will declare all beers as good, except of course Heineken, which anyway can’t be considered as a real beer:
Let’s save it, build it, and try it with swagger UI:
Great, it works as expected. Once we are done with that, we will need to republish the API App to Azure, and to recreate the custom API Definition in PowerApps. No, updating swagger definition is not supported in PowerApps, so, yes, you will have to delete the whole API, and to recreate it again.
Once you have done that, you can start using this controller in PowerApps.
For test, let’s create an empty screen with two text boxes – “txtBeerName” and “txtBeerQuality”, and a button. We will set the “txtBeerQuality” source to the variable “BeerQuality”, and on the button click we will do the following:
UpdateContext({BeerQuality:BeerApi.BeerQualityGet(txtBeerName.Text)})
This command sets the value of the “BeerQuality” variable, to the value that out controller returns for the name of the beer, set in the “txtBeerName” text box.
Type “heineken” in “txtBeerName”, click on the button, and you will see that “txtBeerQuality” value has been set to the appropriate text we’ve got for “heineken”.
Summary
Since there are no possibilities to extend the business logic beyond built in expression language in PowerApps, this is the way how to simulate that “code behind” behavior. You need to delegate your code – your business logic – to some type of the API. In order to do that, you will either have to make custom controllers in API Apps (as explained here), or use Azure Functions, what we are going to cover in the next article in this blog post series.
