Configuration Steps for SAP NetWeaver Administrator (NWA)

As of SAP NetWeaver 04 SP Stack 12, the SAP NetWeaver Administrator (NWA) is also available to you for landscape-wide administration and central monitoring.

The NWA runs as an application on the J2EE Engine and is called using the URL :
http://host:port/nwa

To use the NWA for central monitoring, install a Java Add-In for your CEN, if it does not already have one. Since you can use the NWA not only for central monitoring, but also for central administration, the corresponding double-stack system is referred to as the central administration and monitoring system. This system is also abbreviated to CEN

If you want to use the NWA to monitor your system landscape, you need a System Landscape Directory (SLD), since information about the monitored systems is stored in the SLD for this application. We recommend that you set up an SLD on the J2EE Engine of CEN for this purpose. This SLD is known as the administrative SLD.

• You need to configure and start the administrative SLD; you also need to enter all ABAP and Java systems in your system landscape into this SLD.
• CEN must be able to write data about the agents of the monitored systems to the administrative SLD. You need to create special connections and authorizations for this.
• You also need to set up a special RFC connection between the ABAP and the Java stacks of CEN.
• If you want to use the NWA to administer multiple Java systems, we recommend that you store the corresponding logon data in the NWA's J2EE Engine, so that you do not need to log on with a user name and password every time.

To simplify this step, the Template Installer is available in the NWA. You can use it to perform the above configuration steps more easily.


More can be found @ http://service.sap.com/nwa

Prerequisites:
1) Monitored ABAP systems must be entered in transaction RZ21;
2) A CCMSPING availability agent must be installed and registered with CEN;
3) Monitored Java systems must be registered with CEN using the CCMS agent SAPCCMSR;
4) It is recommended to register the monitored ABAP instances with CEN using the CCMS agent
SAPCCM4X;

More Information can be found from the link below.

http://help.sap.com/saphelp_nw04s/helpdata/en/3d/b5f9c2ea65c242957ee504ca4a37a9/frameset.htm

SAP Netweaver 2004s - Components of Monitoring - Global Workload Monitor

The Global Workload Monitor (transaction ST03G) displays statistical records for entire landscapes and therefore allows the analysis of statistical data from ABAP and non-ABAP systems. You can use this data to analyze the workload of the monitored components in great detail.

While statistics records for an ABAP system can only trace actions that are processed by ABAP components, you can use Distributed Statistics Records (DSRs) to trace actions that are processed by, for example, the J2EE Engine, ITS, and TREX. You can even do so across component boundaries.

SAP Netweaver 2004s - Components of Monitoring - Standalone Log Viewer

With the standalone log viewer, you can monitor any J2EE Engine or Java application log files, even if the J2EE Engine is not functioning correctly, cannot be started, or is not available on the system to be monitored. The standalone log viewer contains any number of servers and one client:

• 
  The server of the standalone log viewer monitors log files that are registered with this server. It must be installed on every host of the J2EE system landscape. The various servers function independently of each other.
• 
  The client of the standalone log viewer connects to one or more servers of the standalone log viewer and displays the contents of the log files. You only need to install the client once in the J2EE system landscape.

For general information about the standalone log viewer, see the SAP NetWeaver Library
under SAP NetWeaver -> SAP NetWeaver by Key Capability -> Application Platform by Key Capability -> Java Technology in SAP Web Application Server -> Administration Manual -> Supportability and Performance Management -> Logging -> Log Viewer -> Standalone Log Viewer.

SAP Netweaver 2004s - Components of Monitoring - Operating System Collector SAPOSCOL

The operating system collector SAPOSCOL is an independent program that runs in the
operating system background. It functions independently of the SAP instances, exactly once per monitored host. SAPOSCOL collects data about operating system resources, including:

* Usage of virtual and physical memory
* CPU utilization
* Utilization of physical hard disks and file systems
* Resource usage of running processes

SAP Netweaver 2004s - Components of Monitoring - CCMS Agents

CCMS agents are independent processes with an interface using RFC to a central monitoring system and an interface to the shared memory. These agents have the following properties:

• A connection to CEN using RFC, to ensure greater downtime security and general availability
• Use of the push technology to optimize performance when reading and writing monitoring attributes and alerts
• Inclusion of the operating system collector SAPOSCOL to monitor processes at operating system level.
• Connection to systems with no SAP NetWeaver Application Server
• Monitoring of any log files

There are various CCMS agents, including:

SAPCCMSR - Monitoring of components on which no SAP ABAP instance is active, such as the J2EE Engine or SAP IPC
SAPCCM4X - Monitoring of SAP ABAP systems as of SAP Basis 4.X

SAP Netweaver 2004s - Components of Monitoring - SAP NetWeaver Administrator (NWA)

The SAP NetWeaver Administrator (NWA) unifies the most important administration and monitoring tools both for Java and for ABAP systems in a new, browser-based user interface. The most important advantages of the NWA are:

• You no longer need to switch between different tools for administration, troubleshooting, and problem analysis of your entire SAP NetWeaver system landscape.
• There is now a central administration tool available to you landscape-wide for both Java and ABAP systems for starting and stopping instances, checking configuration settings and logs, and monitoring error-free functioning of components.
• The interface follows the current guidelines for interface design, is easy-to-use, task-oriented, and complete. By using Web Dynpro, it runs in a normal browser.
• The interface allows seamless navigation to other SAP NetWeaver administration tools (User Management Engine, in the future also System Landscape Directory, Adaptive Computing).
• For Java, the NWA represents the crossover from various expert tools to an integrated, simple, and clear solution. The NWA also completes the integration of the data sources for monitoring.
• For ABAP, the NWA represents the crossover from many different expert transactions, some of which are difficult to use, to integrated, centrally available information.

The NWA is delivered for the first time for SAP NetWeaver 04 SP Stack 12. A more advanced version is delivered with SAP NetWeaver 2004s. It is intended to deliver an advanced version with SAP NetWeaver 2004s. The NWA will also be continually further developed in later releases, and extended with additional administration and monitoring functions.

SAP Netweaver 2004s - Components of Monitoring - System Landscape Directory (SLD)

The SAP System Landscape Directory (SLD) is the central information provider in a system landscape. The SLD contains two types of information:

• Component information: all available SAP products and components and their versions. If appropriate, external products are also registered here.
• Landscape description: all installed systems in a system landscape.

SAP Netweaver 2004s - Components of Monitoring - Visual Administrator

The J2EE Engine Visual Administrator is a graphical user interface for administering entire clusters, all cluster elements, and all modules that are running on the J2EE Engine.

Among other things, it includes the following functions in a single user interface:

• Obtaining general information about a service, a manager, and interface, or a library
• Administration and changing of the properties for services and managers
• Configuration of global properties
• Administration and monitoring at runtime
• Performing deployments of applications

SAP Netweaver 2004s - Components of Monitoring - Alert Monitor

The alert monitor is the central tool with which you can efficiently administer and monitor distributed SAP solutions or client-server systems. The alert monitor displays problems quickly and reliably. The alert monitor has, among other things, the following properties:

􀁸 You can use the alert monitor to monitor all SAP and non-SAP systems, the host systems and the database completely and in detail.

􀁸 All errors generate alerts that are displayed in a tree structure; the most significant error is reported upward in the display hierarchy.

􀁸 You can assign analysis and auto-reaction methods to the individual nodes. These methods contribute to quicker processing of the error.

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

For general information about the alert monitor, see the SAP NetWeaver Library under
SAP NetWeaver -> Solution Life Cycle Management -> Solution Monitoring -> Monitoring in CCMS -> Alert Monitor.

LiveCache operation modes

There are three liveCache operating modes:
􀂋OFFLINE: No liveCache kernel processes are running, memory areas (caches) are not
allocated. No user can use liveCache .
􀂋ADMIN: The liveCache kernel is active, but caches are not yet synchronized with the volumes. Users cannot connect to the liveCache. Only the liveCache administration user can connect and perform administrative tasks like restoring the database.
􀂋ONLINE: The liveCache kernel is active and data and log information is synchronized between caches and volumes. Users can connect to the liveCache.

