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
Sunday, July 27, 2008
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.
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.
● 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
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.
● 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:
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.
Wednesday, July 9, 2008
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.
Friday, July 4, 2008
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
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
Thursday, July 3, 2008
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.
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
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
Subscribe to:
Posts (Atom)