Try OpenEdge Now
skip to main content
BPM Events User's Guide
Persistent structures : Infopads : Creating infopads : Attaching alarm conditions to cells
 
Attaching alarm conditions to cells
You can attach an alarm condition to a cell by adding a check() statement. The arguments of a check() statement include the following generic terms: conditionname, operand1, operator, operand2, and raisemode where:
*conditionname — Is the name given to this alarm-condition.
*operand1 — Is either the name of a slot involved in the alarm-condition or a constant value. A text constant should be in quotes.
*operator: Is some relational operator. Operators are: GT (greater than), GE (greater than or equal to), LT (less than), LE (less than or equal to), EQ (equal to), NE (not equal to).
*operand2 — Is a slot (of the same cell) or a constant. If it is a slot, then it must follow the syntax: slot[myslotname], where myslotname is the name of the slot. The overall expression must be within quotes, for example, "slot[avgtime]". If it is a text constant, then it should be in quotes, for example, "maxtime". A numeric constant can be written as is, that is, float number 12.5.
*raisemode — Is the mode that specifies when the alarm is raised. If its value is transition, then the alarm will be raised each time the alarm-condition becomes TRUE after being FALSE in the previous check. In the above example, this means that the alarm is raised each time the slot load crosses the "threshold" limit. But no alarm is raised each time the load value changes while staying above the threshold. If the value is absolute, then an alarm is raised each time a change verifies the condition, regardless of what the previous state was of the cell condition.
As an example, assume that we define an infopad to monitor the load of a pool of application servers. Each cell reports about the load of one application server. Each cell has an attribute "load" that should not exceed a particular limit, stored in another attribute "threshold".
When the limit is reached, an alarm is generated. It is possible to associate an alarm-check to the cells of this table using the check() action-item, as illustrated below:
myMonthlyTable.check ("alarm_1","max_time","GT", 120, "absolute");
Where "alarm_1" is the condition name, "max_time" is the operand 1, "GT" is the operator, "120" is operand 2, and "absolute" is raise-mode.
Anytime a cell is updated, the alarm-condition set by the check() statement above checks if the slot "max_time" has a value greater than 120. If this is the case, then an event is generated and notified internally to BPM Events.
myMonthlyTable.check ("alarm_2","avg_resp_time","GT", 90,"transition");
Anytime a cell is updated, the alarm-condition set by the check() statement above checks if the slot "avg_resp_time" has a value greater than 90. The behavior is however different here, as specified by the keyword "transition". An alarm event is generated only if:
*"avg_resp_time" is greater than 90, and
*its previous value was below or equal to 90.
Such internal alarm events are of the type "BPEVENT_INFOPAD_ALARM". In addition to attributes specific to its type, the event also carries all the slots of the offending cell. Its content is:
Type: BPEVENT_INFOPAD_ALARM
Date: date the event is generated
Value: alarm_1
Context.table: name of the infopad that generated the alarm
Context.row: index of the row of the offending cell
Context.column: index of the column of the offending cell
Context.slot: index/name of the offending slot in the cell
Context.slotvalue: value of the offending slot in the cell
Context.max_time: value of the max_time slot of the offending cell
Context.avg_resp_time: value of the avg_resp_time slot of the offending cell
Context.current_user: value of the current_user slot of the offending cell