Azure Services Module Overview
- 14 Dec 2021
- 3 Minutes to read
- Print
- DarkLight
This documentation version is deprecated, please click here for the latest version.
Azure Services Module Overview
- Updated on 14 Dec 2021
- 3 Minutes to read
- Print
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
Overview
Azure Services is a messaging system that can be installed as a module allowing Decisions to integrate application to application communication. Azure Services Queue settings are available and can be configured after the installation. For more information on the messaging services, see Setup Messaging Overview.
Change in Module name
The Azure messaging module has been renamed from "Azure Service Bus" to "Azure Service". The Azure Service Bus module has been removed from the Decisions platform, please install the Azure Service module to integrate with Azure.
Prerequisites:
- Existing Microsoft Azure Service Bus Account
- Installation of the Azure Services Module. To learn how to install modules, see Installing Modules in Decisions.
Example
This example will demonstrate how to configure the Azure Services Module.
- Navigate to System > Jobs and Events > Message Queues. Click ADD AZURE QUEUE.
- On the Add Azure Queue window, configure the options with the correct information. When complete, click SAVE.
Display Name This is the name that will appear for this message queue in the Decisions environment. Queue Name This is the actual name of the queue as it is configured on the messaging server. Custom Connection String This can be used to configure a string that tells Decisions where and how to connect to the Azure message bus server. The connection string can be obtained from the Azure configuration console. 
- To verify connectivity, right-click the Queue, select Control, and click Test Queue. When complete a popup will display the number of messages.
Resync Queue Recreates the message queues if necessary and re-synchronizes with the message server. Start Queue Starts processing messages on the message queues (if stopped). Stop Queue Stops processing messages on the message queues and the message server will hold any unprocessed messages. 
Message Handler
Adding a message handler to the message queue offers configurable options for how received messages are handled in the queue.
| Configuration Options | Function |
|---|---|
| Handler Name | This is the name that will appear for this handler in the Decisions environment. |
| Message Handling | This shows a dropdown list of options to choose from regarding how to handle the messages that are received. |
| Lease: Locks the message in the queue | |
| Lease w/ Expire: Locks the message in the queue with an auto-timeout. | |
| Get: Receives the message and leaves it in the queue after it has been processed. | |
| Get and Remove: Receives the message and removes the message after it has been processed. | |
| Active Flow Count | The maximum number of simultaneous messages that Decisions will process. |
| Handler Flow | The Flow is used to process messages that appear in the queue. |
| Message Queue | The queue for the handler to listen on. |
Get/Lease Message Handling
The Get function reads messages from the message server and communicates to the server that the messages have been processed and typically, the message server removes them from the queue. This mode instructs the relevant message server or third-party client to pull messages off of the message server as fast as possible while keeping them on an in-memory list for Decisions to reference.
The Lease function reads messages from the message server and communicates to the server that the messages have been processed in the condition that every message must be processed. The message server keeps the messages in the queue and marks them as "leased" by a client (Decisions); this prevents them from delivering to any other client that requests messages from the queue. When Decisions is finished handling the message by running the Handler Flow, it tells the message server that the message has been handled, and the message server marks it for deletion. If Decisions is unable to complete this (for example, if the Handler Flow encountered an error), then the lease on that message will eventually time out and the message server will mark it as deliverable to another client.
The Leased function is slightly slower than the Get functions, but it does not encounter a problem where messages can be lost in memory before getting processed, in the case that the Decisions server is shut down or rebooted.
Message Queue Handler Flow
The Message Queue Handler Flow template can be accessed by selecting the Flows [Advanced] section after selecting the CREATE FLOW button in a Designer Folder. Selecting this Flow template automatically creates a Flow that uses the Message Queue Handler Flow behavior. Because of this, the Flow has two special inputs called HandlerId and Message. The Handler ID is used to identify that a message is received with the message server and the Message is used as the payload field that contains raw data for message contents.
Building a Message Handler Flow will require different steps that are contingent on the content of the message being formatted. Formats from simple text to XML/JSON have different steps that are used when it comes to extracting the contents of a message. Once the appropriate steps have been configured with message handling logic, they can be used to create a new Message Handler in Decisions.
Was this article helpful?
