Aegis Workflow 101 - Triggers

Aegis Workflow 101 - Triggers

Welcome to Part 4 of Aegis Workflow 101.  This time we look at Triggers which define the conditions when workitems should start as well as well as other behavior which we will learn about below.

In the last topic we learned about events.  When events arrive into Aegis they are written to the Aegis Database but they are also passed onto the correlation engine for evaluation against a set of rules.  These rules are defined in triggers.  When an event or series of events matching those rules occur the correlation engine tells Aegis to start an instance of a particular workflow.

There is one in-built trigger which operates differently - this is the 'Manual Trigger' which allows you to manually start a workitem.  This is a really powerful trigger as it allows you to test workflows without having to wait for / recreate event conditions to trigger a workitem.  Many workflows may only ever have a manual trigger.

It is also possible to have a number of triggers associated with the same process.


Creating a Trigger

A Trigger is not specific to workflow so can be created independent of any workflow in the Configuration Console in the Administration - Triggers section.

h1

'Initiate New Workitem If' is required in all triggers.  It defines the list of events from which all or any of those events must occur in a time window in order to initiate a new workitem.  When you add a new event event expression you get a lot of options.

h2

The 2 most commonly used (and easiest) are :

'Any Event of a Specific Type and Attribute value' :  Example is an event of type Email.Message with the Message Subject attribute containing 'emergency'.  This is why we looked at events first, you will need to know what the event attributes are of a real event in order to create this filter.

'One Event of a Specific Type' : Example is any time an event of type Email.Message occurs.


So continuing to use the Email.Message event as an example, we want to add more criteria.  Now we want the Message Subject attribute containing 'emergency' and we also want the From Field to be equal to admin@sigea.moc.  The normal way people will do this is as in the next screenshot - which is the wrong way to do it!

h3

Remember that I said this is a list of events, its not necessarily the same event.  So 2 different email events could occur, one with the correct subject and the other with the correct FROM field and that would match this trigger.  It would be much clearer if the criteria were from 2 different event types such as :

Any Email.Message event where ....

Any AppManager.Event event where ....

This is much clearer that the criteria is talking about two different events both of which must occur in the time window.  So how is it done then?  We create our own event definition in Trigger Event Definitions which is accessible through Administration - Triggering Event Definitions.

The configuration is very similar to creating the event filter in a trigger except all attributes need to be chosen from the same event type.

h4

I have now created my own Event Definition.  Now I can create a much simpler trigger using 'One Event of a Specific Type' and choosing 'Select Base Event Type or Named Event Definition' and choosing your new event definition from the list.  You'll also get the option to create an 'in-place event definition' instead - I prefer to avoid this as its not saved as a re-usable event definition.

h5

Once a trigger is created it is now available to be added to as many processes as you like to a start of workitem activity.  If you have multiple triggers on a workflow you can put them into an evaluation order although usually the triggers I have seen are rarely related.  Only one trigger in the list will initiate the workitem.

Now we know the basics of initiating a new workflow, lets take a look a the other options in the trigger definition.

Block New WorkItem If and Append to Previous Workitem If

These are essentially the same thing.  Both relate to how to handle  events which occur while a workitem initiated by this trigger is already running.  The most common use-case is simply that you don't want 2 workitems investigating the exact same issue.  So for example if an event is generated every 5 minutes to say you are low on disk space on a particular server, you only want one workitem running to handle that situation.  Instead you can choose to append or block the event.  In both cases the new event(s) are associated with the workitem which is already running.  Not only that but this initiates a new 'flow' in that workitem starting at the start of workitem which will definitely cause problems if the workflow logic doesn't handle appended or blocked events.  Instead logic needs to be added to the workflow so that appended/blocked events are sent through a different path through the workflow, often directly to the end of workflow.

I will normally create a block rule when I don't care about the event, I just want to prevent it starting another workitem, and I send it directly to the end of workitem.  When the event may have some value I send it via a different branch and do perhaps some minimal operations on it.  It may be simply to 'acknowledge' the event on the target system, or maybe update a service desk ticket with the eventids which were also seen with the same issue.  I will be doing a topic on making decisions and will revisit this area there.


Custom Attributes

We are covering variables in the next topic, but here Custom Attributes are possible to be generated in the trigger and are accessible in Input Builder via 'Trigger Custom Attribute'.  It basically allows you to create a new value my manipulating attributes of an event.  I am personally not a fan of this in most circumstances, I prefer to do this in the workflow but its a matter of choice.


Once a trigger has been saved it can be freely edited until it is associated with a workflow which is put into production.  At that point no more changes can be made to that revision of the trigger - a new revision needs to be created instead.  This allows multiple revisions of the same trigger to be used simultaneously and also allows to choose which revision to use.

We previously ignored Policies when putting a workflow into production but now we know about triggers we will take a look.

h6

Policies include two configurable options.

Event Consumption Policy

This setting defines how events are handled once they are associated with a workitem.  The default value is consume.  This basically means that once an event matches a trigger it is not available to trigger any other workitems and this is the most common use you will see.

'Mark and Pass' marks the event as already being used but passes it along to be evaluated by other triggers.  Only processes set to 'Consume' or 'Mark and Pass' can trigger based on marked events.

The last two options deal with events which have been not already been marked.

'Use if Not Marked' - this is basically the same as Consume but it will not consider marked events.

'Use if Not Marked and Pass' - this is basically the same as 'Mark and Pass' but will not consider marked events.  Only processes set to 'Consume' or 'Mark and Pass' can trigger based on marked events.


Trigger Processing Order

This the easier of the two to understand.  Since the same trigger can be added to multiple workflows, how does Aegis decide which workflow should trigger based on the same criteria?  You guessed it, Trigger Processing Order.  You can set a Priority number from 0 to 100, 100 being the highest priority.  Aegis will trigger workflows with the highest priority first, and events are made available to other workflows depending on the Event consumption Policy of the process.

 

Next up is: Aegis Workflow 101 - Variables

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2016-04-20 18:43
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.