Microsoft Service Bus Connector FAQ
A: The Service Bus connector allows integration with both Windows Service Bus on-premises or Azure Service Bus cloud-hosted environments.
A: All Service Bus queue types are supported, including standard queues, topics, and event hubs.
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.
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.
A: Yes, the full admin API is exposed via the Service Bus connector making it simple to build dynamic integration applications.
A: This connector is supported on any Enterprise Edition Anypoint platform running on any operating system and bit-ness, including the CloudHub integration PaaS.
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 is 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.
In the flow configuration, select
synchronous from the Processing Strategy drop-down menu to enable zero message loss. This guarantees that ACK is sent to the BUS only after the Mule flow is executed.
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.