bpm for crm40

Manage mySAP CRM 4.0

Best Practice for Solution Management

Version Date: January 2005 The newest version of this Best Practice can be obtained through the SAP Solution Manager

Contents 1 Introduction.............................................................................................................................3

1.1 Applicability, Goals, and Requirements...............................................................................3 1.2 Best Practice Procedure.....................................................................................................4

1.2.1 Preliminary Tasks.......................................................................................................4 1.2.2 Monitoring Concepts ..................................................................................................4 1.2.3 Monitoring Procedure.................................................................................................4 1.2.4 Solution finding procedure..........................................................................................5 1.2.5 Legend ......................................................................................................................5

2 mySAP CRM...........................................................................................................................6 3 mySAP CRM Online Sales ......................................................................................................6

3.1 Sales Order Management...................................................................................................7 4 mySAP CRM Interaction Center Overview.............................................................................15

4.1 Interaction Center Building Blocks ....................................................................................16 4.2 Core Business Processes in SAP CRM Interaction Center................................................18

4.2.1 Inbound Telesales ....................................................................................................18 Outbound Telesales...............................................................................................................25 4.2.2 Complaint Management ...........................................................................................28

4.3 Scenario specific recommendations .................................................................................31 4.3.1 Memory Consumption by transaction CIC0...............................................................31 4.3.2 Statistical records (STAD) ........................................................................................32 4.3.3 Interpretation of response time of transaction CIC0 ..................................................32

5 mySAP CRM Field Sales Overview .......................................................................................34 5.1 Field Sales System Landscape.........................................................................................34

5.1.1 Sales order management.........................................................................................37 5.2 Further Information...........................................................................................................56

5.2.1 Integration of BW and CRM Field Sales ...................................................................56 5.2.2 Background Information and References for the Field Sales Scenario ......................57

5.3 Scenario specific Monitoring.............................................................................................61 5.3.1 Basic Monitoring Guidelines for the CRM Server ......................................................62 5.3.2 Basic Monitoring Guidelines for the Communication Station .....................................63 5.3.3 Basic Monitoring Guidelines for the Mobile Clients ...................................................63 5.3.4 Housekeeping for Mobile Clients ..............................................................................66 5.3.5 Application Troubleshooting on Mobile Client ...........................................................69

6 mySAP CRM ESelling Overview ..........................................................................................72

Best Practice: SAP Business Process Management for CRM

© 2005 SAP AG

2

2

6.1 ESelling System Landscape............................................................................................72 6.2 Core Business Processes in SAP CRM ESelling .............................................................75

6.2.1 B2B Sales Order Management.................................................................................75 6.2.2 B2C Sales Order Management ................................................................................87

6.3 SAP Recommendations for additional components...........................................................90 6.3.1 Security Recommendation for ESelling ...................................................................91

7 mySAP CRM Marketing and Analytics ...................................................................................93 7.1 Marketing System Landscape...........................................................................................93 7.2 Core Business Processes in SAP CRM Marketing and Analytics.......................................95

7.2.1 Marketing Planning and Campaign Management......................................................95 7.2.2 Trade Promotion Management (TPM) ....................................................................103 7.2.3 Business Partner Segmentation .............................................................................107

8 Generic Part........................................................................................................................ 113 8.1 Availability Check ........................................................................................................... 113 8.2 Connection to SAP Business Warehouse (BW)............................................................... 115 8.3 BDoc Monitoring and Handling ....................................................................................... 116

8.3.1 Monitoring.............................................................................................................. 116 8.3.2 Usage .................................................................................................................... 118

8.4 Interface Monitoring........................................................................................................ 119 8.5 Performance Monitoring ................................................................................................. 119

8.5.1 General information ...............................................................................................120 8.5.2 Procedure..............................................................................................................121 8.5.3 Transaction ST03...................................................................................................122 8.5.4 Transaction STAD..................................................................................................123 8.5.5 Transaction ST05...................................................................................................128 8.5.6 Transaction SE30 ..................................................................................................129

8.6 Batch Jobs .....................................................................................................................130 8.7 Mass data changes ........................................................................................................133

9 Further Information..............................................................................................................138 10 Appendix.............................................................................................................................139

10.1 General Monitoring Guidelines for the SAP CRM System and the SAP R/3 System....139 10.2 Middleware specific Monitoring Activities for the R/3 System ......................................141 10.3 Middleware specific Monitoring Activities for the CRM System....................................141

of 145

1 Introduction

1.1Applicability, Goals, and Requirements To ensure that this Best Practice is the one you need, consider the following goals and requirements.

Goal of Using this Service This Best Practice helps you set up a businessprocess management and application monitoring concept for your mySAP CRM solution, valid for CRM release 4.0. The concept aims to define procedures for business process oriented monitoring, error handling and escalation procedures for you company’s CRM core business process. This best practice is divided into five mayor areas: The first chapter deals with CRM Online which includes several steps that are generic to the other scenarios The following four chapters focus on the scenarios Interaction Center, Field Sales, ESelling and Marketing.. The last one, Generic Part, includes scenario independent topics like ATP, BW and so on. The procedure is based on the most common CRM environment, which consists of an SAP CRM System and an SAP R/3 System. The optional use of a SAP BW or a SAP APO system is also included. The procedures intend to ensure smooth and reliable flow of the core business process in order to meet your business requirements.

Alternative Practices You can have SAP experts deliver this Best Practice onsite by ordering a Solution Management Optimization (SMO) service known as the SAP Business Process Management service.

Staff and Skills Requirements To implement this Best Practice, you require the following teams: Application Management Team This team creates the CRM business process management concept and consists of experts from several areas of your company:

• Business department • Solution support organization (for example, the IT department and the Help Desk) • Implementation project team

Execution Team The execution team will be responsible for applying the resulting procedures derived from implementing this best practice. They include the following groups:

• Persons designated to perform business process oriented monitoring and ensure that the process runs smoothly (e.g. the Business Process Champion for each business process)

• All parties in your Solution Support Organization and IT department involved in monitoring (Application Support, Development Support, Program Scheduling Management, Software Monitoring Team, System Monitoring Team)

More information about roles and responsibilities of these teams can be found in the superordinate Best Practice General Business Process Management, which you can obtain through the SAP Solution Manager.

Necessary or Useful Trainings q CR500 CRM Middleware Overview q BC305 Advanced R/3 System Administration q BC 315 Workload Analysis q CR700 CRM Service q CR900 Analytical CRM


© 2005 SAP AG

4

4

System Requirements In case you want to set up Business Process Monitoring on the SAP Solution Manager, the SAP Solution Manager should be set up. Otherwise there are no special system requirements.

Duration and Timing Duration Creating a businessprocess management concept could take around one week per business process. Implementing the businessprocess management concept might take approximately an additional week. Timing The best time to apply this Best Practice is during the planning phase or during the implementation phase of your mySAP.com solution.

How to use this Best Practice Here you find a brief description of how you should proceed in using this document: • Read through the General Business Process Management Best Practice, available on the Service

Marketplace. This document explains you the procedure you should use to create a general business process management concept. It deals with questions like who is responsible to create what and what has to be documented in which order. The result will be a flow chart for your core business processes that includes the necessary technical and application details.

• At the beginning of the chapters dedicated to the five scenarios (Interaction Center, Field Sales, E Selling, Marketing and CRM Online) you will find a typical flow chart for the core business process and a description of the typical system landscape. They should be used as a guideline for writing down your process documentation.

• In the generic part you find information that is relevant for two or more scenarios. In case information from the generic part is relevant for a specific business process step in one of the scenarios; you will find a clear link to the corresponding chapter in the generic part.

1.2Best Practice Procedure 1.2.1Preliminary Tasks Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in the system: • Complete all installation and postinstallation actions and procedures including customizing • Ensure that the initial download has been successfully executed • Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations

resulting from customer problem messages • Implement all current SAP Support Packages upon availability

1.2.2Monitoring Concepts The monitoring procedures ensure that the technical processes meet the requirements for stability, performance and completeness. Monitoring must cover three areas: errors; performance and throughput; and processing progress and completeness. In the chapters dealing with the scenarios Interaction Center, Field Sales, ESelling, Marketing, CRM Online and the generic issues part and, you will find monitoring recommendations for each of the typical process steps. You should use them as a guideline for setting up your monitoring concept.

1.2.3Monitoring Procedure The core of this Best Practice is the monitoring concept for each business process step. For each of the business process steps you will find the following information:

• A detailed functional description of the process step • Monitoring activities for the process step

• Relevant issues of error handling, restartability and escalation


© 2005 SAP AG

5

5

• A monitoring object table listing each relevant monitoring object, showing the: o Monitoring object o Monitoring transaction or tool o Monitoring frequency o Indicator or error o Monitoring activity or error handling procedure o Responsible team

General monitoring activities that are valid for all or most scenarios are described in the Appendix. Monitoring activities that are special to one scenario, but cannot be related to one special step or are valid for many steps are described at the end of each chapter. Recommendations for performance monitoring can be found in the generic part of this document. The performance of the most important steps of your core business processes should be monitored on a regular basis. The monitoring procedure for performance monitoring of all steps that are executed on the CRM system is generally the same. Therefore you will only find specific performance monitoring recommendations on selected business process steps. For some steps it is possible to use a the tool for an automated monitoring, if available. Such a monitoring concept is optimally implemented using the Computer Center Management System (CCMS) in conjunction with the SAP Solution Manager. Most of the monitoring objects originate in the CCMS but can be implemented within the SAP Solution Manager and its functionality called SAP Business Process Monitoring that offers for example an extended alert handling. Incase this is possible you will find for the specific step a separate table indicating the automatic monitoring via CCMS and Solution Manager The SAP Business Process Monitoring within the SAP Solution Manager is the proactive and process oriented monitoring of the core business processes of your company. It includes the observation of all technical and business applicationspecific functions that are required for a smooth and reliable flow of the business processes. For further details on Business Process Monitoring please refer to http://service.sap.com/bpm.

1.2.4Solution finding procedure Generally in case of questions or problems that cannot be solved, forward the issue to the next support level. If the corresponding escalation path is not well defined, contact the Application Support. If you have identified a transaction, process step or SQL statement that has a bad performance, search for relevant information in the solution database of the solution manager. As next step search for related SAP Notes in the SAPNet. As input for the search, provide the relevant data that applies in the particular case (transaction, program, table, component, release, etc). If it is not possible for any of the defined support levels to provide a solution for a particular problem, open a customer problem message in the SAPNet R/3 frontend system. Under severe performance issues, we recommend ordering an EarlyWatch session with focus on performance tuning.

1.2.5 Legend

This symbol indicates you a paragraph from where you can navigate to another chapter of this document for more detailed information on a topic.

This symbol indicates you a paragraph from where you can navigate to another document within the SAP Service Marketplace for more detailed information on a topic.


© 2005 SAP AG

6

6

2 mySAP CRM SAP Customer Relationship Management (CRM) supports all “customerfacing” processes throughout the entire customer relationship life cycle from market segmentation and opportunities to postsales and customer service. It includes business scenarios such as mobile (or field) sales and service, customer interaction center, Internet sales and service as well as Marketing.

3 mySAP CRM Online Sales In the CRM Online Sales part of this Business Process Management Best Practice you will find information regarding those steps and processes that are common to several CRM scenarios. The following core business processes are considered to be the most vital processes for an SAP CRM Online installation:

• Sales Order Management • Sales Planning and Forecasting • Territory Management • Account and Contact Management • Activity Management • Contract Management and Leasing • Incentive and Commission Management • Sales Analytics

The management of the Sales order management business processes along with a processoriented monitoring concept including the various components of an SAP CRM Online solution based on the solution with a connected Backend is described in this Best Practice document. . For most customers this business process is the most critical one.

The graphic shows the typical hardware solution landscape for CRM Online with CRM, IPC, R/3 (as backend), APO (optional) and BW (optional) systems.

SAP CRM

RDBMS

App Server

SAP APO

RDBMS

App Server

IPC

SAP R/3

RDBMS

App Server

SAP BW

RDBMS

App Server

App Server


© 2005 SAP AG

7

7

These sections below are referenced in the corresponding business process steps of the other scenarios in the chapters below.

3.1Sales Order Management The Sales Order Management topic of the CRM Online part of this document deals with those steps involved in the sales order management process, that are common to the interaction center, field sales and eselling scenarios. We consider here in detail the process steps:

• Create one order document (lead, quotation, sales order …) • Determine price • Determine configuration • Check availability • Upload of the sales order to the R/3 backend.

The steps of this business process that are executed on the R/3 system are not discussed in this document in detail.

Process Workflow for Sales Order Management (Online Sales)

Business Process Step 1,2,3,4 or 8: Create one order document (CRM) As part of the sales management live cycle you can create leads, opportunities, inquiries, quotations, and/or sales orders. Any of these CRM one order documents can be created as the first document of the cycle, without having created the others before. Which of these documents are created in your CRM system strongly depends on your particular business process. For instance the user can create a quotation depending on the requests of the business partner. The quotation can have several line items with different configurable products. In this case the price can be determined and the availability of the product can be checked for each line item individually. If the quotation refers to an inquiry, two different ways can be realized to transform the inquiry into a quotation. 1. The user can create a quotation with reference to an inquiry. In this case two documents exist (quotation and inquiry). 2. The user converts the inquiry into a quotation by changing the status of the document. The original inquiry position becomes a quotation position. In this case, the inquiry is not preserved as an additional document.


© 2005 SAP AG

8

8

Also a sales order can be created in different ways. The sales order can be entered directly into the system upon request of the business partner or based on a quotation. Similar to the quotation, also in this case the price can be determined and the availability of the product can be checked for each line item individually. If the sales order refers to a quotation, two different ways can be realized to transform the quotation into a sales order. 1. The sales order can be created with reference to a quotation. In this case two documents exist (quotation and sales order). 2. A quotation can be transformed into a sales order by changing the status of the document. The original quotation position becomes a sales order position. In this case, the quotation is not preserved as an additional document. The monitoring activities and error handling procedures explained below do also apply for activities and complaints. However please be aware that activities and complaints are not uploaded to the backend system in standard.

Monitoring Activities Apart from safeguarding the general availability of the R/3 system, CRM server, IPC and CTI server, SAP recommends to monitor the objects listed in the following table in order to ensure the business step Create one order document. Monitoring Object

Monitor TA/Tool

Monit orFreq.

Indicator or Error

Monitoring Activity or Error Handling Procedure

Respon sibility

Escalation Procedure

Sales document consistency

SDIMA – Integrity Manager

Daily Check if all sales documents created in CRM have been consistently uploaded to the R/3 backend

Cross application monitoring team

Sales documents with errors

SLG1 Daily Error status (log class very important, important and less important)

Search for the object: CRM_DOCUMENT; Investigate the cause of the errors

Application monitoring team

Performanc e

ST03, STAD

Week ly and upon error

Long runtime See chapter performance monitoring


Contact system administrator

BDocs SMWP (CRM)

Daily Red light at Bdoc level

Investigate the cause in the Runtime Information tree


Queues SMWP (CRM)

Daily Queues are stopped

Investigate the cause in the Runtime Information tree


BW consistency (optional)

BW Monitor

Daily / weekl y

Check if all sales order data has been correctly uploaded to the BW system.


Automated monitoring via CCMS and Solution Manager Monitoring Object

Monitor TA/Tool

Monitor Freq.

Threshold Indicator or Error


Responsibility

Performance SolMan, CCMS

Weekly and upon error

To be set Long runtime Monitoring on function code level can be set up in SolMan using function code NEWT_POP 10MAIN_CREATE ( transaction SAPLCRM_10_MANAG_UI). For background information see chapter performance monitoring


Update errors

SolMan, CCMS, (SM13)

Daily or hourly

# of errors < 1

Update error related to transaction

Analyze reasons for update errors

Application monitoring


© 2005 SAP AG

9

9

Monitoring Object

Monitor TA/Tool

Monitor Freq.



Responsibility

crmd_order team Application log entries

SolMan, (SLG1)

Daily or hourly

# of errors < 1

Errors, warnings

Analyze reasons for errors and warnings


• If you find sales documents (opportunities, quotations, sales orders …) with error status in the application log (slg1), you can use the report CRM_ORDER_READ to find out if the content of the sales document is filled in correctly. For this fill in the object type (>Objects to be read) and the external ID (> Header GUID) in the selection screen of the report. Selection by more than one sales order number is possible. From here you can navigate directly to the related tables. We suggest you to set the trace level for the CRM application log messages for the members of the application monitoring team to ‘6’ (professional user). (This can also be set with the parameter CRM_USER_LEVEL)

• When the sales order is saved, a BDoc is generated. This BDoc transacts with the application database to request or write data. To ensure the normal flow of this business step, we recommend monitoring within the Middleware Portal (transaction SMWP) the state of BDocs on a daily basis. For all BDocs that are stopped, you should take a corrective action and investigate the reason.

• Monitor queues with the Middleware Portal (SMWP) as well the data transmission between the CRM and the R/3 system. Queues destined for the R/3 system should be relatively short and quickly processed. Investigate the cause for those queues in status stopped.

• Whenever you change your sales order related customizing (in R/3 or in CRM), you can check the consistency of the customizing. Use report CRM_ODE_CHECK_CFG to check the data exchange customizing and report CRM_ODE_CHECK_DOC to check the filling of certain fields as position, quantity, etc. For further questions regarding the replication between CRM and R/3 see the FAQnote 656224.

• Monitor regularly the RFC response time statistics with the statistical records monitor (STAD), system workload analysis monitor (st03) and SQL trace monitor (st05) in the CRM server and R/3 system.

• If you use a BW system and plan to upload sales order related information to that system, please refer to the document ‘SAP BW Consistency Check Guideline’, available on the SAP service marketplace, for detailed information on the procedures you should set up to check the consistency of your systems.

