About this task
When you define an event rule, you specify one or more
events, a correlation rule, and one or more actions. To define event
rules you can use:
- The composer command line
- The Dynamic Workload Console
- A set of APIs described in a separate document
In
composer, you edit the rules with an XML
editor of your choice (preferable but not mandatory) since event rule
definitions are made using XML syntax.
The explanation of how
you use composer to define event rules is in Event rule definition, while the explanation
of how you use the Dynamic Workload Console can be found in its online help.
Event rule definitions are
saved in the
Tivoli® Workload Scheduler database like all other scheduling objects. You can save them as:
- Draft
- The rule is saved in the database but is not ready yet to be deployed
and activated.
This state is determined by the isDraft=yes attribute.
- Not draft
- This rule is being deployed or is ready to be deployed in the
scheduling environment.
This state is determined by the isDraft=no attribute.
Non-draft rules are ready to
be activated. The rule builder calculates the status of each rule.
The
status can be:
- active
- not active
- update pending
- update error
- activation pending
- activation error
- deactivation pending
- deactivation error
The scheduler periodically (every five minutes or in
accordance with a time set in the
deploymentFrequency global configuration option) scans the database for non-draft rules
and builds rule configuration files for deployment. The new monitoring
configurations are downloaded to the agents (each agent gets its own
configuration file containing strictly the rules it is to run) only
if there have been changes since the previous configuration files.
As an additional feature, a planman deploy command
is available to deploy rules manually at any time.
You can
deploy and undeploy rules as you need by setting the isDraft attribute to no or to yes with composer or with the Dynamic Workload Console.
Based on their characteristics, rules are classified as:
- filter
- The rule is activated upon the detection of a single specific
event.
- sequence
- The rule is activated when an ordered group of events is detected
or fails to complete within a specific time interval.
- set
- The rule is activated when an unordered group of events is detected
or fails to complete within a specific time interval.
Filter rules are based on the detection of
one event such as a job being late, a Tivoli Workload Scheduler workstation going down, a file being modified, a job stream completing
its run successfully, and so on.
Set and sequence rules are
based on the detection of more events. Optionally, they can be based
on a time out condition. A rule times out when the first event(s)
in a sequence or part of the events in a set are received, but not
all the events are received within a specified time interval counted
from when the first event was received.
Rule definitions may
include attributes that specify a validity period and an activity
time window within each day of validity. If you do not specify these
attributes, the rule is active perpetually at all times once it is
deployed and until it is changed back to draft status or deleted from
the database.
You can use variable substitution. This means that when
you define action parameters, you can use attributes of occurrences
of events that trigger the event rule in either of these two forms:
- ${event.property}
Replaces the value as is.
This is useful to pass the information to an action that works programmatically
with that information, for example the schedTime of
a job stream.
- %{event.property}
Replaces the value formatted
in human readable format. This is useful to pass the information to
an action that forwards that information to a user, for example to
format the schedTime of a job stream in the body
of an email.
Where:
- event
- Is the name you set for the triggering eventCondition.
- property
- Is the attributeFilter name in the filtering
predicate of the triggering event condition. The value taken by the
attribute filter when the rule is triggered is replaced as a parameter
value in the action definition before it is performed.
Note that
you can use variable substitution also if no attributeFilter was specified for an attribute and also if the attribute is read-only.
You can see the use of variable substitution in some
of the following sample definitions, where attribute filter values
are replaced in email subject and body matters.