Azure Service Bus
This page describes the usage of the Stream Reactor Azure Service Bus Sink Connector.
Stream Reactor Azure Service Bus Sink Connector is designed to effortlessly translate Kafka records into your Azure Service Bus cluster. It leverages Microsoft Azure API to transfer data to Service Bus in a seamless manner, allowing for their safe transition and safekeeping both payloads and metadata (see Payload support). It supports both types of Service Buses: Queues and Topics. Azure Service Bus Source Connector provides its user with AT-LEAST-ONCE guarantee as the data is committed (marked as read) in Kafka topic (for assigned topic and partition) once Connector verifies it was successfully committed to designated Service Bus topic.
Connector Class
Full Config Example
For more examples see the tutorials.
The following example presents all the mandatory configuration properties for the Service Bus connector. Please note there are also optional parameters listed in Option Reference. Feel free to tweak the configuration to your requirements.
KCQL support
You can specify multiple KCQL statements separated by ;
to have the connector map between multiple topics.
The following KCQL is supported:
It allows you to map Kafka topic of name <your-kafka-topic>
to Service Bus of name <your-service-bus>
using the PROPERTIES specified (please check Configuring KCQL mappings for your QUEUEs and TOPICs for more info on necessary properties)
The selection of fields from the Service Bus message is not supported.
Authentication
You can connect to an Azure Service Bus by passing your connection string in configuration. The connection string can be found in the Shared access policies section of your Azure Portal.
Learn more about different methods of connecting to Service Bus on the Azure Website.
Configuring KCQL mappings for your QUEUEs and TOPICs
The Azure Service Bus Connector connects to Service Bus via Microsoft API. In order to smoothly configure your mappings you have to pay attention to PROPERTIES part of your KCQL mappings. There are two cases here: reading from Service Bus of type QUEUE and of type TOPIC. Please refer to the relevant sections below. In case of further questions check Azure Service Bus documentation to learn more about those mechanisms.
Writing to ServiceBus of type QUEUE
In order to be writing to the queue there's an additional parameter that you need to pass with your KCQL mapping in the PROPERTIES part. This parameter is servicebus.type
and it can take one of two values depending on the type of the service bus: QUEUE or TOPIC. Naturally for Queue we're interested in QUEUE
here and we need to pass it.
This is sufficient to enable you to create the mapping with your queue.
Writing to ServiceBus of type TOPIC
In order to be writing to the topic there is an additional parameter that you need to pass with your KCQL mapping in the PROPERTIES part:
Parameter
servicebus.type
which can take one of two values depending on the type of the service bus: QUEUE or TOPIC. For topic we're interested inTOPIC
here and we need to pass it.
This is sufficient to enable you to create the mapping with your topic.
Kafka payload support
This sink supports the following Kafka payloads:
String Schema Key and Binary payload (then
MessageId
in Service Bus is set with Kafka Key)any other key (or keyless) and Binary payload (this causes Service Bus messages to not have specified
MessageId
)No Schema and JSON
Null Payload Transfer
Azure Service Bus doesn't allow to send messages with null content (payload)
Null Payload (sometimes referred as Kafka Tombstone) is a known concept in Kafka messages world. However, because of Service Bus limitations around that matter, we aren't allowed to send messages with null payload and we have to drop them instead.
Please keep that in mind when using Service Bus and designing business logic around null payloads!
Option Reference
KCQL Properties
Please find below all the necessary KCQL properties:
Configuration parameters
Please find below all the relevant configuration parameters:
Last updated