Azure Service BusMessaging

The namespace is the root management, billing, and DNS container (<namespace>.servicebus.windows.net) that houses all your queues and topics.

1. Navigate to the Azure Portal and sign in with your administrator account.
2. In the top global search bar, type Service Bus and select Service Bus under Services. Alternatively, click + Create a resource → Integration → Service Bus.
3. Click + Create to open the Create namespace provisioning wizard.
4. Under Project Details, select your active Subscription and pick or create a target Resource group (e.g. rg-messaging-prod).
5. Under Instance Details:
   • Namespace name: Enter a globally unique name (e.g. sb-ecommerce-prod). A green checkmark confirms availability.
   • Location: Choose your target Azure region (e.g. East US) close to your client workloads.
   • Pricing tier: Choose Standard for production publish-subscribe topics, queues, sessions, and deduplication. (Select Premium if you require private link isolation and dedicated messaging units).
6. Click Review + create, verify the validation passed, and click Create.

Once Azure Resource Manager completes deployment, access the namespace overview to inspect endpoint addresses, resource status, and operational telemetry.

1. When the notification banner confirms “Your deployment is complete”, click Go to resource.
2. Inspect the Essentials top card:
   • Status: Ensure it shows Active.
   • Host name: Note your primary DNS endpoint (e.g. sb-ecommerce-prod.servicebus.windows.net).
   • Resource group: rg-messaging-prod.
3. Examine the left navigation pane: identify Entities (Queues and Topics) and Settings (Shared access policies, Networking).
4. Review the built-in real-time charts in the Overview page displaying Incoming Messages and Outgoing Messages.

Queues implement point-to-point decoupling where multiple workers can read from the queue, but each message is exclusively delivered to and processed by a single competing consumer.

1. In the left sidebar under Entities, click Queues, then click + Queue on the command bar.
2. In the Add queue side blade, configure the following core parameters:
   • Name: orders-queue.
   • Max queue size: 1 GB (or up to 80 GB in Premium).
   • Max delivery count: 10. After 10 failed/abandoned delivery attempts, the message is automatically sequestered in the Dead-Letter Queue (DLQ).
   • Message time to live (TTL): 14 Days.
   • Lock duration: 30 Seconds (time a consumer has to process and settle before the lock expires).
3. Select the advanced feature flags:
   • Check Enable duplicate detection with a 10 minutes detection window (broker discards duplicate MessageIds).
   • Check Enable dead lettering on message expiration so expired orders are never silently lost.
   • (Optional) Check Enable sessions if strict FIFO per SessionId is required.
4. Click Create at the bottom of the blade.

Topics provide 1:N publish-subscribe fan-out: publishers send to a single topic, and each attached subscription receives an independent copy according to configurable rule filters.

1. In the left sidebar under Entities, click Topics, then click + Topic. Enter name events-topic and click Create.
2. Click on the newly created events-topic to open its blade, then click + Subscription.
3. In the Add subscription blade, configure subscription sub-billing:
   • Subscription name: sub-billing.
   • Max delivery count: 10.
4. Open the subscription’s Filters & actions tab:
   • Add a SQL Filter: sys.Label = 'OrderPlaced' AND Amount >= 100.00.
   • Add an optional Rule Action: SET RoutedBy = 'EnterpriseBus'; to annotate message headers before queuing.
5. Repeat the process to add other independent subscriptions (e.g. sub-shipping with correlation filter or sub-audit with TrueFilter 1=1).

Grant client applications permission to send or receive messages securely using either passwordless RBAC (recommended) or Shared Access Signature (SAS) connection strings.

1. Option A — Microsoft Entra ID (Recommended for Production & Cloud Apps):
   • Go to Access control (IAM) → + Add → Add role assignment.
   • For producers, assign the Azure Service Bus Data Sender role to your App Service, Azure Function, or User Managed Identity.
   • For consumers, assign the Azure Service Bus Data Receiver role.
