Synchronous and Asynchronous callbacks¶

Since version 1.5, Content Script supports the definition of Event Callbacks: in response to specific actions performed on Content Server, it is possible to execute one or more Content Scripts.

The callbacks can be:

• synchronous: the script is executed within the same transaction as the triggering action. Synchronous callbacks are configured through the CSSynchEvents container.

• asynchronous: the triggering action completes normally. The callback script is executed later on. Asynchronous callbacks are configured in the CSEvents container.

The definition of Content Script callbacks is based on a convention over configuration approach. In order to register a new callback, a script should be placed somewhere in a nested container structure in the CSSynchEvents or CSEvents container, following a specific naming convention.

The first level under the container indicates the object or object subtype to which the callbacks are bound.

The naming convention is one of the following:

• D<nodeID>

• S<subtype>

where nodeID identifies the node unequivocally and subtype identifies a specific object subtype on Content Server.

Examples:

D2000 will intercept events on the Enterprise Workspace

S144 will intercept event on Document type objects (subtype: 144)

The second level should be once again a container and specifies the event type. The name of this container should be one of:

• ChildNodeAdded

• ChildNodeCreate

• NodeAddVersion

• NodeAddVersionPre

• NodeCopy

• NodeCreate

• NodeCreatePre

• NodeMove

• NodeRename

• NodeUpdate

• NodeUpdateCategories

Inside the Event Type container it is possible to place one or more Content Scripts that will be invoked when the callback is triggered.

In the following tables we present a summary of the supported Events and the information regarding the variables that are injected in the Execution Context, automatically by the framework, for each event. These variables can be useful to implement the required business logic within the Script.

The following table is related to the structure of the ChangeAssoc object, necessary to manage NodeUpdateCategories type events.

Synchronous Callbacks Configuration¶

Default Settings¶

Synchronous callbacks can significantly impact system performance. Therefore, they are disabled by default to ensure system stability.

Enabling Synchronous Callbacks¶

To enable synchronous callbacks, set the following property: amcs.core.callbackSynchEventsEnabled = true

User-Specific Configuration¶

In certain scenarios, it's beneficial to exclude specific users from synchronous callbacks, especially those performing bulk jobs. This exclusion helps in maintaining system efficiency and avoiding unnecessary load.

Specifying Excluded Users¶

• To exclude users, add their IDs to the amcs.core.callbacksUserIDs property.
• Multiple user IDs can be specified, separated by commas.
• Example format: 12345,6789

InterruptCallbackException - transaction roll-backed¶

There are cases in which you might want your synchronous callback to cause the roll-back of the original event transaction (to prevent its completion), e.g. you implemented a synch-callback triggered by the NodeCreate event and you want to use it to ensure that the node that is going to be created respects some specific business rule, for example, it's a PDF document. In this cases, you can just raise an un-catched InterruptCallback exception from within your callback script.

E.g.

log.error("Running ${self.parent.parent.name}:${self.parent.name}:${self.name} for $nodeID")
out << "This is the mother of all failures..."
throw new InterruptCallbackException("New Callback Exception...")