Logic app service bus message trigger.
Currently logic app service message trigger should poll every 1 mins to check any message exists and every trigger cost the customers and we would like to trigger executed automatically with out polling the trigger every 1 mins whenever message received to queue/topic.
This can be achieved now with an Azure Event Grid trigger.
Brian Stewart commented
+1 to Jason Steele's reply. The Premium SKU will tack nearly $10,000 USD per year onto your bill, just so you have your logic app triggered more intelligently. That seems a bit absurd as a "solution".
To automatically achieve this using Event Grid you currently have to have the Premium SKU which is too expensive for most.
This solution will raise an Event when an item is added to the service bus queue, and also later if there are events on the queue and no listener. (It's this latter part of the solution which makes this difficult to implement ourselves).
I don't think we have a solution until this available on the other SKUs.
Wagner Silveira commented
Right now, you should be able to workaround this using Event Grids, But I agree that as much as possible connectors should be using event grids under the hood to enable push notifications instead of polling scenarios.
Hi, it's been over 6 months since this request was marked as Planned. Can we have an update on it's progress? Thanks.
There appears to be a workaround now that Service Bus can raise Event Gris events.
But I'm sure we would still all like to be able to achieve this without resorting to Event Grid.
Any update on this
Sam Vanhoutte commented
Right now we have a huge trade off between performance and cost
Because of the underlying architecture, it does not seem possible to have 'session-based' listening on service bus queues/subscriptions... Therefore, the performance is really limited to the 'second level' polling.
And having a polling for every second (even without receiving messages) is extremely expensive.
(example: 20 pollings per second for 1 month equal 1140€/month!)
Isn't it possible to include a receive timeout (of several minutes) on the receive configuration so that messages still have an acceptable performance in a pub/sub scenario ?