When a trigger fires, the system does not execute the workflow directly, but schedules it for immediate execution - with the specified priority - by Back4.

The workflow by default is scheduled with priority 0, no execution profile and no extra parameters, but it is possible to specify different values as well, e.g.:

cmd4 triggerwf -ids 3768,3770 -name TestTrigger -priority 50 -profile Retry3 -pars MyPar:value1 -username xxxx -password yyyy

where xxxx is the name of a GN4 user who can logon to system with sufficient permissions to perform this operation and yyyy is the password.

Note: the above connects to the default connection: should you want to specify the connection or server name, see cmd4 examples.

A trigger is always fired as a consequence of an action on an object: creation, edit, deleting, etc.. This object is passed to the workflow in the 'ObjectIds' property. Furher information are passed in named parameters:

•action_Cause: action causing the execution of the workflow - 'Create', 'Spike', 'UnSpike', 'PlaceIn', 'SendFrom', 'Modify', 'CheckOut', 'CheckIn', 'Index'.

•action_ObjectId: id of the object that have been created/deleted/unspiked/moved/modified/checked-out/checked-in.

•action_ContainerObjectId: it is set only for Referencing and ReferencingIndex triggers, and it is the id of the container object that caused the trigger to fire - usually this is the same as 'action_TriggerObjectId' (see below), except for referencing triggers defined without specifying a container object, in such cases 'action_TriggerObjectId' is 0 and action_ContainerObjectId specify the actual id of the container (e.g. the folder when the reference attribute is folderObject.fodlerRef).

•action_Login: the GUID of the login that created/deleted/unspiked/moved/modified/checked-out/checked-in the object, causing the trigger

•action_Time: UTC date-time specifying when the object has been created/deleted/unspiked/moved/modified/checked-out/checked-in (formatted as per XML standard - e.g. '2011-01-31T21:03:45.467Z')

•action_CheckOutUserIds: space-separated database ids of the user of all the current check-out of the object AFTER the action that caused the trigger. Valid only when action_Cause is 'CheckOut' or 'CheckIn'

•action_CheckOutCodes: space-separated codes (i.e. access classes: 'Normal', 'Protected', 'Special' and 'Content') of all the current check-out of the object AFTER the action that caused the trigger. Valid only when action_Cause is 'CheckOut' or 'CheckIn'

•action_CheckOutTimes: space-separated date-times of all the current check-out of the object AFTER the action that caused the trigger. Valid only when action_Cause is 'CheckOut' or 'CheckIn'

•action_CheckOutClientSpecIds: space-separated database ids of the client specification used for a persistent check-outs. 0 if the check-out is not persistent. Valid only when action_Cause is 'CheckOut' or 'CheckIn'

•action_TriggerMode: mode of the trigger that cause the execution of the workflow - 'Object' or 'Referencing'

•action_TriggerObjectId: id of the object monitored by the trigger that caused the execution of the workflow. It is identical to action_ObjectId except for referencing triggers

•action_TriggerAttrName: name of the attribute monitored by the trigger that caused the execution of the workflow

The sample workflow wf_TestTrigger.xml test the cause that triggered the workflow execution and logs all these information - producing entries like this:

<INFO>    Object 6404 sent from container 9 on 2011-03-26T19:40:29.263Z - Referencing trigger on object 9, attribute 'folderObject.folderRef'

It can be used as a starting point for more useful workflows (it is part of the distribution but it is NOT loaded automatically when a system is installed/updated).