vovalc.blogg.se - Service bus queue fifo

SERVICE BUS QUEUE FIFO UPDATE

SERVICE BUS QUEUE FIFO UPDATE

Running the console app creates 400 messages on both subscriptions, 4 status update messages per 1 order.

var message = new Message(( $”Status- īelow is the settings for the service bus topic which has 2 subscriptions and one of them has Requires Session checked.

for ( int m = 0 m < messagePerSession m++).

//simulate a status update in the correct order.

var sender = new MessageSender(connectionString, topicName).

Console.WriteLine( “Creating Service Bus sender….” ).

private static int messagePerSession = 4.

private static string topicName = ConfigurationManager.AppSettings.

private static string connectionString = ConfigurationManager.AppSettings.

This is so we can compare the ordering of messages being received with and without sessions enabled. The app will then send the messages to a SB Topic where it will have two subscriptions, one with sessions enabled and the other disabled. The session Id of each status message will be set to the order number. To simulate the warehouse tracking system, a console app will be used to create messages for each status change (Ordered, Picked, Packaged, Dispatched), for several hundred orders. An Azure function will then pull the messages from the service bus and update the order status in a database where the customer can view the current state of their order. This involves placing a new message onto the service bus every time the order status needs to get updated. Throughout each stage (Ordered, Picked, Packaged, Dispatched) of the ordering process, the status of the order must be updated.

Typical ScenarioĪ warehouse needs to track the progress of an order from when its first received to when it gets dispatched. Enabling sessions on the Azure Function places a lock on all messages that have the same session Id causing the locked messages to be consumed by that one function instance that placed the lock.

This feature for Azure Functions to use SB sessions only came GA as of mid 2019. Azure Functions need to have the IsSessionsEnabled property set to enabled on the SB input binding. Some examples of a session Id could be the account number, customer number, batch Id, etc. Messages sent onto the SB must set the context property SessionId to unique value from other non related messages. The property Requires Session must be enabled on the SB queues and topic subscriptions. To enforce message ordering several properties must be set. A more scalable option is to use sessions.This allows you to have multiple instances of a function executing giving you a higher message throughput. The only problem with this solution is it won’t scale very well. One option to enforce ordered delivery is to configure the Azure Function to spin up only one instance. This is represented in the sequence diagram below, where the function instance 1 took longer to update the same record in a database than instance 2. Typically when using Azure Functions to consume messages from a Service Bus (SB), the ordering is not guaranteed although the SB is First-In-First-Out (FIFO). This is due to competing consumers, where multiple instances of the function are competing for messages of the service bus.Īn example where out of ordering can happen is when a function instance takes longer to process a message than other instances therefore affecting the process ordering.