mysap CRM Monitoring

Best Practice: mysap CRM Monitoring mysap CRM Monitoring Best Practice for Solution Management Version Date: November 2002 The newest version of this Best Practice can always be obtained through the SAP Solution Manager Contents CRM 3.0 Applicability, Goals and Requirements 3 1.1 Goal of Using this Service 3 1.2 Staff and Skills Requirements 3 1.3 Example of a Business Scenario 3 2 Best Practice Procedure and Verification 6 2.1 Preliminary Tasks 6 2.1.1 Monitoring Concepts 6 2.2 Procedures 10 2.2.1 R/3 Back-End System Monitoring 10 2.2.2 CRM Server Monitoring 15 2.2.3 Field Sales Specific Monitoring 23 2.2.3.1 CRM Server 23 2.2.3.2 Communication Station 25 2.2.3.3 Mobile Client Monitoring 28 2.2.4 Interaction Center Specific Monitoring 29 2.2.4.1 CRM Server 29 2.3 Verification 31 2.3.1 Middleware Portal SMWP 32 2.3.2 Monitoring CRM Outbound Queues SMQ1 33 2.3.3 QOUT Scheduler SMQS 36 2.3.4 Monitoring CRM Inbound Queues SMQ2 37 2.3.5 Scheduler Status SMQR 39 2.3.6 TRFC Monitoring SM58 40 2.3.7 Monitoring the Middleware Message Flow Statistics SMWMFLOW 41 2.3.8 Check Flow Definitions SMO8FD 42 2.3.9 Middleware Trace 43 2.3.10 Monitor Request R3AR3 43 2.3.11 Monitor Initial Load R3AM1 43 2.3.12 Monitoring the Replication & Realignment Queues SMOHQUEUE 44 2.3.13 Queue Information for CRM Mobile Sites SMWMQUEUES 45 2.3.14 Communication Monitor SMWMCOMM 46 2.3.15 Message Recovery CMWQ 47 2.3.16 DCOM Connector Monitor 47 2.3.17 Communication Station Log File: TransferService.Log 48 2.3.18 Windows Performance Monitor 49 2.3.19 SAP Connect Monitor SCOT 50 2.3.20 SAP Phone Administration SPHB 51 2002 SAP AG 1

2.3.21 Internet Communication Manager Monitor SMICM 52 2.3.22 Gateway Monitor SMGW 53 2.3.23 R/3 Buffer Monitor ST02 53 2.3.24 Workload Monitor ST03N 53 2.3.25 Database Performance Analysis ST04 54 2.3.26 Operating System Monitor ST06 55 2.3.27 Local and System-Wide Work Process Overview SM50 / SM66 55 2.3.28 Display Statistical Records STAD 56 2.3.29 ABAP Dump Analysis ST22 56 2.3.30 System Log SM21 57 2.3.31 Update Error Monitor SM13 58 2.4 Troubleshooting 59 2.4.1 Problems during Data Exchange 59 2.4.1.1 Error Detection in Delta Download 59 2.4.1.2 Error Detection in Initial Download 65 2.4.1.3 Error Detection in Upload 68 2.4.2 Problems with E-Mail Sending (Outbound Direction) 71 2.4.3 CRM Server Performance problems or high I/O load due to excessive traces and logs being written 72 2.4.4 Mass changes of data (creating, changing) on the OLTP system leads to reduced system performance 74 2.4.5 Performance problems due to statistics updates on trfc/qrfc tables 74 2.4.6 System performance degrades as the size of the trfc/qrfc tables increases 74 2.4.7 Problem situation 1 75 2.4.8 Problem situation 2 75 2.4.9 Problem situation 3 75 2.4.10 Problem situation 4 75 2 77 Feedback and Questions 77 2002 SAP AG 2

Applicability, Goals and Requirements A Best Practice may not be applicable in some situations. To ensure that this Best Practice is the one that is needed in your situation, consider the following goals and requirements. 1.1 Goal of Using this Service The goal of this Best Practice is to document and to recommend procedures for: Identifying system conditions that can lead to business process standstill, loss of production or inefficient system operations Facilitating good system operations practices Troubleshooting system problems The general monitoring goals are: Detect documents in an error status Refer to reliable procedures for error handling Measure performance of data exchanges Monitoring objects and their attributes are usually displayed in the alert monitors. However, some interface points must be checked using generic tools and procedures. These are also described in this document. 1.2 Staff and Skills Requirements System administrators with experience for your installed my SAP CRM-Scenarios like e.g. mysap CRM Field Sales, mysap CRM Field Service solutions, mysap Interaction Center solutions and CRM Online. 1.3 Example of a Business Scenario The example below describes a business process typical for companies with a field force organization and covers the basic tasks in the daily work of a sales representative like e.g. entering new sales orders. The business process flow for Sales Order Processing in the Field Sales environment is depicted on the following page. Business Process Flow Description 1. Sales person creates an order for one of his customers. 2. Once a day the sales person connects to the CRM Server to upload his sales orders. 3. The sales orders are transferred to the CRM Server and passed through the validation process, which then decides to either update the Consolidated Database (CDB) or to forward rejections. In case of an update, all subscribed receivers are provided with the order. One of the receivers can be e.g. the R/3 back-end system. 4. If the R/3 back-end system is subscribed to these data, an SD sales order is created based on the information provided by the CRM Server. 5. During this process within the R/3 back-end system, the sales order is created or rejected, e.g. because of the exceeding the credit limit. 6. The R/3 back-end system sends confirmation or refusal information to the CRM Server. 2002 SAP AG 3

7. The CRM Server updates the CRM Online database and after replication to the CDB puts the information to update the mobile client s database into the client s outbound queue on the CRM Server. 8. The mobile client picks up its data from the CRM Server. SAP CRM Mobile SAP CRM SAP R/3 Create inquiry Create quotation Create inquiry Create sales order Create quotation Print sales order Mark for upload Perform upload (conntrans) Create sales order Save sales order to CDB Create sales order Perform download (conntrans) Replicate to mobile clients IPC IPC Configure product Configure product Determine price Determine price Technical Process Flow Overview The business process described above is technically represented by the message flow used for transferring data from the mobile client to the CRM Server and to the R/3 back-end system. The flow is based on the standard SAP business process steps of the Standard Sales Order Processing Scenario. This general description can be applied to most communications between the mobile clients and the R/3 back-end and/or CRM Servers. Sales orders are represented by the corresponding BDoc message type being transferred between the mobile client and the CRM Server. BDoc types can also transfer all types of data between the mobile client and the CRM Server (such as system information and administrative information) and then to all other receivers. Message Flow Within CRM In all CRM scenarios, message flow is used to supply all components of the CRM landscape with necessary information in accordance with subscription rules. The figure below shows message flow for CRM Field Sales scenario. 2002 SAP AG 4

Mobile Client R/3 Adapter XIF Adapter R/3 External interfaces (XML - SOAP, IDoc) Both XML/SOAP and IDocs can be generated from the ABAP complex data type used to define the external interface Sync BDoc Flow Mapping: Sync BDoc -> Msg BDoc Msg BDoc Flow CRM Adapter CRM Adapter CRM Server Application Routing (Simple Replication) XIF Adapter External interfaces (XML SOAP, IDoc) R/3 Adapter R/3 Mobile Bridge: Msg BDoc -> Sync BDoc Sync BDoc Flow CDB Service Replication/ Realignment Outbound Adapter Mobile Client CRM Middleware Adapters and Services The CRM Adapter is called by the message flow to pass inbound BDoc messages to the CRM Server application for validation. In case of a successful validation by the CRM Server applications, the content of the BDoc message is written (from the extension part) to the corresponding tables of the CRM database. If the validation was not successful, the BDoc message is sent back to the sender. The Replication and Realignment Service determines whether a replication and/or a realignment is necessary or not. If a realignment has to be performed for a BDoc message, this message is copied into a separate realignment queue for further processing. If realignment is not required, the receiving sites for a BDoc message are determined. The Mapping Service maps synchronization BDoc types to messaging BDoc types. The reverse direction is mapped using the Mobile Bridge. The Mobile Bridge takes a messaging BDoc type and creates one or more synchronization BDoc types (1:n relationship). It also takes one or more synchronization BDoc message and produces exactly one messaging BDoc message of one predefined type (n:1 relationship). The CDB Service saves the content of a synchronization BDoc message in the corresponding CDB tables. Note: Mobile Bridge and CDB Service are only active in Field Sales (=MSA) or Field Service (=MSE) Scenarios. (CDB = Consolidated Database on the CRM Server, MTS = Message Transfer Service. MTS client is on the Mobile Client, MTS server - on the Communication Station) 2002 SAP AG 5

2 Best Practice Procedure and Verification 2.1 Preliminary Tasks Before applying this Best Practice, ensure that you perform the following preliminary tasks or checks in the system: Complete all installation and post-installation actions and procedures including customizing. Ensure that the initial load 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. 2.1.1 Monitoring Concepts Monitoring in the mysap CRM can be divided into the following areas: Monitoring the end-to-end message flow in the CRM Server Monitoring transactional RFC requests Monitoring the queues located on the respective server systems Operating system performance monitoring Database system performance monitoring Error analysis Detected errors Actions Automatically generated E.g. message to system administrator Undetected errors Prevention by regular monitoring Standard R/3 tools Use of processing monitors Computing Center Management System Middleware Portal Display BDoc Messages Monitoring of queued RFC Middleware Trace RFC log files The following table briefly lists the Software Components and the monitoring functions associated with them: 2002 SAP AG 6

Server Types Mobile Client Communicatio n Station R/3 Back-End System CRM Server Monitoring Function 1. Monitor the outbound queue of the mobile client 2. Monitor the inbound queue of the mobile client 3. Monitor database 4. Monitor the operating system 5. Monitor network throughput 6. Message Recovery 1. Monitor message flow from all mobile clients to the CRM Server 2. Monitor network throughput 3. Monitor operating system 1. Monitor outbound queue 2. Monitor R/3 Basis System 3. Monitor database 4. Monitor operating system 5. Monitor network throughput 1. Start with the Middleware Portal. In case of an error go to the appropriate transactions. 2. Monitor outbound queue, data transfer from the CRM Server to mobile clients 3. Monitor inbound queue, data transfer from mobile clients to the CRM Server 4. Monitor outbound queue, data transfer from the CRM Server to the R/3 back-end system 5. Monitor inbound queue, data transfer from the R/3 back-end system to the CRM Server 6. Monitor replication and realignment queues (only MSA/ MSE) 7. Monitor Middleware message flow 8. Monitor flow control 9. Monitor the Middleware log 10. Monitor status of BDoc types 11. Monitor initial/delta load / requests from the R/3 back-end system to the CRM or from the CRM to the CDB (only MSA/ MSE) In addition to the Middleware monitors, the SAP basis has to be monitored: 1. Monitor R/3 Basis System 2. Monitor SAP Connect interface for mailing and/or fax (if used in CRM Online or Interaction Center Scenarios) 3. Monitor CTI interface (if used in Interaction Center scenario) 4. Monitor database Scenario Only MSA/ MSE Only MSA/ MSE all, if R/3- Back end is connected 2002 SAP AG 7

Server Types Monitoring Function 5. Monitor operating system 6. Monitor network throughput Scenario 2002 SAP AG 8

Best Practice: mysap CRM Monitoring Business Process Monitoring in the CRM MSA Server Landscape Example QMTCHECK Mobile Client(s) Business Processing DCOM Connector Monitor TransferService.log Inbound Queue Outbound Queue Comm. Station DCOM Connector SMQ2 SMQR SMWMQUEUES SMQ1/SMQS Outbound Queue Inbound Queue CRM MW System R/3 System Inbound Queue Outbound Queue SMQ2 SAP Business Processing DB & Log Replication and Realignment Queue Log file Flow / Process Control Engine & other services R/3 Application Database CDB MS Windows NT Performance Monitor MS Windows NT Performance Monitor SMWMFLOW SMO8FT SMW01/SMW02 SMOHQUEUE SM58 SMQ1 / SMQS ST03 DB02 ST06 SM50 / SM66 SM58 SMGW ST22 Non CRM-specific SAP System monitoring transactions: ST02, ST04, SM21, SMGW, SM13, STAD 2002 SAP AG 9

2.2 Procedures 2.2.1 R/3 Back-End System Monitoring After the CRM Server has been installed and the initial load has been successfully performed, system load (data exchange) to and from the R/3 back-end system can be categorized as follows: R/3 Back-End System CRM Server Delta load (business data and conditions) Request of specific data Synchronization load (customizing data only) Regular communications using RFC calls CRM Server R/3 Back-End System Delta uploads from CRM via outbound adapter Regular communications using RFC calls The following diagram shows the main points of interface on the R/3 back-end system. The transactions used to monitor these interface points are listed along with a brief label describing their function. 2002 SAP AG 10

Monitoring R/3 System SMQ2 Mobile Client(s) Comm. Station CRM MW System R/3 System Business Processing Inbound Queue Outbound Queue DCOM Connector Outbound Queue Inbound Queue Inbound Queue Outbound Queue SAP Business Processing DB & Log Replication and Realignment Queue Log file Flow / Process Control Engine & other services R/3 Application Database CDB SMQ1 / SMQS ST03N DB02 ST06 SM50 / SM66 SM58 SMGW ST22 2002 SAP AG 11

The table below lists transactions for monitoring the R/3 back-end system: Middleware Specific Monitoring R/3 Back-End System Monitoring Queue Monitoring Activities / Functions 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 Note 438015) To prevent data inconsistencies, you need to monitor the interfaces regularly for aborted or stopped data transfer Status of Queue Scheduler Monitor status of the QOUT Scheduler Transaction Code Monitoring Frequency Periods and Events SMQ1 Several times a day depending on the business process In case of an error message During mass updates Use Alert Monitoring SMQS In case of a status error Use Alert Monitoring Basis Monitoring: SAP Performance Monitors R/3 Back-End System General Monitoring Activities / Functions R/3 System Buffer Monitor: Monitor memory resource usage for specific R/3 application servers Implement parameter recommendations for memory management per EarlyWatch analysis Transaction Code ST02 Weekly Monitoring Frequency Periods and Events In case of performance problems Use normal R/3 system monitoring practices R/3 System Workload Analysis: Monitor RFC response time statistics for CRM Monitor the Dialog response time for online transactions Database Performance Analysis: Monitor database statistics Monitor the buffer cache hit ratio ST03N Daily ST04 Daily In case of performance problems In case of performance problems 2002 SAP AG 12

R/3 Back-End System General Monitoring Activities / Functions Database Performance Monitor Monitor the growing of tables and indices, especially on trfc- and qrfc-tables Transaction Code DB02 Daily Monitoring Frequency Periods and Events In case of performance problems Operating System Monitor: Monitor hardware load during high RFC transmission times ST06 Several times a day depending on the business process In case of performance problems Basis Monitoring: General System Checks R/3 Back-End System General Monitoring Activities / Functions Local Work Process Overview: Monitor current state of individual work processes Ensure that enough work process capacity is available at peak times System-wide Work Process Overview: Similar to SM50 but for system-wide statistics ABAP Dump Analysis: Analyze aborted programs Transaction Code Monitoring Frequency Periods and SM50 Several times a day depending on the business process Daily In case of performance problems or error messages SM66 Several times a day depending on the business process In case of performance problems or error messages ST22 Several times a day depending on the business process In case of an error message System Log: Check for general system errors Update Errors: Check for entries that have ERR status Display Statistical Records: Determine the performance of single statistical records SM21 Daily SM13 Daily In case of an error message In case of an error message STAD In case of an error message 2002 SAP AG 13

