MySAP CRM Mobile Sales Monitoring

mySAP CRM Mobile Sales Monitoring
Best Practice for Solution Management

Version Date: May 2001
The newest version of this Best Practice can be obtained through
the SAP Solution Manager or the SAP Service Marketplace.
Contents
Applicability, Goals, and Requirements ....................................................................................................1
Best Practice Procedure and Verification .................................................................................................6
Preliminary Tasks ...............................................................................................................................6
Monitoring Concepts ....................................................................................................................6
Procedure .........................................................................................................................................11
R/3 OLTP System Monitoring.....................................................................................................11
CRM Middleware Component Monitoring ..................................................................................12
Communication Station / Admin Station Monitoring ...................................................................19
Mobile Client Monitoring.............................................................................................................24
Verification ........................................................................................................................................25
Further Information .................................................................................................................................41
Feedback and Questions........................................................................................................................51
Applicability, Goals, and Requirements

A Best Practice may not be applicable in some situations. To ensure that this Best Practice is the
one that is needed in your situation, consider the following goals and requirements.
Goal of Using this Service

The goal of this Best Practice is to document and recommend procedures:
For identifying system conditions that can lead to business process standstill, loss of
production, or inefficient system operations
For troubleshooting system problems
For defining threshold values for specific system operations
For facilitating good system operations practices
The general monitoring goals are to be able to:

Measure performance of data exchanges
Detect documents in an error status
Detect an inconsistent status in the sender and receiver system
Refer to reliable procedures for error handling
2001 SAP AG
Best Practice: CRM (Mobile Sales) Monitoring 2
Normally, monitoring objects and their attributes are displayed in the alert monitors. However,
some interface points must be checked using generic tools and procedures. These are also
described in this document.
Staff and Skills Requirements

System administrators with training for the mySAP CRM Mobile Sales and mySAP CRM Mobile
Service solutions.
System Requirements
System landscape comparable to that described below in the case study.
Case Study
In this document, SAP System monitoring is discussed within the context of the mySAP CRM
Mobile Sales environment as implemented at a large German company.
The business solution consists of the following components:
mySAP CRM Mobile Sales business processes
Sales order processing
Availability of sales order processing solution
Solution landscape
Software components
Hardware components
User frontends
System availability
In this document, the mySAP CRM Mobile Sales solution is called CRM-MSA. The SAP R/3
application system is referred to as the R/3 OLTP System.
The business process flow in the CRM-MSA environment is shown on the next page.
Business Process: Sales Order Processing (CRM-MSA)
Mobile Client CRM Middleware R/3 OLTP System

System (CDB)
Create
Sales
Order
BDoc In Queue
Create R/3 Sales Order

Upload w/ Pricing & ATP
Sales Process BDocs
Client
InQueue Orders
Delivery Due List

BDoc Out Queue
Post Goods Issue
Billing Due List
2001 SAP AG
Business Process Description

1. Sales person creates an order for one of his customers.
2. Every night (between 17:00 19:00 hrs) the sales person connects to the CRM Middleware
server in order to upload his sales orders.
3. The sales orders are transferred to R/3 and during the process the CRM Middleware
Consolidated Database (CDB) is updated.
4. An SD sales order is created in the R/3 OLTP system based on the information from the
Middleware server.
5. During this process, within the R/3 System, the sales order creates additional information,
such as pricing information and availability.
6. The sales order is accepted from R/3 and then processed or refused (for example, for
exceeding the credit limit).
7. The R/3 System sends the confirmation or the refusal information to the Middleware.
8. The Middleware server updates the CDB and puts the information to update the mobile clients
database into the clients outbound queue on the CRM server.
9. The mobile client picks up its data from the CRM server.
Sales Order Processing Availability

The table below describes the availability of sales order processing.
Process Availability Online Background Peak Times

Processing Processing
07:00 - 09:00 h (daily)
Sales Order
6 x 24 100% <None> 17:00 - 19:00 h (daily)
Processing
September (peak season)
Technical Process Flow Overview

The table below details the process flow used for transferring data from a mobile client to the OLTP
system. It is based on the standard SAP business process steps as described above in the standard
sales order processing scenario.
This general description can be applied to most communications between the mobile clients and the
OLTP and/or CRM Systems.
Sales orders are used as the BDoc message type being transferred between the Mobile Client and
the R/3 OLTP System. BDocs can also be other types of data that are transferred between the Mobile
Client and the CRM System (such as system information and administrative information).
Active System Action Interface

Mobile Client - Sales order created
- Sales order is stored in the clients outbound queue as BDoc
Mobile Client - Connection handler started to receive/transmit BDocs Mobile Client
- BDoc transmission to CRM System initiated Comm Station
Comm Station - Protocol conversion (LDAP to RFC) Comm Station

- Forward BDoc to specific inbound-client queue in CRM system CRM
CRM Server - Process data from inbound-client queues CRM OLTP

- Update CRM - CDB
- Forward sales order to OLTP via CRM outbound queue
R/3 OLTP - Process data received from CRM via OLTP inbound queue OLTP CRM
System - Create sales order
- Process sales order per order management system
- Send confirmation/refusal of sales order to CRM via OLTP
2001 SAP AG
Active System Action Interface

outbound queue
CRM MW - Process data received from OLTP via CRM inbound queue
System - Update CRM - CDB
- Put sales order info into specific outbound-client queue for Mobile
Client
Mobile Client - Connection handler started to receive/transmit BDocs Mobile Client
- MTS client-request transmitted to CRM System Comm. Station

- Forward MTS client-request to CRM system CRM
CRM MW - MTS client-request picks-up the messages from the client-specific CRM
System outbound queue on the CRM Server and sends the data to the Comm. Station
mobile client
- Forward client data to requesting mobile client Mobile Client
Mobile Client - Data from CRM System is put into the client-side inbound queue
- Mobile Client processes the data from its inbound queue
(database update and so on)
CDB = Consolidated Database on the CRM Middleware server, MTS = Message Transfer Service
(MTS client on the Mobile Client, MTS server on the Communication Station)
Solution Landscape
This section provides an overview of the solution landscape used during the analysis period:
SAP components and their release levels
Server hardware in use
User frontends
System availability is shown
Software Components
SAP Components on the CRM Middleware, Communication Station, and Mobile Client Servers
Components Release SAP Basis Kernel Components / Patch
Release Database
Release Levels
BBP/CRM
CRM Middleware 2.0B 4.6C 4.6D Oracle ABA
Basis
DCOM-Connector 2.0B - - -
Admin-Console 2.0B - - -
Mobile Client(s) 2.0B - - MS SQL
In the case study, 12 mobile clients were in productive use during the analysis period. Client
MC_REP1 is listed in this table as an example of what is installed on the other mobile clients.
The DCOM Connector and Admin Console components are installed on the same server.
2001 SAP AG
SAP Components on the R/3 OLTP System
SAP Kernel SAP Database Components

Basis Release Applications
Release
4.6B 4.6D FI, CO, MM, PP, PS, SD Oracle SAP_ABA 46B
SAP_BASIS 46B
SAP_HR 46B
SAP_APPL 46B
PI 2000_1_46B
Hardware Components
Hardware components of the CRM-MSA server landscape
Server Role OS system
CRM Middleware System Central Instance & DB Server Unix
CRM Middleware System Application Server (1 server) Unix
Communication Station Windows NT
Mobile Client(s) (Laptop PCs) Windows NT

R/3 OLTP System Central Instance & DB Server Unix
R/3 OLTP System Application Servers (total of 5 servers) Unix
User Frontends
User frontends used during the analysis period
SAP Frontend type Operating System Release Connection Type /

Platform Network environment
SAPGUI for Windows Windows 95 and Windows NT 4.6C LAN
SAP Mobile clients Windows NT 2.0B Dial-In (ISDN)
System Availability
The system availability plan for the CRM-MSA environment
System Name Availability Online Background Maintenance Window Peak time
Processing processing
Saturday: 20:00
R/3 OLTP Reboot+ 20:00-22:00
6 x 24 Day profile Night profile
System Offline backup at the (November)
same time with CRM
Saturday: 20:00
CRM Reboot+ 07:00-09:00 +
Online
Middleware 6 x 24 Offline backup 17:00-19:00
Process Only
System at the same time with (November)
OLTP
Comm 07.00-09:00 +
6 x 24 - - Daily backup
Station 17:00-19:00
07:00-09:00 +
Mobile Daily backup on
6 x 24 - - 17:00-19:00
client(s) CD ROM
(November)
2001 SAP AG
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
Monitoring Concepts
Monitoring in the mySAP CRM-MSA environment can be divided into the following areas:
Monitoring the end-to-end message flow from the mobile clients to the R/3 OLTP System
Monitoring transactional RFC requests
Monitoring the queues located on the respective server systems
Monitor the R/3 Adapter components
Download objects, log file, queues, requests
Operating system performance monitoring
Database system performance monitoring
Error analysis
The following table briefly lists the CRM-MSA server components and the monitoring functions
associated with them.
Server Types Monitoring Function

Mobile Client 1. Monitor outbound queue, Mobile Client Comm Station
2. Monitor inbound queue, Comm Station Mobile Client
3. Monitor database
4. Monitor operating system
5. Monitor network throughput, Mobile Client Comm Station
Communication 1. Monitor message flow from all Mobile Clients CRM Middleware System
Station
2. Monitor network throughput, Mobile Client CRM Middleware System
R/3 OLTP System 1. Monitor outbound queue, R/3 OLTP System CRM Middleware System
2. Monitor Gateway
3. Monitor R/3 Basis System
4. Monitor database
6. Monitor network throughput
2001 SAP AG
CRM Middleware 1. Monitor outbound queue, CRM Middleware System Mobile Client
Server
2. Monitor inbound queue, Mobile Client CRM Middleware System
3. Monitor outbound queue, CRM Middleware System R/3 OLTP System
4. Monitor inbound queue, R/3 OLTP System CRM Middleware System
5. Replication and realignment queue monitoring
6. Monitor Middleware message flow
7. Monitor flow control
8. Monitor the Middleware log
9. Monitor status of BDocs
10. Monitor initial download from R/3 OLTP System
11. Monitor R/3 Basis System
12. Monitor database
14. Monitor network throughput
The following graphic represents the CRM MSA server landscape. It details the monitoring interface
points on the servers.
2001 SAP AG
Business Process Monitoring in the CRM MSA Server Landscape
SMQ2
DCOM Connector Monitor SMQR
TransferService.log SMQ2
SMQ1
QMTCHECK
Comm. CRM MW R/3 OLTP

