ADM106 Advanced SAP System Monitoring

ADM106

n    SAP Web AS 6.10

n    2002/Q4

n    Material Number: 50059038

n    Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

n    Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

n    IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries.

n    Oracle is a registered trademark of Oracle Corporation.

n    UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

n    Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

n    HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

n    Java is a registered trademark of Sun Microsystems, Inc.

n    JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

n    MaxDB is a trademark of MySQL AB, Sweden. 

n    SAP, R/3, mySAP, mySAP.com, xApps, xApp, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

n    These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

n    The mySAP.com e-business platform is a family of software and services that empowers customers, partners, and employees to work together successfully - anywhere, anytime.

n    The mySAP solutions are based on a four-tier architecture that enables frontend Internet users such as buyers and sellers to interact with a backend online transaction processing (OLTP) SAP System.

n    In the mySAP Customer Relationship Management (CRM) and Enterprise Buyer professional edition (EBP) solutions, frontend Internet users interact indirectly through CRM or EBP middleware with the backend OLTP SAP System.

n    Each Server, Middleware or Backend system is scalable and can consist of several hosts to increase the performance. All hosts are relevant for monitoring, which is essential to achieve a high availability and performance of the entire software solution.

n    Many components are involved in the processing of a business process in a modern IT system architecture. These components must be monitored, as both a gradual reduction in performance and a sudden breakdown of a component could susceptibly affect the entire productivity. It is a task of the administrator to monitor the system landscape regularly, and not only in the case of errors, but to be prophylactically active.

n    Example: A file system in which files of the SAP database are stored is 100% full. The database can no longer extend the tables in the files. A user performs a business transaction in the context of which a data record should be asynchronously added to one of these tables. The insert fails due to the space problem in the file system. The database error is seen as so serious that the entire asynchronous update process is automatically deactivated. All user sessions hang with the display of the hourglass. The SAP system hangs. If the fill level of the file system had been regularly checked, the administrator could have created space in other file systems and avoided the system downtime.

n    Monitoring should be organized as efficiently as possible. There is not enough time for an administrator to log on to each host component to check its status. An efficient monitoring structure should be able to display the entire system landscape at a glance centrally. If an error occurs, the person responsible should be automatically notified. Tools should be provided for the analysis of errors that provide cross-system detailed information about the problem.

n    All components with SAP Basis Systems can be monitored by their own. In all components detailed standard monitoring transactions are available. However, in a complex server landscape it is more helpful to get a central overview first (e.g. system availability, transaction specific response times ...) and to use the system specific analysis transactions afterwards in case of trouble.

n    Components with SAP Basis Systems or SAP Web Application Server can directly be included into a central monitoring environment using the CCMS alert monitoring architecture.

n    Components without SAP Basis are connected using CCMS agents.

n    Each component collects its own monitoring data using the infrastructure and stores it locally in the main memory. This part of the main memory is called the monitoring segment. You can configure the size of the monitoring segment.

n    The central monitoring system collects the monitoring data for the components and displays it in various views. Troughout this course material "CEN" is used to signify this central monitoring system. The actual SID can be choosen differently. In this way, you have a central view of the entire system landscape. If errors occur, you can jump directly from the central monitoring system to the appropriate component to correct a problem in a detailed analysis.

n    The central monitoring system (CEN) should be hosted on a system with high availability and high basis release (4.6C or higher). For example: in a CRM 3.0 scenario, the CRM system itself with underlying SAP Web AS 6.10 is an optimal central monitoring system

n    The CCMS Alert Monitoring Infrastructure consists of three parts: Data collection, data storage, and administration.

n    At the data collection level, small sub areas of the mySAP.com e-business platform are monitored by special programs called data suppliers. Data suppliers can be ABAP, C, or Java programs. There are over 100 data suppliers in ABAP alone. Each data supplier checks its subcomponent at regular intervals and stores the collected monitoring data in the main memory of its host.

n    At the data storage level, the area of the main memory that contains the monitoring data from the data supplier is called a monitoring segment. As the main memory data is always overwritten, monitoring segments can be permanently copied to database tables. You can then analyze the data later. The data collection and storage parts must be present locally on every component that is to be centrally monitored.

n    The administration level allows the display and evaluation of the data from the monitoring segment. SAP provides an expert tool, the CCMS Alert Monitor (transaction RZ20) as a display transaction. Alternatively, you can use the Solution Manager to display the data in a business process-oriented context. If the system identifies a problem, it can execute an auto reaction, such as informing the responsible person. The analysis method then helps you to investigate the problem.

n    The CCMS Alert Monitoring Infrastructure can be extended. You can integrate your own components using data suppliers that you have written yourself. Third-party vendors and partners can export the monitoring data from the monitoring segment using various interfaces.

n    A variety of processes, functions and systems can act as sources for SAP data suppliers and can therefore be integrated into the monitoring architecture. Some provide data from SAP functionality, some provide data from SAP solutions and some provide data from non-SAP software.

n    E.g. communication between a CRM server and the system landscape is mainly done by transactional RFC (tRFC) and queued RFC (qRFC). It is crucial to monitor the communication status regularly.

n    You find more detailed information about specific SAP components in the courses ADM100 and ADM105/BC305. CRM-related components are described in course ADM130.

n    The CCMS has an object-based monitoring architecture that simplifies the task of monitoring several SAP Systems. This monitoring architecture integrates information from the entire SAP environment to present an easy-to-manage overview of the condition of the SAP Systems and their environment. The information is displayed in a tree-based structure.

n    All nodes of the tree-based structure are called Monitoring Tree Element (MTE).

n    The information measured is combined with monitoring attributes. Monitoring attributes are the leaf nodes of the tree. They represent physical characteristics or messages related to a monitoring object. For example, the monitoring object Optimizer Statistics has the monitoring attributes Last Check and Last run. All nodes above the level of Monitor Attributes only help to find the right "leaf node".

n    For each monitoring attribute, alerts are displayed if configurable threshold conditions are met.

The SAP Solution Manager integrates in one platform:

n    System monitoring (real time)

n    Business process monitoring (real time)

n    Service level management (SLM Reporting)

n    Access to Best Practices for mySAP.com (service procedures / documents)

n    Proactive and predictive services for optimization and maintenance over the entire lifecycle (Feasibility Integration GoingLive EarlyWatch Conversion Upgrade)

n    Support desk with integrated messaging for user support (full range help desk functionality with ongoing integration into mySAP Customer Relationship Management (mySAP CRM) and a defined interface to SAP Support)

n    Remote support (desktop application sharing and service data transfer)

n    Components with SAP Basis Systems or SAP Web Application Server can directly be included into a central monitoring environment using the CCMS alert monitoring architecture. This chapter gives an overview how to use the CCMS alert monitor transaction RZ20 in general. Furthermore some useful monitors of RZ20 are presented.

n    All components with SAP Basis Systems can be monitored by their own. In all components detailed standard transactions like SM59 (RFC connections), BD87 (IDoc processing) or ST03/ST03N (Workload analysis) are available. However, in a complex server landscape it is more helpful to get a central overview first (e.g. system availability, transaction specific response times ...) and to use the system specific analysis transactions afterwards in case of troubles. The central overview is achieved by the alert monitor transaction RZ20.

n    The CCMS alert monitor consists of two transactions:

The alert monitor itself is transaction RZ20.

Global customizing settings for the alert monitor are set in transaction RZ21.

n    SAP delivers the alert monitor with a sample of useful monitor collections and monitors. These monitors are stable copy templates and can't be changed. But after copying the copied monitor can be adapted to customer needs.

n    Enter transaction RZ20. The entrance screen shows the available monitor collections (for example SAP CCMS Monitor templates). Click the ,plus' icon. Under the collection there are several monitors (for example Entire System). There is only one physical CCMS alert monitor - monitor in our context means a special part of the CCMS alert monitor. For example, Entire System shows the complete SAP system, whereas Database represents only those parts relating to database issues.

n    You can use the SAP monitors directly. Double click at the monitor which shows that part of the SAP system which is important for your administrative work.

n    Nevertheless, SAP monitors only display local monitoring 313x2319d data. If data coming from remote systems should be displayed, you have to set up your own monitors.

n    Transaction RZ21 is for global customizing of the alert monitor. Definition of remote systems, analysis and auto-reaction methods are done there.

n    The CCMS has an object-based monitoring architecture that simplifies the task of monitoring a set of SAP Systems. This monitoring architecture integrates information from the entire SAP environment and uses this data stream to present an easy-to-manage overview of the condition of the SAP Systems and their environment. The information is displayed in a tree-based structure.

n    Any node in the tree is called a Monitoring Tree Element (MTE).

n    The information measured is combined with monitoring attributes. Monitoring attributes are the leaf nodes of the tree. They represent physical characteristics or messages related to a monitoring object.

n    For each monitoring attribute, alerts are displayed if configurable threshold conditions are met. To view alerts, select a MTE and choose Display alerts. You see all alerts of this MTE and all MTEs under the selected one. For example if you work with the monitor Entire System and select the alerts of the top MTE (<SID>) you see the alerts processed for the whole system.

n    Monitoring attributes are bundled using monitoring objects at the second-lowest level. 

n    The SAP system is delivered with all the tool assignments required to monitor your system. However, you can maintain additional tool assignments and threshold conditions.

n    The meaning of the colors in the Open alerts view is explained later.

n    In a monitor you can choose Extras Display Options for adjusting the display. With the automatic display refresh option you decide whether your display should be refreshed periodically while you work in the transaction RZ21 or not. This refresh occurs at the frequency that you specify in the display options. The refresh does not collect new information; it simply updates the display with the currently available information by reading data from the shared memory. The shared memory is only updated in certain time intervals, usually 300 seconds. Therefore it is recommended that you do not set a refresh interval of less than 300 seconds.

n    You can also update the alert monitor display manually by choosing Refresh, or by performing other operations that prompt a refresh (examples of such operations are leaving the alert browser to return to the alert monitor display, or changing from the Open alerts to Current system status views).

n    Furthermore, you can choose which details of the data you want to see from the MTEs. The relevance of these options is explained later.

n    Additionally you can choose the visibility of alert information and error nodes, and you can choose if you prefer to see the current values (probably not available) or the last relevant values.

Online Help

n    Choose an MTE, press F1 and choose Long Text to obtain an online help for this MTE. You can edit this documentation to supplement it with your personal notes.

n    The Alert Monitor has two views:

Current status shows the present situation of the system.

Open alerts shows the situation of the system in the past. This view is useful for analyzing any problems that occurred since the last system monitoring run.

n    The Current status view provides an overview of the current values of the systems that were reported to the monitoring architecture. It displays the relevant values for all attributes, for example, the performance value or the last report that was received.

n    The color of the monitoring object (red, yellow or green) indicates its status, and is independent of any open alerts that may exist for that MTE. For example, an MTE may be green because everything is currently alright, even though that MTE may have open alerts. Note that the display can be set to refresh automatically so the most current system status is always displayed.

n    In the Open alerts view, i.e. the "History"-view, the system displays for each monitoring object the most important, that is the most critical and the most severe, current alert, regardless of the total number of alerts for that object.

n    For every node that you select in the tree, you can:

Display details on the alert

Customize all node elements

Start analysis methods

n    Alerts

Alerts report and log warnings and problems in an SAP System and its environment. Alerts also direct your attention to critical situations and relieve you of constantly having to review the whole set of information. Alerts must always be processed by you, otherwise they remain in the alert browser.

The alert status of each node of a monitoring tree is clearly displayed and color coded according to criticality. A red alert indicates a problem or an error, a yellow alert indicates a warning. Green status, or the absence of alerts, indicates that there are currently no problems with the component being monitored.

Alert colors and their meanings:

Red: Problem or Error

Yellow: Warning

Green: Everything OK

Gray: No information available

n    You see all alerts belonging to a MTE by double clicking on the MTE. The alerts are ordered by severity.

n    You can customize the columns that are to be displayed by defining your own "Layout".

n    In order to gather information on an alert you can execute methods that analyze the alert. These methods are predefined in the system and are specifically tailored (in analysis and display methodology) to the problem that the alert represents. By choosing an icon, you can jump from the alert to the method, which carries out a detailed analysis. There is no need to search for and gather together the analysis methods for a particular problem. The relationships between alerts and analysis methods are already specified in the monitoring object definition.

n    To start the specific analysis method which is assigned to this alert, select the alert and choose Start analysis method.

n    In the alert browser you can set alerts to Complete once they have been resolved, or it has been determined that the alert was transient and/or can be ignored. The completed alert is then removed from the list.

n    After a certain time, which can be adjusted, the open alerts are auto-completed and removed from the open alerts display.

n    The alerts which are completed or auto-completed are removed from the open alerts display. However, they are still stored in the alert history and can be displayed via Show alert history.

n    In the Alert History alerts already "completed" are shown with status Done.

n    Technically, the alert history is stored in the database table ALALERTDB. As no alert is removed automatically from this database table, there is a program which allows you to select alerts by date and remove them from the database. To start this program choose the analysis method of the monitoring attribute CCMS_SELFMONITORING\AlertsInDB.

n    You can disable the generation of alerts by deactivating the respective nodes. Activate maintenance function first, then choose Edit Nodes (MTE) Deactivate. If an inner node is selected, all nodes under the selected one are deactivated. The color of the MTEs switches to white.

n    In case of passive data suppliers (explained in chapter Customizing Methods), not only the alert generation, but also the data collection for the selected MTEs is disabled (independent of, if the data supplier is matched to other MTEs).

n    In case of active data suppliers (explained in chapter Customizing Methods), the data collection can't be deactivated, but the actual monitoring information is suppressed.

n    SAP Note 411415 gives you further information about disabling alert generation.

n    The importance of a red or yellow alert is ranked according to its severity. Since the monitoring architecture propagates alerts up the monitoring tree, it is necessary to have an attribute for prioritizing alerts that have the same criticality (yellow or red). The severity serves as this attribute. A red alert with a higher severity than another red alert has higher priority. The red alert with the higher severity is therefore propagated up the monitoring tree as the most important alert.

n    The standard criticality/severity pair of SAP for performance alerts is usually yellow 50 or red 50.

The monitoring architecture displays a tree with all monitor tree elements of the SAP System. The tree consists of different node types for storing dynamic attributes, ,static' information or just to structure the monitor. The different node types are:

n    Monitoring attribute node

Performance attribute node

Status attribute node

Heartbeat attribute node

Log attribute node

Several monitoring attributes are grouped under one monitoring object.

n    Information node

n    Summary node

Real node

Virtual node

n    The Dialog Response Time is a typical performance attribute.

n    Via Display details you can display detailed performance values.

n    Via Extras Display Options you can choose which details of the data you want to have displayed in the Display details  view.

n    The customizing of how the alert criticality (green, yellow, red) is set depending on the performance attribute values is done via Properties. Here you can choose if the comparison value is smoothed or averaged or the last reported value. This value is compared to threshold values for the different transitions between the colors green, yellow and red. E.g. for the dialog response time, it is useful to smooth the value over a certain time. Otherwise an alert could be triggered when the response time is bad for one minute, which could happen for many reasons.

n    Status attributes can deliver a message and have threshold rules. In the Open Alerts view, you can decide via Properties Status attribute, in which cases a message should cause an alert. Sometimes it is useful to suppress duplicate messages which occur regularly and are understood to be irrelevant. Analogous, messages can be suppressed as long as the message value, i.e. criticality is unchanged.

n    The criticality (color) upon alert generation can be changed to emphasize or attenuate a status transition.

Log attributes have a number of special features in the display of properties and methods. These are described here. If you want to display the properties of a log attribute, select the attribute in the alert monitoring tree and choose Properties.

Display "Current Value" If there are multiple messages in the selected log attribute, you can choose which message should be displayed:

Always display only the newest message (Last incoming message)

The message with the severest alert, irrespective of its age (Maximum alert)

The message with the severest alert that is not older than a specified time (Maximum value from the last . minutes)

n    Alert Settings You can select whether and how the messages for this log attribute should trigger alerts. Every message is assigned a color and a severity level. You can set as of which color and which level of severity an alert is to be triggered (From value), whether all messages should trigger the alert that is assigned to them (Always), or whether no messages should trigger alerts (Never).

n    Internal Storage of Message Lines : If the messages are stored in the shared memory, you can decide how many messages are stored (Maximum number of lines to be saved). If you select the radio button As many as possible, the system will store messages as long as there is enough space available in the monitoring segment of the shared memory.

n    For deciding which alerts from log attributes should be displayed at top level, there are two possibilities:

Either you add filters which reduce the severity of less important alerts

Or you increase the threshold, so that many alerts disappear, and in addition you increase the severity of important alerts to a value above the threshold

