Package com.orchestranetworks.schema.trigger

Class InstanceTrigger

  • public abstract class InstanceTrigger
extends Object
    Specifies methods that are automatically executed when certain operations are performed on a dataset.

    Definition in the data model

    The trigger must be declared under the element xs:annotation/xs:appinfo: 

     <osd:trigger class="com.foo.MyDataSetTrigger" />
    where com.foo.MyDataSetTrigger is the fully qualified name of the class implementing this interface. It is also possible to set additional JavaBean properties: 
     <osd:trigger class="com.foo.MyDataSetTrigger">
         <param1>...</param1>
         <param2>...</param2>
 </osd:trigger>
    where param1 and param2 are JavaBean properties of the specified class.

    For more information, see the JavaBean specification.

    Life cycle

    1. When the data model is loaded:
      1. the specified class is instantiated through its default constructor and the JavaBean property setters are called (in the example above, setParam1(...) and setParam2(...));
      2. the method setup(TriggerSetupContext) is called on the new instance.
    2. During the operational phase: the methods handle... are called each time the associated operation is executed.

    If several operations are defined for the same dataset, they are not executed in any particular order.

    Restrictions

    Dataset triggers are not invoked in the following contexts:

    Functional guard and exceptions

    In the context of a method handleBefore..., it is possible to implement a guard by throwing an OperationException if some functional conditions on the data are not satisfied. This will cancel the current transaction.

    Throwing an OperationException instead of a RuntimeException provides the end-user with the benefit of a well-localizable and a more user-friendly error message, when the error happens in the context of the user interface. In all cases, the current transaction is aborted.

    Note: In further detail, if a ProcedureContext raises an exception, any preceding updates made on the repository during nested update executions are first cancelled before the corresponding update method catches the exception. This additional feature is for ensuring that the repository and cache remain consistent, even if the corresponding update method catches the exception.