Description:

The Send Msg to Service Bus step belongs to the Azure category in FlowWright. Its XML definition identifies the step as sendazuresbmessage, with the label “Sends a message to the Azure Service Bus” and display name “Send Msg to Service Bus.” It uses the FlowWright.Workflow.SendAzureSBMessage namespace and FlowWright.Workflow.dll. The step is a Process step with two input connections and two output connections.

The step sends a specified message to an Azure Service Bus message queue using the configured Azure connection string and queue name. It also provides a Message parameters property for mapping message parameters. All four properties are required by the XML definition.

Typical uses include:

• Sending workflow messages to an Azure Service Bus queue
• Triggering downstream application processing
• Sending work items to queue-based integrations
• Integrating FlowWright workflows with Azure-based applications
• Publishing business-process messages for asynchronous processing
• Sending workflow-generated values to external systems
• Decoupling workflow processing from downstream application processing
• Integrating FlowWright with queue-based enterprise architectures

The step provides True and False execution paths so subsequent workflow processing can branch based on the outcome of the operation.

Azure Service Bus connection string parameters

The Azure Service Bus connection string contains the following information:

• Endpoint: The URL for the Azure Service Bus instance you want to connect to.
• Shared Access Key Name (SharedAccessKeyName): The name of the shared access key that provides security credentials for authentication.
• Shared Access Key (SharedAccessKey): The actual security key associated with the shared access key name used to establish secure communication.
• Entity Path (EntityPath): If you’re connecting to a specific queue or topic in the Service Bus, this specifies the path to that entity. This key value is optional.

Here’s a typical example of how an Azure Service Bus connection string might look:

Endpoint=sb://your-servicebus-name.servicebus.windows.net/;SharedAccessKeyName=YourKeyName;SharedAccessKey=YourKey;EntityPath=YourQueueOrTopicName

This connection string would enable your application to securely connect to the Azure Service Bus instance and interact with the specified queue or topic.

Here's a link to the article for more information on the Azure Service Bus connection. 

Usage:

The Send Msg to Service Bus step is typically placed in a workflow when business-process execution needs to send information to an external application or downstream processing component through an Azure Service Bus queue.

During execution:

1. Select the required Azure connection string.
2. Specify the Message queue name.
3. Enter the Message to send.
4. Configure the required Message parameters.
5. Execute the step.
6. Continue workflow processing through the True or False path.

The XML confirms that these four properties are the complete configurable property set exposed by the step.

A typical workflow might look like:

Example:

Let’s build and execute the “sendAzureSBMessageDef” example.          

• Create a new definition called “sendAzureSBMessageDef” and open the definition in designer mode.
• Drag a “sendAzureSBMessage” step to the canvas. 
• Connect the dots between the “Start” and “sendAzureSBMessage” steps, as shown above. 
• Click the "sendAzureSBMessage" step to configure its "Required" properties. Provide a name for the step, the Azure connection string, the message queue name, and the message to send. Click the button to configure multiple message parameters if necessary. Click the Save button. Note: Click the "AI Predict" button for the Copilot to add new process steps that match your process description. 

• Click the button to configure multiple message parameters. Click the Add Row (+) button to insert an empty row. Enter the message parameter and value. Click the Save button. You may add multiple parameters by inserting additional rows. 

• The “Logging” configuration is necessary for documentation and also measures workflow progress and percent complete. This is achieved by configuring the step state and percent fields individually, as shown in the images below. Configure the “Logging” using the following properties.

• Save the process definition, create a new instance, and execute it. Render the process instance. Click the process step to view its properties. The step should send the message as configured. 

Tips:

• Always configure the required Azure connection string, Message queue name, Message to send, and Message parameters properties. 
• Verify that the Azure connection string provides appropriate access to the Service Bus.
• Verify that the configured queue exists and that the workflow has permission to send messages.
• Use workflow values to construct dynamic messages where appropriate.
• Use Message parameters to map the values required by the message.
• Keep message structures consistent when multiple workflows send messages to the same queue.
• Avoid placing sensitive information in messages unless the application's security and data-handling requirements permit it.
• Use the True path to continue normal workflow processing.
• Use the False path for appropriate error handling, logging, notification, or recovery.
• Test the Service Bus integration independently before using it in production workflows.
• Ensure downstream applications understand the message structure produced by FlowWright.
• Use separate queues where different business processes require independent downstream processing.

Notes:

• Category: Azure. 
• Internal name: sendazuresbmessage. 
• Display name: Send Msg to Service Bus. 
• Label: Sends a message to the Azure Service Bus. 
• Namespace: FlowWright.Workflow.SendAzureSBMessage. 
• DLL: FlowWright.Workflow.dll. 
• Step definition type: Process. 
• Input connections: 2. 
• Output connections: 2. 
• Azure connection string: Required. 
• Message queue name: Required. 
• Message to send: Required. 
• Message parameters: Required. 
• The first three inputs use the string data type. 
• Message parameters use the MessageParms data type. 
• True and False execution paths are available. 
• The XML does not expose configurable retry count, timeout, batching, transaction, message priority, dead-letter settings, or result-storage properties. These should not be documented as features of this step based on the supplied XML.

sendAzureSBMessage vs. sendAzureEventHubMessage:

Both steps provide Azure messaging capabilities and have almost identical FlowWright-side configuration models.

The primary difference is the Azure messaging service and destination.

Service Bus

sendAzureSBMessage sends a message to Azure Service Bus. Its destination property is:

Message queue name (messageQueue).

Event Hub

sendAzureEventHubMessage sends a message to Azure Event Hub. Its destination property is:

Event hub name (eventHubName).

When to use sendAzureSBMessage

Use sendAzureSBMessage when the workflow needs to send a message to an Azure Service Bus queue.

Typical scenarios include:

• Sending work items to a downstream application
• Queue-based integration
• Asynchronous application processing
• Sending business messages to a specific queue
• Decoupling FlowWright from downstream applications
• Routing different types of work to separate queues

The step definition specifically identifies Azure Service Bus as its destination and exposes Message queue name as the destination property.

When to use sendAzureEventHubMessage

Use sendAzureEventHubMessage when the workflow needs to send a message to an Azure Event Hub.

Typical scenarios include:

• Publishing workflow events
• Sending business events to event-stream processing
• Publishing application events
• Integrating FlowWright with event-driven consumers
• Sending workflow-generated events to downstream event-processing systems

Its XML explicitly identifies Azure Event Hub as the destination and exposes Event hub name as the destination property.

Key Distinction

In short:

Use sendAzureSBMessage for Azure Service Bus queue messaging.

Use sendAzureEventHubMessage for Azure Event Hub messaging.

The two steps have essentially the same FlowWright-side configuration model:

• Azure connection string
• Destination
• Message
• Message parameters
• True/False execution paths

The only significant configuration difference in their XML definitions is the destination property

Definition Sample:

You may download the sample definition and later import it by drag-and-drop into the FlowWright Process Definition (XML file) page.

After importing the sample, verify and complete any environment-specific configuration, including:

• Azure connection string
• Service Bus queue name
• Message content
• Message parameter mappings
• Azure access permissions
• Workflow variable mappings
• Environment-specific configuration

After verifying the configuration, save the Process Definition before execution.

This follows the same definition-sample pattern used in the supplied executeSQL Step - FlowWright documentation, which instructs users to import the definition, verify missing configuration, save the definition, and then execute the process.

Click here to download the sample file.