• The purpose of the “Data Integrity Manager” is to help to detect and repair data inconsistencies between the CRM database and the CDB or the connected R/3. For additional information please check the guide “Checking CrossComponent Data Integrity”. This can be found in the SAP Service Marketplace (http://service.sap.com), alias CRMMW. There select CRM powered by Netweaver > Process Integration > CRM Integration Services > System Landscape Management.

Error Handling, Restartability, and Escalation

Sales documents with errors In the daily operation of your business the CRM online user will have to handle with sales documents (e.g. sales orders) that contain errors and cannot be further processed automatically. In order to find the corrupted documents, search with transaction CRMD_ORDER in the CRM server for e.g. sales orders with status “contain errors”. You will get all orders that contain errors. For every order an error log is displayed. If you double click on every error item, you will get more information about why the error occurred and what you can do to solve it. An error log entry may reveal inconsistencies in, for example:

Business Partners: To check the business partner mapping, use transaction VD03 in R/3 Materials: Materials can be maintained in both the CRM server and the R/3 system. To find out where the inconsistencies come from, check product maintenance and the product hierarchy.

SAP recommends setting a workflow so the corrupted orders receive the required postprocessing.

http://service.sap.com/


© 2005 SAP AG

10

10

Depending on your customizing it may be that the status “contains errors” is not available for every one order document in your system.

To get the related BDocs of an erroneous order execute in transaction SE38 the program CRM_MESSAGES and set the ‘user degree’ to 9. Press the button ‘copy values’ and confirm the following popup. Then select in transaction CRMD_ORDER the affected document and watch the document flow. Here you will find all Bdocs belonging to the order and you can start with error analysis.

We recommend setting up a workflow so that corrupted orders trigger the required postprocessing. For example, typical errors are:

• SPC_BRIDGE error: this error is typically solved while restarting the IPC server. Before doing that you might want to save the IPC log file under another name since this file will be reset every time the IPC is restarted

• Partner determination errors: review the customizing In parallel you can check with transaction st22 if there are software dumps in R/3. If you find dumps from pricing programs, review those programs together with the development team. If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation.

Business Process Step 5 or 9: Determine price The price of the product that is displayed in the sales order or quotation is calculated in the IPC in background. The system recognizes the business partner and returns individual prices. Since release 2.0C the IPC does not have a separate database, but uses the CRM database to access the customizing data as well as the condition records. This assures that the same price is determined for all CRM scenarios. The master data that the IPC uses for pricing is typically maintained in the R/3 system and downloaded to the CRM database. Alternatively it is possible to maintain customizing and condition records directly in CRM, but except for the trade promotion management scenario (introduced with CRM 4.0), there is no upload of condition master data and customizing from CRM to R/3 available. In order to calculate the price of the products the IPC reads from its buffer or from the CRM database via RFC (Remote Function Call).

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. Monitoring Object

Monitor TA/Tool

Monit orFreq.

Indicator or Error


Responsibility

CPU of IPC Task Manager

Daily Long response times

CPU Software monitoring team

IPC Statistics

IPC Monitor

Daily Long response times

Command>Show statistics

Software monitoring team

Middleware portal

SMWP Daily Queues are stopped, data download errors

Control status of the queues. Review errors in log files. More info in SAP Note 430980


CCMS RZ20 Daily Red traffic lights Software monitoring team

• Monitor regularly the CPU consumption caused by the IPC in order to avoid performance issues for this business process step. In SAP Notes 372170 and 601800 you will find detailed information about how to monitor the CPU consumption in the IPC.

• Monitor regularly the outbound queue in R/3 with destination CRM. In normal conditions, the R/3 Adapter automatically processes the documents in the queue. If data remains in the queue, this symptom indicates that the R/3 Adapter is not working properly.


© 2005 SAP AG

11

11

• 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.

Error Handling, Restartability, and Escalation You notice that the price for products being displayed is not the right one. If support packages were recently applied, we recommend implementing the following checks to find out the cause of the issue.

• Check with transaction VA01 in R/3 if the pricing is working properly in R/3. If the pricing is also not working in R/3, you might review the pricing conditions in R/3, and once this is working properly, make a delta download to the CRM server. If customizing changes are done, an initial download is necessary. The customizing will be generated with report /SAPCND/RV12N001. See SAP Note 398078 to find more detailed information.

• Check with transaction SMWP in CRM if there are data in the outbound queue in R/3 System with destination CRM: if you find data in the queue this indicates that the R/3 Adapter is not processing the data in the queue automatically. Investigate why this happened in order to avoid this in the future.

• In parallel you can check with transaction st22 if there are software dumps in R/3. If you find dumps from pricing programs, review those programs together with the development team.

• If you could not find the cause yet and the pricing is nevertheless working properly in R/3, we would recommend you contact an expert CRM pricing consultant to review if the pricing procedures that you have implemented in R/3 are also supported in the IPC.

• If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation on component CRMIPC.

• You can restart the IPC server. If this happens in a productive environment, all users might get error messages when determining the price or the configuration of a product.

• In case of questions contact the system administrator or your development team. The process owner of this process must be aware of any functional and development issues.

Business Process Step 6 or 10: Determine configuration This is an optional step. Whenever configurable products are chosen, the IPC allows the users entering products in the quotation or sales order to choose exactly which product configuration they require. The configuration from a quotation can be copied to a sales order. The actual configuration of the product takes place in the Internet Pricing and Configurator. You call the interface up from the sales transaction. If the Internet Pricing and Configurator is not available, the product cannot be configured. The master data that the IPC uses for product configuration is maintained in the R/3 system and downloaded to the CRM database. When a configurable product is handled in a sales order transaction, the product is configured interactively by the IPC services. The IPC reads the configuration data via RFC from the CRM database. The Internet Pricing and Configurator combines the functions of the Sales Configuration Engine (SCE) and the Sales Pricing Engine (SPE).

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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error Monitoring Activity or Error Handling Procedure

Responsibility

CPU of IPC Task Manager

Daily Long response times CPU Software monitoring team

IPC Statistics

IPC Monitor

Command>Show statistics Software monitoring team


© 2005 SAP AG

12

12

Monitoring Object

Monitor TA/Tool

Monitor Freq.


Responsibility

ipcapplicati on.*.log

Upon error

Application error message

Check logfile for detailed information on error (SAP Note 658805)


CCMS RZ20 Daily Red traffic lights Check the areas with red traffic lights and find the cause for them.


• Monitor regularly the CPU consumption caused by the IPC in order to avoid performance issues for this business process step. In SAP Notes 372170 and 601800 you will find detailed information about how to monitor the CPU consumption in the IPC.

• To improve performances in the IPC in general, import the latest service packs and patches according to note 486061.

• Monitor regularly the IPC using the IPC Monitor tool. See more detailed information in the Documentation in the SAP Internet Pricing and Configurator directory of your IPC installation.

Error Handling, Restartability, and Escalation Troubleshooting while calling the IPC for product configuration: After checking the configuration icon at product level, you find there is a problem when the IPC is called for product configuration. If Support Packages were recently applied, SAP recommends checking whether the Support Package level in the IPC is the same as the Support Package level in the CRM server. If not, implement the same Support Package level in the IPC and in the CRM server. IPC uses ipcapplication.*.log file for logging in any errors or warnings that it has encountered. The default location for the logfile is the path pointed to by the local environment variable TEMP. Under Windows 2000 and XP this is normally the directory c:\Documents and Settings\<username>\Local Settings\Temp The quickest way to locate the TEMPfolder is to open Start>Run and type %temp% followed by return.

In addition, use transaction ST22 to check whether there are short dumps in the CRM server and R/3. If you find dumps from configuration programs, review those programs together with the development team.

If necessary, you can restart the J2EE server and IPC server. However, if you perform a restart in a productive environment, all users logged on at that moment will loose their sessions. In situations that may require escalation, contact the system administrator or your development team. The process owner of this process must be aware of any functional and development problems.

If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMIPC.

Business Process Step 7 or 11: Check Availability Availability check (ATP check) is used to check whether a product can be confirmed in a quotation or a sales order, based on the fact that enough stock is available or can be produced or purchased on time.

For more information regarding this step please refer to the Availability Check in the generic part of this document.

Business Process Step 13: Create sales order (R/3) After saving the sales order several processes are triggered on the backend: If the customer order is complete in the CRM, it will be replicated to the R/3 for the logistic settlement. This replication involves all order data including the confirmed quantities. Depending on the customized exchange scenario, the order is changeable in CRM or not. For a detailed description see notes 541113 and 705200.


© 2005 SAP AG

13

13

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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Responsibility

Sales order consistency

SDIMA On demand

After failure of one of the systems or if inconsistencies are expected

Check if all sales orders created in CRM have been consistently uploaded to the R/3 backend


Data download from R/3 to CRM

R3AM2 and R3AM3

Daily Log file entries, stucked queues

Investigate the cause Cross application monitoring team

Performance ST03, STAD




BDocs SMWP (CRM)


Investigate the cause Application monitoring team

Queues SMWP (CRM)



BW consistency (optional)

BW Monitor

Daily / weekly

Check if all sales order data has been correctly uploaded to the BW system.


3.1.1.1.1 Automated monitoring via CCMS and Solution Manager Monitoring Object

Monitor TA/Tool

Monitor Freq.



Responsibility



To be set Long runtime See chapter performance monitoring


Update errors


Daily or hourly

# of errors < 1

Update error related to transaction crmd_order



Application log entries

SolMan, (SLG1)

Daily or hourly

# of errors < 1

Errors, warnings



• Start transaction SDIMA on the CRM server to compare the sales orders in both systems on header or item level. The purpose of the “Data Integrity Manager” is to help to detect and repair data inconsistencies between the CRM database and the CDB or the connected R/3. For additional information please check the guide “Checking CrossComponent Data Integrity”. This can be found in the SAP Service Marketplace (http://service.sap.com), alias CRMMW. There select CRM powered by Netweaver > Process Integration > CRM Integration Services > System Landscape Management.

• Monitor with the Middleware Portal (SMWP) as well the data transmission between the CRM and the R/3 system. Queues destined for the backend system should be relatively short and quickly processed. Investigate the cause for those queues in status stopped.

• Monitor regularly the RFC response time statistics with the statistical records monitor (STAD), 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.



© 2005 SAP AG

14

14

• 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.

Error Handling, Restartability, and Escalation • For each BDoc an Error handling is maintained in transaction smw00. As an example, after 10

times unsuccessfully trying to process the BDoc CONGEN_OBJECT_WRITE an email will be sent to the responsible person. Pro BDoc the number of executions and an action must be defined and the required workflow must be set up in transaction swu3.

• Check that the code is working properly and if you do not find the cause of the issue, open a SAPNet message for further processing.


© 2005 SAP AG

15

15

4 mySAP CRM Interaction Center Overview The Interaction Center is a key technology of Customer Relationship Management (CRM) with mySAP. It is designed as a multichannel, blended business process interaction center to empower call centers to provide the highest possible level of customer service. It provides the technology for contact center operations. It integrates a highly customizable and fullfeatured front office with your backoffice as well as your entire range of customercentric processes. The Interaction Center integrates technology for any business transactions via phone, email, chat, paging, or Web call back. With CRM4.0 the Interaction Center WebClient was introduced. It can be fully integrated into a People Centric CRM (PCC), web based environment. From CRM 4.0 onwards, the SAP Enterprise Portal is used for PeopleCentric CRM. An iView for the ICWebclient is available. The most important differences between IC WebClient and IC WinClient are listed here:

IC WebClient • New BSP based Framework, runs in a

Browser • Currently uses the new ICI / BCB interface

for CTI • Usabilityoptimized views for certain

business process objects • Can integrate into CRM and R/3 objects

via PCC UI or WebGui

IC WinClient • Dynpro Based Framework, application

runs within SAP GUI • Currently only uses SAPphone interface

for CTI • Reuse of screens for business process

objects from CRM Online • Can integrate into CRM or R/3 objects via

new GUI session

ICWebClient is containing a Java Web application (ICSERVER) which is required to be deployed on the Java 2 Enterprise Edition (J2EE). Actual J2EE 6.20 and 6.40 is supported! The IC is developed with an open interface to support a variety of CTI middleware products, as well as telephony servers and switches. The IC also supports Interactive Voice Response (IVR) systems, which capture callattached data. The Integrated Communication Interface (ICI) supports the integration of nonSAP communication products with SAP components that use communication services. The new ICI is intended in particular for scenarios involving multiple communication channels, such as telephony, email, and chat, but it can also be used in singlechannel scenarios. It enables activities such as an agent accepting an inbound phone call, an agent deflecting an inbound chat request, or a supervisor monitoring queues. The ICI is only one of several components required to implement communication scenarios of this kind. Organizations use the IC in a variety of business scenarios including sales or service. For one company, the IC may be used as an inbound sales center, where agents enter sales orders, answer delivery inquiries, create return material authorizations, or update customer addresses. Another company might use the IC to register service requests for internal or external customers. Yet another company might only process email correspondence with their customers through the IC. Agents in an integrated call center may perform all of these activities. To satisfy customers, customerfacing employees require quick and easy access to the information about their customers and the transactions that will serve them. This requires an intuitive user interface that supports the method of communication. This is realized in mySAP CRM with the role based PeopleCentric User Interface (PCUI). PCUI is designed for integration in Enterprise Portal. For the user to logon to Enterprise Portal in a specific role, a relationship between the Portal user and the CRM system users must be created. There is no technical relationship between Portal role and CRM role. The relationship is accomplished by assigning for every Portal role that is assigned to a Portal user the according CRM role to the according CRMuser.

http://help.sap.com/saphelp_crm31/helpdata/en/36/3f4dc544b21ed1e10000009b38f985/content.htm


© 2005 SAP AG

16

16

4.1 Interaction Center Building Blocks

mySAP CRM Interaction Center

IC Sales IC Sales IC Service IC Service IC Marketing IC Marketing

CRM

Other scenarios e.g. Field Sales or Marketing IC Management IC Management

Agent WebClient

Agent WinClient

IC Manager Portal

Multichannel

R/3 IPC

Portal

Portal user

Portal role

CRM system

CRM user

Authorization

Navigation

(SSO)

CRM role


© 2005 SAP AG

17

17

The graphic above shows the abstract of a solution landscape for an Interaction Center. The central point of a typical installation is the CRM server. For the smooth and reliable operation of the core business processes it is required to ensure the general availability and performance of the following system components (if used):

• CRM Server • Backend System such as SAP R/3 • IPC

Basic instructions for the monitoring of these components are given in the Appendix. SAP delivers CRM with a special monitor set: CRM Middleware Alert Monitoring. This set includes monitors for the technical middleware components of the CRM CIC solution. It can be used via SAPGUI using transaction RZ20. For more detailed information about how to install this monitor see SAP Note 437187. For general information regarding the use of Computer Center Management System (CCMS) in combination with the SAP Solution Manager for central monitoring, refer to the SAP Best Practice for Solution Management “Central System Monitoring for mySAP.com” that you can download from the Solution Manager, if you have installed it, or from the Service Marketplace.

Monitoring in the mySAP CRM Interaction Center environment can be divided into the following areas: • Monitoring the endtoend message flow from the CRM to the R/3 System • Monitoring the queues located on the respective server systems • Monitor the R/3 Adapter components (Download objects, log file, queues, requests) • Monitor the network • Operating system performance monitoring • Database system performance monitoring • Error analysis

The following table briefly lists the monitoring functions associated to the CRM Server and the R/3 system.

Server Types Monitoring Function CRM Middleware Server

1. Monitor outbound queue, CRM middleware system è R/3 system 2. Monitor inbound queue, R/3 system è CRM middleware system 3. Monitor middleware message flow 4. Monitor flow control 5. Monitor the middleware log 6. Monitor status of BDocs 7. Monitor initial download from R/3 system 8. Monitor R/3 basis system 9. Monitor database 10. Monitor operating system 11. Monitor network throughput

R/3 System 1. Monitor outbound queue, R/3 system è CRM middleware system 2. Monitor gateway 3. Monitor R/3 basis system 4. Monitor database 5. Monitor operating system 6. Monitor network throughput

of 145

4.2Core Business Processes in SAP CRM Interaction Center

The following core business processes are considered to be the most vital processes for an SAP CRM Interaction Center installation:

• Inbound Telesales • Outbound Telesales • Complaint Management in IC

The management of these business processes along with a processoriented monitoring concept is described in this Best Practice document. At the end of this part you will find a chapter about general recommendations for the management of a SAP CRM Interaction Center.

4.2.1 Inbound Telesales The following diagram shows the business process steps covered in this monitoring concept. Depending on the configuration carried out in your project, some elements might appear different from the description in this document.

Process Workflow for Inbound Telesales

The business process: ‘Inbound Telesales’ describes the process where customers or sales prospects (consumers or enterprises) contact the interaction center to initiate a sales order. Furthermore, customers often ask for information about products or services before placing an order, or wish to gain information about the status of business transactions that have already been processed. The typical process starts with the initial contact of the customer with the interaction center. This contact can be represented by a phone call, an email or a fax.


© 2005 SAP AG

19

19

In case of a call this call is routed to a call queue. The customer can be identified with the ANI (Automatic Number Identification) automatically. After picking up the call, the agent validates and confirms the business partner. Emails and faxes are represented as work items in the agent inbox. The agent can process and execute each item, which also leads to an identification and confirmation of the sending customer. Following he can use the fact sheet to get additional information about the customer. The interactive script might be used for answering an incoming call. Depending on the request of the customer, the agent can provide information about a specific problem using the knowledge search. An opportunity or quotation might be created in advance before a sales order is created. By using the up, down or crossselling functionality of the CRM system, products can be proposed to the customer. Subsequently the agent creates the sales order. Prices and product configuration are determined in the Internet and Pricing Configurator (IPC). The availability check for the sales order can be performed in the APO or R/3 system. The saving of the sales order can trigger the sales order management in the connected backend. The agent maintains details of the interaction record as for example priority, reason, notes or description. When the interaction record is saved relevant key figures from interactions in the Interaction Center are transferred to the SAP Business Warehouse (SAP BW) for analysis purposes. The steps mentioned here are optional and the business process can be adjusted to the requirements of each customer. However the monitoring activities are not directly depending on the sequence or the completeness of the sample process described above and can be used almost independently.

4.2.1.1 Business Process Step 1: Routing call, email, fax to queue The routing of calls is hardware dependent and considers the availability of agents. Interactive voice response (IVR) might be used to support the routing. Emails and faxes can be routed dependent on business partner address details. Routing rules have to be maintained accordingly.

4.2.1.1.1 Monitoring Activities 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Responsibility

Integration test for incoming phone calls

Hardware dependent Monthly and upon error

No call throughput to agents

Check and monitor the incoming/ outgoing call transfer to the agents to ensure that no calls get lost

Software/ hardware monitoring team

Check routing of incoming calls

Hardware dependent Weekly and upon error

Wrong routing of calls to agents

Check and monitor the rules and processing of the routing for the incoming calls.


Check routing of emails and faxes

Compare routing rules (in CRMC_CIC_MAIL_E_RESP and CRMC_IC_MAIL_E_RESP) and routing results


Wrong routing of emails and faxes to agents inboxes

Check and monitor the rules and processing of the routing for the incoming emails and faxes.


4.2.1.1.2 Error Handling, Restartability, and Escalation In case of an error and escalation situation contact your system administrator or your telephony hardware/implementation partner for further assistance.

4.2.1.2 Business Process Step 2: Identify, confirm account/ contact person

When you answer an incoming call, the system automatically identifies the calling business partner (account) by Automatic Number Identification (ANI). A prerequisite for the identification of the business partner is the support from a telephone technology (e.g. ISDN). This transfers the number of the incoming call including the dialed number (e.g. a general 0800 number or a special number of an agent). This service is called DNIS (Dialed Number Identification Service). With this information the


© 2005 SAP AG

20

20

customer can be identified, if the number is assigned to a business partner in the system, and will be proposed to the agent before actually picking up the phone. This mapping of the number to the business partner can either be done on the CTI server (e.g. Genesys) or in the CRM system (SAPphone). In case you don’t use ANI your call center agent searches for the calling business partner, for instance by name or by business partner number. Their sender address or number identifies customers in case of incoming emails or faxes. If this is not possible the agent has to execute the search manually with other search criteria. Once the customer is identified and confirmed, business partner data is displayed in the interaction history, in the business partner search area and in the fact sheet. In the case of a new customer, you have to create a new business partner.

The call center agent can create a new business partner (BP) or a new contact person by pushing the corresponding buttons in the BP search environment. He has to specify all necessary data, as address data, function, IBase data, etc. If the agent finds out that some of the identified business partner data is wrong (e.g. the phone number of the contact person) he can maintain this as well. If there is an R/3 backend connected to the CRM system, the new/ changed business partner data may be replicated to the backend. (optional, not shown in the graphic).

4.2.1.2.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility



BP finding takes too long

See chapter performance monitoring


BP creation, data consistency

Bdoc monitoring

Daily Incorrect BP data in R/3

Check replication to R/3 Application monitoring team


Monitor TA/Tool

Monitor Freq.



Responsibility



To be set Long runtime Monitoring on function code level can be set up in SolMan using function codes CSEARCH_SEARCH. &IC1, CSEARCH_CONTINUE (Transaction CIC0). For background information see chapter performance monitoring


4.2.1.2.3 Error Handling, Restartability, and Escalation Make sure that the necessary indexes for the BP search (and your search criteria) are available in the system. If created business partners are not replicated to R/3, use CRMM_BUPA_MAP to replicate it again. If you could not find the cause of the problem with this checklist, open a SAPNet message (component CRMCICBPSEA/CRMICSEA) for further investigation. In general the business partner search is depending on several factors:


© 2005 SAP AG

21

21

• Number of master data (business partner) Duplicates have to be prevented by an appropriate strategy to keep the volume of business partner master data at a minimum level

• Quality of master data Inconsistent and duplicated entries have to be avoided to get the best search result as possible (e.g. no multiple hits due to duplicates)

• Search strategy depending on business process The way the agents perform the business partner search is completely depending on the information the customer provides. If possible selective criteria should be used like the customer number and also the use of asterisks (‘*’) should be avoided. This has a direct influence on performance.

4.2.1.3 Business Process Step 3 and 4: Retrieve information from fact sheet

The HTML based fact sheet provides you with an immediate and condensed overview of information about business partners taken from several sources such as business partner master data, statistical and transaction data. It enables you to see quickly and easily the most essential details about a customer. The information contained in the fact sheet is divided into information (info) blocks that group together certain kinds of data. The data itself not only is retrieved from the CRM system but also from other systems like SAP R/3 or BW.

4.2.1.3.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility






4.2.1.3.2 Error Handling, Restartability, and Escalation Consult note 490871 for performance problems, error messages and not working info blocks among others. If you cannot find the cause of the problem open a SAPNet message for further investigation (CRMCICHISCFA/CRMICCFA). The performance of the fact sheet is mainly depending on 2 factors:

• Amount of information in fact sheet Using the settings for the info blocks in the customizing can restrict the amount of data that will be displayed.

• Source of information The source of information has also a very big impact on the performance of the fact sheet. For example the response time for retrieving information from a connected R/3 backend is longer than just getting information from the CRM system. Establishing the network connection and transferring the data back to the CRM system cause this. In addition this puts load on the R/3 system and on the network. In general the data retrieved from connected systems should be kept to a minimum. In case of problems with data coming from other systems the analysis has to include the source system.

4.2.1.4 Business Process Step 5: Use script for answering Interactive scripts can be used to support the agent dealing with an incoming phone call. There are standardized text components available which give the agent the correct greeting phrase to welcome a customer on the phone, or remind him to ask all relevant questions to retrieve the required


© 2005 SAP AG

22

22

information needed for the business. Asked questions are dependent on the answer the customer has given, e.g. yes or no. This is realized with a tree structure of possible answers.

4.2.1.4.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility




See chapter performance monitoring.


4.2.1.4.2 Error Handling, Restartability, and Escalation If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation (component CRMCICSCR/CRMICSCR)

4.2.1.5 Business Process Step 6 and 7: Search in knowledge database In the Interaction Center, agents use the knowledge search to find solutions to problems or other issues that are reported by customers through channels such as telephone, email or fax. It also can be used to get additional information about products or for general questions from the business partner. The knowledge search is the entry point for searches in a knowledge base. In the IC WinClient the knowledge base is the Solution Database (SDB). In the IC WebClient, the SDB is the default knowledge base, but agents can switch and search other knowledge bases as well. In the IC WinClient the search engine is TREX (Text Retrieval and Information Extraction). In the IC WebClient, the default search engine also is TREX but other search engines could be used. The actual search (Step 7 “Search Solution”) is performed in the search engine for the knowledge search, the TREX (Text Retrieval and Information Extraction), which is the default search engine in the IC WinClient. In the IC WebClient, the default search engine also is TREX but other search engines could be used.

4.2.1.5.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility

Performance ST03, STAD Weekly and upon error

Long response times



Execution of knowledge search

Report CRM_SAF_TOOL_DIAGNOSIS


Errors in knowledge search

Analyse report results Application monitoring team

TREX server TREX server installation guide Weekly and upon error

Knowledge search not working

Check the TREX server installation and whether the TREX service is running


4.2.1.5.2 Error Handling, Restartability, and Escalation If the knowledge search returns bad results, the customizing of the search engine might have wrong settings and should be adjusted following note 457764. Please check SAP Note 702639 for a hint on performance improvement for the SAF diagnosis tool.


© 2005 SAP AG

23

23

For more information on the Software Agent Framework (SAF) and it’s diagnosis tool please go to the SAP Library search for SAF or follow the link below. http://aiokeh.wdf.sap.corp:1080/SAPIKS2/logonFromUrl.sap?_LOIO=B24EF97483FB11D68865 00008658ACB2&_SCLASS=IWB_STRUCT&_SLOIO=83C72C55F7F3463BAC2922EF300EAB45 &LANGUAGE=EN&RELEASE=500&IWB_INDUSTRY=BBPCRM&IWB_COUNTRY=&TMP_IWB_T ASK=PREVIEW2&_CLASS=IWB_EXTHLP

If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation (component CRMCICIIA/CRMICSOL for step 6 and component EPKMTRX for step 7).

4.2.1.6 Business Process Step 8, 9, 13: Create Opportunity, Create Quotation, Create Sales Order

For the process steps Create opportunity, Create Quotation, Create sales order (CRM) please review the corresponding section in the Sales Order Management section in the CRM Online part.


Monitor TA/Tool

Monitor Freq.



Responsibility



To be set Long runtime Monitoring on function code level can be set up in SolMan using function code 10MAIN_CREATE (transaction CIC0). For background information see chapter performance monitoring


4.2.1.7 Business Process Step 10: Search, propose, configure product For the process step Search, propose, configure product please review the corresponding section in the Sales Order Management section in the CRM Online part.

4.2.1.8

4.2.1.9 Business Process Step 11, 12: Determine price. Determine configuration

For the process steps Determine Price and Determine Configuration please review the corresponding section in the Pricing section in the CRM Online part.

4.2.1.10 Business Process Step 14 and 15: Check availability (APO/ R/3)

For the process step Check availability(APO/ R/3) please review the corresponding section in the Availability Check section in the CRM Online part.

4.2.1.11 Business Process Step 16: Create sales order (R/3) For the process step Create sales order (R/3) please review the corresponding section in the Sales Order Management section in the CRM Online part.

4.2.1.12 Business Process Step 17: Maintain interaction record To complete the interaction record the agent can, for example, document the content of the call with the customer. Therefore he can add further information, as notes and attachments, to the interaction record or create follow up activities.

http://aiokeh.wdf.sap.corp:1080/SAPIKS2/logonFromUrl.sap?_LOIO=B24EF97483FB11D6886500008658ACB2&_SCLASS=IWB_STRUCT&_SLOIO=83C72C55F7F3463BAC2922EF300EAB45&LANGUAGE=EN&RELEASE=500&IWB_INDUSTRY=BBPCRM&IWB_COUNTRY=&TMP_IWB_TASK=PREVIEW2&_CLASS=IWB_EXTHLP


© 2005 SAP AG

24

24

In order to end the interaction with the customer, the agent chooses the ‘End Contact’ button. This clears all fields in the interaction center user interface so that the agent can continue working with the next customer.

For the process step Maintain interaction record please review the section in the Activity Management section in the CRM Online part.

4.2.1.13 Business Process Step 18: Update interaction center statistics

Relevant key figures of the interactions from the Interaction Center are passed to the SAP Business Information Warehouse (SAP BW). For the process step Update Interaction Center statistics please review the corresponding section in the Connection to SAP Business Warehouse (BW) section in the CRM Online part.


© 2005 SAP AG

25

25

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.

Process Workflow for Outbound Telesales

The business process: ‘Outbound Call’ describes the process of an agent initiating calls to customers or sales prospects (consumers or enterprises). This process supports the execution of sales campaigns and periodic calls with call list management. On the basis of a call list, the agent selects a business partner from the call list. Alternatively he can place a call manually via the telephone functionality in the interaction center user interface. He also can use the call preparation functionality to get information about the customer from the fact sheet in beforehand of the actual call. After initiating the call, the agent has to validate the business partner. He can use interactive scripts in order to explain the purpose of his call to the customer. Lead, opportunity or quotation documents might be created. The agent might also provide information about up, down or crossselling products for the specific customer. Consequently the agent can place a sales order. The price will be determined in the Internet and Pricing Configurator (IPC). The availability check for the sales orders can be performed in the APO or R/3 system. Saving the order can trigger the sales order management in the connected backend. Finally the agent can create a follow up activity or maintain the content of the call in the interaction record before it gets saved. When the interaction record is saved relevant key figures from interactions in the Interaction Center are transferred to the SAP Business Warehouse (SAP BW) for analysis purposes. The 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.

The following detailed description of the process steps with the monitoring procedure and activities for the Outbound call focuses only on the process steps which are different to the process steps mentioned in the process description above (see chapter: Inbound Telesales).


© 2005 SAP AG

26

26

4.2.1.14 Business Process Step 1: Create/Assign call list Managers can create call lists for specific target groups or a range of business partners based on maintained calling hours. They maintain call list details such as assigning call lists to agents, assigning scripts to call lists, and copying, searching, or moving call lists. Finally every call from the call list is represented by an activity in the CRM system. Interaction Center agents can execute the call lists directly from the IC WinClient or WebClient user interface.

4.2.1.14.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility


Long response times



4.2.1.14.2 Error Handling, Restartability, and Escalation If call lists have to be split to get a smaller size à check note 669459: Call list splitting If you could not find the cause of the problem open a SAPNet message for further investigation using the component CRMCICCAMCAL or CRMICCAL.

4.2.1.15 Business Process Step 2: Select call from call list To select the business partner from the call list in the WinClient user interface, the agent has to open the campaign workspace and to click on a Call List that he wants to execute. This opens the Call List browser workspace with the business partners the agent can make a call to. In the WebClient the agent navigates to the call list view where he gets a list of assigned call lists. He can select one and display the calls for the selected list.

4.2.1.15.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility


Long response times



4.2.1.15.2 Error Handling, Restartability, and Escalation If call lists have to be split to get a smaller size à check note 669459: Call list splitting If you could not find the cause of the problem open a SAPNet message for further investigation using the component CRMCICCAMCAL.

4.2.1.16 Business Process Step 5: Execute call After selecting the business partner to be called, a click on the dial button from the toolbar dials the number. In case of multiple numbers a popup is shown to choose the right number. The business partner is searched and confirmed automatically, the corresponding activity is opened. If the agent wants to place an individual outbound call (not from call list), then he can use the consult button to make a call.

4.2.1.16.1 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.


© 2005 SAP AG

27

27

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility


Long response times



4.2.1.16.2 Error Handling, Restartability, and Escalation If you could not find the cause of the problem open a SAPNet message for further investigation (component CRMCICCOMTEL or CRMICCHATEL).

4.2.1.17 Business Process Step 6: Execute Call (Communication Mgmt Software)

The execution of the call is depending on the hardware you are using. Usually the call is initiated in the SAPphone application of the CRM system. SAPphone integrates telephony functions in SAP applications. This allows data to be exchanged between computer and telephone processes. CIC uses the SAPphone CTI interface to communicate all soft phone controls of the Front Office screen and the different work modes and status of the agent. Then the CTI links the call to the connected phone system (PBX) where it is physically generated.

4.2.1.17.1 Monitoring Activities The monitoring activities of this process step strongly depend on the used telephony system.

4.2.1.17.2 Error Handling, Restartability, and Escalation In case of an error and escalation situation contact your system administrator or your telephony hardware/implementation partner for further assistance. If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation (component BCSRVCOMTEL).

4.2.1.18 Business Process Step 8: Create lead For the process step Create lead please review the Sales Order Management process in the CRM Online part.


© 2005 SAP AG

28

28

4.2.2Complaint 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.

Process Workflow for Complaint Management

The business process: ‘Complaint management’ describes the process of handling customer complaint requests in the interaction center. Agents can create complaint documents for issues that have a limited degree of complexity, for example, complaints involving only one business partner and for which no other related complaints are currently open. On creation of a complaint, agents immediately see information that supports them in their interaction with the customer, such as the warranties and service contracts that are valid for faulty products, or the reaction time stipulated in a service level agreement. Created complaints can reference on CRM billing documents or documents from integrated systems such as deliveries or invoices from the SAP R/3. This scenario variant (especially the mentioned features) runs on the Interaction Center WinClient only.

The typical process starts with an identified and confirmed business partner (account) from a phone or email contact. The fact sheet can be used to get some additional information about the customer. The interactive script is helpful to guide the agent to ask the best questions and to determine the right way about handling the customer’s complaint. Depending on the request of the customer the agent might provide information about a specific problem using the search in the knowledge database. Then a complaint is created. Agents record the complaint reason and problem and can trigger the creation of credit memos, return requests, or substitute deliveries, which are then handled by the back office. Finally the agent can create a follow up activity or maintain the content of the call in the interaction record before it gets saved. When the interaction record is saved relevant key figures from interactions in the Interaction Center are transferred to the SAP Business Warehouse (SAP BW) for analysis purposes.

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

29

29

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).

4.2.2.1 Business Process Step 8: Create complaint You can create complaints for products or services that customers are dissatisfied with. Complaints can be productrelated or have no reference to products.

Please also review the section Sales Order Management in the CRM Online part for general monitoring activities for this step.


Monitor TA/Tool

Monitor Freq.



Responsibility



To be set Long runtime Monitoring on function code level can be set up in SolMan using function code 10MAIN_CREATE (transaction CIC0). For background information see chapter performance monitoring


4.2.2.1.2 Error Handling, Restartability, and Escalation If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation (component CRMCICBTX).

4.2.2.2 Business Process Step 9, 10: Replicate return request item, Replicate substitute delivery item

After saving the complaint in SAP CRM, the returns item is replicated in a sales order in SAP R/3 for the purpose of logistics processing. This means that a sales order is automatically created with a corresponding returns item.

4.2.2.2.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility

BDocs SMWP (CRM)



Queues SMWP (CRM)



4.2.2.2.2 Error Handling, Restartability, and Escalation If you could not find the cause of a problem open a SAPNet message for further investigation (component CRMBTXBFIF).

4.2.2.3 Business Process Step 10: Replicate substitute delivery item You create a subitem of category ‘Substitute Delivery’ for the main complaints item. After saving the complaint in SAP CRM, the substitute delivery item is replicated in a sales order item in SAP R/3 for the purpose of logistics processing.


© 2005 SAP AG

30

30

4.2.2.3.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility

BDocs SMWP (CRM)



Queues SMWP (CRM)



4.2.2.3.2 Error Handling, Restartability, and Escalation If you could not find the cause of a problem open a SAPNet message for further investigation (component CRMBTXBFIF).

of 145

4.3Scenario specific recommendations In this chapter you will find some general recommendation to improve the management and performance of the SAP CRM Interaction Center. As well hints are given to locate functional problems and to interpret the CIC response times.

4.3.1Memory Consumption by transaction CIC0 Many functions of the whole CRM solution are integrated into the Interaction Center scenario. Because of this, the memory allocated during a contact is not completely released after the contact is finished.

Smart restart option There is a 'smart restart' solution available (as of SP12 for CRM 3.0) where you can set a time and/or memory limit for a transaction restart. When an agent starts CIC0, time and memory counters are set. When one of the defined limits is exceeded AND the agent pushes the 'End Contact' button, the CIC0 will be restarted. Due to the restart, the memory is released and thereafter available for other users again.

It depends on various factors how the restart options in CRMC_CIC_RESTART have to be set up.

It has to be found out which amount of memory a user needs and how much he can get at all. This depends on

• available memory of the application servers • CIC configuration • number of contacts per time • every action the agent performs • ...

Transaction SM04 can be used to monitor the memory consumption and to see how fast it grows for every user. In the syslog (SM21) you can see whether a restart was performed due to the memory limit or due to the time limit.

Usually a value of 30 40 MB as limit is sufficient but this has to be verified using SM04 and the syslog. The time limit is less important. It can be set to 999 when a memory limit is set as recommended. But if there are users, which only use the CIC temporarily, then a time limit could be useful, too. Because in that case unnecessary allocated memory could be prevented by the restart.

From a functional point of view the limitations mentioned in note 542090 have to be considered. In case you are using a Genesys Gplus Adapter, please refer to SAP Note 586037.

In case you have implemented owndeveloped workspaces, their data can be lost at End Contact, when a restart is performed. To solve this problem and to present an unchanged framework to the agent, the concept described in SAP Note 550027 can be used. Please refer to this Note and set up this concept for your owndeveloped workspaces.

CIC Memory trace (as of CRM 3.1, SP04) Using transaction CRM_CIC_TRACE the memory consumption while working with CIC0 can be observed. The trace can be started in the same session or in parallel mode. The result list of the trace displays the deltas in memory consumption between the different events and programs that are executed during the CIC processes. Therefore steps with a high memory allocation can be found easily.


© 2005 SAP AG

32

32

4.3.2Statistical records (STAD) The table below represents common CIC actions and their corresponding entries in transaction STAD: Description: performed action in CIC Transaction/Program, Fcode, CUA internal command: corresponding STAD entries

Description Transaction/ Program

Fcode CUA internal command

Search business partner CIC0 CSEA CSEARCH_SEARCH Select business partner from popup (in case of multiple hits)

CIC0 &IC1 &IC1

Confirm business partner CIC0 CSEA CSEARCH_CONTINUE Reset search fields CIC0 CSEA CSEARCH_DELETE Display fact sheet SAPMHTTP Execute action box transaction CIC0 %_GC %_GC * Execute search in locator CIC0 BUS_ BUS_LOCATOR_SRCH_GO Select inbox view CIC0 INBO INBOX_SEL_VIEW Display email CIC_SOFMVIEW Change to tabstrip in application area

CIC0 AA_T AA_TAB* * = tabstrip number

Change to tabstrip in navigation area

CIC0 NA_T NA_TAB* * = tabstrip number

End contact CIC0 ECNT Any hitting of the return key (= “Enter”)

CIC0 RFSH

If there are problems to reproduce a certain problem the STAD entries may be helpful to figure out the last steps until a specific point of time. The display mode ‘Show business transactions sums’ has to be chosen to see the corresponding entries in STAD.

For more information regarding STAD see also the chapter Performance Monitoring in the generic part of this document.

4.3.3 Interpretation of response time of transaction CIC0 If the CRM system mostly is used for CIC scenarios then transaction "CIC0" may have one of the highest "Average Response Time" results in the monitoring transactions STAD or ST03N. A high value for the average response time may lead to the assumption that the performance is very bad regarding this transaction. In Transaction CIC0 the response time frequently includes a high RollIn + Wait time. In most cases this RollIn + Wait time is caused by the following effects:

• Executing a CIC actionbox transaction an OnLine transaction is called in a remote system and the agent continues the work there (creating of sales order in R/3). As long as the mode of the remote system remains open, the CRM system holds an RFC for the remote system.

• The agent signals the Telephony Server to be ready to receive the next inbound call. In the process, the system starts an RFC for the Telephony Server that is only terminated if a new call is received.

The system adds the duration of these RFCs to the RollIn + Wait time and thus also to the response time of Transaction CIC0. Therefore the average response time contains also times, during which agents work in remote systems or wait for inbound calls. It cannot be used as a criterion for the performance of the CIC0 transaction.


© 2005 SAP AG

33

33

Refer to note 594904 to get further information about alternatives to get a significant statement about the CIC0 performance. For more information regarding performance monitoring see also the chapter Performance Monitoring in the generic part of this document.


© 2005 SAP AG

34

34

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

5.1Field Sales System Landscape The main components of a CRMFSA installation are summarized in the following table and shown schematically in the subsequent figure.

CRM Server The CRM Server is used for central data storage and distribution unit for the CRM components. Data from all mobile clients is consolidated in one central database on the CRM Server and replicated to the clients according to predetermined replication rules. The CRM Server also handles the messaging between clients and server, temporarily stores information and guarantees its delivery. Data is exchanged with an R/3 system and other external systems. The CRM Server contains the CRM Middleware, which is the heart of the Field Sales scenario. It handles the controlled data exchange (replication, synchronization or distribution) with other systems such as mobile clients, backend systems and data warehouses. Especially for mobile clients, a replication mechanism ensures a consistent and uptodate data set on the distributed local databases. Message queuing ensures delivery and processing of data. Software adapters are used to connect to external systems. They map and convert data to various formats. In addition, the CRM application components exchange data with the middleware layer using a CRM adapter, e.g. XIF. Furthermore the CRM Server hosts the CRM server applications as well as the consolidated database (CDB) in which all the CRM data is stored centrally. The CDB is a logical component of the entire CRM database. SAP CRM Release 4.0 provides also an independent CRM solution that can be executable with thirdparty backend systems as well as SAP R/3. The CRM Server 4.0 is based on SAP Release 6.20 (SAP Web Application Server).

Communication Station

The Communication Station acts primarily as a communication server. It hosts the Microsoft Transaction Service (MTS), the technique for data transfer, and the SAP DCOM connector. The Communication Station transforms DCOM (Distributed Component Object Model) calls from the mobile clients into RFC calls and hands them to the CRM Servers Middleware and vice versa. The data that is to be exchanged is accumulated and stored in queues at both ends (mobile clients and CRM Server). The data distribution follows a flexible set of replication rules, where business objects are assigned to mobile clients. The reason for a separate communication server is load balancing, i.e. to bundle the various connections between the single mobile clients and the CRM server. There is only one connection between the communication station and the CRM server. The Communication Station is available for Windows NT 4.0 and


© 2005 SAP AG

35

35

Windows 2000.

Mobile Development Workstation

The Development Workstation hosts the Mobile Application Studio (MAS); an integrated development environment that provides the tools that are used to customize and develop each layer of the mobile component client software. For example, adding a new information field, modifying the layout of an existing screen, or amending the rules associated with the processing of information. The MAS requires a connection to the Mobile Application Repository on the Mobile Repository Server, but it is recommended to install the MAS on its own machine or laptop. This allows having several developers working on customization changes simultaneously. This machine contains also software for system administration and maintenance tasks. The software includes the following components: Authorization Management Tool client (AMT), Mobile System Maintenance application and Upgrade Console.

Mobile Repository Server

The Mobile Repository Server contains the Mobile Application Repository (MAR) as an MS SQL Server database and Mobile Application Repository services and tools like the MAR Central Server service (used to lock development objects in a multiuser development environment) and the ARS Transport Agent (used to transport development objects from one repository to another). The Transport Agent service is also needed to distribute mobile client software upgrades via CRM server to mobile clients.

Mobile Clients The Mobile Client software is the CRM functionality on a mobile terminal either with or without (as workgroup client) its own dataset. Typically Field Sales users have certain mobile client software with its own database and an IPC (see below) on their laptops that enables them to work offline. In a Workgroup Production Environment only one common user database exists on the Workgroup Server. Mobile clients connect to the CRM Server from time to time via phone or network to exchange data, accumulated and stored in queues at both ends. This connection is established via the Communication Station. Mobile clients may also be permanently connected to the server.

IPC The IPC (Internet Pricing & Configurator) processes product configurations and calculates product prices. This is a Java application that is installed on the Mobile Client. It enables ffline product configuration and pricing at the point of sale on the laptop, using the same configuration and pricing rules and models as in the CRM Server or the R/3 System.

SAP R/3 (optional) The R/3 system is connected to the CRM Server as a backend system and provides additional business functionality such as sales and/or distribution and/or financial accounting, e.g. it continues the sales order management cycle when a sales order is created in CRM.

SAP APO (optional)

SAP APO is part of the supply chain management. SAP APO comprises tools for realtime planning and decision support. With CRM Mobile Application SAP APO can be used as optional software component in order to perform product availability checks (ATP) when sales orders are created in CRM (Reservations cannot be done).

SAP Business Warehouse (BW) (optional)

SAP BW is an analysis tool that gathers and refines information from internal and external sources containing customizable reporting tools from any perspective and predefined information models, reports, analyses and key performance indicators. You can analyze data from operative SAP applications as well from any other business applications and external data sources such as databases, online services and the Internet. SAP BW can be used as an optional software component for all SAP CRM scenarios in order to create reports and replicate them to the different offline working users using the Middleware mechanisms. The


© 2005 SAP AG

36

36

BW analysis is replicated as MS Excel spreadsheets and will be available within the Mobile Client in the component reports.

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 (CRM Host) • Communication station • Mobile client

Mobile Client(s)

Mobile Cl ient

Communication Station

MTS DCOM

Connector

CRM Host

CRM Server

Middleware

OLTP R/3

PlugIn

IPC

Mobile Admin Workstation

Author ization Management Tool

IPC MS SQL

Mobile Client

Mobile Development Workstation

Mobile Appl ication Studio

Mobi le Client

IPC

IPC

Internet Pr icing and Configurator

RDBMS

RDBMS

BW

RDBMS

APO

RDBMS

Mobile Repository Server

Mobile Application Repository Services

and Tools

MS SQL

MS SQL

MS SQL

Basic instructions for the monitoring of the CRM Server, the IPC and the SAP R/3 are given in the Appendix. Instructions for monitoring the Communication station and the Mobile Clients are given at the end of this chapter. SAP delivers CRM with a special Middleware monitor set. This set includes monitors for the technical middleware components of the CRMFS solution. It was implemented based on the CCMS Alert Monitoring infrastructure. It can be used via SAPGUI using transaction RZ20 where it is available under the SAP CRM Monitor Templates’ monitor sets with the name ‘CRM’. The CRM Middleware Alert Monitor checks the most important processes within the CRM Middleware and generates alerts if critical situations occur. For further information on Middleware Monitoring please also check the document “mySAP CRM Monitoring 3.0”, that can be found under www.service.sap.com/solutionmanagerbp > topic area > mySAP CRM Monitoring (far down the list)

Most important of these processes are: • Processing of the CRMspecific qRFC inbound and outbound queues in the CRM System • Processing of the CRMspecific qRFC outbound queues in the R/3 System • Processing the BDoc messages in the flow • Processing Replication/Realignment

http://www.service.sap.com/solutionmanagerbp


© 2005 SAP AG

37

37

All R/3bound QRFCs can be monitored in R/3 by using standard R/3 AlertMonitoring functionality (e.g. Short dumps, Update errors, Syslog). To detect possible critical situations within your main processing we recommend setting up CRM Middleware Alert Monitoring. For more information on the Middleware Alert Monitoring, please refer to the following

SAPNet Notes: 437187 CRM Middleware Alert Monitoring 441269 Setting up tRFC/qRFC monitoring in the alert monitor 485826 Corrections to CCMS tRFC/qRFC Monitor

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 CRMField Sales installation:

• Sales order management • Business Partner Management • Activity Management • Opportunity Management • Campaign Execution • Download from the CRM server to the mobile clients • Upload from the mobile clients to the CRM server

This Best Practice document describes the management of the business process Sales order management and a processoriented monitoring concept including the various components of a CRM Field Sales solution. For most customers this process is the most critical one.

5.1.1Sales order management Sales order management in the Field Sales scenario typically begins with the creation of an inquiry, a quotation or a sales order (generally speaking with the creation of a sales document) on a mobile client, e.g. as consequence of a customer contact of a sales representative. To create a sales document header information and items have to be specified: Sales documents can be generated on basis of opportunities (also on basis of campaigns and listings that are not discussed in this document). Configurable products can be processed using the IPC. If the product price for a business partner is to be determined in the mobile sales application, the field sales representative enters the order details (such as item, quantity, tax jurisdiction code, and so on). The system calls the IPC on the mobile client that accesses the latest state sales tax rates for the product. The system than calculates the price accordingly. If document layouts have been defined, sales documents can be generated using a layout and then be printed out. As soon as a sales representative considers a sales document as complete, it can be finished and is thus ready for upload to the CRM server. When the next upload is performed using the program ConnTrans with the send option, all finished sales documents are uploaded to the CRM server. On the CRM server the sales document (inquiry, quotation or sales order) is created and saved to the consolidated database (CDB). The data is also uploaded to an backend system, e.g. an R/3 System, if connected. In this document the scenario is described with an R/3 System connected. The sales document is then created in R/3.


https://websmp104.sap-ag.de/~form/handler?_APP=00200682500000001266&_EVENT=DISPLAY


© 2005 SAP AG

38

38

In parallel the sales order is replicated to the mobile clients (the order with status “to be distributed”). Later the CRM gets a confirmation of the backend system and the status of the sales order is changed to “successfully distributed”. This status change is replicated to all mobile clients that have appropriate subscriptions.

Process Workflow for Sales Order Management (Field Sales)

5.1.1.1.1 Monitoring Procedure Please note that for this special business process (or rather this special scenario) a stepwise monitoring concept is hard to define. Sales representatives initiate all steps that run on mobile clients. Typically sales representatives hardly do any monitoring activities other than informing an administrator, the hot line or similar in case of errors. Furthermore all steps running on the CRM server as well as on a possible backend system run automatically. When setting up a proper monitoring concept the general monitoring activities have to be defined clearly and have to run on a regular basis. Please read the Specific Monitoring part at the end of this chapter carefully and include the described actions to your monitoring concept.

5.1.1.2 Business Process Step 1, 2, 5,: Create Inquiry, Quotation, Sales Order

This is an optional step that takes place on the mobile client. An inquiry is preceded by (and based on) a customer request to the company whether certain goods are sold at a predefined price. The sales information of an inquiry that is given by the sales representative is not binding. The request can refer to materials or services, conditions and, if necessary, delivery deadlines. The intention of an inquiry is to support a business partner’s ability to make informed purchasing decisions. An inquiry is created with header and line items like an inquiry in R/3. Inquiries are sales transactions, that is, transaction types with the business transaction category ‘sales’. The business function for inquiries is found at item level for a business transaction. They are only indicated as inquiries by the system status Inquiry. A business transaction can, for example, also contain services or order items, in addition to inquiry items. An inquiry status is given at item level. Inquiries are processed converting the item status to status quotation or order.


© 2005 SAP AG

39

39

5.1.1.2.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror

Monitor ing Activity or Er ror Handling Procedure

Responsibility

Sales document

Applica tion trouble shooting on mobile clients

Upon error Application error message

Contact Application monitoring team or system administrator (depending on error) for error handling

Sales representative/end user

Performance Upon performance problems

Long response time of transaction

Contact application monitoring team or system administrator for housekeeping and/or tracing


Performance SQL Profiler and Trace, SQL/ Query Analyzer

On demand of sales representativ e (in case of reported performance problems)

Response time of transaction

SQL Trace of transaction and query analysis

Application monitoring team or system administrator

Mobile client House keeping for Mobile Clients

At least twice a year and on demand (in case of reported performance problems)

Application monitoring team or System Administrator

5.1.1.2.2 Error Handling, Restartability, and Escalation If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMMSASAD.

5.1.1.3 Business Process Step 2: Create Quotation This is an optional step that takes place on the mobile client. A quotation is a legally binding agreement to deliver specific products or a selection of a certain amount of products in a specified timeframe at a predefined price. A quotation has a validity period. Within the validity period, the customer has the option of placing an order within the agreed conditions with reference to the quotation, or to cancel a contract. A customer quotation can refer to a partner sales activity or can be used by the sales area to reply to a customer inquiry. A quotation is created with header and line items like a quotation in R/3. You can manually create a quotation, and determine items and details, with or without using the IPC, i.e. with or without configuration and/or pricing. Quotations are sales transactions, that is, transaction types with the business transaction category ‘sales’. The business function for quotations is found at item level for a business transaction. They are only indicated as quotations by the system status Quotation. A business transaction can, for example, also contain services or order items, in addition to quotation items. A quotation can be created with reference to an inquiry. Sales representatives manually create a quotation, and determine items and details, with or without using the IPC, i.e. with or without configuration and/or pricing (see below). Quotation items are checked with a separate ATP profile for availability, which can be defined in Customizing for the item category – see also generic part: ATP for sales documents.

5.1.1.3.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility


© 2005 SAP AG

40

40

Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

Sales document




Sales representative/e nd user














5.1.1.4 Business Process Step 5: Create Sales Order This is a step that takes place on the mobile clients. A sales order is created with header and line items like a sales order in R/3. A sales order can also be created as ‘followup’ document of a quotation. Sales representatives manually create an order, and determine items and details, with or without using the IPC, i.e. with or without configuration and/or pricing (see below).

5.1.1.4.1 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.

Sales document















© 2005 SAP AG

41

41





5.1.1.5 Business Process Step 3,4,6 or 7: Determine the Price of the Product

This is an optional step that takes place on the mobile client. The price of a product is determined by the IPC (Internet Pricing and Configurator). The IPC uses the condition technique for pricing, like R/3. The master data for the pricing is downloaded from the central pricing system. Pricing can begin after the field sales representative has started pricing in order entry or quotation entry. The system calculates the price for each item in the background using the data that has been entered (e.g. customer, material and date) and the master data set up in the system (e.g. material price, discounts). It then adds all of the items to find the overall result of the document. To see which conditions the system has used for pricing, the salesperson calls up the item pricing screen (display or change mode). In the change mode, the calculated amount or the conditions used for pricing can be changed, provided the relevant condition types have been defined as changeable. If required, the currency units or the units of measure can also be changed. Once a unit has been entered, the system automatically converts the condition value into the document currency. If all of the manual changes are to be deleted, the price determination can be carried out again. The system then calculates a new price on the basis of the existing master data, without taking into account any of the manual input. The pricing result appears in the document.

Tax Process: The tax determination allows the field sales force to determine taxes on products, in order to provide business partners with accurate, uptodate pricing information. When the salesperson wants to determine the product price for a business partner the order details (such as item, quantity, tax jurisdiction code, and so on) have to be entered. The system then calls the IPC. The IPC starts pricing and calls the TTE for tax determination. The TTE triggers the tax determination function and determines the applicable tax calculation procedure. Then the IPC completes pricing and calculates tax amount. Finally the IPC returns price and tax amount to the mobile sales application.

5.1.1.5.1 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.

Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

ipcapplication .*.log



Sales representative/e nd user or Application monitoring team




Sales representative/ end user

Performance SQL Profiler and

On demand of sales representativ e (in case of





© 2005 SAP AG

42

42

Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

Trace, SQL/ Query Analyzer

reported performance problems)




5.1.1.5.2 Error Handling, Restartability, and Escalation If a pricing problem on a mobile client cannot be solved easily, the same sales document example should be investigated on the CRM Server as a matter of principle. The 'same' example means a sales document of the same sales document type, with the same soldto party, the same sales organization and the same product(s). If the same errors occur the problem should be solved on the CRM Server rather on the client (or first on the CRM Server and subsequently on the client). If the problem does not occur on the CRM Server and the description below or the troubleshooting tips in the Appendix do not help, a message has to be opened and ideally the log files (see below) should be attached.

Pricing Analysis The "Pricing Analysis"trace shows how the IPC has searched for condition records during the pricing of a sales document. The "Pricing Analysis"trace is the first place to look, when pricing works technically, but the wrong price is calculated because for example not all expected condition records have been found by the IPC. The trace shows:

• Which condition tables where searched by the IPC and which searchcriteria have been used. • Which requirements/userexits were checked during pricing and the result of the checks

To turn on the “Pricing Analysis”trace in Mobile Sales. Until CRM 4.0 SP03 "Pricing Analysis"trace is activated on sales documentlevel by setting the checkbox "Pricing Analysis" in the "Details" tileset. Starting with CRM 4.0 SP03 the "Pricing Analysis"trace is activated on user level, rather than on the sales document level. To enable the "Pricing Analysis"trace: Open the Mobile Client Application à Select the component "Employees" à Click on "Settings". In the tile "Settings" set the check box "Pricing Analysis".

To view the Pricing Analysis: In the component "Sales Transactions" create a new sales document and add line items and save. Go to the tileset "Item Pricing Conditions”. The "Analysis" button should now be enabled. Click on the "Analysis" button to view the trace of the steps performed by the IPC during the pricing of the line items. When the "Pricing Analysis"trace is turned on, the performance of pricing is reduced, because the IPC has to collect trace information. Always turn off the "Pricing Analysis"trace, when you do not need it. The "Pricing Analysis"trace should not be turned on during productive use of the application due to the impact on performance.

The IPC logfile (ipcapplication.*.log) contains the following information (errors and warnings) produced by the IPC:

• Error and warning messages when customizing data is missing or incomplete. • Warnings when condition master data tables are missing.

The IPC logfile is the first place to look for more information when pricing or configuration does not work. The logfile is not overwritten when the application is restarted.

You can locate the ipcapplication.*.log file as follows: By default the IPC writes a logfile called ipcapplication.0.log, until it reaches the size of 1 MB. The IPC now starts writing into a new logfile called ipcapplication.1.log. When this file has also reached a size of 1MB, the first logfile ipcapplication.0.log is overwritten. The number of logfiles, their size and the name of the logfiles can be customized. The procedure is


© 2005 SAP AG

43

43

the same as for the IPC in the CRMOnline scenario. Refer to IPC specific documentation. The default location for the logfile is the path pointed to by the local environment variable TEMP. Under Windows 2000 and XP this is normally the directory c:\Documents and Settings\<user name>\Local Settings\Temp The quickest way to locate the TEMPfolder is to open Start>Run and type %temp% followed by return.

The following Field Salesspecific trace information can be found in the IPC logfile. The IPC can be configured to produce additional Mobile Sales specific traceinformation. The trace will then contain the following additional information:

• All IPC methods called by Field Sales • For which object the methods was called (i.e. the sales document or lineitem guid) • The input parameters of the methods • The output parameters of the methods • The duration of the call in Java.

To enable the logging of the additional traceinformation you have to change the properties file "logging. properties". This file can be found under the folder <installation path>\SAP\IPC\lib\properties In this file uncomment the following lines by removing the preceding "#"

Setting to enable the logging: # Trace for Mobile Sales com.sap.spc.beans.logs = log [Unknown] com.sap.spc.beans.severity = PATH

Setting to disable logging: # Trace for Mobile Sales #com.sap.spc.beans.logs = log [Unknown] #com.sap.spc.beans.severity = PATH

IMPORTANT: The writing of the additional traceinformation affects performance! Turn it off when not needed by commenting the above lines again.

For the Field Sales scenario the IPC requires SUN JRE version 1.3.1_05 or later, but not SUN JRE 1.4 or later (see above). The SAPInst installer for IPC 4.0 executes all installation steps automatically. Please refer to the SAP Note 0433855 for detailed information on Java Runtime Environment for Mobile IPC 3.0/3.1/4.0.

If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMMSAIPCPRI.

5.1.1.6 Business Process Step 4 or 7: Configure the Product This is an optional step that takes place on the mobile client. If the sales representative creates a sales order for a configurable product, the configuration is performed using the IPC (Internet Pricing and Configurator). The IPC is realized as a standard Java interface. The master data used for product configuration is maintained in R/3 and downloaded to the mobile client. When visiting customers the IPC enables the field sales representatives to discuss their customer’s requirements, with a view to presenting them one or more quotations for different combinations of product options (variants). Whenever a salesperson enters a configurable product as an item in a quotation or sales order Configure has to be chosen. A screen appears where the salesperson assigns values to the characteristics of the product, according to the product options required by the customer. This screen is CRM Mobile’s interface to the IPC. Once the configuration is complete, the salesperson can proceed with the quotation or sales order in the usual way. The configuration data is uploaded to the CRM Server for further processing with the next upload.

5.1.1.6.1 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

44

44

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. Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

ipcapplication .*.log



Sales representative/e nd user or Application monitoring team

Performanc e

Upon performanc e problems

Long response time of transactio n



Performanc e

SQL Profiler and Trace, SQL/Qu ery Analyze r

On demand of sales representati ve (in case of reported performanc e problems)

Response time of transactio n



Mobile client Housek eeping for Mobile Clients

At least twice a year and on demand (in case of reported performanc e problems)


5.1.1.6.2 Error Handling, Restartability, and Escalation Please note that if you do not use configuration on the mobile client, the import manager should be disabled for performance reasons. You can disable the import manager by setting the following registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\SAP\MSA\SCE\parameters\ImportManagerSupport' to 'FALSE'. You may enable the import manager again by setting the key to 'TRUE'.

If a configuration problem on a mobile client cannot be solved easily, the same sales document example should be investigated on the CRM Server as a matter of principle. The 'same' example means a sales document of the same sales doc type, with the same soldto party, the same sales organization and the same product(s). If the same errors occur the problem should be solved on the CRM Server rather on the client (or first on the CRM Server and subsequently on the client). If the problem does not occur on the CRM Server and the description below or the troubleshooting tips in the Appendix do not help, a message has to be opened and ideally the log files should be attached. If there are any problems with the IPC call, first check the Java Version.

IPC uses ipcapplication.*.log file for logging in any errors or warnings that it has encountered. The default location for the logfile is the path pointed to by the local environment variable TEMP. Under Windows 2000 and XP this is normally the directory c:\Documents and Settings\<username>\Local Settings\Temp The quickest way to locate the TEMPfolder 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 CRMMSAIPCCFG.


© 2005 SAP AG

45

45

5.1.1.7 Business Process Step 8: Generate for printing This is an optional step that takes place on the laptop. A printout of the sales order can be made through the mobile client. The sales representative chooses button “Generate” for generating a Microsoft Word document based on a layout that has to be selected for printing. Before this function can be used, at least one document layout of a relevant type needs to be defined.

5.1.1.7.1 Error Handling, Restartability, and Escalation Typically an error occurs if no layout for this sales document could be found. Please refer to the MSY application help for detailed information on designing layouts. Standard layouts, provided by SAP, can be imported via MSY application. Please refer to the SAP Note 620722. If you are unable to generate layouts using the configuration data please refer to the SAP Note 766345. The reason is the changed configuration data model in CRM 4.0. Configuration data is not stored in the SMOCUVAL table anymore but for performance reasons is stored as XML in the SMOCUCFG table. The new interfaces for document generation are available from Field Sales 4.0 SP05 and onwards.

Other SAP Notes: 737733 Enhanced features for Document Generation 766334 Printing Configuration Characterstics using doc generation 766345 Interfaces to extract configuration XML in MSA 40

If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMMSASAD.

5.1.1.8 Business Process Step 9: Submit sales document This is a step that takes place on the mobile client. Once the sales order has been put in its final form, the ‘Submit’ button has to be used. To submit a sales document; indicates that a sales document is ready for upload to CRM Online. If you have created several versions of a quotation for a business partner, you would ideally only submit the final one for upload that is, the one that has become effective. Once a sales document is submitted, it enters the outbound queue, and is uploaded to CRM Online the next time you synchronize data. After the sales document is available in CRM Enterprise you should not change it any more on the laptop, as you do not know if it has already been processed and thus your changes won’t have any effect any more (for instance, changing the amount of an orderitem, if the order is already shipped). You can therefore customize Mobile Sales either by making a sales document readonly, after it has been marked for submission, or making it still is available to specific employees for editing. From CRM 4.0 SP04 onwards users can modify documents which have been submitted to/downloaded from CRM server. You can modify the following on the mobile client: Items, Partners, Business data, notes and attachments. It is not allowed to delete any of the above objects. In order to maintain data consistency, editing is restricted in a way that only one sales rep (laptop user) at the same time will be able to do updates on the same document.

The update scenario (new functionality of MSA SAD 4.0) requires a partner with a partner function, which acts as token. Means the partner who is assigned to this token partner function only can modify the current sales document. The token partner function can be specified through the Sales Doc Customizing. The token partner function is of type employee. The partner function type for the same is 0008. Please refer to the SAP Note 725187 for detailed information on the sales transaction update scenario.

5.1.1.8.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

BDOC SMQ1 Client Console

Check if BDOC STFC_WRITE_TO TCPIC has been added to the

Sales representative


© 2005 SAP AG

46

46

Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

à Data Transfer àQueue Monitor àOutbou ndQueue

outbound queue

Sales document

Applicati ontroubles hooting onmobile clients

Upon error Applicatio n error message


Sales representative /end user

Performanc e

Upon performanc e problems

Long response time of transactio n


Sales representative /end user

Performanc e

SQL Profiler and Trace, SQL/Qu ery Analyze r

On demand of sales representati ve (in case of reported performanc e problems)

Response time of transactio n



Mobile client Houseke eping for Mobile Clients




5.1.1.9 Business Process Step 10: Perform upload (ConnTrans) This is a step that is started on the mobile client. The sales representative can upload new data by dialing up a modem connection (or by connecting via network) to the CRM server and starting the program Conntrans.exe on the mobile client. The data from the outbound queue in the mobile client is uploaded the CRM Enterprise server. Conntrans starts the Message Transfer Service Client that takes BDocs from the outbound queue of the mobile client and sends it to the Message Transfer Service Server that is located on the communication station. In addition, the ConnTrans_Log.xml file is generated that contains runtime information associated with the execution of ConnTrans. CRM Mobile sends data with a synchronization BDoc to MW. The data is mapped into a messaging BDoc and goes via the CRM adapter to the validation system CRM Online.

For messaging BDoc types, the name of the validation function module must be specified (field SMW3FDBDOCVALIFUMO). For synchronization BDoc types, the name of the mapping class (implementing interface IF_SMW_MAP) must be populated, if the synchronization BDoc type is linked to a messaging BDoc type (required to transfer data changes from mobile to CRM online). The link between a mBDoc and a sBDoc is established with the BDocModeler (transaction SBDM on the CRM server).


© 2005 SAP AG

47

47

5.1.1.9.1 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.

Monitor ing Object

Monitor TA/Tool

Monitor Frequ.

Indicator or Er ror

Monitor ing Acitivity or Er ror Handling Procedure

Responsibility

Outbound queue and logfile on mobile client

Client Console Each time ConnTrans is used

Monitor the outbound queue on the mobile client. View the logfile in the in client console.


Errors, warnings

ConnTrans_Log.xml Upon error Check logfile for detailed information on error


Errors, warnings

TransferService.log fileon communication station

Upon error Check logfile for detailed information on error


Errors, warnings

TransferService.log file on mobile client



Performance MS Windows NT Performance Monitor on mobile client and communication station

On demand Lon runtime

Check operating system load System administrator

Inbound Queue

SMQ2 on CRM Server

On demand Monitoring inbound queue on CRM Server If the queue has status STOP, this might be a Customizing problem in the CRM application

System administrator

BDoc SMW01(SMW02 and SMW03) on CRM Server

Upon error Check if Bdoc (SALESDOCGEN_OBJECT_WRITE) is there. If this is not the case the inbound queue may be not registered. Analysing Bdoc messages and perform required actions, e.g. BDoc messages with status beginning with E (red traffic light) need manual correction and retry, see also BDoc Monitoring and Handling.


TRFC Monitoring

SM58 on CRM Server (R&R)

Upon error Monitor all transactional RFCs (tRFCs) processed on the CRM Server


ConnTrans Performance

SMWMCOMM on CRM Server

Upon error Monitor ConnTrans performance and data exchange


Connection DCOM Connector Monitor on CRM Server

Upon error Monitor connection components System administrator

Message flow statistics

SMWMFLOW on CRM server

Upon error Use this as a starting point for analyzing performance problems


Flow Definitions

SMO8FD on CRM server

Upon error Check consistency of Flow definitions


Replication queues

SMOHQUEUE on CRM server (R&R)

Upon error Display information about the status and content of the replication and realignment queues in the clients defined in the CRM Server



© 2005 SAP AG

48

48

Monitor ing Object

Monitor TA/Tool

Monitor Frequ.

Indicator or Er ror


Responsibility

Performance SQL Profiler and Trace, SQL/Query Analyzer

In case of performance problems

Long runtime



Performance Transaction STAD/ Transaction ST05 on CRM server and R/3 System


Long runtime

See chapter performance monitoring Application monitoring team

5.1.1.9.2 Error Handling, Restartability, and Escalation On the Mobile Client the ConnTrans_Log.xml file is generated that contains runtime information associated with the execution of ConnTrans. You can specify default values for logging and UI related options in the ConnTrans_Startup.xml file. As a result, when you invoke ConnTrans, the default settings are read from this file and accordingly the data synchronization is performed. ConnTrans generates an XML file (StatisticsLog.xml) that captures statistics such as time taken to process the different stages (Send, Receive, and Import) of the data synchronization process. The system administrator can use this file to analyze data related to the performance of ConnTrans.

If you face any problems with Conntrans or the BDoc Layer, you should apply the SAP Note 708378 before opening an OSS message. The Note contains the link to the Note 716052 (HotFix For CRM 4.0 Mobile Client).

The basic performance issue for the data upload is the performance of the communication line (Telephone; ISDN, DSL internal network). These communication lines differ significantly in speed. The workload on the client (“clearing MW_Qout”) is neglectible. Other components affected are the Comm Station (data is sent though the Commstation, DCOM calls are transferred into RFC calls and vice versa) and the CRM Server, where the incoming data has to be processed (Inbound Queue, SMQ2). Usually the load for all components during Data Upload can be neglected as only a small amount of data is processed

In case of performance problems the traces on the CRM server have to be switched on before starting the ConnTrans.exe. Unfortunately every service of the flow on the CRM server could be processed by a different user. Therefore you must run the trace with user “*” and distinguish between the trace records belonging to the BDOC processing and the trace records belonging to other processes. The best is no other user is logged on to the CRM server.

XML Data Synchronization

The data synchronization between the mobile client and the CRM server in the form of XML messages is supported from mySAP CRM 4.0 SP04 onwards. XML message synchronization:

• Reduces the message content on the wire significantly compared to RFC structures

• Enables data exchange with a Unicode CRM server which was not possible using the RFC structures

XML data synchronization is applicable in the following scenarios:

Data Exchange with a Unicode CRM +Server

If the CRM server is Unicode enabled, then the data exchange between the mobile client and the CRM server is performed in the form of XML messages only.

Data Exchange with a NonUnicode CRM Server

If the CRM server is not Unicode enabled, then, by default, the data exchange between the mobile client and the CRM server is performed through RFC structures. However, you can enable the data exchange to be performed in the form of XML messages for a particular site. To do this:

1. In the Administration Console, under Site Attributes, select the Send XML Messages option.

2. Using Client Console, assign the mobile client to the XML enabled site

Data Exchange with an XML Enabled Workgroup Server site


© 2005 SAP AG

49

49

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 CRMMTFWTL for problems on a mobile client and CRMMW COM for problems in data transfer.

5.1.1.10 Business Process Step 11, 13 or 17: Create Inquiry, Create Quotation, Create Sales Order

5.1.1.10.1 This is an automated step on the CRM server that is preceded by the upload of an inquiry from a mobile client. A BDOc has been forwarded to specific inbound client queue in the CRM system and is processed now from the inbound queue. Afterwards the CRM database is updated.

5.1.1.10.2 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. Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

Data consistency

Crmd_or der

Upon error

Verify that changes have been made in CRM server From here you can also go to the application log that logs application errors.


BDoc SMW01( SMW02 and SMW03) on CRM Server

Upon error

Analysing Bdoc messages and perform required actions, e.g. BDoc messages with status beginning with E (red traffic light) need manual correction and retry, see also BDoc Monitoring and Handling.



Monitor TA/Tool

Monitor Freq.



Responsibility



To be set Long runtime Monitoring on function code level can be set up in SolMan using function code NEWT_POP 10MAIN_CREATE (Program SAPLCRM_10_MANAG_UI). For background information see chapter performance monitoring


Update SolMan, CCMS,

Daily or # of errors Update error related to

Analyze reasons for update Application monitoring


© 2005 SAP AG

50

50

Monitoring Object

Monitor TA/Tool

Monitor Freq.



Responsibility

errors (SM13) hourly < 1 transaction crmd_order

errors team


SolMan, (SLG1)

Daily or hourly

# of errors < 1

Errors, warnings



5.1.1.10.4 Error Handling, Restartability, and Escalation If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMBTXSLOQUT.

5.1.1.11 Business Process Step 13: Create Quotation This is an automated step on the CRM server that is preceded by the upload of a quotation from a mobile client. A BDOc has been forwarded to specific inbound client queue in the CRM system and is processed now from the inbound queue. Afterwards crm database and cdb are updated. 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.

5.1.1.11.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

Crmd_or der

Upon error




Upon error



Performance Transacti on STAD / Transacti on ST05 on CRM server and R/3 System


Long runtime



5.1.1.11.2 Error Handling, Restartability, and Escalation If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMBTXSLOQUT.

5.1.1.12 Business Process Step 17: Create Sales Order This is an automated step on the CRM server that is preceded by the upload of an inquiry from a mobile client. A BDOc has been forwarded to specific inbound client queue in the CRM system and is


© 2005 SAP AG

51

51

processed now from the inbound queue. Afterwards CRM database and CDB are updated. The sales order is then forwarded to backend system via CRM outbound queue. In CRM the sales order is send to the R/3 system via request. In parallel the sales order is replicated to the mobile clients (order in status “to be distributed”). Later the CRM gets a confirmation of the R/3 system and the status of the sales order is changed to “successfully distributed” . This status change is replicated to the mobile client.

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.

5.1.1.12.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

Crmd_or der

Upon error




Upon error



Performance Transacti on STAD / Transacti on ST05 on CRM server and R/3 System


Long runtime



5.1.1.12.2 Error Handling, Restartability, and Escalation If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMBTXSLO.

5.1.1.13 Business Process Step 20: Create Sales Document (R/3) This is a step that takes place on the R/3 System that is connected as backend server in this scenario. To trigger further processing of the business transactions created in the CRM Online system, the sales documents are transferred to the R/3 system via CRM Middleware. Here, three logistic processes to finish the order processing can occur: shipping, billing and transfer to accounting. The data to process is received from the CRM Server via the R/3 inbound queue. In 4.0 the site concept is used. In this example the backend site is one site for the R/3 backend system. All publications for replication to R/3 system are bulk delivered by SAP. Only the subscribed business objects can be uploaded to the backend system. To create the sales order it is booked in over a BAPI (like creating a sales order in R/3). The backend system then performs the rest of the sales document management cycle depending on the settings of the order management system. The document can be accessed for further processing by an authorized sales clerk to view or change the document, to check the document flow and to create follow up documents (e.g. delivery, billing document).

The available exchange scenarios for Sales Documents are described in the SAP Note 705200. If you use a CRM server release 4.0 or higher with an R/3 system release 4.70 or higher, data exchange


© 2005 SAP AG

52

52

scenario A is available (see SAP Note 642944). As of CRM Release 4.0 Support Package 04, you have the option to create sales orders both in the CRM Server and in the R/3 System and to change them. You can make the changes independently of the system in which the order was originally created. This way you can change sales orders at any time on the CRM mobile client as well. The sales document update scenario between CRMServer and R/3 can be activated by making the appropriate table entries in table CRMC_SCENARIOid_change_active (on CRM Server side) and CRMPAROLTP (on R/3side). If this scenario is active the 2nd digit of field CRMD_ORDERADM_H scenario will always be defaulted with ‘A’ (no matter if the order is created/updated in CRM or R/3).

You can only use interdependent changes in sales orders and quotations if you are using SAP CRM 4.0 SP04 and SAP R/3 4.7 from plug in 2003.1 onwards. If you are using SAP CRM 4.0 with SP01, 02 or 03 and SAP R/3 4.7, you can use update scenarios. If you are using different release combinations, you can only use the functions available for data exchange up to that point. You can get information about this in the SAP Help Portal under SAP CrossIndustry Solutions → SAP Customer Relationship Management and the required Release as well as in SAP Note 541113.

Please also see Business Process Step: Create sales order (R/3) in section CRM Online.

5.1.1.13.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Frequ.

Indicator or Er ror


Respon sibility

VA06 If error has been detected on CRM Server

Verify that the document has been posted to the R/3


SE16 If error has been detected during MW monitoring/reported

Verify that changes have been posted to the R/3 server




Long runtime




Monitor TA/Tool

Monitor Freq.



Responsibility





Update errors


Daily or hourly

# of errors < 1

Update error related to transaction crmd_order




SolMan, (SLG1)

Daily or hourly

# of errors < 1

Errors, warnings



5.1.1.13.3 Error Handling, Restartability, and Escalation Warnings related to the transferred document can also be viewed on the CRM Server, e.g. in case of incompleteness. Use transaction R3AC6 and enter the following settings:

• Key: R3A_SALES • Parameter name: COLLECT_WARNINGS • Parameter value: X


© 2005 SAP AG

53

53

Tip: When tracing on the R/3 system please note the following: On the CRM server use transaction SM59. Choose R/3 connections. Find out the destination to backend system (<SID>CLNT<productive client>). Doubleclick the destination and you find the RFC user. Trace this user for the duration of the sales transaction. 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 SLSSO.

5.1.1.14 Business Process Step 21: Save Sales Document to CDB This is an automated step that takes place on the CRM server. The CDB (consolidated database) is the logical overall database of a Mobile Sales/Service system. It is located on the CRM server and contains all the data that is supposed to be distributed. It is a subset of the database on the CRM server. Before the replication the CDB is updated (for example with the sales document number). In case of a realignment the sales document BDoc is first replicated to the original recipients and then the realignment is done asynchronously. This means a delete BDoc is send to the mobile clients that should not get the data anymore and a sales document BDoc is send to the mobile client which get the information now. The CDB has the following performance advantages:

• Fast realignment of data • Fast recovery of a mobile client database

All the data that has been uploaded from the mobile client regarding the sales document (either opportunity or sales order) is stored to the CDB. Data flow: CRM Online fills a messaging BDoc with the validated data. This messaging BDoc is mapped into synchronization BDoc (here some CRM Mobile only fields are added) that gets then persisted into CDB.

You should activate the mobile bridge for sales documents when setting up Mobile Sales. The path where the Mobile bridge entries can be maintained is Transaction 'SPRO' Customer Relationship Management>CRM Middleware and Related Components >Mobile Scenario Setup>Activate Mapping functions. For detailed information refer to the SAP Note 632700 and 629861.

5.1.1.14.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Freq.

Indicator or Er ror


Responsibility

SMOVBAK SE16 Upon error

Verify that changes have been written to the CDB tables



Upon error




Monitor TA/Tool

Monitor Freq.



Responsibility



To be set Long runtime Monitoring on program level can be set up in SolMan using Program SALESDOCGEN_O_W_CDB. For background information see chapter performance monitoring



© 2005 SAP AG

54

54

5.1.1.14.3

5.1.1.14.4 Error Handling, Restartability, and Escalation If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMMSAADPSAD

5.1.1.15 Business Process Step 22, 23: Replicate to Mobile Clients The replication and realignment service distributes the BDoc (as confirmation) to the laptops which have subscribed this data. Subscription determines the distribution of data to sites based on previously defined publications. The assignment of a subscription to one or more mobile sites triggers the actual replication of data to the sites. Data is extracted from the CDB after the subscription has been assigned. The Mobile Client subsequently receives the change information.

List of Publications recommended for working with Sales Documents:

Sales Documents by Business Partner – Intelligent

Sales Documents by Business Partner and Sales Area – Intelligent

Business Transaction Customizing download – Bulk

Customer Hierarchy – Bulk

Customizing objects – Bulk

Customizing objects II – Bulk

Customizing objects III – Bulk

Customizing objects (Mobile Sales Specific) – Bulk

Employee Bulk – Bulk

User by Employee – Intelligent

Authorizations – Bulk

Authorsations2 – Bulk

Service Customizing – Bulk

Customizing ATP

5.1.1.15.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Frequ.

Indicator or Er ror


Respon sibility

Queue demon SMOHQUEUE Upon error No data is replicated

Check if the queue demon is running. If the queue demon is not running, no data is extracted, the outbound queue remains empty and no data is replicated.


Replication objects

SMOEAC Upon error No data is replicated

Check if object that should be downloaded to the mobile client has a proper subscription.



Monitor TA/Tool

Monitor Freq.



Responsibility

Queues SolMan, CCMS

Hourly # of blocked queues < 1, # of entries / queue <

Check in transaction smq1, smq2, smohqueue for the queues with errors

System Administrator, Application monitoring team


© 2005 SAP AG

55

55

Monitoring Object

Monitor TA/Tool

Monitor Freq.



Responsibility

40 000 Performance SolMan,

CCMS Weekly and upon error

To be set Long runtime

Monitoring on program level can be set up in SolMan using Program CGCAPGEN_OBJ_WRITE_RRR. For background information see chapter performance monitoring


5.1.1.15.3

5.1.1.15.4 Error Handling, Restartability, and Escalation If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMMWCOM.

5.1.1.16 Business Process Step 23: Perform Download (ConnTrans) This is a step that is initiated on the mobile client. In Principle the process of the data download is the same as for data upload. Now data is transferred from the Middleware’s Outbound Queue (CRM Server, check transaction smq1) via the communication station and is sent to the inbound Queue of the Mobile Client. The amount of data usually is much higher then on upload. As for data upload, for Data Download the critical factor is the connection speed. The downloaded data is now stored in table MW_Qin on the mobile client and will now be processed (data will be transferred to the appropriate tables). For this process the main factor is the overall system performance especially the performance of the database. The performance of the database is additionally dependent on the database configuration and the fragmentation of the database on your local disk. Please note, that also here different Bdocs have different processing times.

5.1.1.16.1 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. Monitor ing Object

Monitor TA/Tool

Monitor Frequ.

Indicator or Er ror


Responsibility

Inbound queue and logfile on mobile client

Client Console Each time ConnTrans is used

Monitor the inbound queue on the mobile client. View the logfile in the in client console and double click on messages for solution suggestions.


Errors, warnings

TransferService.log file on communication station



Errors, warnings

TransferService.log file on mobile client



Performance MS Windows NT Performance Monitor on mobile client and communication station

On demand Lon runtime Check operating system load


Outbound Queue

SMQ1 on CRM Server

On demand Monitoring outbound queue on CRM Server If the queue was stopped because of capacity overload, use F6 to restart the queue



© 2005 SAP AG

56

56

Monitor ing Object

Monitor TA/Tool

Monitor Frequ.

Indicator or Er ror


Responsibility

If a second start of the queue is not successful, call the short dump analysis in the CRM system

BDoc SMW01(SMW02 and SMW03) on CRM Server

Upon error Analysing Bdoc messages and perform required actions, e.g. BDoc messages with status beginning with E (red traffic light) need manual correction and retry, see also BDoc Monitoring and Handling.


TRFC Monitoring

SM58 on CRM Server (R&R)

Upon error Monitor all transactional RFCs (tRFCs) processed on the CRM Server


ConnTrans Performance

SMWMCOMM on CRM Server

Upon error Monitor ConnTrans performance and data exchange


Connection DCOM Connector Monitor on CRM Server

Upon error Monitor connection components


Message flow statistics

SMWMFLOW on CRM server

Upon error Use this as a starting point for analyzing performance problems


Flow Definitions

SMO8FD on CRM server

Upon error Check consistency of Flow definitions


Replication queues

SMOHQUEUE on CRM server (R&R)

Upon error Display information about the status and content of the replication and realignment queues in the clients defined in the CRM Server


Performance SQL Profiler and Trace, SQL/Query Analyzer

In case of performance problems

Long runtime





Long runtime



5.1.1.16.2 Error Handling, Restartability, and Escalation Please refer to the Step 8 ‘Perform Upload’.

If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMMTFWTL.

5.2Further Information 5.2.1 Integration of BW and CRM Field Sales Please also see Connection to SAP Business Warehouse (BW).

5.2.1.1 From BW to CRM Query data can be loaded into the CRM system once the required settings have been made and the request job "SMOBWREQ" (choose the "Request" pushbutton (F8) in transaction smobilebw) has been scheduled to be run regularly.


© 2005 SAP AG

57

57

It is possible to examine the entire processing log by choosing the "Display Log" pushbutton (SHIFT+F4) within transaction smobilebw. By doubleclicking the messages assigned to specific requests, you directly access the appropriate request screen, where you can immediately set about resolving the problem.

• Manual Requests: It is possible to start individual requests manually. This is useful if an error occurred that was removed in the meantime. To do this, you choose the "Request" pushbuttons (F8) in the "Workbooks Request", "Query Request", and "Users" screens. These pushbuttons request the corresponding data independently of the report "SMOBWREQ". A confirmation message tells you whether the request was successful or not.

• Flow Monitor: You can start the Middleware Flow Monitor by choosing the "Flow Monitor" pushbutton (SHIFT+F1) or by doubleclicking in the "Users" screen. In this way, you can check whether the flow has correctly processed the corresponding BDocs. This is essential before the data is transferred to the tables of the CRM system. The Flow Monitor view in the detail screens relates to the respective request. In addition, you can examine all REP_BOREPMA_WRTE BDocs from the menu.

• Queue Monitor: You can access the monitor for the Middleware Replication & Realignment Queue from the menu.

• Display Query Data: In the "Workbooks Request" screen, you can access the data available in CRM for this workbook by choosing the "Display Query Data" pushbutton (SHIFT+F2). By doubleclicking, you can check the data in greater detail. Note that workbooks are binary files for which the detail view does not provide very detailed insights, but plausibility checks can easily be run on query data. The "Display Data Records" pushbutton (SHIFT+CTRL+F2) calls up transaction SE16, which you can also use to display the relevant data records.

5.2.1.2 From CRM to the Mobile Client After the query data has been loaded from BW into CRM, it then needs to be distributed to the mobile clients (the component "BW Report Tools" is located in the system administrator application).

Checking the Client Log in CRM: The assembly process is documented in a log file. This log information is found in the file c:\bwmsa.log. You have the option of using the transaction SMOBILEBW to determine whether this file is to be initialized and whether the system administrator can call it up in the CRM system for analysis purposes. By doubleclicking in the "User Links" screen, you call up a view of a copy of this file. The original file version remains on the laptop in question but is replicated if required in CRM. This view is blank at first because no data is transferred from the client. You need to choose the pushbuttons "Transfer Log" (SHIFT+F1) to start the process. This generates special BDocs that are replicated to the client with appropriate subscription and trigger the respective processes in the client. For this a subscription for BW query reports with REPKIND = "Q", BWUSER = <BWusername> and BWGROUP = "C:\BWMSA.LOG" needs to be created for the client concerned. Moreover an identical subscription must not exist for any other client to prevent the log data from being overwritten. Depending on the action triggered (see the status display in the top row of the log), the log data on the client is now either sent to the CRM system or deleted before the assembly (in which case only the last assembly process is visible). Note that this transfer can have a negative effect on the overall performance of the client system. For this reason, you should only activate this option to examine problems as they occur and then deactivate it again afterwards.

5.2.2Background Information and References for the Field Sales Scenario

5.2.2.1.1 Consolidated Database (CDB)

The CRM database is the common database for all CRM applications. It contains the CDB, a separate consolidated database for the Mobile Client applications. The CDB is a logical part of the entire CRM database. The CDB contains the data that needs to be transported to and from the Mobile Client, i.e. data relevant to replication (CDB tables) for mobile scenarios.


© 2005 SAP AG

58

58

For the sales representatives in the field the CDB is divided into partial datasets in order to allow them to work independently. They do not work online on the overall database, but rather on the sites (their laptops) with local, geographically distributed datasets.

The partial datasets of the CDB must correspond to the requirements of the employees in the field force. This means that each remote employee is given access only to the data for which he or she is responsible. The employee then manages "his/her" data (be it customers, contact persons, orders or appointments) on a local database.

Generally speaking, there will be a degree of overlap between the various partial datasets into which the overall database is divided. The phrase "replicated data storage" implies that there may be several different employees who are all responsible for managing a given item of data and who could make changes to it.

5.2.2.1.2 ConnTrans

The ConnTrans is the connection handling interface between the client computer (site, laptop) and the CRM Server (via the Communication Station). It is the main task of the synchronization process.

Whenever data is to be sent from a mobile client to the CRM Server, ConnTrans is used. It starts the Message Transfer Service Client which in turn takes the BDocs from the outbound queue of the mobile client and sends it to the Message Transfer Service Server that is located on the communication station. ConnTrans receives and sends the changes that have been made since the last synchronization. Changes are not sent step by step but in a package of Remote Function Calls (RFC), which are processed when the whole package has been received/sent.

The ConnTrans does not connect directly to the mySAP CRM system but through the Communication Station, especially the DCOM Connector. ConnTrans and DCOM Connector communicate by using Microsoft’s Distributed Component Object Model (DCOM). The DCOM Connector uses RFC to connect to the CRM System.

The connection setup is carried out via DialUp Networking (Remote Access Service).

After installation of the mobile client the ConnTrans.exe is stored under ...\SAP\Mobile\bin\.

5.2.2.1.3 Queued Message Transfer Configuration Tool (QmtCnfg)

The QmtCnfg plays a role in data transfer from the CRM mobile client via the Communication station to the CRM Server. Various protocols are used here, namely DCOM from the mobile client to the Communication Station and RFC from the Communication Station to the CRM Server (after the DCOM protocol has been converted into the RFC protocol in the SAP DCOM Component Connector).

The QmtCnfg consists of a client component and a server component, with the server component being located on the Communication Station. QmtCnfg can thus be used on the mobile client as well as on the communication station.

This is a tool that displays:

• Parameters for managing the components of the Queued Message Transfer (QMT). Only QmtCnfg can change these parameters.

• Relevant configuration parameters of the Windows operating system for the DCOM transport layer.

You have to configure these parameters using Windows tools. QmtCnfg however, provides direct access to these tools.


© 2005 SAP AG

59

59

• Parameters of the DCOM Component Connector on the Communication Station. You have to configure these parameters using tools of the SAP DCOM Component Connector. QmtCnfg however, provides direct access to these tools.

QmtCnfg has two main tasks:

• It displays all the relevant Windows and SAPspecific configuration parameters that affect data exchange between the CRM Mobile Client and the CRM Server, including the version of the relevant QMT components.

• It tests the connection to the Communication Station and to the CRM Server.

In addition, QmtCnfg enables you to create a log file documenting the configuration that has been found. In this way you can compare different computer configurations for example, or in the case of an error message information on the configuration can be included. To create a file like this, choose the option Write Log File in the Select menu. A window containing the message: Log file ‚<TEMP>\QmtCnfgLog.txt’ written. appears. In addition, the program flow is logged in a text output window, whose current content you can clear using the button Clear Text.

5.2.2.1.4 DCOM Connector The SAP DCOM (Distributed Component Object Model) Connector controls the access of the sales employees via their front ends (laptop, workstation PC) to the CRM Server. It acts like a proxy server between the ConnTrans process and the CRM system. On the client side it talks DCOM and on the server side RFC, i.e. it converts the Mobile Clients’ DCOM calls into qRFC calls to the CRM Middleware. The connectors’ runtime environment offers a general interface to call the remote function modules used in this context. The DCOM Connector can be installed stand alone or in the MTS. In the mySAP CRM Mobile Client scenario it is always installed in the MTS.

5.2.2.1.5 Message transfer Service (MTS) The Message transfer Service provides a rich set of integrated services providing support for scalability, security and transactions. MTS is based on COM (Component Object Model) and uses DCOM for componenttocomponent communications across a network. As client on the mobile client and server on the communication station the MTS serves as a transaction processor over distributed systems. It efficiently supports connection pooling and increases network security by providing an authentication system. Another main reason to run the MTS is better performance (connection pooling).

5.2.2.1.6 Admin(istration) Console The Admin Console is located on the CRM Server (transaction SMOEAC) and uses its data and function modules. It is a central tool used for the administration of mobile sites and users, as well as for administration and customizing of data distribution to the mobile clients (replication, publications..).

5.2.2.1.7 BDoc Modeler

BDoc Modeler (BDocM) is a tool for modeling business document (BDocs) types. A BDoc is a set of data related to a business operation in the Transaction Repository. The Transaction Repository is a data storage device that holds the entire user related BDoc information. It helps to define atomic BDocs.

BDocM is used to maintain Bdocs, to define BDocs and to configure the application database depending on the Transaction Repository

On the CRM server the Bdoc Modeler is an integral part that is available as transaction (SBDM). On the mobile clients the BDocM is be located at …\SAP\Mobile\bin\.


© 2005 SAP AG

60

60

5.2.2.1.8 ASCII Adapter The ASCII (American Standard Code for Information Interchange) Adapter is the interface between the CRM Middleware and external systems that cannot supply any BDocs (business documents) to the CRM Middleware. Instead, these external systems can supply the CRM Middleware with ASCII files, which are converted into database tables by using the ASCII Adapter. Similarly, information from the CRM Server can be supplied in text files to the external systems.

5.2.2.1.9 Sales Configuration Engine (SCE)

The SCE lets you configure downloaded R/3 master data on a PC or laptop, either with or without a connection to an R/3 System. To use the SCE a locally installed relational database is needed as well as a framework for the SCE to work in.

The framework for the SCE can be, for example the Internet Pricing and Configurator, SAP Customer Relationship Management (CRM), SAP Field Sales, or a custom thirdparty environment.

The SCE uses R/3 master data converted to an SCE knowledge base. Master data cannot be maintained in the SCE.

The SCE is written entirely in JAVA and runs on any Web browser. It is compatible with R/3 releases 3.1H, 3.1I, 4.0B, 4.5, and 4.6.

The user interface layer is completely separate from the configurator itself. This allows to integrate the SCE with a wide range of other applications.

In the field sales scenario the SAP Internet Pricing and Configurator (SAP IPC) is included in the standard mySAP CRM Mobile Sales installation with a standard Java interface. The mySAP CRM Mobile Sales middleware downloads all the R/3 data that the SAP IPC requires to configure and price products.

The field sales force uses CRM Mobile, installed on laptops, to manage the whole range of activities, from planning of customer site visits to order entry. Some of the products that are market in this way may be configurable. Salespeople can visit customers to discuss their requirements, with a view to presenting them with one or more quotations for different combinations of product options (variants).

5.2.2.1.10 Sales Pricing Engine (SPE)

The Sales Pricing Engine (SPE) enables field sales representatives to calculate prices at the pointof sale for those offers and orders created in the mobile system. The system uses the company’s price elements, such as discounts and surcharges, etc. These are downloaded with the master data from the system that is normally used for pricing. This enables a rapid direct access to pricing information. Pricing results can also be printed out immediately in the order. The pricing results can be transferred into the central system, where they can be used for further order processing.

The SPE is based on the following SAP R/3 system concepts and functions:

• Condition technique • Currency conversion, including Euro conversion • Conversion of units of measurement and measure

The SPE is integrated according to the standard in the Field Sales Application. Data exchange with the SCE enables pricing for configurable products.

To be able to calculate prices in the mobile system, you must have created a pricing procedure in the central system in Customizing for Sales and Distribution. The SPE offers the most important pricing functions from the SAP R/3 System. Depending on the release status of the R/3 standard system that you wish to download the master data from, you may not be able to use the full scope of functions. Some of the condition types from the R/3 Standard System cannot be used. For example, you cannot


© 2005 SAP AG

61

61

maintain Customizing settings in the SPE and you cannot create or change pricerelevant master data such as condition records and agreements. This happens exclusively in your main system.

5.2.2.1.11 Client Console The ClientConsole is located on the Mobile Client. The initial step for connecting the Clients to the CRM Server (via CommStation) is carried out here. During this process (assign SiteID) the Middleware Outbound Queue for this Mobile Client is registered on the client itself.

It is also used for the administration of the CRM Mobile Client. It also undertakes the role of monitoring and troubleshooting the mobile client.

It offers one window to client health monitoring tools. Contains different tools for communication administration available under one roof. The tools are divided into two groups:

• Client Administration, i.e. to set up and test the data exchange with the Middleware layer on the CRM Server

• Data Transfer, i.e. to monitor and view the data transfer and the transaction layer environment on the client.

Within the Client Administration the following functions are available: • Metadata generator: generates metadata (stored procedures and views) and cache file for

transaction layer runtime. • Metadata Viewer (to view the Metadata) • Check Metadata (to test the consistency of the Metadata) • Assign SiteID: makes appropriate settings on the client as well as the server so that a laptop is

identified as a valid client. • Test Adapter Connection (The connection to the commstation can be checked here) • Table Script Generator (Table changes in the CRM Middleware can be transferred • BDOC Upgrade Scripter (To create or transfer BDoc changes to the Mobile client)

Data Transfer folder includes the Queue Processor and the Queue Monitor, whereas the former functionality of the Queue Processor has been shifted completely to the Queue Monitor. The Queue Monitor can be used to:

• View the presence of messages in the client’s inbound and outbound queues • Test the readability of queues by transaction layer • View contents of top messages in the inbound queue, if readable

It is used to list the number of BDoc messages that are not processed in the inbound as well as the outbound queue. Whenever data is saved in the CRM Mobile application, messages are generated and they reach the outbound queue of the client. These messages have to be sent to the CRM Server. Messages in the inbound queue are those that are received from the CRM Server and are waiting to be processed and written into the local database of the mobile client.

5.2.2.1.12 Backweb SAP BackWeb is an optional thirdparty software component in the field sales scenario. BackWeb is intended to provide sales representatives with a means of gaining timely access to marketing and sales materials or Internetbased information. It is a system that enables businesses to gather, target and deliver large amounts of data in any format (e.g. audio, video, software files, HTML) to user desktops across their extended enterprise. BackWeb accomplishes this through the use of information channels. This function consists of two components: a BackWeb server and a BackWeb client component. This client is seemlessly integrated with the info center component of the Mobile Sales Application, which means that it is part of the

5.3Scenario specific Monitoring Tip: The names of the Site ID‘s on the Mobile Client (Client Console) and in the CRM (SMQ1, SMQ2) are different. In table SMOHQTAB (use transaction SE16 à Table contents) the names are mapped together.


© 2005 SAP AG

62

62

5.3.1Basic Monitoring Guidelines for the CRM Server Apart from the general monitoring activities on a CRM Server that is described in the Appendix we recommended the following actions when running CRM Field Sales. Mobile Bridge settings: For all BDoc types that you are planning to use in the FS scenario you have to enable the Mobile Bridge: Set field ACTIVE to ‘X’ in table SMW3FDCUST according SAP Note 430392. Monitoring Activities / Functions Monitoring Type Monitoring Frequency

Periods and Events Queue Information for CRM Client Sites

• Display all mobile sites defined in the CRM Server together with the name of the queue assigned to each of these sites

SMWMQUEUES Only for error tracking in seldom cases

Replication Queues Monitor • Displays information about the status and

contents of the replication and realignment queues in the clients defined in the CRM Server

• The EXTRACT queue shows to which clients a specific BDoc type will be distributed

• To check the status of the queues • Deselect the flag: Display current client

only • Press the Refresh button • Search for queues with • Status = Hold • number of entries > 0 and a • flash icon button in the rightmost column • Correct the error situation for the indicated

queues (error handling in SM58) Note: Do not press the trash icon button if it appears next to an entry.

SMOHQUEUE • Several times a day depending on the business process

• Daily

Communication monitor • Communication monitor: monitoring

individual sessions, statistics of the data exchange for each site

SMWMCOMM Middleware à Monitoring à Mobile Client à Communication Monitor

• Daily • In case of performance

problems

Mobile Client Message Recovery Unprocessed message recovery: reporting messages informing the CRM Server about errors during the import on the mobile clients

CMWQ Monitoring > Mobile Client > Message Recovery

• Daily

Operating System / Gateway The SAP system statistic collector daemons, SAPOSCOL and RFCOSCOL, run on the Communication Station and gather hardware resource consumption data. Complementary programs run on the CRM Server and collect and display statistical data. While the Communication Station is running, data is continually being collected via existing connections, and system data is also collected for subsequent evaluation. This data is called up periodically by the CRM Server and can be displayed and analyzed there using monitoring tools. The gateway, which is installed on the Communication Station, is used to call up the collected data. Windows performance monitor.

OS07 • Daily

• In case of performance problems


© 2005 SAP AG

63

63

5.3.1.1 Scheduling Batch Jobs

5.3.1.1.1 Middleware Trace Reorganization For tracing, you can use various standard settings or your own settings; see above in section settings in table SMOFPARSFA. Depending on the selected trace level, the system writes entries into trace tables. Such entries must be deleted in regular intervals to prevent these tables from becoming too large. Some possibilities to handle this would be to keep trace information (especially errors) in the log for e.g. 1 day, or 1 week and to delete the data afterwards. You have to schedule reorganization jobs, called SMO6_REORG (SAP Note 206439) and MW_REORG (SAP Note 487915)

5.3.1.1.2 Middleware Portal To be able to use the centralized status monitoring for the generation steps, you must call up the Middleware Portal (transaction SMWP) and activate the background job for status processing by clicking on Scheduled Background Job. Note that status monitoring will be available only during the next day.

5.3.1.1.3 BDoc Flow Statistics Activation Ensure that the middleware kernel application statistics are switched on. Call transaction SMWMFLOW. Execute Goto > Activate Statistics. Select “message flow statistics”. Activate monitoring of the middleware message flow. To activate the application statistics, select “Kernel application statistics”, select the change mode, mark the field “MW” (Middleware Message Hub Statistics). Save.

5.3.1.1.4 Communication Monitor Collector Activation For activating transaction SMWMCOMM, the Conntrans Performance monitoring, you have to choose “Environment”> “Run Collector

5.3.2Basic Monitoring Guidelines for the Communication Station

The Communication Station (Comm Station) is the link between the CRM Middleware server and the Mobile Clients. The Comm Station is the server where the DCOM Connector component is installed. Monitoring Activities / Functions Monitoring Type Monitoring Frequency

Periods and Events DCOM Connector component monitor Start à

Programs à Middleware à DCOM Connector. Start the application and choose Monitor.

• In case of errors and problems

Communication Log File: TransferService.Log Txt oder hyper The SAP CRM Queued Transfer Service component logs the communication sessions between the mobile clients and the CRM Server in the TransferService.log file. The default file path is as follows: C:\WINNT\TransferService.log.

• This file should be monitored daily.

Windows NT Performance Monitor / WIN 2000 Perfmonitor

• In case of performance problems

5.3.3Basic Monitoring Guidelines for the Mobile Clients When a traveling sales person has data to up or download from his laptop, he must establish a connection to the CRM Server via the Communication Station. This may be done at the customer site using a telephone line. The Communication Station maintains a connection to the CRM Server that in turn maintains a connection to the R/3 backend system (LAN configuration).


© 2005 SAP AG

64

64

The CONTRANS.EXE program is executed on the mobile client to establish the connection. Data from the outbound queue of the mobile client is transferred through the Communication Station to the CRM Server. This data can be customer orders and/or customer data, such as newly created customers on the mobile client. For monitoring the mobile clients, you have to consider four different areas: • The operating system • The local IDES database • Trace files • Data transfer log file

Mobile Client Monitoring Activities / Functions Monitoring Type Monitoring Frequency Periods and Events

Queued Transfer Service The QmtCnfg program displays the connection status between the mobile client and the Communication Station.

QmtCnfg.exe TransferService.log

• In case of an error message in the data transfer phase

Client Console, metadata check, generation, comparison of BDoc structures Data bound from the CRM outbound queue to a specific mobile client is copied to the inbound queue of that mobile client. Data from the mobile client outbound queue is transferred to the inbound queue on the CRM Server. The inbound and outbound queues of the mobile client can be displayed using the Client Console.

• In case of an error message in the import phase

Operating system Windows NT Performance Monitor

Perfmon.exe In case of an error message

Database You can monitor the SQLServer database on the Mobile client with the remote SQLServer Monitor

SAP Note 358507 SAP Note 433401 SAP Note 530317

5.3.3.1 ConnTrans Data Exchange and Restart Queues The ConnTrans program is used to connect the Mobile Client to the CRM Middleware System and to restart the data queues that hold messages bound for the CRM Middleware System.

ConnTrans covers the following functions: • Send and receive messages to the CRM Middleware system • Shows status of data transmissions • Restart inbound and outbound queues processing When the ConnTrans program is started, or restarted, previously unprocessed inbound and outbound queue entries will be processed. After connection to the CRM system the outbound queue empties. Entries remain in the outbound queue until they are successfully copied to the inbound queue of the CRM system. Entries that remain in the client outbound queue after ConnTrans was started have not been processed. The inbound queue of the mobile client should also be empty after running ConnTrans. Entries that remain in the client inbound queue after ConnTrans was started have not been processed. Both the Mobile Client outbound and inbound queues should be empty within a relatively short time after ConnTrans has been started.


© 2005 SAP AG

65

65

To use ConnTrans, on the Mobile Client choose Start > Programs > SAP CRM Mobile Client > ConnTrans.

Operating System / Gateway The SAP system statistic collector daemons, SAPOSCOL and RFCOSCOL, run on the Communication Station and gather hardware resource consumption data. Complementary programs run on the CRM Server and collect and display statistical data. While the Communication Station is running, data is continually being collected via existing connections, and system data is also collected for subsequent evaluation. This data is called up periodically by the CRM Server and can be displayed and analyzed there using monitoring tools. The gateway, which is installed on the Communication Station, is used to call up the collected data. Windows performance monitor.

5.3.3.2 TransferService.log file File logs the communications between the Mobile Client and the Communication Station. The format of the TransferService.log file on the Mobile Client is not as clearly selfdocumenting as the log file on the Communication Station. In most cases the client log file should not be analyzed until after analyzing the Communication Station TransferService.log file. Although both files have the same name, their formats are very different. For this reason when diagnosing SAPrelated communications problems on the Mobile Client, first look at the log file from the Communication Station. The default file path is as follows: <windows temp folder >\TransferService.log The TransferService.log file supplies the following data for each session. This data is stored and can be displayed in text format on the local Communication Station server. The session header data contains the following information:

• Name and/or IP address of the DCOM Server • Date and time when the session was started (in UTC time) • Date and time when the session was closed • PID of the DCOM process • TID (thread ID) of the current session (PID and TID together are unique IDs for session) • Object ID (session ID) • Site name • Queue name • Name of the PC from which the session was opened • Name of the Windows user • Session status The session performance data contains the following information: • Number of transactions sent to the R/3 System • Number of table entries sent to R/3 • Number of transactions received from R/3 • Number of table entries received from R/3 • Compression rate for data received from client • Compression rate for data sent to client • Processing time on the DCOM Server for data received from R/3 and sent to the client • Processing time on the DCOM Server for data received from the client and sent to R/3 • Session status • Detailed information for the functions Read, ReadConfirm, Send and SendConfirm: • Number of calls to R/3 • R/3 response time • Network time between Mobile Client and DCOM Server • Response time of the client database • Transmission rate for communication of DCOM Server with R/3


© 2005 SAP AG

66

66

• Transmission rate for RFC communication between client and DCOM server • Access rate in the client database (bytes per second) Please note that the measured answer times in the transferservice.log does not capture the post processing time of the BDOC‘s. On the CRM server you can measure the post processing time with transaction SMWMFLOW.

5.3.3.3 Windows NT Performance Monitor The Microsoft Windows Performance Monitor (PERFMON) is a performancemonitoring tool on Windows NT and Windows 2000 systems. PERFMON can be used on the Communication Station to analyze performance problems due to: • Total response time • Network time • Browser generation time When analyzing network conditions, PERFMON should be run locally on the Comm. Station rather than from a remote server. When running PERFMON from a remote server, network statistics can be affected due to the network load caused by PERFMON itself. Other networkbased applications, such as PCAnywhere, also create a significant network load that may invalidate any network statistics measured while connected. Handling procedure for Performance Monitor: • Verify that the Performance Monitor is installed • Set up the counters and the log file (modify/set the log file and chart settings) • Ensure that no other services or programs are running that may impact the measurement (such as

programs causing network or CPU load). • Perform the measurement • Extract the relevant counters (export them to a file) • Calculate the relevant quantities • Interpret the results

For further details, go to www.microsoft.com > Support Knowledgebase and see the White Paper Measuring performancerelevant data using PERFMON on Windows NT. For a detailed description of the use of the MS Performance Monitor, see SAP Note 203845. In Windows NT, to start PERFMON, choose Start > Run and enter PERFMON. Set up PERFMON as follows. 1. Measure the CPU utilization on the server or PC. From the PERFMON menu, choose Edit > Add to Chart / Add Item Select in PERFMON: Object, Processor, Counter, % Processor Time 2. Determine the size of dataset transferred for analysis. Select in PERFMON: Object, Network Interface, Counter, Bytes Received/sec Note: Depending on the network connection, the name of the category and item of the above mentioned examples may differ. When selecting the network interface counter it is possible that various instances (= lines) are offered. If you are not sure on which network line the traffic takes place, choose all instances. You may have to start processes at the NT level monitoring network traffic. 3. To start your analysis, monitor during the peak time when Mobile Clients are uploading to the CRM

Middleware System. To save the performance data and transfer it into a spreadsheet program, choose File > Export Chart.

Evaluate your analysis.

5.3.4Housekeeping for Mobile Clients

5.3.4.1 General PC Tuning The following list contains some general measures to prevent a gradual decrease of your PC’s performance:

http://www.microsoft.com/


© 2005 SAP AG

67

67

1. Make sure that there is enough free disk space (i.e. 1 GB). 2. Regularly delete the files in the directories TEMP and TMP. 3. Empty the Recycle Bin. 4. Delete temporary Internet files (in the directory WINNT or WINDOWS or by choosing Internet

Options in the Internet Explorer). 5. Check whether regular jobs are scheduled, such as reindexing. These can be very

performanceintensive and should not run at the same time as CONNTRANS or a mobile client application.

6. Ensure that you set the pagefile large enough (300MB). Avoid fragmentation by using the same minimum and maximum values.

7. From time to time, check fragmentation on the hard disk. Windows 98 has an integrated de fragmentation routine: Choose System _ Tools. Windows NT does not have an integrated routine.

5.3.4.2 Database reorganization Over time, inserting, deleting, and changing data leads to fragmentation on the database of the mobile client, and additional (I/O)load arises. To ensure good performance with the mobile client, the database must be reorganized from time to time. A script can be downloaded from sapservx for the purposes of database reorganization (defragmentation). See SAP Note 417539 for details. Using command file sap_smo_reorg7_apply.cmd, two stored procedures are created in the IDES database. You should only execute this command file once per mobile client. Two command files are available for the reorganization/defragmentation of the database: 1. reorg_initial.cmd This command reorganizes the whole IDES database. This is worth doing after an initial download, especially if the “Initial Client Setup” indicator was not set for Conntrans. 2. reorg.cmd This command only reorganizes the IDES database tables, in which more than 10% of the data has changed since the last reorganization. You are advised to execute this command regularly (once per month), at the latest when performance on the mobile client becomes noticeably poorer. Please note that defragmentation requires as much free space in the database as the largest table to be defragmented occupies. This space is released again after defragmentation has completed. Before defragmenting any table, the system checks that enough space is available. If not, the action is canceled and a message to this effect is issued. We do not recommend to shrink the database on a regular basis to save disk space. It is also recommended to switch the ‘auto shrink’ function off due to performance reasons.

5.3.4.3 Database reindexing If database tables are updated frequently, it is recommended to reindex the whole DB on regular basis (monthly or every 2 month). You can schedule a Database Maintenance Plan by means of SQL Enterprise Manager. Expand tree and choose Management > Database Maintenance Plan>New Maintenance Plan. Select the option "Reorganize data and index pages". Start 'SQL Server Agent' before running the created job.

5.3.4.4 TL (Transaction Layer) Hotfix The last version of TL Hotfix should be applied according to note 497748. The note is updated frequently and customers should always apply the last update. It contains fixes for all known problems in the BDOC Layer and ConnTrans. Especially check the note when facing problems before opening a SAPNet message.

5.3.4.5 IPC logs and traces Refer to the SAP Note 658805.

Pricing Analysis

The "Pricing Analysis"trace shows how the IPC has searched for condition records during the pricing of a sales document. The trace shows:

Which condition tables where searched by the IPC and which searchcriteria have been used.


© 2005 SAP AG

68

68

Which requirements/userexits were checked during pricing and the result of the checks?

The "Pricing Analysis"trace is the first place to look, when pricing works technically, but the wrong price is calculated because for example not all expected condition records have been found by the IPC.

How to turn on the "Pricing Analysis" trace in Mobile Sales.

Until 4.0 SP03 "Pricing Analysis"trace is activated on sales documentlevel by setting the checkbox "Pricing Analysis" in the "Details" tileset. Starting with 40SP03 the "Pricing Analysis"trace is activated on user level, rather than on the sales document level.

To enable the "Pricing Analysis"trace:

Open the Mobile Client Application.

Select the component "Employees".

Click on "Settings".

In the tile "Settings" set the check box "Pricing Analysis".

To View the Pricing Analysis:

In the component "Sales Transactions" create a new sales document and add line items and save.

Go to the tileset "Item Pricing Conditions”. The "Analysis" button should now be enabled.

Click on the "Analysis" button to view the trace of the steps performed by the IPC during the pricing of the line items.

When the "Pricing Analysis"trace is turned on, the performance of pricing is reduced, because the IPC has to collect trace information. Always turn off the "Pricing Analysis"trace, when you do not need it. The "Pricing Analysis"trace should not be turned on during productive use of the application due to the impact on performance.

What information is contained in the IPC logfile (ipcapplication.?.log) ?

The IPC Logfile lists the following errors and warnings produced by the IPC:

Error and warning messages when customizing data is missing or incomplete.

Warnings when condition master data tables are missing.

The IPC logfile is the first place to look for more information when pricing or configuration does not work.

How to locate the IPC logfile” ipcapplication.*.log”?

The logfile is not overwritten when the application is restarted. By default the IPC writes a logfile called ipcapplication.0.log, until it reaches the size of 1 MB. The IPC now starts writing into a new logfile called ipcapplication.1.log. When this file has also reached a size of 1MB, the first logfile ipcapplication.0.log is overwritten. The number of logfiles, their size and the name of the logfiles can be customized. The procedure is the same as for the IPC in the CRMOnline scenario. Refer to the IPC documentation. The default location for the logfile is the path pointed to by the local environment variable TEMP. Under Windows 2000 and XP this is normally the directory c:\Documents and Settings\<user name>\Local Settings\Temp The quickest way to locate the TEMPfolder is to open Start>Run and type %temp% followed by return.

Mobile Salesspecific trace information into the IPC logfile.

The IPC can be configured to produce additional Mobile Sales specific traceinformation. The trace will then contain the following additional information:

All IPC methods called by Mobile Sales.

For which object the methods was called, i.e. the sales document or lineitem guid.

The input parameters of the methods.


© 2005 SAP AG

69

69

The output parameters of the methods.

Duration of the call in Java. To enable the logging of the additional traceinformation you have to change the properties file "logging. properties". This file can be found under the below folder

<installation path>\SAP\IPC\lib\properties

In this file uncomment the following lines by removing the preceding "#"

Setting to enable the logging

# Trace for Mobile Sales com.sap.spc.beans.logs = log [Unknown] com.sap.spc.beans.severity = PATH

Setting to disable logging

# Trace for Mobile Sales #com.sap.spc.beans.logs = log [Unknown] #com.sap.spc.beans.severity = PATH

IMPORTANT: The writing of the additional traceinformation affects performance! Turn it off when not needed by commenting the above lines again.

5.3.4.6 Unused functionality If some functionality is not used, we could turn it OFF to boost the performance slightly. Open the Mobile System Maintenance application. Navigate to the component 'CrossComponent Settings', navigate to the tileset 'Choice Fields'. 1. Create Choice field 'SAD_NOITEMPARTNERS' to disable the functionality of item partner creation. 2. Create Choice field 'SAD_NOITEMBUSDATA' to disable the functionality of item business data creation. 3. Create Choice field 'SAD_NOTAX' to disable the functionality tax determination. 4. BOM explosion can be switched off: In the MSY (Mobile System Maintenance application) component 'Sales Document Settings' tileset 'Global Sales Document Settings' deselect the checkbox 'Explosion BillofMaterial'.

5.3.5Application Troubleshooting on Mobile Client Always check if the problem is reproducible. Simply execute the respective transactions several times over and check, if the problem persists. Then check if the problem is related to the data that is used. Perform the transaction with different data to make sure that the problem is reproducible and has nothing to do with specific data constellations. Also check if the problem does have anything to do with the CPU or the database. Currently there are no SAP internal tools to perform this analysis. Many problems are database related – it is recommended to start with the database analysis first using MSSQL Profiler (see below). If the database analysis does not show any problems at database level, check whether the problem is CPU related using the task manager. While the transaction is running, simply check which process is most CPU timeconsuming. If it is an application related process for that you cannot find a solution please open a SAPNet message for further investigation.

5.3.5.1 Transaction Tracing on Mobile Clients In case of performance problem it is necessary to analyse a certain step or business process on the mobile client. Database interaction can be analyzed using a set of tools available in the SQL Server suite. These are

• SQL Profiler • SQL Query Analyzer

For the analysis a profiler trace has to be run on the mobile client by the application monitoring team. For this step the mobile client must not be connected to the CRM server. In general the team looks for selects with high response times (min. > 500 ms), checks which index has been used and if the index is selective (density).


© 2005 SAP AG

70

70

Please note, on some Mobile Clients, customers installed Windows 2000 wherein SQL Server 2000 is included. With this spare version of SQL Server 2000 (SQL Server 8.0) no Profiler tool is available. Therefore a trace on the Mobile Client itself is not possible.

5.3.5.2 SQL Profiler and Trace The SQL Profiler is a tool to monitor events in an instance of the SQL Server. It can be used for the following:

• Recording SQL Statements/Stored Procedures • Analyze these statements • Monitor performance • Rerun scenarios

These events can be saved onto a file or table for later analysis or reruns.

How to switch on the SQL trace: 1. Choose Program > MS SQL Server7.0 > Profiler 2. Choose "New Trace" (= yellow lightening) 3. Choose GENERAL:

Define a trace name Set TRACETYP = 'Private‚ in "SQL SERVER" local Server Choose the path, where the trace should be saved

4. Choose EVENTS: From the left window add to the right: TSQL, Stored Procedures,

5. Data Columns From the left window add to the right: Database ID

6. Choose FILTERS and set Minimum Duration to 1 7. After the process is finished switch off the trace and safe the trace file. This trace can also be

reopened at later times for analysis by using FILE > OPEN > TRACE FILE. Now the SQL statements (select ....) with the longest duration can be analysed using the SQL/Query Analyser (see below).

5.3.5.3 SQL/Query Analyzer The SQL or Query Analyzer is a tool to run queries and SQL scripts on SQL database. It can be used for the following:

• Running queries on the database • Analyze queries • Modify tables directly on the database (Various database queries can be analyzed by looking

at) • Query execution plan • Estimated execution plan • Server trace • Client statistics

The Query Execution plan can be used to analyze the steps taken by SQL Server to execute a query. The SQL Query Analyzer provides a graphical tool to analyze a query execution plan. A Query analysis would result in a change of the query (or) table indices that would improve the query execution.

Choose Start > Programs > Microsoft SQL Server > Query Analyzer o open the Query Analyzer. Attention: Never execute the following statements: Insert, Update and Delete! Information about table fields can be get by entering statement: „sp_help <Table name>“


© 2005 SAP AG

71

71

With the command: ‘dbcc show_statistics (Table name, Index)’ you get Statistics about the density. The density is a measurement how selective the index is. Rows is the total number of rows the table has. Rows Sam is the number of rows for which the statistics were created. Steps is the number of rows selected by the database optimiser to create the statistics. The density is a value how selective the index (field) is. Divide 1/Rows Sam. If the result is close to the Density value displayed then the index (field) is very selective. When you click the Result Grid #2 Button you see the density of the table fields. Due to the density for the field SFAVBFA that is exactly the same as the density of the primary key index we conclude that this field is unique. When you click the Result Grid #2 Button you see the content of the fields for every step the statistics were done. This information can be used for a more detailed analysis if requiredStored procedures are executed within SQL Batch commands. Within the stored procedure Dynamic SQLs are fired to the database. These SQL statements can be analysed in the Query Analyzer. Suggestions based on analysis can be table indices or query changes.


© 2005 SAP AG

72

72

6 mySAP CRM ESelling Overview CRM ESelling is a complete solution for selling products via the Internet. It supports all processes connected with the sales cycle of all types of goods and services, in all industries. The main characteristics are: o SAP ESelling covers all phases of the sales cycle, from marketing, catalog browsing and search,

to order placement, payment, contract fulfillment and customer support. o The SAP ESelling solution supports the SAP OneStep Business concept. This allows business

partners to access SAP Internet Sales web catalogs from a purchasing system and to order products. Open Catalog Interfaces enable business processes to be concluded in one single, integrated step.

o SAP Internet Sales allows companies to offer the right customers the right products at the right time. As a result, the profitability and productivity of the company, as well as customer satisfaction is improved.

Standard encryption technology, such as SSL (Secure Sockets Layer) guarantees your customers security when executing all online transactions.

6.1ESelling System Landscape The main components of an SAP ESelling are summarized in the following table (see also the diagram below).

R/3 system The R/3 backend system covers functionality for sales and distribution and financial accounting.

CRM Server The CRM Server is used for:

• Central data storage and distribution unit for the CRM components.

• Message handling between clients and server, temporarily storing information and guaranteeing its delivery.

• Data exchange with the R/3 system and other external systems.

J2EE Engine The SAP J2EE Engine 6.20 is a J2EE™compliant application server that supports Servlets, Java Server pages (JSP), Enterprise Java Beans (EJB) and all services listed in the J2EE™ specification.

The Internet Sales Web Application is running in the SAP J2EE Engine 6.20 and represents the middle tier between the clients (the web browsers) and the SAP CRM resp. the R/3 system. It connects to the mySAP CRM system and to TREX with RFC .The connection to the IPC is established through a TCP connection.

Web Server The Web server is optional as a connection between the Web browser and the ESelling Web Application. The Web server is also used to deliver static catalog content, such as product images.

The Web frontend connects directly with the Web server. On the Web server, a specific plugin enables communication to the J2EE Engine. At present only the MS Internet information Server with the J2EE IIS Extension is supported and (Apache on Unix).

SAP JAVA Connector (JCo)

The SAP Java Connector enables RFC communication between JAVA applications (such as J2EE or IPC) and SAP systems (such as the CRM server). Therefore, the SAP Java Connector is automatically installed during the IPC (J2EE) setup. However, SAP Java Connector is not the most upto date version available and may cause performance problems. Updating the SAP Java Connector can solve these problems.

Internet Pricing and Configurator (IPC)

The Internet Pricing and Configurator is used to configure products and determine their correct prices.


© 2005 SAP AG

73

73

Text Retrieval & Information Extraction (TREX)

SAP TREX is used as a special purpose engine in the area of ECommerce. It is optimized for indexing mass data, for example in catalog scenarios, or in 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 Advisor (IPA)

UBIS IPA is a 3rd party product, which is used to enable a guided selling 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 Basket

The Persistent Shop Basket consists of a local Database, where the shopping basket can be stored and loaded. It is an optional component.

Business Warehouse (BW)

SAP Business Warehouse can be used for reporting purposes. It is an optional component.

Advanced Planner and Optimizer (APO)

The APO system can be used for availability statements in the ESelling scenario, Supply Chain Management, Demand Planning and other tasks. It is an optional component.

There are two possible scenarios for Internet Sales. • ESelling with a CRM Backend • ESelling (ISA R3) linked to R3.

Technical Overview: Internet Sales CRM Edition


© 2005 SAP AG

74

74

Technical Overview: Internet Sales R/3 Edition


• CRM Server • Backend System such as SAP R/3 • 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 ESelling can be divided into the following areas: • Monitoring the endtoend message flow from the CRM to the R/3 System • Monitoring the queues located on the respective server systems • 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

75

75

6.2Core Business Processes in SAP CRM ESelling The following core business processes are considered to be the most vital processes for an SAP CRM ESelling installation:

Order Process in B2B Internet Sales – This scenario enables business partners to order products on your web page. Marketing functions are not as important here, as this scenario is designed more to enable business partners to find and order the chosen products quickly and easily. This scenario can be linked with a purchasing application, such as Enterprise Buyer professional edition.

Order Process in B2C Internet Sales – This scenario allows end customers to order products and services on your Web page. It is designed to offer products attractively in order to encourage purchasing and in doing so maximize profit. Marketing, therefore, plays an important role here.

Product Catalog Management (and Product Recommendations) – This scenario enables you to determine the content of your SAP Internet Sales application. The product catalog contains the products that you want to sell via the Internet and in this respect presents the foundation of the Web shop. In exactly the same way, you determine in the product catalog how products are presented and how the web catalog is structured. Personalized or current product recommendations and cross / up selling also make up the content. These marketing functions enable you to draw the attention of your customers to certain products.

This Best Practice document describes the management of the business process Sales Order Management in the two scenarios Businessto Business (B2B) and BusinesstoCustomers (B2C), and a processoriented monitoring concept including the various components of a CRMISA solution based on the classic integration scenario and ISA R3 Edition.

6.2.1B2B Sales Order Management This scenario enables business partners to order products and services on your web page. Marketing functions are not very important here, as this scenario is designed to enable business partners to find and order the chosen products quickly and easily. This scenario can be linked with a purchasing application, such as Enterprise Buyer professional edition.

6.2.1.1 B2B Sales Order Management CRM Edition Business customers select an employee to act as a contact person for sales orders. The process starts when contact person logs on to the web shop using a user ID and password. In the web shop, they can view a bestseller list containing personal product recommendations. These recommendations are based on profiles created for each business when business customers first log on to the web shop. Customers can also navigate directly to the product catalog, where they can browse the entire range of products or services. Customers select the products they wish to purchase, place them in their shopping basket and proceed to the check out, where the order is finalized. The order value is calculated in the IPC and the pricing conditions are read from the CRM database via RFC connection. At the check out, the order contains prices specific to the individual customer and the customers can view the availability of their chosen products. This availability check can be done in a R/3 system or in a mySAP APO system. A sales order is created in your CRM and back end systems, where authorized sales representatives can easily access it for further processing. 6.2.1.2 We consider in detail the following process steps (standard process):

• Login to web shop • Search and select products from shop • Configure product • Determine price • Create shopping basket • Determine price for shopping basket • Check availability (R/3 or APO) • Save shopping basket as an order template • Create sales order (CRM) • Create sales order (R/3)


© 2005 SAP AG

76

76

Process Workflow for Internet Sales B2B CRM Edition

6.2.1.3 Business Process Step 1: Login to web shop The Internet user logs on into the Web shop using a User ID and password. This identifies the Internet user as the contact person for the sales process.

6.2.1.3.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility


Connection SM59 Monthly and upon error

Logon procedure fails

Check and monitor the connection between J2EE and CRM system and check if J2EE Server and Dispatcher are running



Internet user manageme nt

Webbased User management SU01 SU05

Monthly and upon error

User is not allowed to login

Investigate the cause Software/ hardware monitoring team


6.2.1.3.2


Monitor TA/Tool

Monitor Freq.



Responsibility


Weekly and upon


Application


© 2005 SAP AG

77

77

Monitoring Object

Monitor TA/Tool

Monitor Freq.



Responsibility

error monitoring team Performance SolMan,

CCMS Weekly and upon error



6.2.1.3.4 Error Handling, Restartability, and Escalation Troubleshooting at log on If the log on to the initial screen does not succeed, this indicates a connection problem between the J2EE and the R3. Contact your system administrator and ensure that the connection is working properly.

If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMISAUM.

6.2.1.4 Business Process Step 5: Search and select products from shop The user can browse and search in the Web catalog for products. This step takes place in the index server. The user can also perform direct order entry instead of browsing in a catalog for products. If the material number is entered, a shopping basket is created without using a catalog. Catalog views are used to create and manage customerspecific views for Web shop users (business partners), for example, using filters. Specific catalog views can be assigned to specific business partners.

6.2.1.4.1 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.

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Responsibility

Catalog maintenance

COMM_PCAT_ ADM

Upon error Catalog is missing, product info is not consistent, etc

Check and monitor the catalog content

Software/ hardware monitoring

Shop maintenance

Web based shopadmin

Upon error Shop is not shown, shop is working incorrectly

Check and monitor the shop content


Product Catalog Replication

COMM_PCAT_ IMS_INIT COMM_PCAT_ IMS_UPDA

Every replication or upon error

Replication fails, web shop data is not consistent

Check and monitor the replication runtime


6.2.1.4.2 Error Handling, Restartability, and Escalation • Product inconsistencies The Internet user notices product inconsistencies (data is missing or erroneous) in places that previously did not show inconsistencies. It may be that after an update replication from the product catalog, the Web shop cache has not been updated. Another variant of this problem is when products do not appear in the Web shop or the products that the Internet user sees are different from the expected ones. If you are using catalog views, ensure that the business partner is assigned to the right catalog view.

If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMISACAT.


© 2005 SAP AG

78

78

6.2.1.5 Business Process Step 6: Configure product This is an optional step. The IPC allows customers buying your products in the Web catalog to choose exactly which product components they require. Specifying these product components is called "configuring" the product. The master data that the IPC uses for product configuration is maintained in the R/3 system and downloaded to the CRM database. When a configurable product is handled in a sales order transaction, the product is configured interactively by the IPC services, which is accessed via an HTML control and the Web server. The IPC reads the configuration data via RFC from the CRM database.

6.2.1.5.1 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.

Monitoring Object

Monitor TA/Tool

Monitor Freq.


Responsibility

IPC Task manager

Upon error or performance problem

Product Configuration does not work or price inconsistencies occur

Check and monitor the hardware utilization IPC log files


6.2.1.5.2 Error Handling, Restartability, and Escalation Troubleshooting while calling the IPC for product configuration: After checking the configuration icon at product level, you find there is a problem when the IPC is called for product configuration. If Support Packages were recently applied, SAP recommends checking whether the Support Package level in the IPC is the same as the Support Package level in the CRM server. If not, implement the same Support Package level in the IPC and in the CRM server and Internet Sales.



If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMISACFG.

6.2.1.6 Business Process Step 7: Determine price The price of the product that is displayed in the catalog is calculated in the IPC in the background. The system recognizes users by their user ID, and offers them individually pitched prices. IPC can access both the Customizing data as well as the condition records. The master data that the IPC uses for pricing is maintained in the R/3 system and downloaded to the CRM database. As a result, the problem of data transfer from the R/3 system into the IPC system is avoided and the results of pricing in Internet Sales are identical with those in the CRM system. In order to calculate the price of the products, the IPC reads from its buffer or from the CRM database via Remote Function Call (RFC).

6.2.1.6.1 Monitoring Activities The monitoring activities of this process step strongly depend on the hardware used.


© 2005 SAP AG

79

79

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.

Monitoring Object

Monitor TA/Tool

Monitor Freq.


Responsibility

CPU and IPC

Task manager Upon error or performance problem

Product Configuration does not work or price inconsistencies occur

Check and monitor the hardware utilization IPC log files


IPC Statistic

IPC Monitor Command >> Show statistics


J2EE J2EE Administration

If there are errors or poor performance

Shop functionalities are working incorrectly Response time for the shop operation is high

Log files Software monitoring team

6.2.1.6.2 Error Handling, Restartability, and Escalation • Troubleshooting while calling the IPC for pricing If Support Packages were recently applied, SAP recommends to check whether the Support Package level in the IPC is the same as the Support Package level in the CRM server. If not, implement the same Support Package level in the IPC and in the CRM server.


If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component APBFPR.

6.2.1.7 Business Process Step 11: Create shopping basket In the Web Shop, the customer can create an order either directly by entering the material number of a product in fast order entry or by adding products to the virtual shopping basket that the customer identified through a search function in the product catalog. Once the shopping basket contains all articles to be purchased, the order is checked out and submitted. Customerspecific prices are displayed. During this process the CRM server calls IPC for pricing and to calculate the order value (see below under “Determine Price for the Shopping Basket”). When you create the shopping basket, a sales order with status “offer” is created in the CRM server.

6.2.1.7.1 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 Object

Monitor TA/Tool

Monitor Freq.


Respon sibility


Performanc e

ST03, STAD Weekly and upon error



J2EE J2EE Administration Isaruntime.log


Log files Application monitoring team



© 2005 SAP AG

80

80

Monitoring Object

Monitor TA/Tool

Monitor Freq.


Respon sibility


Isa.log

Regularly monitor the RFC response time statistics with the following monitors: the statistical records monitor (STAD) and the system workload analysis monitor (ST03) – in both the CRM server and R/3 system. If you find performance is critically poor, SAP recommends ordering an Early Watch session with a focus on performance tuning.


Monitor TA/Tool

Monitor Freq.



Responsibility





6.2.1.7.3 Error Handling, Restartability, and Escalation 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 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 CRMISABBS.

6.2.1.8 Business Process Step 12: Determine price for shopping basket When a sales order item is priced, the CRM system uses an RFC (Remote Function Call) to request pricing information from the Internet Pricing and Configurator, usually in the background. The RFC call goes to the IPC Bridge, which converts the call to an IPC command. CRM system always uses the IPC to calculate prices.

6.2.1.8.1 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.

Monitoring Object

Monitor TA/Tool

Monitor Freq.


Responsibility

Performanc e

ST03, STAD Weekly and upon error Long runtime See chapter performance monitoring

J2EE J2EE Administration Isaruntime.log Isa.log



IPC IPC Monitor Daily Monitor IPC statistics Application monitoring team


© 2005 SAP AG

81

81

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.

6.2.1.8.2 Error Handling, Restartability, and Escalation If there are inconsistencies with pricing calculation in the IPC, SAP recommends using the Desktop UI tool that is including with the IPC. Connect to the IPC server remotely so you can analyze the price calculation for a current session.


6.2.1.9 Business Process Step 13 or 14: Check availability (R/3 or APO) For the process step Check availability(APO/R/3) please review the corresponding section in the Availibility Check section in the CRM Online part.

6.2.1.10 Business Process Step 15: Save shopping basket as order template

6.2.1.10.1 If business partners wish to make recurring orders, they have the option of saving the shopping basket with the appropriate products as an order template. Using order templates means that they can access document processing at any time and process their order efficiently, by copying an order template or individual products out of it.

6.2.1.10.2 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.

Monitoring Object

Monitor TA/Tool

Monitor Freq.


Responsibility

Performanc e



BDocs SMWP (CRM)

Daily Red light at the BDoc level Application monitoring team

Queues SMWP (CRM)

Daily Queues are stopped. Investigate the cause


When the shopping basket is saved as an order template, a BDoc is generated. This BDoc transacts with the application database to request or write data. To ensure the normal flow of this business step, SAP recommends using the Middleware Portal (transaction SMWP) to monitor the state of BDocs daily. For all BDocs that are "stopped", investigate why this happened and take corrective action.

6.2.1.10.3 Error Handling, Restartability, and Escalation For each BDoc, error handling is maintained in transaction SMW00. For example, after 10 unsuccessful attempts to process the BDoc CONGEN_OBJECT_WRITE, an email is sent to the responsible person. Per BDoc, the number of executions and action must be defined. In addition, the required workflow must be set up in transaction SWU3.

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 CRMISABBS.


© 2005 SAP AG

82

82

6.2.1.11 Business Process Step 16: Create sales order (CRM) A sales order is created in the CRM server and transferred to the R/3 backend system. In both the CRM server and the R/3 system, the order can be accessed for further processing by an authorized sales clerk.

With APO Integration If the B2B scenario is integrated with mySAP SAP Advanced Planner and Optimizer (APO), an additional availability check is carried out and a persistent reservation performed for the product. Once the sales order has been transferred to R/3, the reservation is converted in APO, and the sales order is further processed in R/3.


Monitor TA/Tool

Monitor Freq.



Responsibility





For more information regarding the process step Create sales order (R/3) please review the corresponding section in the Sales Order Management section in the CRM Online part.

6.2.1.12 Business Process Step 18: Create sales order (R/3) After the order has been transferred to the R/3 system, the order processing is finished there. You can view or change the document, check the document flow and create follow up documents (for example, delivery and billing documents). For more information regarding the process step Create sales order (R/3) please review the corresponding section in the Sales Order Management section in the CRM Online part.

6.2.1.13 B2B Sales Order Management R/3 Edition The main difference between this process and the B2B Sales Order Management CRM Edition is that in this case there is no CRM system installed and the sales orders are saved directly in the R/3 system. Customers log on to the web shop using a password and an email address. Customers select the goods they wish to purchase, place them in their shopping basket and proceed to the check out, where they confirm their order and select a payment method. They can then submit their order. The sales order is created directly in the R/3 system, where authorized sales representatives can easily access it for further processing. Optional the saving of the shopping basket as order template is possible, if the JDBC Basket is installed. Also optional the replication of the products to the TREX is possible. This means the products are selected from the TREX Index Server into the shopping basket.

The 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

83

83

Process Workflow for Internet Sales B2B R3Edition

6.2.1.14 Business Process Step 1: Login to web shop The Internet user logs on into the Web shop using a User ID and password. This identifies the Internet user as the contact person for the sales process.

6.2.1.14.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility







Performanc e

ST05 J2EE log (isaruntime.log)


Logon runtime is long

Monitor hardware utilization on Middleware server, network load, CRM system load



Internet user manageme nt

SU01 SU05








© 2005 SAP AG

84

84

6.2.1.15 Business Process Step 3 or 4: Search and select products from shop

The user can browse and search in the Web catalog for products. This step takes place in the cached catalog products. The user can also perform direct order entry instead of browsing in a catalog for products. If the material number is entered, a shopping basket is created without using a catalog. Catalog views are used to create and manage customerspecific views for Web shop users (business partners), for example, using filters. Up to SP5 it is possible to use the TREX to replicate the products from the R3 Product Catalog to the TREX. This functionality is recommended for huge product catalogs > 5000.

6.2.1.15.1 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility


Catalog maintenanc e

WWM2, WWM3 Upon error Catalog is missing, product info is not consistent, etc

Check and monitor the catalog content

Software / hardware monitorin g

Contact system administrat or

TREX Webbased Upon error Catalog error in the Web shop

Check the XCM scenario and the maintained XML files



Shop maintenanc e

Shopadmin Javabased!

Upon error Shop is not shown, shop is working incorrectly

Check and monitor the shop content

Software / hardware monitorin g

Contact system administrat or

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 CRMISACAT.

6.2.1.16 Business Process Step 3: Create shopping basket In the Web Shop, the customer can create an order either directly by entering the material number of a product in fast order entry or by adding products to the virtual shopping basket that the customer identified through a search function in the product catalog. Once the shopping basket contains all articles to be purchased, the order is checked out and submitted. Customerspecific prices are displayed. During this process the R/3 calls IPC for pricing and to calculate the order value (see below under “Determine Price for the Shopping Basket”). When you create the shopping basket, a sales order with status “open” is created in theR/3. Price determination in the IPC takes not place in case list prices are used

6.2.1.16.1 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 Object

Monitor TA/Tool

Monitor Freq.


Respon sibility

Escalati on Procedu re


© 2005 SAP AG

85

85

Monitoring Object

Monitor TA/Tool

Monitor Freq.


Respon sibility

Escalati on Procedu re

Performanc e

ST03, STAD




Contact system administr ator

J2EE J2EE Administr ation Isaruntim e.log Isa.log

If there are errors or poor performa nce

Long runtimes, functional errors


Contact system administr ator

6.2.1.16.2 Error Handling, Restartability, and Escalation

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.

In situations that may require escalation, contact the system administrator or your business process owner.


6.2.1.17 Business Process Step 6: Save Shopping basket as an Order Template

If business partners wish to make recurring orders, they have the option of saving the shopping basket with the appropriate products as an order template. Using order templates means that they can access document processing at any time and process their order efficiently, by copying an order template or individual products out of it. This works in the ISA R3 Edition only with the JDBC Basket and an additional SQL Database.

6.2.1.17.1 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.

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Responsibility Escalation Procedure

Performanc e

ST03, STAD


Long runtime




6.2.1.17.2 Error Handling, Restartability, and Escalation If necessary, you can restart the J2EE server. This leads that the Internet user will loose there sessions. Check the regarding logs isa.log, isaruntime.log for exceptions and review that with your internal development team.


© 2005 SAP AG

86

86


Business Process Step 5: Track sales orders (optional step not shown in the graphic) Customers can call up the status of their orders at a later stage in SAP Internet Sales R/3 Edition, and display further information from external service providers, display the delivery status from the carrier, for example

6.2.1.17.3 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 Object

Monitor Freq.


Responsibility Escalation Procedure

Performanc e

ST03, STAD See chapter performance monitoring



Order Status SE16 Check order status manually, check table VBUK



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 CRMISAR3.

Business Process Step 7: Display invoice (optional step not shown in the graphic)

Customers can display their invoices in SAP Internet Sales R/3 Edition. The system accesses the invoice information stored in the SAP R/3 System.

6.2.1.17.4 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 Object

Monitor TA/Tool

Monitor Freq.


Respon sibility


Performanc e





J2EE J2EE Administratio n 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 CRMISA.


© 2005 SAP AG

87

87

6.2.2B2C Sales Order Management This scenario enables customers to order products and services on your web page. Marketing functions are important here, as this scenario is designed to sell your products to occasional customers, allowing them to find and order the chosen products quickly and easily. This scenario can be linked with a purchasing application, such as Enterprise Buyer professional edition.

6.2.2.1 B2C Sales Order Management CRM Edition Usually customers first browse trough the catalogue or select products from bestsellers lists. They can also configure products and determine their (generic) price, before logging on to the web shop. However they can also logon at first. Customers log on to your web shop using a password and an e mail address. Once logged on, they can view a bestseller list containing personal product recommendations. These recommendations are based on profiles for each individual customer generated when customers first log on to the Web shop. Customers select the goods they wish to purchase, place them in their shopping basket and proceed to the check out, where they confirm their order and select a payment method. They then submit their order. The sales order is created in the CRM and back end systems, where authorized sales representatives can easily access it for further processing.

Process Workflow for Internet Sales B2C CRM edition

The business process steps for B2C Sales Order Management are quite similar to B2B Sales Order Management process. The following detailed description of the process steps with the monitoring procedure and activities for the Internet Sales B2C Sales Order Management focuses only on the process steps which are different to the process steps mentioned in the process description above (see chapter: B2B Sales Order Management CRM Edition). 6.2.2.2 We consider in detail the following process steps:

• Login to web shop • Do payment check

Business Process step 9: Login to web shop


© 2005 SAP AG

88

88

The Internet user logs on into the Web shop using a User ID and password. This identifies the Internet user as the contact person for the sales process.

6.2.2.2.1 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

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility







Performance ST05 J2EE log (isaruntime.log)






Internet user management SU05







Business Process step 16: Do payment check

The customer selects the payment method (invoice, cash on delivery or credit card). If Credit Card is chosen, then credit card institute, card number and validity date must be entered.

6.2.2.2.3 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 Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility


Performanc e

ST05 J2EE log (isaruntime.log)






6.2.2.2.4 Error Handling, Restartability, and Escalation

If you could not find the cause of the problem with this checklist, open a SAPNet message for further investigation. Please use component CRMISA.


© 2005 SAP AG

89

89

6.2.2.3 B2C Sales Order Management R/3 Edition The main difference between this process and the B2C Sales Order Management CRM Edition is that in this case there is no CRM system installed and the sales orders are saved directly in the R/3 system. Usually customers first browse trough the catalogue. They can also configure products and determine their (generic) price, before logging on to the web shop. However they can also logon at first. Customers log on to the web shop using a password and an email address. Customers select the goods they wish to purchase, place them in their shopping basket and proceed to the check out, where they confirm their order and select a payment method. They can then submit their order. The sales order is created directly in the R/3 system, where authorized sales representatives can easily access it for further processing. Optional the saving of the shopping basket as order template is possible, if the JDBC Basket is installed. Also optional the replication of the products to the TREX is possible. This means the products are selected from the TREX Index Server into the shopping basket.

The 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).

Process Workflow for Internet Sales B2C R3 Edition

Business Process step 6: Login to web shop

The Internet user logs on into the Web shop using a User ID and password.

6.2.2.3.1 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 Login to web shop can be performed.


© 2005 SAP AG

90

90

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility







Performance ST05 J2EE log (isaruntime.log)






Internet user management SU05







6.3SAP Recommendations for additional components

Product Catalog Management and Product Recommendation You determine the following content of your SAP Internet Sales application with this business scenario:

• Products you want to offer in your Web shop • Structure of the Web catalog • Personalized or current product recommendations you want to use for advertising • Cross / upselling products you want to offer your customers

You can refer to the analysis results from Web Analytics to do this.

Determine catalog contents 1. You create the chosen products in SAP CRM and replicate the products to the TREX. 2. You create a product catalog with a corresponding catalog type. If you want a catalog type

that does not yet exist, you create it in the IMG of SAP CRM. You activate the product catalog so that it is taken into account during the publication that takes place later on.

3. You create a catalog variant for your product catalog. You activate the catalog variant so that it will be considered during the replication that takes place later on.

4. You create catalog areas that correspond to your idea of how your Web catalog should look. 5. You assign products to the catalog areas. 6. You can assign multimedia objects to products and catalog areas. You can also adopt

multimedia objects that are assigned to products in the product master. 7. You activate the catalog areas so that they will be considered during the publication that takes

place later on 8. You can create catalog views and activate them 9. You replicate product catalog contents.

Offering personalized product recommendations (optional) 1. You define target groups of the product proposal category for your planned marketing activity. 2. You put the products that you want to offer into a topn product list. This can contain a

combination of products that are manually assigned and automatically determined.


© 2005 SAP AG

91

91

3. You assign an attribute set to your Web shop in CRM.

Offering current product recommendations (optional) 1. You define a global target group for your planned marketing activity. With this target group all

customers who enter the Web shop are offered the same product recommendations. 2. Assign the global target group to your topn product list. This can contain a combination of

products that are manually assigned and automatically determined. 3. You assign the corresponding global target group to your Web Shopadmin.

Offering Cross / UpSelling Products (optional) 1. You create a method schema. 2. You define rules for cross/upselling. 3. You assign a method schema to your Web shop in SAP CRM that determines cross /up

selling products 4. If you want to offer your customers personalized cross/upselling products, select the

Personalized Cross/UpSelling field in the Web shop master. 5. If you want to offer your customers global cross/upselling products, edit the Target Group for

Global Cross /UpSelling field in the Web shop master.

6.3.1 Security Recommendation for ESelling You have just installed the Internet Sales scenario and want to ensure that it is protected from unauthorized usage or attacks from Internet. The default settings of J2EE do not provide sufficient level of security for business data. This is getting more important if Internet Sales solution is supposed to be used by Internet users.

6.3.1.1.1 Security settings, Handling, Restartability, and Escalation We recommend you to take special care in the configuration of the Web server's operating system. For example, keep the network services that the server offers to the bare minimum needed for the operation of the server.

For an Internet shop, you have to leave a user ID and password on the middleware server, which has access to the CRM Server. R/3 system, so that anonymous access to the shop is possible. This is why the middleware host should not be located in the demilitarized zone (DMZ) but in the internal network. Additionally this user should have only very limited permissions in the backend system. For enhanced security, you can implement a multistage firewall concept and place another firewall between the middleware host and the internal backend systems like CRM, R/3, APO and BW.

These are general recommendations, which should be adjusted depending on the landscape of your Internet Sales solution.

1. Directory browsing After installing J2EE server the directory browsing is enabled by default. The recommendation is to disable it by changing the property of ‘HTTP’ service in file: <J2EE_install_dir>\cluster\server\services\http\properties. Please change the setting DirList to: DirList=false.

Disable directory browsing on IIS by disabling the ‘Directory Browsing’ property of the virtual directory or site, which is used for storing MIME files: Internet Information Server=> Default WebSite => your_site_name =>Properties => Directory = > Directory Browsing (checkbox). SAP Note 531495 describes how to disable directory browsing in inqmy web server.

2. HTTP PUT To disable HTTP PUT command in J2EE web server for special application (B2B or B2C) you need to edit the file <J2EE_install_dir>\cluster\server\services\servlet_jsp\globalweb.xml and uncomment the lines starting with: <! Remove comment to protect all resources from PUT request leaving the above line in comments.


© 2005 SAP AG

92

92

You may find an example in the J2EE Administration manual.

Disable also HTTP PUT in IIS for virtual directory or site, which stores MIME objects: Internet Information Server => Default WebSite => your_site_name =>Properties => Directory => Write (checkbox)

3. Administrator password for J2EE server The admin pages of J2EE’s web applications (B2B or B2C) are protected by username – Administrator and a password. By default the password is left blank and is required to be changed. Please refer to documentation of J2EE server (valid after ISA 3.0 SP7).

4. FTP server If you replicate mime objects to the web server outside the firewall (e.g. IIS server) please ensure that FTP protocol is disabled after creating the directory structure (00FF). Background: The CRM system uses FTP to create catalog directories during the initial replication by the publishing server. Images and other catalog mimes are transferred with HTTPPUT. The standard FTP transfer mode is the active mode, which needs to open backward connections from source port 20 to a dynamically assigned target port range on the FTP client. If you do not want to allow incoming TCP connections into your Intranet, you should use passive mode. SAP note 0420512 describes how to activate passive mode.

5. Port on the firewall before J2EE server J2EE server opens several TCP ports used for controlling of its services. It is recommended to disable routing through the firewall before J2EE server of all the ports except for those used for HTTP (HTTPS) protocol. Please refer to your hardware supplier to clarify the setup of firewalls in your system.

In order the changes to take effect you need to restart your J2EE and IIS servers as well as firewalls.

We recommend to visit the ‘Secure Business with SAP’ web site in the SAP Net for further security methods. Address: http://service.sap.com/security. For further details: SAP Note 606733 composite SAP note on security of Basis 6.20

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.

http://service.sap.com/security


© 2005 SAP AG

93

93

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

7.1 Marketing System Landscape The main components of a SAP Marketing installation are summarized in the following table:

SAP CRM Enterprise System

The CRM Server is used as the central data storage and distribution unit for the CRM components and the data exchange with R/3 and other connected external systems.

CRM Mobile Clients Can use all marketing data available in CRM Enterprise

R/3 system The backend system covers functionality for financial accounting, controlling, and material management in case of the integration scenario.

SAP APO Provides information for planning

SAP BW with SAP SEM Provides information for planning and segmentation

The graphic above shows a typical hardware solution landscape for CRM Marketing, integrated with SAP R/3 and SAP BW.


CRM Server PROMO

Offer Offer

Conditions

Products

Order

Item

Item

Conditions

Products

S SA AP P R R/ /3 3

SEMBPS MSA

BW

SAP APO

COPA PS MM FI SD


© 2005 SAP AG

94

94

• 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


© 2005 SAP AG

95

95

7.2Core Business Processes in SAP CRM Marketing and Analytics

The following core business processes are considered to be the most vital processes for an SAP CRM Marketing and Analytics installation:

• Marketing Planning and Campaign Management • TPM Trade Promotion Management • Business Partner Segmentation

The management of these business processes along with a processoriented monitoring concept including the various components of an SAP CRM Marketing solution based on the solution with a connected Backend is described in this Best Practice document. As a lot of process steps interact with CRM middleware, please see also the generic chapter for BDOC monitoring. For each concerned step the appropriate BDOC is mentioned.

7.2.1Marketing Planning and Campaign 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.

Process Workflow for Marketing Planning and Campaign Management

At first, a marketing plan and further marketing elements (marketing plans, marketing plan elements, campaigns and campaign elements can be summed up with the term marketing elements) are created according to planning requirements.

Marketing plans are used for the longterm planning of marketing activities, including budgeting and scheduling. For example, they can be used as a management tool for annual costing in the Marketing


© 2005 SAP AG

96

96

department. Any number of marketing plan elements can be used to structure a marketing plan in the form of a hierarchy.

Campaigns can be assigned to marketing plans and form their operative structure. They describe the actions performed, for example mailing actions, TV spots, and telemarketing, so they are used for operative marketing planning and execution. Campaigns are broken down into campaign elements.

The creation of marketing elements can take place directly in the Marketing Planner or via the Marketing Calendar.

The Marketing Planner is a tool for creating and editing marketing plans and campaigns. It supports work with individual marketing plans and campaigns or with an entire plan hierarchy.

The Marketing Calendar is designed to act as a central entry point for field people and provides a working area that gives an overview of all promotional events within a certain time range. It allows defining criteria for displaying marketing projects by means of a query and therefore to look at marketing projects from several perspectives or viewpoints; for example, by brand, customer, or product group by selecting a particular view. Displaying is possible by a graphical view or a list view.

During saving the marketing elements and their hierarchy can be updated to BW.

For each marketing element some basic information as ID, description, type etc. has to be maintained. In the next step different objects can be assigned as target group, products.

For planning key figures from BW can taken into account during the next step. These values are directly updated to SEM.

During saving, the marketing elements can be transferred to R/3 to act as a cost collector.

After the marketing structure is saved and its status is changed to released, the campaign can be executed. Executing means to contact the business partners by the chosen channel, this can be via CIC, by mail or by other possibilities.

Therefore the followon steps are either the creation of a call list for CIC, the lead generation or the generation of emails. Additionally an activity can be created for each way, which can be extracted to BW.

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.

7.2.1.1 Business Process Step 1: Create Marketing Plan A marketing project can be created new or by help of a template. This can be done via the Marketing Calendar (transaction CRM_MKTPL_CALENDAR) or in the Marketing Planner directly (transaction CRM_MKTPL). A template can be an already existing marketing plan, a campaign (see later) or a Microsoft Project.

Data to be maintained can be i.e. priority and planning profile group, dates, segments and partner. Contrary to some other CRM Enterprise Applications, it is not possible to save an object in the marketing planner as long as it has a message of type 'error'.

When you save the marketing plan, it can be automatically transferred to BW by RFC.

A marketing plan can be transferred also to a mobile client by intelligent subscription. For this purpose BDOCs MKTPL_MKTELEM and CAMPAIGN_WRITE are used.

7.2.1.1.1 Monitoring Activities Monitoring Object Monitor

TA/Tool Monitor Freq.

Indicator or Error


Respon sibility

Marketing hierarchy, report CGPL_BW_ACTIVAT E_HIERARCHY

SM37 Daily Status Check Job Log Application monitoring team


© 2005 SAP AG

97

97

Monitoring Object Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility

mBDOC MKTPL_MKTELEM, sBDOC CAMPAIGN_WRITE

SMW01 Daily Status F01, E01

Check error message Application monitoring team

7.2.1.1.2 Error Handling, Restartability, and Escalation During the start of the marketing calendar, the system displays warning stating that the logon language was not maintained. This is caused by missing customizing and can be solved with the following path "CRM>Marketing>Marketing Planning and Campaign Management>Marketing Calendar>Define Field Settings for Table View" (according to note 710518). If views are missing in the marketing calendar, this can also be solved by customizing with path “CRM >Marketing>Marketing Planning and Campaign Management>Marketing Calendar>Define Views for Marketing” (note 727283). The list viewer in the calendar does not show any data. In this case the global layout is not maintained, which can be done according to note 674241. Transaction CRM_MKTPL_BW_UPDATE provides the possibility to transfer marketing projects to BW. This transaction can not be used in case of deactivation of marketing hierarchy update to BW in customizing. The automatic transfer of an element to BW can be deactivated in customizing according to note 631742 to improve performance. In this case report CGPL_BW_ACTIVATE_HIERARCHY should be scheduled on a regular base (i.e. daily according to note 611321) to update the hierarchy in BW. The report should be monitored by SM37. Errors during the download of marketing plans to mobile clients can be detected within SMW01 for MKTPL_MKTELEM. More details for monitoring and restartability procedures for middleware functionality for this step and the following can be found in the middleware chapter.

7.2.1.2 Business Process Step 2: Create Marketing Plan Element Marketing plan elements are used to structure a marketing plan. Please see the step Create Marketing Plan for Monitoring Activities, Error Handling, Restartability and Escalation.

7.2.1.3 Business Process Step 3: Create Campaign A campaign can be created new or by use of a template (an already existing campaign). Data to be entered are i.e. campaign type (helps to categorize individual campaigns), priority, authorization group, planning profile group (to use the corresponding planning profile from SEMBPS), partner responsible, currency, dates, action profile or status. Please see the step Create Marketing Plan for Monitoring Activities, Error Handling, Restartability and Escalation.

7.2.1.4 Business Process Step 5: Create Campaign Element With a campaign element a campaign can be structured. Please see the step Create Marketing Plan for Monitoring Activities, Error Handling, Restartability and Escalation.

7.2.1.5 Business Process Step 6: Assign objects to campaign elements Different objects can be assigned to marketing elements.

A target group is a list of business partners drawn up with a specific marketing activity in mind. A target group can be created both by executing the selection conditions for a marketing profile or independently of the profile. Therefore four possible sources for a target group exist, a selection based on marketing attributes of business partners in CRM, an infoset query within CRM, a query within BW or as of 4.0 also a query on business partners from an external system can be used. To create and work with the target group, the Segment Builder is used. This tool is HTMLbased and allows a user e.g. to split or to merge target groups based on different criteria. The creation of target groups will be discussed in a separate chapter later on.


© 2005 SAP AG

98

98

A product or product group, which should be promoted, can be assigned. For them special conditions can be maintained, which will be valid during the length of the campaign. These conditions can be determined in a sales order, which is created with reference to a campaign.

Business partners with partner functions can be assigned to a marketing element. Later on these partners can be used for activity management.

For a campaign element, a survey can be specified. This could be used as a feature within campaign automation process.

7.2.1.5.1 Monitoring Activities Monitoring Object

Monitor TA/Tool

Monitor Freq.


Respon sibility

Marketing element

Marketing Planner CRM_MKTPL

After creation

Error message Check error message User

7.2.1.5.2 Error Handling, Restartability, and Escalation Business partner determination will not occur, even if a partner determination procedure was maintained in customizing. This is not a program error. The determination can only be used to define allowed partner functions and minimum and maximum numbers per function. The requested functionality could be implemented by means of a BADI (note 724295).

In case of error messages regarding partners, which prevent from saving the plan, note 634022 offers help.

7.2.1.6 Business Process Step 7: Plan key figures Key figures from marketing plans and campaigns form the basis of planning and reporting. Key figure planning from SAP BW/SEM is fully integrated with CRM 4.0 to allow planning using the Marketing Planner as a basis. There is the option of carrying out key figure planning using an ALV grid or Excel sheet or in HTML. This option gives additional features, allowing synchronizing dates, products, target groups, sales organizations, customers, success measures, trade spends, EEW enhancements and currencies. This can all be done directly from the Marketing Planner. The technical basis for planning is the planning processor of SAP SEM, so the planning data is edited directly in SAP BW.

SAP CRM updates the master data for the marketing elements to SAP BW automatically during saving by RFC.


Monitor TA/Tool

Monitor Freq.

Indicator or Error


Respon sibility

Marketing Element

Marketing Planner

During creation

Error message Check message User

7.2.1.6.2 Error Handling, Restartability, and Escalation SAP SEM collects all planning errors in a log. Errors that occur when the planning system is called up are logged in the marketing planner directly.

Note 741512 provide a solution for common customizing problems in CRM Planning and its related errors (key figures set to zero, language of texts, short dump 'Function module UPX_KPI_API_XML missing', mode of fields, decimals of key figures).

7.2.1.7 Business Process Step 9: Transfer account object A connection between mySAP CRM and the SAP R/3 System is set up when actual costs or revenues for the marketing project should be entered and settled to Profitability Analysis. A marketing element can be assigned to an existing WBS element, or from the Marketing Planner a new WBS element can be created with an assignment to a marketing element.

When a marketing object is created in the Marketing Planner, it can be transferred to the R/3 project system manually or automatically, once a status allowing transfer is assigned. Manually transfer means to execute the transfer manually directly from Marketing Planner, automatically transfer means


© 2005 SAP AG

99

99

via middleware when saving the object. For the manual transfer the consistency can be checked in advance directly in the Marketing Planner.



Indicator or Error


Respon sibility

Transfer of campaign to R/3

Marketing Planner

After manual transfer

Status Check error message User

BDOC MKTPL_MKTELEM

Middleware monitoring SMW01

Daily Status Check error message Application monitoring team

Queue CSAMKTPL*

SMQ1 Daily Status Application monitoring team

7.2.1.7.2 Error Handling, Restartability, and Escalation For a successful transfer the following points have to be taken into account:

The mask used in CRM has to fit to the mask used in R/3.

In the Marketing Element the flag ‘Create WBS Element’ has to be set.

The fields transferred from the CRM marketing element/project to the R3 WBS element are: identification, description, plan start date, plan end date, actual start date, actual end date.

With transaction SMQ1 and SMQ2 the outbound and inbound RFC queues can be monitored. The queue name starts with CSAMKTPL*. Alternatively the queues and data transmission between the CRM and the R/3 system can be monitored with the Middleware Portal (SMWP). Investigate the cause for those queues in status stopped.

The related mBDOC for transfer of Marketing Elements to R/3 system is MKTPL_MKTELEM.

7.2.1.8 Business Process Step 11: Execute campaign After building up a target group, having it assigned to a campaign and releasing the campaign by changing its status, it can be executed. Therefore a communication channel has to be defined which is used to communicate to the customer. Possible channels are email, phone, leads, activities or open channel (BADI implementation). Execution of the campaign means to plan report CRM_MKTTGGRP_EXPORT_BATCH which will transfer the BP of the segment to the chosen channel and will trigger followon processing, which can be to generate emails, generation of a calling list, creation of OneOrder objects (leads, activities etc.) or transfer to open channel (an example implementation for the open channel can be found by note 672599).

There are two possible options, which people or organizations from the marketing segments should be addressed. This is the B2C scenario (Business to Consumer) or the B2B scenario (Business to Business). In B2C a person can be contacted using their private address, in B2B the person to be contacted is a contact person within a company, so it is contacted using the business address.

The execution of the campaign can be started synchronously or in parallel. In this case servergroups have to be set up. This can be done in RZ12.

During execution target group, campaign and contacts could be written into its related BW queues.



Indicator or Error


Respon sibility

Report CRM_MKTTGGRP_EXPORT_BATCH

SM37 After execution

Status Analyze error message

User / Application monitoring


© 2005 SAP AG

100

100


Monitor Freq.

Indicator or Error


Respon sibility

team

Marketing Element log Marketing Planer

After execution

Status Analyze error message

User

7.2.1.8.2 Error Handling, Restartability, and Escalation During the campaign executions, the system writes messages which can be displayed in the log of the respective execution. These messages are supposed to allow a more transparent view to the execution. For channel letter no print outs are done. In this case check the customizing of the printer in transaction SPAD. During campaign execution printing is done in background, therefore ‘Acc. Method’ on tab 'Access methods' could have all settings except F (Printing on Front End Computer). If F was selected, the printouts are put into the spool. In this case you can start the printout manually in SP01 (please see note 681104.) All generated contacts can be tracked by table CRMD_IM_ML_ITEM (consulting note 702996): Possible status are

• 0 = Contact Achieved • 1 = Contact Not Possible (Missing Communication Data) • 2 = Contact Not Possible (Incorrect Communication Data)

Communication data of the business partner is incorrect. • 3 = Contact Not Permitted (Max. Usage BP List)

Check for maximum usage of the business partner within a business partner list with External List Management (ELM).

• 4 = Contact Not Permitted (Block Indicator for BP) Indicators checked: donotuse / donotcontact / to be archived / central block

• 5 = Contact Not Possible (Technical Problems) Example: If the email to a business partner is blank and thus cannot be sent or if the email server does not return any confirmation.

In case of performance problems during campaign execution (or terminated jobs due to runtime) parallelization could be a solution. Note 524647 provide internal benchmarks, which performance improvements are possible. Further performance improvements are described by notes 672260 (Enhancement of index).

7.2.1.9 Business Process Step 12: Generate call list for CIC If channel telephone was chosen, the execution of the campaign will generate a call list for Customer Interaction Center (CIC). This call list can be assigned to an organization unit or to a telesales agent. Afterwards the business process Outbound Call of CIC can be executed.

The monitoring and error handling procedure is according to step Execute Campaign.

7.2.1.10 Business Process Step 13: Generate lead If channel lead was chosen, the execution of the campaign will generate leads. They facilitate the company’s chance to make business and qualify the level of interest presented by business partners. With the help of leads, a streamlined link between marketing and sales can be provided, so as to accelerate the process between first interest and sales. Leads do not provide complete details of potential business opportunities, but they can help to find out more about a potential business.

The monitoring and error handling is similar to step Execute Campaign.


© 2005 SAP AG

101

101

7.2.1.11 Business Process Step 14: Generate personalized email Predefined email forms can be assigned to individual marketing elements. These forms are used to create personalized emails for individual target groups. Personalized emails can be sent from within the CRM Marketing Planner using the Job Wizard in background. Beforehand the functionality can be tested in marketing planner on tab ‘Channels’. The marketing emails are sent to all business partners in the target group assigned to the marketing element. The mailing is performed through SAP Office. For each created email an activity with status closed can be created.

7.2.1.11.1 Monitoring Activities The monitoring activities of this process step strongly depend on the hardware used. Monitoring Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Responsibility

Sending of emails

SOST and SCOT

Daily Status See below Application monitoring team

CRM_MAIL SLG1 Daily Error status

Check message Application monitoring team

Email contact

CRMD_EMAI L_LIST

Daily See below User

7.2.1.11.2 Error Handling, Restartability, and Escalation During the campaign executions, the system writes messages which can be displayed in the log of the respective execution. These messages are supposed to allow a more transparent view to the execution. For reasons of clearness, the system does not display all messages in the log of the Marketing Planner. Messages during execution can be found in transaction SLG1 for object CRM_MAIL.

A more general view about the created emails provides transaction CRMD_EMAIL_LIST. The number of mails which were sent can be seen.

Sample note 694313 provides further information for common problems with emails (graphics in faxes, sending of URLs, URL tracking, restriction of email title, attachments…).

Transaction SCOT provides SAP Connect administration. Via View/Jobs you can check the status of jobs which were scheduled for report RSCONN01 for send processes.

Transaction SOST will provide an overview about sent requests and its status. Depending on the selection criteria chosen, the program displays send requests that are sent or have already been sent using SAP Connect.

A reorganization of entries of SOST is possible by reports RSSORE00 or RSBCSRE03. Documents will be deleted from the Business Workplace and associated send entries will be deleted from the SAP Connect status overview. The objects are only deleted if there are no references to these objects, that is, if the document is not stored in a folder by the user. This could also be a background folder or the outbox of a background user, under whose name the documents were sent.

Reports RSSORE00 and RSBCSRE03 should be scheduled every 12 week. Note 728063 (SAP Office: Reorganization as of 6.10) provides detailed information about these reports and useful others (as RSSODLIN (Deletion of inbox entries for individual users), RSSOTRCL (Deletion of shared trash), and RSSODLWF (Deletion of workflow). Also the reports RSSORESN (Reorganization of successful send operations) and RSSORE00 (physical removing out of database after deletion of mails) should be scheduled regularly.). Related component to this topic is BCSRVCOM.

In case of performance problems during parallel mailing please check according to note 610923, if you transfer the email address of the sender via the 'Email address' field on the 'Channel' tab. Instead please use a dummy business partner as sender.

If wrong business partners are contacted or some could not be contacted according to missing addresses, please check note 518671 for details of contact person determination.


© 2005 SAP AG

102

102

7.2.1.12 Business Process Step 15: Generate activities Activities can be generated for each channel (email, telephone…) when executing a campaign to get a complete story for a particular customer. They are created with status closed to document, that a certain kind of contact has been taken place.

Alternatively interaction objects can be created, which only contain the most important information about the outbound contact and therefore optimize performance.

7.2.1.12.1 Error Handling, Restartability, and Escalation For the creation of activities the monitoring and error handling procedure is according to step Execute Campaign.

Additionally note 544916 CRM Marketing: One Order generation during campaign will provide a detailed explanation which kind of business partner can be determined in a created OneOrder Objects.

7.2.1.13 Business Process Step 16: Update activities Created activities can be extracted to BW after creation. Therefore the have to be written into a delta queue and a regular scheduled report from BW has to get the data from this queue.



Indicator or Error


Responsibility

Datasource 0CRM_SALES_ACT_1

RSA7 daily Status Investigate the cause & try to restart the hanging queues


Queue CRM_BW* SMQ1 daily Status Investigate the cause & try to restart the hanging queues


Infopackage for datasource 0CRM_SALES_ACT_1

RSA1, RSMO in BW

daily Red status


7.2.1.13.2 Error Handling, Restartability, and Escalation Transaction RSA7 provides the overview about the delta queue and shows each single delta record to be transferred. Via RSA3 the data to be extracted can be simulated.

FAQ note 692195 will provide answers for common problems with data extraction between CRM and BW (no delta extraction, performance problems during extraction, difference between RSA3 and delta extraction).

As described in note 666635, CRM_BWA* queues should be deactivated, as there are only set up for testing reasons.

The initial and delta load will be planned from BW with transaction RSA1. An InfoPackage has to be set up to specify, which datasource at which time should be checked against new data. Monitoring transactions RSA1 resp. RSMO provide an overview about the status of data transfers for the certain objects.

For further information regarding the interaction with BW can be found in the generic part.


© 2005 SAP AG

103

103

7.2.2Trade Promotion Management (TPM) The following diagram shows the steps performed in this business process. Depending on the configuration carried out in your project, some elements might appear different from the description in this document.

Process Workflow for Trade Promotion Management

Trade promotions are marketing activities specific to the consumer goods industry which take place within a defined period of time. The aim of these activities is to boost brand capital, brand profile and market share, increase sales or position new products/product pallets on the market. Trade promotions facilitate strategic and tactical marketing and sales revenue planning and enable the implementation, validation and analysis of promotion strategies such as features, displays and temporarily reduced prices. The marketing planner is a platform for planning, maintaining, tracking and evaluating all merchandising activities which take place between a company and its retailer.

Trade promotions have the same structure as all other marketing projects, for example marketing plans or campaigns (see business process Marketing Planning and Campaign Management). However, they differ from these in that they are targeted at a particular key customer for whom certain conditions can be created to support the promotion.

The promotion can be created via the Marketing Planner or the Marketing Calendar. Within the Calendar at first a query has to be executed. A new trade promotion can be created for the appropriate time frame. When saving, its hierarchy is updated to BW directly.

The plan uplift quantities for products, key figures from SEM can be used. Planning is done during the next step in the promotion; the figures are updated to SEM automatically.

After planning conditions are generated in the promotion which should be found in sales orders if the customer orders the negotiated products. Therefore during saving the conditions are updated to R/3.

The planned uplift quantity is transferred to SAP APO directly during saving. In a later step, these quantities can be used for demand planning.

To collect costs for a marketing element, it can be transferred to R/3 in a separate step. Afterwards an account element is created in R/3.


© 2005 SAP AG

104

104

7.2.2.1 Business Process Step 1: Execute query in marketing calendar The marketing calendar is designed to act as a central entry point and to provide a working area that gives an overview of all promotional events within a certain time range, providing basic information, such as the name of the promotion, status and time range in the form of bars. It also allows to create new promotions or campaigns by creating a bar directly in the appropriate time range and to reschedule any planned activities by moving these bars around to a more appropriate time slot.

A query is created in the marketing calendar (transaction CRM_MKTPL_CALENDAR) to define criteria for displaying marketing projects from several perspectives or viewpoints; for example, by brand, customer, or product group.

For the query no special monitoring has to be performed. In case of missing information for deal in marketing calendar note 687328 provides information, how customizing has to be set up.

7.2.2.2 Business Process Step 2: Create trade promotion An existing trade promotion can be used as a template to create a new one. Alternatively it can be created newly or based on a deal. A deal is a set of promotional constraints that are applied to a pre defined set of customers for predefined products. They are created and maintained in CRM Enterprise.

Data to be maintained for a trade promotion are customer, planning profile group, sales organization, dates and other. Additionally a product or a group of products (category, hierarchy, and group) can be assigned.

The trade promotion can be created either in CRM Enterprise or on Mobile Sales and can be exchanged with each other.



Indicator or Error


Respon sibility

sBDOC CAMPAIGN_WRITE

SMW01 Daily Status F01 Check error message Application monitoring team

mBDOC MKTPL_MKTELEM

SMW01 Daily Status E01 Check error message Application monitoring team

7.2.2.2.2 Error Handling, Restartability, and Escalation BDOC CAMPAIGN_WRITE can be used for intelligent subscription of trade promotions to clients and can be monitored in transaction SMW01. Note 625903 describe how intelligent subscription in transaction SMOEAC has to be set up.

7.2.2.3 Business Process Step 4: Plan key figures Key figure planning from SAP BW/SEM is fully integrated with CRM 4.0 to allow planning using the Marketing Planner as a basis. There is the option of carrying out key figure planning using an ALV grid or Excel sheet or in HTML. This option gives additional features, allowing synchronizing dates, products, target groups, sales organizations, customers, success measures, trade spends, EEW enhancements and currencies. This can all be done directly from the Marketing Planner. The technical basis for planning is the planning processor of SAP SEM, so the planning data is edited directly in SAP BW.

There are in total 5 tabs in the marketing planner, which support key figure planning: Key Figures, Success Key Figures, Trade Spends/Volumes, Costs and Analyses. On the first one there is the option of planning on both the business partner and the product. On the Trade Spends/Volumes tab forecasting can be carried out to plan uplift sales volume and sales deduction.

SAP CRM updates the master data for the marketing elements to SAP BW automatically during saving by RFC, so that no extractor has to be used.


© 2005 SAP AG

105

105


Monitor TA/Tool

Monitor Freq.


Respon sibility

Marketing element

Marketing Planner CRM_MKTPL

During creation

Error message Check message User

7.2.2.3.2 Error Handling, Restartability, and Escalation SAP SEM collects all planning errors in a log. Errors that occur when the planning system is called up are logged in the marketing planner directly.

7.2.2.4 Business Process Step 6: Generate conditions In key figure planning, the trade spends for products, product groups or product categories are determined. Condition generation then converts this trade spends to condition records. There are two types of conditions possible: price determinationrelevant conditions and a condition for campaign determination.

The first ones of usage PR (price determination), BO (rebate agreement) or FG (free goods) control price determination when the trade promotion is executed. The system creates these condition records when the condition generation on the Trade Spends/Volumes tab is started. Afterwards they can be changed on tab Discounts.

The latter condition type is of usage CD (campaign determination) and controls campaign determination when the trade promotion is executed. Campaign determination is required so that price determination takes campaignspecific condition records into account. The system creates this condition record automatically when the trade promotion is released.

When saving the promotion, both types of records can be transferred to SAP R/3 and to mobile clients. They are automatically active and do not have to be released separately.


Monitor TA/Tool

Monitor Freq.

Indicator or Error


Responsibility

mBDOC CND_M_SUP

SMW01 Daily Status Check error message Application monitoring team

sBDOC CNBCCP*

SMW01 Daily Status Check error message Application monitoring team

7.2.2.4.2 Error Handling, Restartability, and Escalation With BDOC CND_M_SUP the condition records are transferred to R/3, with sBDOC CNBCCP* (i.e. CNBCCPSAP040 for condition table A040) the conditions are transferred to the clients. These BDOCs can be monitored in SMW01.

7.2.2.5 Business Process Step 7: Update uplift sales quantity The planning of trade promotions can be included in Demand Planning (DP) and Supply Network Planning (SNP) in SAP SCM. When the planning data is saved, the data is transferred to SCM, where a promotion is created.



Indicator or Error


Respon sibility

mBDOC MKTPL_MKTELEM

SMW01 daily status Check error message Application monitoring team

Marketing Element Marketing Planner log

After creation

Message Check message User

Queues SMQ1 daily stopped Check queue status Application


© 2005 SAP AG

106

106


Monitor Freq.

Indicator or Error


Respon sibility

CSA_MASS_MKTPL, CSA_MKTPL*, AI* and CRM_MKTPL_APO_INT

monitoring team

7.2.2.5.2 Error Handling, Restartability, and Escalation If any errors occur during replicating to APO, these errors can be checked in the Marketing Planner via Extras > Logs > APO Integration.

The transfer to APO is handled by BDOC MKTPL_MKTELEM. Its status can be checked in SMW01.

7.2.2.6 Business Process Step 10: Transfer account object A connection between mySAP CRM and the SAP R/3 System is set up when actual costs or revenues for the trade promotion should be entered and settled to Profitability Analysis.

When the trade promotion is created in the Marketing Planner, it can be transferred to the R/3 project system manually or automatically, once a status allowing transfer is assigned. Manually transfer means to execute the transfer manually directly from Marketing Planner, automatically transfer means via middleware when saving the object. For the manual transfer the consistency can be checked in advance directly in the Marketing Planner.



Indicator or Error


Respon sibility

Transfer to R/3 Marketing Planner

After manual transfer

Status Check error message User

BDOC MKTPL_MKTELEM

Middleware monitoring SMW01

Daily Status Check error message Application monitoring team

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

7.2.2.6.2 Error Handling, Restartability, and Escalation Within the marketing planner, via Extras > Logs > R/3 Integration logs can be found.

For a successful transfer the following points have to be taken into account:

The mask used in CRM has to fit to the mask used in R/3.

In the Marketing Element the flag ‘Create WBS Element’ has to be set.

The fields transferred from the CRM marketing element/project to the R3 WBS element are: identification, description, plan start date, plan end date, actual start date, actual end date.

With transaction SMQ1 and SMQ2 the outbound and inbound RFC queues can be monitored. The queue name starts with CSAMKTPL*. Alternatively the queues and data transmission between the CRM and the R/3 system can be monitored with the Middleware Portal (SMWP). Investigate the cause for those queues in status stopped.

The related BDOC for transfer of Marketing Elements is MKTPL_MKTELEM, which can be monitored in SMW01.


© 2005 SAP AG

107

107

7.2.3Business Partner Segmentation The following diagram shows the business process steps covered in this monitoring concept. Depending on the configuration carried out in the customer’s project, some elements might appear different from the description in this document.

Process Workflow for Business Partner Segmentation

To communicate with customers in a purposeful manner, it must be known who the customers are, and which kind of interests and purchasing behavior the have. The existing marketing data on business partners therefore makes a valuable contribution when modeling target groups for marketing activities. Dividing customer master into different groups is called customer segmentation, and depends to a great extent on the planned marketing activity. The segments created can then be processed in different ways, according to the particular needs and preferences of the business partners they contain.

Target groups can be created from a variety of different data sources by combining selection criteria obtained, for example, from InfoSet queries, BW queries, business partner master data and from acquired address lists. Therefore in first steps either marketing attributes, (which are grouped to attribute sets) InfoSet queries or BW queries have to be created. In a second step they are the basis of a datasource, which can later on be assigned to an attribute list.

The attribute list can be used in the segment builder to create at first a profile set, related profiles and for them target groups. If attributes based on InfoSet query or BW query are used, the query is executed directly in the appropriate backend system or in BW system.

In a next step target groups may be attached directly to marketing campaigns. From the CRM Marketing Planner, the business partners in the target groups can be contacted by a variety of channels including SMS, email, and telephone. This is described in Business Process ‘Marketing Planning and Campaign Management’.

There are also the options of contacting target groups directly without reference to a campaign, extracting them into a file for further use or creating business transactions for the BP directly. All these steps can be performed directly from the Segment Builder.

7.2.3.1 Business Process Step 1: Create marketing attribute Attributes are used as criteria for differentiating between business partners. They can be used to perform individually tailored marketing activities. Attributes can be created manually or by using a template in transaction CRMD_PROF_CHAR.

http://help.sap.com/saphelp_crm40/helpdata/en/09/6c2f0efacbd311ba4d0800060d888b/content.htm


© 2005 SAP AG

108

108

When the attribute is saved, it can be subscribed to the clients via BDOC. If the subscription to the clients is not necessary, it can be prevented by means of note 711267. In this case the mobile bridge should be deactivated for the relevant BDOC CHAR_MSG by transaction SMW3_00.

Marketing attributes can be extracted to BW by datasource 0CRM_MKTATTR_ATTR.



Indicator or Error


Respon sibility

mBDOC CHAR_MSG SMW01 Regularly Error status E01


sBDOC Attribute SMW01 Regularly Status F01


Datasource 0CRM_MKTATTR_ATTR

RSA7 Regularly Status Investigate the cause & try to restart the hanging queues


Infopackage for datasource 0CRM_MKTATTR_ATTR

RSA1, RSMO in BW

Regularly Status Check error message Application monitoring team

7.2.3.1.2 Error Handling, Restartability, and Escalation mBDOC CHAR_MSG and sBDOC ATTRIBUTE belong to marketing attributes. BDOC monitoring should be done by transaction SMW01. If there are error messages for the related BDOCs, this can be due to differences for attributes in CRM Online and in CDB.

Report CRM_MKTMSA_ATTRIBUTE_DELTA of note 591183 compares the data in Online tables and CDB tables (CABN, CABNT, CAWN, CAWNT and SMOCABN*, SMOCAWN*) and generates BDOCs when necessary.

Transaction RSA7 provides the overview about the delta queue and shows each single delta record to be transferred. Via RSA3 the data to be extracted can be simulated.

The initial and delta load will be planned from BW with transaction RSA1. An InfoPackage has to be set up to specify, which datasource at which time should be checked against new data. Monitoring transactions RSA1 resp. RSMO provide an overview about the status of data transfers for the certain objects.

7.2.3.2 Business Process Step 2: Create attribute set An attribute set is used to group attributes created specifically within CRM Marketing together for a marketingrelated purpose in transaction CRMD_PROF_TEMPL. When saving the attribute set, it can be subscribed to the clients via CDB. If the subscription should not be possible (mobile clients are not used), BDOC PFTPL_MSG can be disabled in transaction SMW3_00 according to note 711267. Attribute sets can be assigned to business partner master data in transaction BP. Afterwards each attribute can be specified for the business partner. This attribute specification can be transferred to the clients as well.



Indicator or Error


Respon sibility

mBDOC PFTPL_MSG, MKTPROF_MSG and CHARVAL_MSG

SMW01 Regularly Status E01 Check error message Application monitoring team

sBDOC CLASS OBJCLASS,

SMW01 Regularly Status F01 Check error message Application monitoring


© 2005 SAP AG

109

109


Monitor Freq.

Indicator or Error


Respon sibility

OBJCHARACTERIS team

7.2.3.2.2 Error Handling, Restartability, and Escalation BDOC monitoring should be done by transaction SMW01 (please refer for general information to the generic chapter).

mBDOC PFTPL_MSG and sBDOC CLASS belong to an attribute set, mBDOC MKTPROF_MSG and CHARVAL_MSG and sBDOC OBJCLASS and OBJCHARACTERIS belong to BP specification.

If you find errors in BDOC processing in SMW01, several check reports should be started in order to find possible inconsistencies between online and the client.

The relevant check report for attribute sets is CRM_MKTMSA_ATTR_SET_DELTA (note 591186). It will generate new BDOCs, if there are differences for tables KLAH, KSML, SWOR, KLAT and CDB tables SMOKLAH, SMOKSML, SMOSWOR und SMOKLAT.

The relevant check reports for BP specification on CRM Online and the clients are mentioned in note 591233.

• First, you should check whether all notes from sample note 545391 have been implemented in the system. If this is not the case, it is absolutely necessary that you implement them. If you have not implemented any of the notes, differences may have occurred. Therefore, you should carry out an initial download in R3AS if possible (refer to note 545391). If an initial download is not possible, execute the following reports. In this process you must make sure that no BDOCs are generated on CRM server or Mobile Sales side at this time.

• Start report CRM_MKTMSA_CHECK_KSSK. You should start this report in your system every night because empty BDOCs of Mobile Sales may cause unnecessary records in table SMOKSSK.

• Start report CRM_MKTMSA_CHECK_AUSP.

• Start report CRM_MKTMSA_CHECK_SMOKSSK.

Depending on the auxiliary table in which entries can be found, you must start the following reports:

• If there are entries in table CRMD_MKTMSA_CH5, create a SAPNet R/3 Frontend message.

• If there are entries in tables CRMD_MKTMSA_CH4 or CRMD_MKTMSA_CH7, start report CRM_MKTMSA_DELETE_SMOKSSK.

• If there are entries in table CRMD_MKTMSA_CH2, start report CRM_MKTMSA_DELETE_SMOAUSP.

• If there are entries in table CRMD_MKTMSA_CH1, start report CRM_MKTMSA_UPDATE_SMOAUSP.

• If there are entries in table CRMD_MKTMSA_CH6, start report CRM_MKTMSA_UPDATE_SMOKSSK.

• If there are entries in table CRMD_MKTMSA_CH3, create a SAPNet R/3 Frontend message.

Then restart the three check reports. If the tables still contain entries, create a SAPNet R/3 Frontend message. When you execute the check reports, it is absolutely necessary that no activities concerning marketing attributes occur in CRM Online. BDOCs must not be posted at this time either.

7.2.3.3 Business Process Step 3: Create infoset query InfoSets are used for segmentation to access business partner master data (stored for example in the R/3 System). Therefore the Infoset must make its selections using fields relating to the business partner and must be able to return business partner keys. Ideally these keys are GUIDs. If this is not possible (for example because this Infoset lies in a system in which the GUID is not known, such as an SAP BW or an SAP R/3 System) then it must be a key that can be converted into a GUID in CRM. Infosets in CRM are created by transaction SQ02 and should be created for the global work area. The query can be tested in SQ01.


© 2005 SAP AG

110

110

SAP provides additionally a lot of standard InfoSets covering many of the queries most useful for marketing purposes.

There is no special monitoring for this step.

7.2.3.4 Business Process Step 4: Create BW query BW queries are used to access transactional data stored in the SAP BW System. The BW query can be tested in RSRT on BW system.

To ensure the best possible system performance, try where possible to avoid:

• Unnecessary characteristics, attributes, or key figures

• Superfluous conditions or variables

• Complex key figures

• Large cubes

• Complex hierarchies

• A lot of coding in variables filled by means of user exits

In addition, specify for characteristics either variables or restrictions but not both together.

7.2.3.4.1 Error Handling, Restartability, and Escalation Restrictions for the usage of BW queries for segmentation are described in note 605208.

7.2.3.5 Business Process Step 5: Create data source A data source describes the origin of attributes used to create attribute lists. Data sources can be created in transaction CRMD_MKTDS by help of Data Source Wizard. 4 different origins are possible: attribute sets, BW queries, Infoset queries and External List Management. A RFC destination for a data source should only be maintained if data is taken from an external system! Errors during creation of a data source are shown in the transaction itself. There is no separate monitoring transaction, error messages are shown directly.

7.2.3.6 Business Process Step 6: Create attribute list Attribute lists are lists of selection criteria used in Segment Builder for modeling marketing profiles. These selection criteria can derive from one of the following data sources as described in the last steps:

• Business partner master data (obtained by Infoset queries)

• Marketing attributes (grouped together as attribute sets)

• Key figures and attributes from the BW (obtained by BW reports)

• External List Management

The maintenance transaction is CRMD_MKTDS. There is no special monitoring transaction, error messages during creation are shown directly.

7.2.3.7 Business Process Step 7: Create profile set A profile set consists of individual marketing segments profiles, target groups and other profile sets which were modeled together and which are to be interpreted together. The profile set is created in Segment Builder based on attribute specification.


7.2.3.8 Business Process Step 8: Create profile Profiles are used to describe marketing objects. In the Segment Builder, profiles are modeled by combining selection criteria from different sources with a view to create specific target groups. So a profile is a semantic description of a target group in terms of the selection criteria used to create such

http://help.sap.com/saphelp_crm40/helpdata/en/ab/727ec214cfd311ba4d0800060d888b/content.htm

http://help.sap.com/saphelp_crm40/helpdata/en/b2/e5ad1984c7d411b11b0008c784efb1/content.htm


© 2005 SAP AG

111

111

a group. All of the selection criteria within the profile must be met before a business partner matches the profile.


7.2.3.9 Business Process Step 9: Create target group A target group is a list of business partners that have been combined for a specific marketing activity. A target group can be created by executing the selection conditions for a marketing profile directly in the Segment Builder.

Other possibilities are the independent creation by importing a list of business partners from an external system and the selection of target groups in the BW system (transaction rstg_bupa) to create them from there directly in CRM.

The creation of a target group can be scheduled as a (periodic) background job ‘TARGET GROUP SELECTION’ (program CRM_MKTTG_TG_SELECTION).

Target groups can be extracted to BW, but only during campaign execution (note 717539). For this purpose datasource 0CRM_CONTACT_IN can be used. Further information regarding campaign execution can be found in business process Marketing planning and Campaign Management.



Indicator or Error


Responsibility

Program CRM_MKTTG_TG_SELECTION

SM37 daily Status Check job log Application monitoring team

7.2.3.9.2 Error Handling, Restartability, and Escalation If target groups are created by a background job, transaction SM37 should be used to monitor program CRM_MKTTG_TG_SELECTION. In case of performance problems for target group creation directly in Segment Builder please refer to note 538984, which is a sample note for all known issues.

7.2.3.10 Business Process Step 12: Export target group Three different further processing steps can be performed for a target group, which need no reference to a campaign. The function Export target group is used to export the business partner data for a target group to a file, in order to process this data further at a later date, or simply for storage purposes.



Indicator or Error


Respon sibility

Report CRM_MKTTG_PROC_TG_FEXP_B ATCH

SM37 Daily Status Check job log Application monitoring team

7.2.3.10.2 Error Handling, Restartability, and Escalation Report CRM_MKTTG_PROC_TG_FEXP_BATCH is used for export to the application server. This report can be monitored by transaction SM37. Please check the status of the job. Possible errors can be found in the job log.


© 2005 SAP AG

112

112

7.2.3.11 Business Process Step 13: Transfer target group to channel With this function the target groups can be sent directly to the desired communication channel without going via a campaign (as described in business process Marketing Planning and Campaign Management).

Before sending, the communication data is checked. Only those business partners with correct addresses are contacted. This check is not used for the open channel.

In the SAP GUI there is the option to trigger the sending of several target groups to the corresponding channel simultaneously.

If button Generate Contacts is chosen in the SAP GUI, a contact is created for every single business partner.




Respon sibility

Program CRM_MKTTG_PROC_TRANS_BATCH


7.2.3.11.2 Error Handling, Restartability, and Escalation Program CRM_MKTTG_PROC_TRANS_BATCH is used to transport to the target group to channels without campaign reference. This program can be monitored with transaction SM37. In the job log possible errors can be found.

7.2.3.12 Business Process Step 14: Create business transactions This function can be used to generate business transactions contact, task or lead for the members of the target group directly from the Segment Builder. Different fields (transaction type, priority, period, person responsible, and product) can be filled, depending on which transaction is selected.



Indicator or Error


Respon sibility

Program CRM_MKTTG_PROC_ORDER_B ATCH


7.2.3.13 Error Handling, Restartability, and Escalation Program CRM_MKTTG_PROC_ORDER_BATCH is used to create the chosen business transaction for the target group. This program can be monitored with transaction SM37. In the job log possible errors can be found.


© 2005 SAP AG

113

113

8 Generic Part In the Generic Part of this Business Process Management Best Practice you will find information regarding those steps and processes that are common to several CRM scenarios. The following topics are covered:

• Availability Check • Connection to SAP Business Warehouse (BW) • BDoc Monitoring and Handling • RFC Monitoring • Performance Monitoring • Batch Jobs • Mass Data Changes

These sections are referenced in the corresponding business process steps of the scenario specific parts above.

8.1Availability Check The Availability check topic of the CRM Generic Part of this document deals with those steps involved in the availability checking process, that are common to the interaction center, field sales and eselling scenarios. When a sales order is entered in the Customer Relationship Management (CRM) System, it may be important for the customer to know whether the products are available and can be delivered on time. The system can activate an availability check and scheduling for each line item of the sales order or quotation. In order to confirm whether the requested items can be delivered on time, the following functions need to be carried out: • AvailabletoPromise (ATP) availability check • Delivery Scheduling • Transportation Scheduling These functions are carried out, every time a customer order or quotation is created or changed and a date for the delivery is specified, either by the R/3 system or by the mySAP Advanced Planner and Optimizer (APO) System, which is the SAP system used for Supply Chain Management.

• Check availability in APO The following basic methods of availability check used in SAP APO are supported in CRM Enterprise: Product Availability Check and Rulesbased Availability Check. The confirmed amounts are reserved in the APO system. The requests are transferred to production or purchasing, when the sales order is saved in CRM online. After the availability check, details for each item are transferred back to CRM Enterprise, such as: Delivering country (for tax reasons) and region (U.S.), confirmed quantities, confirmation dates, globally unique identifier (PosGUID or GUID used for requirements in SAP APO) and the item category usage

8.1.1.1.1 Automated monitoring via Solution Manager Monitoring Object

Monitor TA/Tool

Monitor Freq.



Responsibility

APO Log SolMan Weekly and upon error

# errors < 1 Errors or warnings

Check for the reason of the error in the log.


For details on the APO Demand Planning application log and the monitoring setup procedures use the following link http://service.sap.com/~sapidb/011000358700003081072005E and navigate to section 2.2.

http://service.sap.com/~sapidb/011000358700003081072005E


© 2005 SAP AG

114

114

• Check availability in R/3 The product availability check using the R/3 system gives your customers information on the latest availability situation. Temporary reservations are made. The confirmed data and the delivery date with the available amount are shown on the item level to customers when transferring a product into the shopping basket. If you carry out material requirements planning in SAP R/3 Enterprise (SAP R/3), you can carry out availability check in the business transaction in CRM Enterprise using SAP R/3. This function is supported for SAP R/3 4.6B and higher. The functions are similar to those used when you carry out an availability check using SAP APO. The system transfers requirements to production or purchasing, reserves stock and carries out scheduling for delivery and transportation. SAP R/3 transfers the results of the availability check back to the business transaction in CRM Enterprise. The confirmed data and the delivery date with the available amount are then shown on item level. You can use the following processes in SAP R/3 in combination with availability check using SAP R/3: Transportation and shipment scheduling to determine the material availability date, followup activities such as outbound delivery and goods issue, product allocation and backorder processing. For backorder processing the system however does not set the order status to Rescheduled, as is the case when you carry out availability check with SAP APO.

8.1.1.1.2 Error handling In case of problems you can run an ATP simulation to check whether ATP works correctly. If you check the availability in R/3 you can perform a simulation in R/3 using transaction CO09. if your availability check is done in APO transaction AO09 can be used in the APO system accordingly – in CRM a dummy sales order should be created to compare both. If the displayed available amount for a product is equal to zero, it means in normal operation conditions that there is no stock in the warehouses, but it could also be an error. As well, if there are any doubts regarding the given quantity, proceed as follows: Availability Check done in R/3: Check the availability for that product with transaction CO09 in R/3. If the result differs from zero, this indicates a functional error within the availability check in CRM. We recommend opening a SAPNet message for further investigation. Availability Check done in APO: Check the availability for that product in the APO system with transaction /sapapo/ac04. If the result differs from zero, this indicates a functional error within the availability check in CRM. We recommend checking the customizing and if the issue still occurs, you should open a SAPNet message for further investigation.

If you are using an APO system, we also recommend you to check the following documents for APO specific monitoring:

Monitoring and Administration for SCM / APO helps you analyzing the workload and performance on liveCache and the APO database (APO specific monitoring (life cache, optimizers, APOR/3, regular jobs)).

Manage APO Core Interface in SCM deals with the Business Process Management of the APO CIF and is an essential enhancement to this document. All the jobs and monitoring activities listed in the CIF document have to be considered in every business process step that sends or receives data through CIF.

Manage the Global ATP Service, this procedures ensures the smooth and reliable flow of the Global ATP service, independently of the core business process that uses the Global ATP service

System Monitoring for SAP APO / mySAP SCM, explains how you can use the comparison program CIF_DELTAREPORT to achieve data consistency between SAP Advanced Planner and Optimizer (APO) system of release 3.0 and 3.1, and your other R/3 systems that use APO services

This documents can be found in the service marketplace. Monitoring and Administration for SCM / APO (PDF) Manage APO Core Interface in SCM (PDF) Manage the Global ATP Service (PDF) System Monitoring for SAP APO / mySAP SCM (PDF)

https://sapneth10.wdf.sap.corp/~sapidb/011000358700007382642002E





© 2005 SAP AG

115

115

8.2Connection to SAP Business Warehouse (BW)

8.2.1.1 Business Process Step: Update Information to BW system Relevant key figures of the business processes are passed from the CRM system to the SAP Business Information Warehouse (SAP BW). With this information the SAP BW can analyze e.g. the success of the business process on the basis of generated analysis objects.

8.2.1.1.1 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 Object

Monitor TA/Tool

Monit orFreq.

Indicator or Error


Responsibility


Daily Long times (>1000 ms per line item)

Monitor RFC Statistics, see also the section performance monitoring


BDocs smwp (CRM)



Queues smwp, smq1, rsa7 (CRM)


Investigate the cause & try to restart the hanging queues


Infopackages rsa1 (BW) Daily Red light at Infopackage Monitor



Monitor TA/Tool

Monitor Freq.

Threshold Indicator or Error Monitoring Activity or Error Handling Procedure

Responsibility

Background jobs running on BW system updating CRM statistics

SolMan Daily To be set Start and enddelay, Out of time window, Maximum Duration, Cancellation, Parallel processing of jobs, Job log messages

Check for the cause


8.2.1.1.3 Error Handling, Restartability, and Escalation • Monitor with the Middleware Portal (smwp) the data transmission between CRM and BW

system. Queues destined for the BW system should be relatively short and quickly processed. Investigate the cause for those queues in status stopped. Restart hanging queues if possible.

• Monitor regularly the RFC response time statistics with the statistical records monitor (stad), system workload analysis monitor (st03) and SQL trace monitor (st05) in the CRM server and BW system.

• Monitor regularly the outbound queues in CRM within transactions smq1 and/or rsa7. • If no entries in the delta queues are created for transactional data, then check if outbound

queues which names begin with CRM_BWA###### (# is a number) do exist in the CRM system. Activate/restart these queues. After this activation the BW delta queues should be filled.

• Use the infopackage monitor of the Administrator Workbench (transaction rsa1) in BW to check whether all infopackages had been uploaded successfully from CRM to BW. If there are failed requests, then check the logs to investigate the cause of the errors.


© 2005 SAP AG

116

116

• Use the Extractor Checker (transaction rsa3) in CRM to analyze the extraction from CRM to BW if necessary. Have a look at note 529789 for explanations if there are differences between the actual extraction from CRM to BW and the results of the Extractor Checker in CRM.

• If you could not find the cause of the problem with this checklist, then open a SAPNet message for further investigation.

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

Flow Contexts: overview

Outbound Adapter Mobile

Replication /

Realignment

Inbound processing

sBDoc

Inbound qRFC

mBDoc R/3 Adapter

XIF Adapter

BW Adapter

sBDoc

R/3 Adapter

BW Adapter

XIF Adapter

Mobile Bridge

BAPI

BAPI

Outbound qRFC

sBDoc

Synchronization flow

Inbound Adapter Mobile

Outbound processing Validation

Synchronisation Flow CRM

Adapter

mBDoc

replication

SI1 MI0

MO1, MO2, MO3, MO4 MOA, MOB, MOC

SO1, SO2, SO3, SO4 SOA, SOB, SOC

8.3.1Monitoring It is important to monitor your system actively (using SMWP, SMW01, SMW02, SMW03) or passively (using CCMS or flow error handler) and solve issues related to BDoc messages immediately. Critical


© 2005 SAP AG

117

117

BDoc messages are BDoc messages staying in error or for a long time in temporary status. Not dealing such BDoc messages can lead to inconsistencies in the CRM system landscape (CRM, CDB, R/3 backend system, mobile clients).

BDoc messages are composed of:

• Exactly one message header,

• A list of message receivers (Outbound processing),

• A list of validation errors (mFlow inbound processing),

• A message body

• A message extension (mBDocs only), this extension is supposed to hold the transaction data, whereas the classic part shall only contain fields used in the receiver determination by the replication component.

• A list of root IDs for each receiver (may be empty),

• A list of receiver specific error information.

When searching for important SAPNet Notes please enter the Bdoc and the status. The following monitors are available:

8.3.1.1 SMW01

You can display and trace the flow of BDoc messages within the CRM Middleware. You can delete incorrect BDoc messages, trigger further processing of processed BDoc messages, and display the recipient list and receiver errors.

Menu path: Middleware Monitoring Message Flow Display BDoc Messages Transaction: SMW01 a) Analysis • Search for special error situations per BDoc ID, date, Site ID, message ID