Mobile Station Server System
Inbound Outbound Inbound
Business Queue
Queue Queue
Processing SAP
Business
DCOM Processing
Outbound Connector Inbound Outbound
Queue Queue Queue
DB & Replication and

Log Realignment Queue
Log Flow / Process Control

Engine & other services
R/3 Application
Database
CDB
MS Windows NT MS Windows NT SMWMFLOW SMQ1

Performance Monitor Performance Monitor
SMO8FT
ST03
SMOHQUEUE
DB02
SM58
ST06
SM50 / SM66
SM58
Non CRM-specific SAP System monitoring transactions:
ST02, ST04, SM21, SMGW, SM13, STAT
8
R/3 OLTP System Monitoring
The SAP R/3 OLTP System is used for the processing of sales orders and as the central repository for
system data.
In its role as the lead system, the R/3 OLTP System can also be referred to as the SAP Backend
system or as the SAP Application System. In all 3 cases the same system is referred to.
After the CRM Middleware system has been installed and the initial download has been performed
successfully, system load on the R/3 OLTP System can be categorized as follows:
OLTP System CRM System

Delta downloads
Using arbitrary users at arbitrary times
Regular communications using qRFCs
CRM System OLTP System

Delta uploads
Using a single user defined when the individual RFC destinations are defined
(CPIC user type, SM59 and SU01)
Regular communications using tRFCs
OLTP Server Monitoring Points of Interface

The following diagram shows the main points of interface on the R/3 OLTP System. The transactions
used to monitor these interface points are listed along with a brief label describing their function.
2001 SAP AG
Monitoring the R/3 OLTP Server
SMQ2

Business Queue
Queue Queue
Processing SAP
Business
DCOM Processing
Queue Queue Queue


R/3 Application
Database
CDB
SMQ1
ST03
DB02
ST06
SM50 / SM66
SM58
SMGW
ST22
2001 SAP AG
Procedure
R/3 OLTP System Monitoring

The table below shows which transactions to use to monitor the R/3 OLTP System.
Some types of monitoring are specific to CRM-MSA, some use a combination of CRM-MSA and
generic monitoring methods, and some are generic SAP System performance monitors.
R/3 OLTP System Monitoring Transaction Monitoring Frequency
Queue Monitoring Activities / Functions Code Periods and Events
qRFC Outbound Queue Monitor SMQ1 Hourly
Monitor communications going from R/3 OLTP Daily
System CRM System
Upon error
Queues should be relatively short and quickly
During Mass
processed
Updates
Check if the qRFC Version is up to date (see SAP
Notes 166096 and 366735)
qRFC Inbound Queue Monitor SMQ2 Upon error
Monitor communications from CRM System R/3
OLTP System
Messages flow through the inbound queue on the
OLTP system and are immediately processed
Normally SMQ2 should show an empty list
R/3 OLTP System Transaction Monitoring Frequency

General Monitoring Activities / Functions Code Periods and Events
Gateway Monitor / Connection List SMGW Weekly
Monitor the active connections to other servers Upon error
Check the SAP return code and CPI-C return
code values for errors
R/3 System Buffer Monitor ST02 Weekly
Monitor memory resource usage for specific R/3 Upon error
application servers
Implement parameter recommendations for ROLL
area and PAGE area per EarlyWatch analysis
Use normal R/3 System monitoring practices
R/3 System Workload Analysis ST03 Daily
Monitor RFC response time statistics for CRM Upon error
Database Performance Analysis ST04 Weekly
Monitor database statistics Upon error
Database Performance Monitor DB02 Daily
Monitor indices on tRFC and aRFC tables Upon error
Monitor the current size of tRFC and qRFC (see SAP
note 375566)
Threshold < 500 MB
Reorganize the tables regularly
Operating System Monitor ST06 Hourly
Monitor hardware load during high RFC transmission Daily
times Upon error
2001 SAP AG
R/3 OLTP System Transaction Monitoring Frequency
General Monitoring Activities / Functions Code Periods and Events
Local Work Process Overview SM50 Hourly
Monitor current state of individual work processes Daily
Ensure that enough work process capacity is Upon error
available at peak times
System-wide Work Process Overview SM66 Hourly
Similar to SM50 but for system-wide statistics Daily
Upon error
ABAP Dump Analysis ST22 Daily
Analyze aborted programs Upon error
System Log SM21 Daily
Check for general system errors Upon error
Update Errors SM13 Daily
Check for entries that have ERR status Upon error
Display Statistical Records STAT Daily
Determine the status of update records Upon error
R/3 OLTP System Parameter Settings

Table CRMPAROLTP is the primary parameter table for the R/3 OLTP System in the CRM-MSA
environment. This table is customized during system installation and is normally not changed during
system operations.
Here is a sample of how the CRMPAROLTP table is setup. The actual CRMPAROLTP is client
dependent and significantly larger than this example.
Parameter Name Parameter Parameter Parameter ParaValue 2

Name 2 Name 3 Value
APO_MATGUID_ACTIVE X
CRM_COND_DELTA_BLOCKSIZE 1000
CRM_DEFAULT_DESTINATION AB1_ABC
CRM_EVENT_ACTIVE X
CRM_SEND_MSG_IMMEDIATELY
Scheduling Background Jobs

There are no CRM-specific background jobs to schedule on the R/3 OLTP System.
CRM Middleware Component Monitoring

To prevent data inconsistency you need to monitor the interfaces regularly for aborted or stopped
transfer of documents.
CRM Server Monitoring Points of Interface

The following diagram shows the main points of interface on the CRM Middleware Server. The
transactions used to monitor these interface points are listed along with a brief label describing their
function.
These transactions and interface points are discussed in the following sections.
12
SMQ2
Monitoring the SMQR
CRM Middleware Server SMWMQUEUES
SMQ1

Business Queue
Queue Queue
Processing SAP
Business
DCOM Processing
Queue Queue Queue

Log
Realignment Queue
Log
file Flow / Process Control
R/3 Application
Database
CDB
SMWMFLOW
SMO8FT
SMW01/SMW02
SMOHQUEUE
SM58
2001 SAP AG
CRM Middleware System Monitoring Transactions and Procedures
The table below lists transactions used in monitoring the CRM Middleware system.
CRM Middleware System Monitoring Monitoring Frequency

Queue Monitoring Activities / Functions Type Periods and Events
qRFC Outbound Queue Monitor SMQ1 Hourly
Monitor data transmission between the R/3 OLTP Daily
System and the CRM System and between the
CRM System and Mobile Clients
Queues destined for the OLTP system should be
relatively short and quickly processed
Queues destined for the Mobile Clients remain in
the queue until each client picks-up its data
When the queue entries for a 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 in
these cases.
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 client cannot be manually
rebuilt, it can be brought back into a consistent
state by rebuilding the client data from the CDB
(AC_EXTRACT)
qRFC Inbound Queue Monitor SMQ2 Hourly
Monitor data transmission between the R/3 OLTP Daily
System and the CRM System and between Mobile
Clients and the CRM System
Messages in the inbound queue are processed
according to the capacity of the CRM Middlware
System.
High number of entries in the inbound queue can
indicate insufficient capacity on the Middleware
System
Queue Information for CRM Client Sites SMWMQUEUES Upon error
Display all the mobile sites defined in the CRM
System together with the name of the queue
assigned to each of these sites
2001 SAP AG
Queue Monitoring Activities / Functions Type Periods and Events
Scheduler Status SMQR Hourly
This transaction runs the scheduler for checking Daily
the inbound queues on the CRM Middleware
Server Upon error
Ensure that all inbound queues are registered (type
R).
Register them, if necessary, using transaction
SMQR
If a queue is registered and has not been
processed for a long time the administrator has to
check the reason for it.
Possible middleware scheduler problems may
exist.
Check maximum processing time of the inbound
queues
Set the maximum processing time of a queue
("Max-time") to 5 seconds for all queues during
normal operations
Replication Queues Monitor SMOHQUEUE Hourly
Displays information about the status and contents Daily
of the replication and realignment queues in the
clients defined in the CRM Middleware System
The EXTRACT queue shows to which clients a
specific BDoc will be distributed
To check status of the queues
o Deselect 'Display current client only' flag
o Press 'REFRESH' button
Search for queues with
o Status = Hold
o # of entries > 0 and a
o flash icon button in the right-most column
Correct the error situation indicated for the
indicated queues
Note: Do not press the trash icon button if it appears

next to an entry.
TRFC Monitoring SM58 Hourly
Monitor all transactional RFCs (tRFCs) processed Daily
on the middleware server (e.g. workflow)
SM58 is linked to from the Replication and
Realignment queues upon error in the EXTRACT
and/or AC_EXTRACT queue (click on the error
symbol)
15
Message Flow Monitoring Activities / Functions Type Periods and Events
Middleware Message Server flow monitoring SMWMFLOW Daily
Collects statistical data about the workload on the Upon error
middleware server caused by BDocs
Use this as a start-point for analysis of performance
problems
The message flow is a central function to monitor
BDocs in the Middleware System
Display statistics on the message flow within CRM
Middleware
Ensure that the middleware message flow statistics
are switched on
Ensure that the middleware kernel application
statistics are switched on ("MW" in column type
and "Middleware Message Hub Statistic" in column
Text, flag "act" is set)
BDoc Summary SMW01 / SMW02 Hourly

Application error analysis Daily
SMW01: Display the data of a BDoc and display Upon error
possible errors
SMW02: Display the processing BDocs according
to types and Last Service Reached. Errors are
highlighted in red-shading
Flow control trace monitoring SMO8FT Upon error
Developer Trace - useful in error situations
Middleware Log SMO8FA1 Upon error
(see also R3AM2)
Developer Log - should only be used in error
situations
Check Flow Definitions SMO8FDC After BDoc
Consistency Check for Flow Definitions changes or
changes in services
or flow
Upon error
16
R/3 Adapter / Download Monitoring Activities / Type Periods and Events
Functions
Monitor Download Status R3AM1 Upon errors after
Checks whether the initial download was initial download
completed successfully. Dependent on
Object status and actions: object status
o RED: refer to SAP Note 309734 for initial
download problem analysis
o YELLOW: initial download must still be
done
o GREEN: OK
Logfile Communications OLTP/Middleware R3AM2 Daily
Display of the log files for communication between
the OLTP System and the CRM System
Recommended to use instead of transaction
SMO8FT
Monitor Queue Status R3AM3 Monitor the
Monitors the Delta Download queues on OLTP outbound queue on
system the R/3 OLTP
System directly on
the OLTP via smq1
Monitor Request R3AM5 Upon error, if
Used in exceptional cases to bring the database databases are not
into a consistent state after a data lost in the CDB consistent and
request from OLTP
is necessary

