Introduction

As announced during the Logic Apps Live webcast, the product team has released the concurrency control feature.  This feature is only available in code-view at the moment, but it will make it eventually to the designer.  I’ve requested this feature 9 months ago on UserVoice, so I’m very pleased to have this extra capability.

The main reason to limit the number of concurrent Logic Apps instances, is to avoid that backend systems are overwhelmed by too many requests.  Via this concurrency control, you can throttle the outbound connectivity to those backend systems, by limiting the number of parallel connections.  It’s important to be aware that this feature is only available for recurrence / polling triggers and that the resubmit function does not respect the configured limit, as described over here.

Please remark that concurrency control is also available for ForEach loops.  This is discussed more in depth in this blog post.

Scenarios

In this blog post, I discuss how you can configure this feature and what the runtime behaviour looks like.  For every configuration, I put 10 messages on a ServiceBus queue and check how fast they are processed by the Logic App.

Normal behaviour

In this scenario, I have a simple ServiceBus trigger that polls every 10 seconds for a message in the queue.  I simulate the processing with a Delay action of 5 seconds.

When the Logic App gets enabled, 10 new instances of the Logic App fire immediately.  The ServiceBus trigger has a Poll while data found behaviour, which means it keeps polling until there are no more messages left on the queue.  From that moment on, it will wait for the configured polling interval of 10 seconds.

Single instance behaviour

In the designer, you had already the ability to enable the Single Instance setting.  This is actually the same as limiting the number of concurrent instances to 1.

With this configuration, every 10 seconds, a message will be received from the queue.  This means there is no Polling while data found behaviour when we limit the number of concurrent instances.  This is a pity, I would have loved to see the messages being received every 5 seconds.

Just to verify that the singleton configuration works fine, I increase the Delay time to 15 seconds, which is higher than the polling time of 10 seconds.

With this setup, each 20 seconds a message is auto-completed from the queue.

Configurable concurrency

This sections shows how you can configure the maximum number of concurrent Logic App instances.  This code view snippet configures the polling trigger to fire a maximum of 2 concurrent instances.

...
   "recurrence": {
      "frequency": "second",
      "interval": 10
   },
   "runtimeConfiguration": {
      "concurrency" : {
         "runs": 2
      }
   },
   "type": "ApiConnection"
...

With a configured Delay of 5 seconds, each 10 seconds, 2 Logic App instances get fired.  Again no Polling while data found behaviour, similar to the Single Instance setting.

Feedback

During the testing of this feature, two suggestions for the product team popped up:

1. It would be great to have always the Polling while data found behaviour, even when there’s concurrency control configured.
2. With Azure Event Grid scenarios in mind, it would be great to have similar throttling capabilities for push triggered Logic Apps. Maybe as a Wait Until action, that pauses the workflow until the number of concurrent instances is again lower than configured. This might bring some engineering challenges, though.

Hope this blog post was enlightening!
Toon