Logic Apps event grid consumption

Question

Logic Apps event grid consumption

Henrik Holst 1

Hi

By default, Logic App instances run at the same time, or in parallel. This control changes how new runs are queued and can't be changed after enabling.
To run as many parallel instances as possible, leave this control turned off. To limit the number of parallel runs, turn on this control, and select a limit. To run sequentially, select 1 as the limit.

What will happen if the trigger is an Azure Event Grid event (say a BLOB CREATE event). Will all those events be queued in an Azure Logic Apps queue implicitly or how are the overflow handled if not all events can be concurrently handled by the Logic App instance? If the events are stored in an internal azure Logic Apps queue where can I see the current contents or stats on the internal queue?

Kindly
Henrik Holst

0 comments

1 answer

Your answer

Answer 1

MayankBargali-MSFT 71,016 Moderator

@Henrik Holst Internally the concurrency are handled based on the concurrency value that you have set up on your trigger/action. We take care of scaling of internal queues/resources/queueing of events as needed and these details are not exposed/viewed at the Azure portal at the customer end. If you have concerned that there will be an overflow of internal queue/resources then this will not the case and we make sure of this and services work correctly. If there are no special cases where you only want one instance to be running then I will suggest not to change the concurrency.

Henrik Holst 1 Reputation point

2021-12-09T13:59:21.347+00:00

We need to limit the number of concurrent flows because the flow contains a call to a ML service that can only process a specific number of concurrent calls. Above that it is not reliable and we might get status code 500, or worse.

As seen in the image below it seems that Logic Apps can potentially lose messages before they have been processed by a flow. At least that is the interpretation I made. A large amount of messages from Event Grid combined with a non-concurrent Logic app flow that is unable to process them in time, exposes a risk a part of the messages can be lost.

We really need the flow Event grid to Azure Logic apps to be guaranteed flow - without any risk of having unprocessed messages being discarded.

https://imgur.com/a/AQCQrhf
MayankBargali-MSFT 71,016 Reputation points Moderator

2021-12-14T05:39:02.99+00:00

@Henrik Holst The screenshot talks about the retry policy and I believe you are talking about Settings for the trigger when a resource event occurs. This retry is applicable when the events are delivered from event grid to the logic app. There shouldn't be an event drop while triggering the logic app but in case if your logic app gets successfully triggered but your workflow fails in any action then that event will not be processed from your workflow and not from the event grid to the logic app as it was the successful trigger. The suggestion would to handle this either in your workflow or use a service bus in between.
Event Grid --> service bus (as endpoint to your event grid subscription) --> Logic App (Service bus peek lock trigger). You will only complete the message once you got the response from ML service and your workflow last step will be completing the message so no messages is lost.

Share via

Logic Apps event grid consumption

1 answer

Your answer