Tivoli Workload Scheduler Distributed. Managing Events in a Tivoli Workload Scheduler Environment. Introduction. Using the Event-Driven W orkload Automation you can: Solve many workload automation scenarios Perform on-demand workload automation
Managing Events in a Tivoli Workload Scheduler Environment
Using the Event-Driven Workload Automation you can:
Event- driven workload automation performs on-demand workload automation and plan-based job scheduling. This automation defines 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 in the environment. The focus of this session will be to demonstrate how you can solve workload automation scenarios by using event-driven workload automation.
EventEvent-Driven Workload Automation basic concepts
An Event-Driven Workload Automation Rule is a composition of:
ActionEvent Rule Concepts
ActionEvent Rule modeling
The supported Events are:
(not built yet)
Jobs status notification
Event-Rules: the Life Cycle big picture
EDWA life cycle
Can be done using the Tivoli Dynamic Workload Console (aka TWS Web UI) and the TWS Command Line Interface (composer)
While in draft status, an event rule is not deployed in Tivoli Workload Scheduler. When draft status is changed to complete, the event rule is compiled and deployed.
Tivoli Workload Scheduleraction:
Submit predefined job, job stream or ad hoc job
Reply to prompt
Send an e-mail
Forward an event to Tivoli Enterprise Console
Log a message to file
Run custom commands on the event processor server
CFG fileFileMonitor Events Workflow
SSM reads CFG and monitors the system
EIF reads trap and sends event to TWS
Add FileMonitor rule
Create .cfg file for SSM agent
Create the rule with TWS
TWS creates the cfg file
CFG file is deployed to SSM
SSM reads the file and monitors the system
When the event is matched the SSM generates a trap
EIF listens to the trap and sends event to TWS
TWS executes the action correlated with rule
-composer new eventRule
Local encoding is used by default
For XML encoding
eventRule definition is completely written in XML unlike
other TWS objects written in Scheduling Language
To get this result a new optman keyword has been created:
deploymentFrequency / df = 5
Note: The default value is 5 minutes.
Event correlation types
Common attributes correlation
Timeout actionsEvent Rule Editor: Overview
The Event Rule Editor is the tool you use to create and edit Event Rules
You open the Rule Editor directly from the TDWC portfolio:
- Workload Definition
- Event Management
- New Event Rule
Or you open it by selecting an Event Rule from a query table and click “Edit”
The Event Rule Editor connects to a specific engine to store or retrieve the Event Rule.
As soon as you select an engine, the Editor connects to the engine and loads the list of event and action plug-ins available on it.
When the connection is successful, the Editor opens in its entirety.
The Event Rule, whether existing or a new one, is locked on the TWS database and is kept locked until the Editor is “Closed”.
You can then save the progresses on the Rule multiple times while you are working on it. The Rule will be kept locked all the time.
Select an Engine Connection and click Go
Dates and times expressed here will be referred to the TWS engine Time zone unless otherwise specified here
The Rule will be valid every day between the specified dates, but only within the hours specified here.
An empty value for one or both extremes means midnight.
A Daily end prior to Daily start is a valid range and represents a range that crosses midnight. In this case refer to the manuals for what are the effects on the first and last validity day.
The Rule will be valid between the specified dates.
An empty value for one or both extremes means indefinite.Event Rule Editor: General Information
This section contains general information about the Event Rule and its validity period.
A “Draft” Rule will not be activated or deployed, so it will not generate events and will not run actions.
A “Non Draft”, or “Complete” Rule will be activated and deployed at next
“Planman –deploy” (either scheduled or manual) and will be active within its
The changes you make to a Rule (including changing the “Draft” flag) will be effective only after the next deploying of the Rule.
Select an Event by clicking it to specify its properties
A name is generated and assigned to each Event automatically. You can change it here
Multiple, semi-colon-separated, values not allowed
Wildcards are allowed for this property
Remove Optional properties clicking here
A non-empty value is required
Specify a comparison operator
Add optional properties from this listEvent Rule Editor: Event Properties
Event Properties specify a filtering condition for events.
A condition on a property is specified with a comparison operator and one or more values. The values are in OR condition.
Wildcards may or not be allowed.
Filtering on some properties may be mandatory. You can add optional properties from the drop-down list.
A property can be added multiple times. These are in AND condition.
Use Machine-readable format to use variables as input to scripts, programs, etc…
Select an Event from the list of events currently added to the rule, and then one of its Properties.
A Variable pointing to the selected property will be inserted at the end of the current input field
A variable chooser helps inserting variables.
Variables are used to take values from Event properties to use into Action properties
You can use Variables for any Action PropertyEvent Rule Editor: Actions and Variables
Actions Properties do not specify a comparison operator, because they are actually parameters for the Action
Some properties are mandatory. You can add optional properties from the drop-down list.
A property can be specified only once.
The list of results appears below.
Click on an item to select it, or change the criteria and search again.Event Rule Editor: Lookup of TWS objects
When specifying properties related to TWS objects, a Lookup facility helps selecting an existing object in the TWS database.
Lookup is available for Jobs, Job Streams and Workstations.
Looking-up an object will fill-in all the object properties in the Action, not only the property next to which the button appears.
Press the Lookup button here
An Event or Action box turns RED if there are outstanding errors with it.
Click the box to resolve them in the Properties section
Errors are detected while you are typing and are shown below the corresponding field
Errors related to invalid ranges are outlined with a box around the corresponding fields
Scenario: An event rule does not trigger the required action.
If the STATE field has a lower case e, the event processor is installed but not running.
Action: Start the event processor by conman:
If the STATE field has no M, monman is not running.
Action: Start monman process by conman:
If the STATE field has no D, the current monitoring package configuration is not deployed.
Action: Force the deployment by conman:
Note: If there is neither an upper-case E nor a lower-case e, the event processor is not installed. The event processor is installed by default on the master domain manager and backup master domain manager. If you are working on either, then the installation did not complete correctly.
Monitoring configuration for CPU_MASTER: ****************************************************
*** Package date : 2007/09/03 07:48 GMT *** ****************************************************
TEST1::FileMonitor#FileCreated:C:\TEMP\FILE5.TXT ON CPU_MASTER; TEST1::TWSObjectsMonitor#JobSubmit:* # * . TEST*;
Use Web UI interface or composer command line to verify the state of the rule:
-list [email protected]
Event Rule Name Type Draft Status Updated On Locked By
------------------ --------- ----- ------- ---------- --------------
TEST1 filter N active 09/03/2007 –
Check in the SystemOut of the server whether the event has been received.
The output is different, depending on the type of event: FileMonitorPlugIn event
a. This is an example of the output of a FileMonitorPlugIn event
event: [9/3/07 9:55:05:078 CEST] 00000035 EventProcessor A com.ibm.tws.event.EventProcessorManager processEvent(IEvent) AWSEVP001I The following event has been received: event type = "FILECREATED"; event provider = "FileMonitor"; event scope = "c:\temp\file5.txt on CPU_MASTER". FILECREATED FileMonitor c:\temp\file5.txt on CPU_MASTER
Additional check: If the event has not been received check if it has been created by looking in the <TWS_home>\ssm\Log\traps.log for the message that indicates that the event has been created:
.22.214.171.124.4.1.19126.96.36.199.4.25 OCTET STRING FileCreatedEvent event
b. This is an example of the output of a TWSObjectMonitorPlugIn event
event: [9/3/07 12:28:38:843 CEST] 00000042 EventProcesso A com.ibm.tws.event.EventProcessorManager processEvent(IEvent) AWSEVP001I The following event has been received: event type = "JOBSUBMIT"; event provider = ""TWSObjectsMonitor""; event scope = "CPU_MASTER # JOBS . (CPU_MASTER #) TEST". JOBSUBMIT "TWSObjectsMonitor" CPU_MASTER # JOBS . (CPU_MASTER #) TEST
Additional check :If the TWSObjectMonitorPlugIn event has been received, check in the same log that the EIF event has been sent.
Scenario: Actions involving the automatic sending of an e-mail fail
An event rule is created, including as the required action the sending of an e-mail.
When the event occurs, the action fails with the following message:
AWSMSP104E The mail "<mailID>" has not been successfully delivered to "<recipient>".
Action: Specify the domain name of the SMTP server (mailSenderName (ms))
Example: optman chg ms [email protected]
Scenario: An event is lost
If the event queue is not big enough, it is possible that the most recent event or events are missing.
Action: increase the size of the event processor queue.