Select Page

Hands-on with Azure Logic Apps, Liquid Templates, and the Power Apps Web API

by | Feb 13, 2020 | Power Apps | 0 comments

Are you a Power Apps developer who deals with system integration needs across a business? Someone who works with JSON, or other data formats, and has found yourself in a position where the standard functions (Compose, ParseJSON) just don’t provide enough functionality and you need something more powerful? On top of that, you don’t want to start writing C# code for plugins, Azure Webjobs, or even Azure Functions? This might be the blog for you. In this blog I take a low-code approach to system integration using Microsoft Power Apps, Azure, and Liquid templates.

This blog intends to demonstrate the following:

  • Power Apps integration with other systems through the use of an Azure Service Bus and an Azure Logic App
  • Use of the Power Apps Web API through a Logic App
  • Transformation of data using Liquid Templates for preparing data to be sent in a Web API call

Here are the steps used to complete this exercise:

Identify the schema. For this blog we are going to simulate new contact data coming in from a different system, then processing that with our Logic App and inserting the data into Power Apps. We will use out-of-box Contact fields for everything except a SSN and Drivers License Number.

Here are the fields we’ll be using for this exercise.

These are the actual Power Apps schema names we’ll use.

Create an Azure Service Bus and Queue. Other systems around the enterprise can send messages here. The Azure Logic App will monitor this queue and process messages.

Azure Service Bus configured with a single queue called core-queue.

Create a console app. This app will be used to push data to an Azure Service Bus (queue), essentially simulating the other systems sending messages for our Logic App to process. You can follow the steps here to accomplish this.

Here you can see the simple code written to simulate another system putting a message onto our queue in Azure.
Here is the data we’ll use in our payload to the queue. You can see this broken out into one long string with double-quote delimiters in the C# code.

Create an Azure Integration Account. This will be used to store our Liquid Template and provide transformation services. You can follow the steps here to accomplish this.

Here is the overview for our Azure Integration Account. Please note that I have already uploaded a Liquid template to the “Maps” component as you see in the screen shot.

Create a Liquid Template. This will provide the transformation instructions so we can control how our data will look once the transformation is complete. You can check out how to do this, and add it to the Azure Integration Account, here. In the screen shot below you’ll see the template using Visual Studio Code with the Liquid Languages Support extension. You should notice a couple of things here…

  1. The “message” and “contact” variables at the top, designated by the assign keyword, and how they map to the JSON above in our test data.
  2. The field names on the left at the bottom. Those are our internal Power Apps field names.
  3. The result of this transformation is an output that we can simply drop into the body of a Web API call to Power Apps. If you look at the second screen shot in Cmdr using the local Liquid Template tools, you can see the output of the transformation that used the above JSON as input, and the template below for the transformation.
Our Liquid template that will be used to transform the JSON we saw above, into what we see below so that it is ready for the Power Apps API call.
Using our local Liquid tools, our template, and a console to test the template before we upload it to our Azure integration account.

Create our Azure Logic App. Here we’ll create a very simple Logic App that monitors our queue, then uses the Azure Integration Account we set up above to transform incoming data and ultimately pushing that data into our Power Apps database.

The first thing we need to do is make sure that we’ll be able to make API calls against our Power Apps API from the Logic App. That means we need to set up an App Registration in Azure, for our Power Apps environment. There are posts out there on how to do this, but often times the App Registrations for services in the same tenant will already be ‘mostly’ set up for our needs. In the App Registrations screen shot below, you can see that there is a registration for the Microsoft Common Data Service. If there is no green checkbox under the Certificates & secrets column, simply click into the App Registration and add a new client secret.

Azure App Registrations already configured because they are in the same tenant as my Power Apps environment. You can see that the Microsoft Common Data Service has current Certificates and secrets.
Clients and secrets pane for our Common Data Service app registration.

Once the app registration is complete, you’ll want to either set up an Application User in your Power Apps environment, or set up API permissions on your App Registration in Azure. You can read about the latter of those options here, for this write-up though we’ll use an Application User in Power Apps. Use the information from the App Registration Overview area in Azure to fill in the values needed for the new Application User.

Once the Application User has been created, make sure to assign it a Security Role. For demo purposes I’m just assigning mine the System Administrator role, although you should never do this in a live system.

Our Application User in Power Apps.

When you first select to create a new Logic App, you can select from several different common triggers. We are going to select “When a message is received in a Service Bus queue”.

Choosing a common trigger when starting our Logic App development.

Assuming you haven’t set up a connection yet, we’ll first set up a connection through the Service Bus trigger step. Give the connection a name, then select the name of the Service Bus Namespace that you want to use for this Logic App. The available namespaces should be listed in the step.

Setting up our Service Bus connection. The available Service Bus Namespaces should be listed automatically so you can provide a Connection Name and choose a namespace.

After you select the namespace, you should see the Service Bus Policy associated with that namespace. Go ahead and select that and then click Create.

Select the Root Shared Access Key for your Service Bus Policy.

Once the connection has been created you’ll want to select the queue you want your trigger to monitor and how often you want the Logic App to check the queue for messages. Make sure to save the Logic App once complete.

Select the queue you want to use, provide an interval, and save the Logic App.

Now we want to add a variable (Initialize Variable step) as an object type, and set the value to the body of our message that our Logic App just picked off of the queue. Because the message is encoded upon arrival, we’ll need to use a function in our value setting.

json(base64ToString(triggerBody()?[‘ContentData’]))

Here we are initializing our message-content variable as an Object, and assigning the decoded JSON to the variable. The “Value” uses the Function you see above the screen shot that begins with json(… .

Next we want to add our Liquid Transform JSON to JSON step. Yes… Azure has an out-of-box step for this!

Adding our Transform JSON to JSON action to our Logic App.

If you receive this error that says “There is no Integration Account associated with this Logic App”, fear not. Simply remove that transform step from the Logic App, save the Logic App, and go back to your Logic App’s Workflow Settings to set the Integration Account that your Logic App should use.

If you haven’t assigned an Integration Account to your Logic App you will receive this error when trying to choose a Map from the Transform JSON to JSON action.
Our Workflow Settings for the Logic App. Select the Integration Account we created earlier.

Once you’ve set the Integration Account on the Logic App, you should be able to pick the Liquid ‘map’ that you set up with the Integration Account. Last thing to do on this step is to set the Content parameter to the message-content variable we initialized above.

Select the Liquid template that we uploaded to Maps in our Integration Account earlier.

Finally we add our HTTP step. Set the URI to the Web API contacts URI as seen in the screen shot. Then you’ll want to add the Headers parameters for “Accept”, “Content-Type”, “OData-MaxVersion”, and “OData-Version”. Set the Authentication type to Active Directory OAuth, and use the Tenant and Client ID GUIDs from the App Registration in Azure, and use the Secret from the App Registration that you should have copied when it was first created. Use the “Transformed content” for the Body.

Setting up our Power Apps Web API call through the HTTP POST action.

Finally, save the Logic App and head back to our console app that we created so we can send our Logic App its first message.

Here you can see we have a running instance of our Logic App. That means that our console app successfully sent a message to our queue, and our Logic App trigger fired successfully.
If you used the code in my console app above, you should see something like this in your console window showing the JSON it’s sending to the queue.

Now let’s take a look in our Power Apps database for our new record.

Here you can see the HTTP POST was successful and we have a new contact record in our Power Apps database.

I hope this was helpful in demonstrating just another way we can perform system integration with Power Apps and other systems, while using some other cool technologies. Feel free to hit me up if you have any questions.

Submit a Comment

Your email address will not be published.