Skip navigation links

Package COM.TIBCO.hawk.config.rbengine.schedule

Provides classes for creating and processing schedules used in the rulebases of TIBCO Hawk agents.

See: Description

Package COM.TIBCO.hawk.config.rbengine.schedule Description

Provides classes for creating and processing schedules used in the rulebases of TIBCO Hawk agents.

A Schedule is configuration object that can be used for determining if a rulebase or part of the rulebase should be 'in-schedule' or 'out-of-schedule' at a given time. If a schedule is not specified in a rulebase, then the rulebase is always in-schedule.

Structure of a Schedule

Each schedule has a name, a list of inclusion periods, and a list of exclusion periods. A schedule is in-schedule if at least one of its inclusion periods is in-schedule and none of its exclusion periods are in-schedule. Otherwise, the schedule is out-of-schedule. The inclusion and exclusion periods contain a list of Period or PeriodGroupReference objects. A Period defines the time intervals, days or months that should be included or excluded in a schedule. It is composed of 4 distinct period components - MinutesInDay, WeekDaysInMonth, DaysInMonth and MonthsInYear. A Period object is in-schedule only if all of its 4 components are in-schedule. Otherwise, it is out-of-schedule .

MinutesInDay contains a set of 1440 continuous 1-minute intervals in a day. The MinutesInDay object is in-schedule if the time for checking the schedule is included in the MinutesInDay.

WeekDaysInMonth contains a set of 7 days in a week. It also allow definition of specific weekday of the month. A WeekDaysInMonth is in-schedule if the weekday of date for checking the schedule is included in the WeekDaysInMonth.

DaysInMonth contains a set of 31 days in a month. It also allow definition of last day of the month. A DaysInMonth is in-schedule if the day in the date for checking the schedule is included in the DaysInMonth.

MonthsInYear contains a set of 12 months in a year. A MonthsInYear is in-schedule if the month of the date used for checking the schedule is included in the MonthsInYear.

PeriodGroupReference is a reference to a PeriodGroup. A PeriodGroup object is a logical group of Period object useful for defining an asbtract group of periods. Period groups are useful when you use a set of periods regularly in defining schedules. It also eases the maintance of those schedules because you can make a change in the period group and have it automatically reflected in all the schedules that use it.

Use of schedules in rulebases

Schedules may be used to control when a monitoring activity or action is performed. Schedules may be applied to a Rulebase, Rule, Test, and Action by specifying the schedule name in the attribute of these objects. If a Rulebase, Rule, Test, or Action makes use of a schedule name that is not defined either because the agent couldn't load the Schedule object or because the Schedule object does not exist then it will be flaged as an error. However, the rulebase processing will continue as if no schedule was specified for that component - that component will behave as if always in-schedule

If the schedule name applied to a rulebase component begins with "!" then it refers to the inverse of a schedule. For example, if the schedule BusinessHours is defined in the schedules configuration, a rulebase component may use either BusinessHours or !BusinessHours to refer to it. When using BusinessHours, that component is in-schedule whenever the BusinessHours schedule is in-schedule. When using !BusinessHours, that component is in-schedule whenever the BusinessHours schedule is not in-schedule. If the schedule BusinessHours is not defined in the scheduler then components using either BusinessHours or !BusinessHours will behave as if no schedule is defined (they both will always be in-schedule).

A rulebase is a hierarchical structure: rulebases contain rules, rules contain tests, and tests contain actions. Therefore, a schedule applied to one node in the hierarchy affects all nodes below it. The following describes the behavior of Rulebases, Rules, Tests, and Actions when valid schedules are applied:

Rulebase - When a rulebase is loaded it isn't activated unless its applied schedule is currently in-schedule. Thereafter, when its applied schedule transitions to an in-schedule state, the rulebase is activated. When its applied schedule transitions to an out-of-schedule state, the rulebase is deactivated. Before a rulebase becomes active, no rules are processed no monitoring is taking place by that rulebase. When a rulebase is activated, its rules are loaded and monitoring may begin. When a rulebase is deactivated, all of its rules are unloaded which results in the clearing of outstanding alerts (generated from those rules) and the cessation of all monitoring by that rulebase.

Rule - When a rule is loaded it isn't activated unless its applied schedule is currently in-schedule. Thereafter, when its applied schedule transitions to an in-schedule state, the rule is activated. When its applied schedule transitions to an out-of-schedule state, the rule is deactivated. Before a rule becomes active, no tests are processed no monitoring is being performed by this rule. When a rule is activated, its tests are loaded and monitoring may begin. When a rule is deactivated, all of its tests are unloaded which results in the clearing of outstanding alerts (generated from those tests) and the cessation of all monitoring by that rule. When a rule is inactive, its enclosing rulebase behaves as if that rule is not there.

Test - When a test is loaded it isn't activated unless its applied schedule is currently in-schedule. Thereafter, when its applied schedule transitions to an in-schedule state, the test is activated. When its applied schedule transitions to an out-of-schedule state, the test is deactivated. Before a test becomes active, no actions are loaded no monitoring is being performed by this test. When a test is activated, its actions are loaded and monitoring begins. When a test is deactivated, all of its actions are unloaded which results in the clearing of outstanding alerts (generated from those actions) and the cessation of all monitoring by that test. When a test is inactive, its enclosing rule behaves as if that test is not there.

Action - When an action is loaded it isn't activated unless its applied schedule is currently in-schedule. Thereafter, when its applied schedule transitions to an in-schedule state, the action is activated. When its applied schedule transitions to an out-of-schedule state, the action is deactivated. Before an action becomes active, it performs no action and does not respond in any way to its test's state transitions. When an action is activated, it begins tracking and responding to its test's state transitions. When an action is deactivated, any outstanding alert it may have generated is cleared and the action ceases to track and respond to the state transitions of its test. When an action is inactive, its enclosing test behaves as if that action is not there.

Schedule configuration management

In most respects, configuration management for Schedules is identical to that for rulebases (when in auto-config mode, the agent will load and store this file from auto-config-dir, etc.). However, all schedules use by the agent are maintained in a single Schedules object. Agent stores and retrieves the Schedules to and from the file "schedules.hsf".

Schedules and Agent Performance

Because all schedules are stored in a single file, each agent will load the schedules at startup. However, the scheduler in the agent will evaluate a schedule only if it has loaded rulebases that reference that schedule. Such schedules are referred to as active because there is active interest in them. Furthermore, since the resolution of schedules is every minute, the scheduler will evaluate active schedules only every minute of the hour. The only other times that active schedules are evaluated is when the agent is received a new schedule configuration (such as when using SendTo from the schedule editor) and when a schedule first becomes active (such as the first time any rulebase references it).

In general, having a large number of schedules defined in the schedule file may marginally affect the size of the agent but it doesn't affect the CPU performance. Only when rulebases reference the schedules do they get evaluated, and only at every minute.

Related Documentation

For more details on rulebases and interaction of schedule with RulebaseEngine microagent, please refer to:
Since:
TIBCO Hawk 4.1.0
Skip navigation links

Copyright © 2000-2019 TIBCO Inc. All Rights Reserved.