Introduction
The workflows you create in Azure Logic Apps begin with a trigger that kicks off the workflow and is followed by actions. Logic app connectors provide integrations with services. Connectors provide triggers and/or actions. For example, the Azure Blog Storage connector allows you to trigger workflows whenever a blob is added to a storage container and create, update, or delete blobs as actions. You can use the connector reference for documentation of all the supported connectors. In this Lab Step, you will use a built-in HTTP trigger and demonstrate a basic Azure Logic Apps workflow.
Instructions
1. Click Logic App Designer in the left navigation panel:
Notice that there is also a Logic app code view. The designer is a graphical interface that makes it easy to build logic app workflows. The code view allows you to edit the raw JSON that underpins the workflow you create with the designer. The code view allows you to include your workflows in source control systems and automate the creation of workflows. You will focus on using the designer in this Lab.
2. Read through the information the designer presents and scan through the common triggers and templates:
There are hundreds of triggers but the designer highlights a few of the more commonly used one. The templates allow you to quickly create common workflows with minimal effort. You can appreciate how powerful and easy it is to use logic apps after looking through the templates.
3. Click Blank Logic App + under Templates to start manually building out a workflow.
For the sake of this Lab, you will learn more by building a workflow from scratch rather than using a template.
4. Click the All tab to view all of the services connected to logic apps:
Many Azure services connect to logic apps and there are even more services outside of Azure. Many of the logic app connectors require you to sign in to external accounts. For this Lab, you will focus on workflows that don't require any external accounts.
5. Enter http in the search bar and click When a HTTP request is received in the bottom Triggers list:
The Request action allows you to trigger a workflow by sending an HTTP request to the URL assigned to the logic app. The trigger is added to the workflow canvas:
You can customize the request trigger by including a payload schema and other request details. You will modify the trigger to allow you to trigger the workflow simply by entering a URL into a web browser tab (an HTTP GET request).
6. Click Add new parameter, check Method, click outside the drop-down menu, and then select GET from the drop-down menu for Method:
7. Click Save:
Notice that the URL for the trigger is now available:
You can now use this URL to trigger the workflow, although the workflow doesn't have any actions configured at this point.
8. Click New step to add another step to the workflow:
9. Enter response in the search bar and select Response from the Actions list:
Response will send an HTTP response to the requesting client.
10. In the Body field enter Response from logic apps:
When you select the Body field, the Add dynamic content panel appears:
You can use dynamic content to customize the response content based on the request and other values. You will work with dynamic content later on.
11. Click on the upper-right points, and click on Settings:
12. Check the Asynchronous Response box and click on Done:
Note: This will avoid Azure to send the ActionResponseSkipped error when invoking the app from the Azure portal.
13. Click Save.
14. Copy the HTTP GET URL from the trigger and navigate to it in another web browser tab:
The browser sends the HTTP GET request and displays the contents of the response action that you configured. This workflow is about as simple as it gets but illustrates the basics of how to create workflows in logic apps.
15. Return to the designer view, and click Run in the upper command bar:
This gives you a way to run the workflow without leaving the Azure Portal. Wait until the following notice disappears:
and the result is displayed:
The green check mark indicates each step completed without error and 0s is the number of seconds each step took.
16. Click on each step to reveal the inputs and outputs to each step:
The Run view is a good place to debug more complicated workflows.
You can also click Code view if you are interested in seeing how workflows look in JSON code. Explaining the code is outside the scope of this Lab.
Summary
In this Lab Step, you created a basic workflow in Logic Apps using the designer. You learned how to trigger and test the workflow externally and within the Logic Apps blade in the Portal.
Working with Variables in Logic Apps
Introduction
You can use variables in logic apps to store and retrieve intermediate values. There are several logic app actions that work with variables. In this Lab Step, you will attempt to use variables to track the number of requests.
Instructions
1. Click Designer in the command bar to return to the designer view:
2. Mouse over the arrow connecting the two steps and click the plus (+) icon that appears:
3. Click Add an action in the drop-down menu:
4. Enter variable in the search bar and select Initialize variable from the list of Actions:
5. In the Initialize variable step, enter the following values to initialize a variable that tracks the number of requests received:
- Name: Requests
- Type: Integer
- Value: 0
6. Click the plus icon between the Initialize variable and Response step, and click Add an action:
7. Search for variable and click Increment variable from the Actions list:
8. In the Increment variable step, enter the following values to increment the number of requests received by one:
- Name: Select Requests from the drop-down menu
- Value: 1
9. Click the Response step to expand it and in the Body field append - request # and click the Requests variable in the Dynamic content Variables list:
The response will now include the request number as part of the content.
10. Click Save.
11. Click Run and wait for the view of the steps to appear.
12. Expand the Initialize variable and Increment variable steps and observe the value of the Requests variable incrementing:
13. Expand the Response step and observe the response includes the request number in the Body:
14. Return to the browser tab that is open to the workflow's request URL and refresh the page a few times to watch the request count increment:
Oops, the request count is stuck at 1. This is because variables in workflows only persist for the execution of each workflow run. To store state across workflow runs, you need to make use of a connector to a persistent storage service. You will do this in the next Lab Step.
Summary
In this Lab Step, you learned how to use variables in logic app workflows. You also observed that variables can only store values within a single logic app run.
Controlling the Actions Executed in Logic App Workflows
Introduction
To track the number of requests sent to the logic app workflow, you will use a connector to a database in this Lab Step. There are many available connectors you can choose from to persist variables. You will use Azure Table storage although other choices would work just as well for this simple workflow. Azure Tables is a NoSQL key-value store. You will be introduced to control flow structures that allow you to use conditions to decide which actions will run in the workflow. The following is the basic algorithm that you will implement in the workflow:
- Check if the table storing the number of requests exists
- If it exists, read the number of requests from the table
- If it does not exist, create the table and set the number of requests to zero
- Increment the number of requests
- Store the new number of requests in the table
Instructions
1. In your workflow Designer view, add a new Initialize variable action after the existing Initialize variable step and set the following values:
- Name: tableExists
- Type: Boolean (this is a variable type that can be only two values, either true or false)
- Value: false
The tableExists variable will record if the table exists or not. Later, you will decide whether to create a table or read the number of requests from the existing table using this variable. But first, you need to determine if the table exists.
2. Add a new action after the Initialize variable 2 step you just created, and search for list tables and select the List tables action:
You need to get a list of the tables in your Lab environment's storage account to determine if the table already exists.
3. In the List tables step, set the following values before clicking Create:
- Connection name: tables (this is an arbitrary name)
- Storage account: Select the only storage account listed (It will have a Name similar to calogiccal###. The Lab environment created the storage account when you started the Lab. It does not contain any tables yet)
You need to establish a connection to the storage account for the table actions to succeed. After a few seconds, a connection is established and the List tables step changes to the following:
This means the connection succeeded and the step will get the list of tables in the selected storage account. Now that you have the list of tables, you need to check if the list contains the table storing the number of requests.
4. Add a new action after the List tables step you just created, and search for control and click Control:
The available controls are listed:
Controls let you control which actions to run in your workflow. Some examples of controls are:
- Condition: Make a branching decision based upon whether a condition is true or now. For example, if the table is in the list, retrieve the requests value. If it is not in the list, create the table.
- For each: Perform an action for each item in a list. For example, for each name in a list, increment a variable.
5. Click Condition to design the branching decision about the table existing or not:
The condition is split into three parts:
- Condition which expresses the condition you want to check
- If true which runs if the condition is true
- If false which runs if the condition is false
6. In the Condition, set the following values to check if any of the tables in the list have a specific name (the name of the table storing the number of requests):
- Choose a value (left): Click the text box and select Table metadata Table Name from the dynamic content list:
- Choose a value (right): Enter logicapp as the name of the table you will use to store the number of requests.
When you selected the Table metadata Table Name value, logic apps automatically wrapped the condition in a For each because the table names are in a list, not a single value. Also, note that you can use several other operations besides is equal to and you can Add more conditions to check more complicated conditions.
7. In the If true step, click Add an action and add a Set variable action with the following values:
- Name: tableExists
- Value: true
After the For each control completes, the tableExists variable will be true if a logicapp table exists. Otherwise, the value will be false. There is no need to put any action in the If false step because the tableExists variable is initialized to false.
8. After the For each step, add a new condition with the following values set:
- Choose a value (left): Click the text box and select the tableExists variable from the dynamic content list:
- Choose a value (right): Enter true
9. In the If true step, click Add an action and search for table get entity before clicking the Get entity action:
Entities are the name of records/documents stored inside a table in Azure Tables. The entity you are interested in stores the number of requests.
10. In the Get entity step, set the following values:
- Table: logicapp (Click Use logicapp as custom value if prompted)
- Partition key: 1 (Each entity has a partition key that helps Azure Tables spread your data across nodes. It is not really important in this Lab)
- Row key: requests (The row key identifies an entity within a partition. The combination of partition key and row key must be unique within a table)
Note the Connected to tables message indicates that logic apps is automatically reusing the connection you made before. You now need to set the requests variable to equal the number of requests stored in the table.
11. Below the Get entity step and within the If true step, add a Set variable action:
12. In the Set variable step, set the following values:
- Name: Select Requests from the drop-down menu
- Value: @body('Get_entity')?['count'] (this code instructs logic apps to get the body of the Get Entity action, which will be the entity itself, and select the count property that stores the number of reqeusts)
Currently, you can't select the entity value from the Dynamic content selection because the table doesn't exist and because logic apps doesn't attempt to check for values within an entity that could be used to set the Requests variable (integer values). That is why you need to write a bit of code to access the count property of the entity which stores the number of requests.
13. In the If false branch of the condition, click Add an action and search for create table before clicking the Create table action:
14. In the Create table action, set the following value:
Now the logic is in place to create the table if it does not exist, or to read the number of requests from the table if it does exist.
15. After the Increment variable step, add a new Insert or Replace Entity action:
This action will insert the requests entity if it does not exist, or replace it if it already exists allowing you to update it's value.
16. In the Insert or Replace Entity step, set the following values:
- Table: logicapp (Click Use logicapp as custom value if prompted)
- Partition Key: 1
- Row Key: requests
- Entity: Enter the following
- First enter {"count":
- Then click the Requests variable from the Dynamic Content section
- Lastly, enter }
The Entity must be in JSON format which is why it needs to be written that way. The count property of the entity stores the number of requests. To review, a zoomed out view of the entire workflow is as follows:
17. Click Save.
18. Click Run.
The first time you run the workflow it will create the table and store the initial request count of 1. Once the run completes, you can see which branch was taken for the second condition by looking at the green checkmarks for the action that ran:
This run the table was created. You can also expand other actions to inspect their details.
19. Click Run again and observe the workflow took the other branch to Get entity and Set variable:
20. Expand the Get entity action to click Show raw outputs to see the raw JSON output of the action:
In the output you can see a "body" property that is the actual entity in the table:
Also, notice the "count" inside the "body" that is the number of requests. This output explains why you needed to write body('Get_entity')?['count'] when you set the value of the Requests variable in the Set variable action.
21. Expand the Response and observe the request count has been successfully incremented.
22. Return to your browser tab that is open to the workflow's Request URL and refresh the page a few times to verify the count now increments:
Summary
In this Lab Step, you used workflow controls to add support for storing the request count within Azure Table storage. In particular, you used the For each and Condition controls to determine if a table existed and what to do based on that. In the end, you have a useful workflow and have developed the skills to create and manage workflows using logic app connectors. Although you focused on Azure Tables, it is not difficult to start working with other connectors after gained experience with the Azure Table connector.
If you have time remaining in your Lab session, try to continue to extend the workflow on your own. As an example, instead of only sending an HTTP response, try also writing a file to blob storage at the end of the workflow by adding a parallel branch:
You can also explore the Versions section of the logic app blade and see that all versions of your workflow are saved and you can return to a previous version at anytime.