Successfully processed messages appear with a green light, those still in process with a yellow light, and those with a terminal error condition with a red light.

b) Display functionality • Display the Middleware Trace

Choose BDoc Message > Display > Middleware Trace • Display the data content

Choose BDoc Message > Display > Display data segments to show the classic part Choose BDoc Message > Display > Display data extension segments to show the extension part Both options are also available as XML output.

• Display a recipient list (internal receivers like CRM and CDB are not shown). c) Corrective action • Reprocess failed BDocs (see below)

Choose BDoc Message > Retry to process Note: Do not reprocess the BDoc messages without checking of overlapping effects, overwriting actual data!

• Delete incorrect BDoc messages (PP: was ist eine inkorrekte BDoc message?) Choose BDoc Message > Display > Display error segments Choose BDoc Message > Processing > Mark as deleted Note: Failed BDoc messages must be analyzed and the errors have to be solved. The non processing of the error messages will lead to inconsistencies in the system landscape, as the messages contain updates or new objects that have to be updated in the receiver system.


© 2005 SAP AG

118

118

Do not delete BDoc messages without solving the problem! Deleting a BDoc message means that the receiving system(s) will not be updated and thus creating inconsistencies. Only delete BDoc messages when you are sure that it is obsolete or can be recreated by sending the application object again.