Livecache Architecture

􀂄 ABAP Programs and the APO optimizers use native SQL for communicating through the standard SAP DB interface to liveCache. liveCache has an SQL interface that is used to
communicate with the SAP instances. With native SQL, ABAP programs call stored procedures in the liveCache that point to (LCA) routines written in C++. An SQL class provides SQL methods to access the SQL data through the LCA routines.

􀂄 The LCA routines are part of a dynamic link library that runs in the process context of the
liveCache instance. In the Windows NT implementation of liveCache, LCA routines and their
interface are registered in the Windows NT Registry. For the Unix implementation, a registry
file is provided by liveCache. A persistent C++ class provides the LCA routines with access to
the corresponding Object Management System (OMS) data that is stored in the liveCache.

􀂄 LCA Routines in APO are delivered in DLL libraries as SAPXXX.DLL and SAPXXX.LST on NT or as shared libraries SAPXXX.ISO and SAPXXX.LST on UNIX . The application specific
knowledge is built into these LCA routines based on the concept of object orientation.

􀂄 liveCache is a hybrid of a relational and object-oriented database

􀂄 The relational part of the liveCache is available as the open source data base SAP DB (see http://www.sapdb.org/)

􀂄 The SQL part as well as the OMS part of the liveCache are based on the same DBMS basis
functionality which supplies services as for instance transaction management, logging, device handling and caching mechanisms

􀂄 Object and SQL data are stored on common devices

􀂄 All liveCache data is stored in the caches as well as on disks in 8 KB blocks called pages.

􀂄 liveCache stores the OMS objects in page chains, the pages in the chain being linked by
pointers. SQL table data are stored in the B*trees. SQL and OMS data reside together in the data cache and the data devices of the liveCache.

􀂄 liveCache, similar to the standard SAP RDBMS, can be administered within the SAP system.
The SAP transaction LC10 makes it possible to monitor, configure and administer liveCache.

􀂄 The LC10 applies the Database Manager CLI (DBMCLI) to administer the liveCache. Therefore, it is obvious that all functionalities of an SAP System are still available without the LC10 and could also be performed with the „native“ data base administration tool DBMCLI.

􀂄 In addition to the DBMCLI the administration tool DBMGUI is available, which is a graphical
user interface to the liveCache management client tool DBMCLI.

􀂄 While the DBMGUI works only on Windows NT/2000, running the WEB DBM requires only an internet browser and the DBM Web Server which can be installed anywhere in the net.

􀂄 DBMCLI, DBMGUI and WEB DBM should not be used for starting or stopping the liveCache,
even if LC10 itself calls DBMCLI for starting or stopping the liveCache. They should only be used for changing liveCache parameters, defining backup media and for liveCache monitoring. That is because the LC10 runs in addition to starting, stopping and initializing application specific reports. Moreover, it registers the LCA routines each time the liveCache is started.

The liveCache can be administered by
􀂄 Transaction LC10 in the SAPGUI
􀂄 Database Manager CLI (DBMCLI) command line interface
􀂄 Database Manager GUI (DBMGUI) graphical user interface for Windows NT/2000 only
􀂄 Web Database Manager (WEB DBM)

What is Livecache ? (LC10)

Why the Livecache has been developed ?

􀂄 For the development of the Advanced Planning and Optimization (APO) component a database system was needed which allows fast access to data organized in a complex network.

􀂄 Applying conventional relational database management systems as data sources for the APO showed a poor performance since disk I/O and the non-appropriate data description in the relational schema limited the performance.

􀂄 To read data from an application buffer which is in the same address space as the application
takes about 0.1ms. Reading data from a database takes about 1ms if the corresponding record
is already in the database buffer and even 10 ms if the record must be read from a hard disk
before.

􀂄 Working with an application having a too small buffer to accommodate all required data causes a huge data traffic between application and database server.

􀂄 An additional problem of the traditional buffering is that after reading data into the application buffer they are still organized in a relational schema which is not appropriate to describe complex networks.

􀂄 To achieve a good performance for applications which require access to a large amount of data (i.e. APO) it is necessary to bring the application logic and the application data together in one address space. One possible solution could be to shift the application logic from the application server to the database server via stored procedures. However, this impairs the scalability of R/3. On the other hand one could shift all required data to the application server.
But this requires that each server is equipped with very large main memory. Furthermore, the
synchronization of the data changed on each server with the data stored in the database server is rather complicated.

􀂄 To overcome performance problems the liveCache was introduced which is a dedicated server tier for the main memory-based temporary storage of volatile shared data.

Starting the CCMS Agent

Under Microsoft Windows NT the CCMS agent is automatically started, as the system starts the
associated service. If you have registered the CCMS agent under UNIX, the agent has not yet
been started. Start it using the appropriate command:

Agent Start Command
SAPCCMSR sapccmsr –DCCMS [pf=]
SAPCCM4X sapccm4x –DCCMS pf=
SAPCM3X sapcm3x –DCCMS [pf=]

Under UNIX, you must also ensure yourself that the CCMS agent is automatically started after a
restart of the server (for example, by entering the start command in INITTAB).

Creating the CSMREG User

As of SAP Web AS 6.40 SP 1 and as of 6.20 SP 42, you can have the CSMREG automatically created in CEN. To do this, start transaction RZ21 and choose Technical Infrastructure -> Configure Central System -> Create CSMREG User.

In earlier releases, you must create the user manually using the following procedure:
1. Choose Tools -> Administration -> Administration -> User Maintenance -> Users, or call
transaction SU01.
2. Create the CSMREG user.
3. Create authorizations and a profile for CSMREG and assign the profile to CSMREG. Ensure that the user type Communication (as of SAP Basis 4.6C) or CPIC (up to SAP Basis 4.6B) is selected on the Logon Data tab page.

The profile should contain the following authorizations (the specified authorization object S_CCM_RECV is only relevant in connection with the CCMS System Component Repository, which is delivered as of SAP Basis 4.6C):

Authorization Object
Field -> Value
1) S_RFC
RFC_FUGR -> FUGR
RFC_NAME -> SALC SALF SALH SALP SALS SAL_CACHE_RECEIVE SYST SCSM* RFC1
ACTVT -> 16

2) S_CCM_RECV
ACTVT -> P0-P2
TABLE -> *

Downloading the CCMS Agents

1. You require the file CCMAGENT.SAR. This archive contains all CCMS agents, including SAPCCMSR, SAPCCM4X, and SAPCM3X.

* We recommend that you use the newest version of each agent. You can determine the version of a CCMS agent with the option –v

* The archive also contains the availability agent CCMSPING.



2. You can download CCMAGENT.SAR from the SAP Software Distribution Center of the SAP

Service Marketplace (http://service.sap.com/swdc). Log on with your SAP Service Marketplace ID. Check the following folders in the specified order for this file and download it:

In the navigation bar, choose Download -> Support Packages and Patches -> Entry by Application Group -> SAP NetWeaver -> SAP NETWEAVER -> SAP NETWEAVER

2004S -> Entry by Component -> Application Server ABAP -> SAP KERNEL 7.00 32/64-BIT -> Database Independent.



Only if the desired archive does not exist in the above folder, choose Download -> Support Packages and Patches -> Entry by Application Group -> SAP NetWeaver -> SAP NetWeaver components -> SAP WEB AS -> SAP WEB AS 6.20 ->

SAP WEB AS ABAP -> SAP KERNEL 6.20 32/64-BIT -> Database Independent.



Only if the desired archive is not in either of the above folders, choose Download -> Support Packages and Patches -> Archive for Support Packages and Patches -> Entry by Application Group -> SAP Application Components -> SAP R/3 -> SAP R/3 4.6A -> SAP KERNEL 4.6D 32/64-BIT -> Database Independent.



The reason for specifying multiple folders is that CCMS agents are partly dependent on the operating system release. Agents for a current SAP release may no longer cover all available operating system releases (for example, agents for SAP Web Application Server 6.20 are supported only on HP-UX 11.x; however, there are still application servers to be monitored that are running on HP-UX 10.x).



* You can determine the version of the CCMS agents in CCMAGENT.SAR by displaying the associated Info File.



* If you require an agent for an older operating system release that is not in the folders above, SAP also provides the newest CCMS agent functions in patches to older SAP Basis releases (especially SAP Basis 4.6D), as far as possible.



3. Decompress the CCMAGENT.SAR archive with the SAPCAR tool. Take account of SAP Note 212876 (The new archiving tool SAPCAR). For decompressing the archive, use the following instruction:

sapcar –xvf ccmagent.sar



Up to SAP NetWeaver 04 CCMS agents were freely backward compatible, so you could – independent of the monitored system release – always use the latest release of the CCMS agent. As of SAP NetWeaver 2004s, this has changed:

* To monitor a SAP instance up to release NW04 (6.40), always use an agent with release NW04 (6.40).

* To monitor a SAP instance with release NW2004s (7.00) or a host without SAP instance, use an agent with release NW2004s (7.00).

Prerequisites for the Installation of CCMS agents

Below is the list of agents with the suitability for the systems.

SAPCCMSR - Components with no SAP instance and J2EE Engines with SAP Web AS 6.20; Central monitoring system as of SAP Basis 4.6B
SAPCCMSR with the option –j2ee - Java instances as of SAP NetWeaver 04; Central monitoring system as of SAP NetWeaver 04
SAPCCM4X - ABAP instances as of SAP Basis 4.X; Central monitoring system as of SAP Basis 4.6C
SAPCM3X - SAP systems with SAP Basis 3.X

􀁸 When installing a CCMS agent under Microsoft Windows NT or Microsoft Windows 2000, you require administrator rights on the relevant host.
􀁸 Install SAPCCM4X and SAPCM3X using the user adm (UNIX) or SAPService (Microsoft Windows) of the monitored system to ensure that the agent can access the shared memory.
􀁸 If multiple SAP R/3 3.X systems are running on one host, note the following points:
a) Install only one SAPCM3X agent for each host.
b) If you specify a profile, the agent monitors only one system; therefore, do not specify a profile (with pf=) when starting the agent.
c) So that the agent can read the shared memory segments of all of the systems, install the agent with the root user.
􀁸 For SAPCCM4X and SAPCCMSR with Option j2ee, you have to register one agent per monitored instance.

CCMS Monitoring agents - SAPCM3X

This agent allows the monitoring of SAP instances with SAP Basis 3.X through the CCMS
monitoring architecture. These systems do not have their own CCMS monitoring architecture
runtime environment. SAPCM3X therefore works always works with a monitoring segment that
it creates in its main memory (for more information, see SAP Note 308061).

CCMS Monitoring agents - SAPCCM4X

This agent improves the monitoring of ABAP instances with SAP Basis 4.X or higher. The central monitoring system must have a release status of at least SAP Basis 4.6C. This agent provides an alternative connection route to the monitoring information in the shared memory of an ABAP instance. As this alternative connection method does not require a free work process, the access method is independent of error states of the SAP instance and is therefore more robust.

Systems as of SAP Basis 4.0 have their own CCMS monitoring architecture runtime environment. This means that they have their own monitoring segment in the shared memory area of the running system. After its installation, the SAPCCM4X agent attempts to attach itself to and to work with this monitoring segment in shared memory when it is started.

If this segment does not exist (that is, if the monitored system is not running), the agent does not create it, to avoid interfering with the shared memory management in the restarting system. In this case, the SAPCCM4X agent works with the monitoring segment that it creates in its process memory and the contents of which it synchronizes with the monitored system. SAPCCM4X constantly checks whether the monitored system is active again, and when it is, works with the monitoring segment in the shared memory again, after synchronization.

The central monitoring system automatically first attempts to read data from the monitored
system through the RFC destination of the CCMS agent. If the agent is not active, the system
reads the monitoring data from the monitored SAP instance using the standard RFC, as previously (for more information, see SAP Note 322075).

Note that even if you are using the SAPCCM4X agent, you still continue to need the standard RFC connection anyway.

CCMS Monitoring Agents - SAPCCMSR (with Option j2ee)

SAPCCMSR agent monitors components on which there is no active SAP instance (such as log files, TREX, stand-alone databases, or operating system components). SAPCCMSR is closely connected with the monitoring central monitoring system.
After its installation, the CCMS agent SAPCCMSR attempts to attach itself to a monitoring
segment in shared memory when it is started. If this segment does not yet exist, the agent creates it. SAPCCMSR always works in a shared memory segment that is independent of running SAP systems. The central monitoring system must have a release status of at least SAP Basis 4.6B.


SAPCCMSR with Option j2ee
The functional principle of SAPCCMSR has been extended in case the SAPCCMSR CCMS agent is monitoring a J2EE Engine. In a case of this type, it must be possible that the monitoring segment of the SAPCCMSR agent does not belong to the central monitoring system. This is achieved by extending the system term to include Java components (such as J2EE Cluster). The
SAPCCMSR agent with the -j2ee option exists for this purpose.
Note :
To use SAPCCMSR with option j2ee, you need a central monitoring system as of SAP Web AS 6.40 Support Package 1.
The monitored J2EE Instance requires at least SAP Web AS 6.30 Support Package 4.

It is easier to understand the other steps if you use the following analogies:
ABAP - ABAP System , Application server , Work process

Java - J2EE Cluster , J2EE Engine , Virtual Machine (VM)

A system is no longer only a quantity of classical application servers with an ABAP runtime environment, but simply a number of associated components that have a common system name.
Combinations of ABAP instances and Java instances can also create a system, if all of these parts
are combined under one system ID.
You specify the system ID and the system number of the monitored Java instance during the registration of the agent using the instance's profile

When monitoring, it should be possible to display the data for the ABAP instances and the Java
instances of the same system in a central CCMS under the system ID of the monitored system. As far as possible, a Java instance should not be different from an ABAP instance; it should also be possible to monitor all instances with the same system ID locally as one system unit.

Important SAP Notes on CCMS Monitoring

042692 Test tool for RFC links: sapinfo
The RFC connection test provided in transaction SM59 is either not available or does not provide enough information. Use the test tool sapinfo described in this SAP Note for testing.

135503 CCMS Monitoring Architecture: Meaning of profile parameters
The profile parameters of the monitoring architecture are explained in this SAP Note. These are: alert/MONI_SEGM_SIZE, alert/MTTREE, alert/ALERTS, and alert/PERFHIST.

202591 CCMS Monitoring Kernel Patches (composite SAP Note)
This SAP Note describes the changes to the monitoring architecture through the various patch collections.

209834 CCMS agent technology (composite SAP Note)
This SAP Note contains, in addition to basic information about the CCMS agents, known problems that can occur in connection with the CCMS agents, and their solutions.

212876 The new archiving tool SAPCAR
This SAP Note explains the operation of the archiving tool SAPCAR, with which the SAP Service Marketplace files are compressed.

308061 CCMS monitoring architecture: monitor 3x systems
The CCMS monitoring architecture is available as of SAP Basis 4.0B. However, you can also monitor systems as of SAP Basis 3.0D using the monitoring architecture. This SAP Note explains the procedure required to do this.

322075 Installing the CCMS agent sapccm4x fails
This SAP Note shows how you can solve a possible problem (error during the interaction of the semaphores between the agent and the application server) during the installation of the CCMS agent SAPCCM4X on application servers up to SAP Basis 4.6C.

371023 OS07/ST06: Monitoring of operating system data
Operating system data of (any) server is to be collected with the operating system collector SAPOSCOL and reported in the CCMS monitoring architecture or displayed in transactions ST06/OS07. This SAP Note describes the prerequisites for this.

420213 Composite SAP Note: Central monitoring of mySAP.com components
This SAP Note provides current information about monitoring mySAP.com components that are not described in the standard documentation (see SAP Service Marketplace and SAP Library [page 109]).

429265 CCMS monitoring architecture: Central auto-reaction
As of SAP Web AS 6.10, you can define central auto-reaction methods in the monitoring architecture in the context of the central monitoring of mySAP.com components. The auto-reaction methods are not started in the system, in which the alert occurs, but rather in the central monitoring system. In this way, it is possible for reactions to events that occur in monitored components to be performed immediately in a central location. This SAP Note describes the prerequisites for this scenario.

498179 Enable Monitoring of InQMy/SAP J2EE Engine
You want to include the SAP J2EE Engine in the CCMS monitoring architecture. This SAP Note shows how you can do this with the SAPCCMSR agent.

502461 CRM: CCMS agent PlugIn for IPC
You want to include the IPC Server component in the CCMS monitoring architecture. This SAP Note shows how you can do this with the SAPCCMSR agent and the appropriate PlugIn.

535199 CCMS agents: Monitoring log files
In the context of monitoring systems and system landscapes, you can use CCMS agents to monitor log files; that is, to search through certain files for one or more word patterns. If a search pattern is found, the monitoring architecture displays a message or an alert. This SAP Note explains the configuration required to do this.

516181 SAP Expert Monitor for EMC (SEME)
You want to monitor cached disk subsystems, such as EMC Disc Arrays (Symmetrix) with the monitoring architecture. This SAP Note shows how you can do this with the SAPCCMSR agent and the appropriate PlugIn.

522453 RZ20: Monitoring operating system data
This SAP Note describes how you can configure the collection of operating system data in the monitoring architecture.

584136 CCMS agents and kernels: Patches 2003 (composite SAP Note)
This SAP Note describes the changes to the monitoring architecture through the patch collections during 2003.

694057 CCMS agents and kernels: Patches 2004 (composite SAP Note)
This SAP Note describes the changes to the CCMS agents in the patch collections from 2004.

704349 Activating the CCMS monitoring for TREX
TREX can provide monitoring data for the CCMS using the agent technology. To do this, the CCMS agent SAPCCMSR and the operating system collector SAPOSCOL must be installed and configured on the TREX host. This SAP Note describes the steps on the TREX host.

730629 CCMS agents: Java interface for registration
You want to register the CCMS agent SAPCCMSR. The monitored object can be an instance of a J2EE Engine with a release status of SAP Web AS 6.20 or a host on which SAP standalone components/non-SAP components (such as a database) are running.
During the registration of the agent, you must enter a large amount of information about the CEN, the connection to it, and, if appropriate, the monitored J2EE instance. This SAP Note contains, as an attachment, a Java tool to simplify the registration.

734247 Registering CCMS agents for SAP Web AS Java as of 6.30
You want to register the CCMS agent SAPCCMSR, to centrally monitor an instance of a J2EE Engine as of SAP Web AS 6.30 using a central monitoring system (CEN) as of SAP Web AS 6.40 SP 1. During the registration of the agent, you must enter a large amount of data about the CEN, the connection to it, and the monitored J2EE instance. This SAP Note contains, as an attachment, a Java tool to simplify the registration.

809007 CCMS Agents and Kernel: Patches 2005
This SAP Note describes the changes to the monitoring architecture through the patch collections during 2005.

817714 Agent registration not possible with visual administrator
This SAP Note describes the manual installation of CCMS agents for a SAP NetWeaver J2EE instance or an ABAP+J2EE instance (double-stack) if it is not possible to perform the agent registration from the Visual Administrator.

902460 CCMS: Agent displays no J2EE data in RZ20
A SAPCCMSR CCMS agent has been installed for an SAP NetWeaver 2004s (7.00) J2EE instance and registered with a central monitoring system. The CCMS agent is displayed as ONLINE in transaction RZ21, and provides data for OS monitoring and log file monitoring. However, no monitoring data is displayed for the J2EE Engine.

914721 CCMS Agents and Kernel: Patches 2006
This SAP Note describes the changes to the monitoring architecture through the patch collections during 2006.

929635 “CCMS Agent Configuration” tab page is missing
Automatic registration of the CCMS agent from the Visual Administrator is not possible, since the CCMS Agent Configuration tab page in the Monitoring service of the dispatcher is not displayed. This problem can occur with the following release statuses:
􀂃 SAP NetWeaver 04 SP Stack 13 up to SP Stack 16
􀂃 SAP NetWeaver 2004s up to SP Stack 7

Troubleshooting SAP CCMS Counter Selection

When trying to choose counters for the SAP CCMS monitor, SiteScope for Windows may display a blank screen or a Java exception message on the Choose Counters page. SiteScope will also make an entry in the /SiteScope/error.log.

The error message will be similar to the following:
' ' is not a valid monitor set name
(function 'BAPI_SYSTEM_MON_GET_TREE')
com.sap.mw.jco.JCO$Exception: (104)
RFC_ERROR_SYSTEM_FAILURE: See RFC trace file
or SAP system log for more details

This may be caused by a compatabiliy issue with a dynamic link library that may be included with SiteScope.

Note: This library is only used on the Windows version of SiteScope.

To correct the Counter Selection error
1. Stop the SiteScope service
2. Look for the file librfc32.dll in the /SiteScope/bin directory. If this file is present delete it.
3. Restart the SiteScope service.
4. Open SiteScope and create a new SAP CCMS Monitor

Setting CCMS Monitor Status Thresholds

SiteScope Application Monitors allow you to set multiple threshold conditions to determine the status reported by each monitor. The individual conditions are combined as logical OR relationships so that when one or more of the conditions (for example any of the conditions for Error if) are met the monitor status is set to the applicable condition. If multiple conditions are met for more than one status condition (such as conditions for both error and for warning), the status for the monitor is set to the highest valued condition. Thus a match of an error condition and a warning condition would be reported as an error status, error being the highest value, warning the next highest and good the lowest value.


Error if
Use one or more of the selection boxes in this item to define one or more error conditions for this monitor. Use the drop-down lists in these items to change error threshold(s) relative to the counters have selected to check with this monitor. After choosing a counter or parameter, use the comparison operator drop-down list to specify an error threshold such as: >= (greater than or equal to), != (not equal to), or < (less than) and enter a comparison value in the box provided. Comparison values should be entered as whole numbers.


Warning if
Use one or more of the selection boxes in this item to define one or more warning conditions for this monitor. Use the drop-down lists in these items to change warning threshold(s) relative to the counters you have selected to check with this monitor. Set these values relative to those you set for the error threshold in the Error if item.


Good if
You can set this monitor to return a good status for certain conditions. You may define those conditions here. Complete this item as you would for the Error if and Warning if items.

Completing the SAP CCMS Monitor Form

To display the SAP CCMS Monitor Form, either click the Edit link for an existing SAP CCMS Monitor in a monitor table, or click the Add a new Monitor to this Group link on a group's detail page and click the Add SAP CCMS Monitor link.
Complete the items on the SAP CCMS Monitor form as follows. When the required items are complete, click the Add Monitor button.

Server
Select the server you want to monitor. Use the choose server link to enter a path name to a server. The server selection page is displayed. Complete this form as follows:
· Server: Enter the address of the SAP server you want to monitor.
· SAP Client: Enter the Client to use for connecting to SAP. A default client of 800 is typically used.
· System Number: Enter the System number for the SAP server. A default system number of 00 is typically used.
· Username: Enter the Username required to connect to the SAP server. This user must have authorization to access CCMS metrics; see authorizations for details.
· Password: Enter the Password required to connect to the SAP server.
· Router String (Optional): If your connection is being made through a router, enter a router address string. You can find the router address using the SAP Logon tool from the SAP Client software. Open the Logon console, select the server you want to monitor and then select Properties to view the router address. Leave it blank otherwise.

Counters
Choose the server performance parameters or counters you want to check with this monitor. Use the choose counters link to bring up the counters selection screen where an expandable browse tree will be displayed. This tree will more or less match the hierarchy of Monitoring Tree Elements displayed in the Monitoring Tree that is shown in the SAP GUI with transaction RZ20. However, our browse tree may show more or less information than RZ20 depending on the authorization level of the username you specified for this monitor.
Check or clear the check boxes on the choose counters screen to select counters to monitor on this server.
Note: Due to the large amount of metrics that are being retrieved when displaying the entire SAP metrics browse tree during monitor definition, there could be a noticeable delay going from the "choose server" page to the "choose counters" page (possibly 1 to 2 minutes). However, once a browse tree has been successfully retrieved it will be cached to file automatically, so that the next time you retrieve metrics from the same server/username the wait time will be greatly reduced.

