0
votes

I have an Azure Service Bus Namespace, containing 8 topics, each with at least one subscription.

There are generally two Logic Apps,the first extracting data from our database every half hour (at 15 and 45 past the hour) and placing it onto the Service Bus topic of choice, and a second being triggered using the "When a message is recieved in a topic subscription (auto-complete)" trigger connector - with default concurrency set (25). An example is shown below

"When_a_message_is_received_in_a_topic_subscription_(auto-complete)": {
            "conditions": [],
            "inputs": {
                "host": {
                    "connection": {
                        "name": "@parameters('$connections')['servicebus']['connectionId']"
                    }
                },
                "method": "get",
                "path": "/@{encodeURIComponent(encodeURIComponent('exampletopic'))}/subscriptions/@{encodeURIComponent('examplesubscription')}/messages/head",
                "queries": {
                    "subscriptionType": "Main"
                }
            },
            "recurrence": {
                "frequency": "Minute",
                "interval": 30,
                "startTime": "2021-01-27T00:00:00.000Z",
                "timeZone": "UTC"
            },
            "runtimeConfiguration": {
                "concurrency": {
                    "runs": 25
                }
            },
            "type": "ApiConnection"
        }

As mentioned in the title, the issue I have is that the trigger is only ever firing on the 30 minute polling recurrence, as can be seen below, and not when the messages go into the servicebus (unlike the common data service trigger we also use which fires on create/update/delete instantly). Is this by design or something I have setup wrong?

Logic App Runs - Service Bus Trigger

Another issue is that the concurrency setting is literally only letting 25 through, and keeping the rest in the Service Bus until the next run, so we are having to wait long periods between processing. I thought the point of the concurrency setting was to let the logic app runs wait in a queue, and then when one finishes another one could start. As you can see in the image I pasted above, this is just not happening. The 3.45 run extracted 43 records from the database. Only 25 where triggered at 4.00, with 17 left on the Service Bus until the next run at 4.30. This has the potential to be a massive bottle neck if we send huge numbers through.

The Service Bus settings are also below, if they are of interest to anyone:

Topic:
"properties": {
            "defaultMessageTimeToLive": "P5D",
            "maxSizeInMegabytes": 1024,
            "requiresDuplicateDetection": true,
            "duplicateDetectionHistoryTimeWindow": "PT1H",
            "enableBatchedOperations": true,
            "status": "Active",
            "supportOrdering": true,
            "autoDeleteOnIdle": "P10675199DT2H48M5.4775807S",
            "enablePartitioning": false,
            "enableExpress": false
        }
Subscription:
"properties": {
            "lockDuration": "PT5M",
            "requiresSession": false,
            "defaultMessageTimeToLive": "P5D",
            "deadLetteringOnMessageExpiration": true,
            "deadLetteringOnFilterEvaluationExceptions": true,
            "maxDeliveryCount": 1,
            "status": "Active",
            "enableBatchedOperations": true,
            "autoDeleteOnIdle": "P5D"
        }

Thanks in advance

2

2 Answers

0
votes

Is this by design or something I have setup wrong?

The Service Bus trigger is designed like this, because it is a polling trigger and will run at the interval you specify, please refer to Triggers overview:

Every workflow includes a trigger, which defines the calls that instantiate and start the workflow. Here are the general trigger categories:

  • A polling trigger, which checks a service's endpoint at regular intervals
  • A push trigger, which creates a subscription to an endpoint and provides a callback URL so the endpoint can notify the trigger when the specified event happens or data is available. The trigger then waits for the endpoint's response before firing.

Another issue is that the concurrency setting is literally only letting 25 through, and keeping the rest in the Service Bus until the next run, so we are having to wait long periods between processing.

Have you tried turning off Concurrency Control. According to the description, turning off Concurrency Control can run as many parallel instances as possible, but once the setting of Concurrency Control is turned on, it cannot be turned off. You may need to recreate an Azure logic app, or set Concurrency Control to the largest possible value, the maximum value is 50.

1.

enter image description here

2.

enter image description here

0
votes

Logic app works on polling mechanism so as Frank mentions, one option is you can reducing the polling interval time. But each poll counts as an action so the cost for logic apps will go up. So please keep that in mind. You can increase the concurrency to pick up more number of messages from the service bus.

Another option for you to consider is to use Azure Functions with Service bus trigger. This will be an immediate trigger but yes involves coding rather than configuration.