The following best practices are related to timer configuration and usage.
-
Use the Unity Scheduler Service for its multi-threaded functionality. By using the Unity Scheduler Service, one can have timers executing simultaneously on the same machine. This avoids the sequential, serial processing capabilities of the Workflow Server OnBase Client which is limited to one thread of execution, which could potentially cause the timers to wait for processing on the single threaded machine.
-
Dedicate multiple machines to monitor and execute timers, when necessary. If a Workflow deployment is performing extensive logic behind timers, consider off loading the timers to different machines. Many smaller Workflow deployments with less intensive work performed behind timers may not require multiple machines. When testing and analysis indicates that timers are consuming excessive processing power on a machine, consider adding another machine to distribute processing load.
-
Use timers to off load work. Consider sending a document to a queue where a timer will execute from the Workflow Server. It is not necessary to keep the user waiting until the document completes processing when no user input is expected.
-
Use the Unity Scheduler Service for timers.
-
Create realistic timer work intervals.
-
Before deleting a queue, it is recommended to remove timers from the queue configuration from the Workflow System Monitor in the OnBase Client or the Unity Management Console. If timers are configured for a queue that is going to be deleted, it is recommended to make sure that the timers associated with the queue to be deleted are removed from the Workflow System Monitor in the OnBase Client or the Unity Management Console, depending on the method being used to monitor timers.
-
Configure “Every” timer intervals with care. When configuring an “Every” timer, take special note of how frequently the timer needs to fire. Do not have the timer fire every five (5) minutes if the business process requires that it only needs to fire every one (1) hour.
-
Configure Timer Execution Windows: If one is using an “Every” or “After” timer, consider using a Timer Execution Window to limit when the timer will actually fire. For instance, if the timer only needs to run during business hours, configure an Execution Window from 8 AM to 5 PM. This frees database capacity for those processes that may already be running overnight (import processes, third party updates, Autofill Keyword Set imports, etc).
-
Use a Timer in Initial Queues. Initial queues should be configured to run all system work behind a timer in most scenarios. This ensures that all import processes are separated from Workflow logic and enables the import machine to perform at a higher level.
-
Do not let documents sit in a timer queue indefinitely. When a timer executes, the document should leave the queue in most cases.
-
Use the “At Certain Time” timer versus “Every” 1 Day/24 Hours timer. When the Workflow Server is restarted, “Every” timers will be reset and count down from the original interval (1 Day/24 Hours). If an “At Certain Time” timer is used, when the Workflow Server is restarted, the existing timer count will be respected.
-
Use “After” timers with care. The main point to consider with an “After” timer is that an “After” timer configured for after four (4) minutes is actually polling (to check elapsed time a document has been in the queue) every one (1) minute. An “After” timer configured for after five (5) days is polling every five (5) minutes. Even though the system is polling regularly, it only executes the defined tasks under the timer when documents are returned. There are very few business cases that require an “After” timer. If one is considering using an “After” timer, evaluate if one could use an “At Certain Time” or “Every” timer that has Workflow logic configured to first check “has this document been in the queue for X interval” (Key-Check Date Keyword on this/Related Document) and then perform the work if true.