Deprecated: YoastSEO_Vendor\Symfony\Component\DependencyInjection\Container::__construct(): Implicitly marking parameter $parameterBag as nullable is deprecated, the explicit nullable type must be used instead in /home/nubelus/sharedove/adisjugo/wp-content/plugins/wordpress-seo/vendor_prefixed/symfony/dependency-injection/Container.php on line 60

Deprecated: YoastSEO_Vendor\League\OAuth2\Client\Provider\AbstractProvider::authorize(): Implicitly marking parameter $redirectHandler as nullable is deprecated, the explicit nullable type must be used instead in /home/nubelus/sharedove/adisjugo/wp-content/plugins/wordpress-seo/vendor_prefixed/league/oauth2-client/src/Provider/AbstractProvider.php on line 416

Deprecated: YoastSEO_Vendor\GuzzleHttp\Client::getConfig(): Implicitly marking parameter $option as nullable is deprecated, the explicit nullable type must be used instead in /home/nubelus/sharedove/adisjugo/wp-content/plugins/wordpress-seo/vendor_prefixed/guzzlehttp/guzzle/src/Client.php on line 181

Deprecated: YoastSEO_Vendor\GuzzleHttp\ClientInterface::getConfig(): Implicitly marking parameter $option as nullable is deprecated, the explicit nullable type must be used instead in /home/nubelus/sharedove/adisjugo/wp-content/plugins/wordpress-seo/vendor_prefixed/guzzlehttp/guzzle/src/ClientInterface.php on line 77
{"id":3660,"date":"2018-12-01T00:00:00","date_gmt":"2018-12-01T00:00:00","guid":{"rendered":"https:\/\/blog.sharedove.com\/adisjugo\/?p=3660"},"modified":"2019-03-02T12:58:57","modified_gmt":"2019-03-02T12:58:57","slug":"extending-powerapps-and-flow-part-2-extending-powerapps-expression-language-with-azure-api-apps","status":"publish","type":"post","link":"https:\/\/blog.sharedove.com\/adisjugo\/index.php\/2018\/12\/01\/extending-powerapps-and-flow-part-2-extending-powerapps-expression-language-with-azure-api-apps\/","title":{"rendered":"Extending PowerApps and Flow, part 2: Extending PowerApps language with Azure API Apps"},"content":{"rendered":"

In the first article in this series, I wrote about building PowerApps from the custom data sources using Azure API Apps<\/a>. 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.<\/p>\n

Two recommended – and supported \u2013 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<\/a>). 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.<\/p>\n

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.<\/p>\n

Let\u2019s open the BeerAPI API App, which we have created in the previous article, and add an empty controller to it:<\/p>\n

\"016\"<\/a><\/p>\n

We will call out controller \u201cBeerQualityController\u201d<\/p>\n

\"017\"<\/a><\/p>\n

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\u2019t be considered as a real beer:<\/p>\n

\"018\"<\/a><\/p>\n

Let\u2019s save it, build it, and try it with swagger UI:<\/p>\n

\"020\"<\/a><\/p>\n

 <\/p>\n

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.<\/p>\n

Once you have done that, you can start using this controller in PowerApps.<\/p>\n

For test, let\u2019s create an empty screen with two text boxes \u2013 \u201ctxtBeerName\u201d and \u201ctxtBeerQuality\u201d, and a button. We will set the \u201ctxtBeerQuality\u201d source to the variable \u201cBeerQuality\u201d, and on the button click we will do the following:<\/p>\n

UpdateContext({BeerQuality:BeerApi.BeerQualityGet(txtBeerName.Text)})<\/span><\/p>\n

This command sets the value of the \u201cBeerQuality\u201d variable, to the value that out controller returns for the name of the beer, set in the \u201ctxtBeerName\u201d text box.<\/p>\n

Type \u201cheineken\u201d in \u201ctxtBeerName\u201d, click on the button, and you will see that \u201ctxtBeerQuality\u201d value has been set to the appropriate text we\u2019ve got for \u201cheineken\u201d.<\/p>\n

\"032\"<\/a><\/p>\n

Summary<\/h3>\n

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 \u201ccode behind\u201d 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.<\/p>\n

\n\t\t\t
\n\t\t\t <\/div><\/div>\n\t\t