General Monitoring Activities / Functions Type Periods and Events
R/3 System Workload Analysis ST03 Daily
Monitor RFC response time statistics for CRM Upon error
Local Work Process Overview SM50 Hourly
Monitor current state of individual work processes Upon error
Ensure that enough work process capacity is
available at peak times
System-wide Work Process Overview SM66 Hourly
Similar to SM50 but for system-wide statistics Daily
Upon error
R/3 System Buffer Monitor ST02 Weekly
Monitor memory resource usage for specific R/3
application servers
Use normal R/3 System monitoring practices
Operating System Monitor ST06 Hourly
Monitor hardware load during high RFC Daily
transmission times
Database Performance Monitor DB02 Daily
Monitor indices on tRFC and aRFC tables Upon error
17
General Monitoring Activities / Functions Type Periods and Events
Database Performance Analysis ST04 Hourly
Monitor database statistics Daily
ABAP Dump Analysis ST22 Daily
Analyze aborted programs Upon error
System Log SM21 Hourly
Check for general system errors Upon error
Gateway Monitor / Connection List SMGW Upon error
Monitor the active connections to other servers
Display gateway trace
Check the SAP return code and CPI-C return
code values for errors
Update Errors SM13 Hourly
Check for entries that have ERR status Upon error
Display Statistical Records STAT Upon error
Determine the status of update records
Settings of CRM Middleware Server Parameters

Table SMOFPARSFA contains the relevant Middleware parameters and is very important for a
correctly running system.
Settings of the parameters depend on the business scenario.
Current, experience-based parameter settings are checked during each SAP Service Session
(EarlyWatch, GoingLive, etc.). The SAP recommendations should be applied according to the
instructions given in the SAP Service report. The following parameters are important for CRM-MSA
and are provided here as an example.
Key Parameter Name PARVAL1
FLOW FLOWTRACE_ACTIVE <space>: Flow trace is deactivated

X: Flow trace is activated
CRMGENERAL LOGLEVEL E: Recommended value for all clients -

Only errors are recorded
R3A_COMMON CRM_USE_BULK_DURING_DELTA <space>
R3A_COMMON CRM_USE_BULK_DURING_INIT <space>: Recommended value after initial

download is finished
Scheduling Batch Jobs

Example: Middleware log reorganization
From the Middleware administration menu, you can reach the scheduler for Middleware log
reorganization. For logging, you can use various standard settings or your own settings. Some
standard variants: keep everything (especially errors) in the log for 1 day, 1 week, or 1 month, then
delete the data.
Menu path:
Middleware > Message Flow > Reorganization > Middleware Log > Schedule Job
18
Communication Station / Admin Station Monitoring
The Communication Station (Comm Station) is the link between the CRM Middleware server and the
Mobile Clients. The Comm Station is the server where the DCOM Connector component is installed.
The SAP system statistic collector daemons, SAPOSCOL and RFCOSCOL, run on the Comm Station
and gather hardware resource consumption data. Complementary programs run on the CRM
Middleware server and collect and display statistical data.
The Administration Station (Admin Station) is used for administering the Mobile Clients. Tasks such as
registering each mobile client and assigning site IDs and queue names are done on the Admin
Station. The Admin Station component is not processing-intensive and monitoring is not a primary
concern with it.
Technical Monitoring Transactions and Procedures

In the SAP CRM-MSA Release 2.0B implementation, the monitoring possibilities for the
Communication Station can be divided into 3 areas:
DCOM Connector monitor
Communication Log File: TransferService.Log
Windows NT Performance Monitor
The following diagram shows the areas of monitoring in respect to the Communication Station.
19
Monitoring the
Communication Station
DCOM Connector Monitor
TransferService.log

Business Queue
Queue Queue
Processing SAP
Business
DCOM Processing
Queue Queue Queue


R/3 Application
Database
MS Windows NT
Performance Monitor
CDB
2001 SAP AG
DCOM Connector Monitor
Use the following menu path to access the DCOM Connector component monitor: Start > Programs >
Middleware > DCOM Connector. Start the application and choose Monitor. The following tables
explain the different areas of the monitor.
View: Active Processes

Shows the active processes of the DCOM Connector
Column Headings Descriptions

Process ID
State Either active or terminated
Up since Time since process started
Pagefaults Number of pagefaults since startup
Working Set Size of the process actual working set in KB (kilobytes)
Peak Working Set Maximum working set of the process since startup
Virtual Memory Set actual size of the pagefile usage in KB
Peak Virtual Memory Maximum usage of the pagefile since startup in KB
View: Open Connections

Shows the open connections of the DCOM Connector
Column Headings Descriptions

Destination
State Initial: created but not yet allocated
Connecting: connecting to server
Active: allocated by an object
Pool: resource was returned to pool without cleanup
Cleaning: R/3 context is being released
Clean: resource was returned to pool in a clean state
Closed: resource is closed and not available
Sys Name of application server
Host Hostname of application server
ID System number (port number is 33## and 32##)
SAP User User ID in R/3
Rem. Vers. Version on application server
Rem. Codep. Code page on application server.
Proc. Process ID
hRfc Handle to RFC connection
Loc. Vers. Version of DCOM Connector
Loc. Codep. Code page of DCOM Connector
Conv. ID Conversation ID like in SAP gateway monitor
T
Calls Number of calls since startup
Last Function Name of last function being called
Communication Log File: TransferService.Log

The DCOM Connector component logs the communications between the mobile clients and the CRM
Middleware server in the TransferService.log file.
2001 SAP AG
The default file path is as follows:
C:\WINNT\TransferService.log
The TransferService.log file supplies the following data for each session. This data is stored and can
be displayed in text format on the local Comm Station server.
Session header data

Name and/or IP address of the DCOM Server
Date and time when the session was started (in UTC time)
Date and time when the session was closed
PID of the DCOM process
TID (thread ID) of the current session (PID and TID together are unique IDs for session)
Object ID (session ID)
Site name
Queue name
Name of the PC from which the session was opened
Name of the Windows user
Session status
Session performance data

Number of transactions sent to the R/3 System
Number of table entries sent to R/3
Number of transactions received from R/3
Number of table entries received from R/3
Compression rate for data received from client
Compression rate for data sent to client
Processing time on the DCOM Server for data received from R/3 and sent to the client
Processing time on the DCOM Server for data received from the client and sent to R/3
Session status
Detailed information for the functions Read, ReadConfirm, Send and SendConfirm:
Number of calls to R/3
R/3 response time
Network time between Mobile Client and DCOM Server
Response time of the client database
Transmission rate for communication of DCOM Server with R/3
Transmission rate for RFC communication between client and DCOM server
Access rate in the client database (bytes per second)
As of Release 2.0C, this can be displayed in the CRM Middleware system using transaction
SMWMCOMM.
See SAP Note 205270 for more information on:
TransferService.log file
QmtCnfg.exe, a Release 2.0C tool, which can be used to view the current trace level and log file
location
22
The Microsoft Windows Performance Monitor (PERFMON) is a performance-monitoring tool on
Windows NT and Windows 2000 systems.
PERFMON can be used on the Communication Station to analyze performance problems due to:
Total response time
Network time
Browser generation time
When analyzing network conditions, PERFMON should be run locally on the Comm. Station rather
than from a remote server. When running PERFMON from a remote server, network statistics can be
affected due to the network load caused by PERFMON itself. Other network-based applications, such
as PCAnywhere, also create a significant network load that may invalidate any network statistics
measured while connected.
Handling procedure for Performance Monitor:
Verify that the Performance Monitor is installed
Set up the counters and the log file (modify/set the log file and chart settings)
Ensure that no other services or programs are running that may impact the measurement (such as
programs causing network or CPU load).
Perform the measurement
Extract the relevant counters (export them to a file)
Calculate the relevant quantities
Interpret the results
For further details, go to www.microsoft.com > Support Knowledgebase and see the White Paper
Measuring performance-relevant data using PERFMON on Windows NT.
For a detailed description of the use of the MS Performance Monitor, see SAP Note 203845.
In Windows NT, to start PERFMON, choose Start > Run and enter PERFMON.
Set up PERFMON as follows.
1. Measure the CPU utilization on the server or PC.
From the PERFMON menu, choose Edit > Add to Chart / Add Item
Select in PERFMON: Object, Processor, Counter, % Processor Time
2. Determine the size of dataset transferred for analysis.
Select in PERFMON: Object, Network Interface, Counter, Bytes Received/sec
Note: Depending on the network connection, the name of the category and item of the above-
mentioned examples may differ. When selecting the network interface counter it is possible that
various instances (= lines) are offered. If you are not sure on which network line the traffic takes
place, choose all instances. You may have to start processes at the NT level monitoring network
traffic.
3. To start your analysis, monitor during the peak time when Mobile Clients are uploading to the CRM
Middleware System. To save the performance data and transfer it into a spreadsheet program,
choose File > Export Chart.
4. Evaluate your analysis.
23
Mobile Client Monitoring
Technical Monitoring Procedures

When a travelling sales person has data to upload or download they must establish a connection to
the CRM Middleware server via the Comm Station. For example, this may be done at the customer
site using an ISDN telephone line. The Comm Station maintains a connection to the CRM Middleware
System that also maintains a connection to the OLTP R/3 System (LAN configuration).
To establish the connection, the CONTRANS.EXE program is executed on the mobile client. Data from
the outbound queue of the mobile client is transferred through the Middleware software of the CRM
server to the R/3 OLTP System. This data can be customer orders and/or customer data, such as
when new customers are created on the Mobile Client.
The Mobile Clients have 4 areas of monitoring to consider:
QMTCHECK
ConnTrans
TransferService Log file
QMTCHECK.EXE
The QMTCheck program monitors the connection between the Mobile Client and the Communication
Station.
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 copied to the inbound queue on the CRM system.
The Inbound and Outbound Queues of the Mobile Client can only be monitored on the mobile client
using the program QMTCHECK.EXE
Default file path: C:\Program Files\sap\mobile\bin\qmtcheck.exe
Usage
To connect to the client's database, click Open DB Connection.
To update the Mobile Client Queue status, click Update View.
ConnTrans - Data Exchange and Restart Queues

The ConnTrans program is used to connect the Mobile Client to the CRM Middleware System and to
restart the data queues that hold messages bound for the CRM Middleware System.
Functions
Send and receive messages to the CRM Middleware system
Shows status of data transmissions
Restart inbound and outbound queues processing
When the ConnTrans program is started, or restarted, previously unprocessed inbound and outbound
queue entries will be processed.
After connection to the CRM system the outbound queue empties. Entries remain in the outbound
queue until they are successfully copied to the inbound queue of the CRM system. Entries that remain
in the client outbound queue after ConnTrans was started have not been processed.
The inbound queue of the mobile client should also be empty after running ConnTrans. Entries that
remain in the client inbound queue after ConnTrans was started have not been processed.
Both the Mobile Client outbound and inbound queues should be empty within a relatively short time
after ConnTrans has been started.
Usage
On the Mobile Client, choose Start > Programs > SAP CRM Mobile Client > ConnTrans.
24
TransferService.log file
File logs the communications between the Mobile Client and the Comm Station.
The format of the TransferService.log file on the Mobile Client is not so clearly self-documenting as the
log file on the Comm Station.
In most cases the client log file should not be analyzed until after analyzing the Comm. Station
TransferService.log file. Although both files have the same name, their formats are very different. The
log file on the Comm Station is documented in the section of this document about the Comm Station.
When diagnosing SAP-related communications problems on the Mobile Client, first look at the log file
from the Comm Station.
Verification
After you execute this Best Practice, you can perform monitoring in your mySAP CRM Mobile Sales
solution using the transactions described in this section.
Many CRM-specific transactions are not available in the R/3 OLTP System. Those common to both the
R/3 OLTP System and to the CRM Middleware System are described together. Those that are handled
or interpreted differently are explained separately.
SMWMQUEUES: Queue Information for CRM Mobile Sites

Functional Description
This transaction is available on the CRM Middleware System but not available on the R/3 OLTP
System.
With this function you can display all the mobile sites defined in the CRM System together with the
name of the queue assigned to each of these sites.
If you want to know which queue is assigned to a specific mobile client site
If you want to check whether this queue has been registered for the qRFC scheduler
If you want to check when data was last entered into this queue
Field Names Descriptions

Client CRM Middleware client
Site Name Site name assigned to the mobile client
Queue Name Queue name assigned to the mobile client
Last Date and Last Time When data was last entered in the queue
Registered A queue has been registered (R), has never been registered (empty), or
has been unregistered (U)
Site description Information text field that describes the mobile client sites and was
defined when the site was created in the Admin Console
SMQ1: Monitoring CRM Outbound Queues

Normal some entries exist in the queues to the individual clients
Contains all objects, which should be sent to the OLTP and the Mobile Clients
Each queue contains single tRFCs in a specific sequence, which is called qRFC
Each client has a dedicated queue number
Mobile clients connect asynchronously to the CRM-system, the queue waits in SMQ1 until the
Mobile client connects so that it can pick up its messages
25
Queues to mobile clients start with CRM_SITE_
Queues for the OLTP system start with R3A..., number of these queues depend on the
business logic and Customizing settings
The OLTP system should always be connected (except during the downtime for backup).
The serialized R/3 Adapter relevant queues all start with
R3AI<object name>
R3AD<object name><key>
R3AR<object name>
When, in the OLTP system, mass updates are done, e.g. application data updates, then the data gets
shipped via the outbound queue to the CRM Middleware system.
This data is controlled via the qRFC settings.
To see the current qRFC version in SMQ1, choose Information > Version.
For a detailed description of qRFC, see SAP Notes 166096 and 193515.
Usage
All queues named CRM_SITE_* are BDocs data from Middleware going to the client
All queues named R3A* are BAPIs destined for the OLTP system
CRM SMQ1: R3D* : BAPI data going from the Middleware system to the OLTP system
OLTP SMQ1: R3D* : BAPI data going from the OLTP system to the Middleware system
Handling Procedure
If you delete a queue that is in use between a mobile client and CRM, this will lead to an
inconsistency between CRM and the mobile client.
In this case, you must bring the client back into a consistent state. In some cases, you can do this by
extracting the data from the Middleware system and sending it to the client. This restores the client
state as it is known on the Middleware system. Data that was not yet successfully transferred from the
client to the Middleware must be manually reconstructed. Local data that is not normally sent to the
Middleware system may be also lost and you may need to reconstruct it manually.
If you accidentally delete data from a queue that is not assigned to a mobile client, data may be lost
and cannot be recovered (for example, in APO, BW, OLTP).
In the case of an error, first try to solve the problem. If all other attempts to fix the problem fail, you
may need to delete an entry in a queue.
In these cases, you must bring the different databases (OLTP, CRM Middleware Server, CRM Client)
manually into a consistent state. To do so, you must be familiar with the technical and business logic of
the process involved (if you are not sure what to do, contact SAP Support).
Problems and errors can occur during data exchange (such as program crash, lost connection
between OLTP System and CRM Middleware Server, and so on).
Queues for OLTP should not wait too long.
Possible causes for waiting: error of first BAPI in queue, resource bottlenecks in OLTP, logical
sequence.
Check the status. If it is SYSFAIL or CPICERR, an error has occurred for the corresponding queue
(most likely on the CRM Middleware Server). Double-click on the queue name and look at the status
text of the first entry in the queue: you will find a short error message describing the error. After
correcting the error, you can restart the queue.
Monitoring CRM Outbound Queues - SMQ1 Queue Details

In the Details view of the outbound queue entries you can see when a client was connected last. It is
possible that clients are not used anymore. The end user for such clients should be contacted and the
site deleted or the client connected for running ConnTrans.
Note: If the queue is deleted for the mobile client without deleting the mobile client, an inconsistency
can occur. If data is sent to this mobile client later, it does not have the data that was deleted from the
queue.
To display the function modules of the queue, double-click on the line.
26
Outbound Queue Tables
Queue: TRFCQOUT
Data: ARFCSDATA
Status: ARFCSSTATE

CL. Client
Destination Logical destination (specified in function call)
Entries Number of logical units of work (LUWs)
Status RUNNING
NOSEND: (Queue is not released, use the SMQ1 transaction for queue release)
CPICERR: (Connection error between systems)
SYSFAIL: (System or program error)
STOP
WAITSTOP: (Waiting)
1. Date Oldest date of queue
1. Time Time of oldest queue
NxtDate Most recent date of queue
NxtTim Time of most recent date of queue
Handling Procedure
If you recognize many entries in one or more queues, take care of the following points.
The corresponding client of the queue has not been connected to the CRM Middleware Server for
a long time. You can check this in the column 1. Date. In this example the client was not connected
to the system since 19. October. You should avoid this situation. If there are many queues with a
large amount of data inside it, this can lead to a rapid grow of communication tables (e.g.
ARFCSDATA, ) and have an impact on system performance. Normally the client should be
connected to the CRM Server regularly. In exceptional cases at least every two weeks.
To reduce the amount of data the subscriptions and publications for a client should as small as
possible necessary from the business point of view.
For all other queues not assigned to a client errors should be monitored hourly at least several
times per day. Errors should be resolved and the queue restarted afterwards.
Monitoring CRM Outbound Queues - SMQ1 Transaction Details

Here you can see the function modules that are recorded in the queue.
Only the first and last entries are displayed. To display the full queue you can use the data browser
(transaction SE16) and display entries from table TRFCQOUT for the queue name.
To use the data browser, you need to be logged on in the corresponding client in this example client
020.
To get detailed data about qRFC, double-click on a line.
Monitoring CRM Inbound Queues SMQ2

The transmission of the delta information is performed from the R/3 OLTP system to the CRM
Middleware Server. When the delta information arrives at the CRM Middleware Server, the data is
forwarded to the inbound queue.
27
The delta data can be found in the R3AD* queues.
The inbound queues are normally empty or small, if the CRM server has enough resources and no
errors occur.
To find stopped or hanging queues, mark an entry and click the spectacles icon (F7).
To display the LUWs belonging to a queue, double-click the queue.
It is strongly recommended to avoid deleting the queue or entries in it, because this can lead to
inconsistencies.
The qRFC Inbound Queue Monitor, SMQ2, is not a critical monitor on the R/3 OLTP System because
there is normally no data to display. Instead, monitor the outbound queue (SMQ1 or R3AM2) on the
CRM system.
When the CRM Middleware system tries to send data to the OLTP system and the OLTP system is not
up, the data stays in the outbound queue of the CRM system.
As soon as the data is in the OLTP system in-queue it gets processed through to the respective
application or to its appropriate end location.
Data is not deposited in the OLTP in-queue and picked up later. It is processed immediately.
Inbound Queue Tables

Queue: TRFCQIN
Data: ARFCRDATA
Status: ARFCRSTATE
Usage
Menu path: Middleware > Monitoring > Queues > Display Inbound RFC Queues
Transaction SMQ2
1) Mark an entry that you want to view.
2) To view the details, click the spectacles icon (F7). Check for stopped or hanging queues.

Entries Number of logical units of work (LUWs)
RUNNING
CPICERR (Connection error between systems)
SYSFAIL (System or program error)
Status Options STOP
WAITSTOP (Waiting)
WAITING
NOSEND (Queue is not released, use the SMQ1 transaction for queue release)
1. Date Oldest date of queue
1. Time Time of oldest queue
n. Date Most recent date of queue
n. Time Time of most recent date of queue
Handling Procedure
An error has occurred, if during an object download with status Running (light yellow) the date, time
and the number of blocks remain constant over the time (about five minutes). Normally no queues
should be build up here.
General procedure: In the case of stopped queues first search for the error causes and then fix them.
Following are listed some possible error situations.
If the status of the queue is SYSFAIL or CPICERR, an error has occurred.
- By double clicking on the queue name and looking at the status text of the first entry in the
queue, you will find a short error message describing the error reason. After the correction of
the error, you can restart the queue.
28
- Check the short dumps (transaction ST22) on the CRM Middleware Server and the OLTP
system. An error in the queue data processing in generally generates a short dump. Here you
can find information about the cause and location of the error.
- Check further information about errors in the system log (transaction SM21) on the CRM
Middleware Server and on the R/3 OLTP side. Also in the CRM Middleware Server Log.
The input queue on the CRM Middleware Server has status Ready, but the number of entries do
not decrease:
Transactions cannot be performed because the system is overloaded. If enough systems
resources are available, start the SMQ1 transaction menu Execute LUWs and check queue
registration in SMQR.
If the queue cannot be activated again, check the application log for possible application error
messages.
Data arrives from the OLTP system but is still hanging in the inbound queue of the CRM
Middleware Server:
- Check that the scheduler is set to active on the Middleware server (transaction SMQR)
- Follow-up problems can be found in the tRFC queue (transaction SMQ1) or in case of short
dumps in transaction ST22.
The inbound queue stops after each object:
Check whether a breakpoint exist in the SMOFPARSFA parameter file. If so (parameter name
BREAK-POINT), please delete them.
If no delta data arrived from the R/3 OLTP (no data in the inbound queue of the CRM Middleware
Server), or the Delta queue has the status STOP you can proceed as follows:
At least one object has download status Running or Abort and has not finished. Wait until the
object is finished or you have to force termination (development support needed).
See the subsection about SMQ1 in the section about OLTP.
Monitoring the Replication Queue - SMOHQUEUE

