Middleware Monitoring

Best Practice for Solution Management: CRM 4.
0 Monitoring
CRM 4.0 Monitoring

Best Practice for Solution Management
Version Date: June 2005

The newest version of this Best Practice can always be
obtained through the SAP Solution Manager
Contents
Applicability, Goals, and Requirements ....................................................................................................2
Best Practice Procedure and Verification .................................................................................................4
Preliminary Tasks ...............................................................................................................................4
Procedures .........................................................................................................................................4
Monitoring for Component Middleware ........................................................................................4
Monitoring for Component J2EE engine ................................................................................... 33
Monitoring for Component Internet Communication Manager (ICMAN).................................. 39
Monitoring for Component Mobile Client.................................................................................. 47
Monitoring for Component Groupware-Connector................................................................... 55
Monitoring for Component Roll-out Manager........................................................................... 57
Monitoring for Component Intelligence Connector................................................................... 59
Monitoring for Component SAPphone ..................................................................................... 61
Monitoring for ISA Web Applications ......................................................................................... 66
Monitoring the IC Web Client .................................................................................................... 68
Monitoring for Component CRM Broadcast Messaging Server............................................... 74
Monitoring for Component ICSS ............................................................................................... 77
Monitoring for Component TREX .............................................................................................. 79
Monitoring for Component CRM-IPC ........................................................................................ 84
Monitoring for Component IC Workforce Management ........................................................... 92
Monitoring for Component Content Server .............................................................................. 96
Monitoring for Component CAT Server .................................................................................... 98
Monitoring for Component MapBox .......................................................................................... 99
Further Information .............................................................................................................................. 100
2005 SAP AG 1
Best Practice for Solution Management: CRM 4.0 Monitoring
Applicability, Goals, and Requirements

Consider the following goals and requirements to ensure that this Best Practice is the one you need.
Goal of Using this Service

This Best Practice explains how to setup and use monitoring in a mySAP CRM System landscape.
Both Alert Monitoring using the SAP Computer Center Management System (CCMS) and manual
monitoring methods and procedures are described.
Monitoring transactions and tools as well as trace and log files are described in detail.
The monitoring architecture, a solution within mySAP Technology, centrally monitors any IT
environment - from individual systems through networked SAP solutions to complex IT landscapes
incorporating several hundred systems. It is included in every SAP solution and can be used
immediately after installation. You can easily extend the architecture to include SAP and non-SAP
components.
Alerts form a central element of monitoring. They quickly and reliably report errors such as values
exceeding or falling below a particular threshold value or that an IT component has been inactive
for a specified period of time. These alerts are displayed in the Alert Monitor which reduces the
workload for system administrators since they only need to respond to error conditions based on pre-
defined thresholds rather than sifting through masses of cryptic system data.
The Alert Monitor is therefore the central tool with which you can efficiently administer and monitor
distributed SAP solutions or client/server systems.
2005 SAP AG 2
Alternative Practices
Individual SAP installation and administration handbooks, SAP Notes, OEM documents and other such
documents may also be used instead of this Best Practice.
We have tried to draw together the monitoring-relevant information from all these sources into this Best
Practice. Additionally, experiential input from SAP Active Global Support consultants and thousands of
remote performance service sessions enhance the added-value of this Best Practice over the standard
SAP documentation.
Staff and Skills Requirements

The target groups for this document are system administrators, SAP Basis Technology consultants and
anyone else who would like a detailed overview of the monitoring best practices used in SAP Active
Global Support.
This Best Practice is not conceived as a apply once and forget procedure.
It is meant to be used as a reference for the initial setup of monitoring and as a supplement to the
customer-specific Operations Handbook for daily use.
The procedures and methods described here are meant to be applied according to the customer-specific
business scenarios in use. Many customers have their IT teams split according to functional area and so
parts of this document will have relevance according to how the IT team in an organization is structured.
Please refer to the subsection Background Information in the section Further Information for more
information.
System Requirements
This Best Practice is focused on the components comprising a mySAP CRM release 4.0 solution scenario.
System requirements are dictated by the scenario used in a customers solution landscape.
Duration and Timing

The duration and length of time required to implement this Best Practice is dependent on the size and
scope of the customers solution landscape and business scenarios.
Therefore it is not fitting to assign a value for the project duration for the implementation time required.
Generally if all components are installed, setup and fully customized the implementation time is relatively
short. Training IT-personnel in using the monitors and how to react to critical alerts requires more time.
Implementation of the SAP Solution Manager can tie-together the monitoring across the solution
landscape and thereby streamline the monitoring and save customer manpower and time.
2005 SAP AG 3
Best Practice Procedure and Verification
Preliminary Tasks
Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in
the system:
Complete all installation and post-installation actions and procedures including customizing
Ensure that the initial download has been successfully executed
Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations resulting
from customer problem messages
Implement all current SAP Support Packages upon availability
Procedures
Monitoring for Component Middleware

The CRM Middleware is used to transport business objects coming from R/3 or other sources into the
CRM online database and afterwards to distribute this data to external receivers, defined through
customizing. The business objects are stored in BDocs and transported by the Middleware. QRFC and
TRFC are used at the technical-level for these asynchronous, secure and re-processable transports. The
following section describes monitoring for CRM Middleware, qRFC and tRFC.
Alert monitoring for Middleware

Basics
The CRM Middleware Alert Monitoring was implemented based on the CCMS Alert Monitoring
infrastructure. It can be called via Transaction RZ20 where it is available under the "SAP CRM Monitor
Templates" monitor sets with the name "CRM". The CRM Middleware Alert Monitor observes the most
important processes within the CRM Middleware and generates alerts if critical situations occur. The
processes are displayed in a tree structure in the monitor and alerts are assigned to the nodes of the
corresponding processes.
For additional information on the individual processes use the F1 help for each node in the monitoring
tree.
The most important topics of the middleware as monitored by CCMS are:
Processing of the CRM-specific qRFC inbound and outbound queues in the CRM System
Processing of the CRM-specific qRFC outbound queues in the OLTP R/3 System
Processing of the "Replication & Realignment" queues
Processing the BDoc messages in the flow
2005 SAP AG 4
CRM Middleware Monitoring Cockpit

Transaction SMWP (CRM Middleware Monitoring Cockpit) is a centralized monitoring tool which is
partially based on CCMS-input from SAP CRM Monitoring Template CRM Middleware for
Replication/Realignment-, BDoc and QRFC-monitoring. This CCMS-monitoring template is preconfigured
as part of the installation.
Replication and realignment queues

Replication and realignment queues (transaction SMOHQUEUE) are monitored for the following
properties:
Queue demon status
Alerts are triggered when the demon is in status HOLD (with and without errors) and/or
status STOPPING.
Auto reaction methods can be defined.
Number of queue entries
YELLOW alert is issued when the AC and SU (all other) queues have more than 2000 entries.
RED alert is issued if the AC and SU (all other) queues have more than 10,000 entries.
An auto-alert method (email, pager, cellular) can be triggered both for yellow and red alerts.
Queue status
Alerts are triggered when the queue is in status HOLD (with and without error) and/or
status STOPPING.
Auto reaction methods can be defined.
Processing Status of BDoc Messages

The status of BDoc messages (transaction SMW01) is automatically monitored per client.
Here you find alerts for
BDocs in error status
BDocs which are waiting for response
It shows, which BDoc message type is failing or waiting and how often.
Alert monitoring for qRFC communications can be reached using the CCMS transaction, RZ20, as follows:
RZ20 SAP CRM Monitor Templates CRM Queue Info CRM qRFC Queues
Outbound Queues
Inbound Queues
QIN Schedulers
QOUT Schedulers
For more information on the individual processes, use F1-help for the node in the monitoring tree.
Transaction RZ21 can be used for making changes to the SAP standard settings used in the CCMS.
The following pages describe the methods and procedures for monitoring the CRM specific qRFC
communications in the CRM and R/3 Systems both using CCMS Alert Monitoring and using manual
methods.
2005 SAP AG 5
Note: In an SAP implementation using qRFC with outbound queue and/or qRFC with inbound queue the
following will help to clarify the terminology used:
Sending system = client system = calling system = source system
Receiving system = server system = called system = target system
These terms are often used in different contexts and are important to differentiate from one another.
CCMS Alert Monitoring for qRFC Communications in the CRM System:

Outbound qRFC queues in the CRM System are monitored in CCMS for the following
(see also transaction SMQ1):
Blocked queues per SAP client
o RED alert is triggered when the queue is stopped for whatever reason
o Auto reaction methods can be defined
Number of queue entries per SAP client
o YELLOW alert is issued when the number of queue entries reaches 500,000
o RED alert is issued when the number of queue entries reaches 1,000,000
Mobile client queues that have not been processed
o YELLOW alert is issued if a mobile client queue is older than 2 days and has not been
processed
Inbound qRFC queues in the CRM System are monitored in CCMS for the following
(see also transaction SMQ2):
RED alert is triggered when the queue is stopped for whatever reason
Auto reaction methods can be defined
YELLOW alert is issued when the number of queue entries reaches 500,000
RED alert is issued when the number of queue entries reaches 1,000,000
Inbound Queue Scheduler is monitored in the CRM System using CCMS for the following
(see also transaction SMQR):
QIN Scheduler Errors (for all SAP clients)
YELLOW alert is issued for queues having status CPICERR, STOP, WAITSTOP,
WAITING or ARETRY
RED alert is issued for queues having status SYSFAIL or ANORETRY
QIN unregistered queues (for all SAP clients)
YELLOW alert is issued for unregistered queues
2005 SAP AG 6
Outbound Queue Scheduler is monitored in the CRM System using CCMS for the following
(see also transaction SMQS):
QOUT Scheduler Errors (for all SAP clients)
YELLOW alert is issued for destinations having status CPICERR, STOP, WAITSTOP,
WAITING, ARETRY, WAITUPDA
RED alert is issued for destinations having status SYSFAIL or ANORETRY
RED alert is issued for destinations that have had status RUNNING or EXECUTED for
more than 30 minutes
CCMS Alert Monitoring for qRFC Communications in the R/3 System:

Monitoring qRFC queues in the R/3 System is similar in basic functions as in the CRM System as
described above except the inbound queue is not normally monitored in R/3.
The CCMS / RZ20 menu path is as follows:
RZ20 SAP CCMS Monitor Templates Communications Transactional RFC and
Queued RFC
Outbound Queues: Blocked queues
QOUT Scheduler: Errors (for all SAP clients)
ARFCSSTATE: Outbound tRFC Calls with status
CPICERR
SYSFAIL
SYSLOAD
Outbound qRFC queues in the R/3 System are monitored for the following (SMQ1):
RED alert is triggered when the queue is stopped for whatever reason
YELLOW alert is issued when the number of queue entries reaches 500,000
RED alert is issued when the number of queue entries reaches 1,000,000
Outbound Queue Scheduler, SMQS, is monitored in the R/3 System for the following:
QOUT Scheduler Errors (for all SAP clients)
YELLOW alert is issued for destinations having status CPICERR, STOP, or WAITSTOP
RED alert is issued for destinations having status SYSFAIL
2005 SAP AG 7
The AFRCSTATE table is monitored in the R/3 System for the following:
RED alert is issued upon status CPICERR, SYSFAIL or SYSLOAD
Setup
The Middleware Alert monitoring is delivered preconfigured and installed as part of the CRM and R/3
installation procedures.
Auto reaction methods can be setup as described in SAP note 420661, section 3.
Auto-reaction methods can trigger emails, pager messages or faxes. Furthermore you can change the
alert thresholds for your own needs by using the properties-button.
Manual Monitoring
Overview Monitoring Tools
The below table lists the main monitoring transactions, their descriptions and recommended frequency of
use when manually monitoring the CRM and R/3 Systems:
Tool Description Frequency

SMWP Monitoring Cockpit Hourly
SMW01 Monitoring BDoc Messages Hourly /daily
SMW02 BDoc Message Summary On request
SMW02A BDoc Message Error Analysis Hourly /daily
SMW03 Unprocessed BDoc Messages Hourly /daily
SMWT Monitoring Middleware Trace On request
SMW00 Error Handling Customizing Once after installation/changing
SMWMFLOW Display Message Flow Statistic On request
SMO8FD Display and Check Flow After customizing changes
Definitions
SMOECK Check Replication Relevant After changes
Objects
SMOHQUEUE Replication/ Realignment Hourly
R3AM1 Monitoring Initial Load On Initial Downloading
R3AR3 Monitoring Load Requests On Loading
RSA7 BW Delta Queue Maintenance Daily
BWA7 BW Adapter Status Source Daily
SMQ1 qRFC Outbound Queue Monitor Frequency depends on the business process
for CRM and for R/3 Systems
Upon error
During particular loads (initial load or loads
causing mass updates)
2005 SAP AG 8
SMQ2 qRFC Inbound Queue Monitor Frequency depends on the business process
Upon error
If inbound queues are not being processed
SMQR Inbound Queue Scheduler Upon error

If inbound queues are not being processed
SMQS Outbound Queue Scheduler Upon error

If outbound queues are not being processed
SM58 TRFC Monitor Upon error

Check daily
Details of the CRM Middleware Monitoring Cockpit
Transaction SMWP
The CRM Middleware Monitoring Cockpit can be called using transaction SMWP on the CRM server.
What is monitored by transaction SMWP?

Transaction SMWP consolidates monitoring information from many key areas of the CRM System and is
structured in the following sections:
Generation information
Runtime information
System Settings
Monitoring Tools/Statistics
Background Jobs
Section Generation Information contains

Status of Generation Process (can be waiting or in error)
BDoc Types: Generation of structures
o Double click to get the list of BDoc types for which you can start the BDoc modeler SBDM
and check the generation log
BDoc Types: Generation of Runtime Objects
o Double click to get the list of BDocs with erroneous services and related functions, which
are, or are not, generated with errors
Replication Objects per Industry: Runtime Objects:
o Shows replication/realignment and extract objects per industry template that were
successfully generated, not generated or generated with errors
Publication Objects per Industry: Runtime Objects:
2005 SAP AG 9
o Shows publication objects per industry template that were successfully generated, not
generated or generated with errors
Missing indexes: Indexes with respect to the flow services and the replication model are proposed
and checked here.
Section Runtime Information contains
Message Processing Active:
Checks if BDoc processing is possible.
RED alert: a generation or an upgrade was not completed successfully and neither RFC-processing
nor online processing is possible without generating a dump.
Data exchange using qRFC Queues:
Shows the status of qRFC Queues and the status of the inbound and outbound schedulers.
The data is created by CCMS alerts and displayed here.
Double-clicking will jump to qRFC-monitoring and display details. Additionally, you will find the qRFC-
Outbound Queues of the SAP R/3-backend with their status.
Adapter status information:
o Initial Load Status:
Shows client specific status of the initial load provided by transaction R3AM1.
Possible statuses are waiting, running and aborted.
o Request Status:
Shows client specific status of Request load provided by transaction R3AR4.
Possible statuses are waiting, running and aborted.
o Inactive Objects:
Here you will find a list of processed, aborted, waiting inactive and running inactive
objects by double click on the numbers of objects behind the alerts.
o Parameters in OLTP backend:
Here you find the following settings for initial load in the backend
Whether the RFC-Destination from backend to the CRM System exists
CRM Default Entry for object load,
Parameter in table CRMRFCPAR (see note 5010192) that enables the backend
system to send all relevant updates into CRM
XML active for object load from backend
GREEN: data transfer between backend and CRM is done in XML
YELLOW: not XML
For details check notes 442277 and 487229.
Use Inbound Queues for object load from R/3 backend
GREEN: all objects use Inbound Queues
YELLOW: all objects do not use Inbound Queues
Entries in table CRMPAROLTP with consumer = CRM, see Note 350175,
CRM Middleware RR-Queues
o Status of the RR-Queue Demon:
GREEN: RR Queue Demon is running
RED: RR Queue Demon is not running
You can jump to transaction SMOHQUEUE by double click from here.
o Status of the RR-Queues (per client):
Shows the CCMS results of the AC-Extract, the Extract-Bulk, the Extract, the Realign and
the Subcheck Queue as
GREEN: RUNNING
2005 SAP AG 10
YELLOW: RELEASED
RED: ON HOLD
CRM Middleware BDoc messages in the Flow:
o Shows the CCMS-results for BDoc messages with error (statuses E1, E2, E4-E7) or
waiting (status O01) for response from receiver (for instance R/3-backend).
You can jump into transaction SMW02 from here by double click.
Section System Settings contains the number of defined receiver sites per site type.
Section Monitoring Tools / Statistics is displayed if the CRM relevant Monitoring Tools are switched on:
BDoc Type/ BDoc Service Workload Statistic
GREEN: active
YELLOW: not active
Monitors performance data of the BDoc flow and is only relevant if you want to check this data for
your productive system. The data are displayed using transaction SMWMFLOW by selecting
Message Service Kernel Application Statistic.
See section SMWMFLOW for how to start this monitor.
BDoc Message Flow Processing Statistics
GREEN: active
YELLOW: not active
Monitors performance data of the BDoc flow and is only relevant if you want to check this data for
your productive system. The data are displayed using transaction SMWMFLOW by selecting
Message/site/Queue Statistics.
Mobile Client Communication Statistics
GREEN: active (Background job is running)
YELLOW: not active or no data is available.
Monitors performance data of the Conntrans process and is only relevant for Mobile Scenarios if
you want to check this data for your productive system. The data are displayed using transaction
SMWMCOMM by selecting tab page Statistics.
Middleware Alert Monitor shows the status of the CCMS Monitor for Middleware.
GREEN: active, without alerts
YELLOW: not active
RED: active with alerts
Trace Status shows the status of the trace using transaction SMWTAD.
GREEN: active at SAP default trace level
YELLOW: the trace level is higher
Background Jobs
Monitors whether the background jobs necessary for the CRM Middleware are running.
o Middleware Reorganization (SMO6_REORG):
This job deletes Middleware Trace information, final processed BDocs and other
temporary traces. For scheduling this job see SAP note 206439.
GREEN: job is running
YELLOW: job is not running
o Collecting for Monitoring Cockpit:

