Microsoft Service Bus Connector FAQ

Q: What can I integrate with using this connector?

A: The Service Bus connector allows integration with both Windows Service Bus on-premises or Azure Service Bus cloud-hosted environments.

Q: What queue types are supported by the connector?

A: All Service Bus queue types are supported, including standard queues, topics, and event hubs.

Q: What protocol does the connector use?

A: The Service Bus connector uses AMQP 1.0 for message encoding and transport. The Mule payload is mapped to the AMQP message body, with message properties being mapped to the AMQP envelope properties.

Q: How do I connect to a specific queue or topic of interest?

A: Once the Service Bus namespace has been configured in the connector, the available queues, topics and event hubs in that namespace are made available via DataSense allowing simple configuration of flows to send  or receive messages to the appropriate endpoint.

Q: Can I dynamically provision new queues or topics from within Mule?

A: Yes, the full admin API is exposed via the Service Bus connector making it simple to build dynamic integration applications.

Q: What Mule editions can I use this connector on?

A: This connector is supported on any Enterprise Edition Anypoint platform running on any operating system and bit-ness, including the CloudHub integration PaaS.

Q: Is zero message loss behavior guaranteed?

A: Yes, if the Mule flow for the message does not finish (that is, halts or throws an exception while processing), then the message in the flow is not acknowledged by the connector and after the configured lock duration time at the Service Bus queue or topic, it will be available to retrieve it again. You should also be aware of the maximum delivery retry count for messages before they go to the dead-letter queue.

Q: How does the connector behave in a cluster? Will it be able to have multiple active consumers on all the cluster nodes competing for messages from the same queue?

A: Yes, we can ensure that the connector works smoothly while no exceptions are being thrown within the Mule flows (that is, each one of the consumers will receive a message exactly-one time - this statement depends on lock duration and processing time of prefetched messages within the connector). In the case where messages should be recovered due to a halt or failure while processing them, the at-least-once delivery is the expected behavior. As said before this depends on the time required to process each message in the flow, the lock duration and maximum delivery count configured for the queue within Azure Service Bus, etc.

See Also