Sessions support for Service Bus (Logic Apps Standard)
For more Service Bus enhancements, refer to these articles: Concurrency support for Service Bus
Azure Service Bus Sessions provide a way to group related messages together, allowing for specific processing patterns such as sequential convoy. Choosing a Service Bus trigger that supports sessions (for receiving) and providing a session identifier to an action for sending or reading, allows your Logic App to process messages within a session.
- Sending messages with sessions
- When sending messages to a Service Bus queue or topic, you can optionally specify a session ID for the message
- Messages with same session ID are treated as part of the same logical grouping (session)
- Receiving messages with session
- To receive messages with sessions, use the triggers that support the sessions. Then you can use the triggers or actions later in the workflow to receive and process messages based on session ID
- This allows you to receive and process messages in a way that takes session into account, enabling you to handle related messages together.
- To keep a session active for longer periods of time, use the action to renew the session.
- Dynamic session processing
- You can also dynamically process sessions by using expressions in Logic Apps. For example, you can use the session ID from the received message and use it in subsequent steps.
Before you use sessions, here are two documents that provide an overview into the use of sessions to process related messages and in specific order. These documents refer to consumption logic apps, but the concept applies to Standard Logic Apps as well.
To enable sessions, we have added new triggers which are described in the next section. Managing sessions requires us to keep their state, therefore these triggers are recurrence based triggers (and not built on Azure Function bindings). Recurrence based triggers can only be supported in stateful workflows, which is why the Service Bus session based triggers are only available in stateful workflows.
Using sessions with Service Bus in Logic Apps Standard
In Logic Apps Standard, here are the key steps to consider when using sessions.
- In your Standard Logic Apps workflow, use the Service Bus In-App connector and a trigger that supports sessions.
- In the trigger, you provide the queue name, the session ID and also configure the number of messages the trigger should pick (batch size) and the frequency. The session ID is an optional field. If you do not provide it, then we pick up one of the available sessions from the queue or topic. If you provide the session ID in the trigger, then the messages from the specific session are picked. You can write workflows such that the trigger is not associated with a specific session ID and hence receives messages from different sessions, and you use the actions in subsequent steps, to read messages from specific sessions. [We have attached an example to this blog that follows this pattern]
- The trigger returns messages for a given session. To continue to read more messages from the same session, use the actions to get more messages from a session
- The session should be renewed to keep it active. You can use these actions and provide the session ID to keep it active
Example
Here is an example of a workflow that uses sessions to read items from Service Bus. The left branch keeps the sessions active, while the right branch reads the messages in a given session until the condition is satisfied (in this case - when 6 messages are read in the session). The workflow JSON for this example is also attached.
