Reference · built on requestConnectorStreams, queues & webhooks

Azure Service Bus

Queue and topic-subscription messages from Azure Service Bus by Peek-Lock over REST or AMQP 1.0, with dead-letter and scheduled delivery.

Request accessPricing ↗

About

Azure Service Bus is Microsoft's message broker for queues and publish-subscribe topics. A namespace holds queues, which store messages until a receiver asks for them, and topics, whose subscriptions each receive the messages their rules select. Messages are pulled, locked while a receiver works on them, and deleted when done. Dead-letter subqueues, scheduled delivery, sessions, deferral, transactions, and duplicate detection are part of the broker.

Through Fibric, an operator receives messages by Peek-Lock from the queues and subscriptions you name, proposes an action, and completes each message only once the proposal is on record. Sends happen after your approval and carry a MessageId so the broker discards any duplicate copy.

This is a reference listing. It documents what Fibric would read from Azure Service Bus and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Messages on a queue or subscription, received by Peek-Lock at /{queuePath}/messages/head or /{topicPath}/subscriptions/{subscriptionName}/messages/head
  • BrokerProperties on each message: MessageId, SequenceNumber, LockToken, LockedUntilUtc, DeliveryCount, EnqueuedTimeUtc, Label, TimeToLive, and State
  • Messages parked in the dead-letter subqueue of a queue or subscription
  • Session-ordered messages on session-enabled queues and subscriptions, for first-in, first-out processing
  • Queues, topics, subscriptions, and rules with filters and actions through the Microsoft.ServiceBus Resource Manager API

Proposed actions

  • Target capability: propose sending a message to a queue or topic over REST or AMQP 1.0, with a MessageId for duplicate detection
  • Target capability: propose completing a locked message by deleting it with its LockToken, or releasing the lock for another receiver
  • Target capability: propose scheduled delivery so a message becomes available for processing at a chosen time
  • Target capability: propose a subscription rule with a SQL filter and an optional action on a topic

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Take orders off a queue without losing one

    Peek-Lock returns the message and a LockToken. The operator reads it and proposes; the connector deletes the message only after the proposal is recorded. If the lock lapses first, another receiver gets the message.

    With Order Risk

  • Subscribe to only the invoices

    A rule with a SQL filter copies invoice messages from a purchasing topic into the operator's subscription. Purchase orders and receipts land in other subscriptions, and the operator matches the three for your approval.

    With Three-Way Match

  • Watch the dead-letter queue

    Messages no receiver could process sit in the entity's dead-letter subqueue. The operator reads them, names the DeliveryCount and the sender, and proposes a resubmit or a ticket.

    With Integration Health

  • Hold a stock transfer until its slot

    Scheduled delivery keeps a transfer message out of sight until the time you choose. The operator proposes the time, and the receiving system sees the message when the slot opens.

    With Stock Transfer

Requirements

  • A Service Bus namespace at {namespaceName}.servicebus.windows.net, or the domain for Azure China 21Vianet or United States government clouds
  • A shared access authorization rule (at most 12 per namespace, queue, or topic) or an Entra role assignment with the rights the connector needs
  • Queues, or topics with subscriptions, already defined; the connector reads existing entities and proposes rules rather than creating a topology
  • The Premium tier and AMQP if any message exceeds 256 KB
Authentication
A Microsoft Entra ID OAuth 2.0 token authorized by Azure RBAC on the namespace, queue, or topic, or a SAS token signed by a shared access authorization rule with Send or Listen rights.

Limits

  • Messages are at most 256 KB on Basic and Standard. Premium allows 1 MB over HTTP and up to 100 MB per message over AMQP.
  • Basic and Standard namespaces are limited to 1,000 operations per second; Premium throughput depends on messaging units.
  • A topic accepts 2,000 subscriptions and 2,000 SQL filters. The properties on one message cannot exceed 64 KB in total.
  • Concurrent receive requests on a queue, topic, or subscription are capped at 5,000; beyond that the service returns server busy.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Azure Service Bus ↗

Questions and answers

What stops two receivers processing the same message?
Peek-Lock. The operation locks the message for the entity's lock duration and returns a LockToken. Other receivers on that queue or subscription do not see it until the lock expires or is released. Deleting it with the LockToken completes it.
Can the connector receive from a topic directly?
No. Receivers read from a subscription on the topic. Each subscription gets a copy of every message its rules select and works like a queue from the receiver's side. The filter and optional action on each rule decide what is copied.
Does Service Bus push messages to an endpoint?
No. Messages are delivered in pull mode. A pull can be long-lived and completes when a message is available, or returns 204 when the timeout passes with nothing to deliver. The connector polls with Peek-Lock over HTTPS or holds an AMQP 1.0 link.
Ask about Azure Service Bus

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Azure Service Bus through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy