Event-driven workload automation adds the capability to perform
on-demand workload automation in addition to plan-based job scheduling.
It provides the capability to define rules that can trigger on-demand
workload automation.
The object of event-driven workload automation in Tivoli® Workload Scheduler is
to carry out a predefined set of actions in response to events that
occur on nodes running Tivoli Workload Scheduler (but
also on non-Tivoli Workload Scheduler ones,
when you use the sendevt command line). This implies
the capability to submit workload and run commands on the fly, notify
users via email, or send messages to Tivoli Enterprise Console.
The main tasks of event-driven workload automation are:
- Trigger the execution of batch jobs and job streams based on the
reception or combination of real time events.
- Reply to prompts
- Notify users when anomalous conditions occur in the Tivoli Workload Scheduler scheduling
environment or batch scheduling activity.
- Invoke an external product when a particular event condition occurs.
Event-driven workload automation is based upon the concept of event
rule. In
Tivoli Workload Scheduler an
event rule is a scheduling object that includes the following items:
- Events
- Event-correlating conditions
- Actions
When you define an event rule, you specify one or more events,
a correlation rule, and the one or more actions that are triggered
by those events. Moreover, you can specify validity dates, a daily
time interval of activity, and a common time zone for all the time
restrictions that are set.
The events that
Tivoli Workload Scheduler can
detect for action triggering can be:
- Internal events
- They are events involving Tivoli Workload Scheduler internal
application status and changes in the status of Tivoli Workload Scheduler objects.
Events of this category can be job or job stream status changes, critical
jobs or job streams being late or canceled, and workstation status
changes.
- External events
- They are events not directly involving Tivoli Workload Scheduler that
may nonetheless impact workload submission. Events of this category
can be messages written in log files, events sent by third party applications,
or a file being created, updated, or deleted.
Within a rule two or more events can be correlated through correlation
attributes such as a common workstation or job. The correlation attributes
provide a way to direct the rule to create a separate rule (or copy
of itself) for each group of events that share common characteristics.
Typically, each active rule has one copy that is running in the event
processing server. However, sometimes the same rule is needed for
different groups of events, which are often related to different groups
of resources. Using one or more correlation attributes is a method
for directing a rule to create a separate rule copy for each group
of events with common characteristics.
The actions that
Tivoli Workload Scheduler can
run when it detects any of these events can be:
- Operational actions
- They are actions that cause the change in the status of scheduling
objects. Actions of this category are submitting a job, job stream,
or command, or replying to a prompt.
- Notification actions
- They are actions that have no impact on the status of scheduling
objects. Actions belonging to this category are sending an email,
logging the event in an internal auditing database, forwarding the
event to Tivoli Enterprise Console, or running a non-Tivoli Workload Scheduler command.
This classification of events and actions is conceptual.
It has no impact on how they are handled by the event-driven mechanism.
Simple event rule scenarios
This section
lists some simple scenarios involving the use of event rules. The
corresponding XML coding is shown in
Event rule examples.
- Scenario 1: Send email notification
- The administrator defines the following event rule:
- When any of the job123 jobs terminates in error
and yields the following error message:
AWSBHT001E The job "MYWORKSTATION#JOBS.JOB1234" in file "ls" has
failed with the error: AWSBDW009E The following operating system
error occurred retrieving the password structure for either the
logon user...
send an email to operator john.smith@mycorp.com.
The subject of the email includes the names of the job instance and
of the associated workstation. The event rule is valid from December
1st to December 31st in the 12:00-16:00 EST time window.
- The administrator saves the rule as non-draft in the database
and it is readily deployed by Tivoli Workload Scheduler.
- The scheduler starts monitoring the jobs and every time one of
them ends in error, John Smith is sent an email so that he can check
the job and take corrective action.
- Scenario 2: Monitor that workstation links back
- The administrator defines the following event rule:
- If workstation CPU1 becomes unlinked and does
not link back within 10 minutes, send a notification email to chuck.derry@mycorp.com.
- The administrator saves the rule as non-draft in the database
and it is readily deployed by Tivoli Workload Scheduler.
- The scheduler starts monitoring CPU1.
If
the workstation status becomes unlinked, Tivoli Workload Scheduler starts
the 10 minute timeout. If the CPU1 linked event is
not received within 10 minutes, the scheduler sends the notification
email to Chuck Derry.
- Chuck Derry receives the email, queries the actions/rules that
were triggered in the last 10 minutes, and from there navigates to
the CPU1 instance and runs a first problem analysis.
- Scenario 3: Submit job stream when FTP has completed
- The administrator defines the following event rule:
- The administrator saves the rule as non-draft in the database
and it is readily deployed by Tivoli Workload Scheduler.
- The scheduler starts monitoring the SFoperation directory.
As soon as file daytransac* is created and is no
longer in use, it submits job stream calmonthlyrev.
- The operator can check the logs to find if the event rule or the
job stream were run.
- Scenario 4: Start long duration jobs based on timeout
- The administrator defines the following event rule:
- When the job-x=exec event and the job-x=succ/abend event
are received in 5 minutes, the scheduler should reply Yes to prompt-1 and
start the jobstream-z job stream, otherwise it should
send an email to twsoper@mycompany.com alerting that
the job is late.
- The administrator saves the event rule in draft status. After
a few days he edits the rule, changes the email recipient and saves
it as non-draft. The rule is deployed.
- Every time the status of job-x becomes exec, Tivoli Workload Scheduler starts
the 5 minutes timeout.
If the internal state of job-x does
not change to succ or abend within
5 minutes and the corresponding event is not received, Tivoli Workload Scheduler sends
the email, otherwise it replies Yes to the prompt
and submits jobstream-z.
- Scenario 5: Monitoring process status and
running a batch script
- The administrator creates a rule to monitor the status of Tivoli Workload Scheduler processes
and run a batch script.
- Scenario 6: Integration with SAP R/3 (in combination with Tivoli Workload Scheduler for
Applications)
- The administrator defines the following event rule:
- When an event called ID3965 is generated on SAP
R/3 server Billing, Tivoli Workload Scheduler must:
- Run the command:
“/usr/apps/helpDesk –openTicket –text
‘Processing error $parameter
on SAP system $wsname'”
to open a service desk ticket
- Send an event to Tivoli Enterprise Console.
- The administrator saves the rule as non-draft and it is readily
deployed.
- Tivoli Workload Scheduler starts
monitoring the status of SAP R/3 events activated on the Billing system.
When
the ID3965 event is detected, Tivoli Workload Scheduler runs
the specified help desk command and sends an event to TEC.
- After some time, the administrator sets the event rule in draft
status. The rule is automatically deactivated. It can be deployed
again when needed.