• Trigger further processing of processed BDoc messages

8.3.1.2 SMW02 Alternatively you can use transaction SMW02 that summarizes BDoc messages and gives a good overview about the amount of BDoc messages as combination of BDoc type, state, flow context and receiver (site ID). By doubleclicking on a summary line you will see the single BDoc messages by calling transaction SMW01. SMW02 is used to display BDoc messages in an aggregated view on the basis of various criteria. Menu path: Middleware > Monitoring > Message Flow > Display BDoc Message Summary Transaction: SMW02

8.3.1.3 SMW03 Display the total number of unprocessed BDoc messages, grouped by BDoc type and client. You can use this information to check the system status for monitoring purposes, or before you install a support package.

8.3.2Usage Menu path: Middleware Monitoring Message Flow Display unprocessed BDoc Message Summary Transaction: SMW03 Procedure: Enter a client, BDoc type, and BDoc status. Choose an existing ABAP List Viewer (ALV) layout and click Execute.

There are different reasons for unprocessed BDoc Messages: Wrong customizing Missing ‘required’ fields sBDoc, mBDoc errors RFC Connectionn problems MW specific problems Application specific problem related to data or to customizing

The resolution of unprocessed messages is based on the following actions: Solve the problem and reprocess the message Reprocess the BDoc message Set to processed Request the data from the reference system and set message status to processed

The following table lists the possible actions to put ‘unprocessed messages’ into a final state:

Function Description

Mark message as deleted/processed

Deletes a message, SMW01

Retry to process message Processes message further, SMW01

Define, start and monitor single requests for load

R3AR2, R3AR4, R3AR3

Synchronize objects R3AS4, R3AM1

Process aborted BDoc Messages

SMW20


© 2005 SAP AG

119

119

Unlock data in source or target system and repeat

Application

The following table lists the tools and functionalities that are available for analyzing the problem:

Receivers Displays a list of the receivers of a message

Errors Displays error segments

Middleware Trace Displays records for individual steps

Classic Data Data segments of a message

Extension Data Extension of a message (only for mBDoc messages)

Outbound queues SMQ1 (see also outbound queue scheduler SMQS)

Inbound Queues SMQ2 (see also inbound queue scheduler SMQR)

Mobile clients In and Outbound Queues

SMQ1, SMQ2 or SMWMQUEUES

Short Dumps ST22 (+ 15 minutes), select update User

Links Links between messages and object types

8.4Interface Monitoring During this chapter the focus will be on the business related data exchange between two or more systems. In general Interface Monitoring with SAP Solution Manager is possible for the following Interface Techniques:

ALE/EDI (effective from SAP R/3 4.6C) qRFC (effective from SAP R/3 4.5B) tRFC (effective from SAP R/3 4.5B)

Currently only the IDoc and qRFC monitoring is really meaningful from a Business Process Monitoring perspective. The tRFC monitoring works only generically (all status and all destinations) so that the assignment to one (graphical) interface within the business process is quite imprecise. The monitoring of other components (e.g. Internet Transaction Server or Business Connector) works indirectly as everything that is somehow presented in the CCMS infrastructure can be assigned to one (graphical) interface.

For further details and the setup information refer to http://service.sap.com/bpm > Media Library > “Business Process Monitoring Setup Guide”.

8.5Performance Monitoring In this chapter you will find the description of a general procedure for performance monitoring of your CRM system. The different transactions that are mentioned in the procedure are described in detail below. Please keep in mind that this is general information. For specific recommendations for a scenario (e.g. for Field Sales or ECommerce) please check the corresponding chapters above.

Please also consider the training BC315 Workload Analysis. This course covers topics like workload monitor, statistical records, expensive SQL statements, memory management, database monitor and buffer analysis among others.

http://service.sap.com/bpm


© 2005 SAP AG

120

120

Additionally there is the possibility to monitor the dialog performance in an automated manner using SAP Solution Manager. As of STA/PI01F it is possible to monitor Dialog Performance not just for the whole transaction, but also broken down to function code level of a transaction, i.e. specific dialog steps.

