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.

Keep message properties​

The Keep message Properties pattern is a more advanced pattern that enables modification of how the message is sent and received from the Service Bus (SB). When this option is selected Connxio reads the entire SB message and transforms it into a ConnxioServiceBusMessage which has the following properties:

public class ConnxioServiceBusMessage
{
    public string BodyContent { get; set; }
    public string MessageId { get; set; }
    public string PartitionKey { get; set; }
    public string TransactionPartitionKey { get; set; }
    public string SessionId { get; set; }
    public string ReplyToSessionId { get; set; }
    public TimeSpan TimeToLive { get; set; }
    public string CorrelationId { get; set; }
    public string Subject { get; set; }
    public string To { get; set; }
    public string ContentType { get; set; }
    public string ReplyTo { get; set; }
    public DateTime ScheduledEnqueueTime { get; set; }
    public Dictionary<string, string> ApplicationProperties { get; set; }
    public string LockToken { get; set; }
    public int DeliveryCount { get; set; }
    public DateTime LockedUntil { get; set; }
    public int SequenceNumber { get; set; }
    public string DeadLetterSource { get; set; }
    public int EnqueuedSequenceNumber { get; set; }
    public DateTime EnqueuedTime { get; set; }
    public DateTime ExpiresAt { get; set; }
    public string DeadLetterReason { get; set; }
    public string DeadLetterErrorDescription { get; set; }
    public int State { get; set; }
}

This class is supplied to you i the Connxio.Transformation nuget package and corresponds directly to the SB ServiceBusReceivedMessage class managed by Microsoft.

All attributes changed in the ConnxioServiceBusMessage are propagated to the outbound SB. When Keep message Properties is enabled inbound the ConnxioServiceBusMessage is placed inside your file content and TransformationContext.Content. To change any of the properties you need to create a code map and deserialize the message like so:

ConnxioServiceBusMessage obj = JsonConvert.DeserializeObject<ConnxioServiceBusMessage>(transformationContext.Content);

After the abject is serialized you can change the desired properties and then serialize the ConnxioServiceBusMessage back into transformationContext.Content.

When this property is used for outbound adapters you can create the ConnxioServiceBusMessage class directly from whatever content you desire. Connxio will honor the properties set and send them to the Sb without the need for and SB inbound adapter.

Conclusion​

When selecting a message handling pattern, consider the size of your message payloads and the desired level of storage flexibility. All 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.