BPM For Crm40

Manage mySAP CRM 4.
Best Practice for Solution Management
Version Date: January 2005
The newest version of this Best Practice can be
obtained through the SAP Solution Manager
Contents
1 Introduction .............................................................................................................................3
1.1 Applicability, Goals, and Requirements...............................................................................3
1.2 Best Practice Procedure.....................................................................................................4
1.2.1 Preliminary Tasks.......................................................................................................4
1.2.2 Monitoring Concepts ..................................................................................................4
1.2.3 Monitoring Procedure.................................................................................................4
1.2.4 Solution finding procedure..........................................................................................5
1.2.5 Legend ......................................................................................................................5
2 mySAP CRM...........................................................................................................................6
3 mySAP CRM Online Sales ......................................................................................................6
3.1 Sales Order Management...................................................................................................7
4 mySAP CRM Interaction Center Overview.............................................................................15
4.1 Interaction Center Building Blocks ....................................................................................16
4.2 Core Business Processes in SAP CRM Interaction Center................................................18
4.2.1 Inbound Telesales ....................................................................................................18
Outbound Telesales...............................................................................................................25
4.2.2 Complaint Management ...........................................................................................28
4.3 Scenario specific recommendations .................................................................................31
4.3.1 Memory Consumption by transaction CIC0...............................................................31
4.3.2 Statistical records (STAD) ........................................................................................32
4.3.3 Interpretation of response time of transaction CIC0 ..................................................32
5 mySAP CRM Field Sales Overview .......................................................................................34
5.1 Field Sales System Landscape.........................................................................................34
5.1.1 Sales order management .........................................................................................37
5.2 Further Information...........................................................................................................56
5.2.1 Integration of BW and CRM Field Sales ...................................................................56
5.2.2 Background Information and References for the Field Sales Scenario ......................57
5.3 Scenario specific Monitoring.............................................................................................61
5.3.1 Basic Monitoring Guidelines for the CRM Server ......................................................62
5.3.2 Basic Monitoring Guidelines for the Communication Station .....................................63
5.3.3 Basic Monitoring Guidelines for the Mobile Clients ...................................................63
5.3.4 Housekeeping for Mobile Clients ..............................................................................66
5.3.5 Application Troubleshooting on Mobile Client ...........................................................69
6 mySAP CRM ESelling Overview ..........................................................................................72
Best Practice: SAP Business Process Management for CRM 2
6.1 ESelling System Landscape ............................................................................................72

6.2 Core Business Processes in SAP CRM ESelling .............................................................75
6.2.1 B2B Sales Order Management.................................................................................75
6.2.2 B2C Sales Order Management ................................................................................87
6.3 SAP Recommendations for additional components...........................................................90
6.3.1 Security Recommendation for ESelling ...................................................................91
7 mySAP CRM Marketing and Analytics ...................................................................................93
7.1 Marketing System Landscape...........................................................................................93
7.2 Core Business Processes in SAP CRM Marketing and Analytics.......................................95
7.2.1 Marketing Planning and Campaign Management......................................................95
7.2.2 Trade Promotion Management (TPM) ....................................................................103
7.2.3 Business Partner Segmentation .............................................................................107
8 Generic Part........................................................................................................................ 113
8.1 Availability Check ........................................................................................................... 113
8.2 Connection to SAP Business Warehouse (BW)............................................................... 115
8.3 BDoc Monitoring and Handling ....................................................................................... 116
8.3.1 Monitoring.............................................................................................................. 116
8.3.2 Usage .................................................................................................................... 118
8.4 Interface Monitoring........................................................................................................ 119
8.5 Performance Monitoring ................................................................................................. 119
8.5.1 General information ...............................................................................................120
8.5.2 Procedure ..............................................................................................................121
8.5.3 Transaction ST03...................................................................................................122
8.5.4 Transaction STAD..................................................................................................123
8.5.5 Transaction ST05...................................................................................................128
8.5.6 Transaction SE30 ..................................................................................................129
8.6 Batch Jobs .....................................................................................................................130
8.7 Mass data changes ........................................................................................................133
9 Further Information..............................................................................................................138
10 Appendix.............................................................................................................................139
10.1 General Monitoring Guidelines for the SAP CRM System and the SAP R/3 System....139
10.2 Middleware specific Monitoring Activities for the R/3 System ......................................141
10.3 Middleware specific Monitoring Activities for the CRM System ....................................141
© 2005 SAP AG 2
1 Introduction
1.1 Applicability, Goals, and Requirements
To ensure that this Best Practice is the one you need, consider the following goals and requirements.
Goal of Using this Service
This Best Practice helps you set up a businessprocess management and application monitoring
concept for your mySAP CRM solution, valid for CRM release 4.0. The concept aims to define
procedures for business process oriented monitoring, error handling and escalation procedures for
you company’s CRM core business process.
This best practice is divided into five mayor areas: The first chapter deals with CRM Online which
includes several steps that are generic to the other scenarios The following four chapters focus on the
scenarios Interaction Center, Field Sales, ESelling and Marketing.. The last one, Generic Part,
includes scenario independent topics like ATP, BW and so on. The procedure is based on the most
common CRM environment, which consists of an SAP CRM System and an SAP R/3 System. The
optional use of a SAP BW or a SAP APO system is also included.
The procedures intend to ensure smooth and reliable flow of the core business process in order to
meet your business requirements.
Alternative Practices
You can have SAP experts deliver this Best Practice onsite by ordering a Solution Management
Optimization (SMO) service known as the SAP Business Process Management service.
Staff and Skills Requirements
To implement this Best Practice, you require the following teams:
Application Management Team
This team creates the CRM business process management concept and consists of experts from
several areas of your company:
· Business department
· Solution support organization (for example, the IT department and the Help Desk)
· Implementation project team
Execution Team
The execution team will be responsible for applying the resulting procedures derived from
implementing this best practice. They include the following groups:
· Persons designated to perform business process oriented monitoring and ensure that the
process runs smoothly (e.g. the Business Process Champion for each business process)
· All parties in your Solution Support Organization and IT department involved in monitoring
(Application Support, Development Support, Program Scheduling Management, Software
Monitoring Team, System Monitoring Team)
More information about roles and responsibilities of these teams can be found in the superordinate
Best Practice General Business Process Management, which you can obtain through the SAP
Solution Manager.
Necessary or Useful Trainings
q CR500 CRM Middleware Overview
q BC305 Advanced R/3 System Administration
q BC 315 Workload Analysis
q CR700 CRM Service
q CR900 Analytical CRM
Page 3 of 145
System Requirements
In case you want to set up Business Process Monitoring on the SAP Solution Manager, the SAP
Solution Manager should be set up. Otherwise there are no special system requirements.
Duration and Timing
Duration
Creating a businessprocess management concept could take around one week per business
process.
Implementing the businessprocess management concept might take approximately an additional
week.
Timing
The best time to apply this Best Practice is during the planning phase or during the implementation
phase of your mySAP.com solution.
How to use this Best Practice
Here you find a brief description of how you should proceed in using this document:
· Read through the General Business Process Management Best Practice, available on the Service
Marketplace. This document explains you the procedure you should use to create a general
business process management concept. It deals with questions like who is responsible to create
what and what has to be documented in which order. The result will be a flow chart for your core
business processes that includes the necessary technical and application details.
· At the beginning of the chapters dedicated to the five scenarios (Interaction Center, Field Sales, E
Selling, Marketing and CRM Online) you will find a typical flow chart for the core business process
and a description of the typical system landscape. They should be used as a guideline for writing
down your process documentation.
· In the generic part you find information that is relevant for two or more scenarios. In case
information from the generic part is relevant for a specific business process step in one of the
scenarios; you will find a clear link to the corresponding chapter in the generic part.
1.2 Best Practice Procedure

1.2.1 Preliminary Tasks
Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks
in the system:
· Complete all installation and postinstallation 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
1.2.2 Monitoring Concepts
The monitoring procedures ensure that the technical processes meet the requirements for stability,
performance and completeness. Monitoring must cover three areas: errors; performance and
throughput; and processing progress and completeness.
In the chapters dealing with the scenarios Interaction Center, Field Sales, ESelling, Marketing, CRM
Online and the generic issues part and, you will find monitoring recommendations for each of the
typical process steps. You should use them as a guideline for setting up your monitoring concept.
1.2.3 Monitoring Procedure
The core of this Best Practice is the monitoring concept for each business process step. For each of
the business process steps you will find the following information:
· A detailed functional description of the process step
· Monitoring activities for the process step
· Relevant issues of error handling, restartability and escalation
© 2005 SAP AG 4
· A monitoring object table listing each relevant monitoring object, showing the:
o Monitoring object
o Monitoring transaction or tool
o Monitoring frequency
o Indicator or error
o Monitoring activity or error handling procedure
o Responsible team
General monitoring activities that are valid for all or most scenarios are described in the Appendix.
Monitoring activities that are special to one scenario, but cannot be related to one special step or are
valid for many steps are described at the end of each chapter.
Recommendations for performance monitoring can be found in the generic part of this document. The
performance of the most important steps of your core business processes should be monitored on a
regular basis. The monitoring procedure for performance monitoring of all steps that are executed on
the CRM system is generally the same. Therefore you will only find specific performance monitoring
recommendations on selected business process steps.
For some steps it is possible to use a the tool for an automated monitoring, if available. Such a
monitoring concept is optimally implemented using the Computer Center Management System
(CCMS) in conjunction with the SAP Solution Manager. Most of the monitoring objects originate in the
CCMS but can be implemented within the SAP Solution Manager and its functionality called SAP
Business Process Monitoring that offers for example an extended alert handling. Incase this is
possible you will find for the specific step a separate table indicating the automatic monitoring via
CCMS and Solution Manager
The SAP Business Process Monitoring within the SAP Solution Manager is the proactive and process
oriented monitoring of the core business processes of your company. It includes the observation of all
technical and business applicationspecific functions that are required for a smooth and reliable flow of
the business processes. For further details on Business Process Monitoring please refer to
http://service.sap.com/bpm.
1.2.4 Solution finding procedure
Generally in case of questions or problems that cannot be solved, forward the issue to the next
support level. If the corresponding escalation path is not well defined, contact the Application Support.
If you have identified a transaction, process step or SQL statement that has a bad performance,
search for relevant information in the solution database of the solution manager.
As next step search for related SAP Notes in the SAPNet. As input for the search, provide the relevant
data that applies in the particular case (transaction, program, table, component, release, etc).
If it is not possible for any of the defined support levels to provide a solution for a particular problem,
open a customer problem message in the SAPNet R/3 frontend system.
Under severe performance issues, we recommend ordering an EarlyWatch session with focus on
performance tuning.
1.2.5 Legend
This symbol indicates you a paragraph from where you can navigate to another chapter of
this document for more detailed information on a topic.
This symbol indicates you a paragraph from where you can navigate to another document within the
SAP Service Marketplace for more detailed information on a topic.
© 2005 SAP AG 5
2 mySAP CRM
SAP Customer Relationship Management (CRM) supports all “customerfacing” processes throughout
the entire customer relationship life cycle from market segmentation and opportunities to postsales
and customer service. It includes business scenarios such as mobile (or field) sales and service,
customer interaction center, Internet sales and service as well as Marketing.
3 mySAP CRM Online Sales

In the CRM Online Sales part of this Business Process Management Best Practice you will find
information regarding those steps and processes that are common to several CRM scenarios. The
following core business processes are considered to be the most vital processes for an SAP CRM
Online installation:
· Sales Order Management
· Sales Planning and Forecasting
· Territory Management
· Account and Contact Management
· Activity Management
· Contract Management and Leasing
· Incentive and Commission Management
· Sales Analytics
The management of the Sales order management business processes along with a processoriented
monitoring concept including the various components of an SAP CRM Online solution based on the
solution with a connected Backend is described in this Best Practice document. . For most customers
this business process is the most critical one.
The graphic shows the typical hardware solution landscape for CRM Online with CRM, IPC, R/3 (as
backend), APO (optional) and BW (optional) systems.
SAP APO
App
Server
RDBMS
SAP CRM
App SAP R/3
Server
App
Server
RDBMS
RDBMS
IPC SAP BW
App
Server
App
Server RDBMS
© 2005 SAP AG 6
These sections below are referenced in the corresponding business process steps of the other
scenarios in the chapters below.
3.1 Sales Order Management

The Sales Order Management topic of the CRM Online part of this document deals with those steps
involved in the sales order management process, that are common to the interaction center, field sales
and eselling scenarios. We consider here in detail the process steps:
· Create one order document (lead, quotation, sales order …)
· Determine price
· Determine configuration
· Check availability
· Upload of the sales order to the R/3 backend.
The steps of this business process that are executed on the R/3 system are not discussed in this
document in detail.
Process Workflow for Sales Order Management (Online Sales)
Business Process Step 1,2,3,4 or 8: Create one order document (CRM)
As part of the sales management live cycle you can create leads, opportunities, inquiries,
quotations, and/or sales orders. Any of these CRM one order documents can be created as the first
document of the cycle, without having created the others before. Which of these documents are
created in your CRM system strongly depends on your particular business process.
For instance the user can create a quotation depending on the requests of the business partner. The
quotation can have several line items with different configurable products. In this case the price can be
determined and the availability of the product can be checked for each line item individually.
If the quotation refers to an inquiry, two different ways can be realized to transform the inquiry into a
quotation.
1. The user can create a quotation with reference to an inquiry. In this case two documents exist
(quotation and inquiry).
2. The user converts the inquiry into a quotation by changing the status of the document. The original
inquiry position becomes a quotation position. In this case, the inquiry is not preserved as an
additional document.
© 2005 SAP AG 7
Also a sales order can be created in different ways. The sales order can be entered directly into the
system upon request of the business partner or based on a quotation. Similar to the quotation, also in
this case the price can be determined and the availability of the product can be checked for each line
item individually. If the sales order refers to a quotation, two different ways can be realized to
transform the quotation into a sales order.
1. The sales order can be created with reference to a quotation. In this case two documents exist
(quotation and sales order).
2. A quotation can be transformed into a sales order by changing the status of the document. The
original quotation position becomes a sales order position. In this case, the quotation is not preserved
as an additional document.
The monitoring activities and error handling procedures explained below do also apply for activities
and complaints. However please be aware that activities and complaints are not uploaded to the
backend system in standard.
Monitoring Activities
Apart from safeguarding the general availability of the R/3 system, CRM server, IPC and CTI server,
SAP recommends to monitor the objects listed in the following table in order to ensure the business
step Create one order document.
Monitoring Monitor Monit Indicator or Monitoring Activity or Respon Escalation
Object TA/Tool or Error Error Handling Procedure sibility Procedure
Freq.
Sales SDIMA – Daily Check if all sales documents Cross
document Integrity created in CRM have been application
consistency Manager consistently uploaded to the monitoring
R/3 backend team
Sales SLG1 Daily Error status Search for the object: Application
documents (log class very CRM_DOCUMENT; monitoring
with errors important, Investigate the cause of the team
important and errors
less important)
Performanc ST03, Week Long runtime See chapter performance Application Contact
e STAD ly and monitoring monitoring system
upon team administrator
error
BDocs SMWP Daily Red light at Investigate the cause in the Application
(CRM) Bdoc level Runtime Information tree monitoring
team
Queues SMWP Daily Queues are Investigate the cause in the Application
(CRM) stopped Runtime Information tree monitoring
team
BW BW Daily Check if all sales order data Cross
consistency Monitor / has been correctly uploaded application
(optional) weekl to the BW system. monitoring
y team
Automated monitoring via CCMS and Solution Manager
Monitoring Monitor Monitor Threshold Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
Performance SolMan, Weekly To be set Long runtime Monitoring on function code Application
CCMS and level can be set up in monitoring
upon SolMan using function code team
error NEWT_POP
10MAIN_CREATE (
transaction
SAPLCRM_10_MANAG_UI).
For background information
see chapter performance
monitoring
Update SolMan, Daily or # of errors Update error Analyze reasons for update Application
errors CCMS, hourly < 1 related to errors monitoring
(SM13) transaction
© 2005 SAP AG 8