A dialog transaction consists of various dialog steps. A dialog step is usually a screen change within one transaction. But not all of these screen changes might be equally performance critical. For example, transaction VA01 can be used to create sales orders. Let’s imagine a customer is experiencing performance problems for this transaction while saving. During all other dialog steps (screen changes) the performance is very good. To monitor the performance of the whole transaction might not be very useful, since the very quick screen changes within the transaction compensate the long duration of the saving and therefore influence the average response time per dialog step. In order to just monitor the saving of VA01, you would need to monitor just the dialog steps with function code ‘SICH’ for transaction code VA01. For detailed information refer to http://service.sap.com/bpm > Media Library > “Application Monitoring and User Exit Setup Guide”.

8.5.1General information As part of the daily monitoring activities of your CRM system you should not only watch system availability, system resource consumption and middleware queues (among others), but also the performance of your CRM system. There are several transactions available with which you can monitor the average performance of the system and analyze the cause for bad performance. Bad performance of a system is generally equal to extremely high response times. This may be related to long lasting transactions steps (dialog steps), background jobs running too long, RFC calls taking too long, etc.

The response time of a transaction step is the difference in time between the point when the request arrives in the R/3 System and the point when the R/3 System completes the processing. In addition to this measurement of time, other different times, such as waiting times or database times, are still measured in R/3. If you substract these components from the response time, this leaves the processing time which cannot be directly measured. ABAP programming code is processed during the processing time.

Definitions of the most important components of the Response time:

Time in workprocess Time actually spent in the workprocess (after the dispatcher has found a free workprocess)

Wait time The dispatcher is waiting for a free work process (= dispatcher queue). CPU time It is only given as a sum per transaction step in the workload statistics DB time Time for accessing and waiting for the database interface, and therefore for

the underlying database Load/Generating time Time for loading/generating screens, ABAP programs, and CUA elements (not

for presentation). Rollin time Time for rolling in the roll area context of a dialog step Enqueue time Time for setting a logical SAP enqueue Processing time This time is calculated as follows:

Processing time = Response time Wait time Load/Generating time DB time Rollin time Enqueue time

Important: the CPU time should not be added to the above lines, as it is a total, consisting of parts of the times listed above that cannot be calculated. CPU time is returned by the operating system. The accuracy of the reported value depends on the timer of the operating system (under UNIX,for example, the timer works with 100 Hz so that the CPU time is reported as a multiple of 10 ms). Due to this rough resolution of the CPU time, it is possible that a slightly longer CPU time is displayed for a dialog step than for the response time. The RollOut time is not part of the response time, as it only occurs after the data is transferred to the presentation server. The Roll wait time is a time in which a work process is waiting for the response of a RFC. The Roll wait time is a time which is processed on a client whereas the user context is in the roll area. Therefore, neither resources are used up nor does the bottleneck occur here for high Roll wait time. High Roll

http://service.sap.com/bpm


© 2005 SAP AG

121

121

wait times occur frequently. This may be caused by calls of Windows or other external applications from within the R/3 System. Here, the application of the RFC is started. The user context enters the roll areas and roll wait time is processed until the application is exited, that is the RFC connection is cancelled. Only at this point the transaction step is exited. They also occur when the R/3 System communicates with the frontend controls. While the data on the frontend are being processed, the R/3 context is rolled out, thus releasing the work process. This can occur several times during a transaction step. If frontend Office applications such as Microsoft Word are started and closed only after a long time (several minutes), a very long Roll wait time occurs here also. Roll wait is not part of the response time for transaction steps of task type RFC. The reason for this is that no resource use occurs for the application server.

8.5.2Procedure The following table gives you an overview of which transaction you can use for what purpose for performance monitoring and a first analysis of performance problems.

Transaction Trans. Code Use for … Use when?

Workload monitor ST03

General performance overview for the different task types and analysis of system workload

Daily (e.g. 3 times) and upon performance problems

Workload / statistical records

STAD Detailed performance monitoring of a short time frame, a single user or a specific transaction or program

Upon performance problems

Performance trace ST05

SQL trace of a specific step, short sequence of steps or part of a long running job

Upon performance problems with high DB times

ABAP runtime analysis

SE30

Getting an overview of the duration and performance of the source code, from individual statements up to complete transactions

Upon performance problems with high CPU times

8.5.2.1 Key performance indicators Performance monitoring is most useful if you have previously defined key performance indicators. Generally speaking Key Performance Indicators are quantifiable measurements, agreed to beforehand, that reflect the critical success factors of an organization. In this case we refer to the system response time for single dialog steps of your core business process(es), for transactions or background jobs. The key performance indicators should be agreed on by the business departments and the systems administrators (happy medium between was is needed for business reasons and what is achievable from system side). It is also important to use the right granularity for KPIs. There is no need to define a KPI for the response time of each and every step in the process, but it important that they are not defined in a too general way (e.g. less than 2 sec for each dialog step) as this might be too tight or too wide for specific needs. Furthermore performance monitoring should not only refer generally to a task type, but should rather go one or to steps further to single transactions or even steps. For example: Company ABC is using the call center scenario for inbound calling and also using the marketing scenario to create target groups via infoset or BW queries. As the call center agents need very good response times for business partner searches in order to answer a call and the queries for large target groups may take several seconds, it is not recommended that company ABC just monitors the average response time for dialog transactions. They should rather do the monitoring on transaction or even on dialog step level.

Daily monitoring of system performance and the compliance of the response times to the established KPIs should be done using the workload monitor (transaction ST03). This monitor provides an overview of the response times and it’s components (CPU time, DB time, Wait time, etc). In case of performance problems you should use this and other transactions for a deeper analysis:

• If a single user reports problems use transaction STAD to find what part of the response time is particularly high in his case. Compare it with other users to see if it is an isolated problem. Continue the analysis depending on the result.

• If a single dialog step (one step within a transaction) has a bad performance, use transaction STAD to find what part of the response time is particularly high in this case. Continue the analysis depending on the result.


© 2005 SAP AG

122

122

• If you have a general performance problem, use the system monitors to check resource consumptions. Use also the time profile of transaction ST03 to check if performance has been decreasing over time or if there are peaks. Use the user profile for a comparison among different users and user groups, if you follow a useful naming convention.

• Get a performance trace (transaction ST05) if you find that the performance problems are related to high DB times. Get an ABAP runtime analysis (transaction SE30) if you find that the performance is related to high CPU or high processing times.

• In case you can not find the cause of the performance problem or need further assistance for the analysis contact the next support level or open an OSS message on component XXSER TCC.

8.5.3Transaction ST03 Transaction ST03 is a very powerful transaction with lots of functionalities. Therefore we can mention here only a few, concentrating on what can be important for performance monitoring. The workload monitor is used to analyze statistical data from the SAP kernel. When analyzing the performance of a system, you should normally start by analyzing the workload overview. For example, you can display the totals for all instances and then compare the performances of individual instances over specific periods of time. You can quickly determine the source of possible performance problems using the large number of analysis views and the determined data.

You can use the workload monitor to display the: • Number of configured instances for each SAP R/3 System • Number of users working on the different instances • Distribution of response times • Distribution of workload by transaction steps, transactions, packages, subapplications, and

applications • Transactions with the highest response time and database time • Memory usage for each transaction or each user per dialog step • Workload through RFC, listed by transactions, function modules and destinations • Number and volume of spool requests • Statistics about response time distribution, with or without the GUI time • Workload and transactions used listed by users, payroll number, and client • Workload generated by requests from external systems

For all of this data you can display the data for a particular instance (not only the one to which you are logged on) or optionally totaled for all instances. Depending on your user mode, you can choose the time period for which you want to display the data between day, week and month (or determine the length of time yourself using the Last Minutes’ Load function). For most analysis views, you can display all or only certain task types.

The workload monitor has an interface that is divided into two parts. Use the tree structures on the left of the screen to make the following settings:

• Select the user mode • Select the time period for which you want to display the workload • Select various functions and analysis views (which data you want to display).

The system then displays the result on the right of the screen in a standardized ALV Grid Control.

For general performance monitoring you can use the following options: • User mode à choose expert mode • Workload à choose the instance and time frame you are interested in. Selection between the

last days, the last weeks and the last months is possible. If you are interested in a particular time within the last 24 hours, choose Detailed Analysis, than Last Minute’s Load and than the needed time frame on the appropriate instance.

• In the first workload overview you get, you find the response times and its components for the different task types (Background, Dialog, HTTP, RFC, Update, etc). You can now go to Analysis Views à Transaction Profiles à Standard. Here you can get a more detailed view, selecting for instance the task type dialog and the aggregation per transaction.


© 2005 SAP AG

123

123

The following screen shot shows transaction ST03 using the options: Expert mode, workload for server us0306_Q4C_02, time frame from 03.01.2005 – 09.01.2005, standard transaction profile, showing dialog transactions sorted by average response time.

8.5.4Transaction STAD In the STAD records every step on CRM Application Server is recorded. The records for all instances of a CRM system are displayed. The Business Transactions Analysis (transaction STAD) calculates the system resource usage of individual transactions for SAP R/3 Systems and provides a detailed analysis of a transaction and the dialog steps. The selection criteria include user, transaction, program, task type, start date, and start time. The analyzed time period can be larger than the interval defined by Read Time, as the system analyzes complete transactions as far as possible. However, it is not always possible to perform a complete analysis for longrunning transactions. As the business transaction analysis is time consuming, you should use as short an interval as possible (around 10 minutes).

The aim of this monitor is to analyze in detail how long the response times for particular steps in a process (or transaction) and are these response times distributed among their components (DB time, CPU time, Wait time, GUI time, etc) have been.

If you want to use this transaction to analyze the performance of the steps done by a particular user proceed as follows:

• Tell him to execute the interesting steps once, slowly one after the other and write down the exact time at which he executed them.

• Go to STAD and display the statistical records related to this single execution (use the user name and the appropriate time frame to display the correct records).

• Format the output list (button “Sel. Fields”), including the fields ‘GUI time’, ‘CUA reference program’ and ‘CUA internal command’. The two latter fields can help you to identify the single steps executed.

• Use the time stamps of the statistical records and the execution times you wrote down to assign STAD records to the dialog steps that were performed.


© 2005 SAP AG

124

124

• Check which steps are actually having a bad response time and what part is contributing most to it (DB, CPU, GUI, …).

• Depending on the result proceed with a deeper analysis of the worst steps using e.g. transaction ST05 (for long DB times), transaction SE30 (for long CPU times) or a network analysis (not described in this document) in case of high GUI times.

• Depending on what you are analyzing, it might be wise to let the user execute all steps twice and use the second execution for the analysis. This way you make sure that all buffers (e.g. program buffers) are filled.

You can also use this transaction to see in detail what was going on in the system during specific hours with bad performance. With this analysis you can see if there where a few users having particularly high response times or if there was a general performance problem. Procedure: Go to transaction ST03 and search for the hour with the worst performance or the highest workload using the time profile Call transaction STAD with the following selection criteria:

• Show all statistic records, sorted by start time à Checked • Start date à Today’s date • Read time à 1 hour • Start time à start time of high workload (from ST03) • User à * • Resp. time à >= 5000 ms • Task type à D (dialog) or B (batch) or R (RFC) or * (all)

Please be aware that this query may take several minutes.

The following screen shots show the initial screen of STAD with the options: Show all statistic records, sorted by start time, reading of the records for 10 minutes starting from 16:50 hours, for all users (*) that executed dialog transactions lasting longer than 1000 ms.

Following there are two screen shots showing the result of this query. For each time stamp you see what program was executed within which transaction on which server. For each the user, response time, time in work process, CPU time, DB time, GUI time, CUA ref. Program and CUA internal


© 2005 SAP AG

125

125

command are displayed. These columns are not all part of the first standard output. They where adjusted using the “Select output fields” button (F9).

To make the following steps easier, you may want to download the list with spreadsheet format. Make sure you have displayed all columns you need before getting the download. Please be also aware that the STAD records are only kept in the system for a limited period (normally 24 or 48 hours). Go through the list of long lasting dialog steps and search for those dialog steps that are lasting long on average (those appearing several times). You may identify which steps belong together by comparing the transaction, the program, the CUA reference program and the CUA internal command. Use the table below to identify to which transaction the dialog steps belong. If you can’t find a CUA ref program or a CUA internal command in this list or if you are not sure on the assignment, please proceed as described below. Please beware that the table beneath only shows typical CUA internal commands for some common steps. However these commands can be different in your system depending on customizing settings, user exits, particular system usage, and so on.

• Execute the typical steps of your core business processes once. Execute the steps slowly one after the other and write down the exact time at which you executed them. The steps should be performed by a key user.

• Go to STAD and display the statistical records related to this single execution (use the user name and the appropriate time frame to display the correct records).

• Format the output list (button “Sel. Fields”), including the fields ‘GUI time’, ‘CUA reference program’ and ‘CUA internal command’.


© 2005 SAP AG

126

126

• Use the time stamps of the statistical records and the execution times you wrote down to assign the “CUA internal commands” or the “CUA reference program” to the dialog steps that were performed.

• Use this information to identify which dialog steps are having extremely high response times during you peak load time.

Use this information to analyse in detail what is harming the performance of the corresponding transaction or dialog step. Use also the information on the distribution of the response time (DB time, CPU time, GUI time) given in the list, to identify the cause of the problem. Depending on the result proceed with a deeper analysis of the worst steps using e.g. transaction ST05 (for long DB times), transaction SE30 (for long CPU times) or a network analysis (not described in this document) in case of high GUI times. Additionally search for those taking particularly long (e.g.more than 10 seconds). Contact the responsible user to find out what he was doing at that time, if the did some unusual steps or if he noticed a bad response time. If you cannot identify the cause, you may use the procedure described for transaction ST05 for a deeper analysis.

The following table contains a list of function codes (CUA internal commands) of the most common steps grouped by CRM scenarios. Scenario Step CUA ref. Program CUA internal command

Call cic0 SAPLSMTR_NAVIGATION CIC0 Search for BP in CIC0 SAPLCIC0 CSEARCH_SEARCH Select CP from PopUp in CIC0

SAPLCRM_CIC_BP_SUB &IC1

Confirm BP in CIC0 SAPLCIC0 CSEARCH_CONTINUE Display interaction history SAPLCIC0 BUS_LOCATOR_SRCH_

GO Create one order document (choose) in CIC0

SAPLCIC0 1OMAIN_CREATE

Save one order document in CIC0

SAPMSSY0

Change tab in CIC0 SAPLCIC0 AA_TAB* End contact in CIC0 SAPLCIC0 ECNT

Interaction Center

Hitting the return key (“Enter”)

RFSH

Create inquiry Create quotation SAPLCRM_1O_MANAG_UI NEWT_POP

1OMAIN_CREATE Create sales order SAPLCRM_1O_MANAG_UI NEWT_POP

1OMAIN_CREATE Save sales order to CDB SALESDOCGEN_O_W_CDB

Field Sales

Replicate to mobile clients

CGCAPGEN_OBJ_WRITE_R RR

Start MKTPlanner (CRM_MKTPL)

SAPMSSY0 empty

Create Campaign SAPLCRM_MKTPL %_GC 123 1 Save Campaign SAPLCRM_MKTPL Save Switch to Product Tab SAPLCRM_MKTPL TAB_PRODUCT Add Product on Product Tab

SAPLCRM_MKTPL CGPL_DUMMY

Switch to Segment Tab SAPLCRM_MKTPL TAB_MKTING_SEGM

Marketing – MKTPL

Add Target Group SAPLCRM_MKTPL CGPL_DUMMY Start Segment Builder SAPMSSY0 empty Open Attribute List empty empty

Marketing – SEGBUIL

Add Attribute to empty empty


© 2005 SAP AG

127

127

Segmentation Area Count Profile CRM_MKTTG_SEG_UI_STA %_GC 161 1 Save Profile CRM_MKTTG_SEG_UI_STA SEG_SAVE Create quotation SAPLCRM_1O_MANAG_UI NEWT_POP

1OMAIN_CREATE Create sales order SAPLCRM_1O_MANAG_UI 1OMAIN_CREATE

NEWT_POP Create service order SAPLCRM_1O_MANAG_UI 1OMAIN_CREATE

NEWT_POP Product Proposal (click on the product tab)

SAPLCRM_1O_MANAG_UI T\SALS_HD04

CRM Online

Determine price (click on the price tab)

SAPLCRM_1O_MANAG_UI T\SALS_HD05

Login to web shop SAPLCRM_ISALES_SHOP CRM_ISA_SHOP_GETLI ST

SAPLCRM_ISALES_SOLDT O

