See: Description
Interface | Description |
---|---|
Scheduleable |
The
Scheduleable interface
is implemented by a scheduleable object to check if the scheduleable
object is in-schedule. |
Class | Description |
---|---|
Attributes |
The
Attributes provides methods for accessing attributes in a
Schedules object. |
Period |
A Period defines the time intervals, days or months
that should be included or excluded in a schedule.
|
PeriodGroup |
A PeriodGroup is a logical group of Periods useful for defining an asbtract group of
Periods.
|
PeriodGroupReference |
A PeriodGroupReference object references to a PeriodGroup in the Schedules.
|
Schedule |
A Schedule is configuration object that can be used to determine if a rulebase or part of the rulebase
should be in-schedule or out-of-schedule at a given time.
|
Schedules |
A Schedules contains a list of
Schedule and PeriodGroup objects. |
SchedulesXML |
The
SchedulesXML
provides methods for accessing XML representation of a
Schedules . |
Exception | Description |
---|---|
ScheduleException |
Signals that an error occurred while processing schedule.
|
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.
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.
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.
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.
Copyright © 2000-2019 TIBCO Inc. All Rights Reserved.