- 23 Oct 2020
- 5 Minutes to read
- Print
- DarkLight
- PDF
Automated Tasks
- Updated on 23 Oct 2020
- 5 Minutes to read
- Print
- DarkLight
- PDF
Many enterprises use Service Bus resources and Event Hubs to communicate between different services. As a part of integrating the services, it is important to ensure that the message flow across the services is healthy. Serverless360 provides a capability to automate the process of sending, deleting and resubmitting messages to Service Bus resources and facilitate the above-mentioned requirement.
Business Scenario
Consider a scenario where an application which listens for messages from a Service Bus Queue or Topic Subscription went unresponsive. Now, the number of messages inside the queue will start increasing gradually. Depending on the Time to Live value of the Service Bus resource, either the number of messages to be processed would drastically pile up, or the messages would get dead-lettered.
When the application resumes its operation, it might either get overloaded due to the increased number of messages to be processed or fail to process the dead- lettered messages.
Here Serverless360 automated tasks can be used to take necessary actions like:
- purge the active messages to reset the system
- perform dead- letter automated tasks like, Resubmit or Resubmit and Delete as an active message to be processed by the resumed system
This article will cover all capabilities under Serverless360 automated tasks.
Send Messages to Service Bus Resources
Inline Send Message automated task can be triggered from the context menu beside the Service Bus resource, Queue or a topic subscription within a Composite Application. The configuration can optionally be saved for further use. The saved automated tasks will be listed under, Automated Tasks section of Serverless360.
Send Message automated task can also be defined at Composite Application level, under the Automated Tasks section. The message body, custom properties and message count, schedule for the automated task to run can be configured and saved as a send message automated task.
Send Events to Azure Event Hubs
Send Event automated task can be created inline or at the Automated Tasks section to define and send bulk messages to Event Hub associated in a Composite Application. Created automated tasks can be edited to modify the configuration or schedule.
Send messages and send events automated tasks allow configuring properties:
- Send Batch - the specified number of messages/ events will be spilt across the batches
- Task Count - defines the number parallel instances
- Think time - would define the time gap between every message, in case of more than 1 batch, the time gap between every batch
- Message Count/ Event Data Count - number of messages or events to be sent by these automated tasks
Purge Messages from Service Bus Resources
Inline Purge Message automated task can be triggered from the context menu beside the Service Bus resource, Queue or a topic subscription associated within a Composite Application.
Purge message automated task offers the following configuration options:
- Choose between active and dead-letter messages of the Resource which should be purged
- Purge the messages enqueued before or at a specific time
- Purge specific number of messages
Enqueued time filter cannot be set for partition enabled Service Bus resources.
Service Bus Message Processing Automated Tasks
Managing active and dead-lettered messages can be achieved at ease using Serverless360 Service Bus Messaging automated tasks.
The operations that can be performed on the Service Bus Messages under automated tasks are
1. Resubmit – a copy of the message from the source Queue or Topic Subscription will be sent to the destination Queue or Topic Subscription.
2. Resubmit & Delete – a copy of the message from the source Queue or Topic Subscription will be sent to the destination Queue or Topic Subscription, and the message in the source Queue or Topic Subscription will be deleted.
3. Delete – messages in the selected Queue or Topic Subscription will be deleted.
The following configurations will let the action to be performed only on the selected messages.
1. Message count - The number of messages to be processed.
2. Message Enqueued At or Before - Message Enqueued At or Before - Only those messages enqueued at or before the specified time will be processed on enabling the Message Enqueued At or Before option.
3. Dead-Letter reason - In case of dead-letter message processing, it is possible to restrict the activity to work only on those messages dead lettered due to a specific dead-letter reason.
Message Enqueued At or Before and Dead-Letter reason filters cannot be applied for partition enabled entities.
Below is the illustration of creating an automated task to process active messages:
Below is the illustration of creating an automated task to process dead-letter messages:
Scheduling the automated tasks
The automated tasks can be scheduled with the following options:
- Initiate immediately after save
- Start time (from when the automated task should be initiated)
- Selected days on which the automated task should be performed
- Select the hours of the days when the automated task should be performed
- Restriction on recurrence either by the number of occurrences completed or by the end date.
Follow this illustration to run a configured automated task:
Back up Service Bus messages
Back up messages in Automated Tasks has been introduced to retain the copy of the Service Bus messages. In Serverless360, it is possible to back up the Service Bus messages being processed to a Storage blob associated under the Composite Application. It is possible to have multiple Storage Blob containers associated in a Composite Application.
Below is the snapshot of the message back up to associated Storage blob while processing active messages,
On successful back-ups, the Backup Path will be captured and shown under the History's section. From the path, the backed-up messages can be accessed. If the resubmission fails, the message will not be backed-up. Only successfully processed messages will be backed-up. The messages backed-up will be listed under a directory. The directory name is the Activity name appended with Timestamp. The messages will be stored under the directory. Each message is stored in a separate Blob under the directory. If an error occurs during back up or the message processing, in both the cases, the activity will be stopped, and the error reason will be captured.
Messages can be viewed from the Storage container chosen for back up. Below is the snapshot of the backed-up message stored under the Storage container,