Introduction

Tracked properties

As the documentation states:

“Tracked properties can be added onto actions in the workflow definition to track inputs or outputs in diagnostics data. This can be useful if you wish to track data like an “order ID” in your telemetry. “

Tracked properties can be added in code view to your Logic Apps actions in this way:

"trackedProperties": {
   "Flow": "Ordering",
   "Receiver": "Codit",
   "Reference": "@{triggerBody()['OrderId']}",
   "Sender": "@{triggerBody()['Customer']}",
   "Quantity": "@{triggerBody()['Quantity']}"
},

Outputs

As the documentation states:

“Outputs specify information that can be returned from a workflow run. For example, if you have a specific status or value that you want to track for each run, you can include that data in the run outputs. The data appears in the Management REST API for that run, and in the management UI for that run in the Azure portal. You can also flow these outputs to other external systems like PowerBI for creating dashboards. Outputs are not used to respond to incoming requests on the Service REST API. “

Outputs can be added in code view to your Logic Apps workflow in this way. Remark that you can also specify their data type:

"outputs": {
   "Flow": {
      "type": "string",
      "value": "Ordering"
   },
   "Receiver": {
      "type": "string",
      "value": "Codit"
   },
   "Reference": {
      "type": "string",
      "value": "@{triggerBody()['OrderId']}"
   },
   "Sender": {
      "type": "string",
      "value": "@{triggerBody()['Customer']}"
   },
   "Quantity": {
      "type": "int",
      "value": "@{triggerBody()['Quantity']}"
   }
},

Runtime behaviour

Do runtime exception influence tracking?

What happens if my Logic App fails? Are the business properties still tracked or are they only available in a happy scenario? After some testing, I can conclude the following:

• Tracked properties are only tracked if the appropriate action is executed.
• Outputs are only tracked if the whole Logic App completes successfully.

When using tracked properties, my advice is to assign them to the first action (not supported on triggers) of your Logic App, so they are certainly tracked.

Do tracking exceptions influence runtime?

Another important aspect on tracking / monitoring is the fact that it should never influence the runtime behaviour. It’s unacceptable that a Logic App run fails, because a specific data field to be tracked is missing. Let’s have a look what happens in case we try to track a property that does not exist, e.g.: “Reference”: “@{triggerBody()[‘xxx’]}”

In both cases the Logic App ends in a failed state, however there are some differences:

Tracked Properties

• The action that is configured with tracked properties fails.
• There is a TrackedPropertiesEvaluationFailed exception.

Outputs

• All actions completed successfully, despite the fact that the Logic App run failed.
• In the Run Details, an exception is shown for the specific output. Depending on the scenario, I’ve encountered two exceptions:

  The template language expression ‘triggerBody()[‘xxx’]’ cannot be evaluated because property ‘xxx’ doesn’t exist, available properties are ‘OrderId, Customer, Product, Quantity’.

  The provided value for the workflow parameter ‘Reference’ at line ‘1’ and column ’57’ is not valid.

Below you can find a screen capture of the workflow details.

This is not the desired behaviour. Luckily, we can easily avoid this. Follow this advice and you’ll be fine:

• For strings: Use the question mark operator to reference potential null properties of an object without a runtime error. In case of a null reference, an empty string will be tracked. Example: “Reference”: “@{triggerBody()?[‘xxx’]}”
• For integers: Use the int function to convert the property to an integer, in combination with the coalesce function which returns the first non-null object in the arguments passed. Example: “Quantity”: “@int(coalesce(triggerBody()?[‘xxx’], 0))”

Azure portal

The first place where issues are investigated is the Azure Portal. So it would be very helpful to have these business properties displayed over there. Tracked properties are nowhere to be found in the Azure Portal, but fortunately the outputs are displayed nicely in the Run Details section. There is however no option to search for a specific Logic App run, based on these outputs.

Operations Management Suite

In this post, I won’t cover the Logic Apps integration with Operations Management Suite (OMS) in depth, as there are already good resources available on the web. If you are new to this topic, be sure to check out this blog post and this webcast.

Important take-aways on Logic Apps integration with OMS:

• Only tracked properties are available in OMS, there’s no trace of outputs within OMS.
• OMS can be used to easily search a specific run, based on business properties
  • The status field is the status of the particular action, not of the complete run
  • The resource runId can be used to find back the run details in the Azure Portal

• OMS can be used to easily create reports on the tracked business properties
• Think about data retention. The free pricing tier gives you data retention of 7 days.

MANAGEMENT API

Another way to search for particular Logic Apps runs, is by using the Azure Service Management API. This might come in handy if you want to develop your own dashboard on top of Logic Apps.

The documentation clearly describes operations available to retrieve historical Logic Apps run in a programmatic way. This can be done easily with the Microsoft.Azure.Management.Logic library. Outputs are easier to access than tracked properties, as they reside on the WorkflowRun level. The following code snippet can serve as a starting point:

var cc = new ClientCredential("client-id", "client-secret");
var context = new AuthenticationContext("https://login.windows.net/<add your tenant-id>");
var token = context.AcquireTokenAsync("https://management.azure.com/", cc);

var client = new LogicManagementClient(new TokenCredentials(token.Result.AccessToken));
client.SubscriptionId = "subscription-id";

var filter = new ODataQuery<WorkflowRunFilter> { Top = pageSize };
IPage<WorkflowRun> allWorkflows = client.WorkflowRuns.List(resourceGorupName, workflowName, filter);

Unfortunately, the filter operations that are supported are limited to the ones available in the Azure Portal:

This means you can only find specific Logic Apps runs – based on outputs or tracked properties – if you navigate through all of them, which is not feasible from a performance perspective.

Conclusion

Comparison

Below you can find a comparison table of the investigated features. My current advice is to use both of them, as you’ll get the most in return.

Feedback to the product team

Monitoring is one of areas that needs some improvements to provide all we need for operating and monitoring an integration environment. Here are my feature requests in order of priority:

• Ensure outputs are also monitored in case a workflow run fails. Vote here.
• Provide OMS integration for outputs. Vote here.
• Extend the search filter in the Management API. Vote here.
• Provide a unique URL to directly redirect to a specific Logic App run.

Hope this post clarifies the monitoring capabilities of Logic Apps.

Feel free to vote for the mentioned feature requests!