Integrate with Azure Service Bus for Messaging

Azure Service Bus SDK for Python is a client for enterprise messaging over queues and pub/sub topics, providing reliable cloud communication. Its client hierarchy runs ServiceBusClient (connection management) to a ServiceBusSender (from get_queue_sender() or get_topic_sender()) and a ServiceBusReceiver (from get_queue_receiver() or get_subscription_receiver()), with both async and sync client variants; it authenticates with DefaultAzureCredential.

Sending covers a single message, a plain list of messages, or a size-aware ServiceBusMessage batch built with create_message_batch() that raises when full so you can flush and start a new batch. Receiving pulls a batch with a max message count and wait time, then settles each message explicitly: complete_message() removes it from the queue on success, abandon_message() releases the lock for an immediate retry, dead_letter_message() moves it to the dead-letter queue with a reason and description, and defer_message() sets it aside to be fetched later by sequence number. Receive mode defaults to PEEK_LOCK (the message is locked until explicitly settled, for reliable processing) but can be switched to RECEIVE_AND_DELETE for at-most-once delivery where the message is removed immediately on receipt.

Topics and subscriptions follow the same sender/receiver pattern, just targeting a topic name and a named subscription instead of a queue. Sessions provide FIFO ordering: a message is tagged with a session_id, and a receiver can attach to that specific session or to NEXT_AVAILABLE_SESSION. Messages can be scheduled for future delivery (schedule_messages() returns a sequence number you can later pass to cancel_scheduled_messages()), and the dead-letter queue itself can be read directly via sub_queue=ServiceBusSubQueue.DEAD_LETTER, exposing each message's dead_letter_reason.

Use it when you need durable, ordered, or retryable messaging between services - queues for point-to-point work distribution, topics/subscriptions for pub/sub fan-out, sessions when strict per-key ordering matters. Prefer the async client for production workloads; the sync client is meant for simple scripts, not high-throughput services.

Input is a ServiceBusMessage (or a batch of them) sent to a queue or topic, optionally tagged with a session ID or a scheduled delivery time. Output is delivered messages read by a receiver, each explicitly settled as completed, abandoned, dead-lettered, or deferred. Install it with:

pip install azure-servicebus azure-identity

Its own best practices: use the async client for production, use context managers (async with) for proper cleanup, complete messages only after successful processing, route poison messages to the dead-letter queue, use sessions for ordered FIFO processing, batch messages for high throughput, and always set max_wait_time to avoid blocking indefinitely. The skill also ships reference material for competing-consumer/retry/transaction patterns, dead-letter handling strategies, and a setup script for managing queues, topics, and subscriptions from the CLI.

It's the azure-servicebus package paired with azure-identity for DefaultAzureCredential authentication against an Azure Service Bus namespace.

Python developers building services that need reliable, ordered, or retryable messaging - work-queue distribution, pub/sub fan-out, or FIFO session processing - rather than direct point-to-point HTTP calls between services.