crmd_order team
Application SolMan, Daily or # of errors Errors, Analyze reasons for errors Application
log entries (SLG1) hourly < 1 warnings and warnings monitoring
team
· If you find sales documents (opportunities, quotations, sales orders …) with error status in the
application log (slg1), you can use the report CRM_ORDER_READ to find out if the content of
the sales document is filled in correctly. For this fill in the object type (>Objects to be read)
and the external ID (> Header GUID) in the selection screen of the report. Selection by more
than one sales order number is possible. From here you can navigate directly to the related
tables. We suggest you to set the trace level for the CRM application log messages for the
members of the application monitoring team to ‘6’ (professional user). (This can also be set
with the parameter CRM_USER_LEVEL)
· When the sales order is saved, a BDoc is generated. This BDoc transacts with the application
database to request or write data. To ensure the normal flow of this business step, we
recommend monitoring within the Middleware Portal (transaction SMWP) the state of BDocs
on a daily basis. For all BDocs that are stopped, you should take a corrective action and
investigate the reason.
· Monitor queues with the Middleware Portal (SMWP) as well the data transmission between
the CRM and the R/3 system. Queues destined for the R/3 system should be relatively short
and quickly processed. Investigate the cause for those queues in status stopped.
· Whenever you change your sales order related customizing (in R/3 or in CRM), you can check
the consistency of the customizing. Use report CRM_ODE_CHECK_CFG to check the data
exchange customizing and report CRM_ODE_CHECK_DOC to check the filling of certain
fields as position, quantity, etc. For further questions regarding the replication between CRM
and R/3 see the FAQnote 656224.
· Monitor regularly the RFC response time statistics with the statistical records monitor (STAD),
system workload analysis monitor (st03) and SQL trace monitor (st05) in the CRM server and
R/3 system.
· If you use a BW system and plan to upload sales order related information to that system,
please refer to the document ‘SAP BW Consistency Check Guideline’, available on the SAP
service marketplace, for detailed information on the procedures you should set up to check the
consistency of your systems.
· The purpose of the “Data Integrity Manager” is to help to detect and repair data
inconsistencies between the CRM database and the CDB or the connected R/3. For additional
information please check the guide “Checking CrossComponent Data Integrity”. This can be
found in the SAP Service Marketplace (http://service.sap.com), alias CRMMW. There select
CRM powered by Netweaver > Process Integration > CRM Integration Services > System
Landscape Management.
Error Handling, Restartability, and Escalation
Sales documents with errors
In the daily operation of your business the CRM online user will have to handle with sales documents
(e.g. sales orders) that contain errors and cannot be further processed automatically. In order to find
the corrupted documents, search with transaction CRMD_ORDER in the CRM server for e.g. sales
orders with status “contain errors”. You will get all orders that contain errors. For every order an error
log is displayed. If you double click on every error item, you will get more information about why the
error occurred and what you can do to solve it. An error log entry may reveal inconsistencies in, for
example:
Business Partners: To check the business partner mapping, use transaction VD03 in R/3
Materials: Materials can be maintained in both the CRM server and the R/3 system. To find out
where the inconsistencies come from, check product maintenance and the product hierarchy.
SAP recommends setting a workflow so the corrupted orders receive the required postprocessing.
© 2005 SAP AG 9
Depending on your customizing it may be that the status “contains errors” is not available for every
one order document in your system.
To get the related BDocs of an erroneous order execute in transaction SE38 the program
CRM_MESSAGES and set the ‘user degree’ to 9. Press the button ‘copy values’ and confirm the
following popup. Then select in transaction CRMD_ORDER the affected document and watch the
document flow. Here you will find all Bdocs belonging to the order and you can start with error
analysis.
We recommend setting up a workflow so that corrupted orders trigger the required postprocessing.
For example, typical errors are:
· SPC_BRIDGE error: this error is typically solved while restarting the IPC server. Before doing
that you might want to save the IPC log file under another name since this file will be reset
every time the IPC is restarted
· Partner determination errors: review the customizing
In parallel you can check with transaction st22 if there are software dumps in R/3. If you find dumps
from pricing programs, review those programs together with the development team. If you could not
find the cause of the problem with this checklist, open a SAPNet message for further investigation.
Business Process Step 5 or 9: Determine price
The price of the product that is displayed in the sales order or quotation is calculated in the IPC in
background. The system recognizes the business partner and returns individual prices. Since release
2.0C the IPC does not have a separate database, but uses the CRM database to access the
customizing data as well as the condition records. This assures that the same price is determined for
all CRM scenarios. The master data that the IPC uses for pricing is typically maintained in the R/3
system and downloaded to the CRM database. Alternatively it is possible to maintain customizing and
condition records directly in CRM, but except for the trade promotion management scenario
(introduced with CRM 4.0), there is no upload of condition master data and customizing from CRM to
R/3 available. In order to calculate the price of the products the IPC reads from its buffer or from the
CRM database via RFC (Remote Function Call).
step Determine price.
Monitoring Monitor Monit Indicator or Monitoring Activity or Responsibility
Object TA/Tool or Error Error Handling
Freq. Procedure
CPU of IPC Task Daily Long response CPU Software monitoring team
Manager times
IPC IPC Daily Long response Command>Show Software monitoring team
Statistics Monitor times statistics
Middleware SMWP Daily Queues are Control status of the Software monitoring team
portal stopped, data queues. Review errors
download errors in log files. More info in
SAP Note 430980
CCMS RZ20 Daily Red traffic lights Software monitoring team
· Monitor regularly the CPU consumption caused by the IPC in order to avoid performance issues
for this business process step. In SAP Notes 372170 and 601800 you will find detailed information
about how to monitor the CPU consumption in the IPC.
· Monitor regularly the outbound queue in R/3 with destination CRM. In normal conditions, the R/3
Adapter automatically processes the documents in the queue. If data remains in the queue, this
symptom indicates that the R/3 Adapter is not working properly.
© 2005 SAP AG 10
· During data download from R/3 to CRM, monitor with transaction R3AM2 the log file of the
communication Backend/ Middleware and with transaction R3AM3 the status of the queue to find
out possible errors during data download.
· To improve performances in the IPC in general, import the latest service packs and patches
according to note 486061.
· Monitor regularly the IPC using the IPC Monitor tool. See more detailed information in the
Documentation in the SAP Internet Pricing and Configurator directory of your IPC installation.
You notice that the price for products being displayed is not the right one. If support packages were
recently applied, we recommend implementing the following checks to find out the cause of the issue.
· Check with transaction VA01 in R/3 if the pricing is working properly in R/3. If the pricing is
also not working in R/3, you might review the pricing conditions in R/3, and once this is
working properly, make a delta download to the CRM server. If customizing changes are done,
an initial download is necessary. The customizing will be generated with report
/SAPCND/RV12N001. See SAP Note 398078 to find more detailed information.
· Check with transaction SMWP in CRM if there are data in the outbound queue in R/3 System
with destination CRM: if you find data in the queue this indicates that the R/3 Adapter is not
processing the data in the queue automatically. Investigate why this happened in order to
avoid this in the future.
· In parallel you can check with transaction st22 if there are software dumps in R/3. If you find
dumps from pricing programs, review those programs together with the development team.
· If you could not find the cause yet and the pricing is nevertheless working properly in R/3, we
would recommend you contact an expert CRM pricing consultant to review if the pricing
procedures that you have implemented in R/3 are also supported in the IPC.
· If you could not find the cause of the problem with this checklist, open a SAPNet message for
further investigation on component CRMIPC.
· You can restart the IPC server. If this happens in a productive environment, all users might get
error messages when determining the price or the configuration of a product.
· In case of questions contact the system administrator or your development team. The process
owner of this process must be aware of any functional and development issues.
Business Process Step 6 or 10: Determine configuration
This is an optional step. Whenever configurable products are chosen, the IPC allows the users
entering products in the quotation or sales order to choose exactly which product configuration they
require. The configuration from a quotation can be copied to a sales order. The actual configuration of
the product takes place in the Internet Pricing and Configurator. You call the interface up from the
sales transaction. If the Internet Pricing and Configurator is not available, the product cannot be
configured. The master data that the IPC uses for product configuration is maintained in the R/3
system and downloaded to the CRM database. When a configurable product is handled in a sales
order transaction, the product is configured interactively by the IPC services. The IPC reads the
configuration data via RFC from the CRM database. The Internet Pricing and Configurator combines
the functions of the Sales Configuration Engine (SCE) and the Sales Pricing Engine (SPE).
step Determine configuration.
Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Handling Procedure
CPU of IPC Task Daily Long response times CPU Software
Manager monitoring team
IPC IPC Command>Show statistics Software
Statistics Monitor monitoring team
© 2005 SAP AG 11

ipcapplicati Upon Application error Check logfile for detailed Application
on.*.log error message information on error (SAP monitoring team
Note 658805)
CCMS RZ20 Daily Red traffic lights Check the areas with red Software
traffic lights and find the monitoring team
cause for them.
· Monitor regularly the CPU consumption caused by the IPC in order to avoid performance issues
for this business process step. In SAP Notes 372170 and 601800 you will find detailed information
about how to monitor the CPU consumption in the IPC.
· To improve performances in the IPC in general, import the latest service packs and patches
according to note 486061.
· Monitor regularly the IPC using the IPC Monitor tool. See more detailed information in the
Documentation in the SAP Internet Pricing and Configurator directory of your IPC installation.
Troubleshooting while calling the IPC for product configuration:
After checking the configuration icon at product level, you find there is a problem when the IPC is
called for product configuration. If Support Packages were recently applied, SAP recommends
checking whether the Support Package level in the IPC is the same as the Support Package level in
the CRM server. If not, implement the same Support Package level in the IPC and in the CRM server.
IPC uses ipcapplication.*.log file for logging in any errors or warnings that it has encountered. The
default location for the logfile is the path pointed to by the local environment variable TEMP. Under
Windows 2000 and XP this is normally the directory c:\Documents and Settings\<username>\Local
Settings\Temp
The quickest way to locate the TEMPfolder is to open Start>Run and type %temp% followed by
return.
In addition, use transaction ST22 to check whether there are short dumps in the CRM server and R/3.
If you find dumps from configuration programs, review those programs together with the development
team.
If necessary, you can restart the J2EE server and IPC server. However, if you perform a restart in a
productive environment, all users logged on at that moment will loose their sessions.
In situations that may require escalation, contact the system administrator or your development team.
The process owner of this process must be aware of any functional and development problems.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRMIPC.
Business Process Step 7 or 11: Check Availability
Availability check (ATP check) is used to check whether a product can be confirmed in a quotation or
a sales order, based on the fact that enough stock is available or can be produced or purchased on
time.
For more information regarding this step please refer to the Availability Check in the generic part of
this document.
Business Process Step 13: Create sales order (R/3)
After saving the sales order several processes are triggered on the backend: If the customer order is
complete in the CRM, it will be replicated to the R/3 for the logistic settlement. This replication involves
all order data including the confirmed quantities. Depending on the customized exchange scenario, the
order is changeable in CRM or not. For a detailed description see notes 541113 and 705200.
© 2005 SAP AG 12
Apart from safeguarding the general availability of the R/3 System, CRM server, IPC and CTI server,
step Create sales order (R/3).
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Sales order SDIMA On After failure of one Check if all sales orders created Cross
consistency demand of the systems or in CRM have been consistently application
if inconsistencies uploaded to the R/3 backend monitoring team
are expected
Data R3AM2 Daily Log file entries, Investigate the cause Cross
download and stucked queues application
from R/3 to R3AM3 monitoring team
CRM
Performance ST03, Weekly Long runtime See chapter performance Application
STAD and upon monitoring monitoring team
error
BDocs SMWP Daily Red light at Bdoc Investigate the cause Application
(CRM) level monitoring team
Queues SMWP Daily Queues are Investigate the cause Application

(CRM) stopped monitoring team
BW BW Daily / Check if all sales order data has Cross

consistency Monitor weekly been correctly uploaded to the application
(optional) BW system. monitoring team
3.1.1.1.1 Automated monitoring via CCMS and Solution Manager
Object TA/Tool Freq. Error Error Handling
Procedure
Performance SolMan, Weekly To be set Long runtime See chapter Application
CCMS and upon performance monitoring monitoring team
error
Update SolMan, Daily or # of errors Update error Analyze reasons for Application
errors CCMS, hourly < 1 related to update errors monitoring team
(SM13) transaction
crmd_order
Application SolMan, Daily or # of errors Errors, Analyze reasons for Application
log entries (SLG1) hourly < 1 warnings errors and warnings monitoring team
· Start transaction SDIMA on the CRM server to compare the sales orders in both systems on
header or item level. The purpose of the “Data Integrity Manager” is to help to detect and
repair data inconsistencies between the CRM database and the CDB or the connected R/3.
For additional information please check the guide “Checking CrossComponent Data
Integrity”. This can be found in the SAP Service Marketplace (http://service.sap.com), alias
CRMMW. There select CRM powered by Netweaver > Process Integration > CRM
Integration Services > System Landscape Management.
· Monitor with the Middleware Portal (SMWP) as well the data transmission between the CRM
and the R/3 system. Queues destined for the backend system should be relatively short and
quickly processed. Investigate the cause for those queues in status stopped.
· Monitor regularly the RFC response time statistics with the statistical records monitor (STAD),
the R/3 system.
· Monitor regularly the outbound queue in R/3 with destination CRM. In normal conditions, the
R/3 Adapter automatically processes the documents in the queue. If data remains in the
queue, this symptom indicates that the R/3 Adapter is not working properly.
© 2005 SAP AG 13
· During data download from R/3 to CRM, monitor with transaction R3AM2 the log file of the
communication Backend/ Middleware and with transaction R3AM3 the status of the queue to
find out possible errors during data download.
· If you use a BW system and plan to upload sales order related information to that system,
please refer to the document ‘SAP BW Consistency Check Guideline’, available on the SAP
service marketplace, for detailed information on the procedures you should set up to check the
consistency of your systems.
· For each BDoc an Error handling is maintained in transaction smw00. As an example, after 10
times unsuccessfully trying to process the BDoc CONGEN_OBJECT_WRITE an email will be
sent to the responsible person. Pro BDoc the number of executions and an action must be
defined and the required workflow must be set up in transaction swu3.
· Check that the code is working properly and if you do not find the cause of the issue, open a
SAPNet message for further processing.
© 2005 SAP AG 14
4 mySAP CRM Interaction Center Overview

The Interaction Center is a key technology of Customer Relationship Management (CRM) with
mySAP. It is designed as a multichannel, blended business process interaction center to empower
call centers to provide the highest possible level of customer service. It provides the technology for
contact center operations. It integrates a highly customizable and fullfeatured front office with your
backoffice as well as your entire range of customercentric processes. The Interaction Center
integrates technology for any business transactions via phone, email, chat, paging, or Web call back.
With CRM4.0 the Interaction Center WebClient was introduced. It can be fully integrated into a People
Centric CRM (PCC), web based environment. From CRM 4.0 onwards, the SAP Enterprise Portal is
used for PeopleCentric CRM. An iView for the ICWebclient is available.
The most important differences between IC WebClient and IC WinClient are listed here:
IC WebClient IC WinClient
· New BSP based Framework, runs in a · Dynpro Based Framework, application
Browser runs within SAP GUI
· Currently uses the new ICI / BCB interface · Currently only uses SAPphone interface
for CTI for CTI
· Usabilityoptimized views for certain · Reuse of screens for business process
business process objects objects from CRM Online
· Can integrate into CRM and R/3 objects · Can integrate into CRM or R/3 objects via
via PCC UI or WebGui new GUI session
ICWebClient is containing a Java Web application (ICSERVER) which is required to be deployed on
the Java 2 Enterprise Edition (J2EE). Actual J2EE 6.20 and 6.40 is supported!
The IC is developed with an open interface to support a variety of CTI middleware products, as well as
telephony servers and switches. The IC also supports Interactive Voice Response (IVR) systems,
which capture callattached data. The Integrated Communication Interface (ICI) supports the
integration of nonSAP communication products with SAP components that use communication
services. The new ICI is intended in particular for scenarios involving multiple communication
channels, such as telephony, email, and chat, but it can also be used in singlechannel scenarios. It
enables activities such as an agent accepting an inbound phone call, an agent deflecting an inbound
chat request, or a supervisor monitoring queues. The ICI is only one of several components required
to implement communication scenarios of this kind.
Organizations use the IC in a variety of business scenarios including sales or service. For one
company, the IC may be used as an inbound sales center, where agents enter sales orders, answer
delivery inquiries, create return material authorizations, or update customer addresses. Another
company might use the IC to register service requests for internal or external customers. Yet another
company might only process email correspondence with their customers through the IC. Agents in an
integrated call center may perform all of these activities.
To satisfy customers, customerfacing employees require quick and easy access to the information
about their customers and the transactions that will serve them. This requires an intuitive user
interface that supports the method of communication. This is realized in mySAP CRM with the role
based PeopleCentric User Interface (PCUI). PCUI is designed for integration in Enterprise Portal.
For the user to logon to Enterprise Portal in a specific role, a relationship between the Portal user and
the CRM system users must be created. There is no technical relationship between Portal role and
CRM role. The relationship is accomplished by assigning for every Portal role that is assigned to a
Portal user the according CRM role to the according CRMuser.
© 2005 SAP AG 15
Portal CRM
system
(SSO)
Portal user CRM user
Portal role CRM role
Authorization
Navigation
4.1 Interaction Center Building Blocks
Agent Agent IC Manager

WebClient WinClient Portal
mySAP CRM Interaction Center Other

scenarios
IC Sales
IC Sales IC Service
IC Service IC Marketing
IC Marketing e.g. Field
Sales or
Multichannel IC Management
IC Management Marketing
CRM
R/3 IPC
© 2005 SAP AG 16
The graphic above shows the abstract of a solution landscape for an Interaction Center. The central
point of a typical installation is the CRM server.
For the smooth and reliable operation of the core business processes it is required to ensure the
general availability and performance of the following system components (if used):
· CRM Server
· Backend System such as SAP R/3
· IPC
Basic instructions for the monitoring of these components are given in the Appendix.
SAP delivers CRM with a special monitor set: CRM Middleware Alert Monitoring. This set includes
monitors for the technical middleware components of the CRM CIC solution. It can be used via
SAPGUI using transaction RZ20. For more detailed information about how to install this monitor see
SAP Note 437187.
For general information regarding the use of Computer Center Management System (CCMS) in
combination with the SAP Solution Manager for central monitoring, refer to the SAP Best Practice for
Solution Management “Central System Monitoring for mySAP.com” that you can download from the
Solution Manager, if you have installed it, or from the Service Marketplace.
Monitoring in the mySAP CRM Interaction Center environment can be divided into the following areas:
· Monitoring the endtoend message flow from the CRM to the R/3 System
· Monitoring the queues located on the respective server systems
· Monitor the R/3 Adapter components (Download objects, log file, queues, requests)
· Monitor the network
· Operating system performance monitoring
· Database system performance monitoring
· Error analysis
The following table briefly lists the monitoring functions associated to the CRM Server and the R/3
system.
Server Types Monitoring Function
CRM Middleware 1. Monitor outbound queue, CRM middleware system è R/3 system
Server 2. Monitor inbound queue, R/3 system è CRM middleware system
3. Monitor middleware message flow
4. Monitor flow control
5. Monitor the middleware log
6. Monitor status of BDocs
7. Monitor initial download from R/3 system
8. Monitor R/3 basis system
9. Monitor database
10. Monitor operating system
11. Monitor network throughput
R/3 System 1. Monitor outbound queue, R/3 system è CRM middleware system
2. Monitor gateway
3. Monitor R/3 basis system
4. Monitor database
5. Monitor operating system
6. Monitor network throughput
© 2005 SAP AG 17
4.2 Core Business Processes in SAP CRM
Interaction Center
The following core business processes are considered to be the most vital processes for an SAP CRM
Interaction Center installation:
· Inbound Telesales
· Outbound Telesales
· Complaint Management in IC
The management of these business processes along with a processoriented monitoring concept is
described in this Best Practice document.
At the end of this part you will find a chapter about general recommendations for the management of a
SAP CRM Interaction Center.
4.2.1 Inbound Telesales
The following diagram shows the business process steps covered in this monitoring concept.
Depending on the configuration carried out in your project, some elements might appear different from
the description in this document.
Process Workflow for Inbound Telesales
The business process: ‘Inbound Telesales’ describes the process where customers or sales prospects
(consumers or enterprises) contact the interaction center to initiate a sales order. Furthermore,
customers often ask for information about products or services before placing an order, or wish to gain
information about the status of business transactions that have already been processed.
The typical process starts with the initial contact of the customer with the interaction center. This
contact can be represented by a phone call, an email or a fax.
Page 18 of 145
In case of a call this call is routed to a call queue. The customer can be identified with the ANI
(Automatic Number Identification) automatically. After picking up the call, the agent validates and
confirms the business partner. Emails and faxes are represented as work items in the agent inbox.
The agent can process and execute each item, which also leads to an identification and confirmation
of the sending customer.
Following he can use the fact sheet to get additional information about the customer. The interactive
script might be used for answering an incoming call. Depending on the request of the customer, the
agent can provide information about a specific problem using the knowledge search. An opportunity or
quotation might be created in advance before a sales order is created. By using the up, down or
crossselling functionality of the CRM system, products can be proposed to the customer.
Subsequently the agent creates the sales order. Prices and product configuration are determined in
the Internet and Pricing Configurator (IPC). The availability check for the sales order can be performed
in the APO or R/3 system. The saving of the sales order can trigger the sales order management in
the connected backend. The agent maintains details of the interaction record as for example priority,
reason, notes or description. When the interaction record is saved relevant key figures from
interactions in the Interaction Center are transferred to the SAP Business Warehouse (SAP BW) for
analysis purposes.
The steps mentioned here are optional and the business process can be adjusted to the requirements
of each customer. However the monitoring activities are not directly depending on the sequence or the
completeness of the sample process described above and can be used almost independently.
4.2.1.1 Business Process Step 1: Routing call, email, fax to queue
The routing of calls is hardware dependent and considers the availability of agents. Interactive voice
response (IVR) might be used to support the routing. Emails and faxes can be routed dependent on
business partner address details. Routing rules have to be maintained accordingly.
4.2.1.1.1 Monitoring Activities
step Routing call, email, fax to queue.
Monitoring Monitor Monitor Indicator Monitoring Activity or Responsibility
Object TA/Tool Freq. or Error Error Handling Procedure
Integration Hardware dependent Monthly No call Check and monitor the Software/
test for and throughput incoming/ outgoing call hardware
incoming upon to agents transfer to the agents to monitoring
phone calls error ensure that no calls get lost team
Check Hardware dependent Weekly Wrong Check and monitor the rules Software/
routing of and routing of and processing of the routing hardware
incoming upon calls to for the incoming calls. monitoring
calls error agents team
Check Compare routing rules (in Weekly Wrong Check and monitor the rules Application
routing of CRMC_CIC_MAIL_E_RESP and routing of and processing of the routing monitoring
emails and and upon emails for the incoming emails and team
faxes CRMC_IC_MAIL_E_RESP) error and faxes faxes.
and routing results to agents
inboxes
4.2.1.1.2 Error Handling, Restartability, and Escalation
In case of an error and escalation situation contact your system administrator or your telephony
hardware/implementation partner for further assistance.
4.2.1.2 Business Process Step 2: Identify, confirm account/ contact
person
When you answer an incoming call, the system automatically identifies the calling business partner
(account) by Automatic Number Identification (ANI). A prerequisite for the identification of the business
partner is the support from a telephone technology (e.g. ISDN). This transfers the number of the
incoming call including the dialed number (e.g. a general 0800 number or a special number of an
agent). This service is called DNIS (Dialed Number Identification Service). With this information the
© 2005 SAP AG 19
customer can be identified, if the number is assigned to a business partner in the system, and will be
proposed to the agent before actually picking up the phone. This mapping of the number to the
business partner can either be done on the CTI server (e.g. Genesys) or in the CRM system
(SAPphone). In case you don’t use ANI your call center agent searches for the calling business
partner, for instance by name or by business partner number.
Their sender address or number identifies customers in case of incoming emails or faxes. If this is not
possible the agent has to execute the search manually with other search criteria.
Once the customer is identified and confirmed, business partner data is displayed in the interaction
history, in the business partner search area and in the fact sheet. In the case of a new customer, you
have to create a new business partner.
The call center agent can create a new business partner (BP) or a new contact person by pushing the
corresponding buttons in the BP search environment. He has to specify all necessary data, as address
data, function, IBase data, etc. If the agent finds out that some of the identified business partner data
is wrong (e.g. the phone number of the contact person) he can maintain this as well.
If there is an R/3 backend connected to the CRM system, the new/ changed business partner data
may be replicated to the backend. (optional, not shown in the graphic).
step Identify, confirm account/contact person. The monitoring activities for this process step strongly
depend on the hardware used.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon
Object TA/Tool Freq. Error Error Handling Procedure sibility
Performance ST03, Weekly and BP finding See chapter performance Application
STAD upon error takes too long monitoring monitoring
team
BP creation, data Bdoc Daily Incorrect BP Check replication to R/3 Application
consistency monitoring data in R/3 monitoring
team
Procedure
Performance SolMan, Weekly To be set Long runtime Monitoring on function Application
CCMS and upon code level can be set up monitoring team
error in SolMan using function
codes
CSEARCH_SEARCH.
&IC1,
CSEARCH_CONTINUE
(Transaction CIC0). For
background information
see chapter
performance monitoring
Make sure that the necessary indexes for the BP search (and your search criteria) are available in the
system.
If created business partners are not replicated to R/3, use CRMM_BUPA_MAP to replicate it again.
If you could not find the cause of the problem with this checklist, open a SAPNet message (component
CRMCICBPSEA/CRMICSEA) for further investigation.
In general the business partner search is depending on several factors:
© 2005 SAP AG 20
· Number of master data (business partner)
Duplicates have to be prevented by an appropriate strategy to keep the volume of business
partner master data at a minimum level
· Quality of master data
Inconsistent and duplicated entries have to be avoided to get the best search result as
possible (e.g. no multiple hits due to duplicates)
· Search strategy depending on business process
The way the agents perform the business partner search is completely depending on the
information the customer provides. If possible selective criteria should be used like the
customer number and also the use of asterisks (‘*’) should be avoided. This has a direct
influence on performance.
4.2.1.3 Business Process Step 3 and 4: Retrieve information from fact
sheet
The HTML based fact sheet provides you with an immediate and condensed overview of information
about business partners taken from several sources such as business partner master data, statistical
and transaction data. It enables you to see quickly and easily the most essential details about a
customer.
The information contained in the fact sheet is divided into information (info) blocks that group together
certain kinds of data. The data itself not only is retrieved from the CRM system but also from other
systems like SAP R/3 or BW.
step Retrieve information from fact sheet.
STAD upon error takes too long monitoring monitoring
team
Consult note 490871 for performance problems, error messages and not working info blocks among
others. If you cannot find the cause of the problem open a SAPNet message for further investigation
(CRMCICHISCFA/CRMICCFA).
The performance of the fact sheet is mainly depending on 2 factors:
· Amount of information in fact sheet
Using the settings for the info blocks in the customizing can restrict the amount of data that will
be displayed.
· Source of information
The source of information has also a very big impact on the performance of the fact sheet.
For example the response time for retrieving information from a connected R/3 backend is
longer than just getting information from the CRM system. Establishing the network
connection and transferring the data back to the CRM system cause this. In addition this puts
load on the R/3 system and on the network. In general the data retrieved from connected
systems should be kept to a minimum.
In case of problems with data coming from other systems the analysis has to include the
source system.
4.2.1.4 Business Process Step 5: Use script for answering
Interactive scripts can be used to support the agent dealing with an incoming phone call. There are
standardized text components available which give the agent the correct greeting phrase to welcome
a customer on the phone, or remind him to ask all relevant questions to retrieve the required
© 2005 SAP AG 21
information needed for the business. Asked questions are dependent on the answer the customer has
given, e.g. yes or no. This is realized with a tree structure of possible answers.
step Use script for answering.
STAD upon error takes too long monitoring. monitoring
team
investigation (component CRMCICSCR/CRMICSCR)
4.2.1.5 Business Process Step 6 and 7: Search in knowledge database
In the Interaction Center, agents use the knowledge search to find solutions to problems or other
issues that are reported by customers through channels such as telephone, email or fax. It also can
be used to get additional information about products or for general questions from the business
partner.
The knowledge search is the entry point for searches in a knowledge base. In the IC WinClient the
knowledge base is the Solution Database (SDB). In the IC WebClient, the SDB is the default
knowledge base, but agents can switch and search other knowledge bases as well.
In the IC WinClient the search engine is TREX (Text Retrieval and Information Extraction). In the IC
WebClient, the default search engine also is TREX but other search engines could be used.
The actual search (Step 7 “Search Solution”) is performed in the search engine for the knowledge
search, the TREX (Text Retrieval and Information Extraction), which is the default search engine in the
IC WinClient. In the IC WebClient, the default search engine also is TREX but other search engines
could be used.
step Search in knowledge database and Search solution.
Monitoring Monitor Monitor Indicator Monitoring Activity or Respon
Object TA/Tool Freq. or Error Error Handling Procedure sibility
Performance ST03, STAD Weekly Long See chapter performance Application
and response monitoring monitoring
upon times team
error
Execution of Report Weekly Errors in Analyse report results Application
knowledge CRM_SAF_TOOL_DIAGNOSIS and knowledge monitoring
search upon search team
error
TREX server TREX server installation guide Weekly Knowledge Check the TREX server Application
and search not installation and whether the monitoring
upon working TREX service is running team
error
If the knowledge search returns bad results, the customizing of the search engine might have wrong
settings and should be adjusted following note 457764.
Please check SAP Note 702639 for a hint on performance improvement for the SAF diagnosis tool.
© 2005 SAP AG 22
For more information on the Software Agent Framework (SAF) and it’s diagnosis tool please go to the
SAP Library search for SAF or follow the link below.
http://aiokeh.wdf.sap.corp:1080/SAPIKS2/logonFromUrl.sap?_LOIO=B24EF97483FB11D68865
00008658ACB2&_SCLASS=IWB_STRUCT&_SLOIO=83C72C55F7F3463BAC2922EF300EAB45
&LANGUAGE=EN&RELEASE=500&IWB_INDUSTRY=BBPCRM&IWB_COUNTRY=&TMP_IWB_T
ASK=PREVIEW2&_CLASS=IWB_EXTHLP
investigation (component CRMCICIIA/CRMICSOL for step 6 and component EPKMTRX for step
7).
4.2.1.6 Business Process Step 8, 9, 13: Create Opportunity, Create
Quotation, Create Sales Order
For the process steps Create opportunity, Create Quotation, Create sales order (CRM)
please review the corresponding section in the Sales Order Management section in the
CRM Online part.
Procedure
code 10MAIN_CREATE
(transaction CIC0). For
see chapter
4.2.1.7 Business Process Step 10: Search, propose, configure product
For the process step Search, propose, configure product please review the corresponding
section in the Sales Order Management section in the CRM Online part.
4.2.1.8
4.2.1.9 Business Process Step 11, 12: Determine price. Determine
configuration
For the process steps Determine Price and Determine Configuration please review the corresponding
section in the Pricing section in the CRM Online part.
4.2.1.10 Business Process Step 14 and 15: Check availability (APO/
R/3)
For the process step Check availability(APO/ R/3) please review the corresponding section in the
Availability Check section in the CRM Online part.
4.2.1.11 Business Process Step 16: Create sales order (R/3)
For the process step Create sales order (R/3) please review the corresponding section in the Sales
Order Management section in the CRM Online part.
4.2.1.12 Business Process Step 17: Maintain interaction record
To complete the interaction record the agent can, for example, document the content of the call with
the customer. Therefore he can add further information, as notes and attachments, to the interaction
record or create follow up activities.
© 2005 SAP AG 23
In order to end the interaction with the customer, the agent chooses the ‘End Contact’ button. This
clears all fields in the interaction center user interface so that the agent can continue working with the
next customer.
For the process step Maintain interaction record please review the section in the Activity Management
section in the CRM Online part.
4.2.1.13 Business Process Step 18: Update interaction center
statistics
Relevant key figures of the interactions from the Interaction Center are passed to the SAP Business
Information Warehouse (SAP BW).
For the process step Update Interaction Center statistics please review the corresponding section in
the Connection to SAP Business Warehouse (BW) section in the CRM Online part.
© 2005 SAP AG 24
Outbound Telesales
Process Workflow for Outbound Telesales
The business process: ‘Outbound Call’ describes the process of an agent initiating calls to customers
or sales prospects (consumers or enterprises).
This process supports the execution of sales campaigns and periodic calls with call list management.
On the basis of a call list, the agent selects a business partner from the call list. Alternatively he can
place a call manually via the telephone functionality in the interaction center user interface. He also
can use the call preparation functionality to get information about the customer from the fact sheet in
beforehand of the actual call. After initiating the call, the agent has to validate the business partner. He
can use interactive scripts in order to explain the purpose of his call to the customer. Lead, opportunity
or quotation documents might be created. The agent might also provide information about up, down
or crossselling products for the specific customer. Consequently the agent can place a sales order.
The price will be determined in the Internet and Pricing Configurator (IPC). The availability check for
the sales orders can be performed in the APO or R/3 system. Saving the order can trigger the sales
order management in the connected backend. Finally the agent can create a follow up activity or
maintain the content of the call in the interaction record before it gets saved. When the interaction
record is saved relevant key figures from interactions in the Interaction Center are transferred to the
SAP Business Warehouse (SAP BW) for analysis purposes.
The following detailed description of the process steps with the monitoring procedure and activities for
the Outbound call focuses only on the process steps which are different to the process steps
mentioned in the process description above (see chapter: Inbound Telesales).
© 2005 SAP AG 25
4.2.1.14 Business Process Step 1: Create/Assign call list
Managers can create call lists for specific target groups or a range of business partners based on
maintained calling hours. They maintain call list details such as assigning call lists to agents, assigning
scripts to call lists, and copying, searching, or moving call lists. Finally every call from the call list is
represented by an activity in the CRM system. Interaction Center agents can execute the call lists
directly from the IC WinClient or WebClient user interface.
step Create/Assign call list.
and upon response monitoring monitoring
error times team
If call lists have to be split to get a smaller size à check note 669459: Call list splitting
If you could not find the cause of the problem open a SAPNet message for further investigation using
the component CRMCICCAMCAL or CRMICCAL.
4.2.1.15 Business Process Step 2: Select call from call list
To select the business partner from the call list in the WinClient user interface, the agent has to open
the campaign workspace and to click on a Call List that he wants to execute. This opens the Call List
browser workspace with the business partners the agent can make a call to.
In the WebClient the agent navigates to the call list view where he gets a list of assigned call lists. He
can select one and display the calls for the selected list.
step Activate from call list.
error times team
If call lists have to be split to get a smaller size à check note 669459: Call list splitting
If you could not find the cause of the problem open a SAPNet message for further investigation using
the component CRMCICCAMCAL.
4.2.1.16 Business Process Step 5: Execute call
After selecting the business partner to be called, a click on the dial button from the toolbar dials the
number. In case of multiple numbers a popup is shown to choose the right number. The business
partner is searched and confirmed automatically, the corresponding activity is opened.
If the agent wants to place an individual outbound call (not from call list), then he can use the consult
button to make a call.
step Execute call.
© 2005 SAP AG 26

error times team
If you could not find the cause of the problem open a SAPNet message for further investigation
(component CRMCICCOMTEL or CRMICCHATEL).
4.2.1.17 Business Process Step 6: Execute Call (Communication
Mgmt Software)
The execution of the call is depending on the hardware you are using. Usually the call is initiated in the
SAPphone application of the CRM system. SAPphone integrates telephony functions in SAP
applications. This allows data to be exchanged between computer and telephone processes. CIC uses
the SAPphone CTI interface to communicate all soft phone controls of the Front Office screen and the
different work modes and status of the agent. Then the CTI links the call to the connected phone
system (PBX) where it is physically generated.
The monitoring activities of this process step strongly depend on the used telephony system.
In case of an error and escalation situation contact your system administrator or your telephony
hardware/implementation partner for further assistance.
investigation (component BCSRVCOMTEL).
4.2.1.18 Business Process Step 8: Create lead
For the process step Create lead please review the Sales Order Management process in the CRM
Online part.
© 2005 SAP AG 27
4.2.2 Complaint Management
Process Workflow for Complaint Management
The business process: ‘Complaint management’ describes the process of handling customer
complaint requests in the interaction center. Agents can create complaint documents for issues that
have a limited degree of complexity, for example, complaints involving only one business partner and
for which no other related complaints are currently open. On creation of a complaint, agents
immediately see information that supports them in their interaction with the customer, such as the
warranties and service contracts that are valid for faulty products, or the reaction time stipulated in a
service level agreement. Created complaints can reference on CRM billing documents or documents
from integrated systems such as deliveries or invoices from the SAP R/3.
This scenario variant (especially the mentioned features) runs on the Interaction Center WinClient
only.
The typical process starts with an identified and confirmed business partner (account) from a phone or
email contact. The fact sheet can be used to get some additional information about the customer. The
interactive script is helpful to guide the agent to ask the best questions and to determine the right way
about handling the customer’s complaint. Depending on the request of the customer the agent might
provide information about a specific problem using the search in the knowledge database. Then a
complaint is created. Agents record the complaint reason and problem and can trigger the creation of
credit memos, return requests, or substitute deliveries, which are then handled by the back office.
Finally the agent can create a follow up activity or maintain the content of the call in the interaction
record before it gets saved. When the interaction record is saved relevant key figures from interactions
in the Interaction Center are transferred to the SAP Business Warehouse (SAP BW) for analysis
purposes.
© 2005 SAP AG 28
the Complaint Management focuses only on the process steps which are different to the process
steps mentioned in the process description above (see chapter: Inbound Telesales).
4.2.2.1 Business Process Step 8: Create complaint
You can create complaints for products or services that customers are dissatisfied with.
Complaints can be productrelated or have no reference to products.
Please also review the section Sales Order Management in the CRM Online part for general
monitoring activities for this step.
Procedure
code 10MAIN_CREATE
(transaction CIC0). For
see chapter
investigation (component CRMCICBTX).
4.2.2.2 Business Process Step 9, 10: Replicate return request item,
Replicate substitute delivery item
After saving the complaint in SAP CRM, the returns item is replicated in a sales order in SAP R/3 for
the purpose of logistics processing. This means that a sales order is automatically created with a
corresponding returns item.
step Replicate return request item.
BDocs SMWP Daily Red light at Investigate the cause Application
(CRM) Bdoc level monitoring
team
(CRM) stopped monitoring
team
If you could not find the cause of a problem open a SAPNet message for further investigation
(component CRMBTXBFIF).
4.2.2.3 Business Process Step 10: Replicate substitute delivery item
You create a subitem of category ‘Substitute Delivery’ for the main complaints item. After saving the
complaint in SAP CRM, the substitute delivery item is replicated in a sales order item in SAP R/3 for
the purpose of logistics processing.
© 2005 SAP AG 29
step Replicate substitute delivery item.
BDocs SMWP Daily Red light at Investigate the cause Application
(CRM) Bdoc level monitoring
team
(CRM) stopped monitoring
team
If you could not find the cause of a problem open a SAPNet message for further investigation
(component CRMBTXBFIF).
© 2005 SAP AG 30
4.3 Scenario specific recommendations
In this chapter you will find some general recommendation to improve the management and
performance of the SAP CRM Interaction Center. As well hints are given to locate functional problems
and to interpret the CIC response times.
4.3.1 Memory Consumption by transaction CIC0
Many functions of the whole CRM solution are integrated into the Interaction Center scenario.
Because of this, the memory allocated during a contact is not completely released after the contact is
finished.
Smart restart option
There is a 'smart restart' solution available (as of SP12 for CRM 3.0) where you can set a time and/or
memory limit for a transaction restart. When an agent starts CIC0, time and memory counters are set.
When one of the defined limits is exceeded AND the agent pushes the 'End Contact' button, the CIC0
will be restarted. Due to the restart, the memory is released and thereafter available for other users
again.
It depends on various factors how the restart options in CRMC_CIC_RESTART have to be set up.
It has to be found out which amount of memory a user needs and how much he can get at all. This
depends on
· available memory of the application servers
· CIC configuration
· number of contacts per time
· every action the agent performs
· ...
Transaction SM04 can be used to monitor the memory consumption and to see how fast it grows for
every user. In the syslog (SM21) you can see whether a restart was performed due to the memory limit
or due to the time limit.
Usually a value of 30 40 MB as limit is sufficient but this has to be verified using SM04 and the
syslog.
The time limit is less important. It can be set to 999 when a memory limit is set as recommended. But
if there are users, which only use the CIC temporarily, then a time limit could be useful, too. Because
in that case unnecessary allocated memory could be prevented by the restart.
From a functional point of view the limitations mentioned in note 542090 have to be considered.
In case you are using a Genesys Gplus Adapter, please refer to SAP Note 586037.
In case you have implemented owndeveloped workspaces, their data can be lost at End Contact,
when a restart is performed. To solve this problem and to present an unchanged framework to the
agent, the concept described in SAP Note 550027 can be used. Please refer to this Note and set up
this concept for your owndeveloped workspaces.
CIC Memory trace (as of CRM 3.1, SP04)
Using transaction CRM_CIC_TRACE the memory consumption while working with CIC0 can be
observed. The trace can be started in the same session or in parallel mode. The result list of the trace
displays the deltas in memory consumption between the different events and programs that are
executed during the CIC processes. Therefore steps with a high memory allocation can be found
easily.
Page 31 of 145
4.3.2 Statistical records (STAD)
The table below represents common CIC actions and their corresponding entries in transaction STAD:
Description: performed action in CIC
Transaction/Program, Fcode, CUA internal command: corresponding STAD entries
Description Transaction/ Fcode CUA internal command

Program
Search business partner CIC0 CSEA CSEARCH_SEARCH
Select business partner from CIC0 &IC1 &IC1
popup (in case of multiple hits)
Confirm business partner CIC0 CSEA CSEARCH_CONTINUE
Reset search fields CIC0 CSEA CSEARCH_DELETE
Display fact sheet SAPMHTTP
Execute action box transaction CIC0 %_GC %_GC *
Execute search in locator CIC0 BUS_ BUS_LOCATOR_SRCH_GO
Select inbox view CIC0 INBO INBOX_SEL_VIEW
Display email CIC_SOFMVIEW
Change to tabstrip in CIC0 AA_T AA_TAB*
application area * = tabstrip number
Change to tabstrip in CIC0 NA_T NA_TAB*
navigation area * = tabstrip number
End contact CIC0 ECNT
Any hitting of the return key (= CIC0 RFSH
“Enter”)
If there are problems to reproduce a certain problem the STAD entries may be helpful to figure out the
last steps until a specific point of time.
The display mode ‘Show business transactions sums’ has to be chosen to see the corresponding
entries in STAD.
For more information regarding STAD see also the chapter Performance Monitoring in the generic
part of this document.
4.3.3 Interpretation of response time of transaction CIC0
If the CRM system mostly is used for CIC scenarios then transaction "CIC0" may have one of the
highest "Average Response Time" results in the monitoring transactions STAD or ST03N. A high value
for the average response time may lead to the assumption that the performance is very bad regarding
this transaction.
In Transaction CIC0 the response time frequently includes a high RollIn + Wait time. In most cases
this RollIn + Wait time is caused by the following effects:
· Executing a CIC actionbox transaction an OnLine transaction is called in a remote system
and the agent continues the work there (creating of sales order in R/3). As long as the mode of
the remote system remains open, the CRM system holds an RFC for the remote system.
· The agent signals the Telephony Server to be ready to receive the next inbound call. In the
process, the system starts an RFC for the Telephony Server that is only terminated if a new
call is received.
The system adds the duration of these RFCs to the RollIn + Wait time and thus also to the response
time of Transaction CIC0. Therefore the average response time contains also times, during which
agents work in remote systems or wait for inbound calls. It cannot be used as a criterion for the
performance of the CIC0 transaction.
© 2005 SAP AG 32
Refer to note 594904 to get further information about alternatives to get a significant statement about
the CIC0 performance.
For more information regarding performance monitoring see also the chapter Performance Monitoring
in the generic part of this document.
© 2005 SAP AG 33
5 mySAP CRM Field Sales Overview

SAP Field Sales is the CRM scenario for field sales representatives. It supports them during the sales
process at the customer’s site as well as in their office work. It helps to synchronize the activities of
sales representatives, regional managers and selling teams.
This component allows field sales representatives to regularly share information about business
partners, contacts, or opportunities while still being able to work offline on their laptops. The laptops
are called mobile clients and are linked temporarily (e.g. by means of a modem) with the CRM server
for the exchange of data.
The field sales front office is fully integrated with the R/3 System that can be used as R/3 backend
system. With the help of the CRM Middleware, data changes made in the Field Sales component or
the R/3 System are automatically pushed and synchronized between the two.
5.1 Field Sales System Landscape

The main components of a CRMFSA installation are summarized in the following table and shown
schematically in the subsequent figure.
CRM Server
The CRM Server is used for central data storage and distribution unit for
the CRM components. Data from all mobile clients is consolidated in one
central database on the CRM Server and replicated to the clients
according to predetermined replication rules.
The CRM Server also handles the messaging between clients and
server, temporarily stores information and guarantees its delivery. Data is
exchanged with an R/3 system and other external systems.
The CRM Server contains the CRM Middleware, which is the heart of the
Field Sales scenario. It handles the controlled data exchange (replication,
synchronization or distribution) with other systems such as mobile clients,
backend systems and data warehouses. Especially for mobile clients, a
replication mechanism ensures a consistent and uptodate data set on
the distributed local databases. Message queuing ensures delivery and
processing of data.
Software adapters are used to connect to external systems. They map
and convert data to various formats. In addition, the CRM application
components exchange data with the middleware layer using a CRM
adapter, e.g. XIF.
Furthermore the CRM Server hosts the CRM server applications as well
as the consolidated database (CDB) in which all the CRM data is stored
centrally. The CDB is a logical component of the entire CRM database.
SAP CRM Release 4.0 provides also an independent CRM solution that
can be executable with thirdparty backend systems as well as SAP R/3.
The CRM Server 4.0 is based on SAP Release 6.20 (SAP Web
Application Server).
Communication The Communication Station acts primarily as a communication server. It
Station hosts the Microsoft Transaction Service (MTS), the technique for data
transfer, and the SAP DCOM connector. The Communication Station
transforms DCOM (Distributed Component Object Model) calls from the
mobile clients into RFC calls and hands them to the CRM Servers
Middleware and vice versa. The data that is to be exchanged is
accumulated and stored in queues at both ends (mobile clients and CRM
Server). The data distribution follows a flexible set of replication rules,
where business objects are assigned to mobile clients.
The reason for a separate communication server is load balancing, i.e. to
bundle the various connections between the single mobile clients and the
CRM server. There is only one connection between the communication
station and the CRM server.
The Communication Station is available for Windows NT 4.0 and
© 2005 SAP AG 34
Windows 2000.
Mobile The Development Workstation hosts the Mobile Application Studio
Development (MAS); an integrated development environment that provides the tools
Workstation that are used to customize and develop each layer of the mobile
component client software. For example, adding a new information field,
modifying the layout of an existing screen, or amending the rules
associated with the processing of information.
The MAS requires a connection to the Mobile Application Repository on
the Mobile Repository Server, but it is recommended to install the MAS
on its own machine or laptop. This allows having several developers
working on customization changes simultaneously.
This machine contains also software for system administration and
maintenance tasks. The software includes the following components:
Authorization Management Tool client (AMT), Mobile System
Maintenance application and Upgrade Console.
Mobile Repository The Mobile Repository Server contains the Mobile Application Repository
Server (MAR) as an MS SQL Server database and Mobile Application
Repository services and tools like the MAR Central Server service (used
to lock development objects in a multiuser development environment)
and the ARS Transport Agent (used to transport development objects
from one repository to another). The Transport Agent service is also
needed to distribute mobile client software upgrades via CRM server to
mobile clients.
Mobile Clients The Mobile Client software is the CRM functionality on a mobile terminal
either with or without (as workgroup client) its own dataset.
Typically Field Sales users have certain mobile client software with its
own database and an IPC (see below) on their laptops that enables them
to work offline. In a Workgroup Production Environment only one
common user database exists on the Workgroup Server.
Mobile clients connect to the CRM Server from time to time via phone or
network to exchange data, accumulated and stored in queues at both
ends. This connection is established via the Communication Station.
Mobile clients may also be permanently connected to the server.
IPC The IPC (Internet Pricing & Configurator) processes product
configurations and calculates product prices. This is a Java application
that is installed on the Mobile Client. It enables ffline product
configuration and pricing at the point of sale on the laptop, using the
same configuration and pricing rules and models as in the CRM Server or
the R/3 System.
SAP R/3 (optional) The R/3 system is connected to the CRM Server as a backend system
and provides additional business functionality such as sales and/or
distribution and/or financial accounting, e.g. it continues the sales order
management cycle when a sales order is created in CRM.
SAP APO SAP APO is part of the supply chain management. SAP APO comprises
(optional) tools for realtime planning and decision support.
With CRM Mobile Application SAP APO can be used as optional software
component in order to perform product availability checks (ATP) when
sales orders are created in CRM (Reservations cannot be done).
SAP Business SAP BW is an analysis tool that gathers and refines information from
Warehouse (BW) internal and external sources containing customizable reporting tools
(optional) from any perspective and predefined information models, reports,
analyses and key performance indicators. You can analyze data from
operative SAP applications as well from any other business applications
and external data sources such as databases, online services and the
Internet.
SAP BW can be used as an optional software component for all SAP
CRM scenarios in order to create reports and replicate them to the
different offline working users using the Middleware mechanisms. The
© 2005 SAP AG 35
BW analysis is replicated as MS Excel spreadsheets and will be available
within the Mobile Client in the component reports.
general availability and performance of the following system components:
· CRM Server (CRM Host)
· Communication station
· Mobile client
BW
Com m unication CRM Hos t
Mobile Client(s )
Station
Mobile Client
IPC RDBMS
MTS
Inter net Pr icing
IPC
DCOM and Co nfigur ator
MS SQL Connector OLTP R/3
CRM Server PlugIn
Middleware RDBMS
RDBMS
APO
RDBMS
Mobile Adm in Mobile Developm ent Mobile Repository

Workstation Workstation Server
Author izatio n Mobile Application

Management Tool Studio Mo bile Application
Repositor y Ser vic es
Mo bile Client and Tools
Mobile Client
IPC IPC MS SQL

MS SQL
MS SQL
Basic instructions for the monitoring of the CRM Server, the IPC and the SAP R/3 are given in the
Appendix. Instructions for monitoring the Communication station and the Mobile Clients are given at
the end of this chapter.
SAP delivers CRM with a special Middleware monitor set. This set includes monitors for the technical
middleware components of the CRMFS solution. It was implemented based on the CCMS Alert
Monitoring infrastructure. It can be used via SAPGUI using transaction RZ20 where it is available
under the SAP CRM Monitor Templates’ monitor sets with the name ‘CRM’. The CRM Middleware
Alert Monitor checks the most important processes within the CRM Middleware and generates alerts if
critical situations occur. For further information on Middleware Monitoring please also check the
document “mySAP CRM Monitoring 3.0”, that can be found under
www.service.sap.com/solutionmanagerbp > topic area > mySAP CRM Monitoring (far down the list)
Most important of these processes are:
· Processing of the CRMspecific qRFC inbound and outbound queues in the CRM System
· Processing of the CRMspecific qRFC outbound queues in the R/3 System
· Processing the BDoc messages in the flow
· Processing Replication/Realignment
© 2005 SAP AG 36
All R/3bound QRFCs can be monitored in R/3 by using standard R/3 AlertMonitoring functionality
(e.g. Short dumps, Update errors, Syslog). To detect possible critical situations within your main
processing we recommend setting up CRM Middleware Alert Monitoring.
For more information on the Middleware Alert Monitoring, please refer to the following
SAPNet Notes:
437187 CRM Middleware Alert Monitoring
441269 Setting up tRFC/qRFC monitoring in the alert monitor
485826 Corrections to CCMS tRFC/qRFC Monitor
combination with the Solution Manager for central monitoring, refer to the SAP Best Practice for
For CRM monitoring, refer to the SAP Best Practice for Solution Management: “mySAP CRM
Monitoring”.
For the documentation on the performance of the data exchange between the CRM Server and mobile
clients, see the SAP Service Marketplace (http://service.sap.com). To access the guide “Performance
guide for the Mobile Client”, go to Education, Consulting, Solutions Areas and more > Solution Details
> mySAP Business Suite > mySAP Customer Relationship Mgmt > Solution Library > CRM
Powered by NetWeaver > Application Platform > Mobile Technology
Core Business Processes in SAP CRM Field Sales: The following core business processes are
considered to be the most vital processes for a CRMField Sales installation:
· Sales order management
· Business Partner Management
· Activity Management
· Opportunity Management
· Campaign Execution
· Download from the CRM server to the mobile clients
· Upload from the mobile clients to the CRM server
This Best Practice document describes the management of the business process Sales order
management and a processoriented monitoring concept including the various components of a CRM
Field Sales solution. For most customers this process is the most critical one.
5.1.1 Sales order management
Sales order management in the Field Sales scenario typically begins with the creation of an inquiry, a
quotation or a sales order (generally speaking with the creation of a sales document) on a mobile
client, e.g. as consequence of a customer contact of a sales representative. To create a sales
document header information and items have to be specified: Sales documents can be generated on
basis of opportunities (also on basis of campaigns and listings that are not discussed in this
document). Configurable products can be processed using the IPC.
If the product price for a business partner is to be determined in the mobile sales application, the field
sales representative enters the order details (such as item, quantity, tax jurisdiction code, and so on).
The system calls the IPC on the mobile client that accesses the latest state sales tax rates for the
product. The system than calculates the price accordingly.
If document layouts have been defined, sales documents can be generated using a layout and then be
printed out. As soon as a sales representative considers a sales document as complete, it can be
finished and is thus ready for upload to the CRM server. When the next upload is performed using the
program ConnTrans with the send option, all finished sales documents are uploaded to the CRM
server.
On the CRM server the sales document (inquiry, quotation or sales order) is created and saved to the
consolidated database (CDB). The data is also uploaded to an backend system, e.g. an R/3 System, if
connected. In this document the scenario is described with an R/3 System connected. The sales
document is then created in R/3.
© 2005 SAP AG 37
In parallel the sales order is replicated to the mobile clients (the order with status “to be distributed”).
Later the CRM gets a confirmation of the backend system and the status of the sales order is changed
to “successfully distributed”. This status change is replicated to all mobile clients that have appropriate
subscriptions.
Process Workflow for Sales Order Management (Field Sales)
5.1.1.1.1 Monitoring Procedure
Please note that for this special business process (or rather this special scenario) a stepwise
monitoring concept is hard to define. Sales representatives initiate all steps that run on mobile clients.
Typically sales representatives hardly do any monitoring activities other than informing an
administrator, the hot line or similar in case of errors. Furthermore all steps running on the CRM server
as well as on a possible backend system run automatically.
When setting up a proper monitoring concept the general monitoring activities have to be defined
clearly and have to run on a regular basis. Please read the Specific Monitoring part at the end of this
chapter carefully and include the described actions to your monitoring concept.
5.1.1.2 Business Process Step 1, 2, 5,: Create Inquiry, Quotation, Sales
Order
This is an optional step that takes place on the mobile client. An inquiry is preceded by (and based on)
a customer request to the company whether certain goods are sold at a predefined price. The sales
information of an inquiry that is given by the sales representative is not binding. The request can refer
to materials or services, conditions and, if necessary, delivery deadlines. The intention of an inquiry is
to support a business partner’s ability to make informed purchasing decisions.
An inquiry is created with header and line items like an inquiry in R/3. Inquiries are sales transactions,
that is, transaction types with the business transaction category ‘sales’. The business function for
inquiries is found at item level for a business transaction. They are only indicated as inquiries by the
system status Inquiry. A business transaction can, for example, also contain services or order items, in
addition to inquiry items.
An inquiry status is given at item level. Inquiries are processed converting the item status to status
quotation or order.
© 2005 SAP AG 38
Apart from safeguarding the general availability of the system and software component mobile client
SAP recommends to monitor the objects listed in the following table in order to ensure that the
business step Create Inquiry can be performed.
Monitor ing Monitor Monitor Indicator or Monitor ing Activity or Responsibility
Object TA/Tool Freq. Er r or Er r or Handling Pr ocedur e
Sales Applica Upon error Application Contact Application Sales representative/end
document tion error monitoring team or system user
trouble message administrator (depending on
shooting error) for error handling
on
mobile
clients
Performance Upon Long Contact application Sales representative/end
performance response monitoring team or system user
problems time of administrator for
transaction housekeeping and/or tracing
Performance SQL On demand Response SQL Trace of transaction and Application monitoring
Profiler of sales time of query analysis team or system
and representativ transaction administrator
Trace, e (in case of
SQL/ reported
Query performance
Analyzer problems)
Mobile client House At least twice Application monitoring
keeping a year and on team or System
for demand (in Administrator
Mobile case of
Clients reported
performance
problems)
investigation. Please use component CRMMSASAD.
5.1.1.3 Business Process Step 2: Create Quotation
This is an optional step that takes place on the mobile client. A quotation is a legally binding
agreement to deliver specific products or a selection of a certain amount of products in a specified
timeframe at a predefined price. A quotation has a validity period. Within the validity period, the
customer has the option of placing an order within the agreed conditions with reference to the
quotation, or to cancel a contract. A customer quotation can refer to a partner sales activity or can be
used by the sales area to reply to a customer inquiry.
A quotation is created with header and line items like a quotation in R/3. You can manually create a
quotation, and determine items and details, with or without using the IPC, i.e. with or without
configuration and/or pricing. Quotations are sales transactions, that is, transaction types with the
business transaction category ‘sales’. The business function for quotations is found at item level for a
business transaction. They are only indicated as quotations by the system status Quotation. A
business transaction can, for example, also contain services or order items, in addition to quotation
items. A quotation can be created with reference to an inquiry.
Sales representatives manually create a quotation, and determine items and details, with or without
using the IPC, i.e. with or without configuration and/or pricing (see below).
Quotation items are checked with a separate ATP profile for availability, which can be defined in
Customizing for the item category – see also generic part: ATP for sales documents.
business step Create Quotation can be performed.
© 2005 SAP AG 39

Sales Applica Upon error Application Contact Application Sales
document tion error monitoring team or system representative/e
trouble message administrator (depending on nd user
on
mobile
clients
Performance Upon Long Contact application Sales
performance response monitoring team or system representative/e
problems time of administrator for nd user
Performance SQL On demand Response SQL Trace of transaction and Application
Profiler of sales time of query analysis monitoring team
and representativ transaction or system
Trace, e (in case of administrator
SQL/ reported
Query performance
Analyzer problems)
Mobile client House At least twice Application
keeping a year and on monitoring team
for demand (in or System
Mobile case of Administrator
Clients reported
performance
problems)
5.1.1.4 Business Process Step 5: Create Sales Order
This is a step that takes place on the mobile clients. A sales order is created with header and line
items like a sales order in R/3. A sales order can also be created as ‘followup’ document of a
quotation.
Sales representatives manually create an order, and determine items and details, with or without using
the IPC, i.e. with or without configuration and/or pricing (see below).
business step Create Sales Order can be performed.
Sales Applica Upon error Application Contact Application Sales

document tion error monitoring team or system representative/e
trouble message administrator (depending on nd user
on
mobile
clients
performance response monitoring team or system representative/e
problems time of administrator for nd user
Trace, e (in case of administrator
SQL/ reported
Query performance
Analyzer problems)
© 2005 SAP AG 40

Clients reported
performance
problems)
5.1.1.5 Business Process Step 3,4,6 or 7: Determine the Price of the
Product
This is an optional step that takes place on the mobile client. The price of a product is determined by
the IPC (Internet Pricing and Configurator). The IPC uses the condition technique for pricing, like R/3.
The master data for the pricing is downloaded from the central pricing system.
Pricing can begin after the field sales representative has started pricing in order entry or quotation
entry. The system calculates the price for each item in the background using the data that has been
entered (e.g. customer, material and date) and the master data set up in the system (e.g. material
price, discounts). It then adds all of the items to find the overall result of the document.
To see which conditions the system has used for pricing, the salesperson calls up the item pricing
screen (display or change mode). In the change mode, the calculated amount or the conditions used
for pricing can be changed, provided the relevant condition types have been defined as changeable.
If required, the currency units or the units of measure can also be changed. Once a unit has been
entered, the system automatically converts the condition value into the document currency.
If all of the manual changes are to be deleted, the price determination can be carried out again. The
system then calculates a new price on the basis of the existing master data, without taking into
account any of the manual input. The pricing result appears in the document.
Tax Process: The tax determination allows the field sales force to determine taxes on products, in
order to provide business partners with accurate, uptodate pricing information. When the
salesperson wants to determine the product price for a business partner the order details (such as
item, quantity, tax jurisdiction code, and so on) have to be entered. The system then calls the IPC. The
IPC starts pricing and calls the TTE for tax determination. The TTE triggers the tax determination
function and determines the applicable tax calculation procedure. Then the IPC completes pricing and
calculates tax amount. Finally the IPC returns price and tax amount to the mobile sales application.
business step Determine the Price of the product can be performed.
Refer to SAP Note 526874 for all customizing issues related to Pricing and Configuration in the FS
scenario. Refer to the SAP Note 658805 for information about IPC logs.

ipcapplication Upon error Application Check logfile for detailed Sales
.*.log error information on error (SAP representative/e
message Note 658805) nd user or
Application
monitoring team
performance response monitoring team or system representative/
problems time of administrator for end user
e (in case of administrator
© 2005 SAP AG 41

Trace, reported
SQL/ performance
Query problems)
Analyzer
Clients reported
performance
problems)
If a pricing problem on a mobile client cannot be solved easily, the same sales document example
should be investigated on the CRM Server as a matter of principle. The 'same' example means a sales
document of the same sales document type, with the same soldto party, the same sales organization
and the same product(s). If the same errors occur the problem should be solved on the CRM Server
rather on the client (or first on the CRM Server and subsequently on the client).
If the problem does not occur on the CRM Server and the description below or the troubleshooting tips
in the Appendix do not help, a message has to be opened and ideally the log files (see below) should
be attached.
Pricing Analysis
The "Pricing Analysis"trace shows how the IPC has searched for condition records during the pricing
of a sales document. The "Pricing Analysis"trace is the first place to look, when pricing works
technically, but the wrong price is calculated because for example not all expected condition records
have been found by the IPC. The trace shows:
· Which condition tables where searched by the IPC and which searchcriteria have been used.
· Which requirements/userexits were checked during pricing and the result of the checks
To turn on the “Pricing Analysis”trace in Mobile Sales.
Until CRM 4.0 SP03 "Pricing Analysis"trace is activated on sales documentlevel by setting the
checkbox "Pricing Analysis" in the "Details" tileset.
Starting with CRM 4.0 SP03 the "Pricing Analysis"trace is activated on user level, rather than on the
sales document level. To enable the "Pricing Analysis"trace:
Open the Mobile Client Application à Select the component "Employees" à Click on "Settings".
In the tile "Settings" set the check box "Pricing Analysis".
To view the Pricing Analysis:
In the component "Sales Transactions" create a new sales document and add line items and save.
Go to the tileset "Item Pricing Conditions”. The "Analysis" button should now be enabled.
Click on the "Analysis" button to view the trace of the steps performed by the IPC during the pricing of
the line items.
When the "Pricing Analysis"trace is turned on, the performance of pricing is reduced, because the
IPC has to collect trace information. Always turn off the "Pricing Analysis"trace, when you do not need
it. The "Pricing Analysis"trace should not be turned on during productive use of the application due to
the impact on performance.
The IPC logfile (ipcapplication.*.log) contains the following information (errors and warnings)
produced by the IPC:
· Error and warning messages when customizing data is missing or incomplete.
· Warnings when condition master data tables are missing.
The IPC logfile is the first place to look for more information when pricing or configuration does not
work. The logfile is not overwritten when the application is restarted.
You can locate the ipcapplication.*.log file as follows:
By default the IPC writes a logfile called ipcapplication.0.log, until it reaches the size of 1 MB. The
IPC now starts writing into a new logfile called ipcapplication.1.log. When this file has also reached a
size of 1MB, the first logfile ipcapplication.0.log is overwritten.
The number of logfiles, their size and the name of the logfiles can be customized. The procedure is
© 2005 SAP AG 42
the same as for the IPC in the CRMOnline scenario. Refer to IPC specific documentation.
The default location for the logfile is the path pointed to by the local environment variable TEMP.
Under Windows 2000 and XP this is normally the directory c:\Documents and Settings\<user
name>\Local Settings\Temp
return.
The following Field Salesspecific trace information can be found in the IPC logfile.
The IPC can be configured to produce additional Mobile Sales specific traceinformation. The trace will
then contain the following additional information:
· All IPC methods called by Field Sales
· For which object the methods was called (i.e. the sales document or lineitem guid)
· The input parameters of the methods
· The output parameters of the methods
· The duration of the call in Java.
To enable the logging of the additional traceinformation you have to change the properties file
"logging. properties". This file can be found under the folder <installation path>\SAP\IPC\lib\properties
In this file uncomment the following lines by removing the preceding "#"
Setting to enable the logging:
# Trace for Mobile Sales
com.sap.spc.beans.logs = log [Unknown]
com.sap.spc.beans.severity = PATH
Setting to disable logging:
#com.sap.spc.beans.logs = log [Unknown]
#com.sap.spc.beans.severity = PATH
IMPORTANT: The writing of the additional traceinformation affects performance! Turn it off when not
needed by commenting the above lines again.
For the Field Sales scenario the IPC requires SUN JRE version 1.3.1_05 or later, but not SUN JRE
1.4 or later (see above). The SAPInst installer for IPC 4.0 executes all installation steps automatically.
Please refer to the SAP Note 0433855 for detailed information on Java Runtime Environment for
Mobile IPC 3.0/3.1/4.0.
investigation. Please use component CRMMSAIPCPRI.
5.1.1.6 Business Process Step 4 or 7: Configure the Product
This is an optional step that takes place on the mobile client. If the sales representative creates a
sales order for a configurable product, the configuration is performed using the IPC (Internet Pricing
and Configurator). The IPC is realized as a standard Java interface. The master data used for product
configuration is maintained in R/3 and downloaded to the mobile client.
When visiting customers the IPC enables the field sales representatives to discuss their customer’s
requirements, with a view to presenting them one or more quotations for different combinations of
product options (variants).
Whenever a salesperson enters a configurable product as an item in a quotation or sales order
Configure has to be chosen. A screen appears where the salesperson assigns values to the
characteristics of the product, according to the product options required by the customer. This screen
is CRM Mobile’s interface to the IPC. Once the configuration is complete, the salesperson can
proceed with the quotation or sales order in the usual way. The configuration data is uploaded to the
CRM Server for further processing with the next upload.
business step Configure the Product can be performed.
© 2005 SAP AG 43
Refer to SAP Note 526874 for all customizing issues related to Pricing and Configuration in the FS
scenario. Refer to the SAP Note 658805 for information about IPC logs.
ipcapplication Upon error Application Check logfile for detailed Sales
.*.log error information on error (SAP representative/e
message Note 658805) nd user or
Application
monitoring team
Performanc Upon Long Contact application Sales
e performanc response monitoring team or system representative/end
e problems time of administrator for user
transactio housekeeping and/or
n tracing
Performanc SQL On demand Response SQL Trace of transaction Application
e Profiler of sales time of and query analysis monitoring team
and representati transactio or system
Trace, ve (in case n administrator
SQL/Qu of reported
ery performanc
Analyze e problems)
r
Mobile client Housek At least Application
eeping twice a year monitoring team
for and on or System
Mobile demand (in Administrator
Clients case of
reported
performanc
e problems)
Please note that if you do not use configuration on the mobile client, the import manager should be
disabled for performance reasons. You can disable the import manager by setting the following
registry key
'HKEY_LOCAL_MACHINE\SOFTWARE\SAP\MSA\SCE\parameters\ImportManagerSupport' to
'FALSE'. You may enable the import manager again by setting the key to 'TRUE'.
If a configuration problem on a mobile client cannot be solved easily, the same sales document
example should be investigated on the CRM Server as a matter of principle. The 'same' example
means a sales document of the same sales doc type, with the same soldto party, the same sales
organization and the same product(s). If the same errors occur the problem should be solved on the
CRM Server rather on the client (or first on the CRM Server and subsequently on the client). If the
problem does not occur on the CRM Server and the description below or the troubleshooting tips in
the Appendix do not help, a message has to be opened and ideally the log files should be attached.
If there are any problems with the IPC call, first check the Java Version.
IPC uses ipcapplication.*.log file for logging in any errors or warnings that it has encountered. The
default location for the logfile is the path pointed to by the local environment variable TEMP. Under
Windows 2000 and XP this is normally the directory c:\Documents and Settings\<username>\Local
Settings\Temp
return.
Problems with configuration in MSA are generally caused by an inconsistent state of the consolidated
database (CDB). Please refer to the SAP Note 563053 for solution to the problem.
investigation. Please use component CRMMSAIPCCFG.
© 2005 SAP AG 44
5.1.1.7 Business Process Step 8: Generate for printing
This is an optional step that takes place on the laptop. A printout of the sales order can be made
through the mobile client. The sales representative chooses button “Generate” for generating a
Microsoft Word document based on a layout that has to be selected for printing. Before this function
can be used, at least one document layout of a relevant type needs to be defined.
Typically an error occurs if no layout for this sales document could be found. Please refer to the MSY
application help for detailed information on designing layouts. Standard layouts, provided by SAP, can
be imported via MSY application. Please refer to the SAP Note 620722.
If you are unable to generate layouts using the configuration data please refer to the SAP Note
766345. The reason is the changed configuration data model in CRM 4.0. Configuration data is not
stored in the SMOCUVAL table anymore but for performance reasons is stored as XML in the
SMOCUCFG table. The new interfaces for document generation are available from Field Sales 4.0
SP05 and onwards.
Other SAP Notes:
737733 Enhanced features for Document Generation
766334 Printing Configuration Characterstics using doc generation
766345 Interfaces to extract configuration XML in MSA 40
5.1.1.8 Business Process Step 9: Submit sales document
This is a step that takes place on the mobile client. Once the sales order has been put in its final form,
the ‘Submit’ button has to be used. To submit a sales document; indicates that a sales document is
ready for upload to CRM Online.
If you have created several versions of a quotation for a business partner, you would ideally only
submit the final one for upload that is, the one that has become effective.
Once a sales document is submitted, it enters the outbound queue, and is uploaded to CRM Online
the next time you synchronize data.
After the sales document is available in CRM Enterprise you should not change it any more on the
laptop, as you do not know if it has already been processed and thus your changes won’t have any
effect any more (for instance, changing the amount of an orderitem, if the order is already shipped).
You can therefore customize Mobile Sales either by making a sales document readonly, after it has
been marked for submission, or making it still is available to specific employees for editing.
From CRM 4.0 SP04 onwards users can modify documents which have been submitted
to/downloaded from CRM server. You can modify the following on the mobile client: Items, Partners,
Business data, notes and attachments. It is not allowed to delete any of the above objects. In order to
maintain data consistency, editing is restricted in a way that only one sales rep (laptop user) at the
same time will be able to do updates on the same document.
The update scenario (new functionality of MSA SAD 4.0) requires a partner with a partner function,
which acts as token. Means the partner who is assigned to this token partner function only can modify
the current sales document. The token partner function can be specified through the Sales Doc
Customizing. The token partner function is of type employee. The partner function type for the same is
0008. Please refer to the SAP Note 725187 for detailed information on the sales transaction update
scenario.
business step Submit sales document can be performed.
BDOC SMQ1 Check if BDOC Sales
Client STFC_WRITE_TO TCPIC representative
Console has been added to the
© 2005 SAP AG 45

à Data outbound queue
Transfer
à
Queue
Monitor
à
Outbou
nd
Queue
Sales Applicati Upon error Applicatio Contact Application Sales
document on n error monitoring team or system representative
troubles message administrator (depending /end user
hooting on error) for error handling
on
mobile
clients
Performanc Upon Long Contact application Sales
e performanc response monitoring team or system representative
e problems time of administrator for /end user
transactio housekeeping and/or
n tracing
Performanc SQL On demand Response SQL Trace of transaction Application
e Profiler of sales time of and query analysis monitoring
and representati transactio team or
Trace, ve (in case n system
SQL/Qu of reported administrator
ery performanc
Analyze e problems)
r
Mobile client Houseke At least twice Application
eping for a year and on monitoring team
Mobile demand (in or System
Clients case of Administrator
reported
performance
problems)
5.1.1.9 Business Process Step 10: Perform upload (ConnTrans)
This is a step that is started on the mobile client. The sales representative can upload new data by
dialing up a modem connection (or by connecting via network) to the CRM server and starting the
program Conntrans.exe on the mobile client. The data from the outbound queue in the mobile client is
uploaded the CRM Enterprise server.
Conntrans starts the Message Transfer Service Client that takes BDocs from the outbound queue of
the mobile client and sends it to the Message Transfer Service Server that is located on the
communication station. In addition, the ConnTrans_Log.xml file is generated that contains runtime
information associated with the execution of ConnTrans. CRM Mobile sends data with a
synchronization BDoc to MW. The data is mapped into a messaging BDoc and goes via the CRM
adapter to the validation system CRM Online.
For messaging BDoc types, the name of the validation function module must be specified (field
SMW3FDBDOCVALIFUMO).
For synchronization BDoc types, the name of the mapping class (implementing interface
IF_SMW_MAP) must be populated, if the synchronization BDoc type is linked to a messaging BDoc
type (required to transfer data changes from mobile to CRM online). The link between a mBDoc and a
sBDoc is established with the BDocModeler (transaction SBDM on the CRM server).
© 2005 SAP AG 46
Typically the sales representative that initiated the run will not monitor every ConnTrans run.
Therefore the following monitoring activities should not be seen as everyday activity, but rather as
monitoring activities for the system administration team in case of problems and for technically skilled
sales representatives.
Apart from safeguarding the general availability of the system and software components SAP CRM
System, R/3 System, Communication station, and mobile clients SAP recommends monitoring the
objects listed in the following table in order to ensure that the business step Perform upload
(ConnTrans) can be performed.
Monitor ing Monitor Monitor Indicator Monitor ing Acitivity or Responsibility

Object TA/Tool Frequ. or Er r or Er r or Handling Pr ocedur e
Outbound Client Console Each time Monitor the outbound queue on the Sales
queue and ConnTrans mobile client. representative/end
logfile on is used View the logfile in the in client user
mobile client console.
Errors, ConnTrans_Log.xml Upon error Check logfile for detailed information Application
warnings on error monitoring team
Errors, TransferService.log Upon error Check logfile for detailed information Application
warnings fileon communication on error monitoring team
station
Errors, TransferService.log Upon error Check logfile for detailed information Application
warnings file on mobile client on error monitoring team
Performance MS Windows NT On demand Lon Check operating system load System
Performance Monitor runtime administrator
on mobile client and
communication
station
Inbound SMQ2 on CRM On demand Monitoring inbound queue on CRM System
Queue Server Server administrator
If the queue has status STOP, this
might be a Customizing problem in
the CRM application
BDoc SMW01(SMW02 and Upon error Check if Bdoc Application
SMW03) on CRM (SALESDOCGEN_OBJECT_WRITE) monitoring team
Server is there. If this is not the case the
inbound queue may be not
registered.
Analysing Bdoc messages and
perform required actions, e.g. BDoc
messages with status beginning with
E (red traffic light) need manual
correction and retry, see also BDoc
Monitoring and Handling.
TRFC SM58 on CRM Upon error Monitor all transactional RFCs Application
Monitoring Server (R&R) (tRFCs) processed on the CRM monitoring team
Server
ConnTrans SMWMCOMM on Upon error Monitor ConnTrans performance and Application
Performance CRM Server data exchange monitoring team
Connection DCOM Connector Upon error Monitor connection components System
Monitor on CRM administrator
Server
Message SMWMFLOW on Upon error Use this as a starting point for Application
flow CRM server analyzing performance problems monitoring team
statistics
Flow SMO8FD on CRM Upon error Check consistency of Flow Application
Definitions server definitions monitoring team
Replication SMOHQUEUE on Upon error Display information about the status Application
queues CRM server (R&R) and content of the replication and monitoring team
realignment queues in the clients
defined in the CRM Server
© 2005 SAP AG 47
Monitor ing Monitor Monitor Indicator Monitor ing Acitivity or Responsibility

Object TA/Tool Frequ. or Er r or Er r or Handling Pr ocedur e
Performance SQL Profiler and In case of Long SQL Trace of transaction and query Application
Trace, SQL/Query performance runtime analysis monitoring team
Analyzer problems or system
administrator
Performance Transaction STAD/ Weekly and Long See chapter performance monitoring Application
Transaction ST05 on upon error runtime monitoring team
CRM server and R/3
System
On the Mobile Client the ConnTrans_Log.xml file is generated that contains runtime information
associated with the execution of ConnTrans. You can specify default values for logging and UI related
options in the ConnTrans_Startup.xml file. As a result, when you invoke ConnTrans, the default
settings are read from this file and accordingly the data synchronization is performed. ConnTrans
generates an XML file (StatisticsLog.xml) that captures statistics such as time taken to process the
different stages (Send, Receive, and Import) of the data synchronization process. The system
administrator can use this file to analyze data related to the performance of ConnTrans.
If you face any problems with Conntrans or the BDoc Layer, you should apply the SAP Note 708378
before opening an OSS message. The Note contains the link to the Note 716052 (HotFix For CRM
4.0 Mobile Client).
The basic performance issue for the data upload is the performance of the communication line
(Telephone; ISDN, DSL internal network). These communication lines differ significantly in speed. The
workload on the client (“clearing MW_Qout”) is neglectible. Other components affected are the Comm
Station (data is sent though the Commstation, DCOM calls are transferred into RFC calls and vice
versa) and the CRM Server, where the incoming data has to be processed (Inbound Queue, SMQ2).
Usually the load for all components during Data Upload can be neglected as only a small amount of
data is processed
In case of performance problems the traces on the CRM server have to be switched on before starting
the ConnTrans.exe. Unfortunately every service of the flow on the CRM server could be processed by
a different user. Therefore you must run the trace with user “*” and distinguish between the trace
records belonging to the BDOC processing and the trace records belonging to other processes. The
best is no other user is logged on to the CRM server.
XML Data Synchronization
The data synchronization between the mobile client and the CRM server in the form of XML messages
is supported from mySAP CRM 4.0 SP04 onwards. XML message synchronization:
• Reduces the message content on the wire significantly compared to RFC structures
• Enables data exchange with a Unicode CRM server which was not possible using the RFC
structures
XML data synchronization is applicable in the following scenarios:
Data Exchange with a Unicode CRM +Server
If the CRM server is Unicode enabled, then the data exchange between the mobile client and the
CRM server is performed in the form of XML messages only.
Data Exchange with a NonUnicode CRM Server
If the CRM server is not Unicode enabled, then, by default, the data exchange between the mobile
client and the CRM server is performed through RFC structures. However, you can enable the data
exchange to be performed in the form of XML messages for a particular site. To do this:
1. In the Administration Console, under Site Attributes, select the Send XML Messages option.
2. Using Client Console, assign the mobile client to the XML enabled site
Data Exchange with an XML Enabled Workgroup Server site
© 2005 SAP AG 48
If the workgroup server site is XML enabled, then you need to enable all the workgroup clients to send
XML messages. To do this, set the value of the UNICODE_ENABLED registry key under
HKEY_LOCAL_MACHINE\SOFTWARE\SAP\MSA\MW\TL to 1. The UNICODE_ENABLED registry
key is not available by default. You need to manually create the same as a string value on each
workgroup client.
The SAP Note 690577 is a mandatory note to be applied for exchange of data between a mobile
client and Unicode CRM Server, for CRM 4.0 SP04.
Limitation
The existing mobile clients that synchronize data by using RFC structures cannot switch to XML
messages for data synchronization.
investigation. Please use component CRMMTFWTL for problems on a mobile client and CRMMW
COM for problems in data transfer.
5.1.1.10 Business Process Step 11, 13 or 17: Create Inquiry, Create
Quotation, Create Sales Order
5.1.1.10.1 This is an automated step on the CRM server that is preceded by the upload of an inquiry
from a mobile client. A BDOc has been forwarded to specific inbound client queue in the
CRM system and is processed now from the inbound queue. Afterwards the CRM
database is updated.
Apart from safeguarding the general availability of the system and software component SAP CRM
System SAP recommends to monitor the objects listed in the following table in order to ensure that the
business step Create Inquiry can be performed.
Note that this step runs automatically and therefore no classical stepwise monitoring is available. If
this step fails you may detect this first when monitoring the middleware or also if a sales
representative that waits on a sales document status calls in vain.
Data Crmd_or Upon Verify that changes have been Application
consistency der error made in CRM server monitoring team
From here you can also go to the
application log that logs application
errors.
BDoc SMW01( Upon Analysing Bdoc messages and Application
SMW02 error perform required actions, e.g. BDoc monitoring team
and messages with status beginning
SMW03) with E (red traffic light) need manual
on CRM correction and retry, see also BDoc
Server Monitoring and Handling.
Performance SolMan, Weekly To be set Long runtime Monitoring on function code Application
CCMS and level can be set up in monitoring
upon SolMan using function code team
error NEWT_POP
10MAIN_CREATE (Program
SAPLCRM_10_MANAG_UI).
monitoring
Update SolMan, Daily or # of errors Update error Analyze reasons for update Application
CCMS, related to monitoring
© 2005 SAP AG 49

errors (SM13) hourly < 1 transaction errors team
crmd_order
Application SolMan, Daily or # of errors Errors, Analyze reasons for errors Application
log entries (SLG1) hourly < 1 warnings and warnings monitoring
team
investigation. Please use component CRMBTXSLOQUT.
5.1.1.11 Business Process Step 13: Create Quotation
This is an automated step on the CRM server that is preceded by the upload of a quotation from a
mobile client. A BDOc has been forwarded to specific inbound client queue in the CRM system and is
processed now from the inbound queue. Afterwards crm database and cdb are updated.
this step fails you may detect this first when monitoring the middleware or also if a sales representative
that waits on a sales document status calls in vain.
business step Create Quotation can be performed.
Crmd_or Upon Verify that changes have been Application
der error made in CRM server monitoring team
errors.
Performance Transacti Weekly Long See chapter performance Application
on STAD and upon runtime monitoring monitoring team
/ error
Transacti
on ST05
on CRM
server
and R/3
System
investigation. Please use component CRMBTXSLOQUT.
5.1.1.12 Business Process Step 17: Create Sales Order
This is an automated step on the CRM server that is preceded by the upload of an inquiry from a
mobile client. A BDOc has been forwarded to specific inbound client queue in the CRM system and is
© 2005 SAP AG 50
processed now from the inbound queue. Afterwards CRM database and CDB are updated. The sales
order is then forwarded to backend system via CRM outbound queue.
In CRM the sales order is send to the R/3 system via request. In parallel the sales order is replicated
to the mobile clients (order in status “to be distributed”). Later the CRM gets a confirmation of the R/3
system and the status of the sales order is changed to “successfully distributed” . This status change
is replicated to the mobile client.
business step Create Sales Order can be performed.
Crmd_or Upon Verify that changes have been Application
der error made in CRM server monitoring team
errors.
Performance Transacti Weekly Long See chapter performance Application
on STAD and upon runtime monitoring monitoring team
/ error
Transacti
on ST05
on CRM
server
and R/3
System
investigation. Please use component CRMBTXSLO.
5.1.1.13 Business Process Step 20: Create Sales Document (R/3)
This is a step that takes place on the R/3 System that is connected as backend server in this scenario.
To trigger further processing of the business transactions created in the CRM Online system, the sales
documents are transferred to the R/3 system via CRM Middleware. Here, three logistic processes to
finish the order processing can occur: shipping, billing and transfer to accounting. The data to process
is received from the CRM Server via the R/3 inbound queue. In 4.0 the site concept is used. In this
example the backend site is one site for the R/3 backend system. All publications for replication to R/3
system are bulk delivered by SAP. Only the subscribed business objects can be uploaded to the
backend system.
To create the sales order it is booked in over a BAPI (like creating a sales order in R/3).
The backend system then performs the rest of the sales document management cycle depending on
the settings of the order management system. The document can be accessed for further processing
by an authorized sales clerk to view or change the document, to check the document flow and to
create follow up documents (e.g. delivery, billing document).
The available exchange scenarios for Sales Documents are described in the SAP Note 705200. If you
use a CRM server release 4.0 or higher with an R/3 system release 4.70 or higher, data exchange
© 2005 SAP AG 51
scenario A is available (see SAP Note 642944). As of CRM Release 4.0 Support Package 04, you
have the option to create sales orders both in the CRM Server and in the R/3 System and to change
them. You can make the changes independently of the system in which the order was originally
created. This way you can change sales orders at any time on the CRM mobile client as well. The
sales document update scenario between CRMServer and R/3 can be activated by making the
appropriate table entries in table CRMC_SCENARIOid_change_active (on CRM Server side) and
CRMPAROLTP (on R/3side). If this scenario is active the 2nd digit of field CRMD_ORDERADM_H
scenario will always be defaulted with ‘A’ (no matter if the order is created/updated in CRM or R/3).
You can only use interdependent changes in sales orders and quotations if you are using SAP CRM
4.0 SP04 and SAP R/3 4.7 from plug in 2003.1 onwards. If you are using SAP CRM 4.0 with SP01, 02
or 03 and SAP R/3 4.7, you can use update scenarios. If you are using different release combinations,
you can only use the functions available for data exchange up to that point. You can get information
about this in the SAP Help Portal under SAP CrossIndustry Solutions ® SAP Customer Relationship
Management and the required Release as well as in SAP Note 541113.
Please also see Business Process Step: Create sales order (R/3) in section CRM Online.
Apart from the general availability of the system and software components SAP CRM System and R/3 System
SAP recommends to monitor the objects listed in the following table in order to ensure that the business step
Create Sales Document (R/3) can be performed.
Monitor ing Monitor Monitor Indicator or Monitor ing Acitivity or Respon
Object TA/Tool Frequ. Er r or Er r or Handling Pr ocedur e sibility
VA06 If error has been Verify that the document has Application
detected on CRM been posted to the R/3 monitoring
Server team
SE16 If error has been Verify that changes have been Application
detected during posted to the R/3 server monitoring
MW team
monitoring/reported
Performance Transaction Weekly and upon Long See chapter performance Application
STAD/ error runtime monitoring monitoring
Transaction team
ST05 on CRM
server and R/3
System
Procedure
error
Update SolMan, Daily or # of errors Update error Analyze reasons for Application
errors CCMS, hourly < 1 related to update errors monitoring team
(SM13) transaction
crmd_order
Application SolMan, Daily or # of errors Errors, Analyze reasons for Application
log entries (SLG1) hourly < 1 warnings errors and warnings monitoring team
Warnings related to the transferred document can also be viewed on the CRM Server, e.g. in case of
incompleteness. Use transaction R3AC6 and enter the following settings:
· Key: R3A_SALES
· Parameter name: COLLECT_WARNINGS
· Parameter value: X
© 2005 SAP AG 52
Tip: When tracing on the R/3 system please note the following: On the CRM server use transaction
SM59. Choose R/3 connections. Find out the destination to backend system (<SID>CLNT<productive
client>). Doubleclick the destination and you find the RFC user. Trace this user for the duration of the
sales transaction.
investigation. If the problem is within R/3, please use component SD SLSSO.
5.1.1.14 Business Process Step 21: Save Sales Document to CDB
This is an automated step that takes place on the CRM server. The CDB (consolidated database) is
the logical overall database of a Mobile Sales/Service system. It is located on the CRM server and
contains all the data that is supposed to be distributed. It is a subset of the database on the CRM
server.
Before the replication the CDB is updated (for example with the sales document number). In case of a
realignment the sales document BDoc is first replicated to the original recipients and then the
realignment is done asynchronously. This means a delete BDoc is send to the mobile clients that
should not get the data anymore and a sales document BDoc is send to the mobile client which get the
information now.
The CDB has the following performance advantages:
· Fast realignment of data
· Fast recovery of a mobile client database
All the data that has been uploaded from the mobile client regarding the sales document (either
opportunity or sales order) is stored to the CDB.
Data flow: CRM Online fills a messaging BDoc with the validated data. This messaging BDoc is
mapped into synchronization BDoc (here some CRM Mobile only fields are added) that gets then
persisted into CDB.
You should activate the mobile bridge for sales documents when setting up Mobile Sales. The path
where the Mobile bridge entries can be maintained is Transaction 'SPRO' Customer Relationship
Management>CRM Middleware and Related Components >Mobile Scenario Setup>Activate
Mapping functions. For detailed information refer to the SAP Note 632700 and 629861.
Apart from safeguarding the general availability of the system and software component SAP CRM System SAP
recommends to monitor the objects listed in the following table in order to ensure that the business step Save
Sales Document to CDB can be performed.
Note that this step runs automatically and therefore no classical stepwise monitoring is available. If this step fails
you may detect this first when monitoring the middleware or also if a sales representative that waits on
a sales document status calls in vain.
SMOVBAK SE16 Upon Verify that changes have been Application monitoring
error written to the CDB tables team
BDoc SMW01( Upon Analysing Bdoc messages and Application monitoring
SMW02 error perform required actions, e.g. BDoc team
Performance SolMan, Weekly To be set Long runtime Monitoring on program level Application
CCMS and can be set up in SolMan monitoring
upon using Program team
error SALESDOCGEN_O_W_CDB.
monitoring
© 2005 SAP AG 53
5.1.1.14.3
investigation. Please use component CRMMSAADPSAD
5.1.1.15 Business Process Step 22, 23: Replicate to Mobile Clients
The replication and realignment service distributes the BDoc (as confirmation) to the laptops which
have subscribed this data. Subscription determines the distribution of data to sites based on
previously defined publications. The assignment of a subscription to one or more mobile sites triggers
the actual replication of data to the sites. Data is extracted from the CDB after the subscription has
been assigned. The Mobile Client subsequently receives the change information.
List of Publications recommended for working with Sales Documents:
Sales Documents by Business Partner – Intelligent
Sales Documents by Business Partner and Sales Area – Intelligent
Business Transaction Customizing download – Bulk
Customer Hierarchy – Bulk
Customizing objects – Bulk
Customizing objects II – Bulk
Customizing objects III – Bulk
Customizing objects (Mobile Sales Specific) – Bulk
Employee Bulk – Bulk
User by Employee – Intelligent
Authorizations – Bulk
Authorsations2 – Bulk
Service Customizing – Bulk
Customizing ATP
business step Replicate to Mobile Clients can be performed.
Monitor ing Monitor Monitor Indicator or Monitor ing Acitivity or Respon
Object TA/Tool Frequ. Er r or Er r or Handling Pr ocedur e sibility
Queue demon SMOHQUEUE Upon error No data is Check if the queue demon is System
replicated running. If the queue demon is not administrator
running, no data is extracted, the
outbound queue remains empty
and no data is replicated.
Replication SMOEAC Upon error No data is Check if object that should be Application
objects replicated downloaded to the mobile client monitoring
has a proper subscription. team
Monitoring Monitor Monitor Threshold Indicator Monitoring Activity or Responsibility
Queues SolMan, Hourly # of Check in transaction smq1, System
CCMS blocked smq2, smohqueue for the queues Administrator,
queues < with errors Application
1, # of monitoring
entries /
queue <
team
© 2005 SAP AG 54
Monitoring Monitor Monitor Threshold Indicator Monitoring Activity or Responsibility

40 000
Performance SolMan, Weekly To be set Long Monitoring on program level can Application
CCMS and runtime be set up in SolMan using monitoring
upon Program team
error CGCAPGEN_OBJ_WRITE_RRR.
For background information see
chapter performance monitoring
5.1.1.15.3
investigation. Please use component CRMMWCOM.
5.1.1.16 Business Process Step 23: Perform Download (ConnTrans)
This is a step that is initiated on the mobile client. In Principle the process of the data download is the
same as for data upload. Now data is transferred from the Middleware’s Outbound Queue (CRM
Server, check transaction smq1) via the communication station and is sent to the inbound Queue of
the Mobile Client.
The amount of data usually is much higher then on upload. As for data upload, for Data Download the
critical factor is the connection speed.
The downloaded data is now stored in table MW_Qin on the mobile client and will now be processed
(data will be transferred to the appropriate tables). For this process the main factor is the overall
system performance especially the performance of the database. The performance of the database is
additionally dependent on the database configuration and the fragmentation of the database on your
local disk. Please note, that also here different Bdocs have different processing times.
Apart from safeguarding the general availability of the system and software components SAP CRM
System and mobile clients SAP recommends to monitor the objects listed in the following table in
order to ensure that the business step Perform Download (connTrans) can be performed.
Monitor ing Monitor Monitor Indicator or Monitor ing Acitivity or Responsibility
Object TA/Tool Frequ. Er r or Er r or Handling Pr ocedur e
Inbound Client Console Each time Monitor the inbound Sales
queue and ConnTrans queue on the mobile representative/end
logfile on is used client. user
mobile client View the logfile in the in
client console and double
click on messages for
solution suggestions.
Errors, TransferService.log Upon error Check logfile for detailed Application
warnings file on information on error monitoring team
communication
station
Errors, TransferService.log Upon error Check logfile for detailed Application
warnings file on mobile client information on error monitoring team
Performance MS Windows NT On demand Lon runtime Check operating system System
Performance load administrator
Monitor on mobile
client and
communication
station
Outbound SMQ1 on CRM On demand Monitoring outbound System
Queue Server queue on CRM Server administrator
If the queue was stopped
because of capacity
overload, use F6 to restart
the queue
© 2005 SAP AG 55
Monitor ing Monitor Monitor Indicator or Monitor ing Acitivity or Responsibility

Object TA/Tool Frequ. Er r or Er r or Handling Pr ocedur e
If a second start of the
queue is not successful,
call the short dump
analysis in the CRM
system
BDoc SMW01(SMW02 Upon error Analysing Bdoc messages Application
and SMW03) on and perform required monitoring team
CRM Server actions, e.g. BDoc
messages with status
beginning with E (red
traffic light) need manual
correction and retry, see
also BDoc Monitoring and
Handling.
TRFC SM58 on CRM Upon error Monitor all transactional Application
Monitoring Server (R&R) RFCs (tRFCs) processed monitoring team
on the CRM Server
ConnTrans SMWMCOMM on Upon error Monitor ConnTrans Application
Performance CRM Server performance and data monitoring team
exchange
Connection DCOM Connector Upon error Monitor connection System
Monitor on CRM components administrator
Server
Message flow SMWMFLOW on Upon error Use this as a starting point Application
statistics CRM server for analyzing performance monitoring team
problems
Flow SMO8FD on CRM Upon error Check consistency of Application
Definitions server Flow definitions monitoring team
Replication SMOHQUEUE on Upon error Display information about Application
queues CRM server (R&R) the status and content of monitoring team
the replication and
realignment queues in the
clients defined in the CRM
Server
Performance SQL Profiler and In case of Long SQL Trace of transaction Application
Trace, SQL/Query performance runtime and query analysis monitoring team
Analyzer problems or system
administrator
Performance Transaction STAD/ Weekly and Long See chapter performance Application
Transaction ST05 upon error runtime monitoring monitoring team
on CRM server and
R/3 System
Please refer to the Step 8 ‘Perform Upload’.
investigation. Please use component CRMMTFWTL.
5.2 Further Information

5.2.1 Integration of BW and CRM Field Sales
Please also see Connection to SAP Business Warehouse (BW).
5.2.1.1 From BW to CRM
Query data can be loaded into the CRM system once the required settings have been made and the
request job "SMOBWREQ" (choose the "Request" pushbutton (F8) in transaction smobilebw) has
been scheduled to be run regularly.
© 2005 SAP AG 56
It is possible to examine the entire processing log by choosing the "Display Log" pushbutton
(SHIFT+F4) within transaction smobilebw. By doubleclicking the messages assigned to specific
requests, you directly access the appropriate request screen, where you can immediately set about
resolving the problem.
· Manual Requests: It is possible to start individual requests manually. This is useful if an error
occurred that was removed in the meantime. To do this, you choose the "Request"
pushbuttons (F8) in the "Workbooks Request", "Query Request", and "Users" screens. These
pushbuttons request the corresponding data independently of the report "SMOBWREQ". A
confirmation message tells you whether the request was successful or not.
· Flow Monitor: You can start the Middleware Flow Monitor by choosing the "Flow Monitor"
pushbutton (SHIFT+F1) or by doubleclicking in the "Users" screen. In this way, you can check
whether the flow has correctly processed the corresponding BDocs. This is essential before
the data is transferred to the tables of the CRM system. The Flow Monitor view in the detail
screens relates to the respective request. In addition, you can examine all
REP_BOREPMA_WRTE BDocs from the menu.
· Queue Monitor: You can access the monitor for the Middleware Replication & Realignment
Queue from the menu.
· Display Query Data: In the "Workbooks Request" screen, you can access the data available in
CRM for this workbook by choosing the "Display Query Data" pushbutton (SHIFT+F2). By
doubleclicking, you can check the data in greater detail. Note that workbooks are binary files
for which the detail view does not provide very detailed insights, but plausibility checks can
easily be run on query data. The "Display Data Records" pushbutton (SHIFT+CTRL+F2) calls
up transaction SE16, which you can also use to display the relevant data records.
5.2.1.2 From CRM to the Mobile Client
After the query data has been loaded from BW into CRM, it then needs to be distributed to the mobile
clients (the component "BW Report Tools" is located in the system administrator application).
Checking the Client Log in CRM: The assembly process is documented in a log file. This log
information is found in the file c:\bwmsa.log. You have the option of using the transaction
SMOBILEBW to determine whether this file is to be initialized and whether the system administrator
can call it up in the CRM system for analysis purposes. By doubleclicking in the "User Links" screen,
you call up a view of a copy of this file. The original file version remains on the laptop in question but is
replicated if required in CRM.
This view is blank at first because no data is transferred from the client. You need to choose the
pushbuttons "Transfer Log" (SHIFT+F1) to start the process. This generates special BDocs that are
replicated to the client with appropriate subscription and trigger the respective processes in the client.
For this a subscription for BW query reports with REPKIND = "Q", BWUSER = <BWusername> and
BWGROUP = "C:\BWMSA.LOG" needs to be created for the client concerned. Moreover an identical
subscription must not exist for any other client to prevent the log data from being overwritten.
Depending on the action triggered (see the status display in the top row of the log), the log data on the
client is now either sent to the CRM system or deleted before the assembly (in which case only the
last assembly process is visible).
Note that this transfer can have a negative effect on the overall performance of the client system. For
this reason, you should only activate this option to examine problems as they occur and then
deactivate it again afterwards.
5.2.2 Background Information and References for the Field
Sales Scenario
5.2.2.1.1 Consolidated Database (CDB)
The CRM database is the common database for all CRM applications. It contains the CDB, a separate
consolidated database for the Mobile Client applications. The CDB is a logical part of the entire CRM
database. The CDB contains the data that needs to be transported to and from the Mobile Client, i.e.
data relevant to replication (CDB tables) for mobile scenarios.
© 2005 SAP AG 57
For the sales representatives in the field the CDB is divided into partial datasets in order to allow them
to work independently. They do not work online on the overall database, but rather on the sites (their
laptops) with local, geographically distributed datasets.
The partial datasets of the CDB must correspond to the requirements of the employees in the field
force. This means that each remote employee is given access only to the data for which he or she is
responsible. The employee then manages "his/her" data (be it customers, contact persons, orders or
appointments) on a local database.
Generally speaking, there will be a degree of overlap between the various partial datasets into which
the overall database is divided. The phrase "replicated data storage" implies that there may be several
different employees who are all responsible for managing a given item of data and who could make
changes to it.
5.2.2.1.2 ConnTrans
The ConnTrans is the connection handling interface between the client computer (site, laptop) and the
CRM Server (via the Communication Station). It is the main task of the synchronization process.
Whenever data is to be sent from a mobile client to the CRM Server, ConnTrans is used. It starts
the Message Transfer Service Client which in turn takes the BDocs from the outbound queue of the
mobile client and sends it to the Message Transfer Service Server that is located on the
communication station.
ConnTrans receives and sends the changes that have been made since the last synchronization.
Changes are not sent step by step but in a package of Remote Function Calls (RFC), which are
processed when the whole package has been received/sent.
The ConnTrans does not connect directly to the mySAP CRM system but through the Communication
Station, especially the DCOM Connector. ConnTrans and DCOM Connector communicate by using
Microsoft’s Distributed Component Object Model (DCOM). The DCOM Connector uses RFC to
connect to the CRM System.
The connection setup is carried out via DialUp Networking (Remote Access Service).
After installation of the mobile client the ConnTrans.exe is stored under ...\SAP\Mobile\bin\.
5.2.2.1.3 Queued Message Transfer Configuration Tool (QmtCnfg)
The QmtCnfg plays a role in data transfer from the CRM mobile client via the Communication station
to the CRM Server. Various protocols are used here, namely DCOM from the mobile client to the
Communication Station and RFC from the Communication Station to the CRM Server (after the
DCOM protocol has been converted into the RFC protocol in the SAP DCOM Component Connector).
The QmtCnfg consists of a client component and a server component, with the server component
being located on the Communication Station. QmtCnfg can thus be used on the mobile client as well
as on the communication station.
This is a tool that displays:
· Parameters for managing the components of the Queued Message Transfer (QMT). Only
QmtCnfg can change these parameters.
· Relevant configuration parameters of the Windows operating system for the DCOM transport
layer.
You have to configure these parameters using Windows tools. QmtCnfg however, provides
direct access to these tools.
© 2005 SAP AG 58
· Parameters of the DCOM Component Connector on the Communication Station. You have to
configure these parameters using tools of the SAP DCOM Component Connector. QmtCnfg
however, provides direct access to these tools.
QmtCnfg has two main tasks:
· It displays all the relevant Windows and SAPspecific configuration parameters that affect data
exchange between the CRM Mobile Client and the CRM Server, including the version of the
relevant QMT components.
· It tests the connection to the Communication Station and to the CRM Server.
In addition, QmtCnfg enables you to create a log file documenting the configuration that has been
found. In this way you can compare different computer configurations for example, or in the case of an
error message information on the configuration can be included.
To create a file like this, choose the option Write Log File in the Select menu. A window containing the
message: Log file ‚<TEMP>\QmtCnfgLog.txt’ written. appears. In addition, the program flow is logged
in a text output window, whose current content you can clear using the button Clear Text.
5.2.2.1.4 DCOM Connector
The SAP DCOM (Distributed Component Object Model) Connector controls the access of the sales
employees via their front ends (laptop, workstation PC) to the CRM Server. It acts like a proxy server
between the ConnTrans process and the CRM system. On the client side it talks DCOM and on the
server side RFC, i.e. it converts the Mobile Clients’ DCOM calls into qRFC calls to the CRM
Middleware. The connectors’ runtime environment offers a general interface to call the remote function
modules used in this context.
The DCOM Connector can be installed stand alone or in the MTS. In the mySAP CRM Mobile Client
scenario it is always installed in the MTS.
5.2.2.1.5 Message transfer Service (MTS)
The Message transfer Service provides a rich set of integrated services providing support for
scalability, security and transactions. MTS is based on COM (Component Object Model) and uses
DCOM for componenttocomponent communications across a network.
As client on the mobile client and server on the communication station the MTS serves as a
transaction processor over distributed systems. It efficiently supports connection pooling and
increases network security by providing an authentication system. Another main reason to run the
MTS is better performance (connection pooling).
5.2.2.1.6 Admin(istration) Console
The Admin Console is located on the CRM Server (transaction SMOEAC) and uses its data and
function modules. It is a central tool used for the administration of mobile sites and users, as well as
for administration and customizing of data distribution to the mobile clients (replication, publications..).
5.2.2.1.7 BDoc Modeler
BDoc Modeler (BDocM) is a tool for modeling business document (BDocs) types. A BDoc is a set of
data related to a business operation in the Transaction Repository. The Transaction Repository is a
data storage device that holds the entire user related BDoc information. It helps to define atomic
BDocs.
BDocM is used to maintain Bdocs, to define BDocs and to configure the application database
depending on the Transaction Repository
On the CRM server the Bdoc Modeler is an integral part that is available as transaction (SBDM). On
the mobile clients the BDocM is be located at …\SAP\Mobile\bin\.
© 2005 SAP AG 59
5.2.2.1.8 ASCII Adapter
The ASCII (American Standard Code for Information Interchange) Adapter is the interface between
the CRM Middleware and external systems that cannot supply any BDocs (business documents) to
the CRM Middleware. Instead, these external systems can supply the CRM Middleware with ASCII
files, which are converted into database tables by using the ASCII Adapter. Similarly, information from
the CRM Server can be supplied in text files to the external systems.
5.2.2.1.9 Sales Configuration Engine (SCE)
The SCE lets you configure downloaded R/3 master data on a PC or laptop, either with or without a
connection to an R/3 System. To use the SCE a locally installed relational database is needed as well
as a framework for the SCE to work in.
The framework for the SCE can be, for example the Internet Pricing and Configurator, SAP Customer
Relationship Management (CRM), SAP Field Sales, or a custom thirdparty environment.
The SCE uses R/3 master data converted to an SCE knowledge base. Master data cannot be
maintained in the SCE.
The SCE is written entirely in JAVA and runs on any Web browser. It is compatible with R/3 releases
3.1H, 3.1I, 4.0B, 4.5, and 4.6.
The user interface layer is completely separate from the configurator itself. This allows to integrate the
SCE with a wide range of other applications.
In the field sales scenario the SAP Internet Pricing and Configurator (SAP IPC) is included in the
standard mySAP CRM Mobile Sales installation with a standard Java interface. The mySAP CRM
Mobile Sales middleware downloads all the R/3 data that the SAP IPC requires to configure and price
products.
The field sales force uses CRM Mobile, installed on laptops, to manage the whole range of activities,
from planning of customer site visits to order entry. Some of the products that are market in this way
may be configurable. Salespeople can visit customers to discuss their requirements, with a view to
presenting them with one or more quotations for different combinations of product options (variants).
5.2.2.1.10 Sales Pricing Engine (SPE)
The Sales Pricing Engine (SPE) enables field sales representatives to calculate prices at the pointof
sale for those offers and orders created in the mobile system. The system uses the company’s price
elements, such as discounts and surcharges, etc. These are downloaded with the master data from
the system that is normally used for pricing. This enables a rapid direct access to pricing information.
Pricing results can also be printed out immediately in the order. The pricing results can be transferred
into the central system, where they can be used for further order processing.
The SPE is based on the following SAP R/3 system concepts and functions:
· Condition technique
· Currency conversion, including Euro conversion
· Conversion of units of measurement and measure
The SPE is integrated according to the standard in the Field Sales Application. Data exchange with
the SCE enables pricing for configurable products.
To be able to calculate prices in the mobile system, you must have created a pricing procedure in the
central system in Customizing for Sales and Distribution. The SPE offers the most important pricing
functions from the SAP R/3 System. Depending on the release status of the R/3 standard system that
you wish to download the master data from, you may not be able to use the full scope of functions.
Some of the condition types from the R/3 Standard System cannot be used. For example, you cannot
© 2005 SAP AG 60
maintain Customizing settings in the SPE and you cannot create or change pricerelevant master data
such as condition records and agreements. This happens exclusively in your main system.
5.2.2.1.11 Client Console
The ClientConsole is located on the Mobile Client. The initial step for connecting the Clients to the
CRM Server (via CommStation) is carried out here. During this process (assign SiteID) the Middleware
Outbound Queue for this Mobile Client is registered on the client itself.
It is also used for the administration of the CRM Mobile Client. It also undertakes the role of monitoring
and troubleshooting the mobile client.
It offers one window to client health monitoring tools. Contains different tools for communication
administration available under one roof. The tools are divided into two groups:
· Client Administration, i.e. to set up and test the data exchange with the Middleware layer on
the CRM Server
· Data Transfer, i.e. to monitor and view the data transfer and the transaction layer environment
on the client.
Within the Client Administration the following functions are available:
· Metadata generator: generates metadata (stored procedures and views) and cache file for
transaction layer runtime.
· Metadata Viewer (to view the Metadata)
· Check Metadata (to test the consistency of the Metadata)
· Assign SiteID: makes appropriate settings on the client as well as the server so that a laptop is
identified as a valid client.
· Test Adapter Connection (The connection to the commstation can be checked here)
· Table Script Generator (Table changes in the CRM Middleware can be transferred
· BDOC Upgrade Scripter (To create or transfer BDoc changes to the Mobile client)
Data Transfer folder includes the Queue Processor and the Queue Monitor, whereas the former
functionality of the Queue Processor has been shifted completely to the Queue Monitor.
The Queue Monitor can be used to:
· View the presence of messages in the client’s inbound and outbound queues
· Test the readability of queues by transaction layer
· View contents of top messages in the inbound queue, if readable
It is used to list the number of BDoc messages that are not processed in the inbound as well as the
outbound queue. Whenever data is saved in the CRM Mobile application, messages are generated
and they reach the outbound queue of the client. These messages have to be sent to the CRM Server.
Messages in the inbound queue are those that are received from the CRM Server and are waiting to
be processed and written into the local database of the mobile client.
5.2.2.1.12 Backweb
SAP BackWeb is an optional thirdparty software component in the field sales scenario.
BackWeb is intended to provide sales representatives with a means of gaining timely access to
marketing and sales materials or Internetbased information. It is a system that enables businesses to
gather, target and deliver large amounts of data in any format (e.g. audio, video, software files, HTML)
to user desktops across their extended enterprise. BackWeb accomplishes this through the use of
information channels.
This function consists of two components: a BackWeb server and a BackWeb client component. This
client is seemlessly integrated with the info center component of the Mobile Sales Application, which
means that it is part of the
5.3 Scenario specific Monitoring

Tip: The names of the Site ID‘s on the Mobile Client (Client Console) and in the CRM (SMQ1, SMQ2)
are different. In table SMOHQTAB (use transaction SE16 à Table contents) the names are mapped
together.
© 2005 SAP AG 61
5.3.1 Basic Monitoring Guidelines for the CRM Server
Apart from the general monitoring activities on a CRM Server that is described in the Appendix we
recommended the following actions when running CRM Field Sales.
Mobile Bridge settings:
For all BDoc types that you are planning to use in the FS scenario you have to enable the Mobile
Bridge: Set field ACTIVE to ‘X’ in table SMW3FDCUST according SAP Note 430392.
Monitoring Activities / Functions Monitoring Type Monitoring Frequency
Periods and Events
Queue Information for CRM Client Sites SMWMQUEUES Only for error tracking in
· Display all mobile sites defined in the CRM seldom cases
Server together with the name of the
queue assigned to each of these sites
Replication Queues Monitor SMOHQUEUE · Several times a day

· Displays information about the status and depending on the
contents of the replication and realignment business process
queues in the clients defined in the CRM · Daily
Server
· The EXTRACT queue shows to which
clients a specific BDoc type will be
distributed
· To check the status of the queues
· Deselect the flag: Display current client
only
· Press the Refresh button
· Search for queues with
· Status = Hold
· number of entries > 0 and a
· flash icon button in the rightmost column
· Correct the error situation for the indicated
queues (error handling in SM58)
Note: Do not press the trash icon button if it
appears next to an entry.
Communication monitor SMWMCOMM · Daily
· Communication monitor: monitoring Middleware à · In case of performance
individual sessions, statistics of the data Monitoring à Mobile problems
exchange for each site Client à
Communication
Monitor
Mobile Client Message Recovery CMWQ · Daily
Unprocessed message recovery: Monitoring > Mobile
reporting messages informing the CRM Server Client > Message
about errors during the import on the mobile Recovery
clients
Operating System / Gateway OS07 · Daily
The SAP system statistic collector daemons,
· In case of performance
SAPOSCOL and RFCOSCOL, run on the
problems
Communication Station and gather hardware
resource consumption data. Complementary
programs run on the CRM Server and collect
and display statistical data.
While the Communication Station is running,
data is continually being collected via existing
connections, and system data is also collected
for subsequent evaluation. This data is called
up periodically by the CRM Server and can be
displayed and analyzed there using monitoring
tools. The gateway, which is installed on the
Communication Station, is used to call up the
collected data.
Windows performance monitor.
© 2005 SAP AG 62
5.3.1.1 Scheduling Batch Jobs
5.3.1.1.1 Middleware Trace Reorganization
For tracing, you can use various standard settings or your own settings; see above in section settings
in table SMOFPARSFA. Depending on the selected trace level, the system writes entries into trace
tables. Such entries must be deleted in regular intervals to prevent these tables from becoming too
large. Some possibilities to handle this would be to keep trace information (especially errors) in the log
for e.g. 1 day, or 1 week and to delete the data afterwards. You have to schedule reorganization jobs,
called SMO6_REORG (SAP Note 206439) and MW_REORG (SAP Note 487915)
5.3.1.1.2 Middleware Portal
To be able to use the centralized status monitoring for the generation steps, you must call up the
Middleware Portal (transaction SMWP) and activate the background job for status processing by
clicking on Scheduled Background Job.
Note that status monitoring will be available only during the next day.
5.3.1.1.3 BDoc Flow Statistics Activation
Ensure that the middleware kernel application statistics are switched on. Call transaction
SMWMFLOW. Execute Goto > Activate Statistics. Select “message flow statistics”. Activate
monitoring of the middleware message flow.
To activate the application statistics, select “Kernel application statistics”, select the change mode,
mark the field “MW” (Middleware Message Hub Statistics). Save.
5.3.1.1.4 Communication Monitor Collector Activation
For activating transaction SMWMCOMM, the Conntrans Performance monitoring, you have to choose
“Environment”> “Run Collector
5.3.2 Basic Monitoring Guidelines for the Communication
Station
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.
Monitoring Activities / Functions Monitoring Type Monitoring Frequency
Periods and Events
DCOM Connector component monitor Start à · In case of errors and
Programs à problems
Middleware à DCOM
Connector. Start the
application and choose
Monitor.
Communication Log File: · This file should be
TransferService.Log monitored daily.
Txt oder hyper
The SAP CRM Queued Transfer Service
component logs the communication sessions
between the mobile clients and the CRM
Server in the TransferService.log file. The
default file path is as follows:
C:\WINNT\TransferService.log.
Windows NT Performance Monitor / WIN · In case of performance
2000 Perfmonitor problems
5.3.3 Basic Monitoring Guidelines for the Mobile Clients
When a traveling sales person has data to up or download from his laptop, he must establish a
connection to the CRM Server via the Communication Station. This may be done at the customer site
using a telephone line. The Communication Station maintains a connection to the CRM Server that in
turn maintains a connection to the R/3 backend system (LAN configuration).
© 2005 SAP AG 63
The CONTRANS.EXE program is executed on the mobile client to establish the connection. Data from
the outbound queue of the mobile client is transferred through the Communication Station to the CRM
Server. This data can be customer orders and/or customer data, such as newly created customers on
the mobile client.
For monitoring the mobile clients, you have to consider four different areas:
· The operating system
· The local IDES database
· Trace files
· Data transfer log file
Mobile Client Monitoring Activities / Functions Monitoring Type Monitoring Frequency

Periods and Events
Queued Transfer Service QmtCnfg.exe · In case of an error
The QmtCnfg program displays the connection TransferService.log message in the data
status between the mobile client and the transfer phase
Communication Station.
Client Console, metadata check, generation, · In case of an error
comparison of BDoc structures message in the import
Data bound from the CRM outbound queue to a phase
specific mobile client is copied to the inbound queue
of that mobile client.
Data from the mobile client outbound queue is
transferred to the inbound queue on the CRM
Server.
The inbound and outbound queues of the mobile
client can be displayed using the Client Console.
Operating system Perfmon.exe In case of an error

Windows NT Performance Monitor message
Database SAP Note 358507
You can monitor the SQLServer database on the SAP Note 433401
Mobile client with the remote SQLServer Monitor SAP Note 530317
5.3.3.1 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.
ConnTrans covers the following 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.
© 2005 SAP AG 64
To use ConnTrans, on the Mobile Client choose Start > Programs > SAP CRM Mobile Client >
ConnTrans.
Operating System / Gateway
The SAP system statistic collector daemons, SAPOSCOL and RFCOSCOL, run on the
Communication Station and gather hardware resource consumption data. Complementary programs
run on the CRM Server and collect and display statistical data.
While the Communication Station is running, data is continually being collected via existing
connections, and system data is also collected for subsequent evaluation. This data is called up
periodically by the CRM Server and can be displayed and analyzed there using monitoring tools. The
gateway, which is installed on the Communication Station, is used to call up the collected data.
Windows performance monitor.
5.3.3.2 TransferService.log file
File logs the communications between the Mobile Client and the Communication Station.
The format of the TransferService.log file on the Mobile Client is not as clearly selfdocumenting as the
log file on the Communication Station. In most cases the client log file should not be analyzed until
after analyzing the Communication Station TransferService.log file. Although both files have the same
name, their formats are very different. For this reason when diagnosing SAPrelated communications
problems on the Mobile Client, first look at the log file from the Communication Station.
The default file path is as follows: <windows temp folder >\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 Communication Station server.
The session header data contains the following information:
· 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
The session performance data contains the following information:
· 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
© 2005 SAP AG 65
· Transmission rate for RFC communication between client and DCOM server
· Access rate in the client database (bytes per second)
Please note that the measured answer times in the transferservice.log does not capture the post
processing time of the BDOC‘s. On the CRM server you can measure the post processing time with
transaction SMWMFLOW.
5.3.3.3 Windows NT Performance Monitor
The Microsoft Windows Performance Monitor (PERFMON) is a performancemonitoring 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 networkbased 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 performancerelevant 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.
Evaluate your analysis.
5.3.4 Housekeeping for Mobile Clients
5.3.4.1 General PC Tuning
The following list contains some general measures to prevent a gradual decrease of your PC’s
performance:
© 2005 SAP AG 66
1. Make sure that there is enough free disk space (i.e. 1 GB).
2. Regularly delete the files in the directories TEMP and TMP.
3. Empty the Recycle Bin.
4. Delete temporary Internet files (in the directory WINNT or WINDOWS or by choosing Internet
Options in the Internet Explorer).
5. Check whether regular jobs are scheduled, such as reindexing. These can be very
performanceintensive and should not run at the same time as CONNTRANS or a mobile
client application.
6. Ensure that you set the pagefile large enough (300MB). Avoid fragmentation by using the
same minimum and maximum values.
7. From time to time, check fragmentation on the hard disk. Windows 98 has an integrated de
fragmentation routine: Choose System _ Tools. Windows NT does not have an integrated
routine.
5.3.4.2 Database reorganization
Over time, inserting, deleting, and changing data leads to fragmentation on the database of the mobile
client, and additional (I/O)load arises. To ensure good performance with the mobile client, the
database must be reorganized from time to time.
A script can be downloaded from sapservx for the purposes of database reorganization
(defragmentation). See SAP Note 417539 for details. Using command file
sap_smo_reorg7_apply.cmd, two stored procedures are created in the IDES database. You should
only execute this command file once per mobile client.
Two command files are available for the reorganization/defragmentation of the database:
1. reorg_initial.cmd
This command reorganizes the whole IDES database. This is worth doing after an initial download,
especially if the “Initial Client Setup” indicator was not set for Conntrans.
2. reorg.cmd
This command only reorganizes the IDES database tables, in which more than 10% of the data has
changed since the last reorganization. You are advised to execute this command regularly (once per
month), at the latest when performance on the mobile client becomes noticeably poorer.
Please note that defragmentation requires as much free space in the database as the largest table to
be defragmented occupies. This space is released again after defragmentation has completed. Before
defragmenting any table, the system checks that enough space is available. If not, the action is
canceled and a message to this effect is issued. We do not recommend to shrink the database on a
regular basis to save disk space. It is also recommended to switch the ‘auto shrink’ function off due to
performance reasons.
5.3.4.3 Database reindexing
If database tables are updated frequently, it is recommended to reindex the whole DB on regular basis
(monthly or every 2 month).
You can schedule a Database Maintenance Plan by means of SQL Enterprise Manager. Expand tree
and choose Management > Database Maintenance Plan>New Maintenance Plan. Select the option
"Reorganize data and index pages". Start 'SQL Server Agent' before running the created job.
5.3.4.4 TL (Transaction Layer) Hotfix
The last version of TL Hotfix should be applied according to note 497748. The note is updated
frequently and customers should always apply the last update. It contains fixes for all known problems
in the BDOC Layer and ConnTrans. Especially check the note when facing problems before opening a
SAPNet message.
5.3.4.5 IPC logs and traces
Refer to the SAP Note 658805.
Pricing Analysis
The "Pricing Analysis"trace shows how the IPC has searched for condition records during the pricing
of a sales document. The trace shows:
Which condition tables where searched by the IPC and which searchcriteria have been used.
© 2005 SAP AG 67
Which requirements/userexits were checked during pricing and the result of the checks?
The "Pricing Analysis"trace is the first place to look, when pricing works technically, but the wrong
price is calculated because for example not all expected condition records have been found by the
IPC.
How to turn on the " Pricing Analysis" trace in Mobile Sales.
Until 4.0 SP03 "Pricing Analysis"trace is activated on sales documentlevel by setting the checkbox
"Pricing Analysis" in the "Details" tileset. Starting with 40SP03 the "Pricing Analysis"trace is activated
on user level, rather than on the sales document level.
To enable the "Pricing Analysis"trace:
Open the Mobile Client Application.
Select the component "Employees".
Click on "Settings".
In the tile "Settings" set the check box "Pricing Analysis".
To View the Pricing Analysis:
In the component "Sales Transactions" create a new sales document and add line items and save.
Go to the tileset "Item Pricing Conditions”. The "Analysis" button should now be enabled.
Click on the "Analysis" button to view the trace of the steps performed by the IPC during the pricing of
the line items.
When the "Pricing Analysis"trace is turned on, the performance of pricing is reduced, because the
IPC has to collect trace information. Always turn off the "Pricing Analysis"trace, when you do not need
it. The "Pricing Analysis"trace should not be turned on during productive use of the application due to
the impact on performance.
What information is contained in the IPC logfile (ipcapplication.?.log) ?
The IPC Logfile lists the following errors and warnings produced by the IPC:
Error and warning messages when customizing data is missing or incomplete.
Warnings when condition master data tables are missing.
The IPC logfile is the first place to look for more information when pricing or configuration does not
work.
How to locate the IPC logfile” ipcapplication.*.log” ?
The logfile is not overwritten when the application is restarted.
By default the IPC writes a logfile called ipcapplication.0.log, until it reaches the size of 1 MB. The
IPC now starts writing into a new logfile called ipcapplication.1.log. When this file has also reached a
size of 1MB, the first logfile ipcapplication.0.log is overwritten.
The number of logfiles, their size and the name of the logfiles can be customized. The procedure is
the same as for the IPC in the CRMOnline scenario. Refer to the IPC documentation.
The default location for the logfile is the path pointed to by the local environment variable TEMP.
Under Windows 2000 and XP this is normally the directory c:\Documents and Settings\<user
name>\Local Settings\Temp
return.
Mobile Salesspecific trace information into the IPC logfile.
The IPC can be configured to produce additional Mobile Sales specific traceinformation. The trace will
then contain the following additional information:
All IPC methods called by Mobile Sales.
For which object the methods was called,
i.e. the sales document or lineitem guid.
The input parameters of the methods.
© 2005 SAP AG 68
The output parameters of the methods.
Duration of the call in Java.
To enable the logging of the additional traceinformation you have to change the properties file
"logging. properties". This file can be found under the below folder
<installation path>\SAP\IPC\lib\properties
In this file uncomment the following lines by removing the preceding "#"
Setting to enable the logging
com.sap.spc.beans.logs = log [Unknown]
com.sap.spc.beans.severity = PATH
Setting to disable logging
#com.sap.spc.beans.logs = log [Unknown]
#com.sap.spc.beans.severity = PATH
IMPORTANT: The writing of the additional traceinformation affects performance! Turn it off when not
needed by commenting the above lines again.
5.3.4.6 Unused functionality
If some functionality is not used, we could turn it OFF to boost the performance slightly.
Open the Mobile System Maintenance application. Navigate to the component 'CrossComponent
Settings', navigate to the tileset 'Choice Fields'.
1. Create Choice field 'SAD_NOITEMPARTNERS' to disable the functionality of item partner creation.
2. Create Choice field 'SAD_NOITEMBUSDATA' to disable the functionality of item business data
creation.
3. Create Choice field 'SAD_NOTAX' to disable the functionality tax determination.
4. BOM explosion can be switched off: In the MSY (Mobile System Maintenance application)
component 'Sales Document Settings' tileset 'Global Sales Document Settings'
deselect the checkbox 'Explosion BillofMaterial'.
5.3.5 Application Troubleshooting on Mobile Client
Always check if the problem is reproducible. Simply execute the respective transactions several times
over and check, if the problem persists.
Then check if the problem is related to the data that is used. Perform the transaction with different
data to make sure that the problem is reproducible and has nothing to do with specific data
constellations.
Also check if the problem does have anything to do with the CPU or the database. Currently there are
no SAP internal tools to perform this analysis. Many problems are database related – it is
recommended to start with the database analysis first using MSSQL Profiler (see below). If the
database analysis does not show any problems at database level, check whether the problem is CPU
related using the task manager. While the transaction is running, simply check which process is most
CPU timeconsuming. If it is an application related process for that you cannot find a solution please
open a SAPNet message for further investigation.
5.3.5.1 Transaction Tracing on Mobile Clients
In case of performance problem it is necessary to analyse a certain step or business process on the
mobile client. Database interaction can be analyzed using a set of tools available in the SQL Server
suite. These are
· SQL Profiler
· SQL Query Analyzer
For the analysis a profiler trace has to be run on the mobile client by the application monitoring team.
For this step the mobile client must not be connected to the CRM server. In general the team looks for
selects with high response times (min. > 500 ms), checks which index has been used and if the index
is selective (density).
© 2005 SAP AG 69
Please note, on some Mobile Clients, customers installed Windows 2000 wherein SQL Server 2000 is
included. With this spare version of SQL Server 2000 (SQL Server 8.0) no Profiler tool is available.
Therefore a trace on the Mobile Client itself is not possible.
5.3.5.2 SQL Profiler and Trace
The SQL Profiler is a tool to monitor events in an instance of the SQL Server. It can be used for the
following:
· Recording SQL Statements/Stored Procedures
· Analyze these statements
· Monitor performance
· Rerun scenarios
These events can be saved onto a file or table for later analysis or reruns.
How to switch on the SQL trace:
1. Choose Program > MS SQL Server7.0 > Profiler
2. Choose "New Trace" (= yellow lightening)
3. Choose GENERAL:
Define a trace name
Set TRACETYP = 'Private‚
in "SQL SERVER" local Server
Choose the path, where the trace should be saved
4. Choose EVENTS:
From the left window add to the right: TSQL, Stored Procedures,
5. Data Columns
From the left window add to the right: Database ID
6. Choose FILTERS and set Minimum Duration to 1
7. After the process is finished switch off the trace and safe the trace file. This trace can also be
reopened at later times for analysis by using FILE > OPEN > TRACE FILE.
Now the SQL statements (select ....) with the longest duration can be analysed using the SQL/Query
Analyser (see below).
5.3.5.3 SQL/Query Analyzer
The SQL or Query Analyzer is a tool to run queries and SQL scripts on SQL database.
It can be used for the following:
· Running queries on the database
· Analyze queries
· Modify tables directly on the database (Various database queries can be analyzed by looking
at)
· Query execution plan
· Estimated execution plan
· Server trace
· Client statistics
The Query Execution plan can be used to analyze the steps taken by SQL Server to execute a query.
The SQL Query Analyzer provides a graphical tool to analyze a query execution plan. A Query
analysis would result in a change of the query (or) table indices that would improve the query
execution.
Choose Start > Programs > Microsoft SQL Server > Query Analyzer o open the Query Analyzer.
Attention: Never execute the following statements: Insert, Update and Delete!
Information about table fields can be get by entering statement: „sp_help <Table name>“
© 2005 SAP AG 70
With the command: ‘dbcc show_statistics (Table name, Index)’ you get Statistics about the density.
The density is a measurement how selective the index is.
Rows is the total number of rows the table has.
Rows Sam is the number of rows for which the statistics were created.
Steps is the number of rows selected by the database optimiser to create the statistics.
The density is a value how selective the index (field) is. Divide 1/Rows Sam. If the result is close to the
Density value displayed then the index (field) is very selective.
When you click the Result Grid #2 Button you see the density of the table fields. Due to the density for
the field SFAVBFA that is exactly the same as the density of the primary key index we conclude that
this field is unique.
When you click the Result Grid #2 Button you see the content of the fields for every step the statistics
were done. This information can be used for a more detailed analysis if requiredStored procedures are
executed within SQL Batch commands. Within the stored procedure Dynamic SQLs are fired to the
database. These SQL statements can be analysed in the Query Analyzer.
Suggestions based on analysis can be table indices or query changes.
© 2005 SAP AG 71
6 mySAP CRM ESelling Overview

CRM ESelling is a complete solution for selling products via the Internet. It supports all processes
connected with the sales cycle of all types of goods and services, in all industries. The main
characteristics are:
o SAP ESelling covers all phases of the sales cycle, from marketing, catalog browsing and search,
to order placement, payment, contract fulfillment and customer support.
o The SAP ESelling solution supports the SAP OneStep Business concept. This allows business
partners to access SAP Internet Sales web catalogs from a purchasing system and to order
products. Open Catalog Interfaces enable business processes to be concluded in one single,
integrated step.
o SAP Internet Sales allows companies to offer the right customers the right products at the right
time. As a result, the profitability and productivity of the company, as well as customer satisfaction
is improved.
Standard encryption technology, such as SSL (Secure Sockets Layer) guarantees your customers
security when executing all online transactions.
6.1 ESelling System Landscape

The main components of an SAP ESelling are summarized in the following table (see also the
diagram below).
R/3 system The R/3 backend system covers functionality for sales and distribution and
financial accounting.
CRM Server The CRM Server is used for:
· Central data storage and distribution unit for the CRM components.
· Message handling between clients and server, temporarily storing
information and guaranteeing its delivery.
· Data exchange with the R/3 system and other external systems.
J2EE Engine The SAP J2EE Engine 6.20 is a J2EE™compliant application server that
supports Servlets, Java Server pages (JSP), Enterprise Java Beans (EJB)
and all services listed in the J2EE™ specification.
The Internet Sales Web Application is running in the SAP J2EE Engine 6.20
and represents the middle tier between the clients (the web browsers) and
the SAP CRM resp. the R/3 system. It connects to the mySAP CRM system
and to TREX with RFC .The connection to the IPC is established through a
TCP connection.
The Web server is optional as a connection between the Web browser and
Web Server
the ESelling Web Application. The Web server is also used to deliver static
catalog content, such as product images.
The Web frontend connects directly with the Web server. On the Web
server, a specific plugin enables communication to the J2EE Engine. At
present only the MS Internet information Server with the J2EE IIS Extension
is supported and (Apache on Unix).
SAP JAVA Connector The SAP Java Connector enables RFC communication between JAVA
(JCo) applications (such as J2EE or IPC) and SAP systems (such as the CRM
server). Therefore, the SAP Java Connector is automatically installed during
the IPC (J2EE) setup. However, SAP Java Connector is not the most upto
date version available and may cause performance problems. Updating the
SAP Java Connector can solve these problems.
Internet Pricing and The Internet Pricing and Configurator is used to configure products and
Configurator (IPC) determine their correct prices.
© 2005 SAP AG 72
Text Retrieval & SAP TREX is used as a special purpose engine in the area of ECommerce.
Information It is optimized for indexing mass data, for example in catalog scenarios, or in
Extraction (TREX) an R/3 Application Help environment. SAP TREX is able to index and search
for documents (plain text, HTML, MS Power Point, MS Word, and so on) in
the form of a file destination or text from memory. It provides advanced
features for "error tolerant" and "similarity" searching.
Intelligent Product UBIS IPA is a 3rd party product, which is used to enable a guided selling
Advisor (IPA) process in the product catalog. It is an optional component.
TeaLeaf TeaLeaf is a 3rd party product to trace web activities and transport these
traces into a BW system. It is an optional component.
Persistent Shopping The Persistent Shop Basket consists of a local Database, where the
Basket shopping basket can be stored and loaded. It is an optional component.
Business Warehouse SAP Business Warehouse can be used for reporting purposes. It is an
(BW) optional component.
Advanced Planner The APO system can be used for availability statements in the ESelling
and Optimizer (APO) scenario, Supply Chain Management, Demand Planning and other tasks. It
is an optional component.
There are two possible scenarios for Internet Sales.
· ESelling with a CRM Backend
· ESelling (ISA R3) linked to R3.
Technical Overview: Internet Sales CRM Edition
© 2005 SAP AG 73
Technical Overview: Internet Sales R/3 Edition
· CRM Server
· IPC
· SAPJ2EE
· Webserver
Basic instructions for the monitoring of these components are given in the Appendix.
SAP delivers CRM with a special monitor set: CRM Middleware Alert Monitoring. This set includes
monitors for the technical middleware components of the CRM solution. It can be used via SAPGUI
using transaction RZ20. For more detailed information about how to install this monitor see SAP Note
437187.
combination with the Solution Manager for central monitoring, refer to the SAP Best Practice for
Monitoring in the mySAP ESelling can be divided into the following areas:
· Monitoring the endtoend message flow from the CRM to the R/3 System
· Monitoring SAPJ2EE via the Administrator.
· Monitor the R/3 Adapter components (Download objects, log file, queues, requests)
· Error analysis
© 2005 SAP AG 74
6.2 Core Business Processes in SAP CRM ESelling

ESelling installation:
Order Process in B2B Internet Sales – This scenario enables business partners to order products
on your web page. Marketing functions are not as important here, as this scenario is designed more to
enable business partners to find and order the chosen products quickly and easily. This scenario can
be linked with a purchasing application, such as Enterprise Buyer professional edition.
Order Process in B2C Internet Sales – This scenario allows end customers to order products and
services on your Web page. It is designed to offer products attractively in order to encourage
purchasing and in doing so maximize profit. Marketing, therefore, plays an important role here.
Product Catalog Management (and Product Recommendations) – This scenario enables you to
determine the content of your SAP Internet Sales application. The product catalog contains the
products that you want to sell via the Internet and in this respect presents the foundation of the Web
shop. In exactly the same way, you determine in the product catalog how products are presented and
how the web catalog is structured. Personalized or current product recommendations and cross / up
selling also make up the content. These marketing functions enable you to draw the attention of your
customers to certain products.
This Best Practice document describes the management of the business process Sales Order
Management in the two scenarios Businessto Business (B2B) and BusinesstoCustomers (B2C),
and a processoriented monitoring concept including the various components of a CRMISA solution
based on the classic integration scenario and ISA R3 Edition.
6.2.1 B2B Sales Order Management
This scenario enables business partners to order products and services on your web page. Marketing
functions are not very important here, as this scenario is designed to enable business partners to find
and order the chosen products quickly and easily. This scenario can be linked with a purchasing
application, such as Enterprise Buyer professional edition.
6.2.1.1 B2B Sales Order Management CRM Edition
Business customers select an employee to act as a contact person for sales orders. The process
starts when contact person logs on to the web shop using a user ID and password. In the web shop,
they can view a bestseller list containing personal product recommendations. These
recommendations are based on profiles created for each business when business customers first log
on to the web shop. Customers can also navigate directly to the product catalog, where they can
browse the entire range of products or services. Customers select the products they wish to purchase,
place them in their shopping basket and proceed to the check out, where the order is finalized. The
order value is calculated in the IPC and the pricing conditions are read from the CRM database via
RFC connection. At the check out, the order contains prices specific to the individual customer and the
customers can view the availability of their chosen products. This availability check can be done in a
R/3 system or in a mySAP APO system. A sales order is created in your CRM and back end systems,
where authorized sales representatives can easily access it for further processing.
6.2.1.2 We consider in detail the following process steps (standard process):
· Login to web shop
· Search and select products from shop
· Configure product
· Determine price
· Create shopping basket
· Determine price for shopping basket
· Check availability (R/3 or APO)
· Save shopping basket as an order template
· Create sales order (CRM)
· Create sales order (R/3)
© 2005 SAP AG 75
Process Workflow for Internet Sales B2B CRM Edition
6.2.1.3 Business Process Step 1: Login to web shop
The Internet user logs on into the Web shop using a User ID and password. This identifies the Internet
user as the contact person for the sales process.
The monitoring activities of this process step strongly depend on the hardware used.
system SAP recommends to monitor the objects listed in the following table in order to ensure that the
business step Web shop logon can be performed.
Monitoring Monitor Monitor Indicator Monitoring Activity or Respon Escalation

Object TA/Tool Freq. or Error Error Handling Procedure sibility Procedure
Connection SM59 Monthly Logon Check and monitor the Software/ Contact
and upon procedure connection between J2EE hardware system
error fails and CRM system and check monitoring administrator
if J2EE Server and team
Dispatcher are running
Internet Webbased User Monthly User is not Investigate the cause Software/ Contact
user management and upon allowed to hardware system
manageme SU01 error login monitoring administrator
nt team
SU05
6.2.1.3.2
Procedure
CCMS and upon performance monitoring
© 2005 SAP AG 76

Procedure
error monitoring team
error
Troubleshooting at log on
If the log on to the initial screen does not succeed, this indicates a connection problem between the
J2EE and the R3. Contact your system administrator and ensure that the connection is working
properly.
investigation. Please use component CRMISAUM.
6.2.1.4 Business Process Step 5: Search and select products from shop
The user can browse and search in the Web catalog for products. This step takes place in the index
server. The user can also perform direct order entry instead of browsing in a catalog for products. If
the material number is entered, a shopping basket is created without using a catalog.
Catalog views are used to create and manage customerspecific views for Web shop users (business
partners), for example, using filters. Specific catalog views can be assigned to specific business
partners.
business step Browsing the product catalog and searching for products can be performed.

Procedure
Catalog COMM_PCAT_ Upon error Catalog is Check and monitor the Software/
maintenance ADM missing, product catalog content hardware
info is not monitoring
consistent, etc
Shop Web based Upon error Shop is not Check and monitor the Software/
maintenance shopadmin shown, shop is shop content hardware
working monitoring
incorrectly
Product COMM_PCAT_ Every Replication fails, Check and monitor the Software/
Catalog IMS_INIT replication web shop data is replication runtime hardware
Replication not consistent monitoring
COMM_PCAT_ or upon
IMS_UPDA error
· Product inconsistencies
The Internet user notices product inconsistencies (data is missing or erroneous) in places that
previously did not show inconsistencies. It may be that after an update replication from the product
catalog, the Web shop cache has not been updated.
Another variant of this problem is when products do not appear in the Web shop or the products that
the Internet user sees are different from the expected ones. If you are using catalog views, ensure that
the business partner is assigned to the right catalog view.
investigation. Please use component CRMISACAT.
© 2005 SAP AG 77
6.2.1.5 Business Process Step 6: Configure product
This is an optional step. The IPC allows customers buying your products in the Web catalog to choose
exactly which product components they require. Specifying these product components is called
"configuring" the product.
The master data that the IPC uses for product configuration is maintained in the R/3 system and
downloaded to the CRM database. When a configurable product is handled in a sales order
transaction, the product is configured interactively by the IPC services, which is accessed via an
HTML control and the Web server. The IPC reads the configuration data via RFC from the CRM
database.
business step Configure products can be performed.

Object TA/Tool Freq. Error Handling
Procedure
IPC Task Upon error or Product Check and monitor the Software/
manager performance Configuration does hardware utilization hardware
problem not work or price monitoring
IPC log files
inconsistencies
occur
Troubleshooting while calling the IPC for product configuration:
After checking the configuration icon at product level, you find there is a problem when the IPC is
called for product configuration. If Support Packages were recently applied, SAP recommends
checking whether the Support Package level in the IPC is the same as the Support Package level in
the CRM server. If not, implement the same Support Package level in the IPC and in the CRM server
and Internet Sales.
team.
investigation. Please use component CRMISACFG.
6.2.1.6 Business Process Step 7: Determine price
The price of the product that is displayed in the catalog is calculated in the IPC in the background. The
system recognizes users by their user ID, and offers them individually pitched prices. IPC can access
both the Customizing data as well as the condition records. The master data that the IPC uses for
pricing is maintained in the R/3 system and downloaded to the CRM database. As a result, the
problem of data transfer from the R/3 system into the IPC system is avoided and the results of pricing
in Internet Sales are identical with those in the CRM system. In order to calculate the price of the
products, the IPC reads from its buffer or from the CRM database via Remote Function Call (RFC).
© 2005 SAP AG 78
business step Determine the Product Price can be performed.
Monitoring Monitor Monitor Indicator or Error Monitoring Activity Responsibility

Object TA/Tool Freq. or Error Handling
Procedure
CPU and Task manager Upon error or Product Check and monitor the Software/
IPC performance Configuration does hardware utilization hardware
problem not work or price monitoring team
IPC log files
inconsistencies
occur
IPC IPC Monitor Command >> Show Software
Statistic statistics monitoring team
J2EE J2EE If there are Shop functionalities Log files Software

Administration errors or poor are working monitoring team
performance incorrectly
Response time for
the shop operation
is high
· Troubleshooting while calling the IPC for pricing
If Support Packages were recently applied, SAP recommends to check whether the Support Package
level in the IPC is the same as the Support Package level in the CRM server. If not, implement the
same Support Package level in the IPC and in the CRM server.
investigation. Please use component APBFPR.
6.2.1.7 Business Process Step 11: Create shopping basket
In the Web Shop, the customer can create an order either directly by entering the material number of a
product in fast order entry or by adding products to the virtual shopping basket that the customer
identified through a search function in the product catalog. Once the shopping basket contains all
articles to be purchased, the order is checked out and submitted. Customerspecific prices are
displayed. During this process the CRM server calls IPC for pricing and to calculate the order value
(see below under “Determine Price for the Shopping Basket”). When you create the shopping basket,
a sales order with status “offer” is created in the CRM server.
business step Create Shopping Basket can be performed.
Monitoring Monitor Monitor Monitoring Activity or Respon Escalation

Object TA/Tool Freq. Error Handling sibility Procedure
Procedure
Performanc ST03, STAD Weekly and upon Long runtime See chapter Application
e error performance monitoring team
monitoring
J2EE J2EE If there are errors Log files Application Contact system
Administration or poor monitoring administrator
performance team
Isaruntime.log
© 2005 SAP AG 79

Procedure
Isa.log
Regularly monitor the RFC response time statistics with the following monitors: the statistical records
monitor (STAD) and the system workload analysis monitor (ST03) – in both the CRM server and R/3
system. If you find performance is critically poor, SAP recommends ordering an Early Watch session
with a focus on performance tuning.
Procedure
error
Troubleshooting while calling the IPC for product configuration and pricing:
If necessary, you can restart the J2EE server and IPC server. This leads that the Internet user will
loose there sessions. Check the regarding logs isa.log, isaruntime.log for exceptions and review that
with your internal development team.
team.
In situations that may require escalation, contact the system administrator or your business process
owner.
investigation. Please use component CRMISABBS.
6.2.1.8 Business Process Step 12: Determine price for shopping basket
When a sales order item is priced, the CRM system uses an RFC (Remote Function Call) to request
pricing information from the Internet Pricing and Configurator, usually in the background. The RFC call
goes to the IPC Bridge, which converts the call to an IPC command. CRM system always uses the
IPC to calculate prices.
business step Determine Price for Shopping Basket can be performed.
Monitoring Monitor Monitor Monitoring Activity or Responsibility

Performanc ST03, STAD Weekly and upon error Long runtime See chapter
e performance
monitoring
J2EE J2EE If there are errors or Log files Application
Administration poor performance monitoring team
Isaruntime.log
Isa.log
IPC IPC Monitor Daily Monitor IPC statistics Application
monitoring team
© 2005 SAP AG 80
Regularly monitor the RFC response time statistics with the following monitors: the statistical records
monitor (STAD) and the system workload analysis monitor (ST03) – in both the CRM server and R/3
system. Regularly monitor the IPC using the IPC Monitor tool. For more detailed information, see the
SAP Online Documentation on the IPC directory.
If there are inconsistencies with pricing calculation in the IPC, SAP recommends using the Desktop UI
tool that is including with the IPC. Connect to the IPC server remotely so you can analyze the price
calculation for a current session.
6.2.1.9 Business Process Step 13 or 14: Check availability (R/3 or APO)
For the process step Check availability(APO/R/3) please review the corresponding section in the
Availibility Check section in the CRM Online part.
6.2.1.10 Business Process Step 15: Save shopping basket as order
template
6.2.1.10.1 If business partners wish to make recurring orders, they have the option of saving the
shopping basket with the appropriate products as an order template. Using order templates
means that they can access document processing at any time and process their order
efficiently, by copying an order template or individual products out of it.
business step Save Shopping basket as an Order Template can be performed.
Monitoring Monitor Monitor Monitoring Activity or Responsibility

Performanc ST03, STAD Weekly and upon Long runtime See chapter
e error performance monitoring
BDocs SMWP Daily Red light at the BDoc level Application monitoring
(CRM) team
Queues SMWP Daily Queues are stopped. Application monitoring

(CRM) team
Investigate the cause
When the shopping basket is saved as an order template, a BDoc is generated. This BDoc transacts
with the application database to request or write data. To ensure the normal flow of this business step,
SAP recommends using the Middleware Portal (transaction SMWP) to monitor the state of BDocs
daily. For all BDocs that are "stopped", investigate why this happened and take corrective action.
For each BDoc, error handling is maintained in transaction SMW00. For example, after 10
unsuccessful attempts to process the BDoc CONGEN_OBJECT_WRITE, an email is sent to the
responsible person. Per BDoc, the number of executions and action must be defined. In addition, the
required workflow must be set up in transaction SWU3.
owner.
© 2005 SAP AG 81
6.2.1.11 Business Process Step 16: Create sales order (CRM)
A sales order is created in the CRM server and transferred to the R/3 backend system. In both the
CRM server and the R/3 system, the order can be accessed for further processing by an authorized
sales clerk.
With APO Integration
If the B2B scenario is integrated with mySAP SAP Advanced Planner and Optimizer (APO), an
additional availability check is carried out and a persistent reservation performed for the product. Once
the sales order has been transferred to R/3, the reservation is converted in APO, and the sales order
is further processed in R/3.
Procedure
error
For more information regarding the process step Create sales order (R/3) please review the
corresponding section in the Sales Order Management section in the CRM Online part.
6.2.1.12 Business Process Step 18: Create sales order (R/3)
After the order has been transferred to the R/3 system, the order processing is finished there. You can
view or change the document, check the document flow and create follow up documents (for example,
delivery and billing documents).
For more information regarding the process step Create sales order (R/3) please review the
corresponding section in the Sales Order Management section in the CRM Online part.
6.2.1.13 B2B Sales Order Management R/3 Edition
The main difference between this process and the B2B Sales Order Management CRM Edition is that
in this case there is no CRM system installed and the sales orders are saved directly in the R/3
system.
Customers log on to the web shop using a password and an email address. Customers select the
goods they wish to purchase, place them in their shopping basket and proceed to the check out,
where they confirm their order and select a payment method. They can then submit their order. The
sales order is created directly in the R/3 system, where authorized sales representatives can easily
access it for further processing. Optional the saving of the shopping basket as order template is
possible, if the JDBC Basket is installed. Also optional the replication of the products to the TREX is
possible. This means the products are selected from the TREX Index Server into the shopping basket.
the Internet Sales B2B R3 Edition focuses only on the process steps (or monitoring details) which are
different to the process steps mentioned in the process description above (see chapter: Internet Sales
B2B CRM Edition).
© 2005 SAP AG 82
Process Workflow for Internet Sales B2B R3Edition
6.2.1.14 Business Process Step 1: Login to web shop
business step Web shop logon can be performed
Connection SM59 Monthly Logon Check and monitor the Software/ Contact
and upon procedure connection between J2EE hardware system
error fails and CRM system and check monitoring administrator
if J2EE Server and team
Dispatcher are running
Performanc ST05 Monthly Logon Monitor hardware utilization Software/ Contact
e J2EE log and upon runtime is on Middleware server, hardware system
error long network load, CRM system monitoring administrator
(isaruntime.log) team
load
Internet SU01 Monthly User is not Investigate the cause Software/ Contact
user SU05 and upon allowed to hardware system
manageme error login monitoring administrator
nt team
properly.
© 2005 SAP AG 83
6.2.1.15 Business Process Step 3 or 4: Search and select products from
shop
The user can browse and search in the Web catalog for products. This step takes place in the cached
catalog products. The user can also perform direct order entry instead of browsing in a catalog for
products. If the material number is entered, a shopping basket is created without using a catalog.
Catalog views are used to create and manage customerspecific views for Web shop users (business
partners), for example, using filters. Up to SP5 it is possible to use the TREX to replicate the products
from the R3 Product Catalog to the TREX. This functionality is recommended for huge product
catalogs > 5000.

business step Search and select products from shop can be performed.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon Escalation
Object TA/Tool Freq. Error Error Handling sibility Procedure
Procedure
Catalog WWM2, WWM3 Upon error Catalog is Check and monitor the Software Contact
maintenanc missing, product catalog content / system
e info is not hardware administrat
consistent, etc monitorin or
g
TREX Webbased Upon error Catalog error in the Check the XCM scenario Software/ Contact
Web shop and the maintained XML hardware system
files monitoring administrator
Shop Shopadmin Upon error Shop is not Check and monitor the Software Contact

maintenanc Javabased! shown, shop is shop content / system
e working hardware administrat
incorrectly monitorin or
g
Product inconsistencies
The Internet user notices product inconsistencies (data is missing or erroneous) in places that
previously did not show inconsistencies. It may be that after a restart of the J2EE Engine the loading
of catalog is not completed.
investigation. Please use component CRMISACAT.
6.2.1.16 Business Process Step 3: Create shopping basket
In the Web Shop, the customer can create an order either directly by entering the material number of a
product in fast order entry or by adding products to the virtual shopping basket that the customer
identified through a search function in the product catalog. Once the shopping basket contains all
articles to be purchased, the order is checked out and submitted. Customerspecific prices are
displayed. During this process the R/3 calls IPC for pricing and to calculate the order value (see below
under “Determine Price for the Shopping Basket”). When you create the shopping basket, a sales
order with status “open” is created in theR/3. Price determination in the IPC takes not place in case list
prices are used

business step Create shopping basket can be performed
Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Respon Escalati
Object TA/Tool Freq. Error Handling sibility on
Procedure Procedu
re
© 2005 SAP AG 84
Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Respon Escalati

Object TA/Tool Freq. Error Handling sibility on
Procedure Procedu
re
Performanc ST03, Weekly Long runtime See chapter performance Application Contact
e STAD and upon monitoring monitoring system
error team administr
ator
J2EE J2EE If there Long runtimes, Log files Application Contact
Administr are functional errors monitoring system
ation errors or team administr
Isaruntim poor ator
e.log performa
nce
Isa.log
Troubleshooting while calling the IPC for product configuration and pricing:
If necessary, you can restart the J2EE server and IPC server. This leads that the Internet user will
loose there sessions. Check the regarding logs isa.log, isaruntime.log for exceptions and review that
with your internal development team.
In addition, use transaction ST22 to check whether there are short dumps in the R/3. If you find dumps
from configuration programs, review those programs together with the development team.
owner.
6.2.1.17 Business Process Step 6: Save Shopping basket as an Order
Template
If business partners wish to make recurring orders, they have the option of saving the shopping basket
with the appropriate products as an order template. Using order templates means that they can
access document processing at any time and process their order efficiently, by copying an order
template or individual products out of it. This works in the ISA R3 Edition only with the JDBC Basket
and an additional SQL Database.
business step Save shopping basket as an Order Template can be performed.
Monitoring Monitor Monitor Indicator Monitoring Activity or Responsibility Escalation

Procedure
Performanc ST03, Weekly Long See chapter performance Application Contact
e STAD and upon runtime monitoring monitoring team system
error administrator
If necessary, you can restart the J2EE server. This leads that the Internet user will loose there
sessions. Check the regarding logs isa.log, isaruntime.log for exceptions and review that with your
internal development team.
© 2005 SAP AG 85
Business Process Step 5: Track sales orders (optional step not shown in the
graphic)
Customers can call up the status of their orders at a later stage in SAP Internet Sales R/3 Edition, and
display further information from external service providers, display the delivery status from the carrier,
for example

business step Tracking orders can be performed.
Monitoring Monitor Monitoring Activity or Responsibility Escalation
Object Freq. Error Handling Procedure Procedure
Performanc ST03, STAD See chapter performance Application monitoring Contact system
e monitoring team administrator
Order Status SE16 Check order status manually, Application monitoring Contact system

check table VBUK team administrator
If the performance is poor during the selection of the orders and the tracking status is recommended to
check the transaction STAD for time consuming tables and programs. Further the Status of the orders
should be checked by using transaction SE16 and the concerning table VBUK.
investigation. Please use component CRMISAR3.
Business Process Step 7: Display invoice (optional step not shown in the
graphic)
Customers can display their invoices in SAP Internet Sales R/3 Edition. The system accesses the
invoice information stored in the SAP R/3 System.
business step Display Invoice can be performed.
Procedure
Performanc ST03, STAD Weekly and upon See chapter Application Contact system
e error performance monitoring monitoring administrator
team
J2EE J2EE If there are errors or Log files Application Contact system
Administratio poor performance monitoring administrator
n team
Isaruntime.lo
g
Isa.log
Please refer to the Business Step “Tracking Orders” which includes the same monitoring possibilities.
investigation. Please use component CRMISA.
© 2005 SAP AG 86
6.2.2 B2C Sales Order Management
This scenario enables customers to order products and services on your web page. Marketing
functions are important here, as this scenario is designed to sell your products to occasional
customers, allowing them to find and order the chosen products quickly and easily. This scenario can
be linked with a purchasing application, such as Enterprise Buyer professional edition.
6.2.2.1 B2C Sales Order Management CRM Edition
Usually customers first browse trough the catalogue or select products from bestsellers lists. They can
also configure products and determine their (generic) price, before logging on to the web shop.
However they can also logon at first. Customers log on to your web shop using a password and an e
mail address. Once logged on, they can view a bestseller list containing personal product
recommendations. These recommendations are based on profiles for each individual customer
generated when customers first log on to the Web shop. Customers select the goods they wish to
purchase, place them in their shopping basket and proceed to the check out, where they confirm their
order and select a payment method. They then submit their order. The sales order is created in the
CRM and back end systems, where authorized sales representatives can easily access it for further
processing.
Process Workflow for Internet Sales B2C CRM edition
The business process steps for B2C Sales Order Management are quite similar to B2B Sales Order
Management process. The following detailed description of the process steps with the monitoring
procedure and activities for the Internet Sales B2C Sales Order Management focuses only on the
process steps which are different to the process steps mentioned in the process description above
(see chapter: B2B Sales Order Management CRM Edition).
6.2.2.2 We consider in detail the following process steps:
· Login to web shop
· Do payment check
Business Process step 9: Login to web shop
© 2005 SAP AG 87
business step save shopping basket as a Create Web User/Login can be performed

Connection SM59 Monthly Logon Check and monitor the Software/ Contact system
and upon procedure connection between J2EE and hardware administrator
error fails CRM system and check if J2EE monitoring
Server and Dispatcher are team
running
Performance ST05 Monthly Logon Monitor hardware utilization on Software/ Contact system

and upon runtime is Middleware server, network load, hardware administrator
J2EE log long monitoring
(isaruntime.log) error CRM system load
team
Internet user Monthly User is not Investigate the cause Software/ Contact system
management SU05 and upon allowed to hardware administrator
error login monitoring
team
properly.
Business Process step 16: Do payment check
The customer selects the payment method (invoice, cash on delivery or credit card). If Credit Card is
chosen, then credit card institute, card number and validity date must be entered.
Monitor interfaces to external payment systems. For this interface, define error handling procedures,
restart and recovery procedures.
business step Do Payment Check can be performed
Performanc ST05 Monthly Logon Monitor hardware utilization Software/ Contact
e J2EE log and upon runtime is on Middleware server, hardware system
error long network load, CRM system monitoring administrator
(isaruntime.log)
load team
investigation. Please use component CRMISA.
© 2005 SAP AG 88
6.2.2.3 B2C Sales Order Management R/3 Edition
The main difference between this process and the B2C Sales Order Management CRM Edition is that
in this case there is no CRM system installed and the sales orders are saved directly in the R/3
system. Usually customers first browse trough the catalogue. They can also configure products and
determine their (generic) price, before logging on to the web shop. However they can also logon at
first. Customers log on to the web shop using a password and an email address. Customers select
the goods they wish to purchase, place them in their shopping basket and proceed to the check out,
where they confirm their order and select a payment method. They can then submit their order. The
sales order is created directly in the R/3 system, where authorized sales representatives can easily
access it for further processing. Optional the saving of the shopping basket as order template is
possible, if the JDBC Basket is installed. Also optional the replication of the products to the TREX is
possible. This means the products are selected from the TREX Index Server into the shopping basket.
the Internet Sales B2C R3 Edition focuses only on the process steps (or monitoring details) which are
different to the process steps mentioned in the process description above (see chapter: Internet Sales
B2B CRM Edition).
Process Workflow for Internet Sales B2C R3 Edition
Business Process step 6: Login to web shop
The Internet user logs on into the Web shop using a User ID and password.
business step Login to web shop can be performed.
© 2005 SAP AG 89

Connection SM59 Monthly Logon Check and monitor the Software/ Contact system
and upon procedure connection between J2EE and hardware administrator
error fails CRM system and check if J2EE monitoring
Server and Dispatcher are team
running
Performance ST05 Monthly Logon Monitor hardware utilization on Software/ Contact system

and upon runtime is Middleware server, network load, hardware administrator
J2EE log long monitoring
(isaruntime.log) error CRM system load
team
Internet user Monthly User is not Investigate the cause Software/ Contact system
management SU05 and upon allowed to hardware administrator
error login monitoring
team
properly.
6.3 SAP Recommendations for additional

components
Product Catalog Management and Product Recommendation
You determine the following content of your SAP Internet Sales application with this business
scenario:
· Products you want to offer in your Web shop
· Structure of the Web catalog
· Personalized or current product recommendations you want to use for advertising
· Cross / upselling products you want to offer your customers
You can refer to the analysis results from Web Analytics to do this.
Determine catalog contents
1. You create the chosen products in SAP CRM and replicate the products to the TREX.
2. You create a product catalog with a corresponding catalog type. If you want a catalog type
that does not yet exist, you create it in the IMG of SAP CRM. You activate the product catalog
so that it is taken into account during the publication that takes place later on.
3. You create a catalog variant for your product catalog. You activate the catalog variant so that
it will be considered during the replication that takes place later on.
4. You create catalog areas that correspond to your idea of how your Web catalog should look.
5. You assign products to the catalog areas.
6. You can assign multimedia objects to products and catalog areas. You can also adopt
multimedia objects that are assigned to products in the product master.
7. You activate the catalog areas so that they will be considered during the publication that takes
place later on
8. You can create catalog views and activate them
9. You replicate product catalog contents.
Offering personalized product recommendations (optional)
1. You define target groups of the product proposal category for your planned marketing activity.
2. You put the products that you want to offer into a topn product list. This can contain a
combination of products that are manually assigned and automatically determined.
© 2005 SAP AG 90
3. You assign an attribute set to your Web shop in CRM.
Offering current product recommendations (optional)
1. You define a global target group for your planned marketing activity. With this target group all
customers who enter the Web shop are offered the same product recommendations.
2. Assign the global target group to your topn product list. This can contain a combination of
products that are manually assigned and automatically determined.
3. You assign the corresponding global target group to your Web Shopadmin.
Offering Cross / UpSelling Products (optional)
1. You create a method schema.
2. You define rules for cross/upselling.
3. You assign a method schema to your Web shop in SAP CRM that determines cross /up
selling products
4. If you want to offer your customers personalized cross/upselling products, select the
Personalized Cross/UpSelling field in the Web shop master.
5. If you want to offer your customers global cross/upselling products, edit the Target Group for
Global Cross /UpSelling field in the Web shop master.
6.3.1 Security Recommendation for ESelling
You have just installed the Internet Sales scenario and want to ensure that it is protected from
unauthorized usage or attacks from Internet. The default settings of J2EE do not provide sufficient
level of security for business data. This is getting more important if Internet Sales solution is supposed
to be used by Internet users.
6.3.1.1.1 Security settings, Handling, Restartability, and Escalation
We recommend you to take special care in the configuration of the Web server's operating system.
For example, keep the network services that the server offers to the bare minimum needed for the
operation of the server.
For an Internet shop, you have to leave a user ID and password on the middleware server, which has
access to the CRM Server. R/3 system, so that anonymous access to the shop is possible. This is why
the middleware host should not be located in the demilitarized zone (DMZ) but in the internal network.
Additionally this user should have only very limited permissions in the backend system.
For enhanced security, you can implement a multistage firewall concept and place another firewall
between the middleware host and the internal backend systems like CRM, R/3, APO and BW.
These are general recommendations, which should be adjusted depending on the landscape of your
Internet Sales solution.
1. Directory browsing
After installing J2EE server the directory browsing is enabled by default. The recommendation is to
disable it by changing the property of ‘HTTP’ service in file:
<J2EE_install_dir>\cluster\server\services\http\properties.
Please change the setting DirList to: DirList=false.
Disable directory browsing on IIS by disabling the ‘Directory Browsing’ property of the virtual directory
or site, which is used for storing MIME files:
Internet Information Server=> Default WebSite => your_site_name =>Properties => Directory = >
Directory Browsing (checkbox).
SAP Note 531495 describes how to disable directory browsing in inqmy web server.
2. HTTP PUT
To disable HTTP PUT command in J2EE web server for special application (B2B or B2C) you need to
edit the file
<J2EE_install_dir>\cluster\server\services\servlet_jsp\globalweb.xml
and uncomment the lines starting with:
<! Remove comment to protect all resources from PUT request leaving the above line in comments.
© 2005 SAP AG 91
You may find an example in the J2EE Administration manual.
Disable also HTTP PUT in IIS for virtual directory or site, which stores MIME objects:
Internet Information Server => Default WebSite => your_site_name =>Properties => Directory =>
Write (checkbox)
3. Administrator password for J2EE server
The admin pages of J2EE’s web applications (B2B or B2C) are protected by username –
Administrator and a password. By default the password is left blank and is required to be changed.
Please refer to documentation of J2EE server (valid after ISA 3.0 SP7).
4. FTP server
If you replicate mime objects to the web server outside the firewall (e.g. IIS server) please ensure that
FTP protocol is disabled after creating the directory structure (00FF).
Background: The CRM system uses FTP to create catalog directories during the initial replication by
the publishing server. Images and other catalog mimes are transferred with HTTPPUT. The standard
FTP transfer mode is the active mode, which needs to open backward connections from source port
20 to a dynamically assigned target port range on the FTP client.
If you do not want to allow incoming TCP connections into your Intranet, you should use passive
mode. SAP note 0420512 describes how to activate passive mode.
5. Port on the firewall before J2EE server
J2EE server opens several TCP ports used for controlling of its services. It is recommended to disable
routing through the firewall before J2EE server of all the ports except for those used for HTTP
(HTTPS) protocol. Please refer to your hardware supplier to clarify the setup of firewalls in your
system.
In order the changes to take effect you need to restart your J2EE and IIS servers as well as firewalls.
We recommend to visit the ‘Secure Business with SAP’ web site in the SAP Net for further security
methods. Address: http://service.sap.com/security.
For further details: SAP Note 606733 composite SAP note on security of Basis 6.20
© 2005 SAP AG 92
7 mySAP CRM Marketing and Analytics

CRM Marketing and Analytics as key capability of mySAP CRM enables the customer to carry out
desired marketing activities by providing a wide range of tools and functions for all levels of marketing,
from planning campaigns and trade promotions, through to the creation of target groups, personalized
product recommendations, and complex market analysis functions. The high level of integration
between the different marketing components enables data to be accessed simultaneously across
different interfaces. At various stages of the marketing cycle, data on all business objects (business
partners, marketing plans, target groups, top n product lists, leads, external address lists) can be
written to the SAP Business Information Warehouse (SAP BW) for evaluation purposes. Additionally
data of SAP BW, SAP APO and SAP R/3 can be used for planning purposes and creation of marketing
objects.
7.1 Marketing System Landscape

The main components of a SAP Marketing installation are summarized in the following table:
SAP CRM Enterprise The CRM Server is used as the central data storage and distribution unit for the
System CRM components and the data exchange with R/3 and other connected external
systems.
CRM Mobile Clients Can use all marketing data available in CRM Enterprise
R/3 system The backend system covers functionality for financial accounting, controlling, and
material management in case of the integration scenario.
SAP APO Provides information for planning
SAP BW with SAP SEM Provides information for planning and segmentation
SEMBPS PROMO Order MSA

CRM Server Item
Offer Offer
Item
Condition s
Products
Products
BW Condition s
SAP SA
SAP
P R/
R/3
3
APO
PS COPA MM FI SD
The graphic above shows a typical hardware solution landscape for CRM Marketing, integrated with
SAP R/3 and SAP BW.
© 2005 SAP AG 93
· CRM Server
· SAP BW
Monitoring in the mySAP CRM Marketing environment can be divided into the following areas:
· Monitoring BDOCs related to the marketing objects
· Error analysis
© 2005 SAP AG 94
7.2 Core Business Processes in SAP CRM Marketing

and Analytics
Marketing and Analytics installation:
· Marketing Planning and Campaign Management
· TPM Trade Promotion Management
· Business Partner Segmentation
The management of these business processes along with a processoriented monitoring concept
including the various components of an SAP CRM Marketing solution based on the solution with a
connected Backend is described in this Best Practice document. As a lot of process steps interact with
CRM middleware, please see also the generic chapter for BDOC monitoring. For each concerned step
the appropriate BDOC is mentioned.
7.2.1 Marketing Planning and Campaign Management
Process Workflow for Marketing Planning and Campaign Management
At first, a marketing plan and further marketing elements (marketing plans, marketing plan elements,
campaigns and campaign elements can be summed up with the term marketing elements) are created
according to planning requirements.
Marketing plans are used for the longterm planning of marketing activities, including budgeting and
scheduling. For example, they can be used as a management tool for annual costing in the Marketing
© 2005 SAP AG 95
department. Any number of marketing plan elements can be used to structure a marketing plan in the
form of a hierarchy.
Campaigns can be assigned to marketing plans and form their operative structure. They describe the
actions performed, for example mailing actions, TV spots, and telemarketing, so they are used for
operative marketing planning and execution. Campaigns are broken down into campaign elements.
The creation of marketing elements can take place directly in the Marketing Planner or via the
Marketing Calendar.
The Marketing Planner is a tool for creating and editing marketing plans and campaigns. It supports
work with individual marketing plans and campaigns or with an entire plan hierarchy.
The Marketing Calendar is designed to act as a central entry point for field people and provides a
working area that gives an overview of all promotional events within a certain time range. It allows
defining criteria for displaying marketing projects by means of a query and therefore to look at
marketing projects from several perspectives or viewpoints; for example, by brand, customer, or
product group by selecting a particular view. Displaying is possible by a graphical view or a list view.
During saving the marketing elements and their hierarchy can be updated to BW.
For each marketing element some basic information as ID, description, type etc. has to be maintained.
In the next step different objects can be assigned as target group, products.
For planning key figures from BW can taken into account during the next step. These values are
directly updated to SEM.
During saving, the marketing elements can be transferred to R/3 to act as a cost collector.
After the marketing structure is saved and its status is changed to released, the campaign can be
executed. Executing means to contact the business partners by the chosen channel, this can be via
CIC, by mail or by other possibilities.
Therefore the followon steps are either the creation of a call list for CIC, the lead generation or the
generation of emails. Additionally an activity can be created for each way, which can be extracted to
BW.
7.2.1.1 Business Process Step 1: Create Marketing Plan
A marketing project can be created new or by help of a template. This can be done via the Marketing
Calendar (transaction CRM_MKTPL_CALENDAR) or in the Marketing Planner directly (transaction
CRM_MKTPL). A template can be an already existing marketing plan, a campaign (see later) or a
Microsoft Project.
Data to be maintained can be i.e. priority and planning profile group, dates, segments and partner.
Contrary to some other CRM Enterprise Applications, it is not possible to save an object in the
marketing planner as long as it has a message of type 'error'.
When you save the marketing plan, it can be automatically transferred to BW by RFC.
A marketing plan can be transferred also to a mobile client by intelligent subscription. For this purpose
BDOCs MKTPL_MKTELEM and CAMPAIGN_WRITE are used.
Monitoring Object Monitor Monitor Indicator or Monitoring Activity or Respon
TA/Tool Freq. Error Error Handling sibility
Procedure
Marketing hierarchy, SM37 Daily Status Check Job Log Application
report monitoring
CGPL_BW_ACTIVAT team
E_HIERARCHY
© 2005 SAP AG 96

TA/Tool Freq. Error Error Handling sibility
Procedure
mBDOC SMW01 Daily Status F01, Check error message Application
MKTPL_MKTELEM, E01 monitoring
sBDOC team
CAMPAIGN_WRITE
During the start of the marketing calendar, the system displays warning stating that the logon language
was not maintained. This is caused by missing customizing and can be solved with the following path
"CRM>Marketing>Marketing Planning and Campaign Management>Marketing Calendar>Define
Field Settings for Table View" (according to note 710518).
If views are missing in the marketing calendar, this can also be solved by customizing with path “CRM
>Marketing>Marketing Planning and Campaign Management>Marketing Calendar>Define Views for
Marketing” (note 727283).
The list viewer in the calendar does not show any data. In this case the global layout is not maintained,
which can be done according to note 674241.
Transaction CRM_MKTPL_BW_UPDATE provides the possibility to transfer marketing projects to BW.
This transaction can not be used in case of deactivation of marketing hierarchy update to BW in
customizing.
The automatic transfer of an element to BW can be deactivated in customizing according to note
631742 to improve performance. In this case report CGPL_BW_ACTIVATE_HIERARCHY should be
scheduled on a regular base (i.e. daily according to note 611321) to update the hierarchy in BW. The
report should be monitored by SM37.
Errors during the download of marketing plans to mobile clients can be detected within SMW01 for
MKTPL_MKTELEM. More details for monitoring and restartability procedures for middleware
functionality for this step and the following can be found in the middleware chapter.
7.2.1.2 Business Process Step 2: Create Marketing Plan Element
Marketing plan elements are used to structure a marketing plan. Please see the step Create Marketing
Plan for Monitoring Activities, Error Handling, Restartability and Escalation.
7.2.1.3 Business Process Step 3: Create Campaign
A campaign can be created new or by use of a template (an already existing campaign). Data to be
entered are i.e. campaign type (helps to categorize individual campaigns), priority, authorization group,
planning profile group (to use the corresponding planning profile from SEMBPS), partner responsible,
currency, dates, action profile or status. Please see the step Create Marketing Plan for Monitoring
Activities, Error Handling, Restartability and Escalation.
7.2.1.4 Business Process Step 5: Create Campaign Element
With a campaign element a campaign can be structured. Please see the step Create Marketing Plan
for Monitoring Activities, Error Handling, Restartability and Escalation.
7.2.1.5 Business Process Step 6: Assign objects to campaign elements
Different objects can be assigned to marketing elements.
A target group is a list of business partners drawn up with a specific marketing activity in mind. A target
group can be created both by executing the selection conditions for a marketing profile or
independently of the profile. Therefore four possible sources for a target group exist, a selection based
on marketing attributes of business partners in CRM, an infoset query within CRM, a query within BW
or as of 4.0 also a query on business partners from an external system can be used. To create and
work with the target group, the Segment Builder is used. This tool is HTMLbased and allows a user
e.g. to split or to merge target groups based on different criteria. The creation of target groups will be
discussed in a separate chapter later on.
© 2005 SAP AG 97
A product or product group, which should be promoted, can be assigned. For them special conditions
can be maintained, which will be valid during the length of the campaign. These conditions can be
determined in a sales order, which is created with reference to a campaign.
Business partners with partner functions can be assigned to a marketing element. Later on these
partners can be used for activity management.
For a campaign element, a survey can be specified. This could be used as a feature within campaign
automation process.
Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Respon
Object TA/Tool Freq. Error Handling Procedure sibility
Marketing Marketing Planner After Error message Check error message User
element CRM_MKTPL creation
Business partner determination will not occur, even if a partner determination procedure was
maintained in customizing. This is not a program error. The determination can only be used to define
allowed partner functions and minimum and maximum numbers per function. The requested
functionality could be implemented by means of a BADI (note 724295).
In case of error messages regarding partners, which prevent from saving the plan, note 634022 offers
help.
7.2.1.6 Business Process Step 7: Plan key figures
Key figures from marketing plans and campaigns form the basis of planning and reporting. Key figure
planning from SAP BW/SEM is fully integrated with CRM 4.0 to allow planning using the Marketing
Planner as a basis. There is the option of carrying out key figure planning using an ALV grid or Excel
sheet or in HTML. This option gives additional features, allowing synchronizing dates, products, target
groups, sales organizations, customers, success measures, trade spends, EEW enhancements and
currencies. This can all be done directly from the Marketing Planner. The technical basis for planning
is the planning processor of SAP SEM, so the planning data is edited directly in SAP BW.
SAP CRM updates the master data for the marketing elements to SAP BW automatically during
saving by RFC.
Marketing Marketing During Error message Check message User
Element Planner creation
SAP SEM collects all planning errors in a log. Errors that occur when the planning system is called up
are logged in the marketing planner directly.
Note 741512 provide a solution for common customizing problems in CRM Planning and its related
errors (key figures set to zero, language of texts, short dump 'Function module UPX_KPI_API_XML
missing', mode of fields, decimals of key figures).
7.2.1.7 Business Process Step 9: Transfer account object
A connection between mySAP CRM and the SAP R/3 System is set up when actual costs or revenues
for the marketing project should be entered and settled to Profitability Analysis. A marketing element
can be assigned to an existing WBS element, or from the Marketing Planner a new WBS element can
be created with an assignment to a marketing element.
When a marketing object is created in the Marketing Planner, it can be transferred to the R/3 project
system manually or automatically, once a status allowing transfer is assigned. Manually transfer
means to execute the transfer manually directly from Marketing Planner, automatically transfer means
© 2005 SAP AG 98
via middleware when saving the object. For the manual transfer the consistency can be checked in
advance directly in the Marketing Planner.
TA/Tool Freq. Error Error Handling Procedure sibility
Transfer of Marketing After Status Check error message User
campaign to R/3 Planner manual
transfer
BDOC Middleware Daily Status Check error message Application

MKTPL_MKTELEM monitoring monitoring
SMW01 team
Queue SMQ1 Daily Status Application
CSAMKTPL* monitoring
team
For a successful transfer the following points have to be taken into account:
The mask used in CRM has to fit to the mask used in R/3.
In the Marketing Element the flag ‘Create WBS Element’ has to be set.
The fields transferred from the CRM marketing element/project to the R3 WBS element are:
identification, description, plan start date, plan end date, actual start date, actual end date.
With transaction SMQ1 and SMQ2 the outbound and inbound RFC queues can be monitored. The
queue name starts with CSAMKTPL*. Alternatively the queues and data transmission between the
CRM and the R/3 system can be monitored with the Middleware Portal (SMWP). Investigate the cause
for those queues in status stopped.
The related mBDOC for transfer of Marketing Elements to R/3 system is MKTPL_MKTELEM.
7.2.1.8 Business Process Step 11: Execute campaign
After building up a target group, having it assigned to a campaign and releasing the campaign by
changing its status, it can be executed. Therefore a communication channel has to be defined which is
used to communicate to the customer. Possible channels are email, phone, leads, activities or open
channel (BADI implementation). Execution of the campaign means to plan report
CRM_MKTTGGRP_EXPORT_BATCH which will transfer the BP of the segment to the chosen
channel and will trigger followon processing, which can be to generate emails, generation of a calling
list, creation of OneOrder objects (leads, activities etc.) or transfer to open channel (an example
implementation for the open channel can be found by note 672599).
There are two possible options, which people or organizations from the marketing segments should be
addressed. This is the B2C scenario (Business to Consumer) or the B2B scenario (Business to
Business). In B2C a person can be contacted using their private address, in B2B the person to be
contacted is a contact person within a company, so it is contacted using the business address.
The execution of the campaign can be started synchronously or in parallel. In this case servergroups
have to be set up. This can be done in RZ12.
During execution target group, campaign and contacts could be written into its related BW queues.
Monitoring Object Monitor Monitor Indicator Monitoring Respon
TA/Tool Freq. or Error Activity or sibility
Error
Handling
Procedure
Report SM37 After Status Analyze error User /
CRM_MKTTGGRP_EXPORT_BATCH execution message Application
monitoring
© 2005 SAP AG 99

Error
Handling
Procedure
team
Marketing Element log Marketing After Status Analyze error User
Planer execution message
During the campaign executions, the system writes messages which can be displayed in the log of the
respective execution. These messages are supposed to allow a more transparent view to the
execution.
For channel letter no print outs are done. In this case check the customizing of the printer in
transaction SPAD. During campaign execution printing is done in background, therefore ‘Acc. Method’
on tab 'Access methods' could have all settings except F (Printing on Front End Computer). If F was
selected, the printouts are put into the spool. In this case you can start the printout manually in SP01
(please see note 681104.)
All generated contacts can be tracked by table CRMD_IM_ML_ITEM (consulting note 702996):
Possible status are
· 0 = Contact Achieved
· 1 = Contact Not Possible (Missing Communication Data)
· 2 = Contact Not Possible (Incorrect Communication Data)
Communication data of the business partner is incorrect.
· 3 = Contact Not Permitted (Max. Usage BP List)
Check for maximum usage of the business partner within a business partner list with
External List Management (ELM).
· 4 = Contact Not Permitted (Block Indicator for BP)
Indicators checked: donotuse / donotcontact / to be archived / central block
· 5 = Contact Not Possible (Technical Problems)
Example: If the email to a business partner is blank and thus cannot be sent or if the email
server does not return any confirmation.
In case of performance problems during campaign execution (or terminated jobs due to runtime)
parallelization could be a solution. Note 524647 provide internal benchmarks, which performance
improvements are possible.
Further performance improvements are described by notes 672260 (Enhancement of index).
7.2.1.9 Business Process Step 12: Generate call list for CIC
If channel telephone was chosen, the execution of the campaign will generate a call list for Customer
Interaction Center (CIC). This call list can be assigned to an organization unit or to a telesales agent.
Afterwards the business process Outbound Call of CIC can be executed.
The monitoring and error handling procedure is according to step Execute Campaign.
7.2.1.10 Business Process Step 13: Generate lead
If channel lead was chosen, the execution of the campaign will generate leads. They facilitate the
company’s chance to make business and qualify the level of interest presented by business partners.
With the help of leads, a streamlined link between marketing and sales can be provided, so as to
accelerate the process between first interest and sales. Leads do not provide complete details of
potential business opportunities, but they can help to find out more about a potential business.
The monitoring and error handling is similar to step Execute Campaign.
© 2005 SAP AG 100
7.2.1.11 Business Process Step 14: Generate personalized email
Predefined email forms can be assigned to individual marketing elements. These forms are used to
create personalized emails for individual target groups. Personalized emails can be sent from within
the CRM Marketing Planner using the Job Wizard in background. Beforehand the functionality can be
tested in marketing planner on tab ‘Channels’. The marketing emails are sent to all business partners
in the target group assigned to the marketing element. The mailing is performed through SAP Office.
For each created email an activity with status closed can be created.
Monitoring Monitor Monitor Indicator Monitoring Activity or Responsibility
Sending of SOST and Daily Status See below Application monitoring
emails SCOT team
CRM_MAIL SLG1 Daily Error Check message Application monitoring
status team
Email CRMD_EMAI Daily See below User
contact L_LIST
During the campaign executions, the system writes messages which can be displayed in the log of the
respective execution. These messages are supposed to allow a more transparent view to the
execution. For reasons of clearness, the system does not display all messages in the log of the
Marketing Planner. Messages during execution can be found in transaction SLG1 for object
CRM_MAIL.
A more general view about the created emails provides transaction CRMD_EMAIL_LIST. The number
of mails which were sent can be seen.
Sample note 694313 provides further information for common problems with emails (graphics in faxes,
sending of URLs, URL tracking, restriction of email title, attachments…).
Transaction SCOT provides SAP Connect administration. Via View/Jobs you can check the status of
jobs which were scheduled for report RSCONN01 for send processes.
Transaction SOST will provide an overview about sent requests and its status. Depending on the
selection criteria chosen, the program displays send requests that are sent or have already been sent
using SAP Connect.
A reorganization of entries of SOST is possible by reports RSSORE00 or RSBCSRE03. Documents
will be deleted from the Business Workplace and associated send entries will be deleted from the SAP
Connect status overview. The objects are only deleted if there are no references to these objects, that
is, if the document is not stored in a folder by the user. This could also be a background folder or the
outbox of a background user, under whose name the documents were sent.
Reports RSSORE00 and RSBCSRE03 should be scheduled every 12 week. Note 728063 (SAP
Office: Reorganization as of 6.10) provides detailed information about these reports and useful others
(as RSSODLIN (Deletion of inbox entries for individual users), RSSOTRCL (Deletion of shared trash),
and RSSODLWF (Deletion of workflow). Also the reports RSSORESN (Reorganization of successful
send operations) and RSSORE00 (physical removing out of database after deletion of mails) should
be scheduled regularly.). Related component to this topic is BCSRVCOM.
In case of performance problems during parallel mailing please check according to note 610923, if you
transfer the email address of the sender via the 'Email address' field on the 'Channel' tab. Instead
please use a dummy business partner as sender.
If wrong business partners are contacted or some could not be contacted according to missing
addresses, please check note 518671 for details of contact person determination.
© 2005 SAP AG 101
7.2.1.12 Business Process Step 15: Generate activities
Activities can be generated for each channel (email, telephone…) when executing a campaign to get a
complete story for a particular customer. They are created with status closed to document, that a
certain kind of contact has been taken place.
Alternatively interaction objects can be created, which only contain the most important information
about the outbound contact and therefore optimize performance.
For the creation of activities the monitoring and error handling procedure is according to step Execute
Campaign.
Additionally note 544916 CRM Marketing: One Order generation during campaign will provide a
detailed explanation which kind of business partner can be determined in a created OneOrder
Objects.
7.2.1.13 Business Process Step 16: Update activities
Created activities can be extracted to BW after creation. Therefore the have to be written into a delta
queue and a regular scheduled report from BW has to get the data from this queue.
Monitoring Object Monitor Monitor Indicator Monitoring Activity or Responsibility
TA/Tool Freq. or Error Error Handling Procedure
Datasource RSA7 daily Status Investigate the cause & try to Application
0CRM_SALES_ACT_1 restart the hanging queues monitoring team
Queue CRM_BW* SMQ1 daily Status Investigate the cause & try to Application
restart the hanging queues monitoring team
Infopackage for RSA1, daily Red Check error message Application
datasource RSMO in status monitoring team
0CRM_SALES_ACT_1 BW
Transaction RSA7 provides the overview about the delta queue and shows each single delta record to
be transferred. Via RSA3 the data to be extracted can be simulated.
FAQ note 692195 will provide answers for common problems with data extraction between CRM and
BW (no delta extraction, performance problems during extraction, difference between RSA3 and delta
extraction).
As described in note 666635, CRM_BWA* queues should be deactivated, as there are only set up for
testing reasons.
The initial and delta load will be planned from BW with transaction RSA1. An InfoPackage has to be
set up to specify, which datasource at which time should be checked against new data. Monitoring
transactions RSA1 resp. RSMO provide an overview about the status of data transfers for the certain
objects.
For further information regarding the interaction with BW can be found in the generic part.
© 2005 SAP AG 102
7.2.2 Trade Promotion Management (TPM)
The following diagram shows the steps performed in this business process. Depending on the
configuration carried out in your project, some elements might appear different from the description in
this document.
Process Workflow for Trade Promotion Management
Trade promotions are marketing activities specific to the consumer goods industry which take place
within a defined period of time. The aim of these activities is to boost brand capital, brand profile and
market share, increase sales or position new products/product pallets on the market.
Trade promotions facilitate strategic and tactical marketing and sales revenue planning and enable the
implementation, validation and analysis of promotion strategies such as features, displays and
temporarily reduced prices. The marketing planner is a platform for planning, maintaining, tracking and
evaluating all merchandising activities which take place between a company and its retailer.
Trade promotions have the same structure as all other marketing projects, for example marketing
plans or campaigns (see business process Marketing Planning and Campaign Management).
However, they differ from these in that they are targeted at a particular key customer for whom certain
conditions can be created to support the promotion.
The promotion can be created via the Marketing Planner or the Marketing Calendar. Within the
Calendar at first a query has to be executed. A new trade promotion can be created for the
appropriate time frame. When saving, its hierarchy is updated to BW directly.
The plan uplift quantities for products, key figures from SEM can be used. Planning is done during the
next step in the promotion; the figures are updated to SEM automatically.
After planning conditions are generated in the promotion which should be found in sales orders if the
customer orders the negotiated products. Therefore during saving the conditions are updated to R/3.
The planned uplift quantity is transferred to SAP APO directly during saving. In a later step, these
quantities can be used for demand planning.
To collect costs for a marketing element, it can be transferred to R/3 in a separate step. Afterwards an
account element is created in R/3.
© 2005 SAP AG 103
7.2.2.1 Business Process Step 1: Execute query in marketing calendar
The marketing calendar is designed to act as a central entry point and to provide a working area that
gives an overview of all promotional events within a certain time range, providing basic information,
such as the name of the promotion, status and time range in the form of bars. It also allows to create
new promotions or campaigns by creating a bar directly in the appropriate time range and to
reschedule any planned activities by moving these bars around to a more appropriate time slot.
A query is created in the marketing calendar (transaction CRM_MKTPL_CALENDAR) to define criteria
for displaying marketing projects from several perspectives or viewpoints; for example, by brand,
customer, or product group.
For the query no special monitoring has to be performed. In case of missing information for deal in
marketing calendar note 687328 provides information, how customizing has to be set up.
7.2.2.2 Business Process Step 2: Create trade promotion
An existing trade promotion can be used as a template to create a new one. Alternatively it can be
created newly or based on a deal. A deal is a set of promotional constraints that are applied to a pre
defined set of customers for predefined products. They are created and maintained in CRM
Enterprise.
Data to be maintained for a trade promotion are customer, planning profile group, sales organization,
dates and other. Additionally a product or a group of products (category, hierarchy, and group) can be
assigned.
The trade promotion can be created either in CRM Enterprise or on Mobile Sales and can be
exchanged with each other.
sBDOC SMW01 Daily Status F01 Check error message Application
CAMPAIGN_WRITE monitoring
team
mBDOC SMW01 Daily Status E01 Check error message Application
MKTPL_MKTELEM monitoring
team
BDOC CAMPAIGN_WRITE can be used for intelligent subscription of trade promotions to clients and
can be monitored in transaction SMW01. Note 625903 describe how intelligent subscription in
transaction SMOEAC has to be set up.
7.2.2.3 Business Process Step 4: Plan key figures
Key figure planning from SAP BW/SEM is fully integrated with CRM 4.0 to allow planning using the
Marketing Planner as a basis. There is the option of carrying out key figure planning using an ALV grid
or Excel sheet or in HTML. This option gives additional features, allowing synchronizing dates,
products, target groups, sales organizations, customers, success measures, trade spends, EEW
enhancements and currencies. This can all be done directly from the Marketing Planner. The technical
basis for planning is the planning processor of SAP SEM, so the planning data is edited directly in
SAP BW.
There are in total 5 tabs in the marketing planner, which support key figure planning: Key Figures,
Success Key Figures, Trade Spends/Volumes, Costs and Analyses. On the first one there is the
option of planning on both the business partner and the product. On the Trade Spends/Volumes tab
forecasting can be carried out to plan uplift sales volume and sales deduction.
SAP CRM updates the master data for the marketing elements to SAP BW automatically during
saving by RFC, so that no extractor has to be used.
© 2005 SAP AG 104
Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Respon
Object TA/Tool Freq. Error Handling Procedure sibility
Marketing Marketing Planner During Error message Check message User
element CRM_MKTPL creation
SAP SEM collects all planning errors in a log. Errors that occur when the planning system is called up
are logged in the marketing planner directly.
7.2.2.4 Business Process Step 6: Generate conditions
In key figure planning, the trade spends for products, product groups or product categories are
determined. Condition generation then converts this trade spends to condition records. There are two
types of conditions possible: price determinationrelevant conditions and a condition for campaign
determination.
The first ones of usage PR (price determination), BO (rebate agreement) or FG (free goods) control
price determination when the trade promotion is executed. The system creates these condition
records when the condition generation on the Trade Spends/Volumes tab is started. Afterwards they
can be changed on tab Discounts.
The latter condition type is of usage CD (campaign determination) and controls campaign
determination when the trade promotion is executed. Campaign determination is required so that price
determination takes campaignspecific condition records into account. The system creates this
condition record automatically when the trade promotion is released.
When saving the promotion, both types of records can be transferred to SAP R/3 and to mobile
clients. They are automatically active and do not have to be released separately.
mBDOC SMW01 Daily Status Check error message Application
CND_M_SUP monitoring team
sBDOC SMW01 Daily Status Check error message Application
CNBCCP* monitoring team
With BDOC CND_M_SUP the condition records are transferred to R/3, with sBDOC CNBCCP* (i.e.
CNBCCPSAP040 for condition table A040) the conditions are transferred to the clients. These BDOCs
can be monitored in SMW01.
7.2.2.5 Business Process Step 7: Update uplift sales quantity
The planning of trade promotions can be included in Demand Planning (DP) and Supply Network
Planning (SNP) in SAP SCM. When the planning data is saved, the data is transferred to SCM, where
a promotion is created.
Monitoring Object Monitor Monitor Indicator Monitoring Activity or Respon
TA/Tool Freq. or Error Error Handling Procedure sibility
mBDOC SMW01 daily status Check error message Application
MKTPL_MKTELEM monitoring
team
Marketing Element Marketing After Message Check message User
Planner log creation
Queues SMQ1 daily stopped Check queue status Application
© 2005 SAP AG 105

CSA_MASS_MKTPL, monitoring
CSA_MKTPL*, AI* and team
CRM_MKTPL_APO_INT
If any errors occur during replicating to APO, these errors can be checked in the Marketing Planner via
Extras > Logs > APO Integration.
The transfer to APO is handled by BDOC MKTPL_MKTELEM. Its status can be checked in SMW01.
7.2.2.6 Business Process Step 10: Transfer account object
A connection between mySAP CRM and the SAP R/3 System is set up when actual costs or revenues
for the trade promotion should be entered and settled to Profitability Analysis.
When the trade promotion is created in the Marketing Planner, it can be transferred to the R/3 project
system manually or automatically, once a status allowing transfer is assigned. Manually transfer
means to execute the transfer manually directly from Marketing Planner, automatically transfer means
via middleware when saving the object. For the manual transfer the consistency can be checked in
advance directly in the Marketing Planner.
Transfer to R/3 Marketing After Status Check error message User
Planner manual
transfer
BDOC Middleware Daily Status Check error message Application

MKTPL_MKTELEM monitoring monitoring
SMW01 team
Queue CSAMKTPL* SMQ1 Daily Status Check queue status Application

monitoring
team
Within the marketing planner, via Extras > Logs > R/3 Integration logs can be found.
For a successful transfer the following points have to be taken into account:
The mask used in CRM has to fit to the mask used in R/3.
In the Marketing Element the flag ‘Create WBS Element’ has to be set.
The fields transferred from the CRM marketing element/project to the R3 WBS element are:
identification, description, plan start date, plan end date, actual start date, actual end date.
With transaction SMQ1 and SMQ2 the outbound and inbound RFC queues can be monitored. The
queue name starts with CSAMKTPL*. Alternatively the queues and data transmission between the
CRM and the R/3 system can be monitored with the Middleware Portal (SMWP). Investigate the cause
for those queues in status stopped.
The related BDOC for transfer of Marketing Elements is MKTPL_MKTELEM, which can be monitored
in SMW01.
© 2005 SAP AG 106
7.2.3 Business Partner Segmentation
Depending on the configuration carried out in the customer’s project, some elements might appear
different from the description in this document.
Process Workflow for Business Partner Segmentation
To communicate with customers in a purposeful manner, it must be known who the customers are,
and which kind of interests and purchasing behavior the have. The existing marketing data on
business partners therefore makes a valuable contribution when modeling target groups for marketing
activities. Dividing customer master into different groups is called customer segmentation, and
depends to a great extent on the planned marketing activity. The segments created can then be
processed in different ways, according to the particular needs and preferences of the business
partners they contain.
Target groups can be created from a variety of different data sources by combining selection criteria
obtained, for example, from InfoSet queries, BW queries, business partner master data and from
acquired address lists. Therefore in first steps either marketing attributes, (which are grouped to
attribute sets) InfoSet queries or BW queries have to be created. In a second step they are the basis
of a datasource, which can later on be assigned to an attribute list.
The attribute list can be used in the segment builder to create at first a profile set, related profiles and
for them target groups. If attributes based on InfoSet query or BW query are used, the query is
executed directly in the appropriate backend system or in BW system.
In a next step target groups may be attached directly to marketing campaigns. From the CRM
Marketing Planner, the business partners in the target groups can be contacted by a variety of
channels including SMS, email, and telephone. This is described in Business Process ‘Marketing
Planning and Campaign Management’.
There are also the options of contacting target groups directly without reference to a campaign,
extracting them into a file for further use or creating business transactions for the BP directly. All these
steps can be performed directly from the Segment Builder.
7.2.3.1 Business Process Step 1: Create marketing attribute
Attributes are used as criteria for differentiating between business partners. They can be used to
perform individually tailored marketing activities. Attributes can be created manually or by using a
template in transaction CRMD_PROF_CHAR.
© 2005 SAP AG 107
When the attribute is saved, it can be subscribed to the clients via BDOC. If the subscription to the
clients is not necessary, it can be prevented by means of note 711267. In this case the mobile bridge
should be deactivated for the relevant BDOC CHAR_MSG by transaction SMW3_00.
Marketing attributes can be extracted to BW by datasource 0CRM_MKTATTR_ATTR.
mBDOC CHAR_MSG SMW01 Regularly Error Check error message Application
status monitoring
E01 team
sBDOC Attribute SMW01 Regularly Status Check error message Application
F01 monitoring
team
Datasource RSA7 Regularly Status Investigate the cause & try to Application
0CRM_MKTATTR_ATTR restart the hanging queues monitoring
team
Infopackage for datasource RSA1, Regularly Status Check error message Application
0CRM_MKTATTR_ATTR RSMO in monitoring
BW team
mBDOC CHAR_MSG and sBDOC ATTRIBUTE belong to marketing attributes. BDOC monitoring
should be done by transaction SMW01. If there are error messages for the related BDOCs, this can be
due to differences for attributes in CRM Online and in CDB.
Report CRM_MKTMSA_ATTRIBUTE_DELTA of note 591183 compares the data in Online tables and
CDB tables (CABN, CABNT, CAWN, CAWNT and SMOCABN*, SMOCAWN*) and generates BDOCs
when necessary.
Transaction RSA7 provides the overview about the delta queue and shows each single delta record to
be transferred. Via RSA3 the data to be extracted can be simulated.
The initial and delta load will be planned from BW with transaction RSA1. An InfoPackage has to be
set up to specify, which datasource at which time should be checked against new data. Monitoring
transactions RSA1 resp. RSMO provide an overview about the status of data transfers for the certain
objects.
7.2.3.2 Business Process Step 2: Create attribute set
An attribute set is used to group attributes created specifically within CRM Marketing together for a
marketingrelated purpose in transaction CRMD_PROF_TEMPL.
When saving the attribute set, it can be subscribed to the clients via CDB.
If the subscription should not be possible (mobile clients are not used), BDOC PFTPL_MSG can be
disabled in transaction SMW3_00 according to note 711267.
Attribute sets can be assigned to business partner master data in transaction BP. Afterwards each
attribute can be specified for the business partner. This attribute specification can be transferred to the
clients as well.
mBDOC SMW01 Regularly Status E01 Check error message Application
PFTPL_MSG, monitoring
MKTPROF_MSG team
and
CHARVAL_MSG
sBDOC CLASS SMW01 Regularly Status F01 Check error message Application
OBJCLASS, monitoring
© 2005 SAP AG 108

OBJCHARACTERIS team
BDOC monitoring should be done by transaction SMW01 (please refer for general information to the
generic chapter).
mBDOC PFTPL_MSG and sBDOC CLASS belong to an attribute set, mBDOC MKTPROF_MSG and
CHARVAL_MSG and sBDOC OBJCLASS and OBJCHARACTERIS belong to BP specification.
If you find errors in BDOC processing in SMW01, several check reports should be started in order to
find possible inconsistencies between online and the client.
The relevant check report for attribute sets is CRM_MKTMSA_ATTR_SET_DELTA (note 591186). It
will generate new BDOCs, if there are differences for tables KLAH, KSML, SWOR, KLAT and CDB
tables SMOKLAH, SMOKSML, SMOSWOR und SMOKLAT.
The relevant check reports for BP specification on CRM Online and the clients are mentioned in note
591233.
· First, you should check whether all notes from sample note 545391 have been implemented in
the system. If this is not the case, it is absolutely necessary that you implement them. If you
have not implemented any of the notes, differences may have occurred. Therefore, you should
carry out an initial download in R3AS if possible (refer to note 545391). If an initial download is
not possible, execute the following reports. In this process you must make sure that no
BDOCs are generated on CRM server or Mobile Sales side at this time.
· Start report CRM_MKTMSA_CHECK_KSSK. You should start this report in your system every
night because empty BDOCs of Mobile Sales may cause unnecessary records in table
SMOKSSK.
· Start report CRM_MKTMSA_CHECK_AUSP.
· Start report CRM_MKTMSA_CHECK_SMOKSSK.
Depending on the auxiliary table in which entries can be found, you must start the following reports:
· If there are entries in table CRMD_MKTMSA_CH5, create a SAPNet R/3 Frontend message.
· If there are entries in tables CRMD_MKTMSA_CH4 or CRMD_MKTMSA_CH7, start report
CRM_MKTMSA_DELETE_SMOKSSK.
· If there are entries in table CRMD_MKTMSA_CH2, start report
CRM_MKTMSA_DELETE_SMOAUSP.
CRM_MKTMSA_UPDATE_SMOAUSP.
CRM_MKTMSA_UPDATE_SMOKSSK.
· If there are entries in table CRMD_MKTMSA_CH3, create a SAPNet R/3 Frontend message.
Then restart the three check reports. If the tables still contain entries, create a SAPNet R/3 Frontend
message. When you execute the check reports, it is absolutely necessary that no activities concerning
marketing attributes occur in CRM Online. BDOCs must not be posted at this time either.
7.2.3.3 Business Process Step 3: Create infoset query
InfoSets are used for segmentation to access business partner master data (stored for example in the
R/3 System). Therefore the Infoset must make its selections using fields relating to the business
partner and must be able to return business partner keys. Ideally these keys are GUIDs. If this is not
possible (for example because this Infoset lies in a system in which the GUID is not known, such as
an SAP BW or an SAP R/3 System) then it must be a key that can be converted into a GUID in CRM.
Infosets in CRM are created by transaction SQ02 and should be created for the global work area. The
query can be tested in SQ01.
© 2005 SAP AG 109
SAP provides additionally a lot of standard InfoSets covering many of the queries most useful for
marketing purposes.
There is no special monitoring for this step.
7.2.3.4 Business Process Step 4: Create BW query
BW queries are used to access transactional data stored in the SAP BW System. The BW query can
be tested in RSRT on BW system.
To ensure the best possible system performance, try where possible to avoid:
· Unnecessary characteristics, attributes, or key figures
· Superfluous conditions or variables
· Complex key figures
· Large cubes
· Complex hierarchies
· A lot of coding in variables filled by means of user exits
In addition, specify for characteristics either variables or restrictions but not both together.
Restrictions for the usage of BW queries for segmentation are described in note 605208.
7.2.3.5 Business Process Step 5: Create data source
A data source describes the origin of attributes used to create attribute lists. Data sources can be
created in transaction CRMD_MKTDS by help of Data Source Wizard. 4 different origins are possible:
attribute sets, BW queries, Infoset queries and External List Management.
A RFC destination for a data source should only be maintained if data is taken from an external
system!
Errors during creation of a data source are shown in the transaction itself. There is no separate
monitoring transaction, error messages are shown directly.
7.2.3.6 Business Process Step 6: Create attribute list
Attribute lists are lists of selection criteria used in Segment Builder for modeling marketing profiles.
These selection criteria can derive from one of the following data sources as described in the last
steps:
· Business partner master data (obtained by Infoset queries)
· Marketing attributes (grouped together as attribute sets)
· Key figures and attributes from the BW (obtained by BW reports)
· External List Management
The maintenance transaction is CRMD_MKTDS. There is no special monitoring transaction, error
messages during creation are shown directly.
7.2.3.7 Business Process Step 7: Create profile set
A profile set consists of individual marketing segments profiles, target groups and other profile sets
which were modeled together and which are to be interpreted together. The profile set is created in
Segment Builder based on attribute specification.
7.2.3.8 Business Process Step 8: Create profile
Profiles are used to describe marketing objects. In the Segment Builder, profiles are modeled by
combining selection criteria from different sources with a view to create specific target groups. So a
profile is a semantic description of a target group in terms of the selection criteria used to create such
© 2005 SAP AG 110
a group. All of the selection criteria within the profile must be met before a business partner matches
the profile.
7.2.3.9 Business Process Step 9: Create target group
A target group is a list of business partners that have been combined for a specific marketing activity.
A target group can be created by executing the selection conditions for a marketing profile directly in
the Segment Builder.
Other possibilities are the independent creation by importing a list of business partners from an
external system and the selection of target groups in the BW system (transaction rstg_bupa) to create
them from there directly in CRM.
The creation of a target group can be scheduled as a (periodic) background job ‘TARGET GROUP
SELECTION’ (program CRM_MKTTG_TG_SELECTION).
Target groups can be extracted to BW, but only during campaign execution (note 717539). For this
purpose datasource 0CRM_CONTACT_IN can be used. Further information regarding campaign
execution can be found in business process Marketing planning and Campaign Management.
Monitoring Object Monitor Monitor Indicator Monitoring Responsibility
TA/Tool Freq. or Error Activity or
Error Handling
Procedure
Program SM37 daily Status Check job log Application
CRM_MKTTG_TG_SELECTION monitoring team
If target groups are created by a background job, transaction SM37 should be used to monitor
program CRM_MKTTG_TG_SELECTION.
In case of performance problems for target group creation directly in Segment Builder please refer to
note 538984, which is a sample note for all known issues.
7.2.3.10 Business Process Step 12: Export target group
Three different further processing steps can be performed for a target group, which need no reference
to a campaign.
The function Export target group is used to export the business partner data for a target group to a file,
in order to process this data further at a later date, or simply for storage purposes.
Error
Handling
Procedure
Report SM37 Daily Status Check job log Application
CRM_MKTTG_PROC_TG_FEXP_B monitoring
ATCH team
Report CRM_MKTTG_PROC_TG_FEXP_BATCH is used for export to the application server. This
report can be monitored by transaction SM37. Please check the status of the job. Possible errors can
be found in the job log.
© 2005 SAP AG 111
7.2.3.11 Business Process Step 13: Transfer target group to channel
With this function the target groups can be sent directly to the desired communication channel without
going via a campaign (as described in business process Marketing Planning and Campaign
Management).
Before sending, the communication data is checked. Only those business partners with correct
addresses are contacted. This check is not used for the open channel.
In the SAP GUI there is the option to trigger the sending of several target groups to the corresponding
channel simultaneously.
If button Generate Contacts is chosen in the SAP GUI, a contact is created for every single business
partner.
Monitoring Object Monitor Monitor Indicator or Error Monitoring Respon
TA/Tool Freq. Activity or sibility
Error Handling
Procedure
Program SM37 Daily Status Check Job Log Application
CRM_MKTTG_PROC_TRANS_BATCH monitoring
team
Program CRM_MKTTG_PROC_TRANS_BATCH is used to transport to the target group to channels
without campaign reference. This program can be monitored with transaction SM37. In the job log
possible errors can be found.
7.2.3.12 Business Process Step 14: Create business transactions
This function can be used to generate business transactions contact, task or lead for the members of
the target group directly from the Segment Builder. Different fields (transaction type, priority, period,
person responsible, and product) can be filled, depending on which transaction is selected.
Error Handling
Procedure
Program SM37 Daily Status Check Job Log Application
CRM_MKTTG_PROC_ORDER_B monitoring
ATCH team
7.2.3.13 Error Handling, Restartability, and Escalation
Program CRM_MKTTG_PROC_ORDER_BATCH is used to create the chosen business transaction
for the target group. This program can be monitored with transaction SM37. In the job log possible
errors can be found.
© 2005 SAP AG 112
8 Generic Part
In the Generic Part of this Business Process Management Best Practice you will find information
regarding those steps and processes that are common to several CRM scenarios. The following topics
are covered:
· Availability Check
· Connection to SAP Business Warehouse (BW)
· BDoc Monitoring and Handling
· RFC Monitoring
· Performance Monitoring
· Batch Jobs
· Mass Data Changes
These sections are referenced in the corresponding business process steps of the scenario specific
parts above.
8.1 Availability Check

The Availability check topic of the CRM Generic Part of this document deals with those steps involved
in the availability checking process, that are common to the interaction center, field sales and eselling
scenarios.
When a sales order is entered in the Customer Relationship Management (CRM) System, it may be
important for the customer to know whether the products are available and can be delivered on time.
The system can activate an availability check and scheduling for each line item of the sales order or
quotation. In order to confirm whether the requested items can be delivered on time, the following
functions need to be carried out:
· AvailabletoPromise (ATP) availability check
· Delivery Scheduling
· Transportation Scheduling
These functions are carried out, every time a customer order or quotation is created or changed and a
date for the delivery is specified, either by the R/3 system or by the mySAP Advanced Planner and
Optimizer (APO) System, which is the SAP system used for Supply Chain Management.
· Check availability in APO
The following basic methods of availability check used in SAP APO are supported in CRM Enterprise:
Product Availability Check and Rulesbased Availability Check.
The confirmed amounts are reserved in the APO system. The requests are transferred to production or
purchasing, when the sales order is saved in CRM online. After the availability check, details for each
item are transferred back to CRM Enterprise, such as: Delivering country (for tax reasons) and region
(U.S.), confirmed quantities, confirmation dates, globally unique identifier (PosGUID or GUID used
for requirements in SAP APO) and the item category usage
8.1.1.1.1 Automated monitoring via Solution Manager
Procedure
APO Log SolMan Weekly # errors < 1 Errors or Check for the reason of Application
and upon warnings the error in the log. monitoring team
error
For details on the APO Demand Planning application log and the monitoring setup procedures
use the following link http://service.sap.com/~sapidb/011000358700003081072005E and
navigate to section 2.2.
© 2005 SAP AG 113
· Check availability in R/3
The product availability check using the R/3 system gives your customers information on the latest
availability situation. Temporary reservations are made. The confirmed data and the delivery date with
the available amount are shown on the item level to customers when transferring a product into the
shopping basket.
If you carry out material requirements planning in SAP R/3 Enterprise (SAP R/3), you can carry out
availability check in the business transaction in CRM Enterprise using SAP R/3. This function is
supported for SAP R/3 4.6B and higher. The functions are similar to those used when you carry out an
availability check using SAP APO. The system transfers requirements to production or purchasing,
reserves stock and carries out scheduling for delivery and transportation. SAP R/3 transfers the results
of the availability check back to the business transaction in CRM Enterprise. The confirmed data and
the delivery date with the available amount are then shown on item level.
You can use the following processes in SAP R/3 in combination with availability check using SAP R/3:
Transportation and shipment scheduling to determine the material availability date, followup activities
such as outbound delivery and goods issue, product allocation and backorder processing. For
backorder processing the system however does not set the order status to Rescheduled, as is the
case when you carry out availability check with SAP APO.
8.1.1.1.2 Error handling
In case of problems you can run an ATP simulation to check whether ATP works correctly. If you
check the availability in R/3 you can perform a simulation in R/3 using transaction CO09. if your
availability check is done in APO transaction AO09 can be used in the APO system accordingly – in
CRM a dummy sales order should be created to compare both.
If the displayed available amount for a product is equal to zero, it means in normal operation
conditions that there is no stock in the warehouses, but it could also be an error. As well, if there are
any doubts regarding the given quantity, proceed as follows:
Availability Check done in R/3: Check the availability for that product with transaction CO09 in R/3. If
the result differs from zero, this indicates a functional error within the availability check in CRM. We
recommend opening a SAPNet message for further investigation.
Availability Check done in APO: Check the availability for that product in the APO system with
transaction /sapapo/ac04. If the result differs from zero, this indicates a functional error within the
availability check in CRM. We recommend checking the customizing and if the issue still occurs, you
should open a SAPNet message for further investigation.
If you are using an APO system, we also recommend you to check the following documents for APO
specific monitoring:
Monitoring and Administration for SCM / APO helps you analyzing the workload and
performance on liveCache and the APO database (APO specific monitoring (life cache,
optimizers, APOR/3, regular jobs)).
Manage APO Core Interface in SCM deals with the Business Process Management of the
APO CIF and is an essential enhancement to this document. All the jobs and monitoring
activities listed in the CIF document have to be considered in every business process step that
sends or receives data through CIF.
Manage the Global ATP Service, this procedures ensures the smooth and reliable flow of the
Global ATP service, independently of the core business process that uses the Global ATP
service
System Monitoring for SAP APO / mySAP SCM, explains how you can use the comparison
program CIF_DELTAREPORT to achieve data consistency between SAP Advanced Planner
and Optimizer (APO) system of release 3.0 and 3.1, and your other R/3 systems that use APO
services
This documents can be found in the service marketplace.
Monitoring and Administration for SCM / APO (PDF)
Manage APO Core Interface in SCM (PDF)
Manage the Global ATP Service (PDF)
System Monitoring for SAP APO / mySAP SCM (PDF)
© 2005 SAP AG 114
8.2 Connection to SAP Business Warehouse (BW)

8.2.1.1 Business Process Step: Update Information to BW system
Relevant key figures of the business processes are passed from the CRM system to the SAP
Business Information Warehouse (SAP BW). With this information the SAP BW can analyze e.g. the
success of the business process on the basis of generated analysis objects.
Apart from safeguarding the general availability of the BW System and the CRM server SAP
recommends to monitor the objects listed in the following table in order to ensure the business step
Update Information to BW system.
Monitoring Monitor Monit Indicator or Monitoring Activity or Responsibility
Object TA/Tool or Error Error Handling Procedure
Freq.
ST03, Daily Long times Monitor RFC Statistics, see Application
Performance STAD (>1000 ms also the section performance monitoring team
per line item) monitoring
BDocs smwp Daily Red light at Investigate the cause Application

(CRM) Bdoc level monitoring team
Queues smwp, Daily Queues are Investigate the cause & try to Application

smq1, rsa7 stopped restart the hanging queues monitoring team
(CRM)
Infopackages rsa1 (BW) Daily Red light at Investigate the cause Application
Infopackage monitoring team
Monitor
Monitoring Monitor Monitor Threshold Indicator or Error Monitoring Responsibility
Object TA/Tool Freq. Activity or
Error Handling
Procedure
Background SolMan Daily To be set Start and enddelay, Check for the Application
jobs running Out of time window, cause monitoring team
on BW Maximum Duration,
system Cancellation, Parallel
updating processing of jobs, Job
CRM log messages
statistics
· Monitor with the Middleware Portal (smwp) the data transmission between CRM and BW
system. Queues destined for the BW system should be relatively short and quickly processed.
Investigate the cause for those queues in status stopped. Restart hanging queues if possible.
· Monitor regularly the RFC response time statistics with the statistical records monitor (stad),
BW system.
· Monitor regularly the outbound queues in CRM within transactions smq1 and/or rsa7.
· If no entries in the delta queues are created for transactional data, then check if outbound
queues which names begin with CRM_BWA###### (# is a number) do exist in the CRM
system. Activate/restart these queues. After this activation the BW delta queues should be
filled.
· Use the infopackage monitor of the Administrator Workbench (transaction rsa1) in BW to
check whether all infopackages had been uploaded successfully from CRM to BW. If there are
failed requests, then check the logs to investigate the cause of the errors.
© 2005 SAP AG 115
· Use the Extractor Checker (transaction rsa3) in CRM to analyze the extraction from CRM to
BW if necessary. Have a look at note 529789 for explanations if there are differences between
the actual extraction from CRM to BW and the results of the Extractor Checker in CRM.
· If you could not find the cause of the problem with this checklist, then open a SAPNet
message for further investigation.
8.3 BDoc Monitoring and Handling

The flow control for the BDoc messages distinguishes between synchronization flow (sflow) and
messaging flow (mflow). Both flow types are used for inbound and outbound BDoc message
processing. Inbound processing occurs, when a remote system (for example R/3 Backend system)
posts data into the processing system (CRM Server). It can also be used if the CRM posts via
destination NONE to itself. Outbound processing occurs, when the processing system (CRM Server)
publishes or posts data to remote systems (for example R/3 Backend) or to „listeners“ (for example
BW Adapter, Mobile Bridge, Billing Engine). It can also be used if the CRM posts via destination NONE
to itself.
M and sflow consist of different steps, so called flow contexts. A flow context is defined as a
sequence of services, which must be called within this flow context. The inbound flow consists of
inbound flow contexts MI.. (mflow) or SI…(sflow). For outbound flows the contexts are named as
MO… (mflow) or SO..(sflow).
Messaging flow is an infrastructure for passing data to CRMOnline applications, for processing data in
the CRMOnline applications, and for distributing processed data to other destinations [socalled
notifications]. Messaging flow is used in all SAP CRM scenarios.
The following picture gives an overview on the flow contexts:
Inbound processing
Flow Contexts: overview XIF Adapter
BAPI BW Adapter
R/3 Adapter mBDoc
Inbound
qRFC Inbound
sBDoc Adapter Mobile
SI1 MI0
Synchronisation
Flow CRM
Adapter
Outbound processing R/3 Adapter
BAPI BW Adapter Validation

XIF Adapter
mBDoc
Outbound Synchronization flow Mobile Bridge
qRFC SO1, SO2, SO3, SO4
sBDoc SOA, SOB, SOC sBDoc replication
Replication /
Outbound
Adapter Mobile MO1, MO2, MO3, MO4
Realignment
MOA, MOB, MOC
8.3.1 Monitoring
It is important to monitor your system actively (using SMWP, SMW01, SMW02, SMW03) or passively
(using CCMS or flow error handler) and solve issues related to BDoc messages immediately. Critical
© 2005 SAP AG 116
BDoc messages are BDoc messages staying in error or for a long time in temporary status. Not
dealing such BDoc messages can lead to inconsistencies in the CRM system landscape (CRM, CDB,
R/3 backend system, mobile clients).
BDoc messages are composed of:
· Exactly one message header,
· A list of message receivers (Outbound processing),
· A list of validation errors (mFlow inbound processing),
· A message body
· A message extension (mBDocs only), this extension is supposed to hold the transaction data,
whereas the classic part shall only contain fields used in the receiver determination by the
replication component.
· A list of root IDs for each receiver (may be empty),
· A list of receiver specific error information.
When searching for important SAPNet Notes please enter the Bdoc and the status.
The following monitors are available:
8.3.1.1 SMW01
You can display and trace the flow of BDoc messages within the CRM Middleware. You can delete
incorrect BDoc messages, trigger further processing of processed BDoc messages, and display the
recipient list and receiver errors.
Menu path: Middleware Monitoring Message Flow Display BDoc Messages

Transaction: SMW01
a) Analysis
· Search for special error situations per BDoc ID, date, Site ID, message ID
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.
b) Display functionality
· Display the Middleware Trace
Choose BDoc Message > Display > Middleware Trace
· Display the data content
Choose BDoc Message > Display > Display data segments to show the classic part
Choose BDoc Message > Display > Display data extension segments to show the extension
part
Both options are also available as XML output.
· Display a recipient list (internal receivers like CRM and CDB are not shown).
c) Corrective action
· Reprocess failed BDocs (see below)
Choose BDoc Message > Retry to process
Note:
Do not reprocess the BDoc messages without checking of overlapping effects, overwriting
actual data!
· Delete incorrect BDoc messages (PP: was ist eine inkorrekte BDoc message?)
Choose BDoc Message > Display > Display error segments
Choose BDoc Message > Processing > Mark as deleted
Note:
Failed BDoc messages must be analyzed and the errors have to be solved. The non
processing of the error messages will lead to inconsistencies in the system landscape, as the
messages contain updates or new objects that have to be updated in the receiver system.
© 2005 SAP AG 117
Do not delete BDoc messages without solving the problem! Deleting a BDoc message means
that the receiving system(s) will not be updated and thus creating inconsistencies. Only delete
BDoc messages when you are sure that it is obsolete or can be recreated by sending the
application object again.
· Trigger further processing of processed BDoc messages
8.3.1.2 SMW02
Alternatively you can use transaction SMW02 that summarizes BDoc messages and gives a good
overview about the amount of BDoc messages as combination of BDoc type, state, flow context and
receiver (site ID). By doubleclicking on a summary line you will see the single BDoc messages by
calling transaction SMW01.
SMW02 is used to display BDoc messages in an aggregated view on the basis of various criteria.
Menu path: Middleware > Monitoring > Message Flow > Display BDoc Message Summary
Transaction: SMW02
8.3.1.3 SMW03
Display the total number of unprocessed BDoc messages, grouped by BDoc type and client. You can
use this information to check the system status for monitoring purposes, or before you install a support
package.
8.3.2 Usage
Menu path: Middleware Monitoring Message Flow Display unprocessed BDoc Message
Summary
Transaction: SMW03
Procedure:
Enter a client, BDoc type, and BDoc status.
Choose an existing ABAP List Viewer (ALV) layout and click Execute.
There are different reasons for unprocessed BDoc Messages:
Wrong customizing
Missing ‘required’ fields
sBDoc, mBDoc errors
RFC Connectionn problems
MW specific problems
Application specific problem related to data or to customizing
The resolution of unprocessed messages is based on the following actions:
Solve the problem and reprocess the message
Reprocess the BDoc message
Set to processed
Request the data from the reference system and set message status to processed
The following table lists the possible actions to put ‘unprocessed messages’ into a final state:
Function Description
Mark message as Deletes a message, SMW01
deleted/processed
Retry to process message Processes message further, SMW01
Define, start and monitor single R3AR2, R3AR4, R3AR3
requests for load
Synchronize objects R3AS4, R3AM1
Process aborted BDoc SMW20
Messages
© 2005 SAP AG 118
Unlock data in source or target Application
system and repeat
The following table lists the tools and functionalities that are available for analyzing the problem:
Receivers Displays a list of the receivers of a message
Errors Displays error segments
Middleware Trace Displays records for individual steps
Classic Data Data segments of a message
Extension Data Extension of a message (only for mBDoc messages)
Outbound queues SMQ1 (see also outbound queue scheduler SMQS)
Inbound Queues SMQ2 (see also inbound queue scheduler SMQR)
Mobile clients In and Outbound SMQ1, SMQ2 or SMWMQUEUES
Queues
Short Dumps ST22 (+ 15 minutes), select update User
Links Links between messages and object types
8.4 Interface Monitoring

During this chapter the focus will be on the business related data exchange between two or more
systems. In general Interface Monitoring with SAP Solution Manager is possible for the following
Interface Techniques:
ALE/EDI (effective from SAP R/3 4.6C)
qRFC (effective from SAP R/3 4.5B)
tRFC (effective from SAP R/3 4.5B)
Currently only the IDoc and qRFC monitoring is really meaningful from a Business Process Monitoring
perspective. The tRFC monitoring works only generically (all status and all destinations) so that the
assignment to one (graphical) interface within the business process is quite imprecise. The monitoring
of other components (e.g. Internet Transaction Server or Business Connector) works indirectly as
everything that is somehow presented in the CCMS infrastructure can be assigned to one (graphical)
interface.
For further details and the setup information refer to http://service.sap.com/bpm > Media Library >
“Business Process Monitoring Setup Guide”.
8.5 Performance Monitoring

In this chapter you will find the description of a general procedure for performance monitoring of your
CRM system. The different transactions that are mentioned in the procedure are described in detail
below. Please keep in mind that this is general information. For specific recommendations for a
scenario (e.g. for Field Sales or ECommerce) please check the corresponding chapters above.
Please also consider the training BC315 Workload Analysis. This course covers topics like workload
monitor, statistical records, expensive SQL statements, memory management, database monitor and
buffer analysis among others.
© 2005 SAP AG 119
Additionally there is the possibility to monitor the dialog performance in an automated manner using
SAP Solution Manager. As of STA/PI01F it is possible to monitor Dialog Performance not just for the
whole transaction, but also broken down to function code level of a transaction, i.e. specific dialog
steps.
A dialog transaction consists of various dialog steps. A dialog step is usually a screen change within
one transaction. But not all of these screen changes might be equally performance critical. For
example, transaction VA01 can be used to create sales orders. Let’s imagine a customer is
experiencing performance problems for this transaction while saving. During all other dialog steps
(screen changes) the performance is very good. To monitor the performance of the whole transaction
might not be very useful, since the very quick screen changes within the transaction compensate the
long duration of the saving and therefore influence the average response time per dialog step. In order
to just monitor the saving of VA01, you would need to monitor just the dialog steps with function code
‘SICH’ for transaction code VA01.
For detailed information refer to http://service.sap.com/bpm > Media Library > “Application
Monitoring and User Exit Setup Guide”.
8.5.1 General information
As part of the daily monitoring activities of your CRM system you should not only watch system
availability, system resource consumption and middleware queues (among others), but also the
performance of your CRM system. There are several transactions available with which you can
monitor the average performance of the system and analyze the cause for bad performance. Bad
performance of a system is generally equal to extremely high response times. This may be related to
long lasting transactions steps (dialog steps), background jobs running too long, RFC calls taking too
long, etc.
The response time of a transaction step is the difference in time between the point when the request
arrives in the R/3 System and the point when the R/3 System completes the processing. In addition to
this measurement of time, other different times, such as waiting times or database times, are still
measured in R/3. If you substract these components from the response time, this leaves the
processing time which cannot be directly measured. ABAP programming code is processed during the
processing time.
Definitions of the most important components of the Response time:
Time in workprocess Time actually spent in the workprocess (after the dispatcher has found a free
workprocess)
Wait time The dispatcher is waiting for a free work process (= dispatcher queue).
CPU time It is only given as a sum per transaction step in the workload statistics
DB time Time for accessing and waiting for the database interface, and therefore for
the underlying database
Load/Generating time Time for loading/generating screens, ABAP programs, and CUA elements (not
for presentation).
Rollin time Time for rolling in the roll area context of a dialog step
Enqueue time Time for setting a logical SAP enqueue
Processing time This time is calculated as follows:
Processing time = Response time Wait time Load/Generating time DB
time Rollin time Enqueue time
Important: the CPU time should not be added to the above lines, as it is a total, consisting of parts of
the times listed above that cannot be calculated. CPU time is returned by the operating system. The
accuracy of the reported value depends on the timer of the operating system (under UNIX,for
example, the timer works with 100 Hz so that the CPU time is reported as a multiple of 10 ms).
Due to this rough resolution of the CPU time, it is possible that a slightly longer CPU time is displayed
for a dialog step than for the response time.
The RollOut time is not part of the response time, as it only occurs after the data is transferred to the
presentation server.
The Roll wait time is a time in which a work process is waiting for the response of a RFC. The Roll wait
time is a time which is processed on a client whereas the user context is in the roll area. Therefore,
neither resources are used up nor does the bottleneck occur here for high Roll wait time. High Roll
© 2005 SAP AG 120
wait times occur frequently. This may be caused by calls of Windows or other external applications
from within the R/3 System. Here, the application of the RFC is started. The user context enters the
roll areas and roll wait time is processed until the application is exited, that is the RFC connection is
cancelled. Only at this point the transaction step is exited. They also occur when the R/3 System
communicates with the frontend controls. While the data on the frontend are being processed, the R/3
context is rolled out, thus releasing the work process. This can occur several times during a
transaction step. If frontend Office applications such as Microsoft Word are started and closed only
after a long time (several minutes), a very long Roll wait time occurs here also. Roll wait is not part of
the response time for transaction steps of task type RFC. The reason for this is that no resource use
occurs for the application server.
8.5.2 Procedure
The following table gives you an overview of which transaction you can use for what purpose for
performance monitoring and a first analysis of performance problems.
Transaction Trans. Code Use for … Use when?

General performance overview for Daily (e.g. 3 times) and upon
Workload
ST03 the different task types and performance problems
monitor
analysis of system workload
Workload / Detailed performance monitoring of Upon performance problems
statistical STAD a short time frame, a single user or
records a specific transaction or program
SQL trace of a specific step, short Upon performance problems
Performance
ST05 sequence of steps or part of a long with high DB times
trace
running job
Getting an overview of the duration Upon performance problems
ABAP
and performance of the source with high CPU times
runtime SE30
code, from individual statements
analysis
up to complete transactions
8.5.2.1 Key performance indicators
Performance monitoring is most useful if you have previously defined key performance indicators.
Generally speaking Key Performance Indicators are quantifiable measurements, agreed to
beforehand, that reflect the critical success factors of an organization. In this case we refer to the
system response time for single dialog steps of your core business process(es), for transactions or
background jobs. The key performance indicators should be agreed on by the business departments
and the systems administrators (happy medium between was is needed for business reasons and
what is achievable from system side). It is also important to use the right granularity for KPIs. There is
no need to define a KPI for the response time of each and every step in the process, but it important
that they are not defined in a too general way (e.g. less than 2 sec for each dialog step) as this might
be too tight or too wide for specific needs. Furthermore performance monitoring should not only refer
generally to a task type, but should rather go one or to steps further to single transactions or even
steps.
For example: Company ABC is using the call center scenario for inbound calling and also using the
marketing scenario to create target groups via infoset or BW queries. As the call center agents need
very good response times for business partner searches in order to answer a call and the queries for
large target groups may take several seconds, it is not recommended that company ABC just monitors
the average response time for dialog transactions. They should rather do the monitoring on
transaction or even on dialog step level.
Daily monitoring of system performance and the compliance of the response times to the established
KPIs should be done using the workload monitor (transaction ST03). This monitor provides an
overview of the response times and it’s components (CPU time, DB time, Wait time, etc). In case of
performance problems you should use this and other transactions for a deeper analysis:
· If a single user reports problems use transaction STAD to find what part of the response time
is particularly high in his case. Compare it with other users to see if it is an isolated problem.
Continue the analysis depending on the result.
· If a single dialog step (one step within a transaction) has a bad performance, use transaction
STAD to find what part of the response time is particularly high in this case. Continue the
analysis depending on the result.
© 2005 SAP AG 121
· If you have a general performance problem, use the system monitors to check resource
consumptions. Use also the time profile of transaction ST03 to check if performance has been
decreasing over time or if there are peaks. Use the user profile for a comparison among
different users and user groups, if you follow a useful naming convention.
· Get a performance trace (transaction ST05) if you find that the performance problems are
related to high DB times. Get an ABAP runtime analysis (transaction SE30) if you find that the
performance is related to high CPU or high processing times.
· In case you can not find the cause of the performance problem or need further assistance for
the analysis contact the next support level or open an OSS message on component XXSER
TCC.
8.5.3 Transaction ST03
Transaction ST03 is a very powerful transaction with lots of functionalities. Therefore we can mention
here only a few, concentrating on what can be important for performance monitoring. The workload
monitor is used to analyze statistical data from the SAP kernel. When analyzing the performance of a
system, you should normally start by analyzing the workload overview. For example, you can display
the totals for all instances and then compare the performances of individual instances over specific
periods of time. You can quickly determine the source of possible performance problems using the
large number of analysis views and the determined data.
You can use the workload monitor to display the:
· Number of configured instances for each SAP R/3 System
· Number of users working on the different instances
· Distribution of response times
· Distribution of workload by transaction steps, transactions, packages, subapplications, and
applications
· Transactions with the highest response time and database time
· Memory usage for each transaction or each user per dialog step
· Workload through RFC, listed by transactions, function modules and destinations
· Number and volume of spool requests
· Statistics about response time distribution, with or without the GUI time
· Workload and transactions used listed by users, payroll number, and client
· Workload generated by requests from external systems
For all of this data you can display the data for a particular instance (not only the one to which you are
logged on) or optionally totaled for all instances. Depending on your user mode, you can choose the
time period for which you want to display the data between day, week and month (or determine the
length of time yourself using the Last Minutes’ Load function). For most analysis views, you can
display all or only certain task types.
The workload monitor has an interface that is divided into two parts. Use the tree structures on the left
of the screen to make the following settings:
· Select the user mode
· Select the time period for which you want to display the workload
· Select various functions and analysis views (which data you want to display).
The system then displays the result on the right of the screen in a standardized ALV Grid Control.
For general performance monitoring you can use the following options:
· User mode à choose expert mode
· Workload à choose the instance and time frame you are interested in. Selection between the
last days, the last weeks and the last months is possible. If you are interested in a particular
time within the last 24 hours, choose Detailed Analysis, than Last Minute’s Load and than the
needed time frame on the appropriate instance.
· In the first workload overview you get, you find the response times and its components for the
different task types (Background, Dialog, HTTP, RFC, Update, etc). You can now go to
Analysis Views à Transaction Profiles à Standard. Here you can get a more detailed view,
selecting for instance the task type dialog and the aggregation per transaction.
© 2005 SAP AG 122
The following screen shot shows transaction ST03 using the options: Expert mode, workload for
server us0306_Q4C_02, time frame from 03.01.2005 – 09.01.2005, standard transaction profile,
showing dialog transactions sorted by average response time.
8.5.4 Transaction STAD
In the STAD records every step on CRM Application Server is recorded. The records for all instances
of a CRM system are displayed. The Business Transactions Analysis (transaction STAD) calculates
the system resource usage of individual transactions for SAP R/3 Systems and provides a detailed
analysis of a transaction and the dialog steps. The selection criteria include user, transaction, program,
task type, start date, and start time.
The analyzed time period can be larger than the interval defined by Read Time, as the system
analyzes complete transactions as far as possible. However, it is not always possible to perform a
complete analysis for longrunning transactions. As the business transaction analysis is time
consuming, you should use as short an interval as possible (around 10 minutes).
The aim of this monitor is to analyze in detail how long the response times for particular steps in a
process (or transaction) and are these response times distributed among their components (DB time,
CPU time, Wait time, GUI time, etc) have been.
If you want to use this transaction to analyze the performance of the steps done by a particular user
proceed as follows:
· Tell him to execute the interesting steps once, slowly one after the other and write down the
exact time at which he executed them.
· Go to STAD and display the statistical records related to this single execution (use the user
name and the appropriate time frame to display the correct records).
· Format the output list (button “Sel. Fields”), including the fields ‘GUI time’, ‘CUA reference
program’ and ‘CUA internal command’. The two latter fields can help you to identify the single
steps executed.
· Use the time stamps of the statistical records and the execution times you wrote down to
assign STAD records to the dialog steps that were performed.
© 2005 SAP AG 123
· Check which steps are actually having a bad response time and what part is contributing most
to it (DB, CPU, GUI, …).
· Depending on the result proceed with a deeper analysis of the worst steps using e.g.
transaction ST05 (for long DB times), transaction SE30 (for long CPU times) or a network
analysis (not described in this document) in case of high GUI times.
· Depending on what you are analyzing, it might be wise to let the user execute all steps twice
and use the second execution for the analysis. This way you make sure that all buffers (e.g.
program buffers) are filled.
You can also use this transaction to see in detail what was going on in the system during specific
hours with bad performance. With this analysis you can see if there where a few users having
particularly high response times or if there was a general performance problem.
Procedure:
Go to transaction ST03 and search for the hour with the worst performance or the highest workload
using the time profile
Call transaction STAD with the following selection criteria:
· Show all statistic records, sorted by start time à Checked
· Start date à Today’s date
· Read time à 1 hour
· Start time à start time of high workload (from ST03)
· User à *
· Resp. time à >= 5000 ms
· Task type à D (dialog) or B (batch) or R (RFC) or * (all)
Please be aware that this query may take several minutes.
The following screen shots show the initial screen of STAD with the options: Show all statistic records,
sorted by start time, reading of the records for 10 minutes starting from 16:50 hours, for all users (*)
that executed dialog transactions lasting longer than 1000 ms.
Following there are two screen shots showing the result of this query. For each time stamp you see
what program was executed within which transaction on which server. For each the user, response
time, time in work process, CPU time, DB time, GUI time, CUA ref. Program and CUA internal
© 2005 SAP AG 124
command are displayed. These columns are not all part of the first standard output. They where
adjusted using the “Select output fields” button (F9).
To make the following steps easier, you may want to download the list with spreadsheet format. Make
sure you have displayed all columns you need before getting the download. Please be also aware that
the STAD records are only kept in the system for a limited period (normally 24 or 48 hours).
Go through the list of long lasting dialog steps and search for those dialog steps that are lasting long
on average (those appearing several times). You may identify which steps belong together by
comparing the transaction, the program, the CUA reference program and the CUA internal command.
Use the table below to identify to which transaction the dialog steps belong.
If you can’t find a CUA ref program or a CUA internal command in this list or if you are not sure on the
assignment, please proceed as described below. Please beware that the table beneath only shows
typical CUA internal commands for some common steps. However these commands can be different
in your system depending on customizing settings, user exits, particular system usage, and so on.
· Execute the typical steps of your core business processes once. Execute the steps slowly one
after the other and write down the exact time at which you executed them. The steps should
be performed by a key user.
· Go to STAD and display the statistical records related to this single execution (use the user
name and the appropriate time frame to display the correct records).
· Format the output list (button “Sel. Fields”), including the fields ‘GUI time’, ‘CUA reference
program’ and ‘CUA internal command’.
© 2005 SAP AG 125
· Use the time stamps of the statistical records and the execution times you wrote down to
assign the “CUA internal commands” or the “CUA reference program” to the dialog steps that
were performed.
· Use this information to identify which dialog steps are having extremely high response times
during you peak load time.
Use this information to analyse in detail what is harming the performance of the corresponding
transaction or dialog step. Use also the information on the distribution of the response time (DB time,
CPU time, GUI time) given in the list, to identify the cause of the problem. Depending on the result
proceed with a deeper analysis of the worst steps using e.g. transaction ST05 (for long DB times),
transaction SE30 (for long CPU times) or a network analysis (not described in this document) in case
of high GUI times.
Additionally search for those taking particularly long (e.g.more than 10 seconds). Contact the
responsible user to find out what he was doing at that time, if the did some unusual steps or if he
noticed a bad response time. If you cannot identify the cause, you may use the procedure described
for transaction ST05 for a deeper analysis.
The following table contains a list of function codes (CUA internal commands) of the most common
steps grouped by CRM scenarios.
Scenario Step CUA ref. Program CUA internal command
Interaction Center Call cic0 SAPLSMTR_NAVIGATION CIC0
Search for BP in CIC0 SAPLCIC0 CSEARCH_SEARCH
Select CP from PopUp in SAPLCRM_CIC_BP_SUB &IC1
CIC0
Confirm BP in CIC0 SAPLCIC0 CSEARCH_CONTINUE
Display interaction history SAPLCIC0 BUS_LOCATOR_SRCH_
GO
Create one order SAPLCIC0 1OMAIN_CREATE
document (choose) in
CIC0
Save one order document SAPMSSY0
in CIC0
Change tab in CIC0 SAPLCIC0 AA_TAB*
End contact in CIC0 SAPLCIC0 ECNT
Hitting the return key RFSH
(“Enter”)
Field Sales Create inquiry
Create quotation SAPLCRM_1O_MANAG_UI NEWT_POP
1OMAIN_CREATE
Create sales order SAPLCRM_1O_MANAG_UI NEWT_POP
1OMAIN_CREATE
Save sales order to CDB SALESDOCGEN_O_W_CDB
Replicate to mobile CGCAPGEN_OBJ_WRITE_R
clients RR
Marketing – Start MKTPlanner SAPMSSY0 empty
MKTPL (CRM_MKTPL)
Create Campaign SAPLCRM_MKTPL %_GC 123 1
Save Campaign SAPLCRM_MKTPL Save
Switch to Product Tab SAPLCRM_MKTPL TAB_PRODUCT
Add Product on Product SAPLCRM_MKTPL CGPL_DUMMY
Tab
Switch to Segment Tab SAPLCRM_MKTPL TAB_MKTING_SEGM
Add Target Group SAPLCRM_MKTPL CGPL_DUMMY
Marketing – Start Segment Builder SAPMSSY0 empty
SEGBUIL Open Attribute List empty empty
Add Attribute to empty empty
© 2005 SAP AG 126
Segmentation Area
Count Profile CRM_MKTTG_SEG_UI_STA %_GC 161 1
Save Profile CRM_MKTTG_SEG_UI_STA SEG_SAVE
CRM Online Create quotation SAPLCRM_1O_MANAG_UI NEWT_POP
1OMAIN_CREATE
Create sales order SAPLCRM_1O_MANAG_UI 1OMAIN_CREATE
NEWT_POP
Create service order SAPLCRM_1O_MANAG_UI 1OMAIN_CREATE
NEWT_POP
Product Proposal (click SAPLCRM_1O_MANAG_UI T\SALS_HD04
on the product tab)
Determine price (click on SAPLCRM_1O_MANAG_UI T\SALS_HD05
the price tab)
E Selling Login to web shop SAPLCRM_ISALES_SHOP CRM_ISA_SHOP_GETLI
ST
Select a shop SAPLCRM_ISALES_SOLDT CRM_ISA_CONTACT_G
O ET_SOLDTOS
CRM_ISA_BP_BPARTN
ER_GETDETAIL
SAPLCRM_ISALES_ORDER CRM_ISA_STATUS_PR
OFILE_ANALYSE
CRM_ISA_BP_BPARTN
ER_GETDETAIL
Create shopping SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CR
basket/order EATE
SAPLCRM_ISALES_SOLDT CRM_ISA_SOLDTO_AD
O D_TO_BASKET
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CH
ANGEHEAD
SAPLCRM_ISALES_SHIPTO CRM_ISA_SHIPTOS_OF
_SOLDTO_GET
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE
TITEMS
T_MESSAGES
TTEXT
TSHIPCOND
THEAD
Button catalogue SAPLCRM_ISALES_1TO1 CRM_ISA_SHOP_RECO
MMENDAT_GET
SAPLCRM_ISALES_1TO1 SAPLCRM_ISALES_1TO
1
Add to shopping basket SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE
TITEMS
THEAD
SAPLCRM_BATCH_IL CRM_ISA_STATUS_PR
OFILE_ANALYSE
TTEXT
TSHIPCOND
TIPCINFO
© 2005 SAP AG 127
Create/send sales order SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_OR

DER
ANGEITEMS
ANGEHEAD
THEAD
TITEMS
Select related products SAPLCRM_ISALES_1TO1 CRM_ISA_BASKET_CU
A_PRODS_GET
Create order from order SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CH
templates ANGEITEMS
SAPLCRM_ISALES_ORDER SAPLCRM_ISALES_OR
DER
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CR
EATE
TITEMS
ANGEHEAD
Delete product from order SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE
template TITEMS
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_DEL
ETEITEM
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_DEL
ETEITEM
ANGEHEAD
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_AD
DITEMTEXTS
Order from order SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_OR
template DER
ANGEITEMS
ANGEHEAD
THEAD
TITEMS
For details on the Performance monitoring on Function Code level and the monitoring setup
procedures use the following link
http://service.sap.com/~sapidb/011000358700003081072005E and navigate to section 2.1.
8.5.5 Transaction ST05
The performance trace tool contains a range of trace functions that you can use to monitor and
analyze the performance of the system in database accesses, locking, and remote calls of reports and
transactions. It allows you to record database access, locking activities, and remote calls of reports
and transactions in a trace file and to display the performance log as a list. It also provides extensive
support for analyzing individual trace records.
© 2005 SAP AG 128
To use the performance trace, you need the authorization to start transaction ST05 and the system
authorizations "Change trace switches" (authorization STOM for authorization object S_ADMI_FCD)
and "Analyze traces" (authorization STOR, also for authorization object S_ADMI_FCD).
The performance trace contains the following tracing options:
· SQL Trace: This allows you to monitor the database access of reports and transactions.
· Enqueue Trace: This allows you to monitor the locking system.
· RFC Trace: This provides information about Remote Function Calls (RFCs) between
instances.
The aim of the procedure described below is to find the SQL statements that are causing high
response times in the CRM system. If you identified a transaction or a process step that is taking to
long, you may use transaction ST05, to find out if one or more SQL statements are causing the
performance problem.
Procedure:
Call transaction ST05 and make sure you are on the same instance as the user you want to trace:
· Check the option SQL trace (also Enqueue and RFC trace if needed)
· Activate the trace with filter
· Enter the user name of the user that will perform the steps
· Confirm
· Ask the user to perform the relevant steps (and nothing else)
· Deactivate the trace
· Display the trace. Make sure the user name is correct. Write down the displayed time stamps
(trace period) to be able to find the same trace in the system later on. Use the extended trace
list to display the time stamps for each SQL statement.
· Depending on what you are analyzing, it might be wise to let the user execute all steps twice
and use the second execution for the analysis. This way you make sure that all buffers (e.g.
program buffers) are filled.
Go trough the trace and search for the statements having a high duration (marked red). Use the
‘explain’ functionality to see if the correct index is being used for that statement.
In case you can not find the cause of the performance problem or need further assistance for the
analysis contact the next support level or open an OSS message on component XXSERTCC. Attach
the trace, a detailed description of the performed steps and the related STAD records to the message.
8.5.6 Transaction SE30
The runtime analysis tool allows you to examine the performance of any ABAP programs, such as
reports, subroutines, function modules or classes. It saves its results in performance data files, which
you can display as lists. You can use these results to identify runtimeintensive statements, to combine
table accesses, and show the hierarchy of program calls. From the results of the runtime analysis, you
can identify:
· Excessive or unnecessary use of modularization units
· CPUintensive program functions
· Userspecific functions that could be replaced with ABAP statements
· Inefficient or redundant database access.
Depending on the size of the program, considerable volumes of data can be generated during the
runtime analysis. For this reason, this tool is defaulted to Full aggregation. This means that only the
standard hit list is generated with all calls. The standard hit list does not include Group hit list, Hit list of
database tables, Class hit list, Instance hit list, Method hit list, Event hit list, Hit list of internal tables,
Call hierarchy and Statistics. To cancel this restriction, switch off aggregation by replacing the
standard variant in the initial screen with a temporary variant, for example. In this variant, you can then
configure the measurement restrictions according to the selected objects to be measured.
The runtime analysis consists of two parts:
© 2005 SAP AG 129
· Recording performance data
· Analyzing the performance data
In the first part, the system measures the transaction, program, or procedure, and writes the result to a
performance data file. You can restrict the measurement to certain objects. You can also measure up
to ten external processes.
In the second part, the performance data is analyzed, and the system displays the results in list form.
For more information on this transaction and its usage please see the application help.
The runtime analysis tool measures the CPU time required by the measurable components of a
transaction, a program, or a procedure. The information is stored in a performance data file, which you
can analyze either immediately or at a later date. The CPU time required to measure the runtime is
subtracted from the total CPU usage. If you measure the runtime of a program more than once, you
are unlikely to get the same result on each occasion. There are various reasons why it is very difficult
to obtain identical runtimes. For example, in the first measurement, the system might read data
records from the table buffer on the application server, but in a second run, it may have to read them
directly from the database. Runtimes also depend on the overall system or network load (for example,
the number of jobs or systems currently active in your SAP System).
In case you can not find the cause of the performance problem or need further assistance for the
analysis contact the next support level or open an OSS message on component XXSERTCC. Attach
the runtime analyses, a detailed description of the performed steps and the related STAD records to
the message.
8.6 Batch Jobs

Certain jobs must run periodically in a production CRM Server System for example, deleting obsolete
jobs or spool objects. If these periodic jobs do not run, system performance may get worse over time.
Unfortunately, there is currently no easytouse support for such jobs in Basis Customizing. Therefore,
the jobs must be scheduled manually. For more information, see SAP Note 16083. Note that a daily
monitoring of the job log using transaction SM37 is recommended.
8.6.1.1 General periodic jobs
Please schedule the following general periodic jobs as described.
· RSBTCDEL
Report RSBTCDEL deletes entries from tables BTC*, and performs a cleanup of files in directory
/usr/sap/<SAPSID>/SYS/global/<client>JOBLG. Tables BTC* contain background job
administration data. It is recommended to define a variant for report RSBTCDEL. A daily job
called SAP_REORG_JOBS with report RSBTCDEL as a job step should be scheduled.
· RSPO0041or RSPO1041
Report RSPO0041 deletes entries from spool tables TSP*, and performs a cleanup of files in
directory /usr/sap/<SID>/<Instance>/data. Tables TSP* contain spool job administration data and
spool data. Define a variant for report RSPO0041. Schedule a daily job called
SAP_REORG_SPOOL containing report RSPO0041 as a job step.
Alternatively, you can use report RSPO1041 instead of report RSPO0041. For detailed
information, see SAP Note 130978.
· RSPO1043
Report RSPO1043 resets write locks and deletes inconsistent objects in spool tables TSP*. Tables
TSP* contain spool job administration data and spool data. Schedule report RSPO1043 on a
regular basis. See SAP Note 98065 for details.
· RSBDCREO
Report RSBDCREO deletes entries from BDC* and APQ* tables, and performs a cleanup of files
in directory /usr/sap/<SID>/SYS/global. The tables contain Batch Input administration data.
It is recommended to define a variant for report RSBDCREO.
© 2005 SAP AG 130
Thus please schedule a daily job called SAP_REORG_BATCHINPUT containing report
RSBDCREO as a job step.
Note: For SAP Basis Release 4.0, you must apply SAP Note 100915 BEFORE you schedule this
report.
· RSBPSTDE
Report RSBPSTDE deletes entries from tables BTCJSTAT, and deletes statistics for background
job runtimes. Table BTCJSTAT contains background job runtime statistics data. Create a variant
for report RSBPSTDE. Schedule a monthly job called SAP_REORG_JOBSTATISTIC, which
contains report RSBPSTDE as a job step.
· RSCOLL00
Report RSCOLL00 collects various statistical data for performance monitoring of CRM Server, the
database, and the operating system. If this job is not run, no performance data is available, and
system monitoring is impossible. Schedule an hourly job called
SAP_COLLECTOR_FOR_PERFMONITOR. Use RSCOLL00 as a job step. You should also
maintain table TCOLL according to SAP Note 12103.
8.6.1.2 CRM specific periodic jobs
Please also schedule the following CRM specific periodic jobs as described:
· Preparations for update statistics
Report SMO6_MAINT_STATISTIC should always be scheduled one day before the update
statistics run. Scheduling this report before the update statistics run is necessary to optimize
database accesses.
· Automatic start of the QueueDemon
The queue demon needs to be started after each system startup. Schedule report
SMO_QUEUEDEMON after system startup. If you schedule report SMO_QUEUEDEMON as a
background job, you do not need to start the queue demon manually. See SAP note 332002 for
details.
· Refresh of generation status information
Report GN_GENERATE_CHECK updates generation status information. If this report is not
scheduled daily, the generation status information displayed in the CRM middleware monitoring
cockpit (transaction SMWP) is not up to date.
Before the start of production, it is recommended to schedule report GN_GENERATE_CHECK
with period #daily# . Thus please call transaction SMWP. Select Background Jobs. Rightclick on
"Check Generation Status of Objects" and select "Show suggested action". Press button action.
· Collector for Monitoring Cockpit
The Collector for Monitoring Cockpit updates CRM middleware monitoring cockpit information. If
this report is not scheduled periodically, information displayed in the CRM middleware monitoring
cockpit (transaction SMWP) is not up to date. It is recommended to schedule job "Collector for
Monitoring Cockpit". Thus please call transaction SMWP. Select Background Jobs. Rightclick on
"Collector for Monitoring Cockpit" and select "Show suggested action". Press button Action.
· Reorganization Job for Middleware Tables
Report SMO6_REORG for reorganization of the trace tables is not scheduled as a job or stops
with an error. It is recommended to schedule the job to run on a daily basis in every productive
client. Please see SAP Note 206439 for details. If errors occur, check SAP Note 214474.
· Mobile Message Recovery Cleanup Report
Report QBLOCKDELETION for the deletion of extracted/unprocessed messages is not scheduled
daily. This report cleans up tables QBL_EXTN, CCO_INFHDR, CCO_INFDTL.
Please call transaction CMWQ_DEL and create a daily background job with variant 'Delete all
extracted messages for available sites'.
© 2005 SAP AG 131
· Reorganization of BDoc message related object links
The ABAP Program RSRLDREL for reorganization of BDoc message related object links should
be scheduled as a job. It is recommended to create one daily background job that contains two
variants of program RSRLDREL as two job steps. The first variant should cover the period from
the current date until (current date X days) and use the option "One object not available". The
second step should cover the period from the GoLive date of your hardware up until X days before
the current date and use the option "Without existence check". The value of "X" depends on your
business requirements: if a business process is successfully completed, object link entries are no
longer required. In our experience a value of X = 7 is usually sufficient. However, at the beginning
of your CRM project a value of X = 28 is recommended, because in early project stages errors are
more likely and the object link entries in SRRELROLES/SMW0REL are needed for error analysis.
Further details on how to set up variants for RSRLDREL are in SAP Note 493156. If you require
assistance in setting up this background job, please open a customer message on component XX
SERTCCCRM.
· Job HRBCI_ATTRIBUTES_BUFFER_UPDATE
Report HRBCI_ATTRIBUTES_BUFFER_UPDATE should be scheduled. This report buffers the
organizational data that can provide big performance improvements for nearly all CRM scenarios.
It is recommended to execute report HRBCI_ATTRIBUTES_BUFFER_UPDATE on a daily basis.
It is necessary to set up the buffering indicator via the transaction OOATTRCUST for the scenario
CRM. Call transaction OOATTRCUST and tick field buffering for the fields Sales and/or Service,
depending on the CRM scenarios you use. Afterwards schedule a periodic daily running batch job
with the report HRBCI_ATTRIBUTES_BUFFER_UPDATE and the variant SAP&CRM. If your time
window is too short to run after midnight, the job can be executed the day before between 20:00H
00:00H. The job automatically buffers the attributes for the following day if executed during this
time frame. As a consequence one background job will be scheduled at this time. The run time
depends on the size of the organizational plan. This is required because entries in the cluster
tables are only valid for one day. Therefore, the cluster table has to be created on a daily basis by
report HRBCI_ATTRIBUTES_BUFFER_UPDATE. Otherwise performance improvements by this
technique are not possible. See SAP Note 110909 for details.
Monitoring Monitor Monitor Threshold Indicator or Error Monitoring Respon
Object TA/Tool Freq. Activity or sibility
Error Handling
Procedure
Background SolMan Daily To be set Start and enddelay, Out Check for the Application
jobs of time window, Maximum cause monitoring
Duration, Cancellation, team
Parallel processing of
jobs, Job log messages
8.6.1.3 Error Handling Procedures for Batch Jobs
In case of failure of one of the scheduled jobs, if one of the necessary jobs is not scheduled, or
even if a scheduled job has finished, check for the current job status (refer to SAP R/3
documentation CD, component BCCCM, chapter background processing) and proceed as
follows:
· In case of status scheduled, the job steps have already been defined, but the start
condition has not yet been defined. Contact the program scheduling management in order
to clarify when the job will be fully defined.
· In case of status released, the job has been fully defined including a start condition and
waits for the condition to fulfill.
· In case of status ready, the start condition of a released job has been met. A job
scheduler has put the job in line to wait for an available background work process.
· In case of status active, the job is currently running and cannot be modified or deleted
anymore. Check if the job is within the given timeframe, depending on the data volume to
© 2005 SAP AG 132
be processed. Check for particular dependencies on other jobs. If the job exceeded the
given timeframe, contact the software monitoring team.
· In case of status finished, all steps that make up this job have completed successfully.
Program scheduling management has to check whether the job ran in the given
timeframe, and software monitoring team and/ or application support have to check the
respective job results (such as spool output lists, message logs, updates, etc.).
· In case of status cancelled, the job has terminated abnormally, which can happen in two
ways. If an administrator intentionally cancelled the job, clarify why he did so and whether
(and if, when) the job has to be rerun.
If a program in a job step produced an error such as issuing an ‘E’ or ‘A’ error message,
contact the software monitoring team and investigate why the error occurred. In case of an
SAP standard program search for appropriate messages in SAPNet and open a customer
message, if you cannot solve the problem.
8.6.1.4 Job Restartability
In case of the cancellation of a background job possible succeeding jobs or dependencies on other
jobs must be considered when restarting the aborted job. The start of succeeding jobs might be also
delayed due to the restart of the aborted job.
8.6.1.5 Escalation Procedures
If it is not possible for any of your support levels to provide a solution for a particular problem, it is
recommended to open a customer problem message in the SAPNet R/3 frontend system.
8.7 Mass data changes

The purpose of the Mass Data Update process is to get mass data changes into CRM and to external
sites (subscribed to that data) as well as to CDB and mobile clients. It is also the goal to pass mass
data change originated in CRM online to connected sites.
The focus of this chapter is on mass data changes that run during the production. Initial download
topics will not be covered here. For all initial download issues, please refer to the “Setup and
Download Guide”.
(https://websmp203.sap
ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700003462572001E)
Especially customers running the Field Sales scenario (Mobile Sales/Service) have to be careful with
mass data changes, as e.g. 1000 condition changes in R/3 may generate a heavy load on the CRM
system in case these all have to be replicated to the mobile clients.
The application components covered for mass data change here are:
· Conditions
· Business Partner
· Product/Materials
· Sales orders
The following table summarizes the sources of mass data changes that are distributed into the CRM
system and the possible interfaces that can be used. Furthermore special monitoring activities are
named. For more detailed information on the different topics, please refer to the single subchapters
below.
Started in R/3 by transaction: Monitoring
Conditions e.g. VK11 or VK12 SAPMV75A
Business XD99 transactions return error messages in case of
Partner problems
Products / MM17 transactions return error messages in case of
Materials problems
© 2005 SAP AG 133
Sales orders VA05, VA15, VA25, VA35, transactions return error messages in case of

VA45, VA 55 problems
Procedure
In mass maintenance, you must decide which tables of an object type are to be changed. It is possible
to make changes in several tables at the same time. If several tables are selected, only objects that
meet the selection criteria in every table will be chosen.
Several tables should only be selected if it is necessary – for reasons of consistency – to make the
changes simultaneously. If this is not required, it is – for reasons of performance recommended to
process the tables sequentially.
Please note that many objects can be changed simultaneously in mass maintenance. When you save
your changes, the system checks them for consistency. They then take immediate effect for all objects
chosen.
Mass data processing requires special handling in replication and special handling in adapters. For
details about the process, please refer to the following documents:
Doc Processing in CRM 30 (https://websmp101.sap
ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700006510122001E )
(for Initial Load, Mass Data Change, Single Delta Process, Direct Sending)
and
Cookbook: Data Exchange (https://websmp101.sap
ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700006149582001E )
Recommendations:
Coordinate the scheduling with the R/3 and CRM System administrators who may generate
mass data changes.
For Mobile scenarios: Implement Note 453882 (Parallel processing of the R&R queues) that
also includes handling and monitoring instructions. Do not set the number of processes too
high, as this might be hindering system performance otherwise.
Check the filter settings in CRM (transactions: r3ac1, r3ac3, r3ac5) and check table VKORG
(via se16) in R/3 before starting mass data changes in R/3. Always do a forecast on the
amount of load that will be created in the CRM system, before starting the changes.
8.7.1.1.1 General Monitoring Activities
Apart from safeguarding the general availability of the R/3 system and CRM server SAP recommends
to monitor the objects listed in the following table. The monitoring activities strongly depend on the
hardware used.

Performance ST03, STAD Daily Long times Monitor RFC Statistics Application
of CRM and (>1000 ms monitoring team
backend per line item)
Bdocs smwp Daily Red light at Investigate the cause Application
Bdoc level monitoring team
(folders:
‘Runtime
information’
and ‘Bdoc
messages in
the flow’)
Queues smq1 Daily, Queues are In case one or more of the Application
smq2 smohque stopped or on queues get stuck (Error stop monitoring team
ue hourly hold or CPIC errors) try to restart
smwp (activate) the queues
smohqueue manually. If starting the
queues manually does not
work, please check with
transaction ST22 for possible
© 2005 SAP AG 134

error causes.
Bdoc Smq1 (CRM) Daily old dates, big Investigate the cause, Application
Outbound Queues probably contact the monitoring team
Queue (for responsible sales person
Field Sales)
For Field Sales it is recommended to check when the last data transfer to the mobile clients occurred,
i.e. when program Conntrans was executed the last time. For this reason you can use transaction
smq1 on the CRM Server. Select all entries and select “Display Selection (F7)”. By default the queues
are sorted by “1. Date”. This entry represents the oldest entry in the outbound queue waiting to be
transferred, i.e. the first new entry after the last executed download. For queues not transferred for a
long time (e.g. 2 month, but considering holidays and public holidays) you should contact the
respective user.
Please also check the amount of objects waiting for download on a regular basis. As the download for
more than e.g. 10.000 Objects might take quite some time (maybe a few hours) check the
subscriptions and the download frequency. Please note, that different objects might differ considerably
in processing and download time. (Condition BDocs are usually downloaded quickly, whereas Sales
Documents can take a few seconds). Please also check for running data extracts (via transaction
smohqueue for the Replication & Realignment Queue), as deletion or adding of sites for mobile clients
also produces high load on the queues.
Queue Performance
Mass changes of data (creating, changing) on the R/3 system might lead to reduced system
performance, as all dialog and background work processes become occupied.
Analysis:
The outbound queue (SMQ1) of the R/3 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 R/3 system is intended for the delta download to the CRM Middleware Server and is therefore
stored in the outbound queue of the backend 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. Please see SAPNet note 356228 for the handling of parallel processing.
Error handling:
Proposals for long running (never ending) mass maintenance:
Use more CPUs (e.g. from an application server)
Increase the rereading time for the scheduling
Deactivate some queues or queue blocks if the rest of the business is more important. See
above, note 356228
Please note that it is not possible to stop and restart mass data changes, because this may cause
inconsistencies.
Additional helpful SAPNet notes:
576160 MM17: BAdI implementation for append fields
573718 MM17: Calling MLGN Convert BSME>LHME generically
566520 Long runtime mass maintenance MM17, XD99, XK99, MEMASSIN
498382 MM17: Problems with mass data change of AFS tables
557702 FAQ for mass maintenance (updated frequently)
© 2005 SAP AG 135
Monitoring XIF Interface
For mass data changes performed in nonSAP Systems connected to a CRM Server, refer to the
guide “ The use of external interfaces”
(https://websmp101.sap
ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700000614852002E ).The use
and monitoring of XIF interfaces (XML and IDOC) is described there. This document is valid for CRM
3.0, CRM 3.1 and CRM 4.0.
DIMA
The purpose of the “Data Integrity Manager” is to help to detect and repair data inconsistencies
between the CRM database and the CDB or the connected R/3. For additional information please
check the guide “Checking CrossComponent Data Integrity”. This can be found in the SAP Service
Marketplace (http://service.sap.com), alias CRMMW. There select CRM powered by Netweaver >
Process Integration > CRM Integration Services > System Landscape Management.
Frequently asked mass maintenance questions:
1. Why does the mass maintenance select an incorrect number of data records?
Prior to the actual selection, the mass maintenance first carries out a preselection via the leading
table of the selection. The logic according to which the leading table is selected from several tables is
described in note 325088. If a maximum number of data records, that should be selected and
displayed without consultation and that has been defined in mass maintenance by the user, is
exceeded in the preselection, the system displays on dialog box 'Processing mode' how many or, in
case of a selection of several tables, up to how many records it selects. That is, in case of a selection
of several tables the preselection only displays an upper limit. Only when you press pushbutton
'Display all records' or 'Change in background' on dialog box 'Processing mode', the combined
selection is made across all selected tables. Consequently, the number of the selected data can
deviate heavily from the upper limit displayed on the 'Processing mode' dialog box.
The mass maintenance offers 2 processing modes (you can 'change existing data records' and/or
'create new data records'), which you can execute separately or together (!!!). If both processing
modes are activated, all data records that meet the selection conditions for the change plus all data
records that correspond to the selection conditions for the new creation are selected.
2. Why is the runtime of the selection across several tables in the mass maintenance very long? Why
does the selection in the mass maintenance terminate with TIME OUT?
Note 325088 describes the logic of the combined data selection across several tables in the change
mode of the mass maintenance. You can solve the problem by choosing the selection condition in a
suitable way.
3. Which notes reduce the runtime of the mass maintenance.
424635 Long runtime in the mass maintenance customer/vendor
485023 Long runtime with mass maintenance purchase requisition
544687 Mass maintenance: Long runtime of the data selection
566520 Long runtime mass maintenance MM17, XD99, XK99, MEMASSIN
739979 Termination due to memory overflow at start of a
4. Why does the selection terminate with ABAP runtime error 'SAPSQL_WHERE_CANT_SCAN'?
Note 330416 describes the cause and solution of the problem.
5. Why does the mass maintenance terminate with ABAP runtime error
'TABLEVIEW_DUP_COLUMN_INDEX'?
6. Why does the saving of a variant terminate with ABAP runtime error
'SAPSQL_ARRAY_INSERT_DUPREC'?
© 2005 SAP AG 136
7. How do I create new data records?
Note 351283 describes the selection logic for the creation of new data records in the mass
maintenance. Notes 331364 and 339444 additionally describe the effect of foreign key dependencies
of the selection fields on the selection of the new records to be created in mass maintenance.
© 2005 SAP AG 137
9 Further Information
9.1.1.1.1 Troubleshooting
If executing this Best Practice did not produce the desired results,
· Search for related notes in the SAPNet.
· Open an SAP Customer Message describing your problem (please see the respective
component in section Error Handling, Restartability and Escalation of every step).
9.1.1.1.2 Literature
· For detailed information on how to administer an SAP R/3 system, see the book:
Liane Will, SAP R/3 System Administration, 1999
· For information on how to monitor and tune the general system performance, see the book:
Thomas Schneider, SAP R/3 Performance Optimization, 1999.
9.1.1.1.3 Feedback and Questions
Send any feedback by formulating an SAP customer message to component SVGSTSMC. You can
do this at http://service.sap.com/message.
© 2005 SAP AG 138
10 Appendix
10.1 General Monitoring Guidelines for the SAP
CRM System and the SAP R/3 System
For the administration of an SAP R/3 system as well as for the R/3 basis of an SAP CRM system,
there are a number of monitoring activities we strongly recommend scheduling and supervising on a
regular basis. The following list is not complete, especially jobs and tasks for the database
administration (such as backups, archiving transaction logs, update statistics for cost base optimizer
and so on) are not mentioned, however it gives you an impression of what you have to do in order to
keep a system running. As part of the SAP Basis these monitors do not display any CRM specific
monitoring data. They should be analyzed using the same procedures as those used in a nonCRM
system environment.
If you have further questions on these subjects, please refer to the Solution Management Optimization
Service System Administration.
Basis Monitoring: General System Checks
Monitoring Monitor Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Time Error Error Handling Procedure
R/3 System ST03 daily tbd Average Review response times in Software
workload dialog comparison to system load and monitoring team
analysis response performance influencing changes
time within the system of the analyzed
< 1000 ms period.
Identify and improve
performance of any transaction
whose response time exceed the
times defined in the Service
Level Agreement (SLA), if
existing.
Monitor RFC response time
statistics and Dialog response
times for online transactions.
Database ST04 Weekly tbd Expensive Monitor database statistics. Software
perform and in SQL Monitor the buffer cache hit ratio monitoring team
ance case of statements
Analysis perform Check for missing indices;
ance ensure that the data quality is
problem sufficient, and that there is
s sufficient space available.
Operating ST06 Hourly tbd High paging Monitor the CPU and memory Software

system (depend rate and consumption. monitoring team
monitor ing on CPU A hardware bottleneck can have
the utilization a negative impact on the overall
busines response time as well as the
s response time of an individual
process business transaction.
) and in
case of Especially monitor hardware load
perform during high RFC transmission
times.
ance
problem
s
R/3 System ST02 Weekly tbd Swaps Monitor memory resource usage Software
buffer and in for specific R/3 application monitoring team
monitor case of servers
perform To ensure optimal performance
ance check that the R/3 parameters
problem are set correctly with transaction
© 2005 SAP AG 139

s ST02.
Incorrectly sized R/3 buffers or
memory allocation can result in
poor performance. One such
example would be when a work
process enter PRIV mode.
Local work SM50 hourly tbd WP status, Monitor current state of individual Software
process during WP work processes. monitoring team
overview peak utilization Ensure that enough work
hours process capacity is available at
and in peak times.
case of
perform
ance
problem
s or
error
messag
es
System SM66 hourly tbd WP status, Similar to SM50 but for system Software
wide work during long running wide statistics. monitoring team
process peak jobs
overview hours
Database DB02 Daily tbd Table space Ensure that the data quality is Software
perform and in sizes, table sufficient, that there are no monitoring team
ance case of indices for missing indexes, and that there is
monitor perform tRFC and sufficient space available.
ance aRFC In general if table sizes are larger
problem than 500MB, reorganize the table
s and decrease its size.
See SAP Note 375566.
Monitor the growing of tables and
indices, especially on tRFC and
qRFCtables (ARFCSSTATE
ARFCSDATA
ARFCRSTATE)
ABAP dump ST22 daily tbd Dumps Check short dumps, analyze Software
analysis and in aborted programs. monitoring team
case of Select a period and click on the
an List button. Select an error, and
errors then choose Display to see the
short dump.
For SAP developed programs
that experience frequent
terminations, investigate SAPNet
for a possible resolution and if
necessary open a customer
message. For customer
developed programs contact the
appropriate member of the
development team.
System log SM21 daily tbd Entries Check for general system Software
and in program errors and table space monitoring team
case of errors or transactions that
an encounter errors.
errors Maintain date/time and select
Reread system log. Position
cursor on a time, and then
choose Display.
© 2005 SAP AG 140

Update SM13 daily tbd Status Check for entries that have Software
tasks and in status ‘ERR’. monitoring team
case of Update records should be
an monitored regularly and the
errors appropriate user should be
contacted immediately to resolve
any outstanding updates.
Together with the user,
determine whether the update
request can be restarted or has
to be deleted.
Display Transac In case tbd Status Determine the performance of Software
Statistical tion of bad single statistical records monitoring team
Record STAD perform
ance
10.2 Middleware specific Monitoring Activities

for the R/3 System
R/3 BackEnd System Monitoring Queue Transaction Code Monitoring Frequency Periods

Monitoring Activities / Functions and Events
Qrfc Outbound Queue Monitor: SMQ1 · Several times a day
Monitor data exchange from the R/3 back depending on the business
end system to the CRM Server process
Queues should be relatively short and · In case of an error message
quickly processed · During mass updates
Check, if the qRFC Version is up to date (see
SAP Notes 166096, 366735 and 438015) · Use Alert Monitoring
To prevent data inconsistencies, you need to
monitor the interfaces regularly for aborted or
stopped data transfer
qRFC Inbound Queue Monitor SMQ2 · Several times a day
Monitor communications from CRM System depending on the business
è R/3 System process
Messages “flow” through the inbound queue · Upon error
on the R/3 system and are immediately
processed
Normally SMQ2 should show an empty list
Status of Queue Scheduler SMQS · In case of a status error
Monitor status of the QOUT Scheduler · Use Alert Monitoring
10.3 Middleware specific Monitoring Activities

for the CRM System
The table below lists transactions used for monitoring the CRM Server:
CRM Server Central Monitoring Activities / Monitoring Type Monitoring Frequency Periods
Functions and Events
© 2005 SAP AG 141
Middleware Portal SMWP · Several times a day

Monitoring the CRM Middleware Portal with depending on the business
transaction SMWP can be subdivided into the process
following areas: · After implementing transports
· Generation Information containing:
BDocs Types: Generation of structures
BDocs Types: Generation of other runtime
objects
Replication objects
Publications: Missing Indexes, Status of
Delta/Initial Generation, Flow Definitions
· Runtime Information containing:
Data Exchange using RFC queues
Adapter Status Information
Replication and Realignment Queues
BDoc Messages in the Flow
· System settings containing:
Number of sites per site type
· Monitoring tools/statistics
· Background jobs
QRFC Outbound Queue Monitor: SMQ1 Several times a day depending on

Monitor data transfer between the R/3 back the business process
end and the CRM server and between the Daily
CRM server and mobile clients and other
connected systems
Queues destined for the R/3 backend and
other stady connected systems should be
relatively short and quickly processed, queues
to destination NONE too
Entries destined for the mobile clients and BW
remain in the queue until each receiver fetches
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, any
deletion of queues causes data inconsistencies
If a queue that is “in use” between a mobile
client and the CRM Server is deleted, it will
cause data inconsistency between the CRM
Server 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)
QOUT Scheduler SMQS Daily
Ensure that all destinations are registered. Only In case of performance problems
destination NONE must be excluded. See also or error messages
SAP Note 400330
© 2005 SAP AG 142
QRFC Inbound Queue Monitor: SMQ2 Several times a day depending on

Monitor data transfer between the R/3 back the business process
end system and the CRM Server and between
mobile clients and the CRM Server and all
other queues, which have to be stored in the
CRM Online DB
Messages in the inbound queue are processed
according to the capacity of the CRM Server.
High number of entries in the inbound queue
can indicate insufficient capacity on the CRM
Server
QIN Scheduler Status SMQR Daily
This transaction runs the scheduler to check In case of performance problems
the inbound queues on the CRM Server
Ensure that all inbound queues are registered
(type R). Register them, if necessary, using the
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. Possibly a
scheduler problems may exist.
Check the maximum processing time of the
inbound queues.
Set the maximum processing time of a queue
("Maxtime") to 60 seconds for all queues
during normal operations
TRFC Monitoring SM58 Several times a day depending on

Monitor all transactional RFCs (tRFCs) the business process
processed on the CRM Server (e.g. workflow)
SM58 is linked to the Replication and
Realignment queues in error status in the
EXTRACT and/or AC_EXTRACT queue (click
on the error symbol)
Message Flow Statistics SMWMFLOW Daily
Collects statistical data about the workload on Only for power users In case of an error message
the CRM Server caused by BDocs messages
Use this as a starting point for analyzing
performance problems
The message flow is a central function in the
CRM Server and uses BDocs
Display statistics of the message flow within the
CRM Server
Ensure that the middleware message flow
statistics are switched on
BDOc Messages/Summary SMW01/SMW02 Several times a day depending on

Application error analysis the business process
SMW01: Display the data of a BDoc message In case of an error message
and possible errors
SMW02: Display BDocs message summary in
dependency on the site ID
Middleware Trace / Developer Trace SMWT In case of an error message

It is used to to track program flows, record
events and provide information for evaluation
Summary of Unprocessed Bdoc Messages SMW03
© 2005 SAP AG 143
Check Flow Definitions SMO8FD After BDoc type changes or

Only after changes in the customizing changes in services or in the flow
are made
Consistency Check for Flow Definitions
In case of an error message
CRM Server R/3 Adapter / Load Monitoring Monitoring Type Monitoring Frequency Periods and

Activities / Functions Events
Monitor Load Status R3AM1 In case of an error messages
Checks, whether the initial load was during/after initial load
successfully completed Depending on the object status
Object status and actions:
RED: Refer to SAP Notes 429423 and 350176
for initial load problem analysis
YELLOW: initial download must still be done /
is running
GREEN: OK
Monitor Request R3AR3 In case of an error message, if the
Used in exceptional cases to bring the databases are not consistent and a
database into a consistent state after a data request from the R/3 backend, the
lost for instance in the CDB CRM or the CDB is necessary
BDoc Flow Statistics Activation
Ensure that the middleware kernel application statistics are switched on. Call transaction
SMWMFLOW. Execute Goto > Activate Statistics. Select “message flow statistics”. Activate
monitoring of the middleware message flow.
To activate the application statistics, select “Kernel application statistics”, select the change mode,
mark the field “MW” (Middleware Message Hub Statistics”. Save.
Communication Monitor Collector Activation
For activating transaction SMWMCOMM, the Conntrans Performance monitoring, you have to choose
“Environment”> “Run Collector
© 2005 SAP AG 144
© 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 noninfringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential
damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the
information, text, graphics, links or other items contained within these materials. SAP has no control over the information
that you may access through the use of hot links contained in these materials and does not endorse your use of third party
Web pages nor provide any warranty whatsoever relating to third party Web pages.
© 2005 SAP AG 145

BPM For Crm40

Загружено:

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

Исходное описание:

Оригинальное название

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

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

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

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

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

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

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

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

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

BPM For Crm40

Загружено:

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

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

Manage mySAP CRM 4.

Best Practice for Solution Management

6.1 E­Selling System Landscape ............................................................................................72

1.2 Best Practice Procedure

3 mySAP CRM Online Sales

3.1 Sales Order Management

Monitoring Monitor Monitor Threshold Indicator or Monitoring Activity or Responsibility

Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Responsibility

Queues SMWP Daily Queues are Investigate the cause Application

BW BW Daily / Check if all sales order data has Cross

4 mySAP CRM Interaction Center Overview

4.1 Interaction Center Building Blocks

Agent Agent IC Manager

mySAP CRM Interaction Center Other

Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon­

Description Transaction/ Fcode CUA internal command

5 mySAP CRM Field Sales Overview

5.1 Field Sales System Landscape

Mobile Adm in Mobile Developm ent Mobile Repository

Author izatio n Mobile Application

IPC IPC MS SQL

Monitor ing Monitor Monitor Indicator or Monitor ing Activity or Responsibility

Sales Applica­ Upon error Application Contact Application Sales

Mobile client House­ At least twice Application

Monitor ing Monitor Monitor Indicator or Monitor ing Activity or Responsibility

Monitor ing Monitor Monitor Indicator or Monitor ing Activity or Responsibility

Monitor ing Monitor Monitor Indicator or Monitor ing Activity or Responsibility

Monitor ing Monitor Monitor Indicator Monitor ing Acitivity or Responsibility

Monitor ing Monitor Monitor Indicator Monitor ing Acitivity or Responsibility

Monitoring Monitor Monitor Threshold Indicator or Monitoring Activity or Responsibility

Monitoring Monitor Monitor Threshold Indicator Monitoring Activity or Responsibility

Monitor ing Monitor Monitor Indicator or Monitor ing Acitivity or Responsibility

5.2 Further Information

5.3 Scenario specific Monitoring

Replication Queues Monitor SMOHQUEUE · Several times a day

Mobile Client Monitoring Activities / Functions Monitoring Type Monitoring Frequency

Operating system Perfmon.exe In case of an error

6 mySAP CRM E­Selling Overview

6.1 E­Selling System Landscape

6.2 Core Business Processes in SAP CRM E­Selling

Monitoring Monitor Monitor Indicator Monitoring Activity or Respon­ Escalation

Monitoring Monitor Monitor Threshold Indicator or Monitoring Activity or Responsibility

Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility

Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Responsibility

Monitoring Monitor Monitor Indicator or Error Monitoring Activity Responsibility

J2EE J2EE If there are Shop functionalities Log files Software

Monitoring Monitor Monitor Monitoring Activity or Respon­ Escalation

Monitoring Monitor Monitor Monitoring Activity or Respon­ Escalation

Monitoring Monitor Monitor Monitoring Activity or Responsibility

Monitoring Monitor Monitor Monitoring Activity or Responsibility

Queues SMWP Daily Queues are stopped. Application monitoring

6.2.1.15.1 Monitoring Activities

Shop Shopadmin Upon error Shop is not Check and monitor the Software Contact

6.2.1.16.1 Monitoring Activities

Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Respon­ Escalati

Monitoring Monitor Monitor Indicator Monitoring Activity or Responsibility Escalation

6.2.1.17.3 Monitoring Activities

Order Status SE16 Check order status manually, Application monitoring Contact system

Monitoring Monitor Monitor Indicator Monitoring Activity or Respon­ Escalation

Performance ST05 Monthly Logon Monitor hardware utilization on Software/ Contact system

Monitoring Monitor Monitor Indicator Monitoring Activity or Respon­ Escalation

Performance ST05 Monthly Logon Monitor hardware utilization on Software/ Contact system

6.1 ESelling System Landscape ............................................................................................72

Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon

Sales Applica Upon error Application Contact Application Sales

Mobile client House At least twice Application

6 mySAP CRM ESelling Overview

6.1 ESelling System Landscape

6.2 Core Business Processes in SAP CRM ESelling

Monitoring Monitor Monitor Indicator Monitoring Activity or Respon Escalation

Monitoring Monitor Monitor Monitoring Activity or Respon Escalation

Monitoring Monitor Monitor Monitoring Activity or Respon Escalation

Monitoring Monitor Monitor Indicator or Error Monitoring Activity or Respon Escalati

Monitoring Monitor Monitor Indicator Monitoring Activity or Respon Escalation

Monitoring Monitor Monitor Indicator Monitoring Activity or Respon Escalation

SEMBPS PROMO Order MSA

Monitoring Object Monitor Monitor Indicator or Monitoring Activity or Respon

Monitoring Object Monitor Monitor Indicator Monitoring Respon

Monitoring Object Monitor Monitor Indicator Monitoring Activity or Respon

Monitoring Object Monitor Monitor Indicator or Monitoring Activity or Respon

R/3 BackEnd System Monitoring Queue Transaction Code Monitoring Frequency Periods