Creating Scheduled Triggers
Scheduled triggers run on a specified schedule against all items matching the specified query. Any modifications appear as if the user selected in the Run As list made them.
The general steps required to create a scheduled event trigger are as follows:
1. Select the schedule trigger type, and assign a user to be recorded as performing the script the trigger runs.
2. Provide a description for the trigger.
3. Specify the schedule the trigger runs on.
4. Select an existing query to specify which items the query runs on.
|
|
Because scheduled triggers are based on queries, triggers are subject to visibility rules. Visibility rules restrict access to specific information based on project or item type.
|
5. Select a script file from the library for the trigger to run, and fill out the parameters for it.
|
|
• Scripts listed under the samples directory (for example, samples/breakLockNotification.js) are for configuration management and are not applicable to workflow and document management.
• Backlashes (\) in parameters are truncated after you save and run the trigger, for example, in a directory path. To avoid this, use forward slashes (/).
|
6. Assign the values to the fields the trigger modifies when it is run (if the trigger is one that modifies field values in the database).
Key Considerations
• All triggers run sequentially. This prevents an increase in the use of server resources each time a new trigger is added.
• Scheduled event triggers are evaluated on the Integrity Lifecycle Manager server’s time zone.
• Schedules are recomputed after any given run, at system startup, and when the triggers are changed. If a set of triggers takes longer to run than the next scheduled trigger is set to run at, the next schedule run of the trigger is missed.
• All modified items from a single scheduled trigger are part of one single transaction. If the trigger fails, no items are modified. Unlike rule-based triggers, since each trigger operates independently of its own batch of items, each trigger commits the change to the database independently.
• When the server is shut down or the service is stopped, the server does not reschedule triggers that were not able to run to during that time.
Related Links
