How good you do your security there may come a time when user might need emergency authorizations. Such authorization can be necessary in exceptional situations. It could be a month end close, which got closed before the month end.
Virsa provides tool called firefighter, which can help you. First you have to define what is an emergency for your company. You might have to create roles for these emergencies, and also define the time frame this role will be assigned to users. You might have to define an approval procedure for this. Hoe is this going to be audited. Work with your audit team to make sure they are ok

The monitoring architecture, a solution within SAP NetWeaver, centrally monitors any IT environments – from individual systems through networked SAP NetWeaver solutions, to complex IT landscapes incorporating several hundred systems. It is provided in SAP NetWeaver and can be used immediately after installation. You can easily extend the architecture to include SAP and non-SAP components.

Alerts form a central element of monitoring. They quickly and reliably report errors – such as values exceeding or falling below a particular threshold value or that an IT component has been inactive for a defined period of time. These alerts are displayed in the Alert Monitor; this reduces the workload for the system administration, since they now only need to watch the error messages, instead of endless system data.

The Alert Monitor is therefore the central tool with which you can efficiently administer and monitor distributed SAP NetWeaver solutions or client/server systems. The Alert Monitor displays problems quickly and reliably.

Implementation Considerations

If you want to use the Alert Monitor for central monitoring (that is, you want to monitor the systems of your IT landscape from a central monitoring system), you must perform various configuration steps yourself. These are described under Configuring the Monitoring Architecture.

Features

The Alert Monitor provides the following functions:

· You can use the Alert Monitor to perform complete and detailed monitoring of all SAP and non-SAP systems, the host systems, and the database.

· All errors generate alerts, which are displayed in a tree structure.

· The alerts contain a status indicator with a color and a numerical value. Yellow means a warning, red means a problem, and the numerical value shows the severity of the reported error. In the tree structure, the most severe alerts are passed upward in the display hierarchy. If a tree node is not displaying an alert, there is also no error in the entire branch below it.

· You can assign certain analysis and auto-reaction methods to the alerts, which contribute to faster processing of the error. If you double-click an alert, the monitoring architecture starts the assigned analysis method (such as the job administration transaction for a prematurely terminated job). An auto-reaction method, on the other hand, starts automatically as soon as the alert occurs. This includes executing operating system commands and sending an e-mail or an SMS message to the system administration.

· The Alert Monitor contains various view in which either the current or the open (that is, the unanalyzed) problem messages are displayed. Alerts are also archived.

· Threshold values, methods, and detailed help for many monitoring attributes and three extensive monitor sets with monitors for all aspects of system management are predefined on the basis of Best Practices in the monitoring architecture and are available in every SAP system.

· You can adjust all settings individually, and configure your own monitors.

Monitoring objects and attributes are assigned various properties and methods. There are default settings in the standard SAP System (which is delivered with the properties variant SAP_DEFAULT) for most nodes for properties and methods, meaning that you can already work with these settings.

Auto-reactions are an example. There are very few assignments of these in the standard SAP System. You can make your own assignments of these (see also: Selected Methods of the Alert Monitor).

If the standard settings do not meet your requirements, you can change the properties and method assignments at any time. You can make the changes both in the Alert Monitor and in the Customizing transaction RZ21. You can either make changes for the individual node itself or for the MTE class or attribute group, to which the node belongs (we recommend the latter).

Features

The following cases occur most often in practice:

Data suppliers deliver all of the values that are displayed in the Alert Monitor. They each belong to the individual system components and create monitoring objects that report values to the monitoring architecture. These values are displayed in the monitor sets.

The monitoring architecture is delivered with the data suppliers for the most important components of your SAP system and its environment and can therefore be immediately used. When starting the Alert Monitor, you can see that the data suppliers for reporting for the following components are already active:

· The host systems on which your SAP system is running

· The database

· SAP instances (application servers) and their services and components

· Components outside the system

You do not need to prepare or activate the monitoring architecture. The data suppliers in your system are either started automatically when the system is started, or are started as they are required. There are two different types of data suppliers:

· Passive Data Suppliers are started by the monitoring architecture, which is why they must be defined there. “Passive” describes the behavior of the data supplier in relation to the monitoring architecture: it does not start itself, but rather must be started by the monitoring architecture. Passive data suppliers are also known as data collection methods.

· Active Data Suppliers are started by the monitored application rather than the monitoring architecture. These data suppliers are active in their start behavior in relation to the monitoring architecture.

A data supplier writes the values for the monitored objects in a segment of the shared memory known as the monitoring segment. This monitoring data can be transferred to the monitoring architecture in two ways:

· Using a defined ABAP interface, in the case of an SAP instance ‑ a free work process is required for this

· Using a CCMS agent, for any server; the transfer is performed using a Remote Function Call (RFC)

As the connection method using a CCMS agent does not require a free work process, the access method is therefore independent of error states of the SAP instance and therefore more robust. The CCMS agents also use push technology with which the agents report alerts automatically, if the central monitoring system is running SAP Web Application Server 6.10 or above. This helps to ensure a good performance, as the central monitoring system then no longer needs to periodically query the agents for alerts. We therefore recommend that you use CCMS agents when connecting remote systems to the central monitoring system.

Definition

The alert monitoring tree consists of individual monitoring tree elements (MTEs). They are either components of your IT landscape that are to be monitored (monitoring objects), or values, statuses, or texts that are reported for these objects (see Monitoring Objects and Attributes). These MTEs are assigned to MTE classes and attribute groups in the monitoring architecture:

· An MTE class describes the general properties and method assignments that are common to a particular group of monitoring tree elements.

· An attribute group describes the common threshold values for alerts for a particular attribute type.

Use

MTE classes and attribute groups simplify the Customizing of the Alert Monitor, since you do not need to change threshold values, properties, or methods individually for every MTE, but only for the corresponding attribute group or MTE class.

MTE classes also simplify the creation of your own rule-based monitors, since you do not need to specify every MTE individually when constructing the alert monitoring tree, but rather only the corresponding MTE classes.

The classification of the MTEs to MTE classes and attribute groups is already fully predefined. You do not need to make any changes to be able to use this classification.

If you want to change the properties, methods, or threshold values, the system displays a message informing you whether the change refers only to an individual MTE or to the corresponding MTE class or attribute group. You can change this default value (see Changing Properties and Method Assignments).

Examples

· MTE Class:

The Space Management monitoring object and the Free Space monitoring attribute both belong to the MTE class CCMS_DB_Freespace_MT. This means that both MTEs have the same general properties and method assignments.

· Attribute Group:

All instance-specific occurrences of the Response Timemonitoring attribute belong by default to a single attribute group. This means that the same threshold values are set in all of the instances of a system and that changes to the threshold values apply to all instances.

Definition

A monitoring object represents a component of the IT environment that is to be monitored, such as the CPU of a server, the dialog system, or background processing. Monitoring attributes are values, statuses, or texts that are reported to this object, such as the CPU utilization, or the average response time in the dialog system. A monitoring attribute can be assigned an alert. The selection of the monitoring objects is performed using the data suppliers that exist for all areas of system management.

Structure

Monitoring objects and their attributes are displayed in the alert monitoring tree as individual nodes in a hierarchical tree. If the data reported to the monitoring architecture exceeds or falls below the defined alert threshold values, an alert is triggered in the corresponding monitoring tree element.

There are five different types of monitoring attributes:

You can assign methods to monitoring attributes. A method can be a report, a function module, an SAP transaction, or a URL that is to executed as a reaction to an alert. You can execute these methods within the Alert Monitor. If you double click, for example, the MTE for prematurely terminated jobs, the monitoring architecture automatically starts the job management transaction, in which the job reported in the MTE is already selected.

See also:

Properties of Log Attributes

Properties of Performance Attributes

Properties of Status Attributes

Definition

The Alert Monitor generates alerts in the monitored systems using threshold values and rules, if the status of the systems deviates from the norm. These alerts attract your attention to critical situations so that you do not have to search for them yourself. Auto-reaction methods can inform you about a problem, or react to it in some other way, even if you are not currently working in the Alert Monitor.

For the system administrator, an alert is an error report or a service request. You should react to every alert. Use the Alert Browser and the analysis method contained in the Alert Monitor to investigate the alert. If you have solved the problem, or are sure that you can safely ignore it, set the alert to complete. The system then removes this alert from the display and saves it to the alert database.

The alert monitor reports alerts up through the monitoring tree. This means that the color indicator for a node is always the color of the highest alert in all elements of its branch. If, for example, a host system has a red indicator, one or more components in the monitoring tree for the host system are displaying red alerts.

An alert is uniquely assigned to one monitoring tree element (MTE) in the monitoring tree. The alert is generated when values are sent from a data supplier to an MTE. The alert monitor evaluates this incoming information against alert thresholds. If the incoming data exceeds or violates a threshold, then the alert monitor triggers an alert. The alert monitor generates an alert for every abnormal status and keeps track of every alert until it is set to status complete.

You can also use a heartbeat alert to configure an MTE in such a way that an alert is generated if a data supplier fails to report values (see Triggering a Heartbeat Alert if No Values Are Reported).

Alert Threshold Values and Assignment to Attribute Groups

Reliable values for threshold values and the severity of alerts are predefined for all monitoring attributes. These settings are based on our extensive experience with SAP production systems.

Monitoring attributes are combined into attribute groups. An attribute group contains the threshold values that have common associated monitoring attributes. In this way, all instance-specific occurrences of the Response Time monitoring attribute belong by default to one attribute group. This means that the same threshold values are set for the response time in all instances of a system. If you want to change threshold values, you only need to change the value for the corresponding attribute group.

Alert Colors and their Meanings

By default, no alert is generated in the case of a green message. However, you can activate the generation of “green alerts” for selected nodes (see Working with All-Clears (Green Alerts)).