Update every
Select how often the monitor should check the SAP server. The default interval is to run or update the monitor once every 10 minutes. Use the drop-down list to the right of the text box to specify another update interval in increments of seconds, minutes, hours, or days. The update interval must be 15 seconds or longer.
Title
Enter a title text for this monitor. This text is displayed in the group detail page, in report titles, and other places in the SiteScope interface. If you do not enter a title text, SiteScope will create a title based on the host, server, or URL being monitored.

Advanced Options
The Advanced Options section presents a number of ways to customize monitor behavior and display. Use this section to customize error and warning thresholds, disable the monitor, set monitor-to-monitor dependencies, customize display options, and enter other monitor specific settings required for special infrastructure environments. The options for this monitor type are described below. Complete the entries as needed and click the Add or Update button to save the settings.
Disable
Check this box to temporarily disable this monitor and any associated alerts. To enable the monitor again, clear the box.
Verify Error
Check this box if you want SiteScope to automatically run this monitor again if it detects an error.
Update Every (on error)
You use this option to set a new monitoring interval for monitors that have registered an error condition. For example, you may want SiteScope to monitor this item every 10 minutes normally, but as often as every 2 minutes if an error has been detected. Note that this increased scheduling will also affect the number of alerts generated by this monitor.
Schedule
By default, SiteScope monitors are enabled every day of the week. You may, however, schedule your monitors to run only on certain days or on a fixed schedule. Click the Edit schedule link to create or edit a monitor schedule.
Monitor Description
Enter additional information about this monitor. The Monitor Description can include HTML tags to control display format and style. The description will appear on the Monitor Detail page.
Report Description
Enter an optional description for this monitor that will make it easier to understand what the monitor does. For example, network traffic or main server response time. This description will be displayed on with each bar chart and graph in Management Reports and appended to the tool-tip displayed when you pass the mouse cursor over the status icon for this monitor on the monitor detail page.
Depends On
To make the running of this monitor dependent on the status of another monitor or monitor group, use the drop-down list to select the monitor on which this monitor is dependent. Select None to remove any dependency.
Depends Condition
If you choose to make the running of this monitor dependent on the status of another monitor, select the status condition that the other monitor or monitor group should have in order for the current monitor to run normally. The current monitor will be run normally as long as the monitor on which it depends reports the condition selected in this option.
List Order
By default, new monitors are listed last on the Monitor Detail page. You may use this drop-down list to choose a different placement for this monitor.

CCMS Monitoring Authorizations

A SAP user requires certain privileges to read CCMS metrics. When defining a SAP CCMS monitor in SiteScope you must specify a user who has XMI autorization to be able to login to the CCMS server and retrieve metrics. Authorizations are collected in SAP profiles, and the following profiles include XMI authorization:
· S_A.SYSTEM
· PD_CHICAGO
· S_WF_RWTEST
· SAP_ALL
Again, when defining a SAP CCMS monitor in SiteScope you must specify a user who has one or more of these profiles assigned to it. One way to test if a user has such authorization is to try and issue transaction RZ20 in the SAP GUI and see if the CCMS monitor sets can be displayed.

CCMS Monitor - Software Requirements

About the SAP CCMS Monitor
The SAP CCMS Monitor allows you to monitor the performance data for various components of your SAP R/3 landscape. You can monitor multiple parameters or counters with a single monitor instance. This allows you to watch server loading for performance, availability, and capacity planning.
With SAP's Computer Center Management System a SAP administrator can monitor all servers, components and resources in the SAP R/3 landscape from one centralized server, greatly facilitating not only problem discovery but also problem diagnosis. Using SAP's new advanced CCMS interface BC-XAL 1.0, this new SiteScope monitor exposes hundreds of performance and availability metrics that the existing SiteScope SAP monitor did not have access to. The error and warning thresholds for the monitor can be set for up to ten of the nearly 120 SAP server performance statistics available.
This monitor only retrieves and displays numeric metrics (Performance attributes). That is, Status, Log and Information attributes are currently not supported. Also, presentation and management of SAP CCMS Alerts in SiteScope are not supported at this time.

About scheduling this monitor
The default run schedule for this monitor is every 10 minutes, but you can change it to run more or less often using the Update every setting. Note, however, that CCMS metrics are generally only updated once every 5 minutes.

Software Requirements
· The SAP CCMS Monitor requires that the SAP Java Connector (SAP JCo 2.0.10) component be downloaded from the SAP Service Marketplace Software Distribution Center, and installed on the same server where SiteScope is running (or at least be accessible on a shared or remote location).
· The BC-XAL 1.0 interface is supported on R/3 systems 4.5B and above only.
· Consult your SAP documentation to determine if your R/3 landscape components may need additional software installed to run or work with CCMS.

To integrate SiteScope with the SAP Java Connector
1. Using a Web browser, go to the online SAP Software Distribution Center at:
http://www.service.sap.com/connectors
Note: You will need a valid Service Marketplace login to access this site.
2. Click "SAP Java Connector", "Tools and Services".
3. Download and install the SAP Java Connector for the SiteScope platform you will use to monitor the SAP metrics. Follow the installation instructions included with the SAP JCo download to install the files on the server where SiteScope installed or where they are accessible to the SiteScope process.
4. Set environment or system variables on the server where SiteScope is installed to define the location of the SAP Java Connector libraries. Use the following steps based on the platform used to run SiteScope.
On Windows platforms, you add the SAP Java Connector installation location in the System Environment PATH variable rather than as a User variable. This change usually requires you to then reboot Windows in order for the system PATH to be updated.
On UNIX platforms, the best way to make the shared objects accessible to SiteScope is to edit the start-monitor file supplied with SiteScope. This file is found in the /SiteScope/classes/start-monitor directory.

To modify the start-monitor file on SiteScope for UNIX:
a. Open the start-monitor file with a text editor
b. Locate the following line with the load library variable: LD_LIBRARY_PATH= and add the location of the SAP JCO shared libs (*.so) to load library path as follows:
LD_LIBRARY_PATH=
c. Save the changes to the file

5. After you have installed the SAP Java Connector download, find the file sapjco.jar in the location where you installed the download. Copy the sapjco.jar file to the /SiteScope/java/lib/ext directory on the SiteScope server:
6. Stop and restart the SiteScope service or process.

CCMS Monitoring : Creating and Changing Monitors

You can quickly and easily create your own monitors that meet your own specific requirements. If, for example, you want to monitor the relationship between your CPUs, operating system paging, and the dialog response time of your SAP systems, you can create an alert monitor that contains only these monitoring tree elements (MTEs). You can decide whether this monitor covers one or more systems.
To be able to create a monitor, first create a tree structure. You have the following options for the individual nodes:
· Static MTE Selection
You can explicitly select MTEs for your monitor. Only the selected MTEs are added to the monitor, and the selection of the MTEs is not updated.
· Rule-Based MTE Selection
You can also use rule-based MTE selection (dynamic selection) to create your monitor. In this case, the alert monitor includes all MTEs that fulfill a certain rule in your monitor. If the MTEs that meet this rule change, the system automatically updates your monitor. In this way, your monitor is automatically updated if a new system is added to the alert monitor.
You can combine both static and rule-based MTE selection in the same monitor.
· Virtual MTEs
You can define virtual MTEs to structure your monitor. Virtual nodes are used as titles or labels in the alert monitor. They have no function other than to group monitoring tree elements visually. For example, you can create virtual MTEs as titles for different groups of real MTEs in your monitor.

To be able to create or change a monitor, you must first activate the maintenance functions.

Procedure
1. Choose CCMS ->Control/Monitoring -> Alert Monitor, or call transaction RZ20.
2. Choose Extras -> Activate Maintenance Functions.
3. Choose one of the functions from the below list:
Create monitor
Choose the monitor set in which you want to create the monitor; ensure that it is a monitor set that you can modify ( ); choose Monitor (set) -> Create ( ).
Change monitor
Expand the monitor set and choose the monitor that you want to change. Choose Monitor (set) -> Change ( ).
You can also change a monitor that has already been started by choosing Monitor -> Change ( ).
4. The alert monitor displays the complete monitoring tree. The system displays the name of the monitor in the top line of the tree. You can now either add MTEs to your monitor or display the properties of existing MTEs. To do this, choose one of the functions from the table:

