Supported Trigger Events

In a situation where a Child type both inherits a trigger and defines a trigger on the same event (the native trigger), the native trigger is executed, and is inherited by any further Child type.

The ENOVIA Integrations Exchange Framework (IEF) and collaborative products run into this situation, as described in the scenario below

1. ENOVIA Business Process Services is installed and defines the CAD Drawing type with several triggers, including 1 on the Revise event.
2. The IEF is installed and defines the MCAD Drawing type, derived from the CAD Drawing type and also defines its own revise event trigger.
3. An integration such as ProE is installed, and defines the ProE Drawing type, derived from the MCAD Drawing type.
4. The revise event trigger that the ProE Drawing type inherits is the one defined in the IEF (for the MCAD Drawing type) not the one from ENOVIA Business Process Services assigned to the CAD Drawing type.

The following Business Object events support Triggers. These Triggers can be added to Type definitions.

Refer to the "Working With Types" chapter in the MQL Guide for more information and syntax for adding triggers to Type definitions.

Attributes can have triggers on the modify event.

You can define triggers on business object or relationship modifyattribute events, which are fired whenever any attribute is modified (once per attribute modified), or on an attribute's modify event, which is fired when that attribute in particular is modified.

You can configure a trigger for a "general" modify event of a businessobject or relationship.

When defined on a type, whenever a modification is made to any attribute or the description of a business object of that type, the program associated with the trigger is invoked at the end of the outside transaction. When defined on a relationship, modifications to any attribute on a connection of that relationship type cause the trigger to fire. This is in addition to any modifyattribute or modifydescription triggers when those events occur.

The "general" modify event supports only Action triggers; it cannot be configured with a Check or Override trigger.

The trigger program is invoked once per object/relationship per transaction. If multiple changes are made within a transaction, the trigger program only runs once. If a transaction operates on several objects, the trigger program will be run once for each object.

The programs associated with modify triggers must be JPOs. In addition, these programs will always run as deferred. If configured to run immediately, that setting is ignored and program execution is still deferred.

Because the program is deferred, if any errors occur during the program execution, all prior changes within the transaction boundary are not rolled back. In addition, the trigger program should not trigger another modify event on the same business object or connection; if it does, an error will be thrown.

The trigger for the modify event supports these generic macros:

• $USER
• $TRIGGER_USER

Macros specific to the business object or relationship are not available to the trigger program. In addition to the above macros, these arguments are passed to the JPO:

• $ID--the business object ID or the connection ID
• $IDTYPE--Type ID or Relationship ID
• $TRANSHISTORY--history items for operations in the current transaction

$TRANSHISTORY is a carriage return delimited string listing all changes to the business object within the transaction. Programs should process the output of this macro in the same manner as output from "print bus T N R select history".

History information is passed to the trigger program even if history is turned off.

History information for workflow events is not part of $TRANSHISTORY.

There are several options when designing triggers for business object or connection modifications. The tables below point out the differences.

Relationships additionally support the modifyfrom and modifyto events to address the specific scenarios of how objects on either end of a relationship can be replaced by another object, and as such they do not affect attribute or description modification.

The modifyto and modifyfrom events have these macros available to them:

The following relationship events support Triggers, and can be added to Relationship definitions.

Refer to the "Working with Metadata" chapter of the MQL Guide for more information and syntax for adding triggers to Relationship definitions.

See Supported Trigger Events for specific information about using these trigger events.

The following lifecycle events support Triggers. These Triggers can be added to Policy definitions.

Refer to "Working with Metadata" chapter of of the MQL Guide for more information and syntax for adding triggers to Policy definitions.

You can configure a transaction trigger that will be invoked one time for all events on a type or relationship at the end of a transaction.

You can configure a transaction trigger that will be invoked one time for all events on a type or relationship at the end of a transaction. When defined on a type or relationship, whenever a business object or connection of that type or relationship is modified, at the end of the outside transaction, the program associated with the transaction trigger is invoked.

If both a transaction trigger and a general modify trigger are defined for a type, both triggers will be invoked at the end of the outside transaction.

Transaction triggers can only be Action triggers; and cannot be configured as a Check or Override trigger.

The programs associated with transaction triggers must be JPOs. In addition, these programs will always run as deferred. If configured to run immediately, that setting is ignored and program execution is still deferred.

Because the program is deferred, if any errors occur during the program execution, all prior changes within the transaction boundary are not rolled back. In addition, the trigger program should not trigger another transaction event on the same business object or connection; if it does, an error will be thrown.

Transaction trigger JPOs are not invoked for objects that are deleted inside a transaction.

Macros specific to the type or relationship are not available to the trigger program. Only one macro can be passed as an input parameter to a program for a transaction trigger:

• $TRANSHISTORY--history items for operations in the current transaction

$TRANSHISTORY is a carriage return delimited string listing all changes to the business object within the transaction. Programs should process the output of this macro in the same manner as output from "print bus T N R select history". The string size limit for this macro is 2^31-1 bytes. If this limit is exceeded, the program call is split and multiple calls may be made depending on the amount of history information.

Each time a transaction trigger is invoked, information on all events that have occurred is passed to the program. For example, if business object 1 is promoted and the owner of business object 2 is changed, at the end of the transaction, the transaction trigger is invoked on time and $TRANSHISTORY is populated.

History information is passed to the trigger program even if history is turned off.

History information for workflow events is not part of $TRANSHISTORY.

The following business object events support transaction triggers:

The following connection events support transaction triggers:

The following Workflow and Activity events support triggers. These Triggers are defined in the Process and Activity objects.

Process events

Auto Activity Events

Interactive Activity Events

Refer to the "Working with Workflows" chapter of the MQL Guide for more information on adding triggers to processes and activities.