Event management

You can use the event management feature to launch a predefined set of actions in response to events that occur on the nodes where HCL Workload Automation runs.

The main elements of event management are:

Events
Actions
Event rules

You can use event management capabilities to:

Create Event Rules
Create and run Workload Events tasks

Events

An event represents a set of circumstances that match selected criteria. Events are divided into the following major categories:

HCL Workload Automation object related events

All the events relating to scheduling objects such as jobs, job streams, workstations, and prompts. This type of event is described in more detail in Workload Scheduler plan events.

Note: Any change performed on a workstation referenced in a rule is not reported in the rule. For example if you modify, update, or delete a workstation that is referenced in a rule, the rule ignores the change and continues to consider the workstation as it was when it was included in the rule.

File monitoring events

Events relating to changes to files and logs.

File monitoring events are not supported on IBM i systems.

This type of event is described in more detail in File monitor .

Application monitoring events

Events relating to HCL Workload Automation processes, file system, and message box. Application monitoring events are not supported on IBM® i systems.

This type of event is described in more detail in Application Monitor .

SAP related events

These events are available only if you have installed HCL Workload Automation for Applications and they are generated by external SAP systems. This type of event is described in more detail in SAP Monitor.

Data set monitoring

These events are available only if you are using the agent for z/OS on HCL Workload Automation This type of event is described in more detail in Data Set Monitoring.

Generic events

Events used to manage custom events sent by external applications. You can write an XML file to define a custom event. A schema is provided to validate your XML, as well as a basic event template that you can use as a starting point. For more information, see the schemas for generic events. Events of this category are:

Changes in a resource of the operating system, such as processes and memory
Email received

Actions

When one or more of the above events occurs, you can specify which actions to perform. Actions are divided into the following main categories:

Operational actions

Actions that cause a change in the status of one or more HCL Workload Automation objects. Actions in this category include:

Submitting jobs or job streams
Submitting ad hoc jobs
Replying to a prompt

This type of action is described in more detail in IBM Workload Scheduler actions.

Adding an application occurrence (job stream) to the current plan on IBM Workload Scheduler for z/OS® in HCL Workload Automation-IBM Workload Scheduler for z/OS end-to-end scheduling configurations.

This type of action is described in more detail in IBM Workload Scheduler for z/OS actions.

Notification actions

Actions such as:

Sending email's or SMS. For details, see Mail sender plug-in.
Forwarding IBM Enterprise Console events. For details, see Message logger.
Writing messages in a logging repository. For details, see IBM Enterprise Console event forwarder.
Forwarding events to a IBM Business Services Manager server. For details, see IBM Business Services Manager Console event forwarder.
Opening a ticket to a SmartCloud Control Desk. For details, see SmartCloud Control Desk.
Opening an incident in ServiceNow incident management. For details see ServiceNow.

Generic actions

Actions performed by running a command. This type of action is described in more detail in Generic action plug-in.

Event rules

Use event rules to associate one or more events to the response actions that you want to perform. When you create an event rule, you are actually creating an event rule definition in the database. While the event rule is in Draft status, it is not deployed to the HCL Workload Automation. All new and modified non-draft rules saved in the database are periodically (by default every five minutes) found, built, and deployed by an internal process named rule builder. At this time they become active. Meanwhile, an event processing server, which is normally located in the master domain manager, receives all events from the agents and processes them. The updated monitoring configurations are downloaded to the agent and activated. The occurrence of an event rule that has performed the corresponding actions is called the event rule instance.