n    The method of rebalancing the severity of alerts via filters is explained here:

Via Properties you can change the filter definition for log attributes. Filters are evaluated from the top to the bottom. This allows to overwrite the revaluation of severities.

n    Note: The rebalancing of severity via filters is processed before application of the threshold.

n    Using transaction SE92 you could modify the severity of Syslog-Alerts. But SAP does not recommend to do so. as an example you may have a look at System log No.R0 / 1 in SE92.

n    The display of the alerts in the Alert view depends on the severity of the alerts after the application of the rebalancing via filters.

n    After marking MTEs, you can choose the icon Details to view details of the log attributes.

n    Virtual nodes are not stored in the monitoring segment. They exist to provide a clearer display of real MTEs in a monitor, and to collect alerts from nodes below this virtual node.

n    Note: There are two kinds of monitoring summary node:

Real summary nodes, which are saved in the monitoring segment

Virtual Nodes, which do not exist in the monitoring segment

n    The virtual nodes allow to structure the MTEs. They also collect all alerts from nodes below. Via double click on the virtual node or marking the virtual node and choosing Properties you can view all alerts from nodes below.

n    Usually information nodes are filled with information only once at the start of the SAP instance. However, an information node can also be filled by a data supplier.

n    In the examples, you see a collection of typical existing monitors for a variety of tasks.

Using the Dialog overview monitor, you can monitor the following objects of SAP instances:

n    Dialog response time: This monitoring tree element (MTE) reports the response time for the dialog service. This is the service for interactive processing, as opposed to the background or the update service.

n    Network time: Average frontend network time per dialog step.

n    Standardized Response Time: This monitoring tree element shows the dialog response time of a standard transaction created by the CCMS. The standard transaction simulates a normal transactional workload by accessing database data and running a set of ABAP function modules.

n    Users logged on: This monitoring tree element shows the number of SAP users logged on to a particular application server.
Note: SAP users are automatically distributed at logon to application servers according to the quality (response time) at each server and according to any logon groups that you have created.

Using the Database monitor, you can monitor the following objects:

n    Space management: monitors the space situation in your database

n    Performance: monitors database performance

n    Backup/restore: informs about the status and time of the last backup

n    R/3 Consistency: Monitors the database tables and checks for missing unique indexes (it also takes the SAP exception table into account). Monitors consistency between ABAP Dictionary and Database.

n    Health: monitors use of auxialiary storage pool (ASP)

In the standard configuration of your SAP System, the database library is located in ASP1. The journal receivers are in ASP2. This separation avoids disk failure.

When the ASP2 is filling, the system starts storing journals in ASP1. This is called ASP overflow.

ASP overflow is dangerous because it does not ensure possible data recovery.

Please search SAP Library with term "ASP1" to find more information about this topic.

Using the Operating system monitor, you can monitor the following objects:

n    CPU: monitors CPU utilization

n    Paging: monitors page faults

n    Commit charge: monitors the complete memory (physical and virtual), that is used by programs or by the operating system

n    OS collector: checks whether the operating system collector (saposcol) is running

n    LAN: monitors LAN activity

n    File systems: monitors the file systems in a host server

With the Central Syslog you get a central overview over the system logs of your SAP application servers. This is possible for any operating system. You can even get a central overview over all SAP instances of your entire system landscape.

n    To monitor the system log (syslog), the syslog messages are grouped into thematically linked subtrees. The subtree in which an alert is reported depends on the category of message. You set these categories depending on the message ID in transaction SE92. In this transaction, you also set the syslog message text and the criticality and the severity of the alert.

n    You can additionally correct the criticality and severity of the alerts for individual intervals in transaction RZ20 by choosing the desired category, Attributes and Filter.

The CCMS Selfmonitoring reports on the status of the monitoring architecture and the alert monitor itself.

Check the self-monitoring system whenever you check the rest of your SAP System. Among other monitoring functions, the self-monitoring system shows whether the alert monitor has been able to:

n    Start the data collection methods for which it is responsible (monitoring tree elements for SAPMSSY8, the ABAP report that periodically starts collection methods)

n    Allocate and access the shared memory that it needs for collecting and managing data and alerts

n    Establish RFC communication links to remote SAP Systems and components.

Individual alert monitor methods (data collection methods and automatic reaction methods) can also register problems and status in the self-monitoring tree. The self-monitoring tree also registers whether a reorganization of the list of completed alerts is recommended, in order to reduce the storage needed in the database for these alerts.

Monitoring Basics Exercises

	Unit: Monitoring Basics Topic: Using the CCMS Alert Monitor
	At the conclusion of this exercise, you will be able to: Work with the CCMS alert monitor
	The CCMS alert monitor is the entry point for your daily system monitoring. You use the different views of the monitor (history and current status), and the alert browser. In case of an alert, you jump into an analysis action, and complete the alert afterwards. After the exercise, you should be familiar with the mechanisms of the CCMS alert monitor.

2-1 Use the CCMS alert monitor.

2-1-1 Log on to CEN. Start transaction RZ20. Open (by double-clicking) your monitor ADM106_## (## is your group number) of monitor set ADM106. This monitor displays information about the dialog performance of your system.

2-1-2 Change the display options:

Autorefresh: Every 5 minutes

Display Alert Text: On all nodes

Error nodes: Do not display

2-1-3 Display the detailed data for ResponseTime.

2-1-4 Switch between the different views of the monitor. Check the current situation and the situation in the past. Display the alerts for one monitoring attribute. Display the alerts for the complete monitor.

2-1-5 Start the analysis method for one alert. Does it work? If not, why not? Start the analysis method for the MTE ResponseTime. Which transaction is started? Why? Is this transaction useful for analyzing response time problems in the past?

2-1-6 Confirm some alerts. Can you display the alert information again? How?

2-1-7 Where can you check how many alerts are stored in the database? When was the last check?

2-1-8 Where can you check how many alerts are stored in the shared memory

Information about the shared memory segment and the alert database can be found in the CCMS selfmonitoring. Take a look into the monitor set SAP CCMS Technical Expert Monitors.

Monitoring Basics Solutions

Unit: Monitoring Basics Topic: Using the CCMS Alert Monitor

2-1 Use the CCMS alert monitor.

RZ20: Tools CCMS Control / Monitoring Alert Monitor

RZ21: Tools CCMS Configuration Alert Monitor

2-1-1 Open transaction RZ20. Click the plus (+) icon next to monitor set ADM106. Double-click your monitor ADM106-## (## is your group number).

2-1-2 In your monitor, choose Extras Display Options.

Select the General tab and enter 300s (seconds) for Refresh display.

Select the Dsply tree tab. Select Display alert text on all nodes (MTE) and Error nodes: Do not display. Choose Enter.

To save the display options for this monitor, choose Save.

2-1-3 Expand the monitor tree to the leaf nodes. Select ResponseTime and choose Display details. You can see the last 30 minutes and the average values for the last 24 hours. Choose Back to go back into your monitor.

2-1-4 To switch between current and history view, choose Current status or Open alerts. In the Open alert view, double-click a red monitoring attribute. All alerts of this attribute node are displayed in the alert browser. Choose Back. Double-click the root node of the monitoring tree. All alerts of the tree are displayed in the alert browser.

2-1-5 In the alert browser, check one alert and choose Start analysis method (gauge icon). Normally, an information message ".:no method assigned" should appear. Then choose Properties and select the Methods tab. For Analysis Method, you will find the entry <NO_METHOD>, which means that no method is assigned to this MTE.

Choose Back. Choose Back once more to go back into your monitor. Select ResponseTime and choose Start analysis method. The transaction ST03N is started out of the monitor. This transaction is best for analyzing SAP performance history.

Choose Back to go back into your monitor. Choose Properties for ResponseTime and select the Methods tab. Under Analysis method, you will find the entry CCMS_ST03. This is an alias name, defined in transaction RZ21. Double-click this entry. You jump into the definition screen of CCMS_ST03. Under To be executed, you will find the transaction ST03N.

Now, you know why an analysis method is started or not. Later in this course, you will learn how to adapt methods in the CCMS alert monitor.

2-1-6 Open the alert browser to display all alerts of your monitor (exercise 2-1-4). Select one alert and choose Complete alerts. The alert vanishes from the list (out of shared memory) and is stored in a database table. To display the alert again, choose Show alert history. The alert is displayed in the list (status is DONE).

Follow these steps to work with the CCMS monitor:
Open a monitor.
Check the current status.
Open history view.
Open the alert browser to display all alerts.
Check the alerts by starting the corresponding analysis methods.
Complete the alerts afterwards until the alert list is empty.

2-1-7 To check the contents of the database table, which stores the alerts, open the monitor CCMS Selfmonitoring of the SAP monitoring set SAP CCMS Technical Expert Monitors by double-clicking it. Expand the tree <SID> CCMS_Selfmonitoring Runtime AlertsInDB. This monitoring attribute measures the number of alerts in the database. The value is updated twice a day.

2-1-8 In the same monitor, expand the tree <SID> MoniInfra_ <Instance> Space FreeAlertSlots. This monitoring attribute displays the number of free alert slots of the instance's shared memory. Select this MTE and start the analysis method by clicking the gauge icon. A detailed information screen about the shared memory filling level is presented. Press ENTER to go back.

n    The CCMS alert monitoring architecture is able to monitor remote SAP systems (SAP Basis of 4.0B or higher) centrally. To achieve this, it is possible to set up a central monitoring system (CEN) which shows the situation of the system landscape in one view. If something goes wrong in a remote system you can directly jump from CEN into the remote system for further analysis. There is no need anymore to log on to each component locally to check its health.

n    From the technical point of view, the data which is displayed by RZ20 is stored in a shared memory segment of each SAP instance. The shared memory segment can be read out by CEN via an ABAP RFC call or by connecting to an CCMS agent which is described later in this unit. CEN only requests monitoring data, which is delivered by the remote component. The data is NOT stored permanently in CEN.

n    To include a remote SAP system into CEN two RFC connections must be created:

One for pulling the performance data from the remote system. Enter a communication user (type System or CPIC (or Communications)) with the appropriate password into the RFC connection. In CEN you can enter RZ20 and monitor performance data from the remote system without log on.

One for analysis actions done in the remote system. Don"t enter a user into the RFC connection. If an administrator of CEN wants to analyze something in the remote system in case of trouble, he or she has to log on using a valid user account.

n    The roadmap to register remote SAP systems in CEN is as follows.
All steps are processed only in CEN:

Create 2 RFC connections of type "3" from CEN to the remote SAP system using transaction SM59:

One for data transfer with a valid CPIC (or Communications)/System user account in the remote system. The CPIC (or Communications)/System user should have limited authorizations in the remote system. Set up one authorization based on authorization object S_CCM_RECV with value "P0-P9" for field ACTVT and value"*" for field TABLE.
The second authorization is based on authorization object S_RFC.
Enter "FUGR" for field RFC_FUGR,
"SALC, SALF, SALH, SALS, SAL_CACHE_RECEIVE, SYST, SCSM*" for field RFC_NAME and "16" for field ACTVT.

The second RFC connection should be set up without a user entry. Mark "Current user" instead.

There is no naming convention for RFC connections. Nevertheless, is makes sense to name RFC connections as clear as possible. A proposal for RFC connection names might be <SAP-SID>CLNT<Client Number> with suffix _DATA and _ANALYSIS, e.g. DEVCLNT100_DATA.

n    Remote SAP systems are registered in CEN using transaction RZ21. Choose Technical Infrastructure Create remote monitoring entry

n    If necessary, adapt the CCMS monitors in CEN to include data of the remote SAP systems.

n    This slide shows the two RFC definition screenshots of transaction SM59. Don't forget to enter the target host system data properly. The dynpro fields are visible after selecting connection type "3" and pressing ENTER.

n    You should test the RFC connections by choosing "Test connection" or "Remote logon". In case of the RFC connection with a CPIC (or Communications)/System user account, you can't try "Remote logon". Nevertheless, the user and password can be tested by choosing Test Authorization

n    In CEN, start transaction RZ21 and choose Technical Infrastructure Create Remote Monitoring Entry

n    Make the following specifications in the definition screen:

Target System ID: Specify the name of the SAP system that is to be monitored. Examples: C11, R3P

RFC destination of  target system for data coll. and for execution of analysis method: Specify the names of the RFC connections to the remote SAP system. To display a list of the defined connections, choose Goto RFC Connections

n    Choose Save. When saving, the monitoring SAP system automatically tests the connection to the remote SAP system. If the RFC connection does not work, the system displays an error message. If an error occurs, correct and test the connection using transaction SM59.

n    In CEN, remote SAP systems can be grouped together. These system groups can be used later to set up rule based monitors.

n    A system group can contain more than one system. A system can be member in more than one system group.

n    It is useful to group systems of the same operating system, database or SAP release. Another useful grouping is the system type (development, quality assurance or production).

n    Since SAP Web AS 6.10, a new topology display has been introduced, which offers in CEN a better overview of the system landscape. Start transaction RZ21 and choose Technical Infrastructure Display Topology

n    Under Monitored SAP Systems, you get an overview of the registered SAP systems.

n    Choose the tab strip Local Segments. A segment is a shared memory area, which is allocated by the SAP instance during startup. There is one segment per SAP instance, and you can check the status of the segment by clicking the c-clamp icon. You can switch off the CCMS monitoring infrastructure on a "per segment level" by setting the status "offline".

n    A segment is internally divided into several parts, the contexts. Select the tab strip Local Contexts. A context is an enclosed monitoring area. E.g. there is exactly one context available for all database issues.

n    By double clicking a remote SAP system, you can retrieve the segments and contexts of a remote SAP system.

n    Until recently, individual monitoring tasks could not be dealt with, or could only be insufficiently dealt with. For example, CCMS could not monitor components based on SAP R/3 3.x  and non-SAP components centrally. Additional data bottlenecks occurred at times of low performance, as the component that was to be observed because of high response times could only return data slowly using RFC.

n    The new agent concept in central monitoring deals with these bottlenecks.

n    CCMS agents are stand-alone processes that act as an RFC server to a central monitoring system. Agents are fully supported, if CEN has a SAP Basis 4.6C or higher.

n    The advantages of the agent concept in detail:

Simple, automatizable installation: The installation of the agents is simple and can be performed either in dialog mode, or using a script. The script is always the same, because it contains only information about CEN. Therefore, the script control allows administrators of large system landscapes to perform installations concurrently on multiple components without having to manually control every installation.

Seamless data transport:  Agents can transfer the data from the CCMS alert monitoring infrastructure without occupying an SAP work process. On components without SAP Basis or SAP Web Application Server, the agents can return the operational data, such as CPU utilization, paging rates, file system data, and network data. In addition, you can monitor individual processes.

Extensive log file monitoring: Non-SAP components, such as databases, normally write their status and error messages to log files. You can use the agent to search these log files for any combination of characters, and to report them either as error states or target states in the central monitoring system. In this way, you can easily detect and deal with error states in non-SAP components.

Third-party integration: Agents can write alerts that have occurred in the CCMS Alert Monitoring Infrastructure to a log file. Third party software products can easily access this file and react appropriately.

Open flexibility: You can extend agents with regard to the data they determine and manage. Dynamically loaded libraries can be included through a plug-in interface. There is, for example, a plug-in available for monitoring SAP ITS. A Java interface, with which Java programs have access to the monitoring segment, is also available.

n    mySAP Technology provides three CCMS agents that have specific monitoring functions for non-SAP components and SAP components based on SAP Basis 4.x and earlier:

SAPCCMSR for non-SAP basis components

SAPCCM4X for components based on SAP Basis 4.x

SAPCM3X for components based on SAP Basis 3.x

n    SAPCCMSR monitors components on which there is no active SAP instance and therefore no CCMS alert monitoring infrastructure. It determines the fill level of the file system and detailed operating system information. You can use this agent to analyze log files from external applications. Parts of the mySAP.com e-business platform that have no CCMS alert monitoring infrastructure - such as the SAP Internet Transaction Server (SAP ITS) - can be connected through this agent.

n    SAPCCM4X centralizes and improves the monitoring of SAP components with SAP Basis 4.x or later. To do this, the central monitoring system requires at least SAP Basis 4.6C. The agent provides an alternative connection route to the monitoring information in the shared memory of an SAP instance. This alternative connection route does not require a free work process for CEN access to data from SAP Basis 4.x components and is, therefore, more robust.

n    SAPCM3X allows you to centrally monitor SAP instances with SAP Basis 3.x , although SAP R/3 3.x  components do not have a specific CCMS alert monitoring infrastructure. The agent accesses the dispatcher's old shared memory segment.

n    The agent SAPCM3X connects to the old dispatchers shared memory segment and transfers the monitoring information to CEN.