Monitors the running of the background job SMWP_BATCH for status processing which
collects the information of generation and runtime steps in Monitoring Cockpit SMWP.
2005 SAP AG 11

o Collector for BDoc Message Statistic:
Report RSWM_BSTAT_COLECTOR collects information from BDoc message store for
transaction SMWMFLOW and for the Mobile Client Communication Monitor
SMWMCOMM.
o Check the Generation Status of the Objects:
Report GN_GENERATE_CHECK recognizes if a new generation of objects is necessary
in CRM Server.
o Periodic Background Generation
Report GN_WORKLIST_GENERATE starts the generation. The generation can be
monitored using transaction GENSTATUS.
RED: job is cancelled
o Administration Console Subscription Agent
Report SMO_SUBSCR_AGENT_EXECUTE_JOB is only necessary if you use the
subscription agent using transaction SMOEAC to automatically create subscriptions for
Mobile Clients. Green alert means, the Job is running, otherwise you will get a yellow
alert.
o Administration Console Site Scheduling The report
SMOE_SCHEDULING_EXECUTE_JOB can be used for deactivating Mobile Sites for a
certain time period (replacement rules, see transaction SMOEAC).
(De)activation of SMWP
The background job for generation and runtime steps using transaction SMWP can be activated by
clicking Schedule Background Job in the menu.
Verify that it is running by using menu path Utilities Background Collector.
Description of Using the Monitor SMWP

The sections of transaction SMWP should be checked periodically as follows:
Runtime information: check hourly
Generation Information: check daily
Monitoring Tools: check daily
Background Jobs: check daily
System Settings check after system setup and customizing changes
Relevant SAPNET-Notes
704543: Jump in the queues from SMW01 is incorrect
623479: Korrekturen CRM-MW-GEN zu CRM 4.0 SPxx (20.5.2005, not yet translated into English)
2005 SAP AG 12
Details for Monitoring Processing Status of BDoc Messages
Transaction SMW01
Transaction SMW01 is used on the CRM server to monitor the Processing Status of BDoc Messages.
What is monitored by transaction SMW01?

Transaction SMW01 is used to monitor the status of BDocs with respect to application and customizing
errors.
(De)activation of SMW01
Transaction SMW01 cannot be switched off.
Description of Using the Monitor SMW01

Search-functionality:
You can start the selection by BDoc type, Message ID or Creator as well as by BDoc State, Send and
Update time and Flow context.
A list of BDocs is displayed.
YELLOW status: BDoc in process
RED status: BDoc in error state.
Following information is displayed:
BDoc State
BDoc Type
Flow Context
Send date and time
Change date and time
Receive date and time
DISPLAY functionality:
Select BDoc Message Display Classic part
Select BDoc Message Display Extended part
Checking the data content:
Classic Part displays the complete data content for synchronization of BDocs and some fundamental
fields for messaging BDocs.
Extended Part displays the data of a messaging BDoc.
Both classic and extended parts can be shown as XML strings if necessary.
Checking the receiver list

Select BDoc Message Display Errors/receivers
Only external receivers are shown.
2005 SAP AG 13
Display the object links.

Select BDoc Message Display Object Links
Links between m-and s-BDocs can only be shown if there are really links available and they have not
been deleted by the maintenance job SMO6_REORG.
The standard variant of SMO6_REORG job deletes all that have been successfully processed and are
older than 8 days.
Alternatively, these links between m- and s-BDocs can be switched off by implementing note 691628.
With CRM 4.0, SP8, there is a Neighbourhood-functionality button available which shows you the
dependent m- and s-BDocs. This method is much more performance-enhancing than storing the data for
the earlier Link-functionality (which was switched off with note 691628).
Process- functionality:
Select BDoc Message Reprocess Delete
BE VERY CAREFUL CARRYING THIS OUT!
Deleting BDocs causes inconsistencies in business data which must be corrected afterwards.
Deleting a BDoc message means that the receiving system(s) will not be updated, thus creating
inconsistencies. Only delete BDoc messages when you are sure they are obsolete or can be
recreated by sending the application object again.
Select BDoc Message Reprocess Reprocess

Do not reprocess BDoc messages without checking for the possibility of overlapping effects,
overwriting actual data!
If newer BDoc messages for the same application object exist and have been fully processed,
reprocessing an older BDoc message may cause the current data to be overwritten by a BDoc
containing data from an older state.
Show Error/Receiver- functionality:

You can jump to Show BDoc msg errors / receivers by the appropriate button on top of the table.
The meaning of errors in different flow contexts and error states is explained in detail in Best Practice for
BDoc Message Analysis on service.sap.com.
Furthermore you can jump to the Show BDoc message Trace.
Here you can find some Message Flow Trace information which may help in analyzing errors.
This trace information is periodically deleted by the SMO6_REORG job if the BDocs are too old (deleted
after 7 days using the standard variant).
SAPNET-Notes
526853: BDoc errors in CRM
691628: Deactivating links between BDoc messages
2005 SAP AG 14
Details for Monitoring BDoc Message Summary
Transaction SMW02
Transaction SMW02 is used on the CRM server to monitor the BDoc Message Summary.

Transaction SMW02 can be used to display a summarized list of BDoc messages per state and context.

SMW02 can be used to get an overview of BDoc message errors per BDoc type, state and context.
For detailed information you can jump by double click to the appropriate SMW01 record.
Details for Monitoring BDoc Message Error Analysis
Transaction SMW02A
Transaction SMW02A is used on the CRM server to monitor the BDoc Message Error Analysis.
What is monitored by transaction SMW02A?

SMW02A produces a summarized list of BDoc messages per error type.
(De)activation of SMW02A
Transaction SMW02A cannot be switched off.
Description of Using the Monitor SMW02A

This transaction can be used to get an overview of BDoc message errors summarized per BDoc type and
error message. For detailed information you can jump by double click to the appropriate SMW01 records.
Details for Summary of unprocessed BDoc Messages
Transaction SMW03
The number of unprocessed BDoc messages per Message Type is shown using transaction SMW03 in
CRM server.

Transaction SMW03 gives you an overview of all unprocessed BDoc messages.
2005 SAP AG 15

SMW03 can be used to get an overview of unprocessed BDoc messages for planning further analysis.
Details of Monitoring Middleware Trace
Transaction SMWT
Transaction SMWT displays the Middleware Trace on the CRM server.
What is monitored by transaction SMWT?

The processing of a BDoc message within the Middleware Flow is traced step by step for each service.
As a result this trace can be checked using transaction SMWT.
(De)activation of SMWT
Transaction SMWT cannot be switched off.
Settings (like Trace levels etc.)

Trace levels for the different environments (e.g. Generation, or All Environments) can be maintained
using transaction SMWTAD. The default trace levels are Warning for All Environments and Detail
Level 2 for generation.
Description of Using the Monitor SMWT

Transaction SMWT displays a list of traced BDoc messages with their GUIDs, component and
subcomponent as well as program and user name. This information is linked to transaction SMW01 and
displayed in case of an error.
SMWT is used in case of special error analysis.
429423: CRM Release: General analysis in the initial load
Details of Error Handling Settings
Transaction SMW00
Transaction SMW00 displays the error handling customizing in the CRM server.

SMW00 shows the settings of the error handling for BDoc messages and sites.
2005 SAP AG 16
Transaction SMW00 cannot be switched off. If no customizing has been done, no error handling can take
place.

SMW00 is the customizing transaction for the error handler and has to be customized before Go Live.
Default actions to initiate when errors occur can be customized for special BDoc errors or Site Ids.
These actions could be workflow event after error, mail or a customer-defined function after error.
654186: Flow error handler does not display any error
Details of Display Message Flow Statistic
Name and Location/Transaction of SMWMFLOW

Transaction SMWMFLOW, Message Flow Statistic, is on the CRM Server.
What is monitored by transaction SMWMFLOW?

Transaction SMWMFLOW displays the performance statistics for BDoc messages in the Middleware Flow.
(De)activation of SMWMFLOW
Transaction SMWMFLOW can be activated by calling transaction SMWMFLOW Goto Activate
Statistics.
To activate the Kernel Application Statistics press the appropriate button, select change mode and flag
the Middleware Message Hub statistics in the table.
To activate the Middleware Message Flow Statistics select the appropriate button, then select Switch
ON for switching on. Afterwards you will see the green highlighted On in the screen.
Description of Using the Monitor SMWMFLOW

Using SMWMFLOW you can choose to get the performance statistics for BDocs either by Workload from
database or by Message Flow Statistics.
Workload from database
Select a specific server or all servers (Total) and select the time range. As a result you will get a list of
BDoc types with number of records, response time, CPU-, wait- and database time as well as the
requested Kbytes. This gives you an overview of which BDoc types have poor performance and where
processing time is spent.
To get a more detailed knowledge of the processing time consumed select a BDoc type and select button
Per Service. This produces a list of all services called from Middleware Flow to process the BDoc and
the appropriate time measurements per service. This gives a quick overview of where to start with
optimization if performance problems occur.
2005 SAP AG 17
These statistics can also be retrieved in a time range of previous minutes (Last minutes Workload).
Here specify how many minutes back to start the selection for the analysis.
Message Flow Statistics
These statistics are divided into Inbound and Outbound with the server and time range selection below
each in the selection tree. Any time range of interest can be selected. Outputs include BDoc-Type-, Site
Profile-, Queue Profile- and Time profile tabstrips.
The BDoc tabstrip shows which message type is processed and how often. There you find the name of
the synchronization BDoc, if there is any BDoc belonging to the Mobile Scenario, and the name of the
messaging BDoc. Times are shown for how long the BDoc spent in queues (total and average), in Inbound
Flow, in Mapping and in Messaging Flow in Total.
Similar statistics are seen per Site in the Site tabstrip and in the Time profile. The time profile shows it per
hour (for the days statistics) or per day (for the weekly statistics). For the days statistics the Single
Records Statistics including the BDoc ID and the exact processing time are displayed.
The Queue-Profile shows the average, maximum and total queue time and the number of BDocs
processed per queue.
Data of SMWMFLOW (like Logsize)

The data for transaction SMWMFLOW are stored in table MONI.
The job RSMWM_BSTAT_COLLECTOR condenses data hourly and deletes it after some weeks.
Details for Display and Check Flow Definitions
Transaction SMO8FD
Flow definitions are shown using transaction SMO8FD on the CRM server.
What is monitored by transaction SMO8FD?

The content of all flow definitions and the sequence of all services executed in a BDoc flow are shown
using transaction SMO8FD on the CRM server.
(De)activation of SMO8FD
Transaction SMO8FD cannot be switched off.
Description of Using the Monitor SMO8FD

By help of transaction SMO8FD you are able to check the consistency of a flow definition after
customizing changes.
Details of Check Replication Relevant Objects
Transaction SMOECK
The CRM server transaction SMOECK checks all replication relevant objects and their assignments.
Possible errors, such as incorrect assignments, objects that have not been deleted completely, and data
inconsistencies, are determined and displayed.
For the displayed objects, you can normally use the View Object pushbutton to call up the application that
can be used to troubleshoot the error displayed. This may be the Administration Console or the BDoc
Modeler.
2005 SAP AG 18
What is monitored by transaction SMOECK?

The Replication Objects, Interlinkages, Publications, Subscriptions, Sites, Employees, Organizations and
the Subscription Agent are checked for logical consistency.
(De)activation of SMOECK
Transaction SMOECK cannot be switched off.
Description of Using the Monitor SMOECK

The Replication Objects, Interlinkages, Publications, Subscriptions, Sites, Employees, Organizations and
the Subscription Agent are checked for logical consistency. Errors and warnings are displayed.
This transaction should only be used after customizing changes using transaction SMOEAC.
Details for Monitoring Replication/Realignment
Transaction SMOHQUEUE
The functioning of Replication/Realignment can be monitored using transaction SMOHQUEUE on the
CRM server.
What is monitored by transaction SMOHQUEUE?

Transaction SMOHQUEUE shows the status of the queue-demon as well as the status of the subscription
checker, the realignment-, extract- and AC-extract queue. Furthermore you can monitor the number of
entries in these queues and the degree of parallelization at runtime.
By clicking on the number of entries in a queue you can find more information about creation date of the
entry, sequence number, message type and root ID.
Clicking on the status line of a queue will change the status of the queue.
(De)activation of SMOHQUEUE
Transaction SMOHQUEUE cannot be switched off.
Description of Using the Monitor SMOHQUEUE

The transaction SMOHQUEUE is used to check the status of the queue demon, of subcheck, realignment,
extract and AC-extract queue.
453882: Parallel processing of the R&R queues
437187: CRM Middleware Alert Monitoring
2005 SAP AG 19
Details of Monitoring Initial Load
Transaction R3AM1
The transaction R3AM1 monitors load objects in the CRM server.
What is monitored by transaction R3AM1?

The status of all loaded objects (into CRM or CDB) are monitored using transaction R3AM1.
(De)activation of R3AM1
Transaction R3AM1 cannot be switched off.
Description of Using the Monitor R3AM1

If you start an initial load you can monitor the status of this load in R3AM1.
Possible statuses for downloaded objects:
GREEN: done
YELLOW: running
RED: aborted
You can see the respective source and destination of the load. The number of blocks is the number of
packages transferred.
From this transaction you can also stop the load by using the cancel button on top on the list.
Details of Monitoring Load Requests
Transaction R3AR3
The transaction R3AR3 monitors requested objects in the CRM server.
What is monitored by transaction R3AR3?

The status of all requested objects (into CRM or CDB) are monitored using transaction R3AR3.
(De)activation of R3AR3
Transaction R3AR3 cannot be switched off.
Description of Using the Monitor R3AR3

If you start a request load you can monitor the status of this load in R3AR3.
Possible statuses for requested objects:
GREEN: done
YELLOW: running
RED: aborted
You can see the respective source and destination of the load. The number of blocks is the number of
packages transferred.
From this transaction you can also stop the load by using the cancel button on top on the list.
2005 SAP AG 20
Details of BW Delta Queue Maintenance
Transaction RSA7
The transaction RSA7 shows status of the BW interface in the CRM server.
What is monitored by transaction RSA7?

The transaction RSA7 shows the status of all data sources which have to be extracted for the BW-
systems.
(De)activation of RSA7
Transaction RSA7 cannot be switched off.
Description of Using the Monitor RSA7

Transaction RSA7 shows the status of all data sources which have to be extracted for the BW-systems.
You can choose Queue Display data and choose an update mode in the next popup (either Delta
Update or Delta Repetition). This produces a list of the delta load history with date and user per
Transaction GUID and type.
Furthermore you can delete a data source, however, be aware that this can result in loss of data in the
transfer to BW.
380078: FAQ: BW delta queue (RSA7): Questions and answers
396647: FAQ: V3 update: Questions and answers
Details BW Adapter Status Source
Transaction BWA7
Transaction BWA7 shows the status of the BW interface in CRM server.
What is monitored by transaction BWA7?

Transaction BWA7 shows the status of all data sources which have to be extracted for the BW-systems.
(De)activation of BWA7
Transaction BWA7 cannot be switched off.
Description of Using the Monitor BWA7

The transaction BWA7 shows the status of all data sources which have to be extracted for the BW-
systems including the BDoc Name of the extracted BDocs. You can activate the delta load via menu BW
Adapter Activate delta. Furthermore you can choose BW Adapter Display Queue- or Display Data
Source (transaction BWA1). Here you will find all information about Metadata, Extract Structure, Selection
Conditions and Mapping.
766968: Extraction: FAQ on BWA framework to extract data from CRM
692195: FAQ: Sales Analytics and CRM-BW data Extraction
2005 SAP AG 21
Details of the qRFC Outbound Queue Monitor
Name and location the qRFC Outbound Queue Monitor

The qRFC Outbound Queue Monitor is a standard transaction in the CRM Middleware and can be started
using transaction code SMQ1.
What is monitored by transaction SMQ1

In an SAP CRM implementation, the qRFC Outbound Queue Monitor (SMQ1) is a component of the R/3
System (OLTP backend), the BW System and of the CRM Middleware server.
It is used to monitor the RFC message flow between the R/3 System and CRM and to monitor the data
flow between CRM and Mobile Clients or other connected systems, e.g. BW.
Outbound queue monitoring with transaction SMQ1 is possible on

Connected BW systems
Connected R/3 systems
Internally on a CRM system relating to outbound queues between CRM Online and genuine
outbound queues to BW, R/3, mobile clients or nonSAP systems
The following functions are available:

List queues
Display queues, including a list of associated LUWs and function modules (with input data)
Start/stop transmitting the queues
Delete queues or queue entries
If an error occurs in an LUW on the remote receiver system, the function modules of the queue entries are
rolled back on the receiving system. The relevant LUW and all of the other LUWs in the queue remain in
the queue and in the tRFC tables on the sender system. After correcting the error, transaction SMQ1 can
be used to re-transmit the LUW of the queue.
Key points:
Queues destined for the OLTP system are normally relatively short and quickly processed
Outbound Queues for BW and Mobile Clients are used with status NOSEND
The receiver fetches the data and the queue entries can only be deleted after confirmation by
the receiver.
If a queue that is in use between a mobile client and CRM is deleted it will cause inconsistency
between CRM and the mobile client
In severe cases when a mobile client cannot be manually rebuilt, it can be brought back into a
consistent state by rebuilding the client data from the CDB (AC_EXTRACT)
When the queue entries for a mobile client reach 10,000, the queue should be closely monitored
(e.g. issue warning).
When the entries reach 100,000 severe problems may occur and performance will be
affected. Administrative actions must be taken.
See also R3AM3, Delta Download Monitor .
2005 SAP AG 22
Outbound Queue Naming Conventions

Queues are named using the following prefixes designating their receiving system/component:
Note the use of the * (asterisk symbol) that is used as a multi-character wild-card on the end of the
queue name.
Queue-Name Description
CDB* Start Queues for Loads CRM CDB
CRM_SITE_* Load Queues for Mob. Clients
CSA* Send queues of CRM Server application
EXT* Start Queues for Loads CRM External programs
R3AI/R* Start Queues for Loads from OLTP
R3AU* Load Queues CRM R/3 OLTP
BW* Data bound for the BW System
Queue Status Overview:

The following status categories are displayed for each queue in the outbound queue monitor.
Status Descriptions
READY First LUW of the queue is ready for sending
RUNNING First LUW of the queue is currently being processed
EXECUTED First LUW of the queue has already been processed, and is waiting for
confirmation from the receiver system
NOSEND No active sending, receiver has to fetch the data (e.g. mobile clients, BW
System)
Deletion of the first LUW only after confirmation of the receiver
STOP Application locked the first entry of the queue temporarily
WAITSTOP Locked because of dependency on another queue, while the other queue is
locked
WAITING Locked because of dependency on LUW in another queue which is not the
first queue entry in the other queue
WAITUPDA First LUW contains update function for which the queue is currently waiting
SYSLOAD No dialog work process free; automatically reprocessed by a background job
CPICERR Network or communication error; automatically reprocessed by a
background job
Can cause a blocked queue.
RETRY Can cause a blocked queue.
2005 SAP AG 23
ARETRY Temporary error on sender; automatically reprocessed by a background job

ANORETRY During the LUW execution, the application found a serious error and
prompted the qRFC Manager via a specific qRFC call to cancel
processing of this LUW
SYSFAIL Error on receiver; look for short dump in receiving system; No automatic
retry
NOSENDS Queue is waiting to be debugged
MODIFY The data of the first LUW are just been modified
Description of Using the Monitor SMQ1

SMQ1 Screen Details / Display Queues:
Drilling-down on an entry results in more details of the queue being displayed:
Initial level: All outbound queues listed
Basic, high-level queue information
Second level: Individual queue header information
Additional details as shown in below table
Third level: Detailed queue view
Function modules to be executed
Fourth level: Display data of qRFC LUW
The LUW data is displayed
Sample SMQ1 Screens:
Call transaction SMQ1 and execute using the default, current, SAP client to get the current overview of
queues in the outbound queue.
Change the view by using function code F8 to get a list of queues with other-than-normal processing
status.
2005 SAP AG 24
309734 (CRM 2.0) or 429423 (CRM 3.0): General error analysis if the initial load finishes unsuccessfully.
390592: qRFC monitoring
420213: Composite SAP note: Central monitoring of mySAP.com components
420661: CCMS monitor for middleware monitoring for CRM/EBP setting-up alerts, etc.
438015: Latest qRFC version and supplement for 3.x, 4.x, 6.10, 6.20
442478: 40 from 18.06.2002, Installation of qRFC version 6.20.043
460235: tRFC/qRFC: Low-speed processing
481278: qRFC version
788872: SEND_XML-Parameter auf 'X'
814822: SEND_XML-Parameter auf 'X'
378903: Queue status in SMQ1, SMQ2 and table ARFCRSTATE
525549: QOUT scheduler: Registration for qRFC
Details of the qRFC Inbound Queue Monitor
Name and location of the qRFC Inbound Queue Monitor

The qRFC Inbound Queue Monitor is a standard transaction in the CRM Middleware and can be started
using transaction code SMQ2.
What is monitored by transaction SMQ2

Transaction SMQ2 is used to display and maintain the LUWs that are stored in the tRFC tables,
TRFCQIN, TRFCQSTATE and TRFCQDATA.
These LUWs can originate in the R/3 backend system (OLTP), from mobile clients or from other RFC-
compliant programs/servers, e.g. SAP BW or APO systems and the CRM itself.
Inbound queue monitoring is generally not used in the R/3 System since the data from downstream
systems is picked-up by the R/3 applications and processed as it comes in.
Description of Using the Monitor SMQ2

The following functions are available using SMQ2:
List queues including the processing status code for each queue
List the total number of queues to be processed including the number of entries in all queues of
the current SAP client
Display queues with a list of accompanying LUWs and function modules including input data
Start/stop transmitting the queues
Delete queues or queue entries
Page through views using function-key, F8, to show
o High-level queue list
o List of queues with processing errors
o List active queues
2005 SAP AG 25
Activate/deactivate/display/delete tracing for the processing of individual queues

Activate/deactivate/display/delete the qRFC log for queue processing
Display the qRFC version
Fork to the qRFC Administration and to the QIN Scheduler functions
If an error occurs in an LUW, the function modules of the queue entries are rolled back. The relevant LUW
and all of the other LUWs in the queue remain in the queue and in the inbound qRFC tables.
After correcting the error, transaction SMQ2 can be used to re-transmit the LUW of the queue.
Sample SMQ2 Screens:
SMQ2 secondary screen showing special cases
529764: Using inbound queues for CSA queues
Details of the Inbound Scheduler, QIN Scheduler
Name and location of the Inbound Scheduler

The Inbound Scheduler, or QIN Scheduler, is a standard transaction in the CRM Middleware and can be
started using transaction code SMQR.
What is monitored by Transaction SMQR?

Transaction SMQR is used to display the status of the QIN Scheduler and all registered and deregistered
queues. It is used to register and de-register qRFC queues and is configured based on queue names.
This is different from the outbound scheduler, transaction SMQS, which focuses on destinations.
2005 SAP AG 26
Normally the LUWs written in the inbound queue are not automatically executed but are acted on by the
QIN-scheduler.
Field Descriptions:
Scheduler Status: normally displays a status of INACTIV.
The scheduler wakes-up every 2 minutes and whenever an application passes it something to process. It
returns to the inactive state if there is nothing to process or when finished processing.
Last update: displays the date and time of the most recent activity.
Can be used to determine when the inbound scheduler had its last update and so indicate its activity level.
Name of AS group (DEFAULT=all): application server group to use for processing
Normally the QIN Scheduler processes all registered queues using all of the application servers of the
local R/3 or CRM System (the AS group DEFAULT).
Alternatively the group of application servers to use can be explicitly specified:
Specify a group using transaction SM59 by selecting RFC RFC Groups
Specify a group directly using RZ12
Specify the application server group using transaction SMQR by selecting
Edit Change AS Group
Host ID: Name of the SAP instance including server/host name, SAP System identifier and SAP instance
number. The server that processed the last entry of this queue.
Number of active connections: connections that are actively processing
Description of Using the Monitor SMQR

SMQR screens
Queue parameters are changed by marking a queue name and then selecting Registration or using
function-code F6. The parameters can be changed in the secondary dialog window.
Parameters Descriptions
EXEMODE (Mode) The processing type for how the queue entries
are to be processed (dialog or background)
MAXTIME (Max. runtime) The maximum time that the scheduler should
spend on processing this queue before it
switches to the next queue
USERDEST (Destination with LOGON data) Local RFC destination (must have logon data)
2005 SAP AG 27
NRETRY (Attempts) Number of retries in case of an error, if it is an

error that can be retried
TDELAY (Pause) The time of delay between retries
Note: If large queues have to be processed and no time-critical online processing is necessary, MAXTIME
can be set to 300 seconds to reduce the load caused by the inbound scheduler while reading large QRFC-
queues. After changing the parameters the queue must be registered again.
Statuses of QIN Scheduler Monitor (s. note 369007):

Status Descriptions
BATCHJOB SCHEDULED QIN Scheduler has scheduled a batch job
ACTIVE QIN Scheduler is active
INACTIVE QIN Scheduler is not active
STARTING QIN Scheduler is currently in the START phase
WAITING QIN Scheduler waits for free DIALOG work process
SYSFAIL Serious error occurred while the QIN scheduler is running
CPICERR / CPICFAIL Communication error occurred while the QIN scheduler is running
For SYSFAIL and CPICERR statuses, double-clicking on the status will display the corresponding error
text.
Further analysis of the syslog (SM21) or Development Trace (dev_rd, dev_rfc* and dev_w*) may be
required to identify errors.
Sample SMQR Screen:
2005 SAP AG 28
369007: qRFC: Configuration for the QIN Scheduler
Details of the Outbound Scheduler
Name and location of the Outbound Scheduler

Transaction SMQS is a standard transaction in the CRM Middleware.
What is monitored by transaction SMQS

