Skip to main content

Azure Service Bus

The Azure Service Bus inbound adapter in Connxio enables seamless integration with Azure Service Bus, a cloud-based messaging service. With this adapter, users can receive and process messages from Service Bus topics or queues within their Connxio integrations.

Configuring the Service Bus adapter​

To configure Connxio to start fetching data from Service Bus select the "Service Bus" option in the "Inbound Connection" shape:

Configuring inbound connectionConfiguring inbound connection

On creating a new adapter, a popup with the adapter's input fields will appear. Azure Service Bus has 3 sections; Core Settings, Advanced Settings and Wrapper.

propertiesproperties

Core Settings​

data pickup intervaldata pickup interval
  • Servicebus Type: There are two types; Topic and Queue.
  • Connection String Security Configuration: Reference to the Security Configuration that contains the relevant connection properties. Note that a servicebus connection string cannot contain 'EntityPath', as this information is set in the 'Topic Name' or 'Queue Name' field.
  • Topic Name: The name of the topic.
  • Subscription Name: The name of the subscription to pick files from.

Advanced settings​

data pickup intervaldata pickup interval

Wrapper​

data pickup intervaldata pickup interval
  • WrapperType: Choose between Json, XML or None.
  • Might be Wrapped: A wrapper is essentially just a shell around the actual message content that contains information not within the concern of the message itself. Read more about wrappers here.

Message Handling Patterns​

When using the Service Bus outbound adapter in Connxio, you have the option to choose between two message handling patterns: uploading the message to an Azure Blob Storage or pure message sending.

Uploading to Azure Blob Storage​

In this pattern, you can upload the message payload to an Azure Blob Storage container. Connxio offers two different options for including the blob URI within the Service Bus message. This approach is useful when dealing with large message payloads that exceed the size limitations of direct message sending.

  1. URI only: In this option, the URI to the file in the Azure Blob Storage is included as plain text within the Service Bus message. This is a straightforward approach that allows easy access to the file by directly using the URI provided. The message's interchangeId will be included in the Service Bus message's UserProperties object with the key InterchangeId.

  2. JSON Structure: Alternatively, you can choose to include the blob URI, file name, and interchange ID in a JSON structure within the Service Bus message. The structure looks like this:

{
    "SasUri": "the URI to the file",
    "FileName": "the file name",
    "InterchangeId": "the interchange ID for the message"
}

This JSON structure provides a more organized representation of the necessary information related to the file in the Azure Blob Storage.

Pure Message Sending​

Alternatively, you can opt for pure message sending, where the message payload is included directly within the Service Bus message itself. This pattern is suitable for smaller message payloads that do not require external storage. By embedding the message directly, you eliminate the need for additional storage and simplify the overall message handling process.


When selecting a message handling pattern, consider the size of your message payloads and the desired level of storage flexibility. Both options offer their own advantages and can be chosen based on your specific integration requirements.

InterchangeId​

You can supply your own InterchangeId for transactional logging purposes by adding a user property to the message with the key InterchangeId and the string value for the InterchangeId itself. I.e.:

Message sbMessage = new Message(Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(msgCont)));
sbMessage.UserProperties.Add("InterchangeId", "3c8701dc-858b-4f98-915a-5b3432eb37ec");

Be sure to read the Core Concepts for more information about supplying your own InterchangeId.

Retry​

Given that the Service Bus no longer operates in polling mode but rather continuously, the retry mechanism persists indefinitely until connectivity is restored. By default, retries occur every 60 seconds when encountering transient errors. Alternatively, the customer-defined interval takes precedence should the error persist beyond transient conditions. Customization of retry behavior is achievable through inbound retry configuration, allowing customers to override the default settings.