Aegis Workflow 101 - Variables

Aegis Workflow 101 - Variables

Welcome to Part 5 of Aegis Workflow 101. This time we look at variables and their use (and misuse) in Aegis.

Variables in Aegis are storage locations where you can store, retrieve and modify data. Like programming, in Aegis we have Global Variables (Global Settings), values which are accessible to all running work items and local Variables (Work Item Attributes) which are only available to the current work item. But why do we need them? Here are some reasons:

  1. Remember we don't like to hardcode anything where possible in Aegis workflows. So for example if we want to send an email to administrator and we are not getting that email address dynamically (like via an LDAP lookup), then we have to manually type it in. If we have 20 workflows all which use this address (possibly multiple times, if the administrator changes its going to be a headache to modify all workflows with the correct email address. Instead we can create a Global Settings (accessible via Input Builder) to set the value for the email address. Then all you need do is change the Global Settings and it immediately changes for all workflows the next time they request the address. If the email address is specific to a workflow then a Work item Attribute can be used instead of a Global Settings.

  2. Work item attributes can be used to keep track of changing values in a workflow. You might want to keep a count of the number of times a particular event is appended to a workflow, or append data to a string value which records status info of the workitem, or set a flag if a something occurs in the workflow.

  3. Anything values which might cause a workflow to break from being exported from one system to another is usually stored in a workitem attribute. For example going from a Development Environment to Live environment, different ip addresses, database names, file paths etc. may need to be used. Another one on hard-coding!

  4. When a work item can be started in many ways, different types of events or manual trigger for example, not all data may be available depending on the initiation reason. Manual Triggers are especially used during testing to avoid having to re-create a particular scenario every time to generate an event. Instead the workflow can follow a different path and use values saved in work item attributes as substitutes for real event data. Data from real events are saved to the corresponding workitem attributes, so after the workflow starts it doesn't actually matter how the workitem started as the work item refers to workitem attributes instead of event attributes which may not exist.

  5. Any time in a workitem a value varies from location to location it can be best to store the value in a work item attribute so you only need to read the workitem and not worry about which activity output is the current correct value.

  6. Work items themselves have a predefined list of attributes including the work item id, work item start time etc. which have a lot of applications in workflows.

These are just a few reasons, there are many many reasons. However, there are also many reasons not to use them also!

The dark side of Work Item Attributes and Global Settings is that they make database requests each time the value needs to be written or read - in comparison activity outputs are read from memory which is much faster. Ok so you'll probably say (and many have) that the performance difference is negligible, and it normally is. If a 'wait for event' activity compares 50 events per second for an event attribute to a workitem attribute then that is a lot of DB requests. If there are multiple instances of the same workflow running as well as other workflows, you will see a performance hit - I've even seen a scenario when the whole system ground to a halt. So how do we get around this?

*Note - Work Item ID while is an attribute, its value is stored in memory as it will never change and its really popularly used in comparison to any other work item attribute.

If a value has to be a variable and it will be read many times (and perhaps not changed, or changed after a specific point) a clever technique is to use the echo activity to echo the attribute value and then reference the output of the echo activity and not the workitem attribute / global setting. This method can speed up almost any workflow which over uses workitem attributes.

In short though if a value doesn't need to be saved as a workitem attribute then don't do it. I've seen workflows where all outputs of an activity are written to work item global attributes, then read from work item attributes immediately at next activity and never referenced again.

Global Attributes are created in Options in Global Administrator Settings. A number of default settings are already available like the Email Server Name which you defined during installation.


Global Settings allow you to define attributes of different data types, the only data type you cannot create when compared to work item attributes is a Table.

You can create your own Work item Attributes, Custom Work Item Attributes, by selecting the Work Item tab in workflow properties.


While it does allow you to create a Table, it is just an empty table so you need to set its value in the workflow, you cannot pre-set its value. There are some other differences here also. You can use input builder to specify the value of the custom workitem attribute and you can choose an evaluation order so you can set the value of one attribute from the value of another.

'Hidden in Operations Console' means you won't see the value of this attribute when you look at a running workitem. There is a 'password' data type attribute so you don't have to worry about showing sensitive data where passwords are concerned.

'Read Only in Operations Console' means you cannot modify a workitem attribute through the operation console for a running workitem. This comes as news to even experienced workflow developers. By default you can change the value of a workitem attribute while the workitem runs. I use it to set a Boolean flag for example to tell a workitem to end itself rather than terminating it, or changing a counter value or loop iteration so the workflow skips to the end faster.

After Creation, you can use 'Set Work Item Attributes' and 'Modify Global Settings' activities to make changes to the values, and use input build to read the values back again in workflows.

Next up is: Aegis Workflow 101 - Decision Making

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:44
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.