Server Administration > Automate Tasks and Calculate Data Using Event Triggers > Planning Configuration Management Triggers
Planning Configuration Management Triggers
To avoid unpredictable event trigger behavior, plan your event triggers in the following way:
1. First choose the scope of the event trigger
a. Event triggers that you want to apply to all operations should be set in the global context.
b. Event triggers that are related only to a specific configuration management project should be set in the project context.
2. Decide whether your event triggers should occur as a pre-event or post-event.
a. Pre-event triggers can return a code that indicates the operation should not proceed and are therefore most applicable for events that you want to prevent.
b. Post-event triggers are more useful for logging information on a successful operation or for performing linked operations. The post-event trigger executes regardless of whether the event was successful, but the administrator has access to any logged information.
Scripts provide significant flexibility in creating event triggers. You can use one script for more than one event. For the same event you can also point to a script in the global context and another script in the configuration management project context.
3. Consider the following:
Be aware of system security. JavaScript event triggers are expressive and run on the server under the permissions of the administrator. Event triggers therefore have the potential to affect file and system security.
Limit event triggers to only those things you believe to be beneficial to your environment. Event triggers affect the duration of the command from the client’s perspective and therefore have the potential to degrade performance.
The Windchill RV&S server can process commands in parallel—a feature that allows users to initiate a second command even if the first has not completed.
Instead of having a script for each configuration management event, you could have a script for a group of configuration management events. Then in that script, execute different code depending on which event has fired (the event that fired the trigger can be retrieved from a Bean).