CRM_ISA_CONTACT_G ET_SOLDTOS CRM_ISA_BP_BPARTN ER_GETDETAIL

SAPLCRM_ISALES_ORDER CRM_ISA_STATUS_PR OFILE_ANALYSE

Select a shop

CRM_ISA_BP_BPARTN ER_GETDETAIL

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CR EATE

SAPLCRM_ISALES_SOLDT O

CRM_ISA_SOLDTO_AD D_TO_BASKET

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CH ANGEHEAD

SAPLCRM_ISALES_SHIPTO CRM_ISA_SHIPTOS_OF _SOLDTO_GET

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE TITEMS

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE T_MESSAGES

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE TTEXT

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE TSHIPCOND

Create shopping basket/order

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE THEAD

SAPLCRM_ISALES_1TO1 CRM_ISA_SHOP_RECO MMENDAT_GET

Button catalogue

SAPLCRM_ISALES_1TO1 SAPLCRM_ISALES_1TO 1



SAPLCRM_BATCH_IL CRM_ISA_STATUS_PR OFILE_ANALYSE

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE TTEXT

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE TSHIPCOND

E Selling

Add to shopping basket

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_GE TIPCINFO


© 2005 SAP AG

128

128

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_OR DER

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CH ANGEITEMS



Create/send sales order


Select related products SAPLCRM_ISALES_1TO1 CRM_ISA_BASKET_CU A_PRODS_GET


SAPLCRM_ISALES_ORDER SAPLCRM_ISALES_OR DER

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_CR EATE


Create order from order templates



SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_DEL ETEITEM

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_DEL ETEITEM


Delete product from order template

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_AD DITEMTEXTS

SAPLCRM_ISALES_ORDER CRM_ISA_BASKET_OR DER




Order from order template


For details on the Performance monitoring on Function Code level and the monitoring setup procedures use the following link http://service.sap.com/~sapidb/011000358700003081072005E and navigate to section 2.1.

8.5.5Transaction 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.

http://service.sap.com/~sapidb/011000358700003081072005E


© 2005 SAP AG

129

129

To use the performance trace, you need the authorization to start transaction ST05 and the system authorizations "Change trace switches" (authorization STOM for authorization object S_ADMI_FCD) and "Analyze traces" (authorization STOR, also for authorization object S_ADMI_FCD).

The performance trace contains the following tracing options: • SQL Trace: This allows you to monitor the database access of reports and transactions. • Enqueue Trace: This allows you to monitor the locking system. • RFC Trace: This provides information about Remote Function Calls (RFCs) between

instances.

The aim of the procedure described below is to find the SQL statements that are causing high response times in the CRM system. If you identified a transaction or a process step that is taking to long, you may use transaction ST05, to find out if one or more SQL statements are causing the performance problem. Procedure: Call transaction ST05 and make sure you are on the same instance as the user you want to trace:

• Check the option SQL trace (also Enqueue and RFC trace if needed) • Activate the trace with filter • Enter the user name of the user that will perform the steps • Confirm • Ask the user to perform the relevant steps (and nothing else) • Deactivate the trace • Display the trace. Make sure the user name is correct. Write down the displayed time stamps

(trace period) to be able to find the same trace in the system later on. Use the extended trace list to display the time stamps for each SQL statement.

• Depending on what you are analyzing, it might be wise to let the user execute all steps twice and use the second execution for the analysis. This way you make sure that all buffers (e.g. program buffers) are filled.

Go trough the trace and search for the statements having a high duration (marked red). Use the ‘explain’ functionality to see if the correct index is being used for that statement.

In case you can not find the cause of the performance problem or need further assistance for the analysis contact the next support level or open an OSS message on component XXSERTCC. Attach the trace, a detailed description of the performed steps and the related STAD records to the message.

8.5.6Transaction SE30 The runtime analysis tool allows you to examine the performance of any ABAP programs, such as reports, subroutines, function modules or classes. It saves its results in performance data files, which you can display as lists. You can use these results to identify runtimeintensive statements, to combine table accesses, and show the hierarchy of program calls. From the results of the runtime analysis, you can identify:

• Excessive or unnecessary use of modularization units • CPUintensive program functions • Userspecific functions that could be replaced with ABAP statements • Inefficient or redundant database access.

Depending on the size of the program, considerable volumes of data can be generated during the runtime analysis. For this reason, this tool is defaulted to Full aggregation. This means that only the standard hit list is generated with all calls. The standard hit list does not include Group hit list, Hit list of database tables, Class hit list, Instance hit list, Method hit list, Event hit list, Hit list of internal tables, Call hierarchy and Statistics. To cancel this restriction, switch off aggregation by replacing the standard variant in the initial screen with a temporary variant, for example. In this variant, you can then configure the measurement restrictions according to the selected objects to be measured.

The runtime analysis consists of two parts:


© 2005 SAP AG

130

130

• Recording performance data • Analyzing the performance data

In the first part, the system measures the transaction, program, or procedure, and writes the result to a performance data file. You can restrict the measurement to certain objects. You can also measure up to ten external processes. In the second part, the performance data is analyzed, and the system displays the results in list form. For more information on this transaction and its usage please see the application help.

The runtime analysis tool measures the CPU time required by the measurable components of a transaction, a program, or a procedure. The information is stored in a performance data file, which you can analyze either immediately or at a later date. The CPU time required to measure the runtime is subtracted from the total CPU usage. If you measure the runtime of a program more than once, you are unlikely to get the same result on each occasion. There are various reasons why it is very difficult to obtain identical runtimes. For example, in the first measurement, the system might read data records from the table buffer on the application server, but in a second run, it may have to read them directly from the database. Runtimes also depend on the overall system or network load (for example, the number of jobs or systems currently active in your SAP System).

In case you can not find the cause of the performance problem or need further assistance for the analysis contact the next support level or open an OSS message on component XXSERTCC. Attach the runtime analyses, a detailed description of the performed steps and the related STAD records to the message.

8.6Batch Jobs Certain jobs must run periodically in a production CRM Server System for example, deleting obsolete jobs or spool objects. If these periodic jobs do not run, system performance may get worse over time. Unfortunately, there is currently no easytouse support for such jobs in Basis Customizing. Therefore, the jobs must be scheduled manually. For more information, see SAP Note 16083. Note that a daily monitoring of the job log using transaction SM37 is recommended.

8.6.1.1 General periodic jobs Please schedule the following general periodic jobs as described.

• RSBTCDEL Report RSBTCDEL deletes entries from tables BTC*, and performs a cleanup of files in directory /usr/sap/<SAPSID>/SYS/global/<client>JOBLG. Tables BTC* contain background job administration data. It is recommended to define a variant for report RSBTCDEL. A daily job called SAP_REORG_JOBS with report RSBTCDEL as a job step should be scheduled.

• RSPO0041or RSPO1041 Report RSPO0041 deletes entries from spool tables TSP*, and performs a cleanup of files in directory /usr/sap/<SID>/<Instance>/data. Tables TSP* contain spool job administration data and spool data. Define a variant for report RSPO0041. Schedule a daily job called SAP_REORG_SPOOL containing report RSPO0041 as a job step. Alternatively, you can use report RSPO1041 instead of report RSPO0041. For detailed information, see SAP Note 130978.

• RSPO1043 Report RSPO1043 resets write locks and deletes inconsistent objects in spool tables TSP*. Tables TSP* contain spool job administration data and spool data. Schedule report RSPO1043 on a regular basis. See SAP Note 98065 for details.

• RSBDCREO Report RSBDCREO deletes entries from BDC* and APQ* tables, and performs a cleanup of files in directory /usr/sap/<SID>/SYS/global. The tables contain Batch Input administration data. It is recommended to define a variant for report RSBDCREO.


© 2005 SAP AG

131

131

Thus please schedule a daily job called SAP_REORG_BATCHINPUT containing report RSBDCREO as a job step. Note: For SAP Basis Release 4.0, you must apply SAP Note 100915 BEFORE you schedule this report.

• RSBPSTDE Report RSBPSTDE deletes entries from tables BTCJSTAT, and deletes statistics for background job runtimes. Table BTCJSTAT contains background job runtime statistics data. Create a variant for report RSBPSTDE. Schedule a monthly job called SAP_REORG_JOBSTATISTIC, which contains report RSBPSTDE as a job step.

• RSCOLL00 Report RSCOLL00 collects various statistical data for performance monitoring of CRM Server, the database, and the operating system. If this job is not run, no performance data is available, and system monitoring is impossible. Schedule an hourly job called SAP_COLLECTOR_FOR_PERFMONITOR. Use RSCOLL00 as a job step. You should also maintain table TCOLL according to SAP Note 12103.

8.6.1.2 CRM specific periodic jobs Please also schedule the following CRM specific periodic jobs as described:

• Preparations for update statistics Report SMO6_MAINT_STATISTIC should always be scheduled one day before the update statistics run. Scheduling this report before the update statistics run is necessary to optimize database accesses.

• Automatic start of the QueueDemon The queue demon needs to be started after each system startup. Schedule report SMO_QUEUEDEMON after system startup. If you schedule report SMO_QUEUEDEMON as a background job, you do not need to start the queue demon manually. See SAP note 332002 for details.

• Refresh of generation status information Report GN_GENERATE_CHECK updates generation status information. If this report is not scheduled daily, the generation status information displayed in the CRM middleware monitoring cockpit (transaction SMWP) is not up to date. Before the start of production, it is recommended to schedule report GN_GENERATE_CHECK with period #daily# . Thus please call transaction SMWP. Select Background Jobs. Rightclick on "Check Generation Status of Objects" and select "Show suggested action". Press button action.

• Collector for Monitoring Cockpit The Collector for Monitoring Cockpit updates CRM middleware monitoring cockpit information. If this report is not scheduled periodically, information displayed in the CRM middleware monitoring cockpit (transaction SMWP) is not up to date. It is recommended to schedule job "Collector for Monitoring Cockpit". Thus please call transaction SMWP. Select Background Jobs. Rightclick on "Collector for Monitoring Cockpit" and select "Show suggested action". Press button Action.

• Reorganization Job for Middleware Tables Report SMO6_REORG for reorganization of the trace tables is not scheduled as a job or stops with an error. It is recommended to schedule the job to run on a daily basis in every productive client. Please see SAP Note 206439 for details. If errors occur, check SAP Note 214474.

• Mobile Message Recovery Cleanup Report Report QBLOCKDELETION for the deletion of extracted/unprocessed messages is not scheduled daily. This report cleans up tables QBL_EXTN, CCO_INFHDR, CCO_INFDTL. Please call transaction CMWQ_DEL and create a daily background job with variant 'Delete all extracted messages for available sites'.


© 2005 SAP AG

132

132

• Reorganization of BDoc message related object links The ABAP Program RSRLDREL for reorganization of BDoc message related object links should be scheduled as a job. It is recommended to create one daily background job that contains two variants of program RSRLDREL as two job steps. The first variant should cover the period from the current date until (current date X days) and use the option "One object not available". The second step should cover the period from the GoLive date of your hardware up until X days before the current date and use the option "Without existence check". The value of "X" depends on your business requirements: if a business process is successfully completed, object link entries are no longer required. In our experience a value of X = 7 is usually sufficient. However, at the beginning of your CRM project a value of X = 28 is recommended, because in early project stages errors are more likely and the object link entries in SRRELROLES/SMW0REL are needed for error analysis. Further details on how to set up variants for RSRLDREL are in SAP Note 493156. If you require assistance in setting up this background job, please open a customer message on component XX SERTCCCRM.

• Job HRBCI_ATTRIBUTES_BUFFER_UPDATE Report HRBCI_ATTRIBUTES_BUFFER_UPDATE should be scheduled. This report buffers the organizational data that can provide big performance improvements for nearly all CRM scenarios. It is recommended to execute report HRBCI_ATTRIBUTES_BUFFER_UPDATE on a daily basis. It is necessary to set up the buffering indicator via the transaction OOATTRCUST for the scenario CRM. Call transaction OOATTRCUST and tick field buffering for the fields Sales and/or Service, depending on the CRM scenarios you use. Afterwards schedule a periodic daily running batch job with the report HRBCI_ATTRIBUTES_BUFFER_UPDATE and the variant SAP&CRM. If your time window is too short to run after midnight, the job can be executed the day before between 20:00H 00:00H. The job automatically buffers the attributes for the following day if executed during this time frame. As a consequence one background job will be scheduled at this time. The run time depends on the size of the organizational plan. This is required because entries in the cluster tables are only valid for one day. Therefore, the cluster table has to be created on a daily basis by report HRBCI_ATTRIBUTES_BUFFER_UPDATE. Otherwise performance improvements by this technique are not possible. See SAP Note 110909 for details.


Monitor TA/Tool

Monitor Freq.

Threshold Indicator or Error Monitoring Activity or Error Handling Procedure

Respon sibility

Background jobs

SolMan Daily To be set Start and enddelay, Out of time window, Maximum Duration, Cancellation, Parallel processing of jobs, Job log messages

Check for the cause


8.6.1.3 Error Handling Procedures for Batch Jobs In case of failure of one of the scheduled jobs, if one of the necessary jobs is not scheduled, or even if a scheduled job has finished, check for the current job status (refer to SAP R/3 documentation CD, component BCCCM, chapter background processing) and proceed as follows:

• In case of status scheduled, the job steps have already been defined, but the start condition has not yet been defined. Contact the program scheduling management in order to clarify when the job will be fully defined.

• In case of status released, the job has been fully defined including a start condition and waits for the condition to fulfill.

• In case of status ready, the start condition of a released job has been met. A job scheduler has put the job in line to wait for an available background work process.

• In case of status active, the job is currently running and cannot be modified or deleted anymore. Check if the job is within the given timeframe, depending on the data volume to


© 2005 SAP AG

133

133

be processed. Check for particular dependencies on other jobs. If the job exceeded the given timeframe, contact the software monitoring team.

• In case of status finished, all steps that make up this job have completed successfully. Program scheduling management has to check whether the job ran in the given timeframe, and software monitoring team and/ or application support have to check the respective job results (such as spool output lists, message logs, updates, etc.).

• In case of status cancelled, the job has terminated abnormally, which can happen in two ways. If an administrator intentionally cancelled the job, clarify why he did so and whether (and if, when) the job has to be rerun. If a program in a job step produced an error such as issuing an ‘E’ or ‘A’ error message, contact the software monitoring team and investigate why the error occurred. In case of an SAP standard program search for appropriate messages in SAPNet and open a customer message, if you cannot solve the problem.

8.6.1.4 Job Restartability In case of the cancellation of a background job possible succeeding jobs or dependencies on other jobs must be considered when restarting the aborted job. The start of succeeding jobs might be also delayed due to the restart of the aborted job.

8.6.1.5 Escalation Procedures If it is not possible for any of your support levels to provide a solution for a particular problem, it is recommended to open a customer problem message in the SAPNet R/3 frontend system.

8.7Mass data changes The purpose of the Mass Data Update process is to get mass data changes into CRM and to external sites (subscribed to that data) as well as to CDB and mobile clients. It is also the goal to pass mass data change originated in CRM online to connected sites. The focus of this chapter is on mass data changes that run during the production. Initial download topics will not be covered here. For all initial download issues, please refer to the “Setup and Download Guide”. (https://websmp203.sap ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700003462572001E)

Especially customers running the Field Sales scenario (Mobile Sales/Service) have to be careful with mass data changes, as e.g. 1000 condition changes in R/3 may generate a heavy load on the CRM system in case these all have to be replicated to the mobile clients.

The application components covered for mass data change here are: • Conditions • Business Partner • Product/Materials • Sales orders

The following table summarizes the sources of mass data changes that are distributed into the CRM system and the possible interfaces that can be used. Furthermore special monitoring activities are named. For more detailed information on the different topics, please refer to the single subchapters below.

Started in R/3 by transaction: Monitoring Conditions e.g. VK11 or VK12 SAPMV75A Business Partner

XD99 transactions return error messages in case of problems

Products / Materials

MM17 transactions return error messages in case of problems

https://websmp203.sap-ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700003462572001E


© 2005 SAP AG

134

134

Sales orders VA05, VA15, VA25, VA35, VA45, VA 55

transactions return error messages in case of problems

Procedure In mass maintenance, you must decide which tables of an object type are to be changed. It is possible to make changes in several tables at the same time. If several tables are selected, only objects that meet the selection criteria in every table will be chosen. Several tables should only be selected if it is necessary – for reasons of consistency – to make the changes simultaneously. If this is not required, it is – for reasons of performance recommended to process the tables sequentially. Please note that many objects can be changed simultaneously in mass maintenance. When you save your changes, the system checks them for consistency. They then take immediate effect for all objects chosen. Mass data processing requires special handling in replication and special handling in adapters. For details about the process, please refer to the following documents: Doc Processing in CRM 30 (https://websmp101.sap ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700006510122001E ) (for Initial Load, Mass Data Change, Single Delta Process, Direct Sending)

and Cookbook: Data Exchange (https://websmp101.sap ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700006149582001E ) Recommendations:

Coordinate the scheduling with the R/3 and CRM System administrators who may generate mass data changes.

For Mobile scenarios: Implement Note 453882 (Parallel processing of the R&R queues) that also includes handling and monitoring instructions. Do not set the number of processes too high, as this might be hindering system performance otherwise.

Check the filter settings in CRM (transactions: r3ac1, r3ac3, r3ac5) and check table VKORG (via se16) in R/3 before starting mass data changes in R/3. Always do a forecast on the amount of load that will be created in the CRM system, before starting the changes.

8.7.1.1.1 General Monitoring Activities Apart from safeguarding the general availability of the R/3 system and CRM server SAP recommends to monitor the objects listed in the following table. The monitoring activities strongly depend on the hardware used.

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Responsibility

Performance of CRM and backend

ST03, STAD Daily Long times (>1000 ms per line item)

Monitor RFC Statistics Application monitoring team

Bdocs smwp (folders: ‘Runtime information’ and ‘Bdoc messages in the flow’)



Queues smq1 smq2 smwp smohqueue

Daily, smohque ue hourly

Queues are stopped or on hold

In case one or more of the queues get stuck (Error stop or CPIC errors) try to restart (activate) the queues manually. If starting the queues manually does not work, please check with transaction ST22 for possible





© 2005 SAP AG

135

135

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Indicator or Error


Responsibility

error causes.

Bdoc Outbound Queue (for Field Sales)

Smq1 (CRM) Daily old dates, big Queues

Investigate the cause, probably contact the responsible sales person


For Field Sales it is recommended to check when the last data transfer to the mobile clients occurred, i.e. when program Conntrans was executed the last time. For this reason you can use transaction smq1 on the CRM Server. Select all entries and select “Display Selection (F7)”. By default the queues are sorted by “1. Date”. This entry represents the oldest entry in the outbound queue waiting to be transferred, i.e. the first new entry after the last executed download. For queues not transferred for a long time (e.g. 2 month, but considering holidays and public holidays) you should contact the respective user. Please also check the amount of objects waiting for download on a regular basis. As the download for more than e.g. 10.000 Objects might take quite some time (maybe a few hours) check the subscriptions and the download frequency. Please note, that different objects might differ considerably in processing and download time. (Condition BDocs are usually downloaded quickly, whereas Sales Documents can take a few seconds). Please also check for running data extracts (via transaction smohqueue for the Replication & Realignment Queue), as deletion or adding of sites for mobile clients also produces high load on the queues.

Queue Performance Mass changes of data (creating, changing) on the R/3 system might lead to reduced system performance, as all dialog and background work processes become occupied.

Analysis: The outbound queue (SMQ1) of the R/3 system shows that there are between several hundred and several thousand different queues waiting to be processed. A large amount of the changed data from the R/3 system is intended for the delta download to the CRM Middleware Server and is therefore stored in the outbound queue of the backend before being transferred to the middleware server. For performance reasons qRFC tries to transfer as many queues as possible, as fast as possible. The result is that many parallel queues (with different queue names) are generated. The total number of queues that can be generated for parallel processing is limited by the possible names that can be assigned to the queues. Please see SAPNet note 356228 for the handling of parallel processing.

Error handling: Proposals for long running (never ending) mass maintenance:

Use more CPUs (e.g. from an application server) Increase the rereading time for the scheduling Deactivate some queues or queue blocks if the rest of the business is more important. See

above, note 356228

Please note that it is not possible to stop and restart mass data changes, because this may cause inconsistencies.

Additional helpful SAPNet notes: 576160 MM17: BAdI implementation for append fields 573718 MM17: Calling MLGN Convert BSME>LHME generically 566520 Long runtime mass maintenance MM17, XD99, XK99, MEMASSIN 498382 MM17: Problems with mass data change of AFS tables 557702 FAQ for mass maintenance (updated frequently)


© 2005 SAP AG

136

136

Monitoring XIF Interface For mass data changes performed in nonSAP Systems connected to a CRM Server, refer to the guide “The use of external interfaces” (https://websmp101.sap ag.de/~form/sapnet?_FRAME=CONTAINER&_OBJECT=011000358700000614852002E ).The use and monitoring of XIF interfaces (XML and IDOC) is described there. This document is valid for CRM 3.0, CRM 3.1 and CRM 4.0.

DIMA The purpose of the “Data Integrity Manager” is to help to detect and repair data inconsistencies between the CRM database and the CDB or the connected R/3. For additional information please check the guide “Checking CrossComponent Data Integrity”. This can be found in the SAP Service Marketplace (http://service.sap.com), alias CRMMW. There select CRM powered by Netweaver > Process Integration > CRM Integration Services > System Landscape Management.

Frequently asked mass maintenance questions: 1. Why does the mass maintenance select an incorrect number of data records? Prior to the actual selection, the mass maintenance first carries out a preselection via the leading table of the selection. The logic according to which the leading table is selected from several tables is described in note 325088. If a maximum number of data records, that should be selected and displayed without consultation and that has been defined in mass maintenance by the user, is exceeded in the preselection, the system displays on dialog box 'Processing mode' how many or, in case of a selection of several tables, up to how many records it selects. That is, in case of a selection of several tables the preselection only displays an upper limit. Only when you press pushbutton 'Display all records' or 'Change in background' on dialog box 'Processing mode', the combined selection is made across all selected tables. Consequently, the number of the selected data can deviate heavily from the upper limit displayed on the 'Processing mode' dialog box. The mass maintenance offers 2 processing modes (you can 'change existing data records' and/or 'create new data records'), which you can execute separately or together (!!!). If both processing modes are activated, all data records that meet the selection conditions for the change plus all data records that correspond to the selection conditions for the new creation are selected.

2. Why is the runtime of the selection across several tables in the mass maintenance very long? Why does the selection in the mass maintenance terminate with TIME OUT? Note 325088 describes the logic of the combined data selection across several tables in the change mode of the mass maintenance. You can solve the problem by choosing the selection condition in a suitable way.

3. Which notes reduce the runtime of the mass maintenance. 424635 Long runtime in the mass maintenance customer/vendor 485023 Long runtime with mass maintenance purchase requisition 544687 Mass maintenance: Long runtime of the data selection 566520 Long runtime mass maintenance MM17, XD99, XK99, MEMASSIN 739979 Termination due to memory overflow at start of a

4. Why does the selection terminate with ABAP runtime error 'SAPSQL_WHERE_CANT_SCAN'? Note 330416 describes the cause and solution of the problem.

5. Why does the mass maintenance terminate with ABAP runtime error 'TABLEVIEW_DUP_COLUMN_INDEX'? 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.





© 2005 SAP AG

137

137

7. How do I create new data records? Note 351283 describes the selection logic for the creation of new data records in the mass maintenance. Notes 331364 and 339444 additionally describe the effect of foreign key dependencies of the selection fields on the selection of the new records to be created in mass maintenance.


© 2005 SAP AG

138

138

9 Further Information 9.1.1.1.1 Troubleshooting If executing this Best Practice did not produce the desired results,

• Search for related notes in the SAPNet. • Open an SAP Customer Message describing your problem (please see the respective

component in section Error Handling, Restartability and Escalation of every step).

9.1.1.1.2 Literature • For detailed information on how to administer an SAP R/3 system, see the book:

Liane Will, SAP R/3 System Administration, 1999

• For information on how to monitor and tune the general system performance, see the book: Thomas Schneider, SAP R/3 Performance Optimization, 1999.

9.1.1.1.3 Feedback and Questions Send any feedback by formulating an SAP customer message to component SVGSTSMC. You can do this at http://service.sap.com/message.

http://service.sap.com/message


© 2005 SAP AG

139

139

10 Appendix

10.1 General Monitoring Guidelines for the SAP CRM System and the SAP R/3 System

For the administration of an SAP R/3 system as well as for the R/3 basis of an SAP CRM system, there are a number of monitoring activities we strongly recommend scheduling and supervising on a regular basis. The following list is not complete, especially jobs and tasks for the database administration (such as backups, archiving transaction logs, update statistics for cost base optimizer and so on) are not mentioned, however it gives you an impression of what you have to do in order to keep a system running. As part of the SAP Basis these monitors do not display any CRM specific monitoring data. They should be analyzed using the same procedures as those used in a nonCRM system environment. If you have further questions on these subjects, please refer to the Solution Management Optimization Service System Administration.

Basis Monitoring: General System Checks Monitoring Object

Monitor TA/Tool

Monitor Freq.

Monitor Time

Indicator or Error


Responsibility

R/3 System workload analysis

ST03 daily tbd Average dialog response time < 1000 ms

Review response times in comparison to system load and performance influencing changes within the system of the analyzed period. Identify and improve performance of any transaction whose response time exceed the times defined in the Service Level Agreement (SLA), if existing. Monitor RFC response time statistics and Dialog response times for online transactions.


Database perform ance Analysis

ST04 Weekly and in case of perform ance problem s

tbd Expensive SQL statements

Monitor database statistics. Monitor the buffer cache hit ratio Check for missing indices; ensure that the data quality is sufficient, and that there is sufficient space available.


Operating system monitor

ST06 Hourly (depend ing on the busines s process ) and in case of perform ance problem s

tbd High paging rate and CPU utilization

Monitor the CPU and memory consumption. A hardware bottleneck can have a negative impact on the overall response time as well as the response time of an individual business transaction. Especially monitor hardware load during high RFC transmission times.


R/3 System buffer monitor

ST02 Weekly and in case of perform ance problem

tbd Swaps Monitor memory resource usage for specific R/3 application servers To ensure optimal performance check that the R/3 parameters are set correctly with transaction



© 2005 SAP AG

140

140

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Monitor Time

Indicator or Error


Responsibility

s ST02. Incorrectly sized R/3 buffers or memory allocation can result in poor performance. One such example would be when a work process enter PRIV mode.

Local work process overview

SM50 hourly during peak hours and in case of perform ance problem s or error messag es

tbd WP status, WP utilization

Monitor current state of individual work processes. Ensure that enough work process capacity is available at peak times.


System wide work process overview

SM66 hourly during peak hours

tbd WP status, long running jobs

Similar to SM50 but for system wide statistics.


Database perform ance monitor

DB02 Daily and in case of perform ance problem s

tbd Table space sizes, table indices for tRFC and aRFC

Ensure that the data quality is sufficient, that there are no missing indexes, and that there is sufficient space available. In general if table sizes are larger than 500MB, reorganize the table and decrease its size. See SAP Note 375566. Monitor the growing of tables and indices, especially on tRFC and qRFCtables (ARFCSSTATE ARFCSDATA ARFCRSTATE)


ABAP dump analysis

ST22 daily and in case of an errors

tbd Dumps Check short dumps, analyze aborted programs. Select a period and click on the List button. Select an error, and then choose Display to see the short dump. For SAP developed programs that experience frequent terminations, investigate SAPNet for a possible resolution and if necessary open a customer message. For customer developed programs contact the appropriate member of the development team.


System log SM21 daily and in case of an errors

tbd Entries Check for general system program errors and table space errors or transactions that encounter errors. Maintain date/time and select Reread system log. Position cursor on a time, and then choose Display.



© 2005 SAP AG

141

141

Monitoring Object

Monitor TA/Tool

Monitor Freq.

Monitor Time

Indicator or Error


Responsibility

Update tasks

SM13 daily and in case of an errors

tbd Status Check for entries that have status ‘ERR’. Update records should be monitored regularly and the appropriate user should be contacted immediately to resolve any outstanding updates. Together with the user, determine whether the update request can be restarted or has to be deleted.


Display Statistical Record

Transac tion STAD

In case of bad perform ance

tbd Status Determine the performance of single statistical records


10.2 Middleware specific Monitoring Activities for the R/3 System

R/3 BackEnd System Monitoring Queue Monitoring Activities / Functions

Transaction Code Monitoring Frequency Periods and Events

Qrfc Outbound Queue Monitor: Monitor data exchange from the R/3 back end system to the CRM Server Queues should be relatively short and quickly processed Check, if the qRFC Version is up to date (see SAP Notes 166096, 366735 and 438015) To prevent data inconsistencies, you need to monitor the interfaces regularly for aborted or stopped data transfer

SMQ1 • Several times a day depending on the business process

• In case of an error message • During mass updates • Use Alert Monitoring

qRFC Inbound Queue Monitor Monitor communications from CRM System è R/3 System Messages “flow” through the inbound queue on the R/3 system and are immediately processed Normally SMQ2 should show an empty list

SMQ2 • Several times a day depending on the business process

• Upon error

Status of Queue Scheduler Monitor status of the QOUT Scheduler

SMQS • In case of a status error • Use Alert Monitoring

10.3 Middleware specific Monitoring Activities for the CRM System

The table below lists transactions used for monitoring the CRM Server:

CRM Server Central Monitoring Activities / Functions

Monitoring Type Monitoring Frequency Periods and Events


© 2005 SAP AG

142

142

Middleware Portal Monitoring the CRM Middleware Portal with transaction SMWP can be subdivided into the following areas: • 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

SMWP • Several times a day depending on the business process

• After implementing transports

QRFC Outbound Queue Monitor: Monitor data transfer between the R/3 back end and the CRM server and between the CRM server and mobile clients and other connected systems Queues destined for the R/3 backend and other stady connected systems should be relatively short and quickly processed, queues to destination NONE too Entries destined for the mobile clients and BW remain in the queue until each receiver fetches its data When the queue entries for a client reach 10,000, the queue should be closely monitored (e.g. issue warning). When the entries reach 100,000, severe problems may occur and performance will be affected. Administrative actions must be taken in these cases, any deletion of queues causes data inconsistencies If a queue that is “in use” between a mobile client and the CRM Server is deleted, it will cause data inconsistency between the CRM Server and the mobile client. In severe cases when a client cannot be manually rebuilt, it can be brought back into a consistent state by rebuilding the client data from the CDB (AC_EXTRACT)

SMQ1 Several times a day depending on the business process Daily

QOUT Scheduler Ensure that all destinations are registered. Only destination NONE must be excluded. See also SAP Note 400330

SMQS Daily In case of performance problems or error messages


© 2005 SAP AG

143

143

QRFC Inbound Queue Monitor: Monitor data transfer between the R/3 back end system and the CRM Server and between mobile clients and the CRM Server and all other queues, which have to be stored in the CRM Online DB Messages in the inbound queue are processed according to the capacity of the CRM Server. High number of entries in the inbound queue can indicate insufficient capacity on the CRM Server

SMQ2 Several times a day depending on the business process

QIN Scheduler Status This transaction runs the scheduler to check the inbound queues on the CRM Server Ensure that all inbound queues are registered (type R). Register them, if necessary, using the transaction SMQR If a queue is registered and has not been processed for a long time, the administrator has to check the reason for it. Possibly a scheduler problems may exist. Check the maximum processing time of the inbound queues. Set the maximum processing time of a queue ("Maxtime") to 60 seconds for all queues during normal operations

SMQR Daily In case of performance problems

TRFC Monitoring Monitor all transactional RFCs (tRFCs) processed on the CRM Server (e.g. workflow) SM58 is linked to the Replication and Realignment queues in error status in the EXTRACT and/or AC_EXTRACT queue (click on the error symbol)

SM58 Several times a day depending on the business process

Message Flow Statistics Collects statistical data about the workload on the CRM Server caused by BDocs messages Use this as a starting point for analyzing performance problems The message flow is a central function in the CRM Server and uses BDocs Display statistics of the message flow within the CRM Server Ensure that the middleware message flow statistics are switched on

SMWMFLOW Only for power users

Daily In case of an error message

BDOc Messages/Summary Application error analysis SMW01: Display the data of a BDoc message and possible errors SMW02: Display BDocs message summary in dependency on the site ID

SMW01/SMW02 Several times a day depending on the business process In case of an error message

Middleware Trace / Developer Trace It is used to to track program flows, record events and provide information for evaluation

SMWT In case of an error message

Summary of Unprocessed Bdoc Messages SMW03


© 2005 SAP AG

144

144

Check Flow Definitions Only after changes in the customizing Consistency Check for Flow Definitions

SMO8FD After BDoc type changes or changes in services or in the flow are made In case of an error message

CRM Server R/3 Adapter / Load Monitoring Activities / Functions

Monitoring Type Monitoring Frequency Periods and Events

Monitor Load Status Checks, whether the initial load was successfully completed 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

R3AM1 In case of an error messages during/after initial load Depending on the object status

Monitor Request Used in exceptional cases to bring the database into a consistent state after a data lost for instance in the CDB

R3AR3 In case of an error message, if the databases are not consistent and a request from the R/3 backend, the CRM or the CDB is necessary

BDoc Flow Statistics Activation Ensure that the middleware kernel application statistics are switched on. Call transaction SMWMFLOW. Execute Goto > Activate Statistics. Select “message flow statistics”. Activate monitoring of the middleware message flow. To activate the application statistics, select “Kernel application statistics”, select the change mode, mark the field “MW” (Middleware Message Hub Statistics”. Save. Communication Monitor Collector Activation For activating transaction SMWMCOMM, the Conntrans Performance monitoring, you have to choose “Environment”> “Run Collector


© 2005 SAP AG

145

145

© Copyright 2001 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft ® , WINDOWS ® , NT ® , EXCEL ® , Word ® , PowerPoint ® and SQL Server ® are registered trademarks of Microsoft Corporation. IBM ® , DB2 ® , OS/2 ® , DB2/6000 ® , Parallel Sysplex ® , MVS/ESA ® , RS/6000 ® , AIX ® , S/390 ® , AS/400 ® , OS/390 ® , and OS/400 ® are registered trademarks of IBM Corporation. ORACLE ® is a registered trademark of ORACLE Corporation. INFORMIX ® OnLine for SAP and Informix ® Dynamic Server

TM are registered trademarks of Informix Software

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