Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Alternative Practices
SAP experts can deliver this Best Practice on-site when you order a Solution Management
Optimization (SMO) service known as the SAP Business Process Management service.
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 super-ordinate
Best Practice General Business Process Management, which you can obtain through the SAP
Solution Manager.
Page 2 of 138
Best Practice: SAP Business Process Management for CRM 3
System Requirements
None.
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, E-Selling, 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.
2005 SAP AG 3
Best Practice: SAP Business Process Management for CRM 4
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
A monitoring object table listing each relevant monitoring object, showing the:
o Monitoring object
o Monitoring transaction or tool
o Monitoring frequency
o Monitoring time
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 section 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.
mySAP CRM
SAP Customer Relationship Management (CRM) supports all customer-facing processes throughout
the entire customer relationship life cycle from market segmentation and opportunities to post-sales
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.
2005 SAP AG 4
Best Practice: SAP Business Process Management for CRM 5
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
Usability-optimized 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
IC-Webclient contains a Java Web application (ICSERVER) which is a prerequisite on the Java 2
Enterprise Edition (J2EE). J2EE 6.20 and 6.40 are 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 call-attached data. The Integrated Communication Interface (ICI) supports the
integration of non-SAP 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, e-mail, and chat, but it can also be used in single-channel 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 e-mail correspondence with their customers through the IC. Agents in an
integrated call center may perform all of these activities.
To satisfy customers, customer-facing 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 People-Centric User Interface (PC-UI). PC-UI 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 CRM-user.
Portal CRM
(SSO)
Portal user CRM user
Authorization
Navigation
2005 SAP AG 5
Best Practice: SAP Business Process Management for CRM 6
CRM
R/3 IPC
2005 SAP AG 6
Best Practice: SAP Business Process Management for CRM 7
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, the general availability and
performance of the following system components (if used) must be ensured:
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 Solution Manager for central monitoring, refer to the SAP Best Practice for
Solution Management Central System Monitoring for mySAP.com which 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 end-to-end 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.
2005 SAP AG 7
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 process-oriented 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.
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.
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 8 of 138
Best Practice: SAP Business Process Management for CRM 9
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
cross-selling 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.
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 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
2005 SAP AG 9
Best Practice: SAP Business Process Management for CRM 10
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
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 dont 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).
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 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
2005 SAP AG 10
Best Practice: SAP Business Process Management for CRM 11
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 Retrieve information from fact sheet.
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
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 Use script for answering.
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
2005 SAP AG 11
Best Practice: SAP Business Process Management for CRM 12
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 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 you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation (component CRM-CIC-IIA/CRM-IC-SOL for step 6 and component EP-KM-TRX for step
7).
2005 SAP AG 12
Best Practice: SAP Business Process Management for CRM 13
For the process step Maintain interaction record please review the section in the Activity Management
section in the CRM Online part.
2005 SAP AG 13
Best Practice: SAP Business Process Management for CRM 14
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.
Outbound 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.
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 cross-selling 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 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.
2005 SAP AG 14
Best Practice: SAP Business Process Management for CRM 15
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).
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/Assign call list.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon-
Object TA/Tool Freq. Error Error Handling Procedure sibility
Performance ST03, STAD Weekly Long See chapter performance Application
and upon response monitoring monitoring
error times team
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 Activate from call list.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon-
Object TA/Tool Freq. Error Error Handling Procedure sibility
Performance ST03, STAD Weekly Long See chapter performance Application
and upon response monitoring monitoring
error times team
2005 SAP AG 15
Best Practice: SAP Business Process Management for CRM 16
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 Execute call.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon-
Object TA/Tool Freq. Error Error Handling Procedure sibility
Performance ST03, STAD Weekly Long See chapter performance Application
and upon response monitoring monitoring
error times team
Monitoring Activities
The monitoring activities of this process step strongly depend on the used telephony system.
2005 SAP AG 16
Best Practice: SAP Business Process Management for CRM 17
Complaint Management
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.
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 customers 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.
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.
2005 SAP AG 17
Best Practice: SAP Business Process Management for CRM 18
The following detailed description of the process steps with the monitoring procedure and activities for
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).
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 complaint.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon-
Object TA/Tool Freq. Error Error Handling Procedure sibility
Performance ST03, STAD Weekly Long See chapter performance Application
and upon response monitoring monitoring
error times team
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 Replicate return request item.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon-
Object TA/Tool Freq. Error Error Handling Procedure sibility
BDocs SMWP Daily Red light at Investigate the cause Application
(CRM) Bdoc level monitoring
team
Queues SMWP Daily Queues are Investigate the cause Application
(CRM) stopped monitoring
team
2005 SAP AG 18
Best Practice: SAP Business Process Management for CRM 19
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 Replicate substitute delivery item.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon-
Object TA/Tool Freq. Error Error Handling Procedure sibility
BDocs SMWP Daily Red light at Investigate the cause Application
(CRM) Bdoc level monitoring
team
Queues SMWP Daily Queues are Investigate the cause Application
(CRM) stopped monitoring
team
2005 SAP AG 19
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.
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 own-developed workspaces, their data can be lost at End Contact,
when a restart is performed. To solve this problem and to present an un-changed 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 own-developed workspaces.
Page 20 of 138
Best Practice: SAP Business Process Management for CRM 21
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.
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 Roll-In + 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 21
Best Practice: SAP Business Process Management for CRM 22
Refer to note 594904 to get further information about alternatives to get a significant statement about
the CIC0 performance.
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 up-to-date 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 third-party backend systems as well as SAP R/3.
The CRM Server 4.0 is based on SAP Release 6.20 (SAP Web
Application Server).
2005 SAP AG 22
Best Practice: SAP Business Process Management for CRM 23
2005 SAP AG 23
Best Practice: SAP Business Process Management for CRM 24
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:
BW
Communication CRM Host
Mobile Client(s)
Station
Mobile Client
IPC RDBMS
MTS
Internet Pricing
IPC
DCOM and Configurator
MS SQL Connector OLTP R/3
Middleware RDBMS
RDBMS
APO
RDBMS
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 CRM-FS 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)
2005 SAP AG 24
Best Practice: SAP Business Process Management for CRM 25
All R/3-bound QRFCs can be monitored in R/3 by using standard R/3 Alert-Monitoring 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
For general information regarding the use of Computer Center Management System (CCMS) in
combination with the 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.
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 CRM-Field 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 process-oriented monitoring concept including the various components of a CRM-
Field Sales solution. For most customers this process is the most critical one.
2005 SAP AG 25
Best Practice: SAP Business Process Management for CRM 26
connected. In this document the scenario is described with an R/3 System connected. The sales
document is then created in R/3.
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.
Monitoring Procedure
Please note that for this special business process (or rather this special scenario) a step-wise
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.
2005 SAP AG 26
Best Practice: SAP Business Process Management for CRM 27
Monitoring Activities
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.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
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)
Monitoring Activities
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 Quotation can be performed.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
2005 SAP AG 27
Best Practice: SAP Business Process Management for CRM 28
Monitoring Activities
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 Sales Order can be performed.
2005 SAP AG 28
Best Practice: SAP Business Process Management for CRM 29
Tax Process: The tax determination allows the field sales force to determine taxes on products, in
order to provide business partners with accurate, up-to-date 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.
Monitoring Activities
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 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.
2005 SAP AG 29
Best Practice: SAP Business Process Management for CRM 30
The IPC log-file (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 log-file is the first place to look for more information when pricing or configuration does not
work. The log-file is not overwritten when the application is restarted.
2005 SAP AG 30
Best Practice: SAP Business Process Management for CRM 31
The number of log-files, their size and the name of the log-files can be customized. The procedure is
the same as for the IPC in the CRM-Online scenario. Refer to IPC specific documentation.
The default location for the log-file 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
The quickest way to locate the TEMP-folder is to open Start-->Run and type %temp% followed by
return.
The following Field Sales-specific trace information can be found in the IPC log-file.
The IPC can be configured to produce additional Mobile Sales specific trace-information. 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 line-item 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 trace-information 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 "#"
IMPORTANT: The writing of the additional trace-information 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.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-MSA-IPC-PRI.
Monitoring Activities
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 Configure the Product can be performed.
2005 SAP AG 31
Best Practice: SAP Business Process Management for CRM 32
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.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
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)
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 sold-to 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 log-file 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
The quickest way to locate the TEMP-folder is to open Start-->Run and type %temp% followed by
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.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-MSA-IPC-CFG.
2005 SAP AG 32
Best Practice: SAP Business Process Management for CRM 33
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-MSA-SAD.
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.
Monitoring Activities
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 Submit sales document can be performed.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
BDOC SMQ1 Check if BDOC Sales
Client STFC_WRITE_TO TCPIC representative
Console has been added to the
2005 SAP AG 33
Best Practice: SAP Business Process Management for CRM 34
For messaging BDoc types, the name of the validation function module must be specified (field
SMW3FDBDOC-VALIFUMO).
2005 SAP AG 34
Best Practice: SAP Business Process Management for CRM 35
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 BDoc-Modeler (transaction SBDM on the CRM server).
Monitoring Activities
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.
2005 SAP AG 35
Best Practice: SAP Business Process Management for CRM 36
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 Non-Unicode 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.
2005 SAP AG 36
Best Practice: SAP Business Process Management for CRM 37
2. Using Client Console, assign the mobile client to the XML enabled site
Data Exchange with an XML Enabled Workgroup Server site
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.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-MT-FW-TL for problems on a mobile client and CRM-MW-
COM for problems in data transfer.
Monitoring Activities
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.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
Crmd_or Upon Verify that changes have been Application
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 Transacti Weekly Long See chapter performance Application
on and upon runtime monitoring monitoring team
STAD/ error
Transacti
on ST05
on CRM
server
and R/3
System
2005 SAP AG 37
Best Practice: SAP Business Process Management for CRM 38
Monitoring Activities
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 Quotation 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.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
Crmd_or Upon Verify that changes have been Application
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 Transacti Weekly Long See chapter performance Application
on and upon runtime monitoring monitoring team
STAD/ error
Transacti
on ST05
on CRM
server
and R/3
System
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.
2005 SAP AG 38
Best Practice: SAP Business Process Management for CRM 39
Monitoring Activities
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 Sales Order 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.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
Crmd_or Upon Verify that changes have been Application
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 Transacti Weekly Long See chapter performance Application
on and upon runtime monitoring monitoring team
STAD/ error
Transacti
on ST05
on CRM
server
and R/3
System
2005 SAP AG 39
Best Practice: SAP Business Process Management for CRM 40
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 Cross-Industry 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.
Monitoring Activities
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.
Monitoring Monitor Monitor Indicator or Monitoring Acitivity or Respon-
Object TA/Tool Frequ. Error Error Handling Procedure 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
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>). Double-click the destination and you find the RFC user. Trace this user for the duration of the
sales transaction.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. If the problem is within R/3, please use component SD- SLS-SO.
2005 SAP AG 40
Best Practice: SAP Business Process Management for CRM 41
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.
Monitoring Activities
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.
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
Crmd_or Upon Verify that changes have been Application monitoring
der error made in CRM server team
From here you can also go to the
application log that logs application
errors.
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
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 Transacti Weekly Long See chapter performance Application monitoring
on and upon runtime monitoring team
STAD/ error
Transacti
on ST05
on CRM
server
and R/3
System
2005 SAP AG 41
Best Practice: SAP Business Process Management for CRM 42
Monitoring Activities
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 Replicate to Mobile Clients can be performed.
Monitoring Monitor Monitor Indicator or Monitoring Acitivity or Respon-
Object TA/Tool Frequ. Error Error Handling Procedure 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 Activities
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.
Monitoring Monitor Monitor Indicator or Monitoring Acitivity or Responsibility
Object TA/Tool Frequ. Error Error Handling Procedure
Inbound Client Console Each time Monitor the inbound Sales
queue and ConnTrans queue on the mobile representative/end
logfile on is used client.
2005 SAP AG 42
Best Practice: SAP Business Process Management for CRM 43
2005 SAP AG 43
Best Practice: SAP Business Process Management for CRM 44
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-MT-FW-TL.
Further Information
Integration of BW and CRM Field Sales
Please also see Connection to SAP Business Warehouse (BW).
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.
It is possible to examine the entire processing log by choosing the "Display Log" pushbutton
(SHIFT+F4) within transaction smobilebw. By double-clicking 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 double-clicking 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
double-clicking, 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.
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 double-clicking 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 = <BW-username> 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.
2005 SAP AG 44
Best Practice: SAP Business Process Management for CRM 45
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.
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.
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.
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
Microsofts Distributed Component Object Model (DCOM). The DCOM Connector uses RFC to
connect to the CRM System.
The connection setup is carried out via Dial-Up Networking (Remote Access Service).
After installation of the mobile client the ConnTrans.exe is stored under ...\SAP\Mobile\bin\.
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).
2005 SAP AG 45
Best Practice: SAP Business Process Management for CRM 46
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.
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.
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.
It displays all the relevant Windows and SAP-specific 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.
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.
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 component-to-component 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).
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..).
2005 SAP AG 46
Best Practice: SAP Business Process Management for CRM 47
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\.
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.
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 third-party 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).
The Sales Pricing Engine (SPE) enables field sales representatives to calculate prices at the point-of-
sale for those offers and orders created in the mobile system. The system uses the companys 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
2005 SAP AG 47
Best Practice: SAP Business Process Management for CRM 48
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
maintain Customizing settings in the SPE and you cannot create or change price-relevant master data
such as condition records and agreements. This happens exclusively in your main system.
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.
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 clients 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.
Backweb
SAP BackWeb is an optional third-party 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 Internet-based 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.
2005 SAP AG 48
Best Practice: SAP Business Process Management for CRM 49
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
2005 SAP AG 49
Best Practice: SAP Business Process Management for CRM 50
2005 SAP AG 50
Best Practice: SAP Business Process Management for CRM 51
2005 SAP AG 51
Best Practice: SAP Business Process Management for CRM 52
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.
To use ConnTrans, on the Mobile Client choose Start > Programs > SAP CRM Mobile Client >
ConnTrans.
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 self-documenting 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 SAP-related 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:
2005 SAP AG 52
Best Practice: SAP Business Process Management for CRM 53
For further details, go to www.microsoft.com > Support Knowledgebase and see the White Paper
Measuring performance-relevant data using PERFMON on Windows NT.
For a detailed description of the use of the MS Performance Monitor, see SAP Note 203845.
In Windows NT, to start PERFMON, choose Start > Run and enter PERFMON.
Set up PERFMON as follows.
1. Measure the CPU utilization on the server or PC.
From the PERFMON menu, choose Edit > Add to Chart / Add Item
Select in PERFMON: Object, Processor, Counter, % Processor Time
2. Determine the size of dataset transferred for analysis.
Select in PERFMON: Object, Network Interface, Counter, Bytes Received/sec
Note: Depending on the network connection, the name of the category and item of the above-
mentioned examples may differ. When selecting the network interface counter it is possible that
various instances (= lines) are offered. If you are not sure on which network line the traffic takes place,
choose all instances. You may have to start processes at the NT level monitoring network traffic.
3. To start your analysis, monitor during the peak time when Mobile Clients are uploading to the CRM
Middleware System. To save the performance data and transfer it into a spreadsheet program,
choose File > Export Chart.
Evaluate your analysis.
2005 SAP AG 53
Best Practice: SAP Business Process Management for CRM 54
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.
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.
2005 SAP AG 54
Best Practice: SAP Business Process Management for CRM 55
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 search-criteria have been used.
Which requirements/user-exits 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 document-level by setting the check-box
"Pricing Analysis" in the "Details" tile-set. 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 tile-set "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 log-file (ipcapplication.?.log) ?
The IPC Log-file 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 log-file is the first place to look for more information when pricing or configuration does not
work.
How to locate the IPC log-fileipcapplication.*.log?
The log-file is not overwritten when the application is restarted.
By default the IPC writes a log-file called ipcapplication.0.log, until it reaches the size of 1 MB. The
IPC now starts writing into a new log-file called ipcapplication.1.log. When this file has also reached a
size of 1MB, the first log-file ipcapplication.0.log is overwritten.
The number of log-files, their size and the name of the log-files can be customized. The procedure is
the same as for the IPC in the CRM-Online scenario. Refer to the IPC documentation.
The default location for the log-file 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
The quickest way to locate the TEMP-folder is to open Start-->Run and type %temp% followed by
return.
Mobile Sales-specific trace information into the IPC log-file.
The IPC can be configured to produce additional Mobile Sales specific trace-information. The trace will
then contain the following additional information:
2005 SAP AG 55
Best Practice: SAP Business Process Management for CRM 56
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 'Cross-Component
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 Bill-of-Material'.
2005 SAP AG 56
Best Practice: SAP Business Process Management for CRM 57
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).
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.
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.
2005 SAP AG 57
Best Practice: SAP Business Process Management for CRM 58
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>
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.
R/3 system The R/3 backend system covers functionality for sales and distribution and
financial accounting.
2005 SAP AG 58
Best Practice: SAP Business Process Management for CRM 59
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 E-Selling Web Application. The Web server is also used to deliver static
catalog content, such as product images.
The Web front-end connects directly with the Web server. On the Web
server, a specific plug-in 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 up-to-
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.
Text Retrieval & SAP TREX is used as a special purpose engine in the area of E-Commerce.
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 E-Selling
and Optimizer (APO) scenario, Supply Chain Management, Demand Planning and other tasks. It
is an optional component.
2005 SAP AG 59
Best Practice: SAP Business Process Management for CRM 60
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:
CRM Server
Backend System such as SAP R/3
2005 SAP AG 60
Best Practice: SAP Business Process Management for CRM 61
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.
For general information regarding the use of Computer Center Management System (CCMS) in
combination with the 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 E-Selling can be divided into the following areas:
Monitoring the end-to-end message flow from the CRM to the R/3 System
Monitoring the queues located on the respective server systems
Monitoring SAPJ2EE via the Administrator.
Monitor the R/3 Adapter components (Download objects, log file, queues, requests)
Operating system performance monitoring
Database system performance monitoring
Error analysis
2005 SAP AG 61
Best Practice: SAP Business Process Management for CRM 62
2005 SAP AG 62
Best Practice: SAP Business Process Management for CRM 63
2005 SAP AG 63
Best Practice: SAP Business Process Management for CRM 64
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 Web shop logon can be performed.
2005 SAP AG 64
Best Practice: SAP Business Process Management for CRM 65
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.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-UM.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 Browsing the product catalog and searching for products can be performed.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-CAT.
2005 SAP AG 65
Best Practice: SAP Business Process Management for CRM 66
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.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 Configure products can be performed.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-CFG.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 Determine the Product Price can be performed.
2005 SAP AG 66
Best Practice: SAP Business Process Management for CRM 67
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component AP-BF-PR.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 Shopping Basket can be performed.
2005 SAP AG 67
Best Practice: SAP Business Process Management for CRM 68
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.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 Determine Price for Shopping Basket can be performed.
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.
2005 SAP AG 68
Best Practice: SAP Business Process Management for CRM 69
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-BBS.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 Shopping basket as an Order Template can be performed.
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.
In situations that may require escalation, contact the system administrator or your business process
owner.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-BBS.
2005 SAP AG 69
Best Practice: SAP Business Process Management for CRM 70
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.
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.
The following detailed description of the process steps with the monitoring procedure and activities for
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 70
Best Practice: SAP Business Process Management for CRM 71
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 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
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
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-UM.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 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
2005 SAP AG 71
Best Practice: SAP Business Process Management for CRM 72
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.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-CAT.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 shopping basket can be performed
Monitoring Monitor Monitor Indicator or Error onitoring 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.
2005 SAP AG 72
Best Practice: SAP Business Process Management for CRM 73
In situations that may require escalation, contact the system administrator or your business process
owner.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-BBS.
Monitoring Activities
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 shopping basket as an Order Template can be performed.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-BBS.
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 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
2005 SAP AG 73
Best Practice: SAP Business Process Management for CRM 74
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.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-R3.
Monitoring Activities
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 Display Invoice 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 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.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA.
2005 SAP AG 74
Best Practice: SAP Business Process Management for CRM 75
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).
We consider in detail the following process steps:
Login to web shop
Do payment check
2005 SAP AG 75
Best Practice: SAP Business Process Management for CRM 76
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
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 shopping basket as a Create Web User/Login can be performed
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-UM.
Monitoring Activities
Monitor interfaces to external payment systems. For this interface, define error handling procedures,
restart and recovery procedures.
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 Do Payment Check can be performed
Monitoring Monitor Monitor Indicator Monitoring Activity or Respon- Escalation
Object TA/Tool Freq. or Error Error Handling Procedure sibility Procedure
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
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA.
2005 SAP AG 76
Best Practice: SAP Business Process Management for CRM 77
The following detailed description of the process steps with the monitoring procedure and activities for
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).
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
2005 SAP AG 77
Best Practice: SAP Business Process Management for CRM 78
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 Login to web shop can be performed.
If you could not find the cause of the problem with this checklist, open a SAPNet message for further
investigation. Please use component CRM-ISA-UM.
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- / up-selling products you want to offer your customers
You can refer to the analysis results from Web Analytics to do this.
2005 SAP AG 78
Best Practice: SAP Business Process Management for CRM 79
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 multi-stage 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 in-q-my 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\global-web.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 79
Best Practice: SAP Business Process Management for CRM 80
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)
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 (00-FF).
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 HTTP-PUT. 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.
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
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.
2005 SAP AG 80
Best Practice: SAP Business Process Management for CRM 81
BW
Products
Conditions
The graphic above shows a typical hardware solution landscape for CRM Marketing, integrated with
SAP R/3 and SAP BW.
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:
2005 SAP AG 81
Best Practice: SAP Business Process Management for CRM 82
CRM Server
Backend System such as SAP R/3
SAP BW
Monitoring in the mySAP CRM Marketing environment can be divided into the following areas:
Monitoring BDOCs related to the marketing objects
Monitoring the queues located on the respective server systems
Operating system performance monitoring
Database system performance monitoring
Error analysis
The management of these business processes along with a process-oriented 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.
2005 SAP AG 82
Best Practice: SAP Business Process Management for CRM 83
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 long-term planning of marketing activities, including budgeting and
scheduling. For example, they can be used as a management tool for annual costing in the Marketing
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.
2005 SAP AG 83
Best Practice: SAP Business Process Management for CRM 84
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 follow-on 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.
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.
Monitoring Activities
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
mBDOC SMW01 Daily Status F01, Check error message Application
MKTPL_MKTELEM, E01 monitoring
sBDOC team
CAMPAIGN_WRITE
2005 SAP AG 84
Best Practice: SAP Business Process Management for CRM 85
Monitoring Activities
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
2005 SAP AG 85
Best Practice: SAP Business Process Management for CRM 86
Monitoring Activities
Monitoring Monitor Monitor Indicator or Monitoring Activity or Respon-
Object TA/Tool Freq. Error Error Handling Procedure sibility
Marketing Marketing During Error message Check message User
Element Planner creation
Monitoring Activities
Monitoring Object Monitor Monitor Indicator or Monitoring Activity or Respon-
TA/Tool Freq. Error Error Handling Procedure sibility
Transfer of Marketing After Status Check error message User
campaign to R/3 Planner manual
transfer
2005 SAP AG 86
Best Practice: SAP Business Process Management for CRM 87
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.
Monitoring Activities
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
team
Marketing Element log Marketing After Status Analyze error User
Planer execution message
2005 SAP AG 87
Best Practice: SAP Business Process Management for CRM 88
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: do-not-use / do-not-contact / to be archived / central block
5 = Contact Not Possible (Technical Problems)
Example: If the e-mail to a business partner is blank and thus cannot be sent or if the e-mail
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).
Monitoring Activities
The monitoring activities of this process step strongly depend on the hardware used.
Monitoring Monitor Monitor Indicator Monitoring Activity or Responsibility
Object TA/Tool Freq. or Error Error Handling Procedure
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
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 1-2 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 BC-SRV-COM.
In case of performance problems during parallel mailing please check according to note 610923, if you
transfer the e-mail address of the sender via the 'E-mail 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.
Monitoring Activities
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
2005 SAP AG 89
Best Practice: SAP Business Process Management for CRM 90
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.
2005 SAP AG 90
Best Practice: SAP Business Process Management for CRM 91
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.
Monitoring Activities
Monitoring Object Monitor Monitor Indicator or Monitoring Activity or Respon-
TA/Tool Freq. Error Error Handling Procedure sibility
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
2005 SAP AG 91
Best Practice: SAP Business Process Management for CRM 92
Monitoring Activities
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
Monitoring Activities
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
mBDOC SMW01 Daily Status Check error message Application
CND_M_SUP monitoring team
sBDOC SMW01 Daily Status Check error message Application
CNBCCP* monitoring team
2005 SAP AG 92
Best Practice: SAP Business Process Management for CRM 93
Monitoring Activities
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
CSA_MASS_MKTPL, monitoring
CSA_MKTPL*, AI* and team
CRM_MKTPL_APO_INT
Monitoring Activities
Monitoring Object Monitor Monitor Indicator Monitoring Activity or Respon-
TA/Tool Freq. or Error Error Handling Procedure sibility
Transfer to R/3 Marketing After Status Check error message User
Planner manual
transfer
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.
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.
2005 SAP AG 94
Best Practice: SAP Business Process Management for CRM 95
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, e-mail, 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.
Monitoring Activities
Monitoring Object Monitor Monitor Indicator Monitoring Activity or Respon-
TA/Tool Freq. or Error Error Handling Procedure sibility
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
2005 SAP AG 95
Best Practice: SAP Business Process Management for CRM 96
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.
Monitoring Activities
Monitoring Object Monitor Monitor Indicator or Monitoring Activity or Respon-
TA/Tool Freq. Error Error Handling Procedure sibility
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
OBJCHARACTERIS team
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.
2005 SAP AG 97
Best Practice: SAP Business Process Management for CRM 98
Monitoring Activities
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
2005 SAP AG 98
Best Practice: SAP Business Process Management for CRM 99
Monitoring Activities
Monitoring Object Monitor Monitor Indicator Monitoring Respon-
TA/Tool Freq. or Error Activity or sibility
Error
Handling
Procedure
Report SM37 Daily Status Check job log Application
CRM_MKTTG_PROC_TG_FEXP_B monitoring
ATCH team
Monitoring Activities
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
Monitoring Activities
Monitoring Object Monitor Monitor Indicator Monitoring Respon-
TA/Tool Freq. or Error Activity or sibility
Error Handling
Procedure
Program SM37 Daily Status Check Job Log Application
CRM_MKTTG_PROC_ORDER_B monitoring
2005 SAP AG 99
Best Practice: SAP Business Process Management for CRM 100
The management of the Sales order management business processes along with a process-oriented
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
These sections below are referenced in the corresponding business process steps of the scenario
specific parts above.
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.
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 FAQ-note 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 Cross-Component Data Integrity. This can be
found in the SAP Service Marketplace (http://service.sap.com), alias CRM-MW. There select
CRM powered by Netweaver -> Process Integration -> CRM Integration Services -> System
Landscape Management.
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 pop-up. 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 post-processing.
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.
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 Determine price.
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.
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 CRM-IPC.
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.
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 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
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.
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 CRM-IPC.
For more information regarding this step please refer to the Availability Check in the generic part of
this document.
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 sales order (R/3).
Monitoring Monitor Monitor Indicator or Monitoring Activity or Responsibility
Object TA/Tool Freq. Error Error Handling Procedure
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
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 Cross-Component Data
Integrity. This can be found in the SAP Service Marketplace (http://service.sap.com), alias
CRM-MW. 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),
system workload analysis monitor (st03) and SQL trace monitor (st05) in the CRM server and
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.
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.
Generic Information
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
Performance Monitoring
Batch Jobs
Mass Data Changes
These sections are referenced in the corresponding business process steps of the scenario specific
parts above.
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 e-selling
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:
Available-to-Promise (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 Rules-based 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
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, follow-up 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.
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, APO-R/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)
Monitoring Activities
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.
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
Inbound processing
Flow Contexts: overview XIF Adapter
BAPI BW Adapter
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
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 back-end 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:
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.
2005 SAP AG 112
Best Practice: SAP Business Process Management for CRM 113
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 double-clicking 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
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.
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.
The following table lists the possible actions to put unprocessed messages into a final state:
Function Description
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
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 E-Commerce) 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.
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.
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).
Roll-in 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 - Roll-in 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 Roll-Out 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
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.
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.
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 its 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.
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 XX-SER-
TCC.
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.
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 Minutes 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.
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.
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 long-running 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.
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 Todays 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
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 cant 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.
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.
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CR
EATE
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE
TITEMS
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CH
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
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CH
ANGEHEAD
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_AD
DITEMTEXTS
Order from order SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_OR
template DER
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CH
ANGEITEMS
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CH
ANGEHEAD
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE
THEAD
SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE
TITEMS
One order documents include leads, opportunities, inquiries, quotations and/or sales orders.
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.
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.
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 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 XX-SER-TCC. Attach
the trace, a detailed description of the performed steps and the related STAD records to the message.
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 runtime-intensive 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
CPU-intensive program functions
User-specific 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.
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 XX-SER-TCC. Attach
the runtime analyses, a detailed description of the performed steps and the related STAD records to
the message.
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 easy-to-use 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.
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.
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.
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 front-end system.
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
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.
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.
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 Cross-Component Data Integrity. This can be found in the SAP Service
Marketplace (http://service.sap.com), alias CRM-MW. There select CRM powered by Netweaver ->
Process Integration -> CRM Integration Services -> System Landscape Management.
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.
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'?
Note 391449 describes the cause and solution of the problem.
6. Why does the saving of a variant terminate with ABAP runtime error
'SAPSQL_ARRAY_INSERT_DUPREC'?
Note 517296 describes the cause and solution of the problem.
Further Information
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).
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.
Appendix
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 non-CRM
system environment.
If you have further questions on these subjects, please refer to the Solution Management Optimization
Service System Administration.
R/3 Back-End 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
The table below lists transactions used for monitoring the CRM Server:
CRM Server Central Monitoring Activities / Monitoring Type Monitoring Frequency Periods
Functions and Events
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
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 back-end, the
lost for instance in the CDB CRM or the CDB is necessary