Aegis Automation Workflows in 5 Minutes - A Modular Problem Escalation WorkFlow

Aegis Automation Workflows in 5 Minutes - A Modular Problem Escalation WorkFlow

The "Aegis Automation Workflows in 5 Minutes" cool-tool blog series shows examples of Aegis workflows which deliver value in as little as 5 minutes development time - all using out of the box activities! Aegis workflows can be forever evolving, and while these workflows fulfill a purpose, you may for example want to extend a workflow from being a simple notification workflow to one which goes further to remediate a problem.

First of all - what is a modular workflow? Put simply, it is a re-usable workflow which can be called to run by multiple other workflows . In Aegis the great benefits are the same as in programming where methods / functions etc are used. If there is a piece of workflow you end up doing over and over in the same or different workflows, creating a separate 'modular' workflow makes life much easier. If there is a bug found, or enhancement, rather than having to modify multiple workflows you only need to modify one. The escalation workflow is an example of this - many workflow may have a requirement to escalate a problem to a 'human' or even another system. This 5 minute workflow shows how it is done.

In this workflow I have 3 levels of escalation - Aegis contacts team1 to accept the escalation - if team1 does not accept in a defined length of time, it is re-escalated onto team2 and then finally onto team3.

 

This is what the workflow looks like...

esc

Unlike other workflows, this workflow is started by other workflows, in this case using the 'Execute Process with Context' activity from the Parent/calling workflow. The workflow needs to have Workitem Attributes defined which the Parent workflow will use to pass it details about the escalation. In this example I just pass 3 pieces of information - the problem severity, a problem description and problem time. When the escalation workflow runs, these values are populated and are available to the workflow. The first step of the workflow is to change the problem time into a human readable form via the 'convert Unix Timestamp to Text' activity which allows the date to be viewed in the format of your choice.

Next the workflow contacts the first user/DL on the escalation list - in this simple case there is an array WorkItem Attribute - to Accept the escalation via an Input Form.

esc1

 

If the user accepts the escalation, the result including the user who accepted (collected from Input Form) is returned back to the Parent Workflow. If the escalation is not accepted within a timeout (also stored in workitem attribute in this case), then it contacts the second on escalation list and repeats again onto the level 3 escalation.

This is what the workflow looks like mid-escalation waiting on the Level 2 team to accept the problem.

esc2

On the Parent Workflow :

esc3

 

And you are done ... hopefully in 5 minutes!

The workflow is attached if you want to compare results. There are a number of workitem attributes in the workflow which should be modified to suit your environment:

inHoursList is an array containing the email addresses at different levels of escalation

reEscalationTime is an array of time (in seconds) to wait before escalating the workflow to next team

aegisEmail is the from address when sending notification emails.

There are also 3 workitem attributes, input_Description, input_Severity and input_DetectTime, which are used by the parent workflow so these can be left blank, or you can populate them with test values and manually run the workflow as it has a manual trigger (which is required).

 

Next Steps - yes you've guessed it, there are loads of possibilities to extend this workflow! Here are some examples...

  1. A must - add some error handling and notification! If there are any failures (for example if a Email system is down) the workflow will silently fail apart from an error in console.

  2. Add a Timetable for Out of Hours support - when workflow runs check the timetable and alert the out of hours teams!

  3. How could you handle different escalation teams for different types of problems?

  4. Read the escalation details from external source such as database - this makes the workflow more dynamic and doesn't need to be edited when teams change.

  5. Add some logic around the team 3 escalation - it will wait forever in the current design - what would you do next?

  6. What if more levels of escalation are required? - There is already branches of workflow which are almost identical which I don't like ... could you re-design the workflow so it can handle N number of escalations where N is unknown before execution time?


Happy Escalating!
Attachments

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:
‎2014-09-16 00:52
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.