R/3 Back-End System Parameter Settings The parameters for data exchange with an R/3 back-end are defined in tables CRMCONSUM and CRMRFCPAR in the R/3 back-end. These tables are customized during system installation and are usually not changed during system operations. CRMRFCPAR controls the RFC traffic between the R/3 back-end system and the CRM Server. The following table gives an example how to fill the CRMRFCPAR table. The actual CRMRFCPAR entries are client dependent and significantly larger than this example. If you want to, for example, provide a CRM system with data, you have to create the following entries: Example for CRMRFCPAR Settings Parameter Name Value Description RFC QUEUE CRM Consumer that uses the CRM plug-in functions as a data receivers (e.g. CRM) OBJNAME * Object name * = valid for all objects RFCDEST CRM_<SID>_<client> Specifies the RFC destination of the CRM Server. DOWNLOAD * Restricts CRMRFCPAR entries to the initial or delta load. Possible values are: * valid for all kinds of data transfer I only for initial data transfer D for delta data transfer R for request With initial transfers, data can be sent to two destinations but with delta transfers data can only be sent to one destination. Standard value: * USE IN Q X Controls whether qrfc inbound queues are used on the CRM Server SEND XML M M * mixed mode (recommended) space * - no XML-conversion. This is only possible if the sending and receiving CPUs have the same architecture (homogeneous system landscape). X -XML will be used. To improve performance in data exchange and further information on this setting, refer to note 442277 in the SAP Service Marketplace 2002 SAP AG 14

Scheduling Background Jobs There are no CRM-specific background jobs to schedule on the R/3 back-end system. 2.2.2 CRM Server Monitoring The following diagram shows the interfaces on the CRM Server. The transactions used to monitor these interface points are listed along with a brief label describing their function. 2002 SAP AG 15

Monitoring CRM Middleware Server SMQ2 SMQR SMWMQUEUES SMQ1/SMQS Mobile Client(s) Comm. Station CRM MW System R/3 System Business Processing Inbound Queue Outbound Queue DCOM Connector Outbound Queue Inbound Queue Inbound Queue Outbound Queue SAP Business Processing DB & Log Replication and Realignment Queue Log file Flow / Process Control Engine & other services R/3 Application Database CDB SMWMFLOW SMO8FT SMW01/SMW02 SMOHQUEUE SM58 2002 SAP AG 16

The table below lists transactions used for monitoring the CRM Server: CRM Server Central Monitoring Activities / Functions 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: Adapter Status Information Replication and Realignment Queues BDoc Messages in the Flow Monitoring Type Monitoring Frequency Periods and Events 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 back-end 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 SMQ1 Several times a day depending on the business process Daily 2002 SAP AG 17

CRM Server Central Monitoring Activities / Functions Server and the mobile client. In severe cases when a client cannot be manually rebuilt, it can be brought back into a consistent state by rebuilding the client data from the CDB (AC_EXTRACT) QOUT Scheduler Ensure that all destinations are registered. Only destination NONE must be excluded. See also SAP Note 400330 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 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. Possible a scheduler problems may exist. Check the maximum processing time of the inbound queues. Set the maximum processing time of a queue ("Max-time") to 60 seconds for all queues during normal operations Monitoring Type SMQS Daily Monitoring Frequency Periods and Events In case of performance problems or error messages SMQ2 Several times a day depending on the business process SMQR Daily In case of performance problems TRFC Monitoring Monitor all transactional RFCs SM58 Several times a day depending on the b i 2002 SAP AG 18

