Event Handler and Engine Customization

Automation Description

  1. When a document is changed, change it’s remarks to something.
 

       a. We are interested in events that occur when a document changes -  therefore define a new automation on a specific document class.

     b. Following changes the ‘remarks’ of the document that triggered the action:

       c. The ‘Document to Change’ field is the ID of the object to change, ‘Id’ equates to the document that triggered the action, if you click the button to the right of the textbox you’ll get a list of available Id’s – since you are changing a document you can only pick a document that is in some way directly related to the object that triggers the action (in this case also a document).

       d. So if we save, then change a document of this class, the remarks will be updated each time:

        e. An alternative would be to change a field on an object different to the one that triggered the action, I’ll pick child documents:

       f. If you ignore the ‘where’ clause for a moment, this would change the remarks on ALL child documents for the object that triggered the event.

 

      g. The where clause I’ve selected limits it to one document, if you read the whole screen it now says ‘change the remarks of all child documents where the parent document is the one that triggered the event and the prefix of the child document is D-0005’. (This is a silly example,  I would have like to rather had a where clause to filter on child class for example but this is currently limited to what the new search can do). 


               i.   Notice I said ‘Children.Right.Code’ (the code of the child document) and not just ‘Code’ (the code of the document that triggers the action).

  2. Change an attribute of a document that is related to a work order when the work order is changed.

       a. In this case we want to listen for events on work orders, so define and automation on a work order class.

       b. When you choose to change an attribute, you have to say which objects attribute to change – this object must be related to the object (a work order in this case) that triggers the event.

            i.   If I just said ‘Id’ in the ‘Object to Change’ field it would change an attribute of the work order that triggers the event.

           ii.   I chose ‘Documents.Document.Id’ which is documents related to a work order.

      c. The ‘Attribute to Change’ field is obviously the attribute that needs changing – the list you can pick from is decided by the type of object in the ‘Object to Change’ field. In this case I’ve chosen to change the attribute of a document related to the work order so I  can only choose document attributes.
 

      d. The where clause is again to narrow when the action is executed, in this case I’m just saying while the work order that triggered the event is still not approved.

           i.  (If we had the option to search on related documents ‘subject data’ field, I could for example say ‘ApprovalStatus = ‘N’ AND Documents.Document.SubjectData = ‘Y’ to only perform the action when the WO is not approved and the document is subject data).

Just to recap the tricky bits:

• The class for which you create automations decides what the object type is that must be modified to trigger an event.
• The object to change must be the object that triggers the event or another object directly related to it.
• The ‘attribute to change’ must be of the same type than the ‘object to change’
• The where clause refines the criteria for when or on which objects the action is performed. If you want to create criteria for objects related to the one that triggers the action you must use the appropriate criteria (which may be limited at this time), i.e. if object to change is ‘Documents.Document.Id’ then the criteria will have to be ‘Documents.Document.<field>’ to have any effect.

I Hope the above example will help you to do the Automation for required Events!