TagAzure Service Bus

With SendVia, it is possible to create an atomic transaction between the incoming message and outgoing messages, for more posts in this series go to Contents. In scenarios where transactional processing is required for an incoming message that would generate some outgoing messages, the incoming and outgoing messages should all succeed or rollback. Failure to do so would either create duplicate processing (failure to complete the incoming message) or ghost messages (failure to revert the...

Shows how to batch multiple messages together into one single operation against Azure Service Bus, for more posts in this series go to Contents. In the article about atomic sends, we talked about the fact that each send operation executed against Azure Service Bus can fail and potentially has to be retried. Another important aspect though that wasn’t covered in the previous article is that every send operation has latency costs associated with it. Let’s assume we want to send ten...

Shows how to atomically send messages as a group, for more posts in this series go to Contents. This topic is best illustrated by directly diving into some code. await using var sender = serviceBusClient.CreateSender(destination); var message = new ServiceBusMessage("Deep Dive 1"); await client.SendMessageAsync(message); message = new ServiceBusMessage("Deep Dive 2"); await client.SendMessageAsync(message); In the above code, a QueueClient is used to send two messages. By default, every time...

Shows how to create topologies by combining subscriptions with forwarding, for more posts in this series go to Contents. In the previous post we looked at how we can leverage topics and subscriptions together with rules to create powerful message-based solutions. A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. Messages are received from a subscription identically to the way they are received from a queue. The implication of the...

Shows how to publish and subscribe with topics, for more posts in this series go to Contents. In contrast to queues, in which a single consumer processes each message, topics and subscriptions provide a one-to-many form of communication, in a publish/subscribe pattern. The pattern is useful for scaling to large numbers of recipients, and each published message is made available to each subscription registered with the topic. The main benefits are: The publisher...

Introduces the concept of forwarding from one entity to another, for more posts in this series go to Contents. Queues and Subscriptions (more about those later) have the possibility to become what I call “forwarding-only” entities. An entity can be set into the forwarding mode by setting the property ForwardTo to a destination. var description = new CreateQueueOptions("Hop"); await client.CreateQueueAsync(description); description = new CreateQueueOptions("Hop0"); await client...

Explains where messages got when certain conditions are met, for more posts in this series go to Contents. If we are using queuing, we certainly don’t want to lose messages. After all, those queues decouple the sender from the receiver by persisting the business intent messages and allowing them to handle them whenever the receiver has time. But what if: The receiver doesn’t pick up the message before the message’s time to live is expired (Expiry)The receiver could not...

Explains how messages can expire by associating a time to live with the message, for more posts in this series go to Contents. There are multiple ways of how messages can “disappear” from a queue. The most obvious one is that a message in the queue was received by a client and successfully acknowledged. There is another one that might be not that obvious and can even be leveraged to create clever designs: It is called message expiry or time to live. If not specified otherwise...

Explains scheduling of messages into the future, for more posts in this series go to Contents. What if we could write a letter to our future self? It turns out with Azure Service Bus we can! With the SDK, it is possible to schedule a message to be due at a certain point in time, and the broker will make sure to deliver it back into the queue when the date is due. With that trick, we can store durable timeouts on the broker to kill our batch jobs or implement things like invoice reminders...

Explains connections and how they relate to senders and receivers, for more posts in this series go to Contents. So far, we’ve been creating a ServiceBusClient to create senders and receivers. The below code illustrates a small example that sends a message to a destination and then receives a single message from that destination. await using var serviceBusClient =    new ServiceBusClient(connectionString); await using var connectionSharingSender = serviceBusClient   ...