Azure Service Bus actions

Every Azure Service Bus action

• Azure Service Bus: Cancel Scheduled MessagesCancel messages that Schedule Message put on a queue's schedule, by their sequence numbers. Sequence numbers are the only identifier the broker accepts here: a message ID will not do.
• Azure Service Bus: Create QueueCreate a queue. Requires Session, Requires Duplicate Detection and Enable Partitioning are IMMUTABLE: they can only be set at creation, and changing your mind later means recreating the queue and losing its messages. Lock Duration cannot exceed 5 minutes whatever is asked for.
• Azure Service Bus: Create RuleCreate a filter rule on a subscription: a SQL filter, a correlation filter, or a true/false filter, with an optional SQL action that rewrites matched messages. Filter rules are what make a topic worth using instead of N queues. Remember to delete the subscription's $Default rule afterwards: it matches everything, so while it exists the new filter narrows nothing.
• Azure Service Bus: Create SubscriptionCreate a subscription on a topic. Every new subscription ships with a $Default rule that matches everything: add a filter with Create Rule and then DELETE $Default, or the filter will appear to do nothing. Requires Session is immutable here too.
• Azure Service Bus: Create TopicCreate a topic. A topic on its own is a black hole: messages sent to a topic with no subscriptions are discarded and the send still reports success. Create at least one subscription before sending.
• Azure Service Bus: Dead-Letter MessagesReceive messages and dead-letter all of them with a reason and description: the receive-inspect-reject shape, in one step. This is the only dead-letter action that is not a disposition on a receive, and it still receives first for the same reason: a lock token cannot cross nodes, so there is nothing a standalone reject node could hold on to. To dead-letter conditionally, use Receive from Queue with Then = Dead-Letter behind a filter.
• Azure Service Bus: Delete QueueDelete a queue and every message in it, active, scheduled and dead-lettered alike. There is no undo and no recycle bin.
• Azure Service Bus: Delete RuleDelete a filter rule from a subscription. In practice this is how the $Default rule goes: add your real filter with Create Rule, then delete $Default so the subscription stops matching everything.
• Azure Service Bus: Delete SubscriptionDelete a subscription and every message on it. The topic and its other subscriptions are untouched.
• Azure Service Bus: Delete TopicDelete a topic, all of its subscriptions, and every message on them. There is no undo.
• Azure Service Bus: Get Many QueuesList the queues in the namespace with their configuration. Needs a namespace-level connection string (or an Entra principal): an entity-scoped one cannot reach the management API at all. The management plane is rate-limited far harder than the data plane: do not call this in a tight loop.
• Azure Service Bus: Get Many RulesList a subscription's filter rules. Worth running whenever a filter seems to be ignored: every subscription is created with a $Default rule that matches everything, and while it exists any filter you add is redundant.
• Azure Service Bus: Get Many SubscriptionsList a topic's subscriptions with their configuration. Also the answer to "where did my messages go?": a topic with no subscriptions discards everything sent to it.
• Azure Service Bus: Get Many TopicsList the topics in the namespace with their configuration. Needs a namespace-level connection string or an Entra principal.
• Azure Service Bus: Get NamespaceGet the namespace's properties: name, SKU tier and messaging units. The natural test-connection probe: it proves the credentials and reachability without touching a queue, and the tier tells you the message size cap you are working under (256KB on Standard, 100MB on Premium).
• Azure Service Bus: Get QueueGet a queue's configuration: lock duration, max delivery count, TTL, the session and duplicate-detection flags, and the size cap. For live message counts use Get Queue Runtime Properties instead: configuration and counts are different calls.
• Azure Service Bus: Get Queue Runtime PropertiesGet a queue's live counts: active, dead-lettered, scheduled and transfer message counts, plus size in bytes. This is what a monitoring or alerting flow reads: a rising dead-letter count is usually the first sign anything is wrong.
• Azure Service Bus: Get Subscription Runtime PropertiesGet a subscription's live counts: active, dead-lettered and transfer message counts. The topic-side twin of Get Queue Runtime Properties, and the read a monitoring flow is built on.
• Azure Service Bus: Peek Dead-LetteredLook at dead-lettered messages without consuming them: diagnosis without commitment. Pairs with Receive Dead-Lettered once you know what is in there.
• Azure Service Bus: Peek QueueLook at a queue's messages without locking, removing or counting a delivery against them. The safe first question: nothing observed here is consumed. Peek also sees scheduled and deferred messages, which a receive cannot.
• Azure Service Bus: Peek SubscriptionLook at a topic subscription's messages without locking or removing them. Nothing peeked is consumed, and no delivery is counted against it.
• Azure Service Bus: Receive Dead-LetteredReceive from the dead-letter queue of a queue or subscription, exposing the dead-letter reason and description that say why each message ended up there. Messages arrive here automatically once delivery attempts exceed MaxDeliveryCount (default 10), or on expiry. A dead-letter queue has no dead-letter queue of its own, so abandoning here simply redelivers. Settlement happens HERE, in this node, because a lock token belongs to the AMQP connection that took it: a downstream Complete node is impossible, and when this node's link closes the broker releases anything unsettled immediately. Defer is the one handoff that survives: its sequence numbers are durable, so another flow can pick the message up with Receive Deferred Messages.
• Azure Service Bus: Receive Deferred MessagesRetrieve deferred messages by sequence number. This is the one sanctioned handoff between flows: sequence numbers are durable and portable across connections and processes, where lock tokens are not. Defer in one flow, pick the message up in another.
• Azure Service Bus: Receive from QueueReceive messages from a queue and settle them in the same step: complete, abandon, dead-letter or defer. Settlement happens HERE, in this node, because a lock token belongs to the AMQP connection that took it: a downstream Complete node is impossible, and when this node's link closes the broker releases anything unsettled immediately. Defer is the one handoff that survives: its sequence numbers are durable, so another flow can pick the message up with Receive Deferred Messages.
• Azure Service Bus: Receive from SubscriptionReceive messages from a topic subscription and settle them in the same step. Messages live on the subscription, not the topic: a topic cannot be received from. Settlement happens HERE, in this node, because a lock token belongs to the AMQP connection that took it, a downstream Complete node is impossible, and when this node's link closes the broker releases anything unsettled immediately. Defer is the one handoff that survives: its sequence numbers are durable, so another flow can pick the message up with Receive Deferred Messages.
• Azure Service Bus: Receive SessionAccept a session (or the next available one) and receive its messages in FIFO order, with access to the session state. Sessions are all-or-nothing: the entity must have been CREATED with sessions required, and an ordinary receive against a session-enabled entity fails. The session carries its own lock, which expires like a message lock.
• Azure Service Bus: Schedule MessageSchedule a message to be enqueued on a queue at a future time. Outputs the sequence numbers the broker assigns: they are the ONLY handle Cancel Scheduled Messages accepts, so a scheduled message whose sequence number is not kept can never be cancelled.
• Azure Service Bus: Send Batch to QueueSend many messages to a queue in one AMQP transfer. Takes a JSON array of message objects ({"body":…, "message_id":…}) or plain strings. Batching is size-aware: the message that does not fit the 256KB envelope is named rather than silently dropped.
• Azure Service Bus: Send to QueueSend one message to a Service Bus queue, with the full broker property set (message ID, session, correlation, subject, TTL, scheduled enqueue time) and custom application properties. On Standard the 256KB size cap covers headers and application properties as well as the body.
• Azure Service Bus: Send to TopicSend one message to a Service Bus topic, which fans it out to the subscriptions whose filter rules match. A topic with no subscriptions silently discards every message and still reports success: check Get Many Subscriptions if messages seem to vanish.
• Azure Service Bus: Update QueueUpdate a queue's mutable properties. Read-modify-write: the queue is fetched first and only the fields set here are changed, because the management API takes a whole QueueProperties and would otherwise reset everything left blank to its default. The immutable flags (session, duplicate detection, partitioning) are not offered: they cannot change.

Also in Message Brokers