Transaction SMQS is used, in both the CRM and R/3 Systems, to register, deregister and exclude qRFC
destinations and is configured based on RFC destination names.
This is different from the inbound scheduler SMQR which focuses on queue names.
The following points apply to the outbound scheduler, or QOUT Scheduler:
The QOUT Scheduler can be used to determine how many work processes are used for sending
LUWs.
Only one work process should be used for sending to external servers. This setting is done for
each destination using transaction SMQS.
Report RSQOWKEX can be scheduled as a periodic batch job (every 30 minutes) for restarting all
outbound queues that are blocked by errors.
There can be one QOUT Scheduler for each SAP client when using registered destinations
By choosing the maximal number of connections running simultaneously you can limit the
resources on the sender and indirectly also on the receiver system.
See SAP Note 525549 for registration of destinations which have not fully specified the logon
data.
As of qRFC-version 6.20.45 control of resources for tRFCs on sender side is possible
The relevant destination for tRFC can be registered and the number of MAX_CONN
specified
A destination will be automatically registered at the Outbound Scheduler if it is
A destination to an external program (Type T in Transaction SM59)
A destination to another SAP system (Type 3 in SM59) and the logon data (client, user,
password, language) are completely defined in SM59
2005 SAP AG 29
SMQS Transaction-screen headings:
Scheduler Status Status of the Scheduler. To display the current status, update
the display
Last Update Time the Scheduler was last activated
Name of AS Group Name of the RFC server group being used. The group name
DEFAULT is the default setting, and uses all application
servers that are available in the R/3 system.
(See transaction RZ12 for more information
Number of Entries Displayed Number of registered destinations
Host ID Name of the application server instance
SMQS Status Descriptions:
Status Description
INACTIVE QOUT Scheduler is inactive
STARTING QOUT Scheduler is in the START phase
ACTIVE QOUT Scheduler is active
WAITING QOUT Scheduler is waiting for free DIALOG work processes
SYSFAIL A serious system error has occurred in the current QOUT Scheduler operation
CPICFAIL A communication error has occurred in the current QOUT Scheduler operation
Description of Using Transaction SMQS

The following graphic shows the basic SMQS screen with several example destinations displayed:
2005 SAP AG 30
The following functions are supported:
Destination Column: click on an entry and the screen changes to the SM59 transaction for the selected
RFC destination
Registration: all tRFC/qRFC messages are processed by the scheduler. MAXCONN and MAXTIME
parameters can be set when registering.
Registration without activation: MAXCONN and MAXTIME parameters can be set when registering.
Deregistration: No tRFC/qRFC messages will be processed (function used for debugging, admin, etc.)
TRFC Monitor: Monitor (SM58) view for selected RFC destination
QRFC Monitor: Outbound queue monitor (SMQ1) view for selected RFC destination
Excluding a destination in SMQS means that the tRFC records are transferred into the target system
without resource management, instead of through the QOUT scheduler (requests are sent without using
the outbound scheduler). Excluding QRFCs means deregistering a QRFC-destination with the result that
nothing will be processed for this destination.
To exclude a destination from being processed by the outbound scheduler, register the destination in
SMQS and then click on the destination and choose Edit Exclude.
The destination will then show as Type Ns destination, PRD in the example above. (the difference
between N and U means, N is processed by tRFC-manager, U is not processed.
By choosing the maximum number of possible simultaneously running connections you can directly limit
the resources on the sender system and also indirectly on the receiver system.
400330: SMQS
480543: SMQS
Details of Monitoring Transactional RFC
Transaction SM58
Transaction SM58 shows the status of all transactional RFCs in CRM server.
What is monitored by transaction SM58?

The processing of all transactional RFCs running in the CRM server can be monitored here. They are
mainly caused by Replication/Realignment, SAP Business Workflow, Mobile Engine or some special
interfaces.
Executing generates a selection screen where the display period, user name, function, destination and
status of transactional RFCs can be selected. Almost any combination (single or several values, ranges,
and exclusions) of these parameters is possible.
If a system or application exception is raised during the processing of a tRFC-LUW the target system will
return this error back to the sending system. The status of this LUW will be updated with the exception
error message (red background color of status message).
2005 SAP AG 31
Additional information about the caller, function module, target system, date, time and status text is
displayed. Also information about the transaction ID, Host, current transaction code, program, client and
number of attempts establishing the connection are displayed.
(De)activation of SM58
Transaction SM58 cannot be switched off.
Description of Using the Monitor SM58

Using transaction SM58 you can select a time range and a user to see all Transactional RFCs (TRFCs)
belonging for this user. If you do not know the name of the user, specify and * in the input screen.
For Replication/Realignment you can find the name of the appropriate user using transaction SM59
Logical destinations SAPCRM_MW_RR_000 or SAPCRM_MW_RR_XXX where XXX is the name of
the productive client. There you can choose the tabstrip of the Logon/Security and find the user name for
which you should select in SM58. For other interfaces you will also find the user name in the sending
destination.
After entering the selection screen you will get a list of TRFC information including the called function
module, the target system, date, time and status.
Possible statuses are:
RECORDED : The LUW was recorded and should be executed
EXECUTED : The LUW was executed and the entry deleted
CPICERR: Communications error or invalid ABAP/4 command in the LUW
SYSFAIL: Runtime error or E message when executing the LUW
MAILED: CMC call started
READ: CMC call was successfully executed in the target R/3 System
For terminated TRFCs you have to check for SYSFAIL. Technical errors are reported as CPIC-errors and
reprocessed automatically by destination settings (SM59, choose the relevant destination Destination
TRFC options: If there is no X in suppress Background Job, an automatic reprocessing with ARFC
jobs is triggered) or scheduling the report RSARFCEX and switching off the automatic reprocessing in
SM59.
When error messages appear in the SM58 display, the error condition(s) must be resolved before re-
execution of the tRFC procedure.
When the problem is corrected, the tRFC should be manually re-executed / deleted.
If the failed messages are successfully reprocessed, the entry does not appear in the SM58 display after
refreshing the screen.
Do not delete an entry before resolving the problem because this can lead to a data inconsistency.
Sample SM58 screen:
2005 SAP AG 32
Monitoring for Component J2EE engine

Alert Monitoring for J2EE engine
Basics
The SAP J2EE Engine monitoring system consists of a Monitor Server and Monitor Service. The Monitor
Service establishes a connection between the Monitor Server and the system. The Monitor Server,
working on a separate Virtual Machine, collects data from cluster elements, and reports the information
and statistics about the cluster nodes and their components to Visual Administrator, SAPs Computing
Center Management System (CCMS) agent, a File System (in .xls and .html format files), and its own
Monitor Server GUI tool.
The monitor data reported to Visual Administrator, SAPs CCMS, File System, and Monitor Server GUI
tool is the same, but is organized in a different way.
The monitor data for each cluster element is separated in two main groups: Workload and Configuration.
Setup
The setup of the J2EE 620 monitoring is described in detail in https://service.sap.com/crm-inst under
General and Technical Installation Guides CRM Monitoring installation guide on WAS JAVA 6.20.
2005 SAP AG 33
Manual Monitoring
CCMS / Admin Console Workload / Requests Hourly/daily
CCMS / Admin Console Workload / Memory Hourly/daily
CCMS / Admin Console Workload / Sessions Hourly/daily
CCMS / Admin Console Workload / Threads Hourly/daily
Admin Console Workload / Logs On request
Admin Console Workload / Database Pools On request
Admin Console Workload / Connections Manipulator On request
Admin Console Workload / Transactions On request
CCMS / Admin Console Configuration / Service status On request
CCMS / Admin Console Configuration / System Info On request
Workload
Contains all dynamically changing information related to the runtime behaviour of the system.
Currently the Workload provides information for:
Requests
Displays information about the number of HTTP and P4 requests and responses processed by the SAP
J2EE Engine.
The data in the application node is displayed separately for HTTP requests and P4 requests and is
distributed as follows:
Total number of Requests: total number of requests received since startup
Total number of Responses: total number of responses returned since startup
Maximum time for Request: maximum period (in milliseconds) for executing a request from
startup to the present
Average time for Request: average time (in milliseconds) for response to a request
Waiting Requests: number of requests waiting to be processed.
The type of this property is int. Its value range is a non-negative number.
New requests count: number of requests, which were processed since the time of the last report
of the Monitor Server.
New response count: number of responses which were sent since the time of the last report of
the Monitor Server.
Average response time for new requests: average time (in milliseconds) for executing a new
request.
The data in the dispatcher node is aggregated for all requests received by the dispatcher from the
separate application nodes.
2005 SAP AG 34
Memory
SAP J2EE Engine has internal memory management, which is responsible for managing the memory
usage of the server, and prevents lack of memory by using a system based on memory level warnings to
the services. After a service has received a warning for critical memory level it starts actions on its side to
manage the problem.
The memory data is organized as follows:

Allocated Memory: the memory allocated to the corresponding cluster node. The value of this
property is in bytes. Its type is long. The value range is less than or equal to the Memory Limit
property.
Memory Limit: the maximum amount of memory that can be allocated to the relevant cluster node
Max Memory: the maximum amount of memory used by the corresponding cluster node to date
Memory in Use: the amount of memory being used by the cluster node
Utilization Level: an integer corresponding to the percentage range of memory used by the
particular application node at present.
There are six utilization levels, according to the amount of memory used:
o 0: the amount of memory used is from 0% to 40%
Sessions
The Session monitor provides aggregated information about the user sessions. This component displays
monitor data about the Login System and the HTTP Sessions for the relevant cluster node.
Login Sessions: used for collecting data about user sessions on SAP J2EE Engine. Displays summary
information about all user sessions, as well as a list of all logged users and additional information about
their sessions.
The login monitor data is:

Current number of sessions: the number of user login sessions now open
Maximum sessions since startup: the maximum number of login sessions opened since startup
Average sessions since startup: the average number of open user sessions per second
Maximum sessions duration: the maximum duration of a user session from its opening to its
closure
Average sessions duration: the average duration of a user session from its opening to its closure
Http Sessions: reports the current number of active stateful sessions (HTTP Sessions) with
additional information about them.
Current number of sessions: the number of HTTP sessions now open
Maximum sessions since startup: the maximum number of HTTP sessions opened since startup
Average sessions since startup: the average number of open server sessions per second
Maximum sessions gross time: the maximum duration of an HTTP session from its opening to its
closure
Average sessions gross time: the average duration of an HTTP session from its opening to its
closure
Note: To view a detailed list of all active HTTP sessions, use the HTTP_SESSIONS shell command from
the HTTP shell command group by typing the following in your application node command line:
add http
http_sessions
2005 SAP AG 35
Threads
The SAP J2EE Engine thread management system is organized to handle threads in two different thread
pools. The first pool is used by the system itself (SystemThreads); the other pool is used for processing
client requests (ClientThreads).
The type of reported data is the same for both SystemThreads and ClientThreads groups:
Initial threads: the number of threads specified by the InitialThreadCount property in the
ThreadManager
Current threads: the number of all currently started threads.
Equal to the sum of all running and idle threads.
Peak threads: the maximum number of current threads since startup
Running threads: the number of threads currently running
Idle threads: the number of the idle threads
Waiting threads at RQ: the new requests waiting in a request queue (RQ).
When the value of this property becomes too big, this means that the system needs more
threads to operate properly and you must increase the value of the InitialThreadCount
property in the ThreadManager.
RQ current capacity: the capacity of the request queue
Logs
Displays the log messages about all significant events that have occurred on the relevant cluster node.
The following information is displayed about each log message:

Severity: the severity level of the log message
Component: the component that logs the message
Message: the ID and information about the log message
Exception: the exception that is written to the log files
Database Pools
Provides information about the status of the database pools deployed on SAP J2EE Engine, details about
the current number of connections in use and the number of requests waiting for a database connection.
Connections Manipulator
Provides information about the connections used by the P4 and HTTP Service.
Transactions
Contains monitor data about the transactions executed by SAP J2EE Engine.
The data is displayed as follows:
Active transactions count: the number of active transactions
Committed transactions count: the number of transactions committed by SAP J2EE engine
Rolled back transactions count: the number of rolled back transaction
Average time for commit: the average time for committing a transaction
Average time for rollback: the average time for rolling back a transaction
Total transactions count: the sum of the committed and rolled back transactions
Average time for transaction: the average time for executing a transaction
Fast transactions/Slow transactions: the number of fast and slow transactions
Min time/Max time: the minimum and maximum time for committing a transaction
2005 SAP AG 36
Configuration
Provides data which is related to the current configuration status of the system.
Services status
Displays all services and managers on the corresponding cluster node, their current state (Running or
Stopped), and the time of the last change of the corresponding service state.
System Info Provides general information about the cluster node and its environment:
Cluster element ID
Cluster element host/IP
Cluster element opened port
SAP J2EE Engine version
Java version
Operating system (OS) name
Operating system (OS) version
Java Virtual Machine (VM) version
Java Virtual Machine (VM) vendor
Java Virtual Machine (VM) name
User directory
Startup Time
2005 SAP AG 37
Additional J2EE Monitors

Performance Analysis Tool Perfviewer
Beginning with SAP J2EE Engine 6.20 PL25 a performance analysis tool Perfviewer is available.
It handles the output of the monitoring service in the J2EE Engine in a java-only environment. This is
useful for monitoring the J2EE Engine (e.g. in big cluster installations), to observe the performance over
the last several weeks, to analyze and detect the roots of problems in J2EE Engine performance
degradation situations, and to make proactive tuning for productive use with J2EE Engine.
The activation is described in details in OSS Note 766839 for Engine 6.20.
Graphic and table reports in HTML format can be generated from the collected data.
A report presents the most important state counters of the system grouped in several views of summary
statistics
Resource Consumption View
Capacity Planning View
Errors Detection View
Application Activities View
JARM Requests and Components
Console Logs
SAP J2EE Engine 6.20 provides log files for monitoring the cluster elements console output.
The information printed on the command line is provided to <SAPj2eeEngine_install_dir>/cluster/server or
dispatcher/managers/console_logs directory and stored in two separate text files.
One of the files logs the output data about the loading and starting of the managers and services (for
example, Loading: LogManager ...). The name of the file includes the date and time of its creation and
output for marking the information that has been logged (for example,
2001_11_12_at_15_59_3_output.log).
The other file logs exceptions and errors that occurred during the running process of the cluster elements.
The name of the file contains the date and time of its creation and error for marking the information that
has been logged (for example, 2001_11_12_at_15_59_3_error.log).
This log system can be managed using console_logs.properties file located in

<SAPj2eeEngine_install_dir>/cluster/server/managers or
<SAPj2eeEngine_install_dir>/cluster/dispatcher/managers/ directory.
It contains three properties with the following keys and values:

LogConsoleStreams: this property has a Boolean value that indicates if console output is logged
Default is set to YES
LogDir: specifies the directory where the log files are stored
Default value is /managers/console_logs
DaysToKeepLogs: specifies how long (in days) to store the log files
Default value is 7
Logging console output helps the system administrator to monitor the running processes of cluster
elements if the specific node is set as an NT Service, or no console is provided (such as in an SAP Web
Application Server).
For additional information see Administration Manual SAP J2EE Engine 6.20, pages 114/441.
2005 SAP AG 38
Monitoring for Component

Internet Communication Manager (ICMAN)
Monitoring the ICMAN
Basics
The Internet Communication Manager (ICM) guarantees communication between the SAP System
(SAP Web Application Server) and the outside world via the HTTP, HTTPS and SMTP protocols. In its
role as a server the ICM can process requests from the Internet that arrive as URLs with the
server/port combination that the ICM can listen to. The ICM then calls the relevant local handler for the
URL in question.
The ICM administration functions are managed partly using profile parameters and partly using the
ICM monitor (transaction SMICM). The ICM is implemented as a separate process (e.g. icman.exe in
a Windows environment) and is started and monitored by the dispatcher. In profile parameters you
can set whether the ICM is to be started and how it is to be configured
CCMS
The CCMS has a monitoring node for the ICM with information about threads, connections, queue-
length and memory pipes.
2005 SAP AG 39
Manual Monitoring
Tool Frequency
Transaction SMICM Daily
ICM trace file In case of error
ICM http log file In case of error
Details for Transaction SMICM

You can use the ICM Monitor in the SAP System (transaction SMICM), the Web-based administration
interface or the CCMS.
To start the ICM monitor from the SAP menu, choose Administration System Administration
Monitor System Monitoring ICM Monitor, or enter transaction SMICM.
In the initial screen you see a list of the Worker Threads with the activities of the individual threads.
2005 SAP AG 40
The fields in the display have the following meaning:

Field Meaning
No. Thread number: threads that are available for processing (receiving or
sending) requests are numbered by the ICM (like the work processes by the
dispatcher)
Thread ID Thread ID that is assigned by the operating system (analogous to the PID for
processes)
Number Number of requests that were processed by this thread
Status Current status of the thread
The following values are possible:
Free: The thread is waiting for a request.
Running: The thread is processing a request. In this case, you can display
detailed information by double-clicking on the line.
The column Processed Request displays more information.
Processed The type of request that the thread is currently processing
request
Possible values are:
<Blank field> No action
Administration Action that is triggered from transaction SMICM
or program icmon, for example, display list.
For this reason at least one thread always
displays Administration if you call SMICM.
Read request Reads the request (server)
Read response Reads the response (client)
Write request Writes the request (client)
Write response Writes the response (server)
Open connection Sets up connection to a server
Close connection Closes connection to a partner
Accept connection Accepts the connection from a client
Time-dependent action Executes time-dependent (periodically
scheduled) events
Execute shutdown Ends ICM
Wait for response (SERV) Waits for a response from the application
server (SAP Web AS is a server with active
connections)
Wait for response (CLNT) Waits for a request from the application server
(SAP Web AS is a server with active
connections)
2005 SAP AG 41
The following functions for starting, stopping, and managing the ICM are available from the
Administration menu:
Exiting the ICM: Choose Administration ICM Exit Soft or Hard Exit to soft-terminate (signal 2) or
hard-terminate (signal 9) the ICM.
With a soft termination, the ICM tries to send responses to its existing clients, but does not accept any
new connections.
With a hard termination, the process is simply terminated. All existing connections and, of course, all
requests are lost.
You can also monitor and administrate the ICM from the browser. The Web administration interface
provides the same functions as the ICM Monitor, and you have the advantage that you dont need a
SAPGUI and you do not have to be logged on to the computer where the ICM is running.
You can start it via the following URL:
http://<fully qualified ICM server name>:<ICM port>/sap/bc/bsp/sap/icm/default.htm
The functions are essentially the same as in the ICM monitor.
Trace Files
To display or reset the trace file dev_icm, choose Go To Trace File or Go To Trace Level.
You can also set the trace level here (values can be between 0 and 3; the default is 1). You can also
display just the start or the end of the file (the first or last 1000 lines). This is a very useful function for
large files. Choose Goto Trace File Display Start or Display End.
HTTP Logfiles
The access log contains a log of accesses to the ICM from an intranet or the Internet, and thus gives
you an overview of the activity on the ICM. You can also log accesses to the Internet (if the SAP Web
AS acts as the client).
A HTTP sub-handler implements logging in the ICM. This sub-handler statistically analyzes HTTP
requests and records requests.
The log handler uses the log file to serialize itself, making it a bottleneck.
It is therefore not usually activated.
The logging implementation procedure corresponds to the Apache Web Server mod_log_config
module.
2005 SAP AG 42
You can configure logging-in parameters

icm/HTTP/logging_<xx> (for incoming requests) and
icm/HTTP/logging_client_<xx> (for outgoing requests)
Sample Log Entries for Default Format (CLF):

10.18.103.34 - - [08/Jan/2001:16:53:20 +0100] "GET
/sap/bc/bsp/sap/it00/default.htm HTTP/1.0" 200 336
10.18.103.34 - - [08/Jan/2001:17:01:15 +0100] "POST
/bc/bsp/sap/it00/transition_parameter.htm HTTP/1.0" 302 0
The following string creates the CLF format: %h %l %u %t "r" %s %b
Sample Log Entry for a Self-Defined Format

The following format
LOGFORMAT=%b %h %H %S %a %l %u %t %T Line=%r %f %U %s %{user-agent}I
gives these kind of entries:
181 10.18.104.64 ls3022.wdf.sap-ag.de 8080 10.18.104.64 - -
[11/Apr/2001:14:01:08 +0200] 0 Line=GET /sap/bc/bsp/sap/it00 HTTP/1.1
/bc/bsp/sap/it00 /bc/bsp/sap/it00 500 Mozilla/4.0 (compatible; MSIE
5.01; Windows NT 5.0)
2005 SAP AG 43
Alert Monitoring for Communication Station

Basics
The monitoring information for a Communication Station is written into the file transferservice.log. In a
CRM field sales scenario there are two files called TransferService.log. One file is located on the
Communication Station and the other one is stored on the Mobile Client.
The TransferService.log file logs all errors pertaining to the Authentication of Mobile Client, Send and
Receive phase of the Message Transfer Service. In addition to errors, this log holds statistical data of
how many messages were sent/received per call to the Communication Station, authentication status
of the Mobile Client with the Communication Station and the CRM Server and any errors that might be
thrown from the CRM Server or the Communication Station.
Alert monitoring on a Communication Station is possible as external host which does not use SAP
basis software components. The monitoring is done using transaction RZ20 under the node
SAP CCMS Technical Expert Monitors. As prerequisite the SAPCCMSR agent must be installed on
the communication station.
Additionally the SAPOSCOL can be installed on the communication station to collect data about
operating system resources, including usage of virtual and physical memory, CPU utilization,
Utilization of physical disks and file systems and Resource usage of running processes. The collected
data can be sent and displayed in RZ20 of the central monitoring system using the SAPCCMSR
agent.
CCMS Monitor (RZ20)

Transaction RZ20 allows under the node SAP CCMS Technical Expert Monitors System / All
Monitoring Segments / All Monitoring Contexts the monitoring of the transferservice.log and OS data
via SAPOSCOL. Auto reaction methods can also be configured.
Monitoring: Properties and Methods

The status of the agent can be seen using transaction RZ21 under 'Topology box' 'Segment
Overview' 'Display Overview'. The Segment name is SAP_CCMS_<name of host>.
Template of TransferService.logmon.ini
In order to implement the alert monitoring of the transferservice.log a file called
TransferService.logmon.ini must be available in the folder D:\usr\sap\prfclog\logmon on the
communication station. The structure of this file is written according to the following template:
LOGFILE_TEMPLATE
DIRECTORY="c:\winnt\temp"
FILENAME="TransferService.log"
MTE_CLASS="CRM.FS.CommStation.LOG"
PREFIX=""
SHOWNEWLINES=1
ANALYZEMETHOD=""
MONITOR_LAST_FILE_MODIF=1
SHOWLINES=1
PATTERN_0="E "
VALUE_0=RED
2005 SAP AG 44
Version and Configuration

Versions coincide with the CRM and R/3 System releases, service package releases, etc. but the
installed version must not necessarily match the CRM service package level. Since CRM 4.0 SP6 the
XML transfer of mobile client data is available. To enable this transfer, it is important to implement the
Communication Station fix provided by SAP Note 747664.
Setup
For the setup please refer to SAP Notes
420213, 209834, 371023 and 451166: SAPCCMSR
and
19227: SAPOSCOL
Manual Monitoring
Tool Frequency
Qmtcnfg.exe For troubleshooting
SMWMCOMM Daily
Details for Qmtcnfg.exe
Name and location Qmtcnfg.exe

Qmtcnfg.exe is located in <installation path>\rfcsdk\crm.
The executable Qmtcnfg.exe is installed with the setup of the communication station.
What is monitored by Qmtcnfg.exe

With Qmtcnfg.exe, the monitoring of the connection status to the CRM server and the display of the
connection properties is possible. Further the transferservice.log can be accessed and the log level
set.
In case of a Unicode installation, Unicode destinations have to be configured and their connection
status can be monitored.
Settings
With Qmtcnfg.exe Select Communication Station it is possible to set the current log level of the
transferservice.log. This is done in the field Current Trace File Settings.
The default entry is 2. For a deeper analysis the log level can be increased to 4.
In non-Unicode installations the CRM server destinations are configured via the
SAP DCOM Connector console (Program files SAP DCOM Connector SAP DCOM Connector
My Computer Destinations).
Unicode destinations are maintained with QMTcnfg.exe (QMTcnfg.exe Select Unicode SAP
Destinations).
2005 SAP AG 45
Description of Using the Qmtcnfg.exe

The monitoring of a non-Unicode installation is done via Qmtcnfg.exe Select Communication
Station Test Connection. The destinations of a Unicode installation are accessed via Qmtcnfg.exe
Select Unicode Communication Station Test Connection. This test is always done to the
default CRM server connection. The default connection is set in a non-Unicode installation via
Qmtcnfg.exe Tools SAP Dcom CC Components Default Destination. For a Unicode
destination, the default destination is set by marking the checkbox Default Destination in
QMTcnfg.exe Select Unicode SAP Destinations.
The current transferservice.log is displayed via Qmtcnfg.exe Tools Show Qmt Trace File.
Log-Backup and other tasks

Especially when running in an increased log level, the transferservice.log may require considerable
amounts of space. Therefore it should be deleted regularly before the system runs out of disk space.
Details for SMWMCOMM
What is monitored SMWMCOMM

On the CRM server side the transaction SMWMCOMM monitors individual sessions and statistics of the
data exchange for each mobile client site. The status, duration, transferred data (not compressed) for each
session can be seen in this transaction. A statistics overview about all sessions is also offered.
These alerts can be displayed in CCMS view for the CRM Middleware monitor set.
Settings
In order to display the statistics overview in SMWMCOMM, a report RSMWM_BSTAT_COLLECTOR must
run. It collects the necessary data from the BDoc message store for transaction SMWMFLOW. Since this
job is client dependent it must run for every client on the CRM server.
Description of Using the SMWMCOMM

Using the Communication Monitor you can display information on individual sessions between a site and
the CRM Server, as well as statistics on the data exchange for each site.
You are provided with the following information:
Information on the individual sessions between a site and the CRM server based on the data of
the responsible Communication Station
Statistics on the data exchange for each site for a certain period
Data on the utilization of the operating system of the respective Communication Station
A detailed description of how to use the Communication Monitor is provided in the online
documentation for CRM Middleware.
420213: Composite SAP note: Central monitoring of mySAP.com components
209834: CCMS agent technology (composite note)
371023: OS07/ST06: Monitoring of operating system data
451166: SAPOSCOL and CCMS agents: monitoring processes
19227: Open newest saposcol
747664: Send fails during ConnTrans on CRM Mobile Clients
2005 SAP AG 46

Mobile Client
When a traveling sales person has data to up- or download from his laptop, he must establish a
connection to the CRM Server via the Communication Station. This may be done at the customer site
using a telephone line. The Communication Station maintains a connection between the mobile clients
and the CRM Server that in turn maintains a connection to the R/3 back-end system.
The Conntrans program is executed on the mobile client for the data exchange with the CRM server.
Data from the outbound queue of the mobile client is transferred through the Communication Station to
the CRM Server. This data can be customer orders and/or customer data, such as new customers
entered on the mobile client.
Manual Monitoring
Tool Frequency
Queued In case of an error message in the data transfer phase
Transfer Service
Client Console After a support package is applied on each mobile client
In case of an error message in the import phase
Windows Performance Monitor In case of an error message
MS SQL Profiler In case of errors
MS SQL Query Analyzer In case of errors
TransferService.log In case of errors
Details for Queued Transfer Service
Name and location of Queued Transfer Service

Located in the directory <Mobile Application installation directory>\bin
File name is QmtCnfg.exe.
What is monitored by transaction Queued Transfer Service

The Queued Transfer Service is a tool that can be used to monitor the connection status between the
Mobile Client and the Communication Station as well as to view the current trace level, log file location
and to display the log file (TransferService.log).

The current Trace Level settings can be viewed in section Current Trace File Settings. The default
trace for this log file is set to 2. It can be manually changed up to a value of 4. When closing the
application, a popup will appear informing that the trace level has been changed and asking if the
changes must be saved.
2005 SAP AG 47
Description of Using the Monitor Queued Transfer Service

For testing the connection status between the Mobile Client and the Communication Station press
button Test Connection.
To display the TransferService.log file go to the Tools menu and click on Show QMT Trace File.
Details for Monitoring Client Console
Name and location/Transaction of Client Console

The Client Console can be invoked via Start Programs SAP CRM Mobile Administration
Tools ClientConsole
stop
What is monitored by the Client Console?

The client console can be used for client administration, troubleshooting and data transfer monitoring.
In the client administration display the metadata can be generated, checked and the BDoc structures
compared. Further the connection to the Communication Station and to the CRM server can be tested
and a new client be assigned to a site on the CRM server. Check the metadata, generation and
comparison of BDoc structures.
The display data transfer allows the monitoring of the entries in the inbound and outbound queue of
the client. Data bound from the CRM outbound queue to a specific Mobile Client is copied to the
inbound queue of that Mobile Client.
Data from the Mobile Client outbound queue is transferred to the inbound queue on the CRM Server.
.In the troubleshooting display Central Tracing viewing is provided. Further it is possible to trigger an
environment check
Description of Using the Monitor Client Console

Many checks on the Mobile Client can be started via Start Client Console Troubleshooting
Check Environment. A window wills popup with a tree containing all checks that can be performed. A
description of each check is displayed on the right side of the window.
On or more checks can be selected. By pressing button Execute the selected checks will be
performed automatically. The status of the checks will be displayed on the Messages Window, on the
lower left part of the Client Console. The selected checks are then written in a HTML file. The location
of the file is displayed on the Environment Checks window and can be accessed directly from the
tool.
Such checks are:
Connectivity Information
o Comm. Station Connectivity
DB General Requirements Check
o IDES Existence on client Check
o Replication Enabled Check
DB Table Requirement Check
o Primary Key Check
o Timestamp Check
o Unique Indexes Check for Table
2005 SAP AG 48
General Settings Check

o DNS Check
o IDES Connection Check
o SQL trace Enabled Check
o IDES Admin Rights Check
o Registry Admin rights Check
o MSA Registry completion
o ServerName Check
o Upgrade.sql file Check
o Conntrans startupfile rights
o SiteID Consistency
RunTime Consistency Check
o CDB Table Availability Check
o TL Stores Procedures Check
o Conntrans StoreProc Check
o Check Metadata
System Space Check
o Hard disk space check
o RAM Size Check
o Page File Size Check
Software Prerequisites Check
o SQL Installation Check
o IDES Availability Check
o DLL Existence In system Path
o ADO Version Check
o Comm. Station Domain Check
o Check DLLs
o Check Third-Party Controls
Conntrans Settings Info
o Conntrans Autosync on/of
o Conntrans startup file info
o Connection group type Info
o Date Exchange Mode
General Settings Info
o ODBC Version
o CRM Version
o DLL Versions
o QMT DLL Version Information
o DotNet Framework Version Info
2005 SAP AG 49
IDES Properties Info

o IDES Properties
Database Logins Info
o DB Login Information
SQL Server Properties Info
o SQL Server Properties
System Settings Info
o OS Information
o Processor Information
o Language Settings
o Number Format
o Currency Format
o Date/Time Format
o Modem Settings
o Windows Temp Folder Name
o Environment Variables
Database Users Info
o DB User Information
Multilingual
o New QmtServer.tlb Existence Check
o Table script execution check
o Solution compatibility check
The Central Tracing tool allows enabling and displaying traces on the Mobile Client. To switch on the
traces go to Client Console Trouble Shooting Central Tracing.
The Central Tracing screen appears, from this screen you can select the traces that you want. To view
the trace files associated with the individual trace options, choose the corresponding path represented
as a hyperlink.
The following traces are available:

DRVADODB trace
RFC trace
SQL trace
TL trace
Transferservice trace
Conntrans trace
DRVADODB trace
The drvadodb.dll performs the database access and logs any information through its log file TRC.txt.
This trace log is enabled by default and can never be switched off.
2005 SAP AG 50
RFC trace
The srfc2com.dll and librfc32.dll are the higher-level RFC layers that perform the data conversion from
the RFC structures to readable data format. The transaction layer uses the srfc2com to specify the
metadata structures and empty ADO Recordsets. The librfc32 is internally used by srfc2com and
enables in filling the ADO Recordsets with the actual data. The librfc32.dll uses the drvadodb.dll to
access the database and fetch the top-level message in the inbound queue.
Alternatively, the librfc32 uses the drvadodb.dll to persist the data to the outbound queue in the RFC
format.
SQL trace
The SQL trace is activated via the profiler which is installed with the MS SQL server (not MSDE).
TL trace
The TL Trace, also known as the Receive Trace is useful when the import of data during the
ConnTrans fails. This is caused by the data inconsistency between the Mobile Client and the CRM
Server. This is designed as the top-level component containing the logic for importing data from the
inbound queue to the Application Tables. The Transaction layer requests the lower level RFC layers to
fetch the data from the inbound queues and decode the data from RFC format to readable data and
store it in the application tables.
ConnTrans trace
The ConnTrans trace provides information on the performance, status on the invocation of different
phases of ConnTrans, calling of the different transfer services and errors during any of the phases of
the transfer service. The information available in this trace is most useful when there are some errors
during the ConnTrans invocation.
The Inbound and Outbound Queues of the Mobile Client can be displayed using the Client Console via
Start Client Console Data Transfer Queue Manager.
Details for Monitoring Windows Performance Monitor

The Windows Performance Monitor can be useful to analyze the performance of the SQL Server
database.
Name and location/Transaction of Windows Performance Monitor

To start the Performance Monitor select Start Run perfmon.
What is monitored by transaction Windows Performance Monitor?

The Windows Performance Monitor can be used to monitor the memory consumption of the database.
This is indicated by the counter Buffer Cache Hit Ratio from the object SQL Server: Buffer Manager.
The value should not be less than 95%.
The counter Paging errors/sec should not become higher than 25% for the processes sqlserver and
UFContainer (Mobile Client application) except for short term peaks.
Details for Monitoring MS SQL Profiler

The SQL Profiler is a graphical tool that allows monitoring events in an instance of the SQL Server.
Data can be captured and saved about each event to a file or SQL table to analyze it later. The SQL
Profiler can be used for a deep analysis of performance problems on the client
Name and location/Transaction of MS SQL Profiler

The SQL Profiler can be started from the Start menu of the SQL server or by running the command
sqltrace.
In the Profiler Window, click on File New Trace (Ctrl+N)
2005 SAP AG 51
In the popup enter the details of the server to connect to

In the Trace Properties popup, enter the trace name and click on Run
Description of Using the Monitor MS SQL Profiler

The SQL Profiler can be used in two ways:
1. Create a local trace and keep it running during the analysis of the scenario. The trace file,
saved as .trc file, can then be analyzed. The analysis is done by checking each of the queries
executed and respective reads, writes and duration. If a query results in too many read/write
operations, this would have to be further analyzed using the SQL Query Analyzer.
2. Create a local trace and do the following:
Enable the Capture to Table option
Indicate a table (e.g. TableTrace) to store the trace records.
Analyzing this trace would be easy since it would be possible to run SQL statements on these
trace records.
Details for Monitoring MS SQL Query Analyzer

In the SQL Query Analyzer users enter Transact-SQL statements in a full-text window, execute the
statements, and view the results in a results-window. Users can also open a text file containing
Transact-SQL statements, execute the statements, and view the results in the results-window.
SQL Query Analyzer provides tools for determining how Microsoft SQL Server is interpreting and
working with a Transact-SQL statement.
A user can:
Display a graphical representation of the execution plan generated for the statement
Start the Index Tuning Wizard to determine which indexes can be defined for the underlying
tables to optimize the performance of the statement
Display statistics about the performance of the statement
Name and location/transaction of MS SQL Query Analyzer

The SQL Query Analyzer can be started from the start menu of the SQL server.
What is monitored by transaction MS SQL Query Analyzer?

Information about the access path, duration, or cost estimation of the query execution is monitored.
Description of Using the MS SQL Query Analyzer

Among the most important features of SQL Query Analyzer are the tools to help you analyze your
queries for optimal performance.
These tools include:
Show Query Execution Plan
Show Estimated Execution Plan
Show Server Trace
Show Client Statistics
Index Tuning Wizard
2005 SAP AG 52
Viewing the Query Execution Plan

1. If there is no query in the query pane, open a saved query or create a new query
2. On the Query menu, click Show Execution Plan or press CTRL+K to turn it on
Note: This option only works when connected to an instance of Microsoft SQL Server
version 7.0 or later.
3. Execute the query by pressing F5, or on the Query menu, click Query Execute
4. Position the cursor over graphical elements to reveal additional execution plan information
Viewing the Estimated Query Execution Plan

1. If there is no query in the query pane, open a saved query or create a new query
2. On the Query menu, click Display Estimated Execution Plan or press CTRL+L
3. If you have referenced temporary objects, no estimated query execution plan will be displayed
Note: This option works only when connected to an instance of Microsoft SQL Server
version 7.0 or later
4. Position the cursor over graphical elements to reveal additional execution plan information
Viewing Server Trace Information

1. Open a saved query or create a new query in the query pane
2. On the Query menu, click Show Server Trace
3. Execute the query by pressing F5 or Query Execute from the menu
4. Click the Trace tab to display trace information
Viewing Client Statistics Information

1. Open a saved query or create a new query in the query pane
2. On the Query menu, click Show Client Statistics
3. Execute the query by pressing F5 or on the Query menu, click Query Execute
4. Click the Statistics tab to display statistics information
To analyze a query using Index Tuning Wizard

1. Enter the query or batch of Transact-SQL statements to be analyzed into the query pane
2. On the Query menu, click Index Tuning Wizard.

For more information, refer to the Books Online on your SQL Server installation.
2005 SAP AG 53
Details for Transferservice.log
Name and location of TransferService.log

The definition of the path where this file is located is made by the registry key under
HKEY_LOCAL_MACHINE\SOFTWARE\SAP\MSA\TransferService\CurrentConfiguration\CurrentTraceFile
What is monitored by TransferService.log

In the mobile client there is a file called TransferService.log. This file logs all errors related to the
authentication of mobile client and send and receive phases of the Message Transfer Service.

The default trace for this log file is set to 2. In case of errors the trace level can be increased up to 4.
The registry key responsible for the trace level is in
HKEY_LOCAL_MACHINE\SOFTWARE\SAP\MSA\TransferService\CurrentConfiguration\CurrentTracelevel.
The trace level should be changed using the Queued Transfer Service (as explained below).
Do not alter this trace level manually.
Description of Using the Queued Transfer Service

The TransferService.log also contains statistical information about how many messages were
sent/received per call to the Communication Station.
This log-file can be accessed by the tool Queued Transfer Service or via the Client Console as
explained below.
2005 SAP AG 54

Groupware-Connector
Manual Monitoring
Tool Frequency
Connector LogFile On demand
Error Log File On demand
Trace Log File On demand
1.1. Details for Log Files

SAP CRM Groupware Connectors add a new level of integration to the enterprise environment. They
provide access to important business information created in SAP CRM in the most widely used
Groupware systems: Microsoft Exchange Server and Lotus Domino.
This version of SAP CRM Groupware Connectors allows a server based two way replication of CRM
business partners, contact persons and activities with the groupware contacts, appointments and
tasks. Once an item is created, changed, or deleted in the SAP CRM system, the changes are sent to
the Groupware Connector that forwards them to the users mailboxes. Users can immediately see
changes in their mailboxes using their Groupware Client application, such as Microsoft Outlook or
Lotus Notes.
Logfiles
To effectively manage a Groupware Connector, it is necessary to get feedback about the activity and
performance of the connector and any problems that may occur. The Groupware Connector provides
comprehensive and flexible logging capabilities.
Note: The log files are generated when the connector is running. They consume hard disk space and
obsolete log files are not removed automatically. It is an administrative task to remove and backup
obsolete files.
In case of error in the workgroup connector the following trace files are available:
Connector log file: Provides information about all processed messages
Error log file: Provides a brief description of the error
Trace log file: Provides detailed error information if present. You may use the contents of the
error log to search the trace file for details.
ErrDumps subfolder: Contains detailed information about errors sent to CRM
A copy of the sent messages is stored on the local drive.
By default, all the above-mentioned error logging options are enabled. However they can be
individually disabled using the Administrator Tool.
The Connector log file:

The connector log file records all the messages processed by the connector. The format of the log file
is strictly defined and similar to the standard HTTP log file format.
2005 SAP AG 55
The Error log file:

The error log file contains information about the messages that were processed with error(s).
The connector also writes diagnostic information to this file.
The Trace log file:
The connector writes debugging information to the trace file that allows you to investigate problems
with the connector.
For further information refer to the SAP Groupware Connector Administration Guide.
You can find it in the SAP Service Marketplace (http://service.sap.com instguides mySAP
Business Suite Solutions mySAP CRM SAP CRM 4.0 General and Technical Installation
Guides SAP Groupware Connector 2.1 Administration
2005 SAP AG 56

Roll-out Manager
Manual Monitoring
Tool Frequency
Rollout Log On demand
Details for the Rollout Log

A lot of the data which is transferred to the mobile client will be created and transferred to all mobile
clients. This is especially important e.g. for customizing data, authorizations, users, possibly also for
customers, business partners and so on. Experience shows that it is possible that 80% of all data is
distributed to all clients.
With the rollout manager it is possible to prevent the processing of this data on the CRM Server, the
download to the mobile clients, and also the processing on the mobile clients (Conntrans data import).
In short the rollout manager works as follows:

1. The rollout manager is a standalone PCs which is has a local IDES database with all common
subscriptions assigned
2. In the rollout manager all sites to be rolled-out are selected and assigned to appropriate PCs.
(Site names are assigned to PCs by hostname)
3. The rollout manager ensures that the queues for the mobile clients are cleared (old entries
deleted) and extracts the data for the subscriptions assigned to the clients, which are not part
of the Rollout Managers common data subset
4. The back up of the rollout managers PC IDES database is copied via file copy (the Rollout
Manager does this) to the selected machines
5. On the selected machines, conntrans is started to download additional data
Rollout Log
All activities that happen in the background during the rollout/replacement process can be logged to a
separate file for later use.
1. Choose from the Rollout Manager. The File Logging Options screen appears.
2005 SAP AG 57
The following options are available:

Field Description Default Values
File Name Specify the system path where you want to C:\Temp\Rolloutlog.txt
store the log file.
Maximum File Size Specify the maximum amount of information 1 MB
that can be stored in the log file.
Append/Replace Specify whether the existing log file must be Append
appended or replaced with a new log file
whenever the application is restarted.
Log Specify whether you want to log errors, Errors
warnings or any information that the
application provides during its functioning.
For detailed information for configuring the Roll-Out manager refer to the SAP Help Portal:
httphelp.sap.com Documentation mySAP Business Suite SAP customer Relationship
management SAP CRM Support Release 1 SAP CRM Powered by SAP NetWeaver Process
Integration CRM Integration Services CRM Middleware Mobile Clients Mobile Client Rollout
Manager.
2005 SAP AG 58

Intelligence Connector
Alert Monitoring for Intelligence Connector
Basics
From a technical point of view, the CRM Intelligence Connector is a J2EE application that typically
runs within the SAP Web AS Java. It requires SAP Java Connector and a JDBC driver.
From a business point of view, the CRM Intelligence Connector provides the operational processes
with the Real-Time Analytics service. It allows the user to administer and manage large numbers of
predictive models and key performance indicators (KPIs) obtained from multiple sources.
Information about the monitors for the Intelligence Connector can be found using
Transaction RZ20 SAP CRM monitoring templates Component Monitor: Intelligence
Connector. Any red labels require immediate action.
Heartbeat and High Availability

For the heartbeat, the standard xml file for GRMG has to be customized and uploaded to the central
monitoring system. There are the following heartbeat monitors available:
PING to Intelligence Connector: Availability should be 100% with Green status

At the very highest level, support could be interested if the Heartbeat servlet of Intelligence
Connector can be called at all. This is checked in the PING component. The PING component of
Heartbeat simply returns an okay if it is executed, indicating to the support that Heartbeat has
been set up properly
Logon to Intelligence Connector: Availability should be 100% with Green status

The Intelligence Connector Logon component establishes a connection to Intelligence Connector.
If this connection is successfully established, at least the connection to Intelligence Connector
database using the DBC driver has been established successfully
Workbench Access: Availability should be 100% with Green status

This component checks if Intelligence Connectors Workbench GUIs can be accessed. It makes an
http GET call to the workbench URL to check if the GET can be executed successfully.
ABAP Connectivity: Availability should be 100% with Green status.

This is the most sophisticated component, simulating an ABAP application accessing
Intelligence Connector. If this component is successful, an ABAP application should be able to
use Intelligence Connector. If this component fails, there may be a problem with the RFC
destination.

Version and configuration information are available within the intelligence connector. This information
is also available in the central monitoring. The following version information are provided: Component
name, Application name, Major version of the Component, Minor version of the Component, Build Time of
the SDA and Change List Number for the Build.
The following configuration information is available: Information from various server connections
established in the workbench and global parameters used in the application.
Central Logfile viewing

The log file can be viewed by the log viewer through CCMS monitoring. This is achieved by two
configuration files, sapccmsr.ini, which is the standard file for CCMS integration, and an application-specific
logfile template, the AAPLOGS.ini file, specific to the Intelligence Connector.
2005 SAP AG 59
1.1.6 Setup
The setup for the intelligence connector is best done using the corresponding installation guide for
CCMS monitoring which can be found at http://service.sap.com/crm-inst and then selecting General
and Technical Installation Guides. The guides correspond to those used for J2EE Engine version
(Either 6.20 or 6.40).
2005 SAP AG 60

SAPphone
Alert monitoring for SAPphone
SAPphone and the Computer Telephony Integration in IC WinClient and IC WebClient are technically
based on SAP Web Application Server (SAP Web AS) release 6.20. The SAPphone interface contains
function modules to exchange status and trace information with the external CTI software.
The communication environment of SAPphone is connected to the alert monitor of the Computing
Center Management System (CCMS). As a result, monitoring for telephony is integrated into the
central monitoring landscape of the R/3 System. The tools available in the CCMS can be used for the
SAPphone component.
Basics
The SAP Business Communication monitor set is supplied with the alert monitor for the monitoring of
the SAPphone environment. The SAPphone monitor is assigned to this monitor set. The data
collection methods for SAPphone are also supplied. These methods, which are to be scheduled
periodically, query the current operating status of the external communication components and store
the results.
The monitors of the SAP Business Communication Monitor Set can be accessed directly from the
SAPphone administration transaction SPHB. Select the required telephony server and choose Utilities
Alert monitor Display, specify the monitor (SAPphone) and choose Continue.
Note: the flag Server is to be monitored by alert monitor should be selected for this purpose.
The monitor for SAPphone can be also called directly in the central alert monitor display.
Run transaction RZ20 or choose Administration CCMS Control/Monitoring Alert Monitor.
The SAPphone monitor can be located e.g.:

CCMS Monitor Sets SAP CCMS Technical Expert Monitors All Monitoring Contexts
SAP Business Communication...
or in Own monitor sets ...(Monitor sets defined individually).
The RFC connection to the external telephony components can be monitored for errors in RZ20.
In case of, e.g., communication errors (see example below), an alert is raised:
Depending on the setup of CCMS, auto-reaction methods, such as the sending of an email or an SMS
to the system administrator, could be raised by this alert (see SAP note 176492).
2005 SAP AG 61
SPHB SAPphone: System Administration

SPHB is the central transaction for SAPphone administration and provides the functions for starting
and monitoring the telephony environment.
SPHA SAPphone Administration, Extended Settings

In the transaction SPHA, telephony functions can be tested and the work center settings and user
settings can be maintained individually or centrally.
Setup
Monitoring for SAPphone is not automatically activated after the SAP system has been installed and
must be manual scheduled and activated.
Note: the SAPphone and SAPconnect data collection methods are not displayed using transaction
RZ21. You need to create the corresponding entries in RZ21 manually as described in SAP Note
546493.
A data collection method only queries the status of a communication component if you have marked
the corresponding node in the R/3 System as ready to be queried by the data collection method.
Therefore, you have to assign this attribute to every telephony server that represents an external
communication component that is to be monitored by the alert monitor.
Detailed information on how to activate and to setup monitoring for the SAPphone component is
available in SAP Online Help (http://help.sap.com) SAP Web Application Server 620 mySAP
Technology Components SAP Web Application Server Basis Services/Communication Interfaces
Communication Interfaces SAPphone (BC-SRV-COM).
Manual Monitoring
SPHB Details for SAPphone Administration In case of errors
SPHA Details for SAPphone Administration Extended In case of errors
Settings
Details for SAPphone Administration SPHB

The following functions for starting and monitoring the telephony environment are provided using
transaction SPHB:
Creating a work center and maintaining work center and user settings
Displaying specific information on the telephony servers in the navigation structure
Customizing settings, maintaining deflection groups and creating tasks
Checking and monitoring telephony environment
Error analysis tools
Central maintaining of work center settings and user settings
Name and location/Transaction SPHB.

The central transaction for SAPphone Administration can be called via SAP menu
Tools Business Communication Communication SAPphone
or by executing transaction code SPHB.
2005 SAP AG 62
What is monitored by transaction SPHB

Using transaction SPHB, the RFC destination(s) to the external telephony component(s) can be
monitored either manually or by means of CCMS.
Furthermore, various tools for error analysis are available:
Internal trace to check the parameters exchanged with the external CTI
External trace and status to get information from the external CTI
SAPphone NONE server is available for call simulation purposes to determine whether a
problem is caused by the programs inside or outside of the SAP System.
Description of Using the Monitor SPHB

RFC destination to the external telephony component
The connection test for the RFC destination can be performed manually from the transaction SPHB. In
this case, select the appropriate telephony server and double-click the name of the RFC destination
on the tab Server attributes. Now the screen of transaction SM59 is opened where you can test the
connection by pressing the button Test Connection.
Alternatively, the RFC connection to the external telephony component can be monitored in CCMS
(see example above). To enable this automatic monitoring, mark the flag Server is to be monitored by
alert monitor and make required settings using transactions RZ21 and RZ20 to set up CCMS
monitoring.
Internal Trace
The SAPphone internal trace can be used to check the parameters exchanged with the external CTI
and to monitor some of the RFC functions in case of errors.
The trace can be turned on using transaction SPHB Utilities Trace Internal Trace:
Switch on the trace in the lower part of popup

To view the trace, play Display in the upper part of the popup. You then get the catalog of
trace entries, one for each call. If you doubleclick on a line, you receive the trace for one call.
Please note that the trace should only be switched on during the error analysis, i.e. a limited time
frame, and should be deactivated immediately after the analysis has been finished.
External Trace and Status

The SAPphone interface contains functions to load status and trace information from the external CTI
to the SAP system for viewing them within the system. How extensively this functionality is supported
depends on the CTI system. This function can be used to view external traces while logged on to the
SAP system, e.g. when you have remote access to the SAP system, but not to the CTI server.
Since these external traces may have non-SAP formats, they cannot be described in this document.
The SAPphone Server traces can, of course, be viewed from the external trace.
SAPphone NONE Server

The SAPphone NONE server simulates a CTI software. It is implemented in the SAP system. It cuts
the system at the SAPphone RFC layer and helps to determine whether a problem is caused by the
programs inside or outside the SAP System. Furthermore it can be used for self-studying or demo
purposes. It is automatically available in every system. To use it, you simply have to create a new
server node in the transaction SPHB (see below) with RFC-Destination NONE, and assign this node to
your workcenter.
To set up a NONE server, you can either replace the name of the existing RFC destination set up for
a telephony server, copy the existing telephony server to a new one for testing purposes or create a
completely new telephony server using the wizard in transaction SPHB.
2005 SAP AG 63
Note: after the NONE server is created, you need to create a workcenter for you at your desktop
using that NONE server. Start transaction SPHA and assign the created NONE server as your
telephony server. Details regarding work center settings in transaction SPHA can be found in the
following section.
546493: Data collection method not displayed in RZ21
533667: SAPphone Call Status Control: Versions and updates
719873: SAPphone: DYNP_TOO_MANY_RADIOBUTTONS_ON dump in RSPHQUSR
Details for SAPphone Administration Extended Settings - SPHA

The following functions are available in the transaction SPHA to test the telephony functions and to
maintain work center and user settings:
Maintaining work center settings and user settings centrally
Creating a work center and maintaining work center and user settings individually
Manually assigning callers who have not been identified by the system
Displaying the SAPphone version
Functions for testing telephony functions
Name and location/Transaction SPHA

Transaction to maintain the extended settings for SAPphone can be accessed from SAP menu:
Office Telephone Integration Extended Settings or by calling transaction SPHA.
What is monitored by transaction SPHA?

The SAPphone User Interface can be used as an alternative to CIC for executing telephony functions.
It can be used both in a test environment and productively.
To be able to use the telephony functions of the SAP System, the work center has to be created as a
telephone work center. The system needs to recognize which telephone belongs to which computer.
These settings are maintained using transaction SPHA.
Inbound calls can trigger various actions in SAPphone. For example, an application, such as the
creation of a purchase order, can be started. In the user settings, you can change the way the system
handles inbound calls to your work center.
After the SAPphone settings were changed or in case of errors, the telephony functions can be tested
in the transaction SPHA.
Using the SAPphone interface you take CIC out of the picture, which can help you to decide if the
error lies within CIC or outside. It can be used to check telephony functions and ANI identification.
Description of Using the Monitor SPHA

To test the telephony functions in case of error situations or after the SAPphone configuration was
changed, the following can be performed:
In case of problems with user determination for an inbound call, the missing assignments can
be checked using transaction SPHA for the last call performed. Repeat the call or simulate it
by choosing Simulate inbound call. Afterwards, select Utilities Assign inbound call. Check
the data and information displayed. Also read the associated long text. Choose Call/log. The
inbound call is simulated again. However, each step in the search for the caller is logged this
time and, as a result, the step in which the error occurs can be easily identified from the log.
To test outbound calls, you can use the button Initiate outbound call. An opened dialog box
lets you specify the telephone number that you would like to call.
2005 SAP AG 64
To simulate inbound calls, the button Simulate inbound call can be used. You need to specify
your extension and server. If caller identification should be tested, the calling number needs to
be specified as well. Press Initiate Call after having performed all required settings.
The button My telephone provides testing functionality for telephony functions on the
SAPphone interface.
2005 SAP AG 65
Monitoring for ISA Web Applications

Alert monitoring for ISA Web Applications
Basics
The most convenient way to find information about the ISA web applications is by using transaction
RZ20 SAP CRM monitoring templates Component Monitor: E-Selling.
This delivers an aggregated view on all ISA relevant monitors and information. Any red alerts require
immediate action.

Standard availability monitoring delivers values for the custom configured scenarios.
They were maintained in the XCM tool of the corresponding ISA web application (e.g. b2b).
Whenever a red alert pops up in the heartbeat section, then there is a major issue and normally a
production down situation regarding the ISA web application.
When a yellow or red light in the Performance and Activity section appears, check the isaruntime.log
(if running in DEBUG mode) or create a single activity trace including the marked function module.
Please keep in mind that this function module could also call the web application or any other
component of the scenario (e.g. IPC, R/3, BW, etc.), which requires an additional ST05 trace of the
J2EE and/or the web user.

Version and configuration information are available from within the J2EE monitoring. Due to this, it is
mandatory that the J2EE engine also reports information to the central monitoring system.
Any red alerts here indicate that a setting in the scenario is not within the recommended values.
Please check the recommendations from the Going Live Analysis Session or any other
recommendations given to you. If the value corresponds to the recommendation than modify the
properties to the new values, otherwise change the parameter.
Automatic Logfile Monitoring

The standard template for automatic monitoring can be easily extended. The only problem is the fact
that no wildcards are allowed within the monitoring patterns. This makes it difficult to scan for the
pattern exception, as JAVA reports special exceptions and entering all of them in a template would
consume a very high number of resources for a small result. This means, only searching for the
pattern error is useful.
In addition, because there are several components, make sure that there is a pattern file for each web
application used. E.g. the IPC price analysis uses its own application and also has its own log file
pattern.
Further information regarding the utilization of this feature can be found at
http://service.sap.com/monitoring Monitoring in detail.
There you will find a guide about CCMS monitoring: CCMS Agents: Features, Installation and
Operation.
Setup
The setup for the ISA web application is best done using the corresponding installation guide for
CCMS monitoring which can be found at http://service.sap.com/crm-inst and then selecting General
and Technical Installation Guides. The guides correspond to the respective J2EE Engine version
(Either 6.20 or 6.40).
2005 SAP AG 66
Manual Monitoring
COMM_PCAT_ADM Catalogue Maintenance After each replication
Details for COMM_PCAT_ADM
What is monitored by transaction COMM_PCAT_ADM

The transaction COMM_PCAT_ADM is the main maintenance function for the product catalogue.
After each replication, which can be manually triggered within this application or scheduled via batch
jobs, it is strongly recommended to check the results.
For monitoring,
Select the replicated catalogue and then click on the display button
In the tab bar on the top of the page select Goto Replication Display Log
Restrict the time to the appropriate time-frame and press the execute button (F8)
If there is a red light in the result frame, investigate the error and redo the replication partly or fully if
necessary.
2005 SAP AG 67
Monitoring the IC Web Client

Alert Monitoring for the IC Web Client
The Alert monitor for IC WEB CLIENT is integrated in the Computing Center Management System
(CCMS). It is accessible via transaction code RZ20. With 6.20 basis support package 30, predefined
monitor sets became available for monitoring CRM components such as IC WEB CLIENT.
The Alert monitor for IC WEB CLIENT is based on the SAP CCMS Monitoring Agent sapccmsr and is
available for Microsoft Platforms and UNIX Platforms. The latest version is available from
http://service.sap.com.
Basics
Monitoring transaction RZ20

The IC WEB CLIENT Alert Monitor can be accessed via the predefined monitor Component Monitor:
IC WEB CLIENT within the CCMS monitor set SAP CRM Monitor Templates.
The following graphic shows the monitor definitions delivered in the monitor set.
2005 SAP AG 68
Heartbeat and Availability

IC WebClient is integrated with the Computing Center Management System (CCMS) and Generic
Request and Message Generator (GRMG) heartbeat monitoring.
For more information about installing the CCMS agent and customizing the IC WebClient for CCMS
monitoring and GRMG heartbeat monitoring, see the CRM Monitoring Installation Guide in the SAP
Service Marketplace at
http://service.sap.com/CRM-INST SAP CRM 4.0 CRM Monitoring Installation Guide <relevant
release>.
Standard Heartbeat Monitoring: What is Monitored?

Heartbeat monitoring for IC WebClient checks if the web application has started successfully and if it is
listening for requests.
The primary function of the heartbeat is to check the availability of the system and its components.
Availability is defined in this guide by the following characteristics:
The availability information is usually technical.
Once it has been set up, the availability check is performed periodically and without user
interaction.
The result of the check is reported in the central CCMS. This means that an availability monitor
can be set up to centrally display the status of individual components. It is also possible to
implement automatic mechanisms and notifications using auto-reactions.
At the application level, availability is checked with the Generic Request and Message Generator
(GRMG).
With GRMG, the CEN system periodically calls a GRMG application using a URL.
The GRMG application performs component-specific checks and returns the result of the checks to
the CEN system.
SAP delivers a GRMG application for SAP CRM, the SAP J2EE Engine and several other SAP
components.
The availability check can be implemented differently for C-based components. For example, the
availability of the IPC is checked using a Shared Library (Data Supplier), which is periodically started
by the SAPCCMSR agent.
If a GRMG check is not possible or not useful for a component, it is at least possible to prove the
existence of the corresponding process at the operating system level. A check of this type establishes
the necessary (but insufficient) prerequisite for component availability. The check is performed by the
SAP program SAPOSCOL and the SAPCCMSR agent.
2005 SAP AG 69
The figure shows the availability of the IC WEBCLIENT on IC JCO PWDF0430 and the status as
listener.
Please check daily for alerts presented in this monitor. Do this using the Open Alerts button.
The Version Information shows the Versions of the IC WEB CLIENT Server.
This information is useful when contacting SAP support in case of problems.
2005 SAP AG 70
This figure shows configuration information as presented in the CCMS Monitor.

You can display the CRM Message Server, the CRM Server, Gateway, the max. number of JC0
connections, etc.
Logfile Monitoring
Automatic logfile monitoring is displayed in the Component Monitor under Logfile Monitoring.
This can be seen for each server. The Data Collection Check shows the last time that the logfile was
checked.
2005 SAP AG 71
Manual Monitoring
Tool Frequency
RZ20 Daily
ST03N Weekly
IC Web Client Performance Monitoring in ST03N

Statistical records and Workload statistics.
Choose role Expert mode. Then go to the tree on the left side and choose
Collector and Performance DB Statistical records & file Online Parameters Dialog steps
statistics delete entry PLUG IN in column rdispo/no_statistic.
ST03 Choose role "Expert mode. Then choose in left tree Collector and Performance DB"
Workload Collector Statistics to Be Created Web Application Server Statistics:
Choose one of the 3 options to select the summarization level
Afterwards, you will be able to monitor the statistical records of the Internet Communication
Framework in ST03 and STAD under task type HTTP.
Note: The response time showed in the ST03 refers only to the server response time.
The frontend rendering time is not calculated here.
2005 SAP AG 72
Verify the installed components

1. Start the GUI Software Delivery Manager (SDM) Tool as described in SAP Note 544244.
2. Choose SDM Repository CRM Interaction Center WebClient 1.0.
The SAP CRM Interaction Center WebClient Java Server 1.0 should appear as installed, as shown in
the figure below:
Relevant SAPNET Notes

635453: information about how to determine the patch level of the J2EE Engine
2005 SAP AG 73

CRM Broadcast Messaging Server
Alert monitoring for CRM Broadcast Messaging
Server
Basics
Broadcast messaging server (BMS) is a CRM component containing one Web application
(BROADCAST), which is deployed on the J2EE Engine. In cases where the CRM 4.0 Add-On for
Service Industries is implemented, you may not use the Java configuration.
The current document only covers the implementation with the J2EE Engine. The BMS Java
component fully supports the SAP CCMS system monitoring for Java component and provides the
following features:
Single activity trace
Log files
Heartbeat and availability
Version and configuration
Performance monitoring
In order to make these features available, the SAP CCMSR agent and SAPOSCOL have to be
installed and configured. In addition, the GRMG file for this component has to be configured and
uploaded, as described in section Setup.
Performance and Activity Monitoring

The following characteristics of this component are monitored through the performance- and activity
Monitoring (RZ20):
Number of Valid Messages
Used Threads
Used Sockets

For information about installing the CCMS agent and customizing the BMS for CCMS monitoring and
GRMG heartbeat monitoring, see CRM Monitoring Installation Guide <relevant release> in the SAP
Service Marketplace at http://service.sap.com/CRM-INST

The following information is displayed for the configuration:
Information Description
Machine Name Machine where J2EE Engine is installed

Port Port number of the broadcast messaging application
Service Threads Service Threads
2005 SAP AG 74
The following information is displayed for the version:
Component CRM.BMS
Application BROADCAST
Major version Current value appears
Minor version Current value appears
Support package Current value appears
Build time Current value appears
Changelist number Current value appears
Additional information Current value appears

The log and trace files contain information regarding runtime.
The log and trace files can be found under the following directory:
<J2EE_instance>/cluster/server/
The file name of trace is broadcast.*.trc and the file name of the log is broadcast.*.log.
In addition, the log file can be monitored through CCMS. The setup in CCMS is described in section 1.1.6
Setup.

The broadcast messaging server template can be found using transaction RZ20 SAP CRM Monitor
Templates Component Monitor: BCOM Business Broker.
Setup
For information about installing the CCMS agent and customizing the BMS for CCMS monitoring and
GRMG heartbeat monitoring, see CRM Monitoring Installation Guide <relevant release> in the SAP
Service Marketplace at http://service.sap.com/CRM-INST
Manual Monitoring
Tool Transaction Frequency
Single Activity Trace CRMC_IC_TRACE On demand
Details for Single Activity Trace

The Single Activity Trace shows actions performed by an application or software component and
their duration. With this, it is possible to check which actions took which amount of time in an
application and to pinpoint possible bottlenecks and sources of problems.
Transaction CRMC_IC_TRACE
Single Activity Trace is turned on for a user session by adding the user's login name to transaction
'CRMC_IC_TRACE. When the user logs on to the application using the user name added in the
above transaction the trace is started for that user session.
What is monitored by transaction CRMC_IC_TRACE

The Single Activity Trace shows actions performed by an application or software component and their
duration. With this it is possible to check which actions took which amount of time in an application
and to pinpoint possible bottlenecks and sources of problems.
(De)activation of Single Activity trace

To turn off single activity trace, go to transaction 'CRMC_IC_TRACE and delete the user name you
entered. Save the changes.
2005 SAP AG 75
Description of using the monitor CRMC_IC_TRACE

This file is created at runtime and resides in J2EE, under the directory of
<J2EE instance>\cluster\server\log\ and is called sat.trc.<number>.
You can activate tracing for each user by running transaction CRMC_IC_TRACE and adding an entry
for the user.
Description of Using the Monitor

The Single Activity Trace of a component can be viewed with the Central Log Viewer.
The Central Log Viewer is part of the SAP J2EE Engine 6.20 Patch 12 and higher.
Central Log Viewer shows Log and Trace files written by Applications on the SAP J2EE Engine.
The Log Viewer documentation can be found in the SAP online help SAP NetWeaver Application
Platform Java Technology in SAP Web Application Server Administration Manual Server
Administration logging Log Viewer
or at
http://bis.wdf.sap.corp:1080/twiki/bin/view/Techdev/LogViewer
Relevant SAPNET Notes

642665: BMS: CRM 4.0 SP02
2005 SAP AG 76
Monitoring for Component ICSS

Alert Monitoring for ICSS
Basics
Component CRM ICSS (Internet Customer Self-Service) is based on the standard SAP CCMS
Monitoring Infrastructure.
After calling transaction RZ20 the monitoring details for ICSS can be found under
SAP CRM Monitor Templates Component Monitor: E-Service.

Heartbeat Monitoring of ICSS is based on the standard CCMS GRMG technology. It indicates, if
scenarios defined in the Extended Configuration Management (XCM) are properly configured by
executing a URL test on each component for which a test is defined. A sample heartbeat customizing
file can be downloaded from SAP Service Marketplace (http://service.sap.com/crm-inst CRM 4.0
Monitoring Downloads GRMG Heartbeat Customizing Files E-Selling (ICSS)).

The following information concerning versions is available in RZ20:
Component: CRM.ICSS.icss_b2b or CRM.ICSS.icss_b2c
Application: icss_b2b or icss_b2c
Support Package: current Support Package level
Major Version: currently deployed patch level
Build time: creation date of the installed patch level
Change list number: internal build number of the installed patch level
RZ20 also displays a detailed list of important configuration parameters collected from several
configuration files as shown on the following screenshot:

ICSS supports standard CCMS logfile monitoring: The CCMS logfile agent, which is integrated into all
agents, can be used to monitor log files for particular search patterns, the last change time, or for their
existence. If the agent finds the line for which it is searching, it transfers it to the central monitoring
system. This means that you can search any text files for any text patterns, assign alerts to them, and
display the results in the Alert Monitor.
2005 SAP AG 77
A logfile monitoring template can be downloaded from SAP Service Marketplace, and needs to be
customized. In the following example a subtree for the icsserror.log.0 would be displayed in RZ20. If
the agent finds the word Error, the subtree would be YELLOW, if the agent finds the word Fatal, the
subtree would be RED:
DIRECTORY="D:\usr\sap\J2EECRM05\j2ee\j2ee_05\cluster\server\services\servlet_jsp\work\jspTemp
\icss_b2c\root\WEB-INF\logs"
FILENAME="icsserror.log.0"
PREFIX="B2C"
PATTERN_0="Error"
MESSAGEID_0="rt 584"
VALUE_0=YELLOW
SEVERITY_0=100
MESSAGECLASS_0="SAP-T100"
CMP_FROM_BEGIN_0=1
PATTERN_1="Fatal"
MESSAGEID_1="rt 584"
VALUE_1=RED
SEVERITY_1=200
MESSAGECLASS_1="SAP-T100"
CMP_FROM_BEGIN_1=1
SHOWNEWLINES=1
ANALYZEMETHOD=""
MTE_CLASS="B2CICSS"
The monitor creates a subtree for every monitored file. The name of the subtree consists of a prefix
and the name of the file.
Setup
For implementation of CRM ICSS Monitoring refer to the CRM Monitoring Installation Guide
(http://service.sap.com/crm-inst General and Technical Installation Guides).
The guides correspond to the respective J2EE Engine version (Either 6.20 or 6.40).
2005 SAP AG 78
Monitoring for Component TREX

Alert Monitoring for TREX
The Alert Monitor for TREX is integrated in the Computing Center Management System (CCMS).
It is accessible via transaction code RZ20.
With 6.20 basis support package 30 predefined monitor sets became available for monitoring CRM
components such as TREX.
Basics
The TREX Alert Monitor can be accessed via the predefined monitor Component Monitor: TREX
within the CCMS monitor set SAP CRM Monitor Templates.

Availability monitoring is based on the technology of SAP CCMS Generic Request and Message
Generator (GRMG). A TREX GRMG server runs on every TREX host. CCMS uses an HTTP request
to send a GRMG-defined XML file to one of the TREX GRMG servers. The TREX GRMG server
analyzes each request and begins tests to check the availability of the individual TREX servers. The
TREX GRMG server then returns the result to CCMS.
The following screen shot shows a monitoring tree of the TREX heartbeat:
2005 SAP AG 79

A plugin of the CCMS agent gathers the version and configuration information of the TREX.
The results are displayed in the CCMS.
The following screen shot shows a monitoring tree of a TREX for the version and configuration:

Automatic logfile monitoring is standard functionality of the CCMS and monitors logfiles. The logfile
agent, which is integrated into all agents, can be used to monitor log files for particular search
patterns, the last change time, or for their existence. If the agent finds the line for which it is searching,
it transfers it to the central monitoring system.
This means that you can search any text files for any text patterns, assign alerts to them, and display
the results in the Alert Monitor.
The monitor creates a subtree for every monitored file. The name of the subtree consists of a prefix
and the name of the file. Each subtree consists, at most, of the following monitoring tree elements
(MTEs):
Monitoring Tree Meaning
Element
Complete Name Complete name including file path of the monitored log file from the
point of view of the monitoring CCMS agent
You can also display the content of the monitored files in the
Alert Monitor. To do this, double-click the Complete Name attribute in
which the name of the monitored file is displayed.
Info[<Name>] If you are searching for search patterns with no alert value, the
system displays the line that contains the search pattern
APPL_INFO_<n> in the text attribute
Info[<APPL_INFO_MTE_NAME_<n>>]
(see Examples of Logfile Templates).
Monitored Patterns Search pattern with alert value (see Examples of Logfile Templates);
you can monitor a file for multiple search patterns
(the system displays these in the monitor separated by | )
Lines found for pattern Lines of the log file that match the search pattern
2005 SAP AG 80

Element
Data Collection Check Time of the last check of the log file; this status attribute is always
colored green.
File Time Stamp Time of the last change of the monitored log attribute;
this attribute is only created if you specify the parameter
MONITOR_LAST_FILE_MODIF=1 in the log file template
New Lines in Log File Growth of the monitored log file in lines per minute;
this attribute is created only if you specify the parameter
SHOWNEWLINES=1 in the log file template
Log File Size Size of the log file; this attribute is created only if you specify the
parameter MONITOR_FILESIZE_KB0 in the log file template
(if MONITOR_FILESIZE_KB>0, you also assign an alert threshold
value to the attribute by setting)
The following screen shot shows a monitoring tree of a TREX logfile:
2005 SAP AG 81
Process Monitoring
The process monitoring is a standard functionality of the CCMS. With the operating system collector
SAPOSCOL it is possible to monitor individual processes. This can be used to monitor the processes
of the TREX (TREXDaemon.exe, TREXIndexServer.exe, TREXNameServer.exe, etc.).
The following table gives an overview of the content provided for each monitored process and
information about the monitoring tree elements (MTEs):
Element
Process Configuration Status of the process monitoring; this node exists, even if no processes are
State being monitored
Process Count Number of running processes that fulfill the conditions for process name
(superordinate node) and user (prefix of the MTE name)
CPU Total of the CPU usage of the above processes, as a percentage
Resident Size Total physical memory that is assigned to the above processes
VM Size Total of the entire memory (physical and virtual) that is assigned to the above
processes (only on Windows platforms)
The following screen shot shows a monitoring tree of TREX processes:
Setup
The setup of the TREX Monitoring is described in the following SAP notes.
TREX 6.0
SAP note 639786 TREX 6.0 Central Config & Alerting
SAP note 637124 TREX 6.0 Check of Heart Beat by using GRMG
TREX 6.1
SAP note 697949 TREX 6.1: Solution Management / Monitoring TREX
SAP note 704349 Activating the CCMS monitoring for TREX
2005 SAP AG 82
Manual Monitoring
Tool Frequency
Activity Tracing In case of error
Details for Activity Tracing

Activity Tracing can be used to record the processing steps that take place in the system when a user
carries out an action. The results can be displayed in the Log Viewer of the J2EE Engine to analyze
performance and errors.
If activity tracing is activated, TREX processing steps that take place internally are also recorded.
TREX data is particularly useful to analyze actions such as searching, classifying, or creating an
index.
Additional steps have to be carried out to be able to use Activity Tracing. These steps are described in
the SAP note 697949.
2005 SAP AG 83
Monitoring for Component CRM-IPC

Alert Monitoring for CRM-IPC
The Alert monitor for IPC is integrated in the Computing Center Management System (CCMS).
It is accessible via transaction code RZ20.
With 6.20 basis support package 30 predefined monitor sets became available for monitoring CRM
components such as IPC.
The Alert monitor for IPC is based on the SAP CCMS Monitoring Agent sapccmsr and is available for
Microsoft Platforms and UNIX Platforms. The latest version is available from http://service.sap.com.
Basics
The IPC Alert Monitor can be accessed via the predefined monitor Component Monitor: IPC within
the CCMS monitor set SAP CRM Monitor Templates.
The following figure shows the monitor definitions delivered in the monitor set.
2005 SAP AG 84
Heartbeat and Availability

The Heartbeat Monitor for IPC checks for each defined IPC server instance to ensure that it is
registered at the dispatcher and that the heartbeat information can be retrieved.
The following figure shows an example of the Heartbeat and Availability Information presented in
CCMS:
The figure shows that the IPC Server is listening on port 9999 and is registered at the dispatcher.
The functionality of Server, DB connection , Pricing Engine and Configuration Engine was tested by
the Heartbeat Call and resulted in an OK Status (Code=000).
The Open Alerts button should be used daily to check for alerts in this monitor.
2005 SAP AG 85
The Version Information shows the versions of the IPC Server (including Support Package level), the
version and patch level of the Java Virtual Machine.
Furthermore, information about the JCO Version used and the librfc32 shared library is displayed.
This information is useful when contacting SAP support in case of problems.
2005 SAP AG 86
This figure shows more configuration information as presented in the CCMS Monitor.
You have display-access to the main configuration files for IPC and additional selected parameters
from the IPC configuration like whether RFC connectivity is enabled or not and how many servers are
configured.

Automatic logfile monitoring is displayed in the Component Monitor under Logfile Monitoring
A predefined Logfile Monitoring Template ipc.logmon.ini is available from the SAP Service
Marketplace.
Red alerts are triggered whenever an Error or exception is found in any IPC*.log file
Setup
The setup of IPC Alert monitoring using sapccmsr is described in SAP Note 502461.
2005 SAP AG 87
Manual Monitoring
Tool Frequency
IPC REMOTE MONITOR Daily
Report IPC_MON_TOOL (Available in CRM 4.0 as of SP08) Daily
Details for IPC REMOTE MONITOR
Name and location/Transaction of IPC REMOTE MONITOR.

The IPC REMOTE Monitor can be started from the <IPC_HOME>\bin directory with monitor.bat.
The following screen is displayed after starting:
You can test the basic installation of an IPC Server, execute different commands, and get statistical
information from the server, etc. using the remote monitor.
2005 SAP AG 88
What is monitored by IPC REMOTE MONITOR

By executing different commands you can get a statistical overview of performance data for IPC
Servers known to the IPC Dispatcher:
This figure shows Information about memory usage, and session activity in the IPC Server.
If more Details are needed (such as the average execution time for all commands since IPC Server
Startup) you can switch on Command details and session details in the Stats tab.
For each command you will get the number of calls, average, maximum and minimum execution time.
2005 SAP AG 89
502461: CRM: CCMS agent plug-in for IPC
834919: CCMS IPC Monitor: Incorrect performance data
Details for IPC_MON_TOOL
Name and location for IPC_MON_TOOL

IPC_MON_TOOL is a report to monitor data available from IPC Servers addressable via RFC from a
CRM Server. It can be started by executing the report from transaction SA38.
What is monitored by IPC_MON_TOOL

In the report screen you see a navigation area which shows the RFC destinations for the IPC
Dispatcher and the IPC Servers registered with the dispatcher and the CRM Server.
Beneath the Server nodes you find nodes showing information about
Network Data
Kernel Parameters (version and configuration data are reported, sample values are shown
below)
o Version IPC4.0 SP09
o TTE Enabled true
o Database Alias XXX
o TTE Customizing Client 100
o Last refresh customizing 12.04.2005 06:03:12
o Archive-Date April 12 2005 at 0049 Hours
o Build-ID 4.0.08.200504120000.60205
o JCO MiddlewareLayer com.sap.mw.jco.rfc.MiddlewareRFC
o JCO MiddlewareVersion 2.1.4 (2004-10-20)
o JCO Version 2.1.4 (2004-10-20)
o JCO libjrfc Path D:\IPC\q4c\bin\sapjcorfc.dll
o Java File Encoding Cp1252
o Java VM 1.4.2_01-b06 Sun Microsystems Inc.
o Operating System Windows 2000 5.0 for x86
o Patch-Version IPC4.0_SP_TEST
o Specification-Title SAP Internet Pricing and Configurator Patch
o Specification-Vendor SAP AG, Walldorf
o Specification-Version 4.0
2005 SAP AG 90
Buffer entries (show how many buffer entries of the respective category are present in the
buffer)
o Procedure Object Manager 1
o Type Object Manager 39
o Limits Object Manager 0
o Condition Record Object Manager 206
Memory Information (VM memory usage for IPC)
o absolute Value in MB
o actual memory of the VM 127.44
o alocated memory of the VM 72.60
o free memory of the VM 54.83
o Values in percent
o allocated in % related to actual 57
o free in % related to actual 43
Server parameter
Memory Progress
2005 SAP AG 91

IC Workforce Management
Alert Monitoring for IC Workforce Management
Basics
The Interaction Center (IC) Workforce Management (WFM) Alert Monitoring was implemented based
on the CCMS Alert Monitoring infrastructure. It can be called via transaction RZ20 where it is available
under the "SAP CRM Monitor Templates" monitor sets with the name "Component Monitor: IC
Workforce Management".
The Component Monitor of IC Workforce Management observes the topics below within the IC
Workforce Management components (IC WFM Application Server and IC WFM Calculation Server)
and generates alerts if critical situations occur. The information is displayed as a tree structure in the
monitor and the alerts are assigned to the corresponding nodes. For more information on the single
topics, use the F1 help for the node in the monitoring tree. The components IC WFM Application
Server and IC WFM Calculation Server fully support standard SAP CRM Monitoring Templates for
monitoring on your central monitoring (Solution Manager) system:
Automated Log files
Configuration
Component Version information

The IC WFM Application Server is monitored for availability/heartbeat only. The IC WFM
Calculation Server is monitored for Calculation Services (CS), Dispatcher Service (DS) and the
connection to the CRM 4.0 system.

The version and configuration information for the Application Server and Calculation Server are
displayed in different nodes for each server.
The information displayed is structured in both a node version and configuration version.
The version node CRM.IC WFM.AS Version contains:

Component name: CRM.ICWFM.AS
Application Name: Interaction Center Workforce Management
Major and minor Version
Support Package
Build Time: Time stamp for the build currently in use
SAP change list number
Additional Information
2005 SAP AG 92
The configuration node CRM.IC WFM.AS Config contains:

JMS: The URL of the server hosting JMS Services.
This URL is also the address of the central Calculation Server
Calculation Request: Displays the name of the Calculation Request JMS Queue
Calculation Status: Displays the name of the Calculation Status JMS Queue
The version node CRM.IC WFM.CS Version contains:

Component name: CRM.IC WFM.CS
Application Name: Interaction Center Workforce Management
Major and minor Version
Support Package
Build Time: Time stamp for the build currently in use
SAP change list number
Additional Information
The configuration node CRM.IC WFM.CS Config contains:

Allocated/Total CPUs: The number of CPUs that the IC WFM CS is allowed to use, along with
the total number of CPUs present on the server.
CS ID: A unique identifier assigned to this instance of the Calculation Server
CS Start Mode and DS Start Mode: The startup mode for the Calculation Server (CS) and the
Dispatcher Service (DS). Possible values are Automatic, Manual or Delayed.
If the selection is delayed, the delay time is displayed.
Fail-over Ping Time: The interval time (in seconds) at which a self-test is performed to
determine if the dispatcher service is running.
JMS Server: Host name of the Calculation Server where the central JMS Service is running.
This host name is the same as that of the Central Calculation Server.
JMS User Name: The user name used to connect to JMS services.
R/3 Client: Client number of the CRM 4.0 system that is used by the Calculation Server.
R/3 System Name: System name of the CRM 4.0 system that is used by the Calculation
Server.
R/3 System Number: System number of the CRM 4.0 system that is used by the Calculation
Server.
R/3 User Displays: The user name used when connecting to the CRM 4.0 system that is used
by the Calculation Server.
Speed Rating: Speed rating assigned to the host where the Calculation Server is running.
2005 SAP AG 93

Standard Logfile monitoring templates allow monitoring logs of the Application Server and the
Calculation Server for all messages of severity (type) ERROR and specifically for messages with
certain Log message IDs.
For the Application Server the message IDs 1020 (for errors when connecting to the CRM 4.0 back-
end), 1079 (for errors while trying to obtain JMS connection to IC WFM Calculation Server) and
1080 (for errors while trying to obtain JMS context information from JNDI Service) are enabled, for
the Calculation Server the message ID 4201 (indicating a failed calculation request).
It is possible to enhance the number of displayed log messages adding the log message IDs to the
standard Logfile monitoring template. You can activate logfile monitoring for each instance of IC WFM
Application Server and IC WFM Calculation Server running on a different host.
Central Logfile Viewing

IC WFM components (IC WFM Application Server and IC WFM Calculation Server) fully support
standard SAP CRM Monitoring Templates for monitoring on your central monitoring (Solution
Manager) system.
Setup
The setup of alert monitoring for IC Workforce Management is described in the Solution Management
Guide mySAP Interaction Center Workforce Management Release 4.0.
Manual Monitoring
Tool Frequency
IC WFM Application Server Log Upon problem analysis.
IC WFM Calculation Server Log Upon problem analysis.
Details for IC WFM Application Server Log
Name and location of IC WFM Application Server Log

The path and filename of the IC WFM Application Server Log are listed below:
DIRECTORY="/<J2EE Engine
Directory>/cluster/server/services/servlet_jsp/work/jspTemp/sis/root/WEB-INF/logs"
FILENAME="sis.log*"
Data of IC WFM Application Server Log

IC WFM Application Server Log messages and message IDs are described in the
Solution Management Guide mySAP Interaction Center Workforce Management Release 4.0.
788084: No iceLogs in http://<server>:<http_port>/sisopt/logs.jsp
811027: No iceLogs in http://<server>:<http_port>/sisopt/logs.jsp
2005 SAP AG 94
Details for Monitoring IC WFM Calculation Server Log
Name and Location/Transaction of IC WFM Calculation Server Log

The path and filename of the IC WFM Application Server Log are listed below:
DIRECTORY="/<J2EE Engine Directory>/cluster/server"
FILENAME="iceLog*"
Consult IC WFM Application Server Log messages and message IDs (page 37 ff), or
IC WFM Calculation Server Log messages and message IDs (page 40 ff) for detailed description of all
errors and log messages.
Data of IC WFM Calculation Server Log (like Logsize)

IC WFM Calculation Server Log messages and message IDs are described in the
Solution Management Guide mySAP Interaction Center Workforce Management Release 4.0.
2005 SAP AG 95

Content Server
Alert Monitoring for Content Server
Basics
The SAP Content Server is based on the SAP DB database and is available on Windows NT Server
and Windows 2000 Server. The basis of the SAP Content Server is the content server engine which is
implemented as an ISAPI extension in Microsoft Internet Information Server. Content is saved to the
SAB DB.
Besides a Content Server there may be one or more Cache Servers which are used to increase
throughput. Cache servers are similar to Content Servers, but require less administration.
Monitoring must be done for the Cache/Content Server Database and for the Cache/Content Server
Engine.
CCMS
The availability of each Content Server Engine can be monitored via CCMS. For that the table
SCMS_SERCS has to be maintained. (For details about the entries that have to be maintained see
OSS Note 484459).
Cache Server monitoring is initiated by maintaining table SCMS_SERCA and SCMS_SERPX.
With these entries the Content/Cache Servers are defined for CCMS.
After maintaining the tables availability monitoring through CCMS starts automatically.
With Report RSCMSSV the availability status of the monitored servers can be directly checked.
Version
By selecting the monitoring tree element for the Content Server, general information like the version
can be retrieved.
Setup
Setup for monitoring the Content server is described in OSS Note 484459.
2005 SAP AG 96
Manual Monitoring
Tool Frequency
Transaction CSADMIN Daily
Database Manager GUI Daily
Details for Transaction CSADMIN

Transaction CSADMIN is executed on the CRM Server and opens the Content Server Administration.
Here the status for all content server databases can be checked.
Additionally the following information can be retrieved:
General information on the Content Server and Cache Server
Detailed information on the individual content repositories and cache servers
Certificates of the individual content repositories
Settings of the individual content repositories
Content server and cache server statistics
Details for Database Manager GUI

The Database manager GUI is an external tool which is shipped with the installation CD for
SAP DB / MAX DB.
This tool is used, among other things, for monitoring the fill level of the database as well as the
logspaces. Neither database space nor logspace should reach a fill level of 100%.
484459: Downtime management for content servers
511866: Content Server Monitoring
2005 SAP AG 97

CAT Server
Alert Monitoring for CAT Server
Basics
With CRM 4.0 SP03, the CAT Server functionality has been integrated into CRM Server (internal CAT
Server). This make the external Java based installation of the CAT Server (external CAT Server)
obsolete. The external CAT Server is only necessary in the cases mentioned below (for details see
SAP-note 687094):
CRM 4.0 SP03 or newer is not used
FOP/PDF has to be enabled
XSLT programs which use statements that are not yet supported by the internal ABAP XSLT
processor
You need to process very huge XSLT programs or XSLT programs
In contrast to the internal CAT Server, which needs no alert monitoring, the external CAT Server can
use CCMS monitoring.
The CAT Server Alert Monitoring was implemented based on the CCMS Alert Monitoring infrastructure.
It can be called via transaction RZ20 where it is available under the "SAP CRM Monitor Templates"
monitor sets with the name "Component Monitor: CAT Server".
CAT Server Alert Monitoring fully supports standard SAP CRM Monitoring Templates for monitoring on
your central monitoring (Solution Manager) system:
Component version information

The CAT Server server is monitored for availability/heartbeat only.

Version and configuration information for the Application Server and Calculation Server are displayed
in different nodes for each server.
The information displayed is structured in both nodes, Version and Configuration, and contains:
Specification Title, Vendor and Version
Implementation Title, Vendor and Version
host.adress and host.name
cat.javax.xml.parsers.SAXParserFactory
cat.javax.xml.transform.TransformerFacto
Setup
Setup of the alert monitoring for the CAT Server is described in the CRM Monitoring Installation Guide
4.0 SR1, NetWeaver04 and CRM Monitoring Installation Guide 4.0 on SAP Web AS Java Release
6.20.
2005 SAP AG 98
Monitoring for Component MapBox

Alert Monitoring for the MapBox
Basics
Starting with CRM 4.0 SP04 the MapBox runs as an application on top of the J2EE engine.
Alert Monitoring for the MapBox is based on the SAP CCMS Monitoring Infrastructure.
After calling transaction RZ20 the monitoring details for the MapBox can be found under J2EE
Applications under the respective J2EE node.

The following information concerning the state of the MapBox is available in RZ20:
Reason for Failure: In case of failed message processing by the MapBox the reason for the failure is
displayed in this monitoring segment
Queues: Information about the queue that the message currently being processed belongs to
JobID: Internal number which is needed to map the message processed by the MapBox to the
corresponding entry in the log file
Time/Message: Performance information (time in seconds) needed for message processing

The following information concerning versions is available in RZ20:
Component: The component in SAP Service Marketplace(= CRM-MW-MBX)
Application: Simply the application name MapBox
Support Package: Current Support Package level
Major Version/ Minor Version: Details about deployed version
The following information concerning configuration is available in RZ20:

CoordServer Host: Hostname of the Coordination Server
CoordServer Port: RMI (Remote Method Invocation) port used to connect to the Coordination Server
(1099 by default)
CoordServer Log: Log level of the Coordination Server (recommended to keep default value of 1)
CoordServer Polling Interval: Polling Interval (in seconds) to ask for shutdown of the Coordination
Server (recommended to keep default value of 30)
CoordServer Clean-up Interval: Cleanup Interval (in seconds) to check for invalid locks created by
MapBoxLauncher (recommended to keep default value of 60)
JCo Message Server: Hostname of the Message Server used by the MapBoxLauncher
JCo SAP Gateway: SAP Gateway address used by the MapBoxLauncher.
JCo Trace Level: Trace level for the SAP Java Connector (recommended value in production is 0)
Connection Destination: Name of the RFC Destination where the MapBox is registered
Connection User: Username for the RFC Destination
Connection language: Language for the RFC Destination
MapLog Level: Log level for internal log files of the MapBox (higher level means more details)
2005 SAP AG 99
Message Dumps: If this is set to Yes, then the MapBoxLauncher dumps incoming and outgoing
messages on the file system (recommended to keep default value No for performance reasons)
Setup
The setup for the MapBox is best done using the corresponding installation guide for CCMS
monitoring which can be found at http://service.sap.com/crm-inst and then selecting General and
Technical Installation Guides.
The guides correspond to the respective J2EE Engine version (Either 6.20 or 6.40).
Further Information
Troubleshooting
If applying the recommendations and executing the respective procedures documented in this
Best Practice did not produce the desired results and your production is endangered, please
contact SAP
Background Information and References

The information contained in this document has been assembled and compiled by the SAP Active
Global Support (AGS) Technology Center of Expertise (CoE).
We drew our information from the following primary sources:
SAP Online Help portal
SAP Installation and administration handbooks
SAP Notes
OEM documentation
Feedback and Questions

Send any feedback by formulating an SAP customer message to component SV-GST-SMC. You can
do this at http://service.sap.com/message.
2005 SAP AG 100

Copyright 2005 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express
permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of
other software vendors.
Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of
Microsoft Corporation.

IBM , DB2 , OS/2 , DB2/6000 , Parallel Sysplex , MVS/ESA , RS/6000 , AIX , S/390 , AS/400 , OS/390 , and

OS/400 are registered trademarks of IBM Corporation.

ORACLE is a registered trademark of ORACLE Corporation.
TM

INFORMIX -OnLine for SAP and Informix Dynamic Server are registered trademarks of Informix Software
Incorporated.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C , World Wide Web Consortium,
Massachusetts Institute of Technology.
JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun
Microsystems, Inc., used under license for technology invented and implemented by Netscape.
SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch,
BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered
trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned
are trademarks or registered trademarks of their respective companies.
Disclaimer: SAP AG assumes no responsibility for errors or omissions in these materials. These materials are
provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied
warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or
consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or
completeness of the information, text, graphics, links or other items contained within these materials. SAP has no
control over the information that you may access through the use of hot links contained in these materials and
does not endorse your use of third party Web pages nor provide any warranty whatsoever relating to third party
Web pages.
2005 SAP AG 101

Middleware Monitoring

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Middleware Monitoring

Enviado por

Direitos autorais:

Formatos disponíveis

Best Practice for Solution Management: CRM 4.

CRM 4.0 Monitoring

Version Date: June 2005

Applicability, Goals, and Requirements

Goal of Using this Service

Staff and Skills Requirements

Duration and Timing

Best Practice Procedure and Verification

Monitoring for Component Middleware

Alert monitoring for Middleware

CRM Middleware Monitoring Cockpit

Replication and realignment queues

Processing Status of BDoc Messages

CCMS Alert Monitoring for qRFC Communications in the CRM System:

CCMS Alert Monitoring for qRFC Communications in the R/3 System:

Tool Description Frequency

SMQR Inbound Queue Scheduler Upon error

SMQS Outbound Queue Scheduler Upon error

SM58 TRFC Monitor Upon error

Details of the CRM Middleware Monitoring Cockpit

What is monitored by transaction SMWP?

Section Generation Information contains

o Collecting for Monitoring Cockpit:

GREEN: job is running

Description of Using the Monitor SMWP

Details for Monitoring Processing Status of BDoc Messages

What is monitored by transaction SMW01?

Description of Using the Monitor SMW01

Checking the receiver list

Display the object links.

Select BDoc Message Reprocess Reprocess

Show Error/Receiver- functionality:

Details for Monitoring BDoc Message Summary

What is monitored by transaction SMW02?

Description of Using the Monitor SMW02

Details for Monitoring BDoc Message Error Analysis

What is monitored by transaction SMW02A?

Description of Using the Monitor SMW02A

Details for Summary of unprocessed BDoc Messages

What is monitored by transaction SMW03?

Description of Using the Monitor SMW03

Details of Monitoring Middleware Trace

What is monitored by transaction SMWT?

Settings (like Trace levels etc.)

Description of Using the Monitor SMWT

Details of Error Handling Settings

What is monitored by transaction SMW00?

Description of Using the Monitor SMW00

Details of Display Message Flow Statistic

Name and Location/Transaction of SMWMFLOW

What is monitored by transaction SMWMFLOW?

Description of Using the Monitor SMWMFLOW

Data of SMWMFLOW (like Logsize)

Details for Display and Check Flow Definitions

What is monitored by transaction SMO8FD?

Description of Using the Monitor SMO8FD

Details of Check Replication Relevant Objects

What is monitored by transaction SMOECK?

Description of Using the Monitor SMOECK

Details for Monitoring Replication/Realignment

What is monitored by transaction SMOHQUEUE?

Description of Using the Monitor SMOHQUEUE

Details of Monitoring Initial Load

What is monitored by transaction R3AM1?