About Event Triggers

Event triggers provide a powerful way to customize ENOVIA product behavior through Program objects.

Triggers can contain up to three Programs. The triggers can work alone or together to blend functionality and control. You can write Programs that modify the behavior of many functions, and that behavior can vary depending on the circumstances. When you implement triggers you are actually creating hybrid versions of ENOVIA products. Triggers are powerful and can be used for troubleshooting problems that may arise.

Because of their complexity, you should thoroughly test event triggers in your development environment before implementing them in your production database.

Many business rules within an ENOVIA product are automated, especially rules within a business object's lifecycle. For example, when a part is promoted from Preliminary to Review, the system ensures that all the attached specifications are in the Review state and that a Find number other than the default has been specified. You can configure these automated processes by:

• Changing the argument inputs for existing rules. For example, instead of checking on the Find number, you could have the system check on a different attribute for parts, such as the classification or effectivity date.
• Adding new rules to check. For example, you could have the system also route the part to a specific role when a part is promoted.

To view details about a trigger, you can run a trigger report against the administrative object that uses the trigger. Refer to Generating a Trigger Report for instructions.

The context.getUser() and context.getPassword() methods give the current user and password, or empty strings if there is none.

For all validate password triggers (check, override, or action), the username, password, and vault are provided as the first, second and third arguments to the trigger program, JPO or Tcl.

When the ValidatePasswordCheck or ValidatePasswordAction trigger is called, it sets USER and PASSWORD to the TARGET username/password, and args 1,2,3 to the TARGET user/password/vault. This contrasts to the MQL print context still showing the current ORIGINAL user.

If the ValidatePasswordCheck or ValidatePasswordAction trigger calls other programs (Tcl or JPO), the USER macro will be reset to represent the current (ORIGINAL) context and will remain set to that value.

When using ValidatePassword triggers, you should rely only on the input to the configured trigger program (USER/PASSWORD or args 1,2,3 to provide info on the TARGET context), and rely on 'print context' to report the current (ORIGINAL) context.

If you need to pass the target context information to a called program, or refer to it after calling other programs, capture the values in local variables in the configured trigger and to pass/reference those local variables.

Triggers should be used to perform behind the scenes operations on data, and should not require any interaction with the end user.

Since triggers already enlarge the event transaction, you do not want to tie up database resources any longer than necessary. For example, creating an object locks a row in the database table corresponding to the object type. To maintain database integrity, other sessions attempting to access that table must wait until the create transaction is committed. If a trigger program creates a business object, it should avoid presenting any user interface (for example, a Tk dialog box, or a wizard) since this results in locking the database table until the user dismisses the dialog.

If it is absolutely necessary for a trigger to interact with the user, this condition can be avoided by deferring the action trigger to run outside the current transaction, by using the Execute Deferred setting in the program definition.

Existing policies may employ check and action triggers as defined before event triggers were available. These Programs are still valid and are executed in conjunction with event triggers as explained below. ENOVIA recommends that new checks and actions are attached as triggers to take advantage of the wider functionality.

1) Promote event transaction is started

   2) State1 promote Check Trigger is fired, if it exists.

      3) If Check blocks, then transaction aborts. 

         If not, State1 promote Override Trigger is fired if it exists.

      4) If event is not replaced:

         4.1) Promote Access is checked --> abort if no access

         4.2) State transition requirements satisfaction checked --> abort if not 
satisfied.

         4.3) State transition Check program executed (OLD CHECK) --> abort if fails.

         4.4) Is State1 disabled? --> abort if yes.

         4.5) Promote object to State2

         4.6) State2 Notification and Routing occurs, if any.

         4.7) State2 Action program executed (OLD ACTION)

         4.8) Add promote history to object.

5) Promote transaction committed.

6) State1 promote Action Trigger fires. 

State1's Action Trigger fires even though the old lifecycle action of State2 has already executed. Lifecycle actions are part of the event transaction: a failure in the lifecycle action program results in the promote transaction being rolled back. The exit code of a lifecycle action is checked, and if it returns a non-zero integer, the promotion is also rolled back.

When designing and testing triggers, it is highly recommended that you use a Log file so that when unexpected behavior occurs, you can trace it to the culprit program.