ChangeTrigger

Note: ChangeTriggers are an advanced concept and although they have been tested and are behaving as expected, they have not been used extensively in production environments yet.

ChangeTriggerType

A ChangeTriggerType defines a class which is called before and / or after a call to a Cinnamon API method is made. This class is provided with the request params as well as the server's response (for postmethod call).  It has the following fields:

• name - string, the name of the CTT

• trigger class - the name of the Java class that will be called with the request (and response) params. This class must implement the ITrigger interface.

ChangeTrigger

A ChangeTrigger object combines the trigger type with a specific Cinnamon API method. It has the following fields (besides the obligatory id and obj_version etc):

• active - boolean value to determine if this trigger is active or not.
• command - the name of the API method, for example "setcontent"
• pre_trigger - boolean value, determines if the ChangeTrigger will be executed before the command is run
  
• post_trigger - boolean value, determines if the ChangeTrigger will be executed after the command has run
• ranking - integer value, so you can sort ChangeTriggers and choose which is run first. Lower ranking value means higher priority.
• trigger type - foreign key to ChangeTriggerType table. You can use the same type for as many ChangeTriggers as you want, for example to have a specialized logging class store every API method call in the database.
  

ChangeTriggers are currently only available on methods which have been annotated in the source code as being triggerable (@CinnamonMethod(checkTrigger = "true") ), so at the moment the only method which will trigger is setContent.

Possible uses of ChangeTrigger

ChangeTrigges may be used for specialized logging of server events (which may not be available to a general logging mechanism) as well as transformation of data into (filtering, legacy data adapters). They may be used to enhance workflow and lifecycle concepts (for example, automatically creating a translation workflow task whenever a new version of an already translated document is checked in).

Further development may include:

• add checkTrigger to all API methods which can possibly profit from them
  
• remove the checkTrigger annotation and simply check for each method call if one or more pre- or post-trigger classes should be run. It is a trade-off between having additional bookkeeping (for the trigger checks) and having a simple interface.
• ChangeTriggers are not yet integrated into Dandelion (the AdminTool), this should be fixed.
• Example classes for ChangeTriggers are needed.