Aegis Workflow 101 - Events

Aegis Workflow 101 - Events

Welcome to Part 3 of Aegis Workflow 101.  This time we look at Events which act as signals to Aegis to perform some action, from meeting the criteria to starting a workitem to signalling a workitem should end.  Inside the Aegis Web Console Aegis events are view able on the Events tab.

All Aegis events have a number of common General Attributes, such as the Event Type, Severity , Status, Creation Time etc.  and Event Type Specific Attributes which are unique to a type of event.  An event from the Database adapter for example will include Database and Table attributes for example.


The Web Console lists the event details as decided by the configuration of the Adapter.  In the Screenshot 'Other Attributes' are also attributes common to all events.  Typically (but not a rule) is all the more relevant event attributes will be shown in the 'General' and 'Specific' sections.

Events in Aegis aren't meant to be modified, you can't change their state or add comments etc.  However depending on the adapter, Aegis can be used to update the event/alert/incident on the target system which generated the event in Aegis.


Event Sources

Most commonly, Events are generated in Aegis by Adapters.  Out of the box Aegis comes with a couple of inbuilt adapters which can generate events : Mail Adapter, Scheduler Adapter and Database Adapter.

The Mail Adapter allows you to configure monitoring for new emails on a monitored email mailbox (from MS Exchange, POP3 Mail or IMAP).  When a new mail is detected, the adapter generates an event in Aegis.

The Database adapter allows you to monitor a database table for new rows added to the table.  When a new row is detected, an event with the row details is generated in Aegis.

The Scheduler Adapter allows you to create timetables and schedules when to generate timed events.

Most adapters do include an event generation capability based on some condition occurring on the target system.

Outside of adapters, Events can also be generated by other means.  The Aegis installer allows you to install the event generator component on remote systems which allows event generation from the command line.  Events can also be generated by remote systems via the Aegis Webservices.  Aegis also has an activity which can run inside a workflow to generate an event.


Using Events

The biggest use of events is in Triggers which define the conditions of when a workitem should be initiated, or what events should be appended or blocked form a workitem.  Triggers is the next Workflow 101 topic so I will cover that separately.

There are other uses of events other than just triggering an event.  For example you might want to wait for an event to occur before proceeding in a workflow.  For example if your workflow sends an email to a user to approve a request, the workflow might wait for an email reply.  The Mail adapter generates an event in Aegis when the new mail arrives.  Aegis detects the correct email and verifies the body of the email contains an approve/deny message and then continues accordingly (note the risk of human error here!  workflows need to expect and handle human error where manual actions are required).  But how does Aegis know the correct email has arrived?  We use the 'Wait for Aegis Event' activity which is in the 'Basic Workflow Control (NetIQ)' activity library.


First you need to define which Adapter you are waiting for the event from.  For emails you need to know if you are using the Exchange Adapter or a Email adapter.  In my case I am choosing Email adapter.  For 'Event Type' there is one choice.  Some adapters will have different types of events to choose from.  Next we define the Event Filter, which is where we use criteria to identify the correct email has arrived in the mailbox.


In Filter Rules you can enter a number of rules, the first rule is already provided but not configured.  At this point you will realize the email originally sent to the user should have some unique characteristics that will identify it so we know for sure the right email has arrived.  There are activities to generated random string values or unique identifiers which could be added to the mail subject or body.  Often though the workitemid is simply used as this also helps identify where the mail came from easily.  However if a workflow could send more than one mail this may not sufficient to uniquely identify the mail.  This is the first time in the 101 series where you'll see you need to apply logic at many locations in workflows - unfortunately workitems will implement all of your logic errors!

In the screenshot I have selected the Message Subject as the Event Attribute to check and click OK.  Next you select the condition - I will select 'contains' :


Finally the value - when you select this you get the option of a simple value (plain text input - hardcoded value) or Use Input Builder.  In my case I choose to select the workitem attribute workitem id.  I then added a second criteria that the email subject should also contain the words 'approval request'.  We will see later on when we look at workitem attributes in more detail why using workitem attributes in filters may not be such a good idea (also workitem id as always fine).


The last important component of this activity is the Timeout - You don't want to tell the workflow to wait forever.  After a certain length of time with no response you might have to re-send the mail, send it to somebody else or take a different course of action.  The output of the activity indicates if the activity timed out or received an event.


Grooming Events

Some adapters will generate a lot of events, you may be monitoring a table which adds a lot of rows, an active mailbox, or a systems or security management system which has a high EPS (Event per second).  Grooming events removes events after a set period of time, these times are defined in the Global Settings,  'Unused Event Retention Time' and 'Event Retention Time'.  An unused event is basically an event which isn't associated with a workitem.  If an event is initiated, appended, block by a trigger or waited for within a workflow, that event is associated with the workitem.  All other events are considered unused and can normally be groomed after a much shorter period than events associated with workitems.


Next up is: Aegis Workflow 101 - Triggers
Labels (1)


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 #:
6 of 6
Last update:
‎2020-01-09 16: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.