Displays information about the status and contents of the replication and realignment queues in the
clients defined in your CRM Middleware System.
To stop or start replication queues manually, double-click the traffic light: the light changes between
red and yellow or green.
Normally all queues should be running or waiting: function SMOH_QUEUEDEMON is
automatically triggered to process queue entries when such entries are entered into the queue.
The number displayed besides a queue represents the number of entries currently in the queue.
This number should be continuously decreasing, unless new entries are entered into the queue at
the same time. To view the entries in the respective queue, double-click the number.
If you interrupt queue processing, the processing of the current entry is completed and then the queue
is set to status Hold.
Usage
Menu path: Middleware > Monitoring > Queues > Replication Queues
Transaction SMOHQUEUE
29
Name Name of queue:
AC_EXTRACT Represents those extract jobs triggered directly from the Admin
Console, for example for a data reload to a mobile client to
recover the local SQL database
EXTRACT Contains extract jobs broken down by BDocs (the jobs are
created by realignment)
REALIGN Contains realignment jobs for individual BDocs whose
responsibilities must be checked
SUBCHECK Contains subscription checker jobs (these are generated in the
administration console, if a subscription is changed)
No. entries Current number of entries (messages) in the queue
By setting the status icon in the status column you can:

Release queues for processing by setting their status to Released (yellow light)
Reset released queues to Hold (red light)
Interrupt queue processing (Status Running green light) by setting the status to Hold.
Number of queue
entries
Extract Hold 123
Replication Running 34 Manually

trigger
processing
Realignment Released 0 job
AC_Extract Released 0
Handling procedure
Normal condition: All lights green or yellow, number of queue entries is decreasing.
If an error occurs during processing the Queue demon automatically sets the queue to hold. An
error symbol appears in the last column. You can select this to display the error message. When
you release the queue again, the error status is reset.
If you release a queue after the Queue demon has started, the status of the queue changes to
Running, provided it contains entries for processing. If all entries have been processed (number of
entries is zero), the status changes to Released again.
If the number of entries in a queue remains constant for a period of time, it may be necessary to trigger
the processing jobs manually by double-clicking the green flag corresponding to the queue.
If a queue contains entries, you can display details of the individual entries (such as the number of
sites affected) by clicking on the number of entries. You can delete individual entries in this display, by
selecting the checkbox in the first column of the record and choosing Delete. To update the information
choose Refresh.
30
Try to avoid deleting an entry, because this leads to inconsistency of the local database of the mobile
client.
Monitoring the Middleware Message Flow - SMWMFLOW

First, you must schedule the background job SAP_COLLECTOR_FOR_PERFMONITOR that
periodically executes the ABAP program RSCOLL00.
The message flow is a central function for monitoring BDocs in the Middleware System.
With this function you can display statistics on the message flow within CRM Middleware.
The statistics provided by this function are divided into two main areas:
BDoc / service kernel application statistics: Application statistics from the R/3 kernel for BDoc
types and services.
BDoc / site / queue statistics: Statistics for BDoc types, sites and queues.
To activate the statistics, in transaction SMWMFLOW, choose Goto > Activate statistics and continue
as follows.
Kernel Application Statistics

To activate the application statistics from the R/3 kernel, in transaction SMWMFLOW, choose Goto >
Activate Statistics > Kernel application statistics.
The type MW is relevant in the list of application statistics.
If the checkbox in column act. is selected, these application statistics are already active and you
can return to the previous screen.
If it is not, choose the function Change, confirm the displayed information, select the field in
column act., save your entries. and return to the previous screen.
Middleware Message Flow Statistics

To activate the statistics for BDoc types, sites and queues, in transaction SMWMFLOW, choose Goto
> Activate Statistics > Middleware message flow statistics.
Message flow monitoring can be turned on or off.
Application Statistics on Workload

Application statistics on the workload that is generated from the message flow in the CRM Middleware
System can be displayed in two ways:
1. In SMWMFLOW, choose Workload from database > BDoc Type Workload Statistics
An R/3 kernel application statistic that provides statistics on the system load of the message flow
in different R/3 instances. The application statistics interface is built into the message flow.
Times (total response time, CPU consumption, DB response time and so on) are recorded for:
The BDoc in total (that is, for total time spent in the flow)
Each service
Just as in the case of transaction ST03, the single records created in this way are available at
least for the current day and can also be displayed.
They are automatically aggregated by the CCMS data collector to form the following statistics (the
sum of the total and detailed response times, as well as the average total and detailed response
times):
By BDoc type (including the times for the services)per service (for all BDoc types)per BDoc
type and service. Just as in the case of ST03, these statistics are available for days, weeks and
months. Column Records displays the numbers of flow runs of the different BDoc types.
Alternatively, in SMWMFLOW, choose Workload from database > Per service
Here you can get the workload for individual services per BDoc type. You can also display the
workload per BDoc type (Detail).
This overview does not include the processing time for the following:
Inbound adapter
OLTP inbound adapter (mapping and keygen)
31
Flow itself
Therefore the sum of the total response times of all services can be significant smaller than the
total response time of the BDoc type you have chosen before.
2. In SMWMFLOW, choose Last minutes workload
Here you can get statistics about the current workload of the message flow in your system (for
BDoc types and for CRM Middleware services).
To display statistics for the Middleware services, you can also choose Goto > Service statistics. In
the service statistics you can see Detail statistics for individual services as well as the workload for
individual services per BDoc type.
In all detail statistics, to display individual statistics for the selected BDoc type or service, choose
Single records.
Alternatively, in SMWMFLOW, choose Last minutes workload > Per service
Here you can display the workload for individual BDoc types per service.
This overview does not include the processing time for the following:
Inbound adapter
OLTP inbound adapter (mapping and keygen)
Flow itself
Therefore the sum of the total response times of all services can be significant smaller than the
total response time of the BDoc type you have chosen before.
Statistics on Response and Queue Times

Usage
Menu Path: Middleware > Monitoring > Message Flow > Display Message Flow Statistics and then
select button Message flow statistics.
The Data Collector starts automatically every hour to provide the required data. If you need the most
current data for your analysis, you can start the data collector manually at any time by choosing Run
Collector.
With this function, you can display statistics on response and queue times for BDoc types, sites, and
queues in two ways:
1. In SMWMFLOW, choose Message Flow Statistics > Workload from Database
Select one or all (total) R/3 instance(s), specify the required time period, and choose Workload
from database. This statistic records the progress of the BDocs in the Middleware (including the
retention period in the inbound queues). The retention period in the outbound queues is not
recorded. The single records are written directly before the completion of processing in the
message flow. In contrast to the application statistics, they also contain data from the message
header of the BDocs concerned (BDoc GUID, site ID, name of the inbound queue, and so on).
These single records are aggregated to form statistics that are aggregated by BDoc type, by site
(for clients and OLTP R/3 Systems), by queue, and by hour and client (available for the previous
few days).
These statistics are available for days and weeks.
There is also a report for displaying the single records of the application statistic
(RSMWM_CHECK_STATISTIC_RECORDS). This report displays related statistical data records
together (for a single BDoc with its services). Also, you can view the entire statistical data record
here.
Workload Data
Totals
Number of BDocs (records) processed within the specified time period and the number of the
BDoc types, sites and queues concerned.
Total processing and waiting time
Total and average retention time (processing time plus queue time) of a BDoc on the Middleware
Server.
Processing Times
Total and average processing times of BDocs in the inbound adapter and flow.
32
Waiting Times
Number of BDocs in the queue as well as the total, average and maximum queue time of the
BDocs in these queues.
You can branch from each profile into other profiles and you can always change the time period
you selected at the beginning by choosing Change period. The following screens display the
workload data compressed per selected profile, that is by BDoc type, site, queue, or time.
In SMWMFLOW, choose Message Flow Statistics > Workload from Database > BDoc type profile
The table shows you workload data compressed per selected profile, that is by BDoc type.
In SMWMFLOW, choose Message Flow Statistics > Workload from Database > Site Profile
The table shows you workload data compressed per selected profile, that is by Site.
In SMWMFLOW, choose Message Flow Statistics > Workload from Database > Queue Profile
The table shows you workload data compressed per selected profile, that is by Queue.
In SMWMFLOW, choose Message Flow Statistics > Workload from Database > Time Profile
In this screen you can display the processed BDocs within different time periods (per hour, day, or
week).
If you selected one day as the time period, By time refers to hours.
If you selected a week as the time period, By time refers to days.
2. In SMWMFLOW, choose Message Flow Statistics > Single statistics records
The single statistics always relate to one day and always to the current R/3 instance (setting in
field Instance).
The header data shows you which display you are currently in and what your selection criteria
were.
The table shows the single records that the statistics refer to. For each single record the BDoc
type, client, site, queue and name of the Middleware Server are displayed, as well as the retention
time of the corresponding BDoc on the Middleware Server.
From this display you can branch into a profile and you can always change the time period you
selected at the beginning by choosing Change period.
Flow Control Trace Monitoring SMO8FT

Transaction SMO8FT displays the processing status of a BDoc in the message flow
Monitoring information can be selected and filtered according to various criteria.
Successfully processed messages appear with a green light, those still in process with a yellow
light, and those with a terminal error condition with a red light.
The Flow Control Trace list screen displays the sequence of steps for each message.
For each message, you can see the message ID, the message name, the message type ID; the date
and time sent, and the site ID of the sender.
For each step of a message, you can see a step description (comment), the function module called,
the qRFC queue name of the flow, the message type (S for success, E for error , W for warning, or I
for information) and the long name of the service.
Produces a lot of data, do not forget to switch it off and to run reorganization job SMO6_REORG with
variant SAP_MW_REORG for the tables.
Therefore, this transaction should only be used during active monitoring of errors.
Note: The database is filled by a flow trace that is always active. It is stored in tables SMO8FTCFG
and SMO8FTSTP. As a result, time and disk space is unnecessarily occupied in production operation.
An entry that corresponds to the flow trace flag is managed in table SMOFPARSFA.
The trace is activated for key FLOW FLOWTRACE_ACTIVE and value PARVAL1=X. Otherwise it is
not activated.
Usage
Menu path: Middleware > Monitoring > Message Flow > Flow Control Trace
Transaction SMO8FT
Handling Procedure
33
Developer Trace, useful in error situations or if initial download runs.
If a message is in process and does not get processed within a reasonable amount of time, you can
restart the message, view the message content, or discard the message.
On the trace list screen, you can display further information and execute functions. Position the cursor
on a BDoc message header and proceed as follows:
To display the Middleware log for the services that have processed the message, choose Edit >
Message > Log.
To display the BDoc body segments using the structure editor, choose Edit > Message > Display
body.
To display errors for a BDoc, choose Edit > Message > Display errors.
To delete messages, resume processing the message with the last service, or retry processing,
choose Edit > Message > Error Handler.
To release messages locked in a qRFC queue, choose Edit > Message > Release queue.
This may be necessary in exceptional cases when the R/3 OLTP Adapter cannot be called so the
queue is locked.
Queue Information for CRM Client Sites SMWMQUEUES