CRM Server Central Monitoring Activities / Functions (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) 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 Monitoring Type SMWMFLOW Only for power users Monitoring Frequency Periods and Events business process 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 Summary of Unprocessed BDoc Messages Check Flow Definitions Only after changes in the customizing Consistency Check for Flow Definitions SMWT In case of an error message SMW03 SMO8FD After BDoc type changes or changes in services or in the flow are made In case of an error message 2002 SAP AG 19

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 back-end, the CRM or the CDB is necessary Basis Monitoring: General System Checks CRM Server General Monitoring Monitoring Type Activities / Functions R/3 System Workload Analysis: Monitor RFC response time statistics for CRM Monitor the dialog response time for Online transactions (e.g. CIC0) Local Work Process Overview: Monitor current state of individual work processes Ensure that enough work process capacity is available at peak times System-wide Work Process Overview: Similar to SM50, but for system-wide statistics Internet Communication Manager (ICM) Monitor Monitor current state of ICM and services Monitoring Frequency Periods and Events ST03N Daily In case of an error message SM50 Hourly In case of an error message or performance problems SM66 Several times a day depending on the business process In case of an error message or performance problems SMICM Upon error Daily 2002 SAP AG 20

CRM Server General Monitoring Activities / Functions ICM administration Monitoring Type Monitoring Frequency Periods and Events Buffer Monitor: Monitor memory resource usage for specific R/3 application servers Use normal SAP System monitoring practices Operating System Monitor: Monitor hardware load during high dialog user load / RFC transmission times Database Performance Monitor: Monitor indices on trfc and arfc tables Database Performance Analysis: Monitor the growth of tables and indices ABAP Dump Analysis: Analyze aborted programs System Log: Check for general system errors Gateway Monitor / Connection List: Monitor the active connections to other servers Display gateway trace Check the SAP return code and CPI-C return code values for errors Update Errors: Check for entries that have an ERR status Display Statistical Records: Determine the performance of statistical records ST02 Weekly ST06 Several times a day depending on the business process DB02 Daily In case of an error message ST04 Daily In case of performance problems ST22 Daily In case of an error message SM21 Hourly In case of an error message SMGW In case of an error message SM13 Several times a day depending on the business process In case of an error message STAD In case of an error message CRM Server Parameter Settings For data exchange with an R/3 back-end the parameters are defined in the CRMCONSUM table on the CRM Server side. Parameter Name Value Description 2002 SAP AG 21

Parameter Name Value Description Consumer CRM / CDB / EXT / ONL Consumer of adapter functionality Active X Flag if application is activated Q_Prefix CDB R3A EXT ONL Prefix for queue names in QRFC The table SMOFPARSFA contains control parameters of the CRM Server. Other settings of the parameters depend on the business scenario you are using, see CRM Installation Guide. Current, experience-based parameter settings are checked during each SAP Service Session (EarlyWatch, GoingLive, etc.). The SAP recommendations should be applied according to the instructions given in the SAP Service report. The following parameters are important for CRM Field Sales and are provided here as an example: Parameter key Parname Description CRMGENERAL TRACE-LEVEL ENV=G CRMGENERAL TRACE-LEVEL ENV=* CRMGENERAL TRACE-LEVEL ENV=I RRS_COMMON MAX_PACKAGE_SIZE Note 453882 (only MSA/MSE) RRS_COMMON RRQUEUE_PARALLEL Note 453882 (only MSA/MSE) FLOW USE_INQUEUE_ALWAYS Note 529764 (for distributed systems) Scheduling Batch Jobs 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) 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. 2002 SAP AG 22

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 2.2.3 Field Sales Specific Monitoring qrfc Inbound Synchronization Flow Mapping Service: Sync BDoc -> Msg BDoc Messaging Flow R/3 Adapter XIF Adapter CRM Adapter qrfc Inbound qrfc Inbound Inbound and Outbound Queue Monitoring Routing (Simple Replication) Display BDoc Messages, Middleware Trace XIF Adapter R/3 Adapter Mobile Bridge: Msg BDoc -> Sync BDoc qrfc Outbound qrfc Outbound Synchronization Flow CDB Service Replication/ Realignment Outbound Adapter Replication & Realignment Queues qrfc Outbound In this section, all CRM Middleware monitors specific for Mobile scenarios are described. 2.2.3.1 CRM Server Mobile Bridge settings: For all BDoc types that you are planning to use in MSA/ MSE scenario you have to enable the Mobile Bridge: You have to set field ACTIVE to X in table SMW3FDCUST according SAP Note 430392. 2002 SAP AG 23