Azure Services Module Overview
- 31 Mar 2022
- 4 Minutes to read
-
Print
-
DarkLight
Azure Services Module Overview
- Updated on 31 Mar 2022
- 4 Minutes to read
-
Print
-
DarkLight
Module Details | |
| Installation Location | Core Module |
| Step Location | Integration > Azure |
| Settings Location | System > Settings > Azure Settings |
| Prerequisites |
|
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.
Configuring Azure Services
- 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.
Configuration Options Function Display Name Prompts for the name to appear for this message queue in the Decisions environment. Messaging Type Allows selection of the messaging type (Queue or Subscription to Topic*) Queue Name Prompts for the actual name of the queue as it is configured on the messaging server. Subscription Name* Prompts for the name of the subscription for topics Session ID Prompts for the session ID of the user Custom Connection String Configures 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. Once it completes the test, a popup will display the number of messages.
Control Options Function 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.
To add a message handler, navigate to System (gear icon) > Jobs and Events > Message Queue Handlers then select the ADD MESSAGE HANDLER button at the top.
| Configuration Options | Function | |
|---|---|---|
| Handler Name | This is the name that will appear for this handler in the Decisions environment. | |
| Message Handling | Allows selection of how the message handler will handles received messages. | |
| 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. Select an Azure Message Queue. | |
Get/Lease Message Handling
The Get function reads messages from the message server and communicates to the server that the messages have been processed then typically 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 e.g. Decisions, thus preventing them from delivering to any other client requesting 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 e.g. 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 its messages cannot be lost in memory before getting processed in the cases that the Decisions server is shut down or rebooted.
Message Queue Handler Flow
The Message Queue Handler Flow Flow Behavior can be accessed by clicking PICK OR CREATE HANDLER FLOW in the Add Message Handler window then selecting CREATE.
This Flow Behavior subscribes to a message queue and handles each message from the queue as it enters the queue. The Flow will run as the Decisions System and not as a user.
Message Queue Handler Flows generates with three inputs called HandlerId, Message, and Routing Key. 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.
| Input Name | Function |
|---|---|
| HandlerID | Identifies a message as received to the message server |
| Message | Used as a payload field containing raw data for message contents |
| Routing Key | A label not a part of the message that communicates with the message server to route a message sent to an exchange onto a specific queue. |
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.
For further information on Modules, visit the Decisions Forum.
Was this article helpful?