Shows the last time of connection. Here you can see whether a client did not connect for a longer time
Usage
Menu path: Middleware > Monitoring > Queues > Display Queue Information
Transaction SMWMQUEUES
BDoc Summary SMW01/SMW02

Transaction SMW01 enables you to display the data of a BDoc. Transaction SMW02 enables you to
access the display of the processing status of individual BDoc from the BDoc types themselves.
Search for special error situations per BDoc ID, date, Site ID, message ID ...,
Link to trace and log available
Link to data content
Reprocessing possible
Usage
Menu path: Middleware > Monitoring > Message Flow > Display BDocs /
Display BDoc Summary
Transaction SMW01/SMW02
Monitor Queue Status R3AM3

The Delta Download queues can be monitored as follows:
Outbound queue on the R/3 OLTP System: either directly on the OLTP using transaction SMQ1 or
indirectly through the CRM Middleware Server using transaction R3AM3.
Note: R3AM3 causes additional network traffic that can be avoided by using SMQ1 on the OLTP
system. It can be used if OLTP logon is not possible.
From here queues can be stopped, activated and started.
You can list details by double clicking on a row in the list.
Usage
Menu path: Middleware > Monitoring > R/3 Adapter > Display Download Queues
34
Transaction R3AM3
Monitor Request R3AM5

Administration tool to fetch data from OLTP (manually triggered), if there are data in CRM-Servers
database missing. in exceptional cases, if you want to bring your database into a consistent state after
a data lost in CRM Middleware Server database.
Usage
Menu path: Middleware > R/3 Adapter > Synchronization Load > Monitor Request
Transaction R3AM5
Check Flow Definitions SMO8FDC

Consistency Check for Flow Definitions

With CRM 2.0B SP05 there is a consistency check available for the runtime environment used by Flow
Control.
Run transaction SMO8FDC (report SMO8_FLOWDEF_CHECK) to find more hints on possible causes
of the errors.
You developed one or several new BDoc types. You generated the flow definition for these BDoc
types.
Flow definition errors may occur using newly developed BDocs.
Search for notes that solves the problem. If there is no solution, create a customer message.
Note: Use SMO8FDC after a new BDoc definition has been transported.
Usage
Menu path: Middleware >
Transaction SMO8FDC
Middleware Log SMO8FA1

This developer log should only be used in an error situation or if an initial download is running.
It produces a lot of data. Remember to switch it off and to run reorganization job SMO6_REORG with
variant SAP_MW_REORG for the tables.
To display the Middleware log for the services that have processed the message, double-click on a line
item. The Middleware log displays the following information:
Details of the message
(message type and last service, the last service return information, the site ID, date and time sent, and
the qRFC queue name)
Log entries for the message
(date and time of the services called, the service short name and status information)
Usage
Menu: Middleware > Monitoring > Flow Control > Middleware log.
Transaction SMO8FA1
Alternatively, you can view the log from the Flow Control Trace list screen.
Recommendation: Use R3AM2 instead of SMO8FA1 because the selectivity level provides better
top-down monitoring support.
Monitor Download Status - R3AM1

35
Checks whether the initial download was completed successfully.
Usage
Call transaction R3AM1 (Download Status Monitor) on the CRM server
Choose Execute (F8)
Search for objects with a status other than green
How to interpret the status symbols
RED: If the Download Status Monitor displays objects with a status other than green, then
problems occurred during the initial download
YELLOW: If the display is empty - initial download hat not been performed yet
GREEN: Status OK
If the status symbol for an object is RED, refer to SAP Note 309734 for initial download problem
analysis
Logfile Communications OLTP Middleware R3AM2

Display of the log files for communication between the OLTP System and the CRM System. The
selection screen enables the user to choose between different kinds of information - object name,
selection period, and so on.
Information Level:
A (abort)
E (errors)
W (warning)
Different info levels
Different trace level
Message category (log of R/3 Adapter, flow control MW server, CDB service MW server, replication
MW server)
Note: R3AM2 reads the SMO8_LOG table. Usage of R3AM2 is recommended rather than SMO8FA1.
Usage
Menu path: Middleware > R/3 Adapter > Initial Download > Monitoring > Display Log File
Transaction R3AM2
Scheduler Status SMQR

This transaction runs the scheduler for checking the inbound queues on the CRM Middleware Server.
Make sure that the scheduler is set to active. Here you can register or deregister the inbound queues.
You can stop all inbound queues in CRM by de-registering all queues in transaction SMQR.
Only those queues that are registered are processed. These are registrations with any generic queue
name with type R (R = registered, U = unregistered). So an entry must exist in transaction SMQR for
the queue names, such as R3A* for the delta queues.
In the upper part of the display, you find the scheduler status which is either is INACTIVE, ACTIVE or
WAITING.
Scheduler status is INACTIVE: This status means that the qRFC scheduler has no work list at the
moment. Therefore no registered Inbound queues in the READY status.
Handling Procedure
If background processing scheduler status is ACTIVE or WAITING, select Refresh (F9) at short
intervals (approx. 1 second) and monitor the background processing scheduler status as well as date
and time of the field Last update(every 2 minutes).
36
If the status of the scheduler is occasionally WAITING, and the date, time in field Last update (every 2
minutes) changes every few seconds without a decreasing number of queue entries in SMQ2 this
indicates that the qRFC scheduler gets not enough resources. The qRFC scheduler may then not start
any asynchronous RFC calls (all dialog work processes are blocked) with the result that the qRFC
inbound queues are not processed.
You can check whether the system can provide enough resources by using transaction SM50. A few
dialog work processes should remain in status waiting. Otherwise the system is overloaded.
TRFC Monitoring SM58

Here you can monitor all transactional RFCs (tRFC) processed on the Middleware server (such as
workflow).
Executing generates a selection screen where you can choose the display period, the user name,
function, destination and status of transactional RFCs. 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).
You get information about the caller, function module, target system, date, time and status text.
Additionally you get information about the transaction ID, Host, current transaction code, program,
client and number of attempts establishing the connection.
Usage
Menu path: Middleware > Monitoring > Transactional RFC
Transaction SM58
Handling Procedure
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 / re-scheduled.
If the error is fixed, the entry does not appear in the SM58 display.
Do not delete an entry before resolving the problem because this will lead to a data inconsistency.
R/3 Buffer Monitor - ST02

The Buffer Monitor shows the current status and the memory resource usage for a specific R/3
application server.
As part of the SAP Basis, the Buffer Monitor does not display any CRM specific monitoring data.
It should be analyzed using the same procedures as those used in a non-CRM system environment.
General Threshold Values - ST02

Name Threshold value
Hit ratio (PXA, TABLP, EIBUF) >= 98%
Swaps (PXA) <= 10.000
Swaps (other than PXA) =0
Roll area max used < in memory
Extended memory <80% of in memory
Workload Monitor - ST03

ST03 RFC Time Profile check the time of day when the longest wait times are listed. Check on
both Middleware and on the OLTP systems.
37
The Workload Monitor is used to analyze statistical data from the R/3 kernel. When analyzing the
performance of a system, you should normally start by analyzing the workload statistics. For example,
you can display the totals for all instances and compare the performance of individual instances over
specific periods of time.
You can use the workload monitor to display the:
Number of configured instances for each SAP System
Data for all application instances, not just the one you have logged on to
Transactions used and the users that call them
Number of users working on the different instances
Performance history for recent periods for all instances
Response time distribution and resource consumption for any application server
Application server workload for today or for a recent period.
General Threshold Values - ST03

Name SAP Threshold values
Dispatcher wait time <= 50 ms
Database time < 40% of (response time - dispatcher time)
Processing time < 2 x CPU time
avg. response time < 1000 ms
Functional description
As part of the SAP Basis, the Workload Monitor does not display any CRM specific monitoring data.
However the RFC response time statistics should be monitored relative to the RFC communications
between the R/3 OLTP System and the CRM Middleware System.
In general, it should be analyzed using the same procedures as those used in a non-CRM system
environment.
Additionally the RFC parameters and statistics should be analyzed in detail.
See also the description listed in the section about CRM Middleware monitoring.
Monitor RFCs:
Total today, last minute, last week
Goto prof RFC prof.
client (sender is caller, calls)
server (receiver is doer, answers, processes requests from other systems)
client targets
trans codes func mod.
Call time +/- = (Network time + exec time)
(Exec time + network time) = call time
Times are longer for higher data volumes
Avg. time +/- = Exec. Time / quantity
Quantity: # of times it was executed
Detail list: double-click on entry
Targets = +/- RFC destinations
ST03 click RFC Time profile
o Check to see when the heavy times are.
38
o Check wait times.
o Compare RFC response times to Dialog response times.
Example: ALE can also be included in the stats above so these have to also be considered (not only
ALE, but also all other communication applications).
Database Performance Analysis - ST04

The Database Performance Monitor does not display any CRM specific monitoring data.
Exception: Check the indices on the tRFC and aRFC tables (ARFC* and TRFC*).
See also transaction DB02.
Operating System Monitor - ST06

Transaction ST06 for monitoring the available swap space in the host system.
Compare the hardware load for times of high RFC transmissions with the times of normal operations.
You can detect the following bottlenecks from the following values:
CPU bottleneck by CPU idle time of less than 5% or a CPU load greater than 3%
A very high load and a CPU idle time of about 50% normally indicates an I/O bottleneck.
Memory bottleneck
UNIX page-out rate greater than 60 000 pages/hour
NT page-in rate greater than 60 0000 pages/hour
High file system utilization and wait times can indicate a disk bottleneck.
A high number of collisions can indicate network problems on your shared Ethernet network.
General Threshold Values

CPU idle >= 20%, or better >= 35%
(UNIX) page-out rate <= 60 000 page/h
(NT) page-in rate <= 60 000 page/h
Local and Systemwide Work Process Overview SM50 / SM66