Insert static MTE selection
Select the desired MTEs from the list of Selectable MTEs . Only the selected MTEs will be visible in the completed monitor. The system displays the list at every point in the monitoring tree where you can insert statically created MTEs.
Insert rule-based MTE selection
Choose the node under which you want to insert a rule-based node; choose Edit -> Create Node ( ) and, on the Create Node screen, choose the Rule Node radio button
Insert a virtual MTE
Choose the node under which you want to insert a virtual node; choose Edit -> Create Node ( ) and, on the Create Node screen, choose the Virtual Node radio button. Enter a name for the node.
Change node
Select the relevant node; choose Edit -> Change Node ( ). You can change different properties, depending on the type of the node.
Display node
Select the relevant node; choose Edit -> Display Node ( ). The system displays different properties, depending on the type of the node.
Delete node
Select the relevant node; choose Edit -> Delete Node ( ). The node is deleted, along with its subnodes.

The following rules apply to the sequence of nodes in the monitoring tree:
· The root node (top node) of a monitor is always a virtual node. Its name is the name of the monitor.
· You can create as many layers of virtual MTEs as you wish. A virtual node can only be placed under a rule node or another virtual node in the tree hierarchy.
· A rule node can only be placed under a virtual node or another rule node in the tree hierarchy.
· A static node can only be placed under a virtual node.

5. Save your monitor by choosing Monitor Definition ® Save or Generate Monitor ( ). If you are creating a new monitor, the system prompts you to enter a name for your monitor.

CCMS Monitoring : MTE Classes and Attribute Groups

The alert monitoring tree consists of individual monitoring tree elements (MTEs). They are either components of your IT landscape that are to be monitored (monitoring objects), or values, statuses, or texts that are reported for these objects .These MTEs are assigned to MTE classes and attribute groups in the monitoring architecture:
· An MTE class describes the general properties and method assignments that are common to a particular group of monitoring tree elements.
· An attribute group describes the common threshold values for alerts for a particular attribute type.

MTE classes and attribute groups simplify the Customizing of the Alert Monitor, since you do not need to change threshold values, properties, or methods individually for every MTE, but only for the corresponding attribute group or MTE class.
MTE classes also simplify the creation of your own rule-based monitors, since you do not need to specify every MTE individually when constructing the alert monitoring tree, but rather only the corresponding MTE classes.
The classification of the MTEs to MTE classes and attribute groups is already fully predefined. You do not need to make any changes to be able to use this classification.

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

· MTE Class:
The Space Management monitoring object and the Free Space monitoring attribute both belong to the MTE class CCMS_DB_Freespace_MT. This means that both MTEs have the same general properties and method assignments.
· Attribute Group:
All instance-specific occurrences of the Response Timemonitoring attribute belong by default to a single attribute group. This means that the same threshold values are set in all of the instances of a system and that changes to the threshold values apply to all instances.

SAP Notes for Security

SAP Note 2467
Password rules & preventing unauthorized logons

SAP Note 4326
No user with super user authorizations

SAP Note 37724
Customer exits in SAP logon

SAP Note 40689
New reports for the User Information System

SAP Note 68048
Deactivating the automatic user SAP*

SAP Note 103019
SAPshortcut: Program parameter

SAP Note 142724
Prevention of multiple dialog logons

SAP Note 177895
Refitting the mySAP.com Single Sign-On capability

Creating new Superuser and Deactivating SAP*

To make sure that nobody can misuse the standard user SAP*, you should define a new superuser and deactivate SAP* in all clients that exist in table T000.

Do not delete the user SAP*! SAP* is hard-coded in AS ABAP systems and does not require a user master record! If a user master record for SAP* does not exist in a client, then anybody can log on to the AS ABAP as the user SAP* using the well-known password PASS. In this case, SAP* is not susceptible to authority checks and has all authorizations. Therefore, do not delete SAP* from any client.

Procedure
1. Create a user master record for the new superuser.
2. Assign the profile SAP_ALL to this super user.
3. Change this user’s initial password.
Make sure only a limited number of persons have access to this user’s password. Write it down, lock it in a safe, and use it only in emergencies! If you do have to use this super user, then make sure you change its password again after use.
4. If no user master record for SAP* exists in the client, then create a user master record for SAP*.
5. Assign the SUPER user group to SAP* (in all clients) to make sure that only authorized administrators can change its user master record.
6. Deactivate all authorizations for SAP* (in all clients) by deleting all of the profiles in the profile list.

Deactivating the Hard-Coded SAP* User
You can also deactivate the hard-coded user SAP* by activating the profile parameter login/no_automatic_user_sapstar. If a user master record was created for SAP*, then the corresponding authorizations assigned will apply; they are not affected by this parameter's setting.

SAP Note 68048.

Difference between Spool Request & Output Request

The SAP System differentiates between two types of request when printing:

● Spool request: A spool request is a document for which a print function has been selected. However, it has not yet been output to a printer or another device. The output data for the print document is stored partly formatted in a data store until an output request is created, that is, until it is sent to a particular output device.
The spool system uses a spool request to store the print data temporarily and to access it. The data is stored in a temporary format. You can also display the print document.
The system automatically assigns a 10-digit ID number to a spool request.

● Output request: From the point of view of the SAP spool system, an output request outputs the print data of a spool request to a particular output device.
Multiple output requests may exist for a single spool request. Each represents an instance of the output of the same spool request. Each of these output requests may have different attributes, such as the target printer or number of copies.

By differentiating between spool request and output requests, the spool system provides a means of storing the data temporarily.

Exporting the Contents of Spool Requests

You want to export the contents of a spool request in one of the following ways:
● As a text file to the SAP GUI working directory
● Unconverted or as a table, RTF, or HTML to a directory of your choice
● As a PDF file to a directory of your choice

Exporting to the SAP GUI Working Directory
If you are exporting large quantities of data, downloading the spool request as a text file to the SAP GUI working directory is a good solution.
Choose Spool Request -> Forward -> Export as Text.
The entire text is stored in your SAP GUI working directory in ASCII format.
A file of this type is named using the following pattern:
.txt
Example: ABC0000004327.txt
Note : You require appropriate authorization from your administrator for this function.

Exporting Unconverted or as a Table, RTF, or HTML to a Directory of Your Choice
The contents of the spool request are first displayed. You then download the contents in the format of your choice to a directory of your choice.
1. Select the spool request to be exported and choose Display Contents.
2. For SAPscript/Smart Forms documents, activate the list display by choosing Goto.
3. Choose System -> List -> Save -> Local File.
4. Select a format and confirm your choice.
5. Select a directory and save the spool request.
By default, only the first 10 pages of a spool request are saved in a file. You can increase the number of pages to be saved by choosing Goto -> Display Requests -> Settings and making the desired entries in the Display Area group box.

Exporting as PDF File
You want to export the contents of a spool request as a PDF file to a directory of your choice, and print the file. The PDF file contains the print data in the format in which it will be output by the printer.

The following procedure is irrelevant when printing PDF-based forms, since a PDF file is already returned with this method.
Note :You also require authorization from your administrator to run this report.

The PDF file is generated as follows with report RSTXPDFT4:
1. Generate a spool request from the document to be printed.
2. In transaction SE38, start report rstxpdft4.
3. In the displayed window, enter the spool request number and the directory in which
the PDF file is to be stored.
Leave the Download PDF File option selected. Choose Execute.
4. In the next window, confirm or change the path where the file is be stored.
Save your entries.
5. The system displays a log from which you can see whether the report was successfully
performed.
You can then open the file from the directory and print it.