2. Option B — Shared Access Policies (SAS Connection Strings):
   • In the left sidebar under Settings, click Shared access policies.
   • Click + Add, specify name SendListenPolicy, check Send and Listen (avoid checking Manage unless granting administrative privileges), then click Create.
   • Click the policy to open its drawer and copy the Primary Connection String (starts with Endpoint=sb://...).

The Azure Portal embeds Service Bus Explorer, a powerful tool for publishing test payloads, peeking at queue depth, and testing settlement without writing code.

1. Navigate to Entities → Queues → click on orders-queue.
2. In the queue’s left menu, select Service Bus Explorer.
3. Send a Test Message:
   • Select the Send messages sub-tab.
   • Set Content Type to application/json.
   • Paste sample JSON payload in the message body:

     {
       "orderId": "ORD-2026-904",
       "customer": "Fabrikam Retail",
       "amount": 250.00,
       "status": "APPROVED"
     }

   • Under Custom Properties, add key sys.Label with value Priority.
   • Click Send. A green notification confirms successful ingress.
4. Peek and Settle Messages:
   • Switch to the Peek from start tab to view the active message queue without removing messages.
   • Inspect Message ID msg-9041, Sequence Number, Enqueued Time, and Delivery Count.
   • Click into the message to inspect headers and simulate Dead-lettering or settlement.

Implement a production-grade publisher and asynchronous message processor using the official Azure.Messaging.ServiceBus SDK with the complete Peek-Lock settlement lifecycle.

1. Install official client and identity packages in your .NET project:

   dotnet add package Azure.Messaging.ServiceBus
   dotnet add package Azure.Identity

2. Sender (Producer): Creates a batch of messages and sends them atomically:

   using Azure.Identity;
   using Azure.Messaging.ServiceBus;
   
   // Authenticate via Microsoft Entra ID (or connection string)
   await using var client = new ServiceBusClient(
       "sb-ecommerce-prod.servicebus.windows.net", 
       new DefaultAzureCredential());
   
   ServiceBusSender sender = client.CreateSender("orders-queue");
   
   // Build message batch for optimal AMQP throughput
   using ServiceBusMessageBatch batch = await sender.CreateMessageBatchAsync();
   var order = new ServiceBusMessage("payload-json-bytes")
   {
       ContentType = "application/json",
       MessageId = "msg-9041",       // Enables duplicate detection
       Subject = "OrderPlaced"       // Used for subscription filter routing
   };
   
   if (batch.TryAddMessage(order))
   {
       await sender.SendMessagesAsync(batch);
       Console.WriteLine("[PRODUCER] Sent message batch successfully.");
   }

3. Processor (Consumer) with Peek-Lock Settlement:

   ServiceBusProcessor processor = client.CreateProcessor("orders-queue", new ServiceBusProcessorOptions
   {
       ReceiveMode = ServiceBusReceiveMode.PeekLock, // Message stays locked until settled
       MaxConcurrentCalls = 4,                       // Concurrent competing worker threads
       AutoCompleteMessages = false                  // Explicit settlement control
   });
   
   processor.ProcessMessageAsync += async args =>
   {
       string payload = args.Message.Body.ToString();
       Console.WriteLine($"[CONSUMER] Received order: {payload}");
   
       try
       {
           // 1. Execute business logic
           await ProcessOrderAsync(payload);
   
           // 2. Success: Complete and delete from queue
           await args.CompleteMessageAsync(args.Message);
           Console.WriteLine("[ACK] Message completed successfully.");
       }
       catch (TransientNetworkException)
       {
           // 3. Transient failure: Release lock for retry (+1 delivery count)
           await args.AbandonMessageAsync(args.Message);
       }
       catch (InvalidOrderDataException ex)
       {
           // 4. Poison message: Move directly to Dead-Letter Queue with error reason
           await args.DeadLetterMessageAsync(args.Message, "InvalidOrderPayload", ex.Message);
       }
   };
   
   processor.ProcessErrorAsync += args =>
   {
       Console.WriteLine($"[ERROR] {args.Exception.Message}");
       return Task.CompletedTask;
   };
   
   await processor.StartProcessingAsync();
   Console.WriteLine("Worker listening for orders. Press [Enter] to exit.");
   Console.ReadLine();
   await processor.StopProcessingAsync();

Operational excellence in Service Bus requires observing active queue depth, latency, and setting proactive alerts whenever poison messages arrive in the Dead-Letter Queue.

1. In the namespace left sidebar under Monitoring, select Metrics.
2. Add the key operational metrics:
   • Incoming Messages (Sum): Ingress message rate from senders.
   • Outgoing Messages (Sum): Consumption and settlement rate by workers.
   • Dead-lettered Messages (Average): Messages quarantined in the DLQ.
3. Create a Poison Message Alert Rule:
   • Click + New alert rule on the metrics toolbar.
   • Signal: Dead-lettered Messages.
   • Threshold: Set Greater than 0 over a 5-minute aggregation window.
   • Action Group: Assign your DevOps PagerDuty / Email on-call group.
   • Severity: Sev 2 (Warning) or Sev 1 (Error).
4. Save the alert rule to ensure operational teams are notified immediately when a poison message arrives for manual root-cause inspection.