This transaction enables you to detect long running transactions. Check it occasionally or if you
suspect that there is a sudden performance bottleneck.
Threshold Values - SM66/SM50

Work processes in PRIV mode > 20 % of all WP ( memory management problem?)
Work processes in database action > 40% of all WP ( database problem?)
Work processes reading the same > 20% of all WP ( exp. SQL or excl. lock waits?)
table at same time
By monitoring work processes in the R/3 System (transaction SM50) or from outside the system
(program DPMON at operating system level), you can determine the status of the work processes in
relation to the PRIV mode. If work processes are often switched to the PRIV mode, you must increase
the extended memory and/or adjust the limit for the extended memory). In this case, you must consult
with SAP.
39
You can use transaction SM66 to evaluate this information for all the work processes.
You can determine the swap space requirements at R/3 and operating system level.
Many monitoring tools are operating system dependent.
Usage
With help of this transaction you can detect long running transactions.
Monitor periodically, and also check if there are sudden performance problems.
Threshold Values - SM66 / SM50

Name Suggested threshold value
Work processes in PRIV mode > 20 % of all WP ( memory management problem)
Work processes in database action > 40% of all WP ( database problem)
Work processes reading the same table > 20% of all WP ( exp. SQL or excl. lock waits)
at same time
Handling Procedures
In the case study, these transactions are evaluated during the periodic SAP EarlyWatch sessions that
are held on the system.
Systemwide Work Process Overview SM66

Transaction SM66 shows the SAP System work process overview for the local application server and
for all other SAP application servers that are connected to the same SAP database (such as all
application servers connected to the database and central SAP instance).
SM66 check for ARFC jobs
Make sure that all work processes are not blocked if blocked, check the parameters.
Are there work-processes that are stopped or locked by CPIC to determine whether there are enough
work processes configured for the system.
Check the queue using SMQ1 single entries can be locked until capacity is available (but only in an
emergency).
In SM50, ARFC entries show up as entries for the background work processes.
Broken-off tRFCs are automatically post-processed. There are as many background WPs as possible.
For a solution, see SAP Note 319860.
For more information about aRFC problems (SM50 and so on), see SAP Note 36680.
Display Statistical Records STAT

Shows who has done what and when.
Expansion
RFC statistic
Time analysis
Check to see if it says no subrecords
Check RFC subrecords to see who has done what.
Update Error Monitor SM13

Functional description
The Update Error Monitor does not display any CRM specific monitoring data.
40
System Log SM21
Description
The System log does not display any CRM specific monitoring data.
ABAP Dump Analysis ST22

Description
The ABAP Dump Analysis does not display any CRM specific monitoring data.
Database Performance Monitor DB02

Description
The Database Performance Monitor
Check indices: transaction DB02, choose Detailed analysis
Table name
Check these tables:
ARFCSDATA
ARFCSSTATE
TRFCQOUT
TRFCQIN (only in the CRM system)
Double-click the table entry <Tables Indexes>
Displays the table and all its indices
Select Detailed analysis
Check storage quality
If <40 (for storage quality), then the indices must be REBUILT
An index should be rebuilt at the DB level by the DBA.
Gateway Monitor / Connection List - SMGW

Description
The Gateway Monitor is used for analysis and administration of the SAP Gateway in the R/3 system.
The initial screen of the Gateway Monitor shows a list of all the active connections.
For information on return codes, see SAP Note 63347.
Usage
Menu path: Tools > Administration > Monitor > System Monitoring > Gateway Monitor
Further Information
Troubleshooting
This chapter describes problems that can arise in the CRM-MSA environment and standard
procedures in handling and solving the problems.
This chapter is split into 2 sections

Flow diagrams
Problem descriptions
41
Flow Diagrams
This diagram describes a way to analyze a problem encountered during the download from the R/3
OLTP System to downstream systems.
42
OLTP Download Problem:
- SMQ1 Status = RUNNING
- TIME and BLOCK NUMBER remain constant too long (>5 min.)
OLTP - SMQ1 YES?

Queues built-up?
Queue errors?
OLTP CRM network connection down? - Fix

NO? CRMPAROLTP table entry: CRM_USE_INQUEUE_FOR_DEST = <space>
CRM - SMQ2 YES?

AdapterQueue
errors?
Adapter Queue status for R3A* queues Fix Restart Queues

NO?
CRM - ST22 YES?

Queue related
short dumps?
Analyze the short dumps Fix problem
NO?
CRM - SM58 YES?

CRS_FIRST*
Errors?
Analyze error message Fix problem
NO?
OLTP - ST22 YES?

Short dumps
available?
Analyze the short dumps Fix problem
NO?
OLTP SM21
CRM SM21 YES?
CRM R3AM2
Errors?
Analyze error messages Fix problems
NO?
DONE
43
This diagram shows a method for analyzing a problem with the Delta Download. The chart is
continued on the next page.
Delta Download Problem:

- Download was unsuccessfull
OLTP System
Setup OK? NO?
Event Control Setup

YES?
Parameter settings
CRM Inbound
Queue
Processed OK? NO?
Check queue for errors
YES? Fix problems
Initial Download
finished
successfully? NO?
R3AM1
YES? Check log file
CRM
Middleware Events
activated? NO?
Activate missing entries manually

YES?
CRM Server
Scheduler registered
for OLTP queues? NO?
SMQR, register R3A* queue names

YES?
< Continued on the next page >
44
< Continued from the previous page >
SMOFPARSFA
table entry for
download OK? NO?
CRM USE BULK DURING DELTA =

YES?
Do Filter
entries exist for
objects? YES?
R3AC1, delete unwanted filters

NO?
Does the
Inbound Queue
stop after
YES?
each object?
Deactivate the BREAK-POINT entry in the SMOFPARSFA table
Delete the breakpoints or enter a non-existent user name

NO?
Does a
Message Flow get
generated for
objects? NO?
SMO8FD: Check
SMO8FDG: Regenerate for all objects if necessary
YES?
Problems
Solved? NO?
Call SAP Support

YES?
DONE
45
Problem Descriptions
Problem descriptions are described as follows:
Condition problem description, symptoms, etc.
Analysis possible causes of the problem, background information, etc.
Handling problem resolution procedure(s)
1) Condition
Table SMOG_REGEN is not empty. This indicates that some programming structures have not yet
been generated or that generation was not completed successfully.
Note: entries BDoc 26E6D6865C0CD411A6E6080006277FCD and BDoc BWAMESS can be ignored
if they appear in the table.
Analysis
The CRM middleware functionality is dependant on BDoc and flow programming structures. These
structures must be generated as part of the installation otherwise the server cannot perform critical
system functions.
Handling
To verify that the SMOG_REGEN table is empty proceed as follows
a. Call transaction SE16
b. Enter SMOG_REGEN as table name
c. Choose Table Contents -> Execute
d. The table should be empty
If the table SMOG_REGEN is not empty (except for the entries mentioned in the Condition section
above) proceed as follows
A. Regenerate the programming structures using the procedures listed in the post-installation
section of the CRM installation documentation
B. After regeneration, check table SMOG_REGEN for entries
C. The table should be empty
Note: If you cannot regenerate some of the structures
A. Call transaction SMOGLASTLOG
B. Enter message type E
C. Select SHOW LOG
D. Copy the information displayed into a message in SAPNet R/3 Frontend using application
component CRM-MW
2) Condition
Transaction SMQ1 shows that there are many entries in several mobile client queues. A result of this
could be that the outbound queue tables of the Middleware System become very full. This can lead to
a database standstill when the database table spaces become too full.
Analysis 1
1 or more Mobile Clients have not connected to pick-up their messages.
Handling 1
Determine why the mobile client(s) are not connecting
If the clients no longer exist, delete the references to it using the Admin Console/Station
Delete the data from the outbound queues for the non existent mobile clients
Analysis 2
If there are more subscription sites than mobile clients (e.g. for testing purposes) it is possible that the
qRFC queue has entries for nonexistent mobile clients. The publications for the nonexistent clients will
stay in the RFC queue until they are manually deleted and can impact data exchange performance
dramatically.
46
HANDLING 2
Use transaction SE37 to determine the number of subscriptions defined for the mobile clients
defined for your system (function module SMWM_PREPARE_SMOHSITEID (Single test, Execute,
click on result, SITESALL shows the number of subscriptions that are defined in the middleware)
Use the Admin Station to delete the subscriptions that are assigned to unnecessary clients
Use the Admin Station to delete the client IDs which are not needed
3) Condition
The R3AM1 transaction shows that an object from the initial download has a status of RED.
Analysis: The R3AM1 transaction shows that an object from the initial download has a status of RED.
Handling:
queue has stopped processing. The reason why the queue has stopped must be examined and
corrected.
Use SM08FT (Flow Trace) or SMW01 (IDOC Viewer) to view the error messages
Correct the error based
Using SMQ2 delete the STOP entry for the queue
Restart the queue
Use a similar procedure for subsequent errors
Do not restart the initial download from the R/3 OLTP system. The download resumes, by itself; after
the error has been corrected. See the above SAP note for a detailed handling description.
4) Condition
Lots of ARFC* jobs are listed as scheduled in the Background Job overview (SM37) on the OLTP
system. This can lead to slow system performance in the sending system, because most of the batch
processes are used in parallel.
When many of these jobs have the same remote destination this can lead to performance problems on
the remote system, if there are not enough available resources there. The currently executed LUW in
the receiving system may be terminated when it exceeds the max. allowed runtime
(rdisp/max_wprun_time). During this error the system triggers a short dump with error "TIME_OUT".
Analysis
Jobs that cannot be processed immediately by the CRM system get scheduled as ARFC jobs and are
processed asynchronously depending on system resource availability of the downstream
components (CRM, Comm. Station, mobile clients).
Batch job ARFC: SYSLOAD1<client><User>:
Is scheduled if no free dialog work processes are available on the sending system to process the
LUWs asynchronously. The affected LUW is assigned a status of SYSLOAD in the tRFC/qRFC tables.
These background jobs will then be distributed to any application server having available background
work processes. When the background work processes on the application servers become busy due
to processing these additional jobs they may not be available for the normal business processing
which they are intended for.
Batch job ARFC: <Transaction ID> and report RSARFCEX:

Are scheduled if a communication error arises (status CPICERR in table ARFCSSTATE) to resend the
LUW. Within transaction SM59 menu: Destination TRFC options it is possible to specify the number
of connection attempts and the time in minutes between two retries.
Batch job ARFC: <Transaction ID> and report RSARFCDL:
Are scheduled to be started in one year, to delete LUWs which were stopped after the occurrence of a
serious error (status SYSFAIL in table ARFCSSTATE).
This should avoid a continues grow of the tRFC/qRFC tables due to old entries. Beginning with qRFC
version 4.6D.023 this background job is no longer scheduled automatically.
Handling
SYSLOAD status: This is handled by specifying the application server/group where the background
processing should be done.
47
Update the qRFC version to 4.6D.025 or higher.
Define the abap/qrfc_asgroup_for_sysload parameter using 1 of the following options:
Origin : SYSLOAD LUW is restarted on the originating application server
<ASgroup_name> : SYSLOAD LUW is restarted on an application server of the specified server
group. The group must be configured using SM59 or RZ12.
Use transaction SM58 regularly to find stopped LUWs and to delete them if necessary. But be careful
when deleting them in a production system to avoid inconsistencies. They can be deleted using SM58
menu: Edit Delete LUWs or Log file Reorganize.
5) Condition
Mass changes of data (creating, changing) on the OLTP system leads to reduced system performance
due to all of the dialog and batch work processes becoming occupied.
Analysis:
The outbound queue (SMQ1) of the OLTP system shows that there are between several hundred and
several thousand different queues waiting to be processed. A large amount of the changed data from
the OLTP system is intended for the delta download to the CRM Middleware Server and is therefore
stored in the outbound queue of the OLTP before being transferred to the middleware server. For
performance reasons qRFC tries to transfer as many queues as possible, as fast as possible. The
result is that many parallel queues (with different queue names) are generated.
The total number of queues that can be generated for parallel processing is limited by the possible
names that can be assigned to the queues.
Handling:
I. To reduce the possible number of parallel queues/queue names that can be created, edit the OLTP
table CRMQNAMES (transaction SE16). Search for the object name (e.g. CUSTOMER) for which you
want to reduce the number of parallel queues. For the object CUSTOMER the field CUSTOMER
(corresponds to field KUNNR of table KNA1) is used for queue name generation. This results in a
queue named e.g. R3AD_CUSTOME_<KUNNR>.
You now can truncate this field so that only this reduced part is used for queue name generation.
If you for example, change the values of the fields FLDOFFSET and LENGTH. to 7 and 3 you define
that only the last 3 characters are used in the generating of queue names. The field BAPIFLDLEN
determines the length of the field used for queue name generation.
The values for FLDOFFSET and LENGTH together may not be greater than the value used for the
BAPIFLDLEN field.
Examples for a case where BAPIFLDLEN = 10:

FLDOFFSET = 9 and LENGTH = 1, possible queue names can be from 0 9
If you set the `inactive flag in the table CRMQNAMES, all data is put into one queue.
II. Beginning with PI2000.2 patch 01 you can use the parameter
CRM_MAX_QUEUE_NUMBER_DELTA in table CRMPAROLTP to reduce the number of queues. If
you set the parameter value to 5 a maximum of 5 queues are generated despite the settings in
CRMQNAMES.
III. If you are currently experiencing this problem you have the following options:
You can stop the download and activate it later (e.g. at night).
In SMQ1
- select a queue
- press F7 (glasses icon)
- menu Edit Generic queue Lock immediately. For locking the queues you can use wildcards
(e.g.R3AD*)
48
- to unlock use menu Edit Generic queue Unlock.
If you do not need the update data in the CRM Middleware Server delete the queues.
6) Condition
When large datasets are involved, the initial extract of BDocs with intelligent and dependent
distribution and the transport to the mobile clients can take a long time. These long run-times can also
lead to time-out situations.
Analysis
By default every BDoc is extracted separately, placed in the flow, sent to the client, and then read
there. This process can be optimised in most cases by applying the following handling procedures.
Handling
If you have not already done the initial load of your mobile clients, use the following recommendation
to increase the performance of the extract of the data.
Implement the bulk extract for intelligently and dependently distributed objects
Implement the parallel processing of the AC_EXTRACTS (per SAP Note 351086). Both of these
topics are described below.
After changing the parameter settings in table SMOFPARSFA, the profile RRLEX in transaction
SMOGWB must be regenerated.
Prerequisites
CRM 2.0B, SP08 and the following SAP Notes 366936, 370779, 379460, 374270, and 371234.
Additional information is in SAP Notes 361872 and 378252.
This functionality is part of CRM 2.0B SP8 or CRM 2.0C SP2. The SAP Notes are additionally
necessary.
1. Bulk Extract:
Create bulk messages to reduce the extract and transport overhead during AC_EXTRACT. This allows
up to a specified (configurable) number of instances of a Bdoc to be included in a message. Reading
these bulk messages on the clients is more efficient
Configuration: The maximum package size (number of instances of a BDoc in a message) is
determined at the time of generation using the parameter entries in table SMOFPARSFA. If the
settings are changed, the affected extract modules must be generated again (only in 2.0B, in 2.0C the
settings immediately become active).
The SMOFPARSFA table entries are as follows:
PARSFAKEY PARNAME PARNAME2 PARVAL1
RRS_COMMON MAX_PACKAGE_SIZE <empty> <Numeric value>
BULK
SUBSET
<BDoc-Name>
For PARNAME2
- Parameter BULK is used for bulk distributed messages with the specified number of instances of
Bdocs
- Parameter SUBSET is used to specify dependent and intelligent distributed BDocs
- Specify individual Bdoc-types to optimise the settings for individual BDoc types
- This field should not be left empty. It may only be left empty if there is a corresponding value in
the PARVAL1 field
For PARVAL1
- The default value is 50 for all Bdoc types, provided that no entries already exist for individual
Bdoc-types (see PARNAME2)
- Bdoc type-specific entries take priority over general entries (BULK | SUBSET | empty)
- The optimum setting depends on the size of the respective BDoc type (number of segments,
average number of records in dependent segments)
49
- Performance wins can depend on hardware capability, etc.
- Reasonable numeric values for PARVAL1 are relative to the parameters used in the PARNAME2
field as follows:
empty: 50
BULK: 1000 5000
SUBSET: 50
BDOC-Name: 50
- These values should be understood as beginning values. If the values are changed then the
system needs to be monitored to check for timeouts and long runtimes. In these cases the values
should be respectively reduced to acceptable performance levels.
Parallel processing of AC_EXTRACTS

As an option to the default procedure of processing extracts for individual client sites, parallel
processing of the AC_EXTRACT queue can be activated / configured so that extracts for different sites
can be carried out in parallel.
You can specify a number of dialog work processes for parallel running AC-extract jobs, but not more
than
The subscribed mobile clients you have
Your CPUs can handle (rule of thumb: number CPUs * 6)
The dialog work processes you have available (2/3 of the number of dialog processes for
having some processes free for RFC-handling and administrating.
After changing these parameter settings in table SMOFPARSFA, you must regenerate profile RRLEX
in transaction SMOGWB.
Handling
Parameters in table SMOFPARSFA can be used to specify how many jobs are started in parallel
(maximum value). Furthermore you can enter an RFC-group of application servers for load distribution,
which is used by the aRFC to process the jobs in parallel.
The SMOFPARSFA entries look as follows:
PARSFAKEY PARNAME PARNAME2 PARVAL1 PARVAL2
RRS_COMMON RRQUEUE_PARALLEL <Queue short name> <Number of <Name of
(currently AC supported) processes> RFC group>
For PARVAL2, the RFC group is maintained in Transaction RZ12. If no RFC group is specified in table
SMOFPARSFA, the system does without an explicit load distribution and the jobs are distributed to all
available application servers
To use this improvement for performing the AC-extract in parallel, you have to finish realignment for all
subscriptions. The extract must be stopped, extract queue in transaction SMOH and CRM_SITE*
queues in SMQ1 should be deleted and after doing this you can start the full AC-extract on the Admin
Console for all clients
50
Feedback and Questions
Send any feedback by composing an SAP customer message to component SV-GST. You can do
this at http://service.sap.com/message.
Copyright 2001 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.
51

MySAP CRM Mobile Sales Monitoring

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MySAP CRM Mobile Sales Monitoring

Загружено:

Авторское право:

Доступные форматы

mySAP CRM Mobile Sales Monitoring

Best Practice for Solution Management

Applicability, Goals, and Requirements

Goal of Using this Service

The general monitoring goals are to be able to:

Staff and Skills Requirements

Business Process: Sales Order Processing (CRM-MSA)

Mobile Client CRM Middleware R/3 OLTP System

Create R/3 Sales Order

Delivery Due List

Post Goods Issue

Billing Due List

Business Process Description

Sales Order Processing Availability

Process Availability Online Background Peak Times

Technical Process Flow Overview

Active System Action Interface

Comm Station - Protocol conversion (LDAP to RFC) Comm Station

CRM Server - Process data from inbound-client queues CRM OLTP

Active System Action Interface

Comm Station - Protocol conversion (LDAP to RFC) Comm Station

SAP Components on the R/3 OLTP System

SAP Kernel SAP Database Components

Server Role OS system

CRM Middleware System Central Instance & DB Server Unix

CRM Middleware System Application Server (1 server) Unix

Communication Station Windows NT

Mobile Client(s) (Laptop PCs) Windows NT

SAP Frontend type Operating System Release Connection Type /

Best Practice Procedure and Verification

Server Types Monitoring Function

DCOM Connector Monitor SMQR

Comm. CRM MW R/3 OLTP

DB & Replication and

Log Flow / Process Control

MS Windows NT MS Windows NT SMWMFLOW SMQ1

OLTP System CRM System

CRM System OLTP System

OLTP Server Monitoring Points of Interface

Comm. CRM MW R/3 OLTP

DB & Replication and

Log Flow / Process Control

R/3 OLTP System Monitoring

R/3 OLTP System Transaction Monitoring Frequency

R/3 OLTP System Parameter Settings

Parameter Name Parameter Parameter Parameter ParaValue 2

Scheduling Background Jobs

CRM Middleware Component Monitoring

CRM Server Monitoring Points of Interface

Comm. CRM MW R/3 OLTP

DB & Replication and

CRM Middleware System Monitoring Monitoring Frequency

Note: Do not press the trash icon button if it appears

BDoc Summary SMW01 / SMW02 Hourly

CRM Middleware System Monitoring Monitoring Frequency

Settings of CRM Middleware Server Parameters

FLOW FLOWTRACE_ACTIVE <space>: Flow trace is deactivated

CRMGENERAL LOGLEVEL E: Recommended value for all clients -

R3A_COMMON CRM_USE_BULK_DURING_DELTA <space>

R3A_COMMON CRM_USE_BULK_DURING_INIT <space>: Recommended value after initial

Scheduling Batch Jobs

Technical Monitoring Transactions and Procedures

Comm. CRM MW R/3 OLTP

DB & Replication and