Track Issues in Logic Apps/Flow using Correlation Id

 Previously I have written some blog post, like this one, showing how easy it is to create API endpoints in Flow and Logic Apps. This involves creating a workflow that gets triggered by an Http Request with a Json payload.  There are asynchronous “fire and forget” API calls and the calling process receives a 202 response code to indicate the workflow has been triggered. When the workflow runs it may call a number of actions across different connectors. Because it is asynchronous the calling process has no idea if the workflow has run successfully or if any actions have failed.

In this scenario tracking down issues and linking them to a specific API request can be difficult especially in a high throughput environment. There is a software pattern called the Correlation Identifier Pattern we can adopt to make these scenarios more supportable. The Correlation Identifier Pattern advises generating a unique identifier called a Correlation Id for each request. The Correlation Id then gets passed to each of the request’s action. That way any action’s success or failure can be traced back to the specific calling request.

We can adopt this pattern easily in Logic Apps and Flow as each workflow run generates a unique Run Id. The Run Id is also known as the Identifier or Correlation Id depending on which portal page you are on.  The calling process can acquire the Run Id from the response header tagged x-ms-workflow-run-id and log it as required with their request. 

When you view the run history for a Logic App workflow you can see the all the runs with their identifiers. The Run Id also get passed to any child workflows so you trace it across these as well.

You can access the Run Id from your workflow and use it in your actions.  In the workflow designer you can use the expression workflow().run.name to the get the Run Id. In my example I added a custom field to the CDS contact entity called Correlation Id, which I populate with the Run Id.

I also added the field to contact form’s footer.

Just one thing to note that is you can use this technique in Flow however the Runs Id are not displayed on the Runs details screen so you need to log the Run Id elsewhere as part of the workflow.

Now when you partner calls support enquiring about an API call problem they can use the Run Id to track exactly what happened.

Force Rollup Column Calculation in Power Automate

 Rollup columns have been around since the dawn of time CRM. They are a great way to aggregate data across a hierarchy of data such as totals, averages, maximum and minimum, but they come with some limitations too. The shortest delay between each rollup calculation in the system is one hour, which is defined on a per column basis. In many cases this is sufficient, but sometimes you may want to force this recalculation after a change has been made which affect the roll up total.

Recalculating the column for all the rows in the table can have performance implications for large data sets and is often unnecessary. Instead we can recalculate a specific rollup column for a specific row automatically in Power Automate. How you trigger this depends on the scenario but all scenarios will be triggered by a record change in Dataverse of course.

• When an Opportunity is won - recalculate Account ‘Actual Revenue’

• When a Contact is Associated to an Account - recalculate Account ‘Number of Contacts’

• When an appointment is marked complete, regarding an Opportunity - update Opportunity ‘Last Appointment Date’

Compose the request URL

We need to build the GET request URL which looks like this, replacing everything *Inside these*:

https://*environment_url*/api/data/v9.1/CalculateRollupField(Target=@tid,FieldName=@field)?@tid={'@odata.id':'*entity_set_name*(*row_uniqueidentifier *)'}&@field='*logical_column_name*'

Environment URL

Odata from ‘Get a row’ or ‘Add a new row’

uriHost(outputs('Action_Name')?['body/@odata.id'])

Odata from ‘List rows’

urihost(body('List_Rows_Action_Name')?['@odata.context'])

OData from ‘When a row is added, modified or deleted’

Not available, use a get row action after the trigger instead, ensuring you use ‘Select columns’ and enter the Uniqueidentifier column name (e.g. contactid or aeh_tableid), the @odata.id will always be returned in a get/list rows action even when not selected.

Entity Set Name

The plural name of the table, usually an ‘s’ or ‘ies’ on the end of the logical name e.g. ‘contacts’ or ‘accounts’

Row Uniqueidentifier

This will be an input based on wherever your flow is triggered from e.g. d1a757d9-f993-4617-b968-ec5d7e3fe98c

Logical Column Name

The name of the column that includes a prefix and all lowercase

GET request ‘CalculateRollupField’

To trigger the rollup calulation we need to use a HTTP Request. Make sure you choose the ‘Invoke an HTTP request’ for ‘HTTP with Microsoft Entra ID (preauthorized)’. To create the connection you just need to enter your dynamics 365 url in both the Base resource URL and the Resource URI e.g. ‘https://ameyholden.crm.dynamics.com/’

Set the Method as GET and use the outputs from your compose step above as the ‘Url of the request’.

The end - happy rollup-ing!

No lock and distinct conditions in query expression

 

Hi Folks,

Whenever i tried using query expression for retrieve multiple operations, came to know some interesting facts which exists and hence would like to share with you all.

As you already know Query expression was used when dealing with a little complex query, lets see this in action

Basic Query Expression Example

// Query using ConditionExpression and FilterExpression

ConditionExpression condition1 = new ConditionExpression();

condition1.AttributeName = "lastname";

condition1.Operator = ConditionOperator.Equal;

condition1.Values.Add("Brown");

FilterExpression filter1 = new FilterExpression();

filter1.Conditions.Add(condition1);

QueryExpression query = new QueryExpression("contact");

query.ColumnSet.AddColumns("firstname", "lastname");

query.Criteria.AddFilter(filter1); query.NoLock = true;//Condition to prevent occurrence of deadlocks, distinct was used to retrieve unique columnsets in the query

EntityCollection result1 = _serviceProxy.RetrieveMultiple(query);

view raw

QueryExpressionCondition.cs

hosted with  by GitHub

The benefit of setting NoLock to true is that it allows you to keep the system from issuing locks against the entities in your queries; this increases concurrency and performance because the database engine does not have to maintain the shared locks involved. The downside is that, because no locks are issued against the records being read, some “dirty” or uncommitted data could potentially be read. A “dirty” read is one in which the data being read is involved in a transaction from another connection. If that transaction rolls back its work, the data read from the query using NoLock will have read uncommitted data. This type of read makes processing inconsistent and can lead to problems. The risk of having “dirty” data is something to consider, especially in high database transaction environments.

Reference: https://msdn.microsoft.com/en-us/library/microsoft.xrm.sdk.query.queryexpression.aspx 

How to Call an Action through Power Automate(MS Flow)

 Introduction

As Microsoft is providing us more flexibility with Power Automate (MS Flow), recently we found that now we can call the Action through Power Automate (MS Flow) directly. Previously we used to call an Action through HTTP request, but now we can directly call an Action through the Power Automate (flow) steps.

Before that take a short look at what are Bound and Unbound Action?

Bound Action are targeted to the entity and Unbound Action are not bound to the any entity, they are Global.

To get the Bound and Unbound actions in Power Automate (MS Flow) follow the steps given below:

1. Create a solution in https://make.powerapps.com/ where you have to add your Power Automate (Ms Flow) which we are going to use to call Actions.

2. In the solution click on new button & select Flow as shown in below image. Apparently it will redirect you to Power Automate (MS Flow) window as shown in the following image.

3. Now we have to Search for Common Data Service Trigger point in our newly created Flow & from the search result select the Common Data Service (Current Environment).
Select the trigger conditions as per requirements such as Create, Create or update, Delete, Update etc.

4. Now in the next step we have to search for the action & select the Common Data Service (Current Environment). You will get many new action points in the results from that we have to select Bound/Unbound Action.

For the bound action you will see the Action step as shown in below image. In my case I have selected the QualifyLead action which is bounded with the Lead entity.

And for unbound step you will get to see the below window in which you can call your global action or the action which is not bounded with the any entity which will be listed in the unbound action.

Conclusion

As illustrated above, you can now directly call an Action through Power Automate (MS Flow).