• Home
  • About Us
  • Contact Us
  • Privacy Policy
  • Special Offers
Business Intelligence Info
  • Business Intelligence
    • BI News and Info
    • Big Data
    • Mobile and Cloud
    • Self-Service BI
  • CRM
    • CRM News and Info
    • InfusionSoft
    • Microsoft Dynamics CRM
    • NetSuite
    • OnContact
    • Salesforce
    • Workbooks
  • Data Mining
    • Pentaho
    • Sisense
    • Tableau
    • TIBCO Spotfire
  • Data Warehousing
    • DWH News and Info
    • IBM DB2
    • Microsoft SQL Server
    • Oracle
    • Teradata
  • Predictive Analytics
    • FICO
    • KNIME
    • Mathematica
    • Matlab
    • Minitab
    • RapidMiner
    • Revolution
    • SAP
    • SAS/SPSS
  • Humor

Monitoring the Power Platform: Power Automate – Run Time Part 2: Tracked Properties and Error Handling

June 11, 2020   Microsoft Dynamics CRM

Summary

 

Microsoft Power Automate is a service allowing makers to create business processes, orchestrations and workflows to help achieve common and even complex business requirements. Within the Power Platform, Power Automate represents one of the most important pillars of the platform. It provides a no to low code solution to process automation. From sending push notifications to mobile devices, to complex robotic process automation flows, Power Automate can be used in virtually any workload.

If you have not already reviewed Part 1 in the Power Automate Run Time series, please do so as this article is a continuation of previous installments. In this article we will discuss Tracked Properties and how they can be used across actions with a Microsoft Power Automate Flow. We will then look into handling and capturing error information within actions to help troubleshoot and report on failing actions or flows. Finally we will examine the Try, Catch, Finally pattern and result function for monitoring insights.

Action Tracked Properties

 

Tracked Properties are part of most actions within Power Automate. They provide the ability to add properties behind the scenes that can be referenced as part of the specific action. With tracked properties, we can set variables such as time stamps, capture trigger headers and outputs, action outputs, or even previous tracked properties from earlier actions. Expressions, such as “utcNow, outputs, actions” can be used to track what normally wouldn’t be stored in action inputs. Tracked properties are packaged within a node in the action and can easily be referenced, reducing clutter.

Action Headers Example

 

Consider the image below which shows capturing the status code and API throttle information for a List Records action in the Common Data Service (current environment) connector.

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

The example image below, where we are performing a ‘List records’ with the Common Data Service connector, now has a more friendly way of tracking the response code and API throttling response. This is a light weight example but should drive home the concept of how, using Tracked Properties, I can now reference the “TrackedPropertiesExample” variable which now includes outputs from a previous action.

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

NOTE: A key point here is that the action function will work for tracking current action data but not previous actions with the actions function. Attempting to do so will result in the “Tracked properties can only reference its own action’s inputs and outputs, trigger inputs and outputs and parameters.” error.

Timestamp Example

 

Using “utcNow()” as a tracked property for an action creates an interesting result. At first impression, we would be led to believe this may represent the start time of an action. However, when reviewing the output this function actually produces the end time exactly as if we were to reference it from the output of the action. Consider the below gif:

1122.pastedimage1591890792098v3 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

You can see that the five second delay is showing the tracked property “FiveSecondDelay” as the same timestamp as the endTime from the output!

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

Finally, as we look to Azure Logic Apps and what may come with Microsoft Power Automate, we can see how tracked properties work with monitoring solutions. Azure Logic Apps can connect to Azure Log Analytics natively to log logic app runs. One way to extend the information stored in the log store is to use Tracked Properties.

5280.pastedimage1591890792100v5 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

Handling and Capturing Errors in Actions

 

Typically Microsoft Power Automate flows will fail out if an issue occurs. Manually we can review these failures in the Power Automate Portal or with PowerShell. However inside the Power Automate flow we have the ability to track the statusCode within the actions function. Along with the Configure Run After setting we can conditionally capture any error messages and report or store for analysis.

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

Configure Run After

The Configure Run After setting allows the flow to continue if an error or timeout occurs. This can be used in conjunction with the below image showing a conditional based on status code of a previous HTTP request output body:

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

This documentation from Azure Logic Apps does a great job detailing the “run after” behavior. Each action is marked with a status of “Succeeded“, “Failed“, “Skipped” or “TimedOut“. The below image, from the Azure Logic App documentation, details how the “run after” behavior works in parallel branches.

3750.pastedimage1591890792101v8 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

Retry Policies

 

Retry architectural patterns are nothing new in our continually evolving, interconnected world of dispersed systems. In Robert Daigneau’s excellent book “Service Design Patterns”, he goes into great detail discussing various patterns. One such example to handle errors when connecting and processing integration requests and responses involving retry is the Idempotent Retry pattern. (pgs 206 – 212).

In the case of Microsoft Power Automate and Azure Logic Apps, we have a feature called Retry Policy which can be beneficial when working with integrations. Based on the status code returned (408, 429, 5xx, ect), the retry action can be configured to trigger a retry based on different intervals (Default, Exponential, Fixed). The default policy is to send up to four retries scaled by 7.5 seconds.

Mock Responses

 

Integration actions can simulate responses, which can be helpful to troubleshoot without invoking a live system or for designing error handling.

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

These simulated responses can be used, similar to mocks, when developing custom APIs and are quite useful when building custom connectors. The response can be successful, error prone, time out prone, etc based on the scenario. A specific status code and response can be added to help troubleshoot these specific scenarios.

The image below shows setting up a failed mock response and the many different error codes.

NOTE: Depending on what connector you’re using, you may not be able to use certain error codes.

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

The below image shows mocking a Common Data Service API throttled error response:

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

