Rule Queue
The Rule Queue page
This page is found in the Admin Center->System Administration menu.
It displays all instances of asynchronous (in other words, the processes that can run in the background without notifying the user in real-time) Rule Classes, such as HTTP Call, Geocoding, Copy EFile, etc.
Each entry on this page provides details of when the Rule was submitted and how it was processed.
Column Name | Description |
|---|---|
Rule Queue ID | The unique ID that references the specific instance of the Rule submitted to the Rule Queue. |
Thread ID | To manage CPU load, queues can be run in multiple threads. The total number needs to be managed against the capacity of the DB. |
Rule Service | Rule Queues are processed by the services.jar processor on one or more App Servers. |
Started Date | The date that the Rule Queue instance was started or, more precisely, when the asynchronous rule instance started running. |
Creation Date | The date that the Rule Queue instance was created at. |
Processing Date | The date that a Rule Queue instance was processed on. There can be a delay if there are other instances in the queue. |
Rule | The name of the Rule. |
User | The user that initiated the rule instance run. |
ID1 | The underlying entity for the trigger: trackors for triggers like “Before/After Trackor Create/Update/Delete”, workflows for WF-related triggers, etc. |
ID2 | The secondary triggering entitiy for the rule: Child Trackor for Relation-triggered Rules, 1/0 for (un)successful login for login-related triggers. |
Rule Queue Status | The execution/processing status of the Rule. |
Exception Message | The error or exception message after the rule instance is processed. |
Re-run By | The user that resubmitted the Rule instance (Rule Queue ID) to the queue. |
Re-run At | The time that the Rule instance (Rule Queue ID) was resubmitted to the queue at. |
Mass Re-run Rules
Allows rescheduling of the rule queue records (including those for the HTTP Call rule classes) displayed in the grid. When this action is selected and the user accepts the warning message all Rule Queue ID entries in the grid will be resubmitted to the rule queue. This action doesn't create a new rule queue record. Instead, it resets the existing one so it will be re-run by the rule service.
The new "Re-run At" and "Re-run By" columns are populated with the current date and user.
Useful after Filtering the Grid so that it displays the desired set of Rule Classes.
Mass Change Rule Service
This is a form button rule that allows users to reassign all instances in the grid to a different ‘Service’.
Rules and Notifications can be assigned to their respective Services as a part of the Rule or Notification definitions. This assignment ensures that all new instances of the specific Rule or Notification will be executed by the selected Service.
In the case of Rule Queue, Administrators (provided they have the necessary privileges) can re-assign Services to Rule instances if the Rules are not yet executed (Status: Scheduled or Queued).
Individual Rule instances can be re-assigned to a different Service/Queue by clicking the ‘Details’ button and changing the ‘Service’ dropdown value, while the Mass Change Rule Service button can be used to re-assign Service for all instances in the grid and is useful after Filtering the Grid so that it displays the desired set of Rule Classes.
To view the details of a particular Rule, click on the Rule ID link, then click on the Details button.
If the Rule is not executing at the moment, the OK and Apply buttons will be available, as well as the Rule Service drop-down.