Restrictions for Exporting as a PDF File
● The PDF conversion only supports true bar codes for Smart Forms, which were generated with the new bar code technology with SAP NetWeaver 2004. In all other cases, the bar code is only simulated.
● PDF conversion, especially of ABAP lists, is slower and is therefore not suitable for mass printing. However, you can speed up the conversion to PDF using the FASTLISTCONV option in report RSTXPDF3.
● The font selection for ABAP lists is predefined in the PDF converter and cannot be changed.
For more information about constraints, see SAP Note 323736 on the SAP Service Marketplace.

Recommendations for Logon Load Balancing and Logon Groups (SMLG)

SAP Logon Load Balancing
Logon load balancing increases efficiency with respect to performance and the use of system resources for variously defined workgroups by distributing users across available application servers based on requirements for workgroup service and utilization.
In a system landscape where there are multiple application server instances, specific servers are best assigned to a particular application workgroup, with the available resources and buffers of that server tuned specifically to that application and not shared with other applications. This is highlighted in the following sections:

Recommended:
With logon load balancing and servers assigned to specific applications:
Logon Group FI/CO - Server A FI/CO & Server B FI/CO

Logon Group SD - Server C SD & Server D SD

With logon load balancing and shared, or homogeneous, properties of servers across logon groups:
Logon Group FI/CO - Server A FI/CO,Server B FI/CO & Server C FI/CO

Logon Group SD - Server C SD,Server D SD & Server E SD

Not recommended:
With logon load balancing and servers available to all applications:
Logon Group PUBLIC - Server A FI/CO + SD,Server B FI/CO + SD,Server C FI/CO + SD,Server D FI/CO + SD

With only two servers with logon load balancing and servers assigned to specific groups:
Logon Group FI/CO - Server A
Logon Group SD - Server B

Logon Groups
Each SAP application has different resource requirements. Certain applications may therefore require more servers and logon groups. For example, you should assign separate servers for the application component PP.
Generally, each logon group should have two servers. If one server is not available, the users are automatically connected to the second server. Servers can be added or removed while the SAP system is running.
If it is not practical for you to assign separate servers to integrated applications such as the application components SD-MM and FI-CO, you should assign common logon groups to these applications.

SAP : Configuring Logon Groups (SMLG)

In SAP Logon, you can create and delete group entries, remove instances from groups, and delete entire logon groups.
When you call transaction SMLG, the CCMS: Maintain Logon Groups screen shows a table with entries for logon groups and the associated instances. An entry in this table, which is characterized by an instance and a logon group, is known as as assignment. A logon group to which multiple instances belong therefore consists of multiple assignments in this table, where an assignment contains one instance in each case.

Creating a Logon Group or Adding an Instance to a Logon Group
...
1. Choose CCMS -> Configuration -> Logon Groups, or call transaction SMLG.
2. Choose Create Assignment button, and specify the desired name of the logon group in the Logon Group input field. Enter the name of the desired Instance that is to belong to the logon group.
The logon group SPACE is reserved for SAP; therefore, do not use this name.
3. Repeat the last step until you have entered all instances that are to belong to the logon group.
4. Save your changes.

Deleting a Logon Group or Removing an Instance from a Logon Group
...
1. Choose CCMS -> Configuration -> Logon Groups, or call transaction SMLG.
2. Select any assignment for the logon group that you want to delete or from which you want to remove an instance.
3. To remove an instance from the selected logon group, choose Remove Instance, enter the desired instance on the next screen, and confirm your choice by choosing (Delete).
4. To delete the desired logon group, choose Delete Group and confirm your choice by choosing (Delete) on the next screen.
5. Save your changes.

Changing Properties of an Assignment, a Logon Group, or an Instance
...
1. Choose CCMS -> Configuration -> Logon Groups, or call transaction SMLG.
2. To change the properties of an assignment, double-click the assignment, and switch to the Properties tab page.
3. You can change the following properties:
○ IP address of the application server
Only enter a value in this field if the application server associated with the instance needs to be addressed by the front end with a different IP address to the one used for application server-internal communication. This value applies only for the selected assignment.
○ Settings for external RFC call
You can use this indicator to determine whether logon using an external RFC connection is to be permitted. This value applies to the selected logon group.
○ Threshold values for dialog response time and number of users logged on
If you log on using a logon group, the logon is automatically performed using the instance of the group that currently has the best dialog quality. This quality is a key figure that is calculated from the number of users logged on and the average dialog response time. To allow the different prerequisites of different instance to be taken into account in this calculation, you can set threshold values for the dialog response time and the number of users yourself. The larger the actual values for response time and the number of users are in comparison to the threshold values set, the lower the quality. These figures apply for the selected instance.
The values for Response Time and Users are not absolute limits, but rather thresholds. Even if the current value for response time or number of users is higher than this threshold value, it is possible to log on to another instance. The threshold values only influence the calculation of the current logon server of the logon groups.
You can use a preview to see how the settings of the threshold values can affect the quality calculation, based on the current performance data. Choose Test to do this. In a logon group, the instance with the highest quality key figure is always selected for the logon.
4. Choose Copy, and save your changes.

SAP Version Management

Creating Versions
The aim of version management is to record a complete change history of a Repository object. Versions are created automatically at the following times:
Before a Repository object is changed
Each object changed is entered in a change request. If the latest version in version management is not the active version, the version of the object is saved in version management before it is changed. These backup versions are indicated in the version overview with an S or I.
When a change request is released
When you release the change request with the changed objects, versions are created. The request number is displayed in the version overview for the relevant version.
A version is not created when objects are imported for performance reasons. This is not necessary, since the change history of the object was recorded fully in the development system. However, a comment is added to the version overview if an object has changed as the result of an import.
If you want, you can create extra versions of objects during import. This makes sense, for example, if the development system is reinstalled at regular intervals. This leads to the loss of the versions recorded there.

As well as the times mentioned above, versions are also created at the following times:
Before the import
If the newest version in the version database does not match the active version, then a backup version is made immediately before the import. These versions are indicated in the version overview with an S.
After the import
After the import a version is created of each imported object. The number of the imported request is displayed in the version overview for the created version. If an object exists in several requests that are imported at the same time (for example, with tp import all ) only one version is made of this object, after the import of the final request.
You can use these versions to check what was the active status of an object at which time.
You can also set the SAP System so that versions are not created every time you import objects, just when you import objects as part of a relocation with package change. To do this, set the profile parameter VERS_AT_IMP to C_ONLY .
In addition to the versions created automatically, you can also create temporary versions at any time. To do this, use the Generate version function in the maintenance transactions for the Repository objects. You can use these temporary versions to restore the previous version of an object, even while you are developing it. When a request is released, the temporary versions are deleted and replaced by the version active at this time.


Version Management
You can use version management to compare two versions of a Repository object, and display old versions of objects.
You can access version management whenever you are maintaining an object by choosing Utilities ® Versions ® Version management.
You can also access version management from the Transport Organizer (Transaction SE09):
In the initial screen Choose Environment ® Version management. An overview of versionable objects appears. You can display individual object types and search for particular objects.
In the request overview Position the cursor on an object in the object list of a task or request and choose Object ® Versions.
The version display is object-specific and is similar to the display used in normal object maintenance. Object versions can therefore be easily recognized.

Version Overview
The version overview shows the versions stored in the development database (Repository), as well as the historical versions stored in the version database. Both areas can be empty, such as in the following situations:
An object has been newly created and no versions have yet been created.
An object was deleted after versions were stored
Active and/or revised versions are stored in the development database.
The version overview also provides information on the time and release level when the versions were created.
If a transport request is specified for a version in the version database, this version corresponds to the state of the object
when the request was released, if the request is from the current SAP System
or
after the request was imported, if the request with which the object was transported is from another SAP System.
If a request is specified for an active or revised version, the object is currently being edited in connection with this request, or has been imported with the specified request.
The Cat column in the version overview specifies the reason why the version was created. The following values are possible:

" " Version created when request was released
I Version created during import
S Version created due to a system request (for example, for a backup copy before inclusion in a correction or repair)
U Version was created due to a user request (as an intermediate version) at some point in time. When the request is released, these versions are deleted and replaced by a " " version.

The Fla column in the version overview specifies how the version is flagged. The following values are possible:

