When using a generic and decoupled integration design, your integrations span often multiple Logic Apps.  For troubleshooting purposes, it’s important to be able to correlate these separate Logic Apps with each other.  Recently, a new feature has been introduced to improve this.

Existing correlation functionality

• Let’s create a Logic App with a simple request trigger.

• Invoke the Logic App.  In the run history details, you will notice a correlation id.

• Now, update the Logic App to call another Logic App.

• Invoke the parent Logic App.  In their run history details, you will notice that they both share the same id. This is because Logic Apps automatically adds the x-ms-client-tracking-id HTTP header, when calling the child Logic App.  If this header is present, that’s the value taken for the correlation id.

• Your client application can also provide this HTTP header, so a custom correlation id is used.

• This results in these two correlation id’s:

Added correlation functionality

Upon my request, a new functionality has been introduced.  You can now configure in Logic Apps what value you want to use as the correlation id.  There might be two reasons to use this:

• Your solution contains already a certain correlation id, which you want to leverage inside Logic Apps for end-to-end correlation.
• Your solution spans multiple Logic Apps, with Service Bus in between, which currently makes you lose the correlation id on the way

Let’s give it a try.  This feature is currently only available in code-view.

• Consider a client application that sends an HTTP request that includes a custom correlation id

• Configure your Logic App trigger as follows, to take the custom HTTP header as the correlation id.  You can use any property from any type of connector or you could even look inside the message content.  Make sure you write your expression fault-tolerant, because the header might be missing.  That’s why the ‘?’ operation, coalesce function and guid() fallback are included.

"triggers": {
   "manual": {
      "correlation": {
         "clientTrackingId": "@{coalesce(triggerOutputs().headers?['x-my-custom-correlation-id'], guid())}"
      },
      "inputs": {
         "schema": {}
      },
      "kind": "Http",
      "type": "Request"
   }
}

• This results in the correlation id being taking from the custom HTTP header.

One more test that I would like to do, is passing a correlation id through Service Bus message properties.

• In the parent Logic App, I send the message to a Service Bus queue.  Remark that I include the correlation-id in the Service Bus message properties.

• In the child Logic App, we need to configure the trigger to take this Service Bus property as the correlation id.

"correlation": {
   "clientTrackingId": "@{coalesce(triggerBody().Properties?.correlationId, guid())}"
}

• Invoke the parent Logic App now with correlation header ‘correlation-654321’ and see that the correlation id is persevered, even when decoupled through Logic Apps.

It’s important to mention that this also works well when using a splitOn trigger.

"splitOnConfiguration" : {
   "correlation" : {
      "clientTrackingId" : "XXX"
   }
}

What benefits does this bring?

You might ask yourself what benefit this brings, certainly because the correlation id is somewhere hidden in the Azure portal and there’s no way to query it.  Well, when using the OMS monitoring solution this might become very valuable.  This cross Logic Apps monitoring experience allows you to search, based on the Tracking ID (which is the same as the correlation id).  Via this way, you can easily find all Logic Apps that participated in one message exchange, to track back the original message:

In case you might consume the standard logs that can be sent to Event Hubs, you can also benefit from this correlation.  All events include the correlation id:

Conclusion

A very small step for Logic Apps, but a huge step for our operations teams!  In a PaaS and serverless solution, it’s a crucial requirement to have end-to-end correlation across all different services.  This addition really helps to achieve that!

Based on these improvements, I have two small feature requests:

• Make the clientTrackingId available via the workflow definition language, so it can be easily passed into Service Bus properties or a file name.  This could look like @workflow.run.clientTrackingId
  [Update Oct 2020] This is now available.  Read more about it here.
• Make sure that the URL https://…/worfklows/{logicAppName}/runs/{runId} redirects to the monitoring details of a particular Logic Apps run.  This could make alerting a lot more efficient, because we can create direct links.
  [Update Dec 2018] This is now available.  Read more about it here.

Thanks for reading!
Toon