This image shows mocking a Common Data Service Too Many Concurrent Requests error response:

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

Finally, the below image shows the run history and capturing the error response from the Common Data Service:

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

Throttling with Azure Logic Apps

 

Throttling in Azure Logic Apps has many facets and can stem from all sorts of potential areas. Connectors can be throttled, destination APIs can be throttled and depending if you’re running in an integration service environment (ISE) or not can impact that. Consider the following documentation in detail when deciding an implementation approach with Azure Logic Apps. Scenarios such as dealing with Azure Service Bus queues are thoroughly examined (e.g. using nested logic apps…this technique will work for Microsoft Power Automate as well!)

Webhook Tester Site and runtime debugging

 

The below reference and steps are taken from the Azure Logic Apps document “Diagnosing Failures”. This technique of using the Webhook Tester site for debugging run time integrations is very useful. An added benefit is that the Webhook Tester site allows for both cloud and local based (e.g. Docker containers, Virtual Machines, etc).

To help with debugging, you can add diagnostic steps to a logic app workflow, along with reviewing the trigger and runs history. For example, you can add steps that use the Webhook Tester service so that you can inspect HTTP requests and determine their exact size, shape, and format.

  1. Go to the Webhook Tester site and copy the generated unique URL.

  2. In your logic app, add an HTTP POST action plus the body content that you want to test, for example, an expression or another step output.

  3. Paste your URL from Webhook Tester into the HTTP POST action.

  4. To review how a request is formed when generated from the Logic Apps engine, run the logic app, and revisit the Webhook Tester site for more details.

     Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

For more information, review the documentation here.

NOTE: This tool is useful for testing outside of Power Automate including any resource that has HTTP Post capabilities, examples including Azure Functions and GitHub Web hooks!

Scopes and the Try, Catch, Finally Pattern

 

Using scopes, actions can be linked together in a logical group allowing for evaluation of multiple actions as a whole. This comes into play when working with exception and error handling. Scopes provide statuses similar to Power Automate flows or Logic Apps themselves such as “Succeeded“, “Failed“, “Cancelled“, etc. Pieter Veenstra has a really nice approach, “Get the result of your failed actions in Power Automate” for using scopes to implement a Try, Catch, Finally pattern which i’ll discuss below.

In the image below are three scope objects titled “Try“, “Catch” and “Finally“.

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

From a recent flow run, expanding the Try block, we can see two successful actions followed by our mocked failed response from the Common Data Service:

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

The Catch scope underneath the Try scope is using the run after property of the Try scope to catch results with a status of “Failed”. If any actions inside the Try scope, at least how this example is configured, fails, the Catch scope will begin processing. The remaining actions within the Try scope are not processed.

Below is an image of the Catch scope with Tracked Properties:

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

To work with the Try scope within the Catch scope, we will use the results function which provides context to what happened within the Try scope.

Result Function

 

The results() function, as shown in the reference link, returns an array object. At first glance this seems fairly straight forward until we dig deeper into the context of the results output. The actions returned with the results function include the standard properties listed in Part 1 such as start and end time and tracking identifiers. You’ll also see that they include properties indicating if they were successful or not.

The image below shows a successful action named “successful_try_action” and a failed action named “Condition”. Each action includes two properties, code and message that can be used to filter the array. The successful action is in green while the failed action is in red.

 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

Finally, the below gif shows working with the Try, Catch, Finally pattern and scope and results objects to capture and report. This technique can be continued to then send data to Azure Application Insights or Azure Log Analytics as briefly shown below. I’ll cover this in an upcoming article!

7737.pastedimage1591890792104v19 Monitoring the Power Platform: Power Automate   Run Time Part 2: Tracked Properties and Error Handling

Next Steps

 

In this article we have discussed tracking properties across actions to help supplement reporting. When examining error handling and preparing for designing resilient Microsoft Power Automate flows we examined various patterns. Utilizing retry policies, configuring the run after conditions and implementing scope can all help build an enterprise ready flow.

In previous articles, we discussed how to evaluate workflows, triggers and run functions to help deliver insights. In the following articles covering Microsoft Power Automate Flow run time, we will discuss pushing events to Application Insights and reviewing previous flow runs for monitoring and governance.

If you are interested in learning more about specialized guidance and training for monitoring or other areas of the Power Platform, which includes a monitoring workshop, please contact your Technical Account Manager or Microsoft representative for further details.

Your feedback is extremely valuable so please leave a comment below and I’ll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, please go here to submit a new issue.

Index

 

Monitoring the Power Platform: Introduction and Index

Let’s block ads! (Why?)

Dynamics 365 Customer Engagement in the Field

Automate, Error, Handling, monitoring, Part, Platform, Power, Properties, Time, Tracked
  • Recent Posts

    • 5 CRM Marketing Tips to Use as Resolutions for 2021
    • Sidney Poitier To Get A School Named After Him
    • Using Power Automate to Automatically Move Your Email Attachments to SharePoint
    • Why it’s time for fintechs and FIs to jump on the open banking bandwagon (VB Live)
    • Integrating a function with integration limits also dependent on a variable
  • Categories

  • Archives

    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • March 2020
    • February 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    • December 2016
    • November 2016
    • October 2016
    • September 2016
    • August 2016
    • July 2016
    • June 2016
    • May 2016
    • April 2016
    • March 2016
    • February 2016
    • January 2016
    • December 2015
    • November 2015
    • October 2015
    • September 2015
    • August 2015
    • July 2015
    • June 2015
    • May 2015
    • April 2015
    • March 2015
    • February 2015
    • January 2015
    • December 2014
    • November 2014
© 2021 Business Intelligence Info
Power BI Training | G Com Solutions Limited