perform checks and actions when events occur
Event triggers provide a powerful way to customize
the application behavior, implementing business rules. Triggers
are programs that can be executed upon an object for a large class
of events. Most of the events associated with objects and connections,
such as creation, deletion, modification of field's values, promotion
to another stage, etc. support Triggers.
Triggers can perform checks and actions when an event occur; their
associated programs can be written to modify the behavior of many
functions, and that behavior can vary depending on the circumstances.
For example a trigger can block an event when a particular requirement
is not satisfied or can extend the event action by executing additional
Most of the events associated with objects and links support Triggers.
Triggers are added to class, linktype, field and stage definitions
in much the same way as fields and methods are added to the class
definition, and when used in classes, they are likewise inherited.
With event triggers, it is possible to programmatically guarantee
certain events cause (or are replaced by) other actions. For example,
when a field value is modified, a connection could occur or when
the name of an object is changed, also the names of a related objects
are forced to be changed or when an object is promoted to the next
stage an email should be sent to some users.
Each event is implicitly wrapped in a transaction boundary
and the achievement of a new status is not complete until the transaction
is committed (thus ensuring database consistency). When event occurs,
a transaction is opened: first of all the check program is
executed (if defined), subsequently the action related to the event
is performed and finally an additional action program is
executed (if defined) to complete the process. If at least one operation
fails, the whole transaction will abort.
Triggers can be added to Field, Class, Linktype and Lifecycle-stage
definitions; the following table reports the events associated with
each kind of administrative element:
||object (instance) events
||link (instance) events
For each event in the above table you can create a
couple of programs: one for checking if all event's requirements
are met and the other to perform additional actions. For example,
you can define a trigger-program to check if a Movie was already
rented before create a connection between the Movie and a customer,
and you can define a trigger-program to progress automatically the
Movie object toward the "Rented" stage after the connection
You can also use the same program to regress the Movie back to the
"Available" stage as a consequence of the disconnection
of the two objects. This is possible because when a trigger-program
runs, it receives, as input information, the trigger event type
and other additional data that represent the current environment
parameters (like object's class, name, revision, current stage,
etc. ). The list of trigger-parameters
depend on the event type.
A program source code implements the ProgramCode
vArgs,Framework framework) throws
||.... PROGRAM CODE ....
Refer to the "Program
section to know how to write the trigger-program code.
Once created, you can link these programs in the
Trigger tab of relative administrative object specifying the event
type represented by them.
Tricks: when you need to create a new trigger program, just write the name in the "Filter" text field and double click over it. The form for creating a new program will be opened with the name and program type already compiled.
A event can also start a workflow-process
when it occours: if a workflow is associated to a specific event,
the new process generated as workflow-instance inherits the object
and many of its properties as global parameters (the process holder
will be the object holder).
When designing Triggers, programmers should
keep in mind that several Triggers may be
fired by what appears to be a single event. For example, a simple
object-edit event activate generates a sequence
of trigger calls
and if defined, a sequence of running processes related to each
Trigger programmers should carefully evaluate exactly where (which
event and trigger) their logic should be introduced. Also, remember
that if programs exist in many of these Triggers, performance will
Trigger programmers should also carefully take
into account the explicit and implicit trigger recursion
to avoid infinite loops. Explicit recursion is when a program execute
itself; this type of recursion is easy to spot and is a powerful
mechanism when used properly. On the other hand, implicit recursion
is caused when a trigger program generates the same event with which
it is associated. This form of recursion is more difficult to spot
because the running program may be part of a program that was triggered
by a totally different event.