n    The SAP 3.x  system is assigned to CEN, because it has not it"s own monitoring infrastructure. All threshold customizing and method assignment is only done and permanently stored in CEN. There is no need to transport alert settings into the 3.x system.

n    The CCMS agent SAPCM3X delivers information about the configured services and response time information for dialog and update service.

n    Moreover, the "old" alerts displayed in transaction AL01 are transferred to CEN. In the SAP 3.x  system, use transaction RZ06 to configure the "old" alert settings.

n    Like all agents, SAPCM3X is able to communicate with SAPOsCol to transfer all its operating system information to CEN. You can configure additional monitoring activity like single process monitoring or log file monitoring.

n    The CCMS agent SAPCCM4X offers a more performant and robust communication between CEN and a centrally monitored SAP 4.x  system. CEN does not retrieve the monitoring information via an ABAP RFC call anymore. CEN connects directly to the SAPCCM4X agent, which is connected to the shared memory of the SAP instance. The monitoring data can be transferred without usage of a dialog work process of the monitored system.

n    Before installing the SAPCCM4X agent, the SAP system has to be registered in CEN by usage of the common ABAP RFC connections. The ABAP RFC connections are used in special cases, e.g. if an alert of the remote system is completed in CEN. In this case, the alert information is stored in the database of the remote system. The SAPCCM4X agent has only connection to the shared memory of the SAP instance, but not to the database.

n    The CCMS agent SAPCCMSR is especially designed to connect all components without SAP Basis on it. This agent is crucial for the new JAVA-based components of SAP like the SAP J2EE server. The possibilities of monitoring mySAP components without SAP Basis are described in the next chapter.

n    Together with SAPOsCol, SAPCCMSR makes RFCOsCol obsolete.

n    After you have installed the CCMS agent SAPCCMSR, it attempts to attach itself to the monitoring segment in shared memory when starting. If this segment does not yet exist, the agent creates it. SAPCCMSR always works in a shared memory area that is independent of running SAP systems. The default size of the shared memory segment is 16.000.000 Bytes. You can change the size of the segment by setting the profile parameter alert/MONI_SEGM_SIZE (see also SAP Note 135503).

n    Like the CCMS agent SAPCM3X, the monitoring segment of SAPCCMSR is assigned to CEN. All threshold customizing and method assignment is only done and permanently stored in CEN.

n    Agents have their own release cycle. You should get the newest agent version from the SAP FTP server SAPServX. Agents are downward compatible. An SAPCCM4X agent version 6.20 can act with an SAP system of Basis release 4.x . In case of an SAPCCM4X agent, first you have to register the SAP 4.x system by usage of the the ABAP RFC connections.

n    The agent has to be registered to CEN. During installation, CEN system information and a valid user login is requested. The user account is used to insert the necessary registration information and to create a RFC connection from CEN to the agent program. The installation is started by:

sapccmsr -r [-f <File name>]

sapcm3x -r [-f <File name>]

sapccm4x -r pf=<Profile path> [-f <Filename>]; <Profile path>: Path and name of the SAP instance profile

<File name> is the name of the configuration file for the dialog-free installation of the agent. If you do not use this option, the installation is performed in dialog mode.

n    Under Windows NT and Windows 2000, the agent has been entered as a service and started. The agent is automatically started at every restart of the server. If you have installed the CCMS agent on a UNIX platform, the agent is started by entering:

sapccmsr -Dccms

sapccm4x -Dccms pf=<Profile path>

sapcm3x -Dccms.

n    The final central monitoring infrastructure is like this:

Your CEN system is of SAP Basis 4.6C or higher. All central administration functions like Solution Manager, Central User Administration or Transport Domain Controller can be placed there.

Your SAP systems of release 4.x or 6.x are connected to CEN via the CCMS agent SAPCCM4X. Install one agent per SAP instance.

Your SAP systems of release 3.x  are connected to CEN via the CCMS agent SAPCM3X. Install one agent per SAP instance.

All other components without SAP Basis are connected via the CCMS agent SAPCCMSR. Install one agent per host.

n    In CEN, you can set up monitors which show overview or detailed data of your system landscape. In case of an error, you jump out of your central view into a detailed analysis action.

n    The agent technique adapts CCMS central monitoring to the heterogeneity of modern system landscapes and offers high scalability.

n    The topology display offers a detailed view of the CCMS agents which are registered at CEN. Select the tab strip CCMS Agents.

Agent for SAP System <SID> shows all registered SAPCCMSR agents.

Agents for Remote SAP Systems shows all registered SAPCCM4X agents.

Agent for SAP R/3 3.x  Systems shows all SAPCM3X agents.

n    You can check the communication status by clicking the icon similar to a gauge, marked in the graphic.

n    The document "CCMS Agents: Features, Installation and Usage" is located in Service Marketplace under the Quick Link /monitoring. This documents describes, where to find and how to install the agents. The agents functions are improved continuously. Please check for an updated version from time to time.

Including Remote Components Exercises

	Unit: Including Remote Components Topic: How to Include Remote Components
	At the conclusion of this exercise, you will be able to: Register remote SAP components Check whether the connections from CEN to the remote components work properly
	With the CCMS alert monitor, you are able to monitor remote components centrally. The remote components have to be registered first.

3-1 Include remote components.

3-1-1 What transaction is used for registering remote SAP components?

3-1-2 Open the Topology Display in CEN. Perform a connection check to a remote SAP component.

3-1-3 If a CCMS agent is registered to CEN, how can you display log files of this agent?

Including Remote Components Solutions

Unit: Including Remote Components Topic: How to Include Remote Components

3-1 Include remote components.

3-1-1 Use transaction RZ21 for registering remote SAP components. Open transaction RZ21 and choose Technical infrastructure Create remote monitoring entry.

3-1-2 Open transaction RZ21 and choose Technical infrastructure Display topology.

Select one SAP system and choose Test connection. The RFC connection to the child system is tested.

3-1-3 If an agent is registered by the instructor, open the topology display (exercise 3-1-2) and select the CCMS agents tab. Choose the tab for the right agent. Select the agent's entry and choose Work directory of agent. All files of the agents work directory are presented. Double-click a file. The agent transfers the file content.

You can analyze agent problems by using this function centrally.

n    The CCMS Alert Monitor is delivered with stable monitoring templates that can be used either directly or as copy templates. They are predefined and fully customized views on the SAP system.

n    There are monitors for the entire SAP system and for specific areas of the system architecture, such as for data archiving, security, communication and for the database. The MTEs displayed in these SAP monitor templates cannot be changed, but they can be copied and the copy can be modified.

n    Sometimes only a subsystem of your system landscape will be monitored.
When you work with the SAP Alert Monitor:

You can use the predefined SAP monitor templates. Check if there is a specific template for the part of the system that will be monitored, otherwise all the MTEs of the SAP System are shown in the SAP template System / All Monitoring Segments / All monitoring Contexts.

You can copy an SAP monitor template and modify it using Transaction RZ20. However, to do this, you must first activate the maintenance function (under Extras Activate maintenance function). To increase the clarity, you should define your own monitor set and put the copy of the SAP monitor template into the new set.

n    Some SAP monitors are empty by default. Examples are:

Availability: Selected Systems

Transaction-Specific Dialog Monitor

SAPconnect

n    Additional customizing is necessary to activate the corresponding data suppliers. The data suppliers are not activated by default, because on the one hand it is not clear if these components are used by the customer. On the other hand, the appropriate entries can only be set by the customer.

n    The next chapter describes, how the availability check and the transaction specific monitoring can be activated.

n    Keep in mind: if an additional data supplier is activated, additional data must be stored in the corresponding monitoring segment. If no space is available in the segment, the data supplier run fails and the corresponding monitor stays empty.

n    Open the monitor CCMS Selfmonitoring in SAP monitor set SAP CCMS Technical Expert Monitors. The monitoring segment is instance specific. The free space of a segment can be analyzed by starting the analysis method for the attribute node Messages.

n    The instance parameter alert/MONI_SEGM_SIZE regulates the size of the shared memory segment. The size can"t be changed dynamically. Use transaction RZ10 to maintain the parameter.

n    If you want to create own monitors which show special characteristics of your system landscape, you have first to create an own monitor set. In CMS start transaction RZ20 and choose Extras >> Activate maintenance function. All necessary icons like Create, Change, Copy appear.

n    Click Create. You can now create your own monitor set. You can copy a SAP monitor into your monitor set and change the monitor.

n    If you like to create your own monitor position on your monitor set and click Create.

n    The name of the monitor set must not begin with "SAP", otherwise the system ranks this monitor set like sets, delivered by SAP. In this case, you can't insert monitors into the set and you can't delete the set.

n    The attributes of a monitor set determine if the set is visible for or modifiable by other users. If modifiability is set to "Only by me", an administrator has to change the attribute of the set first before changing a monitor of the set.

n    The Public flag controls, if the monitor set is visible for other users in the entrance screen of transaction RZ20 without activating the maintenance function. Check this flag for your personal collections.

n    SAP monitor sets and SAP monitors can't be changed. They are stable copy templates.

n    After setting up your own monitor sets, you can uncheck the Public flag of the SAP monitor sets. These sets vanish out of the entrance screen of transaction RZ20. If you want to switch the visibility option back to Public, activate the maintenance function by choosing Extras Activate maintenance function. You will find the SAP monitor sets by expanding the tree All - SAP.

n    If no appropriate SAP template is available, you can define a new monitor. Remember that a new monitor means a new view on the known MTEs of a system. The thresholds and methods of an MTE can be customized only once and is valid in all monitors.

n    To create a new monitor, call Transaction RZ20 and activate the maintenance function. Then mark your monitor set and choose Create.

n    All the MTEs known by the system are displayed, select the MTEs you want for the new monitor. To change an existing monitor, from Transaction RZ20 mark the monitor, and choose Change. Note that SAP monitor templates cannot be changed.

n    To organize the structure of your  monitor, you can insert virtual nodes that are used as a description. These nodes are marked with a special icon (a circle with a cross in the center). Any MTEs can be aligned under virtual nodes.

n    There are two possibilities to create your own monitor:

Under Selectable MTE you can directly select any MTE of all known systems (CEN and all known remote systems) by marking the checkbox. All MTEs under the marked MTE are  selected implicitly. Building a Static monitor means selecting MTEs directly. This is the easiest way to set up an own monitor. The disadvantage is that may be the monitor must be adapted after some more remote systems are included into CEN. This type of monitor is appropriate for small and stable system landscapes, such as a standard three-tier system landscape.

You can add a rule node by clicking Create nodes. You don't select MTEs directly, furthermore you describe with fixed rules which MTEs you want to see. The monitor is always up to date, because the rules are updated while opening a monitor. This type of monitor is appropriate for huge and dynamic system landscapes.

You can combine static and rule based monitor techniques.

n    You should build monitors in CEN which show exactly these parts of your system landscape which are crucial for your productive business. Keep the amount of data, transferred from the remote components and displayed in CEN, in mind. It is useful to set up several monitors for different monitoring purposes.

n    In this example, a monitor is designed for showing all SAP buffers on all SAP instances that are known and running at the moment the new monitor is created.

n    To create a static monitor, expand the tree under Selectable MTE  until you see the MTE Buffers for all SAP instances. Select the buffer MTEs, and choose Save.

n    This new monitor shows all the MTEs that are aligned under the Buffers. This means, the program buffer, generic, and single record table buffer, screen, CUA buffer are displayed.

n    The advantage of creating a static monitor is its simplicity. Only select what you want to see.

n    The disadvantage of creating a static monitor is that you can only select what is known and running at the moment the new monitor is created. For example, if one of the SAP instances is not running at the moment the new monitor is created, none of the MTEs relating to this instance can be selected. If new SAP systems are included into the monitoring architecture later on, they are not shown in the static monitors that were already defined. Another disadvantage of creating a static monitor is that you man have to select a lot of MTEs of a special MTE class, and you may forget to select some of them.

n    Instead of using static monitors, you can select MTEs dynamically, using rules. The MTEs that you want are not marked explicitly, they are described dynamically. The monitor runtime environment processes rules to make sure that a monitor that includes rules is updated periodically.

n    Rules are predefined by SAP. By changing the parameters of the rules, you can influence the MTEs processed by the rules.

n    The rule CCMS_DEFINE_R3_SYSTEMS creates virtual MTEs for R/3 Systems.

n    The selection options include ALL (all available SAP systems); CURRENT (SAP system in which the alert monitor is running), and specific systems by name. You can also include in your monitor those systems that are included in system groups.

n    You use this rule to set up rule-based monitoring across one or more SAP systems. Rule MTEs that you add below this MTE are interpreted for each system that you have selected. You add monitoring functionality by creating virtual and/or rule MTEs under this MTE.

n    All monitoring objects and attributes are associated with MTE classes. Examples: The ResponseTime monitoring attribute is assigned to the MTE class R3DialogResponseTime; AbortedJobs is assigned to MTE class R3BPServerSpecAbortedJobs. An MTE class is a container for MTEs of a special type.

n    CCMS_GET_MTE_BY_CLASS inserts monitoring functionality by MTE class. The <MTEclass> parameter lets you add monitoring functionality by MTE type: CPU, response time, background, and so on.

n    Since all instances of a particular MTE share a single MTE class, the class selection rule lets you select monitoring objects across SAP instances and systems. For example, you can create a monitor for SAP buffers in all SAP instances.

n    Adding MTEs by class also adds any subordinate MTEs. Example: Adding the MTE class "R3Buffers" also adds the subordinate MTEs Program, SingleRecord and so on, even though these MTEs have different MTE classes.

n    You can display the MTE classes that are available using the F4 help. This does not display where an MTE class appears in the monitoring tree, so it can be hard to find the MTE class that you want. To do this, open one of the standard monitors of the MTE that you want to include in a monitor. Then choose Properties to display the MTE class of the MTE.

n    If you have stacked rule MTEs (that is, inserted CCMS_GET_MTE_BY_CLASS under CCMS_DEFINE_R3_SYSTEM ) then the subordinate rules inherit the SYSTEM specification in the primary rule.

n    Example: If you specify <ALL> for CCMS_DEFINE_R3_SYSTEM , then subordinate "MTE_BY_CLASS" rules also select from <ALL> SAP systems.

n    The effect: Your monitor is structured by SAP system. Under each system entry in the monitoring tree, you will find the MTE_BY_CLASS selection for that particular system.

n    You cannot stack multiple instances of a rule MTE in a hierarchy. Example: The alert monitor issues an error message if you try to create a CCMS_DEFINE_R3_SYSTEMS rule MTE under another CCMS_DEFINE_R3_SYSTEMS MTE.

n    You cannot create rule MTEs or virtual MTEs in the Assigned MTE hierarchy of MTEs for static selection

n    Use these two rules in conjunction. They return the same results as the CCMS_GET_MTE_BY_CLASS rule, but the information you require is displayed in a more clearly structured form.

n    When you select the CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL rule, use the <MTEclass> parameter to include the MTE class as a virtual node in the tree. (Virtual nodes are used as "headings" under which you can group MTEs.

n    You then select the CCMS_GET_MTE_BY_CLASS_UNDER_CLASS rule. In the <ChildMTEclass> parameter, you then specify the MTE classes that you want to monitor as real nodes in your monitor.

n    Before usage of these two rules, please take SAP note 454768 into account. The Basis support packages should be installed in CEN system.

n    As of SAP basis release 4.6C, the rule CCMS_GET_MTE_BY_CLASS_AND_CLIENT is able to process client dependent monitoring data. The parameter R3Client can be set to a specific client, <ALL> or <CURRENT>.

n    In the example above, client dependent ALE information is displayed.

n    Hint: Most of the monitoring data is client independent.

n    Hint: Be careful with the parameter value <CURRENT>. Although such a monitor definition can be transported into other systems, the monitor stays empty, if there is no information available with respect to the logon client. This leads often to the assumption, that there is something wrong with the CCMS monitoring architecture.

n    As of SAP Web AS 6.10, the rule CCMS_GET_AVAILABILITY_FOR_SYSTEM is able to process availability information delivered by the CCMS agent CCMSPING (which is described in the next chapter). This rule is for selecting single monitored SAP systems (parameter R3System).

n    Hint: Use the rule CCMS_GET_MTE_BY_CLASS with CEN for parameter R3System and  Availability_SystemSummary for parameter MTEClass for displaying all monitored SAP systems.

n    Hint: This rule does not implement an availability check. The information displayed is delivered by the CCMS agent CCMSPING, which has to be installed and configured before.

n    The rules CCMS_GET_MONITORING_SEGMENT_NAMES and CCMS_GET_MONITORING_CONTEXT_NAMES are for internal use only.

n    Virtual nodes processed by rules can be faded out. In case of a single system monitor, the system information is unnecessary. In case of a multi system monitor, the display of the virtual nodes can be activated easily.

n    This feature only make sense for the rules CCMS_DEFINE_R3_SYSTEMS and CCMS_GET_MTE_AS_VIRTUAL.

n    Hint: Keep in mind, that monitor definitions can be transported and used in different system landscapes. It may be useful to include structuring rules like CCMS_DEFINE_R3_SYSTEMS or CCMS_GET_MTE_AS_VIRTUAL although only one SAP system or one application server is actually monitored.

n    The name of a monitoring attribute consists of four parts:

SAP system name

Name of the corresponding context of the MTE

Name of the corresponding monitoring object

Short name of the attribute.

n    By default, all parts of the name are displayed. If the meaning is clear, you can disable the display of name parts. In the example above, the SAP system and instance name is presented by the virtual node above.

n    The first step is to create own monitor sets. When the setup procedure is completed, only your monitor sets should be visible by default.

n    Only you can decide what is the aim of the monitor, which monitoring information is important to you and should be displayed in the new monitor. To keep the structure of the monitor clear and the data transfer from the remote systems to the CEN small, only the most important indicators should be included in the monitor. It is useless with respect to performance and data transfer rate reasons to set up a monitor, which shows all monitoring data of all registered systems.

n    The number of MTEs and SAP systems included in the monitor affect the technique, how to build the monitor. Static monitors are only useful for monitors, which show only few MTEs of a single stable system.

n    Work with two modi in parallel:

One for determine the MTE class of the desired MTE. If you have problems to find an MTE you are looking for, take a look into the monitor System / All Monitoring Segments / All Monitoring Contexts which can be found in the SAP monitor set SAP CCMS Technical Expert Monitors. This monitor shows all information of the local system.

One for directly setting up the monitor.

n    Structure your monitor with virtual nodes, included by rules or directly by you.

n    The first example is a monitor, which shows detailed dialog information. Besides the standard components of the overall dialog response time, the frontend response time and the users logged on are shown. If there is a problem with the response time, the monitor gives you directly a hint, where the problem could be located.

n    This information is similar to the data shown in the SAP workload monitor ST03N.

n    By changing the rule CCMS_DEFINE_R3_SYSTEMS to <ALL>, the monitor shows this dialog information for all registered SAP systems. The monitor can than be structured by including virtual nodes per SAP system.

n    This monitor could be expanded by including transaction specific response times (see next chapter).

n    The second example is a monitor, which is a more general performance tool. Not only dialog information, but also memory management and operating system information is presented. From the buffer part, only the most critical program buffer swap is included. The paging information should be adapted with respect to the operating system.

n    This information is similar to the data shown in the SAP workload monitor ST03N, the buffer monitor ST02 and the operating system monitor ST06.

n    By changing the rule CCMS_DEFINE_R3_SYSTEMS to <ALL>, the monitor shows this performance information for all registered SAP systems. The monitor can than be structured by including virtual nodes per SAP system.

n    This monitor could be expanded by adding the resource consumption of the SAP workprocesses or the database which is described in the next chapter.

n    The third example is a monitor, which presents main system errors. It is structured in the error areas ABAP Dumps, Aborted Jobs, Aborted Updates and Syslog.

n    This information is similar to the data shown in the transactions ST22, SM37, SM13 and SM21.

n    By changing the rule CCMS_DEFINE_R3_SYSTEMS to <ALL>, the monitor shows this error information for all registered SAP systems. The monitor can than be structured by including virtual nodes per SAP system.

n    This monitor could be expanded by adding the status of the update service which is described in SAP note 449197.

n    The article "Infrastructure Insights: How to Set Up Your Own Customized Monitors for mySAP.com Solutions" in Sapinsider issue April-June 2002 describes step by step, how to set up a monitor. This article can be found by browsing through the article archives in https://www.sapinsider.com.

n    The following problem may occur: you know, what information should be included into your monitor, but you are not sure, which MTE represents this information. The documentation "Preconfigured Monitors" gives an overview about the information presented in the CCMS monitors of SAP Web AS 6.20. This documentation is also valuable for older releases.

n    The drag & drop functionality of the SAPGUI list viewer is very limited. The structure of a rule based monitor definition can only be changed by deleting and creating. A JAVA based tool is delivered by the CCMS group, which offers drag & drop functionality while changing a monitor definition. The preconditions are:

The monitor definition has to be downloaded to an XML file. This is possible, if CEN SAP Basis release is at least 4.6D. This XML file is imported into the JAVA tool, changed, and uploaded back into CEN.

You need a JAVA VM to run the JAVA tool. The JAVA VM can be found under https://java.sun.com.

The JAVA tool can be found under /general/misc/ccms-ma/monitor-definition-tool on the SAP FTP server.

Creating New Monitors Exercises

	Unit: Creating New Monitors Topic: How to Create a New Monitor Set
	At the conclusion of this exercise, you will be able to: Create static monitors Create rule-based monitors
	After including remote components, you have to set up your own monitor sets and monitors. These views can display information from both local and remote components. You can use either static or rule-based monitor definitions.

4-1 How to create a new monitor set and a new monitor using a template.

4-1-1 Create your own monitor set ADM106-##. Select Modifiability: Only for administrators and me. Clear the Public flag. Save your settings.

4-1-2 Copy your monitor ADM106_## from monitor set ADM106 to your monitor set.

4-2 Consider these issues before you create your own monitors.

4-2-1 A monitor should serve a certain purpose. The purpose of your monitor is to display dialog-specific information.
Consider in advance: What information should be displayed in a specific dialog monitor (no more than 5 values)?

4-2-2 What information is available? What does the displayed information mean? What information should be transferred to a separate monitor? What threshold values would you recommend for the information that is displayed? Do you know appropriate analysis methods for your monitoring area?

Dialog Information	Important?	Threshold Values green > yellow; yellow > red; red > yellow; yellow > green	Analysis Method?
ResponseTime
FrontendResponseTime
QueueTime
Load+GenTime
DBRequestTime
Utilization
NumberOfWpDIA
QueueLength
LongRunners
ProgramErrors
DialogSteps
GuiCallbackTime
FrontEndNetTime
MonitoringTime
ResponseTime (StandardTran.)
UsersLoggedIn

4-3 Create your first static monitor.

4-3-1 Create your own static monitor in your monitor set. The monitor should contain the nodes of CEN that you consider desirable. Please select the MTEs from your context ADM106_##! Save your settings. Name your monitor Static dialog monitor.

4-4 Create your first rule-based monitors.

4-4-1 Create a rule-based monitor in your monitor set. The monitor should contain the same monitoring tree elements (MTEs) as the static monitor (from your context ADM106_##). For the R/3System parameter, choose <CURRENT> in each case. Structure your monitor as you wish using virtual nodes. Save your settings. Name your monitor Rule dialog monitor 1.

4-4-2 Copy your monitor Rule dialog monitor 1 to Rule dialog monitor 2. Change the monitor definition to display the same information for all registered SAP systems. Besides <CURRENT> and <ALL>, is there another way to group SAP systems?

Unit: Creating New Monitors Topic: How to Create a New Monitor Set

4-1 Create a new monitor set.

4-1-1 Start transaction RZ20. Activate the maintenance function by choosing Extras Activate maintenance function.

Choose Monitor(set) Create.

New monitor set is already selected. Press ENTER.

Enter the name ADM106-## for your monitor set. Choose the corresponding attribute settings and press ENTER.

Congratulations! You have created your own monitor set!

4-1-2 Open the monitor set ADM106 and select your monitor ADM106_##. Click the Copy icon. Enter the following data:

Field Name or Data Type	Values
To monitor set	ADM106-##
Monitor	ADM106_##

4-1-3 Choose Enter. Now you have created a copy of the monitor definition in your own monitor set.

4-2 Consider these issues before you create your own monitors.

4-2-1 There is no solution for this exercise. You have to decide on your own. If you are unsure, discuss with your neighbor.

4-2-2 The monitor you copied in exercise 4-1-2 displays all dialog information available in the system. Not all of the information is important to you. You have to decide which information should be transferred into your own monitor definition.

If you are not sure about the meaning of the monitoring attributes, select a monitoring attribute and press F1. If available, look at the long text.

There is no solution for this exercise. You have to decide on your own. If you are unsure, discuss with your neighbor.

4-3 Create your first static monitor.

4-3-1 At the entrance screen of transaction RZ20, activate the maintenance function (exercise 4-1-1). Choose Monitor(set) Create.

Choose New monitor and enter your monitor set ADM106-##. Choose Enter.

You see all SAP systems that are currently registered at CEN. Expand the tree of your CEN system. Expand your monitoring context ADM106_## down to the attribute nodes.

Select those MTEs that should be transferred to your monitor. Choose Save and enter the monitor name Static dialog monitor. Press ENTER.

Open the monitor Static dialog monitor by double-clicking. The monitor shows exactly those MTEs you selected in the definition screen.

4-4 Create your first rule-based monitors.

4-4-1 At the entrance screen of transaction RZ20, activate the maintenance function (exercise 4-1-1). Choose Monitor(set) Create.

Choose New monitor and enter your monitor set ADM106-##. Press ENTER.

Select the white root node <<< New monitor >>>. Choose Create nodes. Select Rule node and choose Continue. Select the rule CCMS_GET_MTE_BY_CLASS and choose Continue.

For the parameter R3System, always enter in this monitor definition <CURRENT>.

The MTE class can be copied easily from your static monitor created in exercise 4-3-1. Open a second mode, start transaction RZ20 and open your monitor Static dialog monitor. Select an attribute node and choose Properties. The MTE class name of this attribute is displayed in the top of the screen under MTE class. Use copy and paste to transfer the MTE class name to the CCMS rule of the second mode. Press ENTER.

Continue in the same manner and transfer all attribute nodes of your static monitor into your rule-based definition.

Your monitor can be structured using virtual nodes. Select the white root node <<< New monitor >>>. Choose Create nodes. Select Virtual node and press ENTER. Enter a meaningful name for your virtual node and press ENTER. Select the new virtual node and choose Create nodes. Now you can select a rule node, which is processed under the virtual node.

Alternatively, you can use the CCMS rule CCMS_DEFINE_R3_SYSTEMS to structure the monitor. At the end, choose Save and enter the monitor name Rule dialog monitor 1.

4-4-2 To copy your monitor, select Rule dialog monitor 1 and choose Copy. Enter your monitor set name ADM106-## and the monitor name Rule dialog monitor 2. Open the monitor by double-clicking. Click the Change monitor icon. Now you see all the rules used in the monitor definition. Double-click on one rule CCMS_GET_MTE_BY_CLASS. Choose Continue. You can change the value of parameter R3System from <CURRENT> to <ALL>. Choose Continue.

Change all other rules of the monitor definition. At the end, choose Save. All SAP systems currently registered at CEN are now processed in your monitor.

If you want to display information that is available only for a subset of the registered systems (database-specific information, for example), you can first create system groups using transaction RZ21. Choose Technical Infrastructure Maintain system groups.

Use the appropriate system groups instead of <ALL> in the rules of your monitors.

n    Within the scope of central monitoring environment, the CCMS alert monitor can display other SAP systems availability. The configuration, which is described in detail in SAP Note 381156, is quite simple, because  there is no need to configure RFC connections from CEN to the remote systems.

n    Availability monitoring features:

Use of a free-standing availability agent. The agent solution makes it possible to verify the availability of several remote systems from a single central system, without running the risk that a system that is down will cause the alert monitor display to "hang".

Configurability: You can choose which systems in your environment should be monitored for availability.

No remote system monitoring entry required. Monitoring for availability is independent of other monitoring in the alert monitor. That is, you do not have to add a remote SAP System to the alert monitor to monitor it for availability

n    The availability check is done by the executable CCMSPING which pings the message servers of the remote systems and transfers the message server information to CEN. CCMSPING can run on any server. CEN must have at least basis release 4.6C

n    The alert monitor does not have to "log on" to a remote system in order to determine its availability. The result is an extremely fast data collection procedure that enables you to monitor the availability of hundreds of systems from a single CCMS alert monitor, if you so desire. The availability monitor also observes a very brief time-out in the event that a system is not reachable.

n       CCMSPING has to be registered to CEN. During installation, CEN system information and a valid user login is requested. The user account is used to insert the necessary registration information and to create a RFC connection from CEN to CCMSPING. The installation is started by CCMSPING -r. Under Windows NT and Windows 2000, CCMSPING has been entered as a service and started automatically at every restart of the server.

n       Enter RSCSM_UPDATE_CSMNSDIC in the Program field of transaction SA38 and execute the program. Accept the file path suggested by the system (c:\winnt\sapmsg.ini or c:\windows\sapmsg.ini) as long as the sapmsg.ini file is not kept in a different directory on your front-end computer. The program reads the sapmsg.ini file on your workstation and uses it to fill the CSMNSDIC table in the SAP System. This table contains information about the message server's host and service names.

n       For all systems you would like to monitor, maintain the following tables using transaction SE16:

CSMNSDIC: Insert "X" in the field AVCheck

CSMSYS: Enter the <SID> (C11, BJA, and so on) of the systems you want to monitor in the SYSGUID and SYSID fields in this table.

n       Enter segment overview in transaction RZ21. Double click the segment of the central instance of CEN. Choose Edit >> Segment >> Reset to 'Warmup' status.

n       You have set up availability monitoring, which will now automatically be continued. To display availability data, expand the SAP CCMS Monitor Templates in transaction RZ20 and open the Availability: Selected Systems monitor.

n       Since SAP Basis 4.6D, the configuration of the availability check has been simplified. The installation of CCMSPING hasn"t changed. After installation of CCMSPING, start transaction RZ21 in CEN and choose Technical Infrastructure Configure availability monitoring. You can directly upload the file sapmsg.ini by clicking Upload service file. Click the system you would like to monitor. You can select

whether only an overall availability node is created

or all instances of an SAP system are monitored individually.

n       Mark the check box Check box to add system for central performance monitoring. If the performance database is activated, the availability data is saved automatically.

n       Enter segment overview in transaction RZ21. Double click the segment of the central instance of CEN. Choose Edit >> Segment >> Reset to 'Warmup' status.

n       You have set up availability monitoring, which will now automatically be continued. To display availability data, expand the SAP CCMS Monitor Templates in transaction RZ20 and open the Availability: Selected Systems monitor.

n       Hint: CEN triggers CCMSPING to ping against a certain port on a certain host. The port is specified by an alias sapms<SID> (e.g. sapmsC11). Ensure that the message server port numbers of the systems that you want to monitor are included in the SERVICES file of the CCMSPING host. The lines have the following structure:
sapms<sid> <Port-No.>/tcp (Example:  sapmsC11 4711/tcp )

n    The availability monitor can be found in transaction RZ20. After configuration and activation, choose the monitor Availability: Selected Systems in the SAP monitor set SAP CCMS Monitor Templates.

n    After activation each remote system has one global availability MTE and, if desired, MTEs for each instance.

n    Since SAP Basis 4.6B it is possible to create a monitor which shows transaction specific response times. For instance, you are able to monitor BBP transactions per client or per system. The setup of the transaction specific monitor is described in SAP note

n    For each transaction which should be monitored you have to create an entry in table ALTRAMONI of each systems (not only in CEN).

n    Maintain table ALTRAMONI using transaction SE16.

n    Enter the transaction that you want to monitor with a meaningful monitoring object name of your choice. SAP recommends that you enter the same name for the MTE class and the monitoring object. This makes it easy for you to select by client or transaction in the monitor definition. Specify client or * for all clients. Enter "<CURRENT>" in the field Server ID. Save the entry.

n    Call transaction RZ20. You can find the Transaction-Specific Dialog Monitor in the SAP monitor set SAP CCMS Monitors for Optional Components (in case of an SAP Basis 4.6B, the monitor has to be created manually). After five minutes the first MTEs will appear.

n    You should activate the transaction specific monitor in the remote systems. In CEN you can build a central monitor by using the rule GET_MTE_BY_CLASS with MTE class ContextR3DialogFocus.

n    In SAP monitoring set SAP CCMS Monitors for Optional Components you can find an ALE monitor template ALE/EDI. This monitor shows outbound and inbound IDocs, change pointers and the transactional RFC queue.

n    The ALE monitor shows ALE information about all IDocs and as an example for MATMAS IDocs.

n    For the ALE monitor the data collection runs in batch mode. Prerequisite is that the CCMS alert monitor batch tool dispatcher is activated otherwise all MTEs of the ALE monitor are white (inactive/deactivated). You can activate batch tool dispatching starting transaction RZ21. Choose Technical infrastructure Method execution Activate background dispatching

n    If you like to monitor individual IDoc types, you can create your own ALE monitoring objects. Enter transaction BDMO and click at Create/active monitoring objects. Click New entries. You can enter the monitoring object name. Mark Active and save your settings. Now you have to define which IDoc type stand behind your monitoring object.

n    Go back to the entrance screen of BDMO. Select your new monitoring object and click Change monitoring object.  Select the IDoc type you want to monitor for outbound/inbound direction. You can also specify the wait time for status changes and the partner system. Save your settings.

n    On the entrance screen of BDMO, choose Monitoring object Start all. A new monitoring object is created which can be used in rule based monitors.

n    It is easy to set up a rule based monitor for your ALE monitoring object. Select the rule CCMS_GET_MTE_BY_CLASS with parameter ALEPfGr: <object name> for the MTEClass. As a result only information concerning your IDoc selection is displayed.

n    You should create ALE monitors in all systems which are involved in ALE. Afterwards you can create a central ALE monitor in CEN showing all ALE information in one screen using the rule CCMS_GET_MTE_BY_CLASS. For the parameters R3System and MTEClass, choose a proper combination for each remote system.

n    Communication between the CRM server and the system landscape is mainly done by tRFC and qRFC. It is crucial to monitor the communication status regularly.

n    In transaction RZ20, choose the monitor Communications, which is located in the monitor set SAP CCMS Monitor templates. This monitor shows basic tRFC information. The information can be expanded by importing a basis support package. The support package is available since SAP Basis 4.5B. Further details are described in SAP Note 441269 and 437187.

n    After installing the support package in an CRM system, the following information is shown:

Status of the database table ARFCSSTATE, which stores information of outgoing tRFC calls.

Status of the database table ARFCRSTATE, which stores information of incoming tRFC and qRFC calls.

Status of outbound qRFC queues, which are grouped by queue name and client.

Status of inbound qRFC queues, which are grouped by queue name and client.

Status of the outbound and inbound queue scheduler.

n    The queue information is refreshed every 15 minutes. Instead of reporting the same error message several times, a particular error message is reported only once per queue, until an administrator completes the message.

n    The data shown in Communications can be customized. You can choose, which queues are grouped together, monitored and if the number of queue entries and the queue age (age of the oldest entry of the queue) is displayed.

n    QRFC monitoring might be delivered with SAP standard customizing, which is automatically active after installation of the appropriate support package. Nevertheless, you can copy the SAP default settings and adapt them to your needs. To change qRFC monitoring customizing, start transaction RZ21 and choose Technical Infrastructure Configure qRFC Monitoring

n    The SAP standard view cluster maintenance shows on the first level the owner of the qRFC customizing package. You can copy the SAP customizing, change the copied version and set the Active flag to your customizing.

n    The second level shows the queue groups of the package. A queue group groups qRFC queues of your choice. Please enter a meaningful name to the queue group, because the queue group name is displayed in the CCMS alert monitor under Inbound or Outbound Queues.

n    The default settings of a queue group can be changed. For instance, analysis or auto-reaction methods can be assigned directly to the corresponding MTEs of the queue group. Furthermore, the monitoring data can be expanded by assigning an exit function module. SAP delivers the two function modules SALK_CRM_QRFC_QUEUE_ENTRIES (number of queue entries) and SALK_CRM_QUEUE_AGE (age of the oldest entry of the queue). These function modules could have high resource consumption, if the underlying database tables are extremely large.

n    The queues assigned to a certain queue group are displayed on the third level. The queues can be named by an asterisk at the end of the queue name. The monitoring of queues could also be switched off. The level of alerts propagated in the CCMS monitoring architecture can be changed on the forth level.

n    SAPOSCOL is a stand alone program available for almost all operating system platforms, which determines operating system data like CPU idle/used,  paging rates or filesystem filling level and stores this data in a shared memory segment of its host. SAPOSCOL runs only once per host (normally as a service for NT). The data of SAPOSCOL can be analyzed by using the local SAP system or transferred to CEN by usage of the CCMS agent SAPCCMSR. In CEN, the data can be analyzed in transaction OS07 or RZ20.

n    SAP Note 451166 describes, how to configure SAPOSCOL to monitor the existence, CPU and memory consumption of single processes. For example, the existence of the process java.exe or the TNS listener of a stand alone oracle database located on an non-SAP host could be checked. Doing so, SAPOSCOL checks a new configuration file dev_proc, where you can specify the process name and the operating system user of the process. The information is transferred via the agent and can be analyzed in CEN using transaction RZ20.

n    All agents have a logfile adapter. They can analyze logfiles to find specific strings and to transfer those logfile rows to CEN. For instance, you can scan the logfile of an Oracle database for ORA-600 errors. You can define, if the matching lines are transferred as errors or as "normal messages" (green lines).

n    Detailed information about installation of agents can be found in SAP Note 209834.

n    SAPOSCOL information transferred by SAPCCMSR can be displayed and analyzed centrally in CEN using transaction RZ20. Open the monitor System / All Monitoring Segments / All Monitoring Contexts of the monitor collection SAP CCMS Technical Expert Monitors and look for information related to the SAPCCMSR host.

n    Detailed information is shown for:

Filesystems: Free space / Percentage used

CPU: Utilization

Paging: Page in / Page out

OS-Collector: SAPOSCOL running?

Network: time for naming resolution...

If the logfile adapter is configured, the matching lines of the monitored logfiles are shown. In the example above, the logfile dev_rout is analyzed for search pattern failed.

Process monitoring: number of processes, CPU and memory consumption.

n    CCMSR is especially designed for components without SAP instances on it. You can use it for various components of the internet middleware.

n    ITS is the converter process, which enables Web access to SAP systems. The Agate of ITS can be monitored centrally by CEN while using the SAPCCMSR agent. On the one hand, SAPCCMSR can transfer operating system information delivered by SAPOSCOL located on ITS host. On the other hand, a shared library can be linked to SAPCCMSR. This library connects to the shared memory segment of the Agate to pull monitoring information. The monitoring data is transferred to CEN by the agent while using RFC. For ITS configuration, see SAP Note 418285.

n    Performance problems in the ITS are reported in the ITS log files. Hardware bottlenecks on the computer where the ITS runs are reported by the tool SAPOSCOL.

n    SAP note 452797 describes two tools which expand the ITS monitor in transaction RZ20. These generic tools are able to:

start the browser with a well defined URL: this tool is used to start the ITS administration tool or a WebGUI directly out of the CCMS alert monitor.

display the content of files located on the ITS host: this tool is used to display several service files. The file information is transferred by the SAPCCMSR agent.

n    SAP note 418285 describes in detail, how to set up ITS monitoring.

n    After installation of the SAPCCMSR agent, a shared library has to be copied to the ITS program directory. The path of the library has to be inserted in the agents configuration file sapccmsr.ini.

n    The registry key PerfMonitoring of of each virtual ITS instance has to be switched to 1. The server must be restarted after the PATH variable is expanded to the ITS program directory.

n    In CEN, create a new rule based monitor. The complete ITS information is shown by the MTE classes ITSRootContext and ITSselfH.

n    This slide shows some parts of the ITS information delivered by SAPCCMSR. Besides availability information, details about processes and threads are shown.

n    The layout of the information presented in transaction RZ20 is similar to the ITS administration tool. In case of a problem, this tool can be directly started out of the RZ20 monitor.

n    The Business Connector can be monitored centrally by installing an Add-On package. A Jmon API included in the package enables Business Connector to read from and write to the shared memory of the SAPCCMSR agent. SAPCCMSR transfers the monitoring data to CEN.

n    The setup of central monitoring the Business Connector is quite simple: after installing the package, the administrator have to customize which components of the Business Connector should be monitored using the common web based administration tool. The setup of the Jmon-API, the start of the corresponding data suppliers and the installation of the SAPCCMSR agent will be done automatically.

n    In CEN, a new monitor has to be set up to display the monitoring information of Business Connector. At operating system level, the existence of the Java VM is checked (process monitoring done by SAPOsCol). Besides detailed performance information of Business Connector, the connection state to the SAP systems and the listeners configured are checked. Furthermore, error messages are displayed.

n    The Add-On package is available on the SAP Service Marketplace: https://service.sap.com/connectors.
Enter the Business Connector part and check the download area.

n    In the future, the Internet Pricing Configurator (IPC) and the Index Management Service (IMS) can be monitored centrally in CEN while using the SAPCCMSR agent. On the one hand, SAPCCMSR can transfer operating system information delivered by SAPOSCOL. On the other hand, a shared library can be linked to SAPCCMSR. These libraries connect to the IPC and the IMS to pull monitoring information. The monitoring data is transferred to CEN by the agent while using RFC. Up to now, you can check the IPC existence by activating process monitoring via SAPOSCOL.

n    As an outlook, a heartbeat of both programs is shown.

n    Information about central IPC monitoring will be available soon in SAP note 502461 and information about IMS in SAP note 502463.

n    SAP J2EE engine (formerly known as InQMy) can be monitored centrally by using the SAPCCMSR agent. A Jmon API enables the SAP J2EE server (clustered version of release at least 4.3) to write to the shared memory of the SAPCCMSR agent. SAPCCMSR transfers the monitoring data to CEN.

n    By default, SAP J2EE engine does not report performance information to a central monitoring system. Under Cluster Server Services monitor, switch daemon.CCMS.mode to "On" to activate performance reporting.

n    After activation, almost all information available in the stand alone administration tool of the SAP J2EE server is passed to the central monitoring system.

n    For more information about SAP J2EE engine monitoring, see the SAP J2EE engine Administration Manual. Please check also SAP note 498179 for further details.

n    Further information about central monitoring of mySAP components can be found in composite SAP note 420213 and all related SAP notes.

Monitoring mySAP.com Components Exercises

	Unit: Monitoring mySAP.com Components Topic: Configuring Monitoring
	At the conclusion of this exercise, you will be able to: Perform advanced customizing activities for central monitoring
	If you are interested in advanced system monitoring such as availability or transaction-specific monitoring, you have to do special customizing and monitoring setup.

5-1 Configure an availability check.

5-1-1 From CEN, activate the availability check for an additional system of your choice. Wait a few minutes and then check if the system displays your monitored system in the standard SAP availability monitor.

5-1-2 Create a new monitor in your monitor set to show the complete availability information.

5-1-3 Which other availability information (if activated) could be included in your availability monitor?

5-2 Configure transaction-specific monitoring.

5-2-1 Log on to the child system. On the child system, activate the transaction-specific monitor for a transaction of your choice. Call the transaction that you have chosen to monitor a few times and then open the SAP standard monitor for transaction-specific monitoring. Is it already displaying values?

5-2-2 Now create a monitor in CEN that displays the transaction-specific values of the remote systems.

5-3 Optional: Configure monitors for your daily work.

5-3-1 Configure the general system monitor
Log on to CEN. Create a rule-based monitor that displays the most important information about the general status of your system landscape using 10 to 20 MTEs.

5-3-2 Configure the performance monitor
Log on to CEN. Create a rule-based monitor that displays the most important information about the performance status of your system landscape using 10 to 20 MTEs.

Monitoring mySAP.com Components Solutions

Unit: Monitoring mySAP.com Components Topic: Configuring Monitoring

5-1 Configure an availability check.

5-1-1 CCMSPING was already configured by the instructor. Only some customizing is necessary using transaction RZ21. Choose Technical Infrastructure Configure availability monitoring.

Double-click one system in the system list Non-monitored systems. The system information is displayed on the right of the screen.

Select Monitor System, and Monitor Selected and All New Application Servers. Select the check box under Monitor for each application server.

Choose Save. From now on, the availability of your system is checked regularly.

Wait a few minutes and open the SAP monitor Availability: Selected Systems of SAP monitor set SAP CCMS Monitor Templates. This monitor shows information about all monitored SAP systems.

Not all systems can be monitored because of network security. Ask your instructor which system can be reached from CEN.

5-1-2 You can either copy the monitor Availability: Selected Systems into your monitor set or create a new rule-based monitor using the rule CCMS_GET_MTE_BY_CLASS with the parameters:

Field Name or Data Type	Values
R3System	<SID> of CEN
MTEClass	Availability_Context

5-1-3 If other components are monitored, you could include availability information for:
ITS
Business Connector
SAP J2EE Server
Single operating system processes

5-2 Configure transaction-specific monitoring.

5-2-1 Transaction-specific monitoring has to be activated in the system, where the transaction is processed.

Log on to the child system.

Start transaction SE16 and enter ALTRAMONI as table name. Choose Create entries. Enter the following data:

Field Name or Data Type	Values
MON Client	* or a specific client
TCODE	The transaction code of the business transaction you want to monitor
MO NAME	Meaningful name for the newly created monitoring object
MTECLASS	SAP recommends to enter the same value for the newly created MTE class as for MO NAME
SERVER ID	<CURRENT>

Choose Save. Open the monitor Transaction-Specific Dialog Monitor of the SAP monitor set SAP CCMS Monitors for Optional Components. This monitor presents transaction-specific monitoring data of the local SAP system. Please check if there are already some monitoring attributes displaying performance data of your business transaction.

5-2-2 The aim of this exercise is to set up central monitoring for monitoring data, which is available only in the component systems. With transaction-specific monitoring, the business transactions often run in the component systems only. The corresponding monitoring data is collected in the component systems and displayed centrally.

Log on to CEN.

At the entrance screen of transaction RZ20, activate the maintenance function (exercise 4-1-1). Choose Monitor(set) Create.

Choose New monitor and enter your monitor set ADM106-##. Press ENTER.

Select the white root node <<< New monitor >>>. Choose Create nodes. Select Rule node and choose Continue. Select the rule CCMS_GET_MTE_BY_CLASS and choose Continue.

For the parameter R3System, enter the child system.

For the parameter MTEClass, enter either ContextR3DialogFocus to display all monitored business transactions or the name of the MTEClass, entered in exercise 5-2-1. Press ENTER.

Ignore a system message telling you that a special MTE class is unknown in CEN.

Choose Save and enter a meaningful name for your monitor.

CEN displays only monitoring data delivered by the component systems. Make use of the advantage to display component-specific data centrally. In this example, you can easily detect performance bottlenecks of your crucial business transactions centrally!

5-3 Optional: Configure monitors for your daily work.

5-3-1 For this exercise, there is no general solution. You decide which information about the system status is important.

As an example, a monitor for system overview might contain information about:
- the last database backup
- the status of the update service and information about aborted updates
- aborted ABAP programs
- aborted batch jobs
- syslog information
Please feel free to include other monitoring information.

5-3-2 For this exercise, there is no general solution. You decide which information about the system status is important.

As an example, a monitor for a performance overview of an SAP system might contain the following:
- standard dialog information: response time and its main parts
- transaction-specific monitoring information
- users logged in
- swap of PXA buffer
- use of roll, page, extended and heap memory
- CPU usage
- paging rates
- single process monitoring
- expensive selects

Please feel free to include other monitoring information.

n    Property variants are containers in which CCMS Alert Monitor settings, such as threshold values, can be stored.

n    You can create as many property variants as you like and store CCMS Alert Monitor settings in them. Exactly one property variant with your settings is active at any time.

n    Property variants have three advantages:

You can manually switch from one property variant to another for test purposes or to adjust the monitor to a special situation. This means that all monitor settings are automatically changed in accordance with the current property variant.

You can connect a property variant to an operation mode. In this way, the threshold value for the dialog response time is set to 1s during the day, while the threshold value is automatically increased to 10s after the switch to night operation, as there is usually no dialog processing during the night.

You can transport the contents of property variants to other SAP systems using the transport system. For example, if you create a variant for production systems in the central monitoring system, and maintain the threshold values that are to apply for production systems there, you can then transport the variant to all production systems and activate the threshold values there.

n    Property variants have been included into the CCMS Monitoring Architecture since SAP Basis 4.0. Nevertheless, the SAP systems using SAP Basis 4.0 and 4.5 have offered only limited functions of property variants.

n    A property variant is a collection of settings for one or more MTEs in the Alert Monitor. The monitor can be directly adapted to a new SAP System situation by switching the property variant manually.

n    The settings for the Alert Monitor might be set differently between day and night operating system mode. Since SAP Basis 4.5, a property variant can be linked to a specific operation mode.

n    The settings of the Alert Monitor are linked to the SAP system. Remote systems can be monitored centrally, but the Customizing of the monitor cannot be set centrally. However, you can use property variants to define thresholds and methods, for example, in a central system once and distribute the complete settings to the remote systems. After the settings are activated in the remote systems, they are also visible in the central monitoring system.

n    Once there is a new property variant defined and set up, it is possible to transport its content.

n    You can create several property variants. It may be useful to create and maintain variants per system type (DEV, QAS, PRD, R/3, BW, APO, CRM.), operation modes or variants per database or basis release type.

n    The road map of working with property variants is as follows:

Create appropriate property variants in CEN.

Fill the property variants with appropriate thresholds and method assignment for MTEs located in CEN. Do not maintain thresholds and method assignment for all MTEs of the CCMS monitoring architecture but for those MTEs located in your CCMS monitors (transaction RZ20).

Create a change request in CEN, which stores the data of property variants. If necessary, store additional customizing (method definitions, .) in the change request.

Release the change request and transport it to the remote systems. After import, the variants are available in the remote systems.

n    To create your own property variant, call Transaction RZ21 and choose Properties Variants Create. Enter a name and description for the variant.

n    A property variant  hierarchy exists in the monitoring architecture which is described on the next slide.

n    In the field owner, you can also specify the name of a manufacturer of a system management program that provides an agent for logging on to the SAP System via the XMI interface and making use of the CCMS system management interfaces. This variant is used if Customizing changes are made by an agent outside of the SAP System.

n    There is a property variant hierarchy in the monitoring architecture, with the values contained in SAP-DEFAULT at the bottom level.

n    The property variant SAP-DEFAULT includes SAP standard threshold settings and method assignments. This variant cannot be changed or deleted. However, you can copy either the whole variant or specific values in it to a separate property variant, and then make changes to this copy. SAP-DEFAULT can be used as a backup if you accidentally change the values provided by SAP in the SAP System

n    From SAP Basis 4.6, you create a monitoring property variant, and specify a "parent" property variant, whose values should be used if the customer-defined property variant does not contain values for an MTE class. If, in turn, this property variant does not contain values for that MTE class, then the system uses the values contained in the its parent variant and so on. The last variant in the line is SAP-DEFAULT by default.

n    SAP delivers two property variants:

SAP-DEFAULT: non-changeable

*: Changeable. The parent variant of "*" is SAP-DEFAULT. Store your default settings in "*".

n    When you change properties of an MTE from the monitor screen, you change the values for the active variant.Therefore, the easiest way to customize your monitors is to change the MTE properties with the appropriate variant active.

n    To activate a property variant, from the main screen of transaction RZ21, choose Properties Variants Activate. In the pop-up window, enter the name of the variant you want to activate and click the green check to continue. Your variant now shows as the active variant.

n    All settings of your property variant are now active with respect to the local system. After customizing is finished, the automatic switch of the property variants according to the operation modes of the SAP systems has to be configured in each SAP system.

n    Monitoring property variants can be created and customized in CEN and transported through the system landscape. To transport a property variant, start transaction RZ21; in the Properties frame, select the radio button for property variants, and click on the Display Overview button; alternately, select Properties Variants Overview of variants from the menu.

n    In the next screen, select Variant Transport from the menu. In the text box enter or select the variant you want to transport, and select the appropriate options from the checkboxes. Click the green check mark to continue and you will be prompted for a change request; enter or select a valid change request, or create a new one. Your variant will be saved to the change request, which can be released from the transport organizer and imported into the downstream systems.

n    Monitoring property variants allow you to tailor the customizing of your monitoring environment to the specific needs of your systems and their roles in the landscape. They are easy to set up and maintain, easy to work with, and easy to transport.

n    Although the connection to the transport system has been established since SAP Basis 4.5, it is possible to import a property variant into an SAP 4.0 system. Please refer to SAP note 492442. Keep in mind, that log attributes have been introduced with SAP Basis 4.5, so do not transport log attribute settings into an SAP 4.0 system.

Keep in mind that the hierarchy of property variants has been introduced with SAP Basis 4.6.

n    You can link property variants to operation modes of your SAP System. To define or change an operation mode, choose Tools CCMS Configuration Operation modes / instances (or call Transaction RZ04). Then choose Create or Change Operation mode. Under Monitoring property variant, you can link a property variant directly to the operation mode. During an operation mode switch, the variant and its settings are activated.

n    Note: The operation mode switch is done by each SAP system itself and is not controlled globally. Also the property variant connected to an operation mode has to be available locally in the system.

Property Variants Exercises

	Unit: Property Variants Topic: Configuring Property Variants
	At the conclusion of this exercise, you will be able to: Deal with property variants
	Property variants are useful for transporting monitor settings to other SAP systems and for changing thresholds and method assignments with respect to operational modes.

6-1 Configure property variants.

6-1-1 Which property variant is currently activated in CEN?

6-1-2 Create your own property variant ADM106-##. The parent variant of ADM106-## should be the * variant.

6-1-3 Where would you activate the variant? Do not activate your property variant because only one variant (the instructor's variant) can be activated at any one time.

6-1-4 What would happen if you activate your (empty) variant ADM106-##? Which property variant's settings would be valid effectively

Property Variants Solutions

Unit: Property Variants Topic: Configuring Property Variants

6-1 Configure property variants.

6-1-1 Start transaction RZ21 in CEN. The active property variant is displayed in the Variants currently active field.

There can be only one property variant active per SAP system!

6-1-2 At the entrance screen of transaction RZ21, choose Properties Variants Create.

Enter the property variant name ADM106-##, a meaningful description, and enter * as the parent variant. Choose Save.

6-1-3 A property variant can be activated in transaction RZ21. Choose Properties Variants Activate.

Please do not activate your property variant because only the instructor's variant should be activated during the training.

6-1-4 Immediately after creation, your property variant is completely empty. If you activate your variant, you activate the * variant implicitly because this is the parent of an empty variant.

n    To enable full functionality of the CCMS alert monitoring infrastructure (for example mail notification in case of an alert), you should check and adapt the SAP default threshold settings to your needs. Instead of checking all monitoring attributes, you should first check the attributes of your monitors.

n    Threshold customizing is easy to perform in the CCMS.

For each performance monitoring attribute node comparison values (threshold values) are defined. These values trigger an alert, when they are exceeded.

For log attributes you can define a threshold for triggering an alert. Moreover, you can redefine SAP default settings using log attribute filters.

For single message attributes you can more or less only define, if an alert is raised or not.

n    Monitoring attributes with the same physical or logical content can be grouped together in attribute groups. The threshold values set can be either specific to a monitoring attribute or valid for all the nodes in an attribute group. This grouping of monitoring attributes reduces the amount of work for Customizing.

n    In this example, the attribute group CPU_Utilization is displayed, which includes one attribute per SAP instance.

n    SAP's default threshold customizing is done via attribute groups. SAP strongly recommends to use the attribute group mechanism, because the settings can be transported into other SAP systems using SAP's transport mechanism.

n    The most important information stored in an attribute group is the threshold information. In case of a performance attribute group, four threshold values must be set, when switching between the following statuses:

GREEN to YELLOW

YELLOW to RED

RED back to YELLOW

YELLOW back to GREEN

n    Ensure that the thresholds, for example from GREEN to YELLOW are set differently than the thresholds from YELLOW back to GREEN, otherwise the monitoring attributes would switch back and fourth to a state of alarm when their values approximate the threshold values.

n    Moreover, the preparation of values (averaging) and the alert text is stored in an attribute group.

n    In some cases, it may be necessary to define your own Customizing groups. For example, the Customizing group CG_FilesystemPrerentageUsed collects the MTEs that show in percent how full the file system is. For dedicated file systems, such as the database log file system, a different threshold value might be set. It is easy to set the special thresholds directly at the corresponding MTE. If more than a few MTEs are affected, it could be helpful to define a new Customizing group covering the special situation.

n    To create a new Customizing group, choose Properties Create group/class and select the appropriate group type.

n    Specify all necessary entries. The easiest way might be to copy the entries from the old attribute group.

n    For performance attribute groups, ensure that the display unit of the group is set correctly (according to the unit of the MTE attributes), otherwise the new Customizing group cannot be assigned.

n    Customizing groups can be displayed or changed using Transaction RZ21. To display a list of all Customizing groups, select Properties assigned to Customizing groups and choose Display overview. Select a Customizing group, and choose Edit data.

n    Several versions can exist for each Customizing group. The version is related to a properties variant. This example shows the Customizing group R3BufferHitRatio of property variant Productive. Click Edit Copy values to variant.

n    In the group box Threshold values, you can set the thresholds for raising a YELLOW or RED alert. These thresholds are valid for all MTE members of this Customizing group, unless that the thresholds are directly assigned to an MTE.

n    Under Alert text, you can set the standard error message.

n    If you like to copy several attribute groups to another variant at once, mark the check boxes and choose List Selected entries to variant

n    Thresholds can be adapted using the CCMS alert monitor RZ20. You should check all attributes displayed in your monitors.

n    Hint: Only attribute nodes have threshold settings. There is no need to check inner nodes of the tree.

n    Open one of your monitors, select an attribute node, and click Properties.

n    The PerformanceAttribute tab is automatically selected. If your MTE is assigned to an attribute group (default setting), the name of the attribute group is displayed under Performance properties assigned from group.

n    To exclude an MTE from a group, choose Edit Properties Use for individual MTE, and click Save. Afterwards, you can define individual threshold for this MTE.

n    To include an MTE into a group, choose Edit Properties Use from MTEclass/group. The group settings will be valid for this MTE afterwards.

n    Click Display <-> Change. If the MTE is assigned to an attribute group, you can change the thresholds for the group now. The group values are stored with resprect to the active properties variant. Click Save.

n    Remember: Local threshold customizing can be stored and transported using property variants. It is important that you first think about property variants and do threshold and method customizing afterwards. Create the property variants using transaction RZ21, activate the variants one by one, and fill them by using transaction RZ20.

n    Often, customers have problems to decide, which tresholds are appropriate for their environment. Note: SAP can only deliver standard values. If they are to low, alerts are raised too often, and noone will take care of the alerts. If they are too high, there alerts will not be triggered.

n    Adapt the thresholds to your environment. If you are looking for performance thresholds, use SAP performance transactions like ST03N, ST06. to analyze normal performance behavior of a standard work week. How do you work with the administrative SAP transactions? For instance, which Syslog messages do you process? You can configure the log settings accordingly. Look for additional information for instance with respect to performance counters. A good example is "SAP Performance Optimization Guide" by Thomas Schneider.

n    It is important to check all attribute settings of your monitors. Alerts raised uncontrolled for MTEs that are not included in your monitors are non-relevant. They do not affect your effective work with your monitors and they are completed automatically.

Customizing Thresholds Exercises

	Unit: Customizing Thresholds Topic: Configuring Thresholds
	At the conclusion of this exercise, you will be able to: Check and adapt thresholds to your needs
	The CCMS alert monitor is delivered with SAP default threshold settings. Depending on thresholds, alerts are raised. You should check and, if necessary, adapt the thresholds to your needs.

7-1 Configure threshold settings.

7-1-1 Open your monitor Rule dialog monitor 1. Check some of the monitoring attributes. Check in detail the settings for Comparison Value, and Threshold values. Do you agree with the actual settings?

The settings of your monitor are not SAP default settings!

7-1-2 Adapt the thresholds using attribute groups according to the table in exercise 4-2-2. Your values are stored in the instructor's variant.

7-1-3 In transaction RZ21, using attribute groups, maintain the threshold values that you recommended for the appropriate attribute groups for your variant.

7-1-4 Open your monitor Rule dialog monitor 2. What are the threshold values for the MTEs from the child system? Why? Maintain a few threshold values for the child system. Is there another way to deliver threshold values to the child system?

7-1-5 Optional: Open your monitors created in exercises 5-3-1 and 5-3-2. Check the threshold settings of some monitoring attributes. What do you think of the SAP default settings? Are these settings suitable? Please do not change the SAP default values.

Customizing Thresholds Solutions

Unit: Customizing Thresholds Topic: Configuring Thresholds

7-1 Configure threshold settings.

7-1-1 Start transaction RZ20 in CEN. Double-click the monitor Rule dialog monitor 1 of your monitor set ADM106-## to open it. Select one monitoring attribute (for example, ResponseTime) and choose Properties. Take a closer look at the settings: they are completely wrong!

Example: ResponseTime

Comparison value: Last reported value. For a performance counter such as response time, it does not make sense to report the last value. Choose a smoothing (last 15 minutes is sufficient) instead.

Threshold values: The overall response time on average should be around 1000 to 2000ms (milliseconds). Adapt the values accordingly. Select exceeds the threshold value.

7-1-2 Activate maintenance function. Open your monitor, select a monitoring attribute and choose Properties. Choose Display <-> Change and maintain the thresholds. Choose Save.

Maintain thresholds out of transaction RZ20. Store the settings in the corresponding attribute groups with respect to the property variant, which is currently set to active.

7-1-3 Using transaction RZ21, you can customize thresholds and store them in a property variant of your choice.

Open transaction RZ21, select Properties assigned to customizing groups and choose Display overview. Select all attribute groups customized in exercise 7-1-2 with respect to the instructor's property variant. Choose List Selected entries to variant. Select your property variant ADM106-## and press ENTER.

You have copied all selected entries into your property variant. To check, select one of the copied entries and choose Edit data.

	If you want to copy only a few attribute groups into a property variant, select the attribute group, select Edit data and choose Edit Copy values to variant. Now you can change the variant name. Choose Save. You can change the settings afterwards.
	Changing thresholds using RZ21 implies that you know the name of the attribute groups you are going to change. It is useful to work with two modes in parallel: one for working with transaction RZ21 and a second one for opening a monitor of transaction RZ20 and for copying the attribute group name.

7-1-4 Double-click your monitor Rule dialog monitor 2 to open it. Select a monitoring attribute of the child system and choose Properties. As you can see in the status bar of SAPGUI, you jump directly into the child system. The threshold values of the child system are unchanged. Thresholds belong to a single SAP system, and you have done threshold customizing only for CEN so far.

Choose Display <-> Change. You can directly change thresholds of the child system using transaction RZ20.
Instead of adapting thresholds manually for each system, you can create a change request from your property variant and transport the request using the SAP transport mechanism TMS.

7-1-5 Open your monitors created in exercise 5-3-1 and 5-3-2. Check the threshold settings for the monitoring attributes. There is no general recommendation for how to set the thresholds. In your office, you should adapt the thresholds according to your system performance situation. If you are unsure, please don't change the SAP default values.

n    A method is a synonym for a program, a function module, a transaction, or a URL. Methods have to be defined in transaction RZ21.

n    There are four types of methods that can be assigned to monitoring attributes:

Data collection mehod: reports data to the corresponding monitoring attribute

Auto-reaction method: is executed automatically, if the threshold condition of the monitoring attribute is met (yellow or red alert)

Analysis method: guides the administrator into a certain action to analyze the alert situation

n    To check, which method is assigned to an MTE, open the CCMS alert monitor (transaction RZ20), choose the MTE, and click Properties. Under the tab Methods, you can see the methods assinged to the MTE.

n    Example: The data collection method for the monitoring attribute UsersLoggedIn is CCMS_User_Collect. This alias stands for the report RSDSUSER, which determine, how many users are connected to a certain SAP instance. There is no auto-reaction method assigned to this MTE. The corresponding analysis method is called CCMS_User_Analyse. This alias stands for the report RSUSR000 (technically the transaction AL08).

n    A data collection method is responsible for delivering monitoring data for its component. The data collection method checks its component regularily and stores the monitoring information in the local shared memory (monitoring segment). The CCMS alert monitor displays the monitoring data, gathered by the data collection methods.

n    There are active and passive data collection methods:

Active data collection methods run independently of the CCMS alert monitoring architecture. They start automatically and cannot be influenced by the user. For instance, the SAP work process gathers monitoring data actively.

Passive data collection methods are started periodically by the CCMS alert monitoring infrastructure. They can be influenced by the user (e.g. collection frequency).

n    There are two modes for starting passive data collection methods:

The data collection method is started in dialog mode (in a dialog work process) by the report SAPMSSY8. SAPMSSY8 is triggered by the report SAPMSSY6 (Auto ABAP), which runs every 5 minutes by default on each SAP instance under the hard coded SAP user SAPSYS. Therefore in dialog mode, data collection methods can't be triggered more often than every 5 minutes. They may be limited with respect to SAP authorizations. For instance, SAPSYS is not allowed to process an RFC call.

The data collection method is started in batch mode (in an batch work process) by the batch job SAP_CCMS_MONI_BATCH_DP. SAP_CCMS_MONI_BATCH_DP is triggered periodically every hour and has to run under an SAP administrator account. Therefore in batch mode, data collection methods can"t be triggered more often than every hour (long running data collectors). They may be limited with respect to the user context of SAP_CCMS_MONI_BATCH_DP.

n    Passive data collection methods, auto-reactions and analysis methods have to be defined in transaction RZ21. Select Method definitions and click Display overview.

n    Select a method definition. On the tab Control and in case of a data collection method, either periodically in dialog process or periodically in background process has to be selected.

n    Data collection methods can be triggered directly during instance startup (startup methods). These methods often allocate the memory and create the monitoring trees. If a startup method fails, often a complete monitoring tree is missing and the corresponding data collection methods never start. The problem can only be solved by switching the corresponding segment into Warmup status or by restarting the SAP instance.

n    The monitor CCMS Selfmonitoring of the SAP monitor set SAP CCMS Technical Expert Monitor shows detailed information of data collection methods. You can select long running tasks (once per system) or short running tasks (per instance).

Select Details of the monitoring attribute Messages. You can check, which data collection method has been triggered.

If a startup method fails, an additional MTE STARTUPTOOL_XXXXX is created.

Check the alerts of these two subtrees to get more information.

n    The batch job SAP_CCMS_MONI_BATCH_DP has to be scheduled and released once. It is not scheduled by default. If this batch job is not scheduled, all passive data suppliers defined to run in batch mode do not start.

n    Enter transaction RZ21 and choose Technical infrastructure Method execution Activate background dispatching. The batch job is planned periodically every hour under your SAP user context.

n    The batch job definition can be checked using transaction SM37.

n    The collecion frequency of passive data collection methods can be adjusted. Under Properties of the selected MTE, choose Methods. Look at Start the data collection method every XXX seconds.

n    Hint: For data collection methods running in dialog, it does not makes sense to select a collection time smaller than 300s. For data collection methods running in batch, the smallest time interval is 1 hour (3600s).

n    Hint: The entry <NO_METHOD> has a double meaning for data collection methods:

There is no method assigned. After some time, the MTE will turn to white (MTE is inactive).

There is an active data collection method assigned, which can't be influenced.

n    SAP delivers data collection methods preconfigured and with optimal default settings. Improper settings of data callection methods could lead to substancial problems of your monitoring environment.

n    If you would like to monitor components, not delivered by SAP, you can program your own data suppliers. A detailed description, how to write an ABAP data supplier can be found in SAP Service Marketplace.

n    Active data suppliers run independently from the CCMS monitoring architecture. They cannot be started manually.

n    Passive data collection methods are started periodically by the CCMS monitoring infrastructure. Nevertheless, you can start a passive data collection method manually:

Open a monitor in transaction RZ20. Activate the maintenance function. Select the monitoring attribute and choose Edit Nodes (MTE) Start methods Start data collection method. The corresponding passive data collection method is started directly.

n    Tip: Pressing Refresh does not start data collection methods. A refresh only displays data delivered by the data collection methods. If there is no new data processed, the old data is displayed.

n    The automatic run of data collection methods costs system performance (overall normally under 10%). In case of significant performance problems, data collection methods can be disabled. Choose the method definition screen of transaction RZ21. Under Release, uncheck the box for data collection method and save your changes.

n    Result: all MTEs delivered with data by this method will become white (inactive) after a while. The data collection method won't be started automatically again.

n    Tip: before deactivating a data collection method, check in the Where-used-list, which MTEs are affected. On the method definition screen, click the Where-used-list icon.

n    If a threshold condition is met, an auto-reaction can be triggered automatically and without user interaction.

n    Auto-reactions are triggered by the the data colletion dispatcher. This means, that they either run in dialog under the user context of SAPSYS or in batch mode under the user, who has activated background dispatching. They are triggered at most 5 minutes (dialog mode) or 1 hour (batch mode) after the alert condition has been met.

n    An auto-reacion has to run without user interaction. This means, only reports without selection screen or function modules are allowed.

n    Note: auto-reactions are triggered on the SAP instance where the alert occurs. This might be important for raising local operating system scripts.

n    Example: You have configured the availability check with CCMSPING and your SAP systems are checked regularily. What happens, when one system breaks down?

n    CCMSPING reports no-availability to the CEN. Depending on the threshold definition, an alert is raised.

n    An auto-reaction is configured for the corresponding MTE. The auto-reaction creates an SAP office document, which describes the corresponding MTE and the alert text. The document is stored in SAPConnect, which acts as a link between the SAP system and an external mail server.

n    SAPConnect transfers the document to the external mail server. The mail server delivers the mail to the mail box of the person in charge.

n    The administrator is notified and can directly check the error situation of the corresponding system.

n    Note: With SAP Web AS 6.30 (and later), you are able to send and acknowledge CCMS alerts via WAP from your mobile.

n    An example, how to configure e-mail notification will be given later in this unit.

n    Central auto-reactions are triggered in a dedicated central SAP system and not in the system where the alert is raised.

n    Prerequisites for central auto-reactions are:

The SAP system, where the auto-reaction is raised centrally, is a SAP Web AS.

The component systems are connected by the CCMS agents SAPCCMSR, SAPCCM4X and SAPCM3X.

n    The central auto-reaction mechanism functions as follows:

Central auto-reactions are configured only in the CEN. Information about the existence and assignment of the central auto-reaction is transferred to the component system during configuration by the CCMS agent. So the component system knows that a central auto-reaction has to be triggered and not a local one.

If an alert is raised in a component system, the alert information is transferred to a database table in CEN by the CCMS agent. Additionally, an event is raised in CEN.

The central method dispatcher is an event periodic batch job, which starts immediately. The alertinformation is read and the corresponding auto-reaction is triggered in CEN.

n    Because of central auto-reactions CCMS agents can act as RFC clients.The installation of agents is a little bit different, if CEN is a SAP Web AS: the CCMS agent needs a valid user account to log on into CEN in case of an alert.

n    The central method dispatcher is not activated by default. You have to trigger the event periodic batch job once in CEN. SAP recommends to trigger the job in client 000.

n    Start transaction RZ21 and choose Technical Infrastructure Method execution Activate Central System Dispatching. A batch job SAP_CCMS_CENSYS_DISPATCHER is triggered.

n    Analysis methods send you straight into the necessary solutions when an alert has occured. Analysis methods can be detailed SAP analysis transactions, reports, function modules or URLs.

n    In case of  SAP application servers, the analysis method can also be called across systems by usage of the analysis RFC connection, specified during system registration. Depending on, if a valid user account is maintained in the RFC connection, the Login screen of the remote component appears, or you jump directly into the remote component.

n    SAP delivers the CCMS alert monitor preconfigured with useful analysis methods. Nevertheless, you can define your own analysis methods and assign them to any MTEs.

n    SAP delivers two special analysis methods, that can be assigned to information nodes:

The CCMS_SHOW_FILE_FROM_TEXT_ATTR analysis method interprets the contents of the text attribute as file names. The related CCMS agent returns the contents of this file via RFC which is then displayed. When monitoring the ITS, various service files of the ITS can be displayed.

The CCMS_SHOW_URL_FROM_TEXT_ATTR analysis method interprets the contents of the text attribute as an URL. The default browser is started and the URL is called. When monitoring the ITS, the Web based administration tool or a Web GUI can be called.

n    In case of CCMS_SHOW_FILE_FROM_TEXT_ATTR the file is transferred by the CCMS agent. For safety reasons, not all files of the remote host can be accessed. The CCMS agent only transfers those files that have the correspondinding display authorization assigned. The files to be displayed must be specified in the sapccmsr.ini agent configuration file with the help of the 'ViewDirList' parameter.

n    You can find further information in SAP Note 452797.

n    If necessary, you can define your own methods. Enter transaction RZ21, select Method definitions and choose Display overview. A list of defined methods is displayed. Choose Create. Your new method name should begin with "Z".

n    There are five tabs:

Execution: You have to define, what type of call is to be executed as method (e.g. report, function module) and where the method is to be processed.

Control: You can define, how your method is to be executed. In case of a data collection method, an automatic start during system startup can be configured.

Parameters: Depending on the program, a method can deal with further parameters. If, for example, you want to be notified by e-mail in case of alert, you have to define the parameters ,sender" and ,recipient" on this tab.

Release: To activate the method, it has to be released. Depending on the program choose the appropriate method type.

Addtl. Info: Shows the user, who last changes the method definition.

n    Note: Not all possible combinations are allowed. For instance, a dialog transaction cannot run automatically as an auto-reaction.

n    The current slide shows the definition of transaction SM37 as an analysis method.

n    After definition and release, the method can be assigned to an MTE. There are different types of possible method assignments:

Methods can be assigned to individual MTEs.

MTEs of the same physical content are logically grouped together in MTE classes. You can assign methods directly to MTE classes. Doing so, the methods are assigned implicitely to all MTEs of the MTE class. Assigning methods to MTE classes can reduce customizing dramatically.

Methods can be assigned to upper levels of the monitoring tree and passed to lower levels.

n    Method assignment can be done on a per property variant level.

n    SAP's default methods are assigned to MTE classes, not to individual MTEs. SAP strongly recommends to assign methods to MTE classes, because the settings can be transported into other SAP systems using SAP's transport mechanism.

n    Example: An SAP system consists of several SAP instances. Each SAP instance has the performance counter CPU_Utilization. Instead of setting up e-mail notification for each SAP instance, you can specify for a complete MTE class that you want to be notified at daytime. If there is only batch processing over night, you can automativally remove the notification method from the property variant for night processing.

n    MTE classes group MTEs of the same physical or logical content. Besides method assignment the standard description text, the data collection frequency (in case of a passive data supplier), and the common attribute properties as for example alert severity are controlled by the MTE class definition.

n    To display the general properties of an MTE class, start transaction RZ21, select Properties assigned to MTE classes amd choose Display overview. Select an MTE class by double clicking. The settings are made within a property variant.

n    Since SAP Basis 4.6, the visibility level has become obsolete. The option Overview should be selected.

n    If you need to change the method assignment of your CCMS alert monitoring infrastructure, you have two possibilities:

Using transaction RZ21: the corresponding MTE class name has to be known.

Using transaction RZ20: the corresponding MTE has to be known.

n    Method assignments to MTE classes can be displayed using transaction RZ21 by selecting Methods assigned to MTE classes and clicking Display overview. A list of all MTE classes and their method assignments with respect to property variants is displayed.

n    Double click on one entry. If you select an MTE class definition of property variant SAP-DEFAULT, you cannot change the settings directly. You first have to copy the settings into another property variant.

n    Select Edit Assignment in other to variant. You can select the appropriate destination of your settings.

n    After copying the settings into another variant, you can adapt data collection, auto-reaction, and analysis methods accordingly.

n    To assign a method to an MTE class using transaction RZ20, open a monitor in RZ20, that shows the corresponding MTE.

n    Mark the MTE and click Properties.

n    The MTE class name of your is displayed in the upper part of the screen.

n    Select the tab Methods. The current assignment for data collection, auto-reaction and analysis method is displayed.

n    To change the settings click method assignment.

n    Hint: Depending on the release and basis support package level of your system, you can directly double-click on the MTE class name in the upper part of the dynpro.

n    To change the assignment of methods to MTE classes, double click on the MTE class name. You jump directly into the corresponding settings of transaction RZ21.

n    Note: changing the assignment of methods to MTE classes affect all MTEs of the MTE class.

n    To change the method assignment of a single MTE, do not double click the MTE class name. Click the Change/Display icon instead.

n    Mark the Method name radio button and enter the appropriate method name. Click Save.

n    Caution: Depending on the release and basis support package level of your system, the tab for data collection is selected by default! Select the appropriate tab, if you want to change the auto-reaction or the analysis method.

n    Note: MTE specific method assignment is not included in a change request created by usage of a property variant! These changes have to be adapted manually in the component systems!

n    As a first example, the steps to configure e-mail notification are described.

n    To configure mail notification as an auto-reaction in a local system, the following steps are necessary:

SAPConnect has to be configured in client 000, because the mail is created and sent out of client 000.

As of SAP Basis 4.6 SAP delivers the preconfigured auto-reaction CCMS_OnAlert_Email. Instead of adapting this method, make a copy of the method.

For each recipient or recipient list, you need an extra copy. Customize the sender and receiver information.

Assign your method to the corresponding MTEs.

n    Information about e-mail notification can also be found in SAP notes 176492 and 502959.

n    SAPConnect is the interface between the SAP office environment (transaction SBWP) and external communication partners. Use transaction SCOT for customizing SAPconnect.

n    SAPConnect cannot send e-mails directly. You need an extra mailing program (e.g. UNIX sendmail) to get a link to the internet. SAPConnect communicates to the external programs by using RFC or SMTP (since SAP Web AS 6.10). You can find further information about SAPconnect and SMTP in SAP note 455140.

n    SAPconnect customizing is client dependent. For sending notifications out of the CCMS monitoring infrastructure, SAPconnect has to be configured in client 000.

n    For each communication partner you have to create and configure a SAPconnect node. You can find further information in the SAP Online documentation. An actual version can be found using SAP Note 440252.

n    The documents are sent out of SAPconnect by a batch job that runs periodically.

n    After configuration of SAPconnect, you have to copy and configure the auto-reaction method. Enter transaction RZ21, select Method definitions, and click Display overview.

n    You get a list of defined methods. Mark the check box next to CCMS_OnAlert_Email and click Copy. Your new method name should begin with "Z".

n    There are only minor changes necessary for completing the method definition.

n    On the tab Execution, choose Execute method on any server. In this case, you can also assign the method to MTEs of the CCMS agent SAPCCMSR, because the mail is processed on the SAP server and not on an agent (which is impossible).

n    Sending an alert notification is a short running task. Choose the tab Control. Execute method automatic in dialog process should be selected. In this case, the method dispatcher running in dialog mode (SAPMSSY8) triggers the notification which is sent at most 5 minutes after the alert is raised.

n    Choose the Parameters tab. You have to configure sender and recipient information:

SENDER: SAP user name of the person who sends the e-mail. If the user is not defined in client 000, you must also specify the system and client in which the user exists.
Example: C11:003:NAKE
If the user is known in client 000 then it is enough to give the SAP user name.
Example: NAKE.

RECIPIENT: SAP user name of the e-mail recipient, or distribution list containing the recipient"s name, external e-mail address, pager, or fax number. If you want to send an e-mail automatically to an external e-mail address, you can enter the address as the RECIPIENT parameter value.
Example: [email protected]
However, if you want to send an e-mail automatically to several external e-mail addresses, you must create a distribution list in client 000 that contains these "remote addresses".

RECIPIENT-TYPE ID: Enter the corresponding ID. The most important ones are:

F: Fax

R: Remote SAP name

U: Internet mail.

n    On the Release tab, mark the box auto-reaction method and save your settings. The method customizing is now complete.

n    Assign the method to important MTEs of your monitors via MTE classes. Think of a method assignment depending on property variants for day and night processing.

n    As a result, if three is an alert for your MTEs, an e-mail is sent to you using SAPConnect.

n    Note: The e-mail notification is now activated for a single system. If there is another SAP system, which should send notifications in case of alerts, you have to transport the auto-reaction and the method assignment to the system. Furthermore, SAPConnect has to be set up accordingly.

n    Using central auto-reactions can reduce customizing efforts, if the auto-reaction can be triggered in the central system only.

n    Central auto-reactions are configured in the central monitoring system only. Preconditions for central auto-reactions are:

The SAP system, where the auto-reaction is raised centrally, is a SAP Web AS.

The component systems are connected by usage of the CCMS agents SAPCCMSR, SAPCCM4X and SAPCM3X.

n    Example: To configure e-mail notification centrally in case of alerts of the component systems, you have to set up the method definition in CEN. Afterwards, the method is assigned to MTE classes of the component systems.
There is no need to transport method definitions. Moreover, SAPConnect has only to be configured in CEN.

n    A single report has to be run, which updates the corresponding information in the component systems.

n    Hint: Using central auto-reactions implies, that the central method dispatcher is activated in CEN! Start transaction RZ21 and choose Technical Infrastructure Method execution Activate Central System Dispatching. A batch job SAP_CCMS_CENSYS_DISPATCHER is triggered.

n    Note: The central auto-reaction cannot be assigned to single MTEs of component systems. The assignment can only be done by usage of MTE classes.

n    Note: The assignment of central auto-reactions is independent of property variants in the component systems.

n    The only difference between local and central auto-reaction definition is the selection of the method execution: on the Control tab, select Only in central system triggered by CCMS agents.

n    To assign a central auto-reaction to an MTE class of a component system, start transaction SE37 in CEN. Select the function module SCSM_CEN_TOOLASSIGN_WRITE and click Single test.

n    Mark the check box for Upper / lower case.

n    For SYSTEM_ID, enter the SID of the component system.

n    For MTE_CLASS, enter the corresponding MTE class name.
Hint: work with a second mode of SAPGUI, that displays the corresponding MTE of the component system. Then you can copy & paste the (more or less cryptic) MTE class names.

n    For TOOLNAME, enter the method name of the central auto-reaction.

n    For TOOLSTATUS, "91" has to be entered.

n    Click Execute.

n    Check the return code, which has to be 0.

n    To update the new method assignment in the component system directly, run the report SAPMSSYT using transaction SA38. Alternatively the information is refreshed automatically after at most one hour by a data supplier, which is triggered by the background dispatcher.

n    As a last example for an auto-reaction, the execution of an operating system command is presented.

n    As of  SAP Web AS 6.10, the function module SALO_EXECUTE_SYSTEM_COMMAND is delivered that can be used for triggering logical commands.

n    The steps to execute operating system commands as auto-reacions are:

Group your operating system commands in a shell script.

Define a logical command in SAP using transaction SM69, which executes the shell script.

Define an auto-reaction method using transaction RZ21, which executes the logical command. Customize the method parameters accordingly.

n    The current slide displays the auto-reaction method definition screen. Under Execution, enter the function module SALO_EXECUTE_SYSTEM_COMMAND. Under Control, select either periodically in dialog process or only in central system triggered by CCMS agents, depending on, if this is a central auto-reaction or not.

n    Select the Parameters tab. Three parameters can be used:

COMMAND: Enter the name of your logical command defined in transaction SM69.

PARAMETERS: An arbitrary string, which is passed as a parameter to your operating system command. After the string defined in PARAMETERS, the corresponding SID, date, time, and the alert message are also passed to the operating system command for further usage.

REACT_ON_ALERTS: Parameter values can be YELLOW or RED, depending on, if the logical command should be executed for yellow and red alerts (YELLOW) or for red alerts only (RED).  The default setting is RED.

n    Don't forget to release the auto-reaction method.

n    Hint: Please make sure, that the operating system command or shell script lies in the PATH of the executing operating system user SIDadm (Unix) or SAPServiceSID (Windows).

n    Now you know the different types of methods and what they are good for. Most of the MTEs of the CCMS monitoring infrastructure have appropriate method settings, and there is no need to change these settings.

n    Nevertheless, you should check your monitor definitions. The attribute nodes of the alert tree should be configured with useful analysis methods. If you have better analysis activities (transactions, reports, URLs, .), create and assign your own analysis methods.

n    Think about the notification possibilities. Are there any MTEs, whose information are crucial for your company"s business? For most administrators for example, the availability check of SAP systems is very important. If you can use central auto-reactions, you should use them in case of notification, because SAPconnect has to be configured only in CEN.

n    Think about operating system scripts as auto-reactions. For example, you could trigger a backup program, if the database log directory exceeds a certain limit. Such an auto-reaction cannot be triggered centrally.

n    The service marketplace delivers important documents about methods for the CCMS alert monitor:

You can write your own data supplier in ABAP or Java. Information can be found in:

"How to write a data supplier for the alert monitor" (ABAP).

"Java monitoring API: Properties and installation" (Java).

The auto-reactions of the CCMS alert monitor are described in "Predefined auto-reaction methods of the alert monitor".

Customizing Methods Exercises

	Unit: Customizing Methods Topic: Data Collection Methods
	At the conclusion of this exercise, you will be able to: Use all types of methods of the CCMS alert monitor Create and assign auto-reaction and analysis methods
	After customizing thresholds for your monitors, you get alerts only if there are severe problems. Now you should think about e-mail notification in case of an alert and check the analysis methods assigned to the monitoring attributes.

8-1 Use data collection methods.

8-1-1 Open your monitor created in exercise 4-1-2. How often is the data collection method started for the monitoring attribute UsersLoggedIn?

8-1-2 Go back into your monitor. Click Refresh. Is the data collection method started by refreshing the display? If not, why not?

8-1-3 Start the data collection method manually for UsersLoggedIn.

8-2 Use analysis methods.

8-2-1 Open your monitor created in exercise 4-1-2. Start the analysis method for the monitoring attribute Response Time. Which transaction is started? Why?

8-2-2 Start the analysis method for the monitoring attribute UsersLoggedIn. What happens? Why?

8-2-3 Create a new analysis method ADM106_Analysis-##, which calls transaction AL08. AL08 is suitable for monitoring users. Release your method to be used as an analysis method.

8-2-4 Assign your analysis method ADM106_Analysis-## to the MTE class of monitoring attribute UsersLoggedIn. Try to start the analysis method directly.

8-2-5 Optional: Open your monitor Rule dialog monitor 1. Check some analysis methods of the monitoring attributes. If you like, you can create some more useful analysis methods and assign them to the MTE classes of the corresponding monitoring attributes.

8-2-6 Optional: Open your monitor Rule dialog monitor 2. What about the analysis methods for the MTEs from the child system? Are they changed? If not, why not? How can method customizing be delivered to the child system? What information has to be transported?

8-3 Use auto-reaction methods.

8-3-1 SAPConnect is already configured in client 000 of the training system so that a send job sends RML documents to the working client every 10 minutes. Check your course user's RML address (transaction SU01 Other communication).

8-3-2 Prepare the method that sends e-mails: In transaction RZ21, copy the CCMS_OnAlert_Email method to ZADM106-MAIL-##. Enter the following details for the parameters:

Sender: DUMMY (the client 000 user with which the document will be sent)

Recipient: Your RML address (<SID>:<CLIENT>:<RML-Username>)

Recipient -TypeID: R for RML

Release the method as an auto-reaction method.

8-3-3 Assign the method: Using your MTE class, assign your auto-reaction method to the MTEs that you have chosen. The assignment should be for both your and the instructor's variants.

8-3-4 Test the auto-reaction: As a test, assign your auto-reaction method individually to the monitoring attribute UsersLoggedIn of your monitor created in exercise 4-1-2. Set the threshold value of this node to a level that is low enough for an alert to be processed. Start the data collector manually. Check the status of the alert: After SAPMSSY8 has run, the status should change from ACTION_REQUIRED to ACTIVE. An e-mail is sent to you (for example, transaction SBWP) as soon as the send job in client 000 has sent the document.

8-3-5 Optional: What has to be changed to configure e-mail notification centrally? Copy method ZADM106-MAIL-## to ZADM106-CENMAIL-## and change the method definition accordingly. Try to assign this central auto-reaction to the MTE UsersLoggedIn of the child system.

Customizing Methods Solutions

Unit: Customizing Methods Topic: Data Collection Methods

8-1 Use data collection methods.

8-1-1 Using transaction RZ20, double-click to open your monitor Rule dialog monitor 2. Expand the monitoring tree and select the monitoring attribute UsersLoggedIn. Choose Properties. Select the Methods tab. Under Start the data collection method every, 240 seconds is displayed.

The data collection method is executed every 300 seconds by the AUTOABAP SAPMSSY8.

SAP does not recommend triggering the AUTOABAP reports more often than every 5 minutes.

8-1-2 Refreshing a monitor means gathering new monitoring data from the shared memory segments. You don't start a data supplier by choosing Refresh. If no new data is stored in the shared memory segments, the old values are displayed.

8-1-3 Activate the maintenance function (Extras Activate maintenance function). Select the monitoring attribute UsersLoggedIn. Choose Edit Nodes (MTE) Start method Start data collection method.

In the Current system status view, for the measuring time you can see that the data supplier has refreshed its value.

Starting a passive data supplier is possible only if the maintenance function is activated!

8-2 Use analysis methods.

8-2-1 Double-click your monitor Rule dialog monitor 2 to open it. Select ResponseTime. Click Start analysis method (gauge icon). You are taken into the transaction ST03N, which is one of the main SAP performance analysis transactions.

Choose Back to go back into your monitor.

Select ResponseTime. Choose Properties. Select the Methods tab. Under Analysis method, you can see that method CCMS_ST03 is assigned. Double-click this method. You are taken into the definition screen of the method. As you can see, transaction ST03N stands behind the method CCMS_ST03.

8-2-2 Choose Back twice to go back into your monitor. Select UsersLoggedIn. Click Start analysis method (gauge icon). Nothing happens: An error message is displayed.

Select UsersLoggedIn. Choose Properties. Select the Methods tab. Under Analysis method, you can see, that method <NO_METHOD> is assigned. No analysis method is assigned to this MTE.

8-2-3 Analysis methods are defined using transaction RZ21. Select Method definitions and choose Display overview. A list of all methods defined in your SAP system is displayed.

Choose Create. Enter the method name ADM106_Analysis-## and a meaningful description.

Select the radio button for transaction and enter AL08. Select Execute method on any server.

AL08 is an instance-independent transaction. If you want to start an instance-dependent transaction (SM50, for instance) to be used as an analysis method, you have to select Execute method on the local server of the MTE to be processed.

Select the Control tab. Under Execute method, select Manually executable only.

Select the Release tab. Select Analysis method and choose Save.
The analysis method is now ready for use!

8-2-4 Using transaction RZ20, open your monitor Rule dialog monitor 2 (by double-clicking it). Expand the monitoring tree and select the monitoring attribute UsersLoggedIn. Choose Properties.

Double-click the MTE class name CL_UsersLoggedIn##. You are taken directly to the method assignment to your MTE class. Choose Display <-> Change. For Analysis method, select Method name and enter your analysis method ADM106_Analysis-##.

Choose Save. Your analysis method is now assigned to the MTE class of the MTE UsersLoggedIn with respect to the active variant, the instructor's variant.

Go back into the monitor, select UsersLoggedIn, and click Start analysis method (gauge icon). You are taken immediately into transaction AL08.

Assigning methods to MTE classes using transaction RZ20 is release and patch level dependent. If double-clicking the MTE class name does not work, select the Methods tab and choose Method assignment. On this screen, double-click the MTE class name to go into the assignment of methods to MTE classes. Choose Edit assignment in other to variant first before changing the method assignment.

8-2-5 Some other useful analysis methods might be:
ST04 - DBRequestTime
SM50 - Utilization
STAD - LongRunners
ST22 - ProgramErrors
SMLG - LogonLoadQuality

8-2-6 Open your monitor Rule dialog monitor 2. Select the monitoring attribute UsersLoggedIn of the child system. Click Start analysis method (gauge icon). Nothing happens.

Choose Properties. Select the Methods tab. For Analysis method, <NO_METHOD> is still selected.

Similar to customizing thresholds, the assignment of methods to MTE classes has to be done for each system locally. You can either assign methods in the remote component using transaction RZ20 (keep in mind, that the method must be available in the remote component) or create a change request out of the properties variant. Additionally, assign the method definitions to the change request and transport it to the remote component using the standard SAP transport mechanism TMS.

8-3 Use auto-reaction methods.

8-3-1 Start transaction SU01, enter your course user name ADM106-## and choose Change. Choose Other communication and select RML by double-clicking it. Enter the following data:

Field Name or Data Type	Values
Syst.Name	SID of CEN
RML client	Your current working client number
RML name	ADM106-##

Choose Enter and save your settings.

8-3-2 Start transaction RZ21 to configure the auto-reaction, which notifies you in case of an alert.

Select Method definitions and choose Display overview. A list of all methods defined in your SAP system is displayed.

Select the method CCMS_OnAlert_Email and choose Copy. Enter the new method name ZADM106-MAIL-## and press ENTER.

Your new method can send SAP office documents. We have to configure the sender and especially the recipient of the document.

Choose Display <-> Change and select the Parameters tab. Enter the following data:

Field Name or Data Type	Values
Sender	DUMMY
Recipient	<SID of CEN>:<Client-Nr.>:ADM106-##
Recipient -TypeID	R

Select the Release tab. Select Auto-Reaction and save your settings. Your notification auto-reaction is now ready for use!

8-3-3 Assignment of your auto-reaction method to MTEs of your choice is done as in exercise 8-2-4. Using transaction RZ20, your assignment is stored in the active variant (the instructor's variant). If you want to store the assignment in another property variant, go to the screen where the assignment of methods to an MTE class is done and choose Edit assignment in other to variant. Enter your own property variant ADM106-## and choose Save.

8-3-4 Start transaction RZ20 and open your monitor, created in exercise 4-1-2, by double-clicking it. Expand the monitor tree and select the monitoring attribute UsersLoggedIn. Choose Properties. Select the Methods tab. Choose Method assignment. Select the Auto-reaction tab. Choose Display <-> Change. Select Method name and enter your auto-reaction method ZADM106-MAIL-##. Choose Save.

Choose Back.

Select the PerformanceAttribute tab. Lower the thresholds so an alert will be raised.

Choose Back to go back into the monitor. Activate the maintenance function (Extras Activate maintenance function). Select the monitoring attribute UsersLoggedIn. Choose Edit Nodes (MTE) Start method Start data collection method.

Switch to the Open alerts view. Double-click UsersLoggedIn to enter the alert browser. A new alert with status ACTION_REQUIRED should be raised. After the next run of SAPMSSY8, the alert status should be changed to ACTIVE.

After some minutes (time delay between creating and batch periodic sending of the e-mail), enter the business workplace (transaction SBWP) and check your inbox for a new e-mail, which notifies you about the error situation of the users logged into your system.

8-3-5 Copy your auto-reaction ZADM106-MAIL-## to ZADM106-CENMAIL-## as described in exercise 8-3-2.

Select the Control tab. Choose Display <-> Change. Select Execute method only in central system, triggered by CCMS agents. This is the main difference between local and central auto-reactions.

Select the Release tab. Select Auto-reaction and choose Save.

To assign the auto-reaction to an MTE of the child system, start transaction SE37 and enter the function module SCSM_CEN_TOOLASSIGN_WRITE. Choose Single test.

Select Upper/lower case. Enter the following data:

Field Name or Data Type	Values
SYSTEM_ID	SID of the child system
MTE_CLASS	CL_UsersLoggedIn## (## is your group name)
TOOLNAME	ZADM106-CENMAIL-## (## is your group name)
TOOLSTATUS	91

Choose Execute. The RETURN_CODE should be 0, otherwise, go back and try once more.

To transfer the information to the child system, start transaction SA38, enter the report SAPMSSYT and choose Execute.

To work with the central auto-reaction, adapt your monitor created in exercise 4-1-2. In the monitor definition, change the parameter R3System from <CURRENT> to <ALL>. Save your settings.

The monitor now shows information about all registered SAP systems. Click monitoring attribute UsersLoggedIn of the child system. Choose Display Details. Under General Details, select the check box and click Choose detail. This information comes right out of the shared memory of the child system. Your auto-reaction method ZADM106-CENMAIL-## should be displayed.

You can now lower the thresholds of this monitoring attribute to raise an alert. You can continue as in exercise 8

n    This appendix outlines the general purpose of the Solution Manager, as well as describing some functions in more detail.

n    This first part will introduce the idea behind Solution Manager.

n    One problem often encountered by SAP's support specialists was that they were called into action when some serious problem had escalated. But to determine the further path of action the support specialist had first get to know the system landscape and its environment. This "get to know" process took sometimes up to two days, depending on the complexity of the implemented landscape. Only then they could begin their work on problem solving. SAP Solution remedies this situation in several ways: first it documents in a very conscise way the implemented system landscape, second it helps tremendously in finding causes for problems.

n    Taking into consideration the other features as producing your own Early Watch Alert reports, accessing Best Practise documents, setting up company-wide Support Desk, and some more, you end up with a very valuable tool for ensuring system performance and consistency.

n    Please note that the points mentioned above correspond to the points on the previous page.
For example the documentation of the complex system landscape helps to reduce the time it takes to get an overview of all components involved in specific business processes. This accelerates the process of problem finding and solving.

n    You can define business processes that span several component systems. Until now, monitoring the total run time of these processes was tricky. With the Solution Manager it is easy to model the core business processes and map the involved components. After connecting the Solution Manager to all components involved and configuring which steps the Solution Manager should track, it is possible to get "the whole" picture of one process spanning several systems.

n    Because this is difficult to set up, you will probably want to limit the monitoring to your core business processes.

n       The Solution Manager draws ist data primarly from two sources:

n       The monitoring infrastructure (RZ20 and ist components)

n       Service Data Downloads conducted in each connected component

n       From the alert graphic dispaly there are two ways to proceed:

n       You can analyze existing alerts, eventually being referred to the "old" analysis transactions like ST02. This way is therefore used when you note a specific problem in your solution landscape.

n       You can navigate to open tasks associated with certain components, like for example regularly checking some system's syslogs. This function is used to prevent error situations from occuring by performing regular checks.

n    If you offer IT services to someone else, the contract indicates what level of service and availability is guaranteed by your operation. Previously some elements of these Service Level Agreements were not easy to prove. Now you can use Service Level Management tools to monitor simple objects (for example, hit rate for some buffer) or to monitor complex business processes (for example, sales order processing spanning several component systems). You are also able to react much faster when some objectives of the service level agreement are endangered.