Hierarchy
SAP_BASIS (Software Component) SAP Basis Component⤷
BC-CCM-MON (Application Component) Monitoring⤷
SMOI (Package) CCMS: Monitoring Architecture
Basic Data
| Data Element | ALKEEPALRB |
| Short Description | Alert: Keep alerts types -radio buttons- |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | CHAR1 | |
| Data Type | CHAR | Character String |
| Length | 1 | |
| Decimal Places | 0 | |
| Output Length | 1 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | KeepAlerts |
| Medium | 15 | Keep alerts |
| Long | 20 | Keep Alerts type |
| Heading | 0 |
Documentation
Definition
Specify which alerts to keep, if not all alerts can be kept in the active list.
Procedure
Mark the type of alert that you wish to keep in the active list. The monitoring architecture will keep this type of alert in the event that alerts must be removed from the active list.
Your choices are as follows:
- Keep all alerts, in the order in which they were generated.
In this case, the monitoring architecture keeps as many alerts as it can. This can exceed the maximum number of alerts to keep that you also can set in this screen.
The monitoring architecture takes as much space as possible in its shared memory area for keeping alerts in the active list. The available space is shared with alerts for other monitoring attributes. No monitoring attribute is allowed to keep all of the available space for its own alerts.
Should space for keeping alerts run out, then the monitoring architecture removes some of the active alerts. The number of alerts for this monitoring attribute is reduced by 1/2 of the difference between the maximum limit specified on this screen and the actual number of alerts in the active list.
Example: The maximum number of alerts to hold is set to 10. You have, however, told the monitoring architecture to hold as many alerts as possible. It has therefore kept 50 alerts in the active list. Now, space for alerts has run out. The monitoring architecture therefore reduces the number of alerts from 50 to 30. The formula: reduce the number of alerts from 50 by 1/2 of the difference between 50 and 10. If storage runs out again, then the number of alerts will be reduced to 20 (30 - (1/2 * (30 - 10))).
- Keep the newest alerts. In this case, the monitoring architecture keeps only the number of alerts specified in the maximum alerts field on this screen. Excess older alerts are discarded.
- Keep the oldest alerts. In this case, the monitoring architecture keeps only the number of alerts specified in the maximum alerts field. Excess newer alerts are discarded.
- Keep alerts that have the same alert condition as the attribute. Example: If the monitoring attribute currently has a red alert, then it is set to criticality red. The monitoring architecture will keep red alerts up to the maximum number specified on this screen. Excess green and yellow alerts are discarded.
The monitoring architecture has limited space for keeping alerts active. Should too many unprocessed alerts accumulate, then the alert monitor may have to remove some from the active list. These alerts are then no longer visible in the alert browser. They need not be processed or set to status "complete".
Examples
Dependencies
History
| Last changed by/on | SAP | 20010130 |
| SAP Release Created in |