" " No special flag exists
I The version last created is not the active version, since the active version was overwritten by an import

In the version overview, you can choose the following functions:
Display a selected version
Compare two selected versions
Restore a selected versionThis function requires change authorization for the Repository object concerned.
Remote comparison with versions of the object in another SAP System

Authorizations in Version Management
The authorization for accessing version management is covered by the authorizations for the ABAP Workbench and the Transport Organizer. It is only for the remote comparison with other SAP Systems that you require a special authorization.
To compare versions of with a remote system, use the user TMSADM, delivered by SAP. This user requires the authorization S_TMSADM_SHO (display authorization for Repository objects) in the remote system. This authorization is in the SAP authorization profile S_A.TMSADM of the user TMSADM.
If the user TMSADM does not have this authorization, then a logon screen appears when you use the remote version comparison. You can enter user and password on this screen. The user that you enter must have the authorization for displaying Repository objects. Otherwise the SAP System rejects the remote comparison.
The user SAPCPIC is used for the remote comparison with SAP Systems which have a release prior to 4.5A. The calling SAP System must have an RFC destination, in which the user is SAPCPIC is entered with the corresponding password.
This user requires the authorization S_RFC_VERS in the target system. This authorization is delivered by SAP in the authorization profile S_A.CPIC of the user SAPCPIC.
If you want to prevent a remote version comparison with a particular SAP System, then delete the authorization S_TMSADM_SHO from the profile S_A.TMSADM and the authorization S_RFC_VERS from the profile S_A.CPIC in the system in question.
To allow the remote comparison again, just add these authorizations to the appropriate profiles.


Archiving Versions
Prerequisites
If the version management data tables VRSX and VRSX2 take up too much space on the database, SAP recommends that you start archiving versions.
Archived versions are displayed in the versions overview, and are marked with an X in the column Arch.
If you choose the options Display or Compare for an archived version the SAP System restores the selected versions from the archive to the database, and then displays them.
You can also restore the complete archive files to the version database.
Archived versions can only be restored to the SAP System from which they were archived.
Procedure
To archive versions, or restore complete archive files from the database, proceed as follows:
1) In the SAP Easy Access menu, choose SAP Menu -> Administration -> System Administration -> Administration -> Data Archiving.
2) Enter the archiving object VERSIONS

SAP CCMS Monitoring & Agents

In the CCMS Alert Monitoring Infrastructure delivered by SAP, data collection programs monitor various components.
Each program stores the data in a “monitoring segment” (part of the shared memory of each server) using either a running SAP instance or a running agent. A dedicated central monitoring system, or CEN, accesses the locally collected data through a defined ABAP interface on an SAP instance, or through agent technology on any server on which the agent is installed and active. With the CEN, administrators now have a central overview for monitoring and managing the entire mySAP.com e-business platform from a single console, without logging on to each and every component.

To access this information, SAP provides two monitors for visual display.
1) The CCMS Alert Monitor (transaction RZ20) is the expert monitor currently available for administrators. It provides a customizable, system-wide overview of the system landscape. From RZ20, you have a guided connection to remote systems in case of an alert.

The CCMS Alert Monitor has the following advantages:
· Automated, central monitoring that only requires you to carry out administration tasks when an alert occurs
· Proactive monitoring by means of alerts that are triggered as soon as a particular threshold value is not reached, or is exceeded
· Support when solving problems by means of pre-defined analysis functions with which you can resolve the cause of an alert in a particular component
The CCMS Alert Monitor offers the following functions:
Displays any error alerts occurring in the TMS or when exporting requests; it organizes the alerts by topic in a tree structure.
Analysis method for each alert
Option of setting alerts to completed
Alerts are visible as long as they have not been completed (completed alerts are visible in the history).
The CCMS Alert Monitor includes all systems in the current system landscape.

2) The CCMS Alert Monitoring Infrastructure also acts as an information source for the second monitor, the SAP Solution Manager. This new platform for support and services analyzes and presents system monitoring data in a modern, graphical frontend geared particularly to business processes.

With the new CCMS agent software, SAP makes central monitoring possible where it didn’t exist before — and enhances the monitoring tasks that are currently available.
CCMS agents are stand-alone processes that act as RFC servers to the CEN. As such, they provide a reliable interface to the shared memory segment.There are three CCMS agents — SAPCCMSR, SAPCCM4X, and SAPCM3X — and each has a specific monitoring function, designed for a particular system, whether SAP or non-SAP.

Advantages of the agent concept include:
Faster Data Delivery
The monitoring segment contains all SAP data from the CCMS Alert Monitoring Infrastructure.This data can be transferred by SAPCCM4X agents without occupying an SAP work process. As a result, your monitors in the CEN will open much faster.

Detailed Operating System Data
On systems without SAP Basis, the SAPCCMSR agent can return the SAPOsCol2 data (e.g., CPU utilization, paging rates, file system data, network data). Administrators can now monitor individual operating system processes like those in Figure 1, which displays the monitoring data of the APOsCol
and SAPRouter processes. Important information can be updated as frequently as every minute, and you can design a monitor in the CEN to provide detailed information concerning non-SAP hosts

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 CEN.

Auto-Reaction Methods
If an alert is triggered in a monitored system, an auto-reaction of your choice can also be triggered. (Until now, auto-reactions were only processed in the same system where the alert occurred.) If the CEN is an SAP Web Application Server 6.10 or later, the agents can transfer the local alert information to the CEN, where an auto-reaction can be generated. The agent to send alert information immediately to the CEN (as of Web Application Server 6.10 and up), which can then automatically react with central auto-reactions or e-mail notifications — resulting in less time spent waiting in the CEN while opening monitors.

Integration Characteristics
Agents can write alerts to a log file, which third-party software products can easily access and respond to appropriately.

Database Administration in CCMS
The advantage of using CCMS is that you have a central point for managing your database. You also get the full advantage of the SAP System graphical user interface (GUI), for example, when displaying space usage in your database.
The main functions for DBA in CCMS are as follows:
DBA Planning Calendar
Update statistics, using the cost-based optimizer
Database System Check
Database Monitor
Database Alert Monitor

LiveCache Monitoring (LC10)

In a liveCache application (such as an APO system), you should not just analyze the application at regular intervals, but also liveCache itself, to detect and avoid bottlenecks. The following problems in the liveCache environment can cause bottlenecks:
· Unsuitable hardware
· Incorrectly configured memory areas
· Algorithm errors in the DB procedures or the liveCache kernel
· Unsuitable parameter settings
Use the functions of the Computing Center Management System (CCMS) in the SAP system to monitor liveCache. The CCMS provides you with the following tools:
· liveCache Assistant
· liveCache Alert Monitor

In the user menu, choose liveCache Assistant (transaction LC10).
Enter the name of the database connection. You can predefine the name of a database connection with a default value. This name appears when you start the liveCache Assistant for the first time. If you call the liveCache Assistant again in a database session, the name of the last used database connection is always displayed.
You can choose between the following functions:
· Integration
· liveCache: Monitoring
· liveCache: Console
· liveCache: Alert Monitor

Determining the liveCache Status

Name of the database connection
This name is displayed when transaction LC10 is first called. If transaction LC10 is called after this during a database session, the name of the last-used database connection is always displayed.

liveCache name
The physical name of the liveCache is a property of the liveCache.The liveCache name is the name of the database instance on the liveCache server. The liveCache name can vary from the name of the database connection.

liveCache server
The name of the liveCache server is a property of the liveCache.The name of the liveCache server is case-sensitive. You can also use the IP address of the liveCache server.You can change specifications for liveCache server using the liveCache integration.

liveCache version
The version of the software of the liveCache kernel is a property of the liveCache.

liveCache state
The current operational state of a liveCache is a property of the liveCache.
· Green: The liveCache is operational (operation state ONLINE) and users can log on.
· Yellow: The liveCache is only available for the administrator for administrative purposes (operation state ADMIN).
· Red: The liveCache is not operational (operation state OFFLINE).

Procedure
Use the Properties display in the liveCache Assistant.
Use the displays State and Installation in the liveCache Alert Monitor.