HCL Workload Automation, Version 9.4

Rule operation notes

The following contains critical information on event rule behavior that might help you understand the reason for unexpected results:
Notes on rule status
  • Depending on its from and to validity dates, the status of any rule changes as follows upon deployment:
    • If you create a rule with already expired from and to validity dates, the rule is saved in activation pending state. When the rule is deployed, it remains in activation pending status.
    • If you set the to validity field to a future date, the rule is deployed in the active state. If you reset it to a past date, the rule is redeployed in the no active state.
  • Rule activity times (start and end) do not affect rule status. As long as a rule is within the right validity dates, the rule remains in the active state regardless whether it is within its defined activity times. If the scheduler receives a rule 's defined events outside its activity time, the events are discarded but the rule stays in the active status.
Event rule paths
Only on Windows operating systems, when you define a path for an event rule, you cannot use the slash / but only the single backslash \ or double backslash \\.
Event rules constrained by files
When you have a file monitoring event rule constrained by the creation or existence of a file, if this file is deleted and then re-created in the same time interval between two consecutive checks, this file is unchanged for HCL Workload Automation and the event rule is not triggered. The time interval between checks can be reduced to a minimum of 5 seconds, but this involves a significant performance degradation. To avoid this issue, do not make file actions during this time interval.
File monitoring event rules for files on Network File Systems
To activate a file monitoring event rule for files on Network File Systems, you must enable the property MonitorRemoteFS in the file <tws_install_dir>/ssm/Config/init.cfg (for fault-tolerant agents), or in the file <tws_install_dir>/EDWA/ssm/Config/init.cfg (for lightweight agents), where <tws_install_dir> is the directory path where the HCL Workload Automation agent is installed. To activate this property, perform the following actions:
  1. Edit the init.cfg file.
  2. Change from MonitorRemoteFS=off to MonitorRemoteFS=on.
  3. Stop the System Service Monitor (SSM) agent.
  4. Start the SSM agent.
Note: On Windows operating systems, the remote workstation address must be included at the beginning of the full path of the file to be monitored. For example: \\123.123.123.123\images\Automation\myFile.txt. This is not needed on UNIX operating systems.
Lack of persistence in rule instance status
If the event processor is stopped or crashes, the status of rule instances that are only partially matched is lost.
Repeating set and sequence rules
Typically, each active rule has one, and only one, copy that runs in the event processing server.Set and sequence rules use the mechanism explained in the following example:
  1. You define a sequence rule with two events, A and B.
  2. When the first event that matches the sequence occurs (event A), it activates the rule and waits for the second event (event B).

    Once the rule is active, any additional event A events that may arrive are ignored. No additional rules are created for any newly detected event A events as long as the rule is waiting for event B.

  3. Once event B occurs, the rule is completed and resets, waiting for event A to occur again.
The mechanism of set and sequence rules is such that any additional occurrences of an already detected event are ignored and discarded if the other defined events have not arrived.

You can prevent this problem by using correlation attributes. Using one or more correlation attributes is a method for directing a rule to create a separate rule copy when another event A arrives.

Set and sequence rule types with shorter than 24 hours activity time windows

Occurrences of set or sequence rules that were defined to be active for only a few hours of every day, are not purged when the activity period within each day expires if only part of the events arrive. They remain in an idle state, waiting to receive the remaining events in the following days.

For example, you define a set rule that includes two events. The rule is valid from January 1 to January 10, and is active daily from 6 to 10 AM.

If on January 1 the first event is received at 8 AM, the rule waits for the second event to take place, and stays alive beyond 10 AM if the event is not detected.

If the second event is received at 11 AM (which is out of the activity time window), it is discarded, but the rule keeps on staying alive. If the second event is received again at 7 AM of January 2, the rule is triggered and the actions are implemented.

If you don not want the rule to carry over to the next day, you should purge it.