To guarantee objective performance analysis and optimal system performance, it is important to activate a collection of performance statistics and traces. You also must ensure that appropriate background jobs are scheduled and executed successfully. In this, the second part of a two-part series covering the Monitoring Cockpit for CRM Middleware, I concentrate on how the Monitoring Cockpit can help you with these tasks. The first article I wrote on this topic, “Simplify CRM Middleware Monitoring with the Central Monitoring Cockpit,” was posted to the knowledgebase in January 2010. In that article, I provided an overview of the central CRM Middleware monitoring tool found in transaction SMWP. I also explained some monitoring capabilities of the Monitoring Cockpit.

In this follow-up, I discuss how the Monitoring Cockpit provides services for:

• Monitoring tools or statistics such as BDoc type, BDoc service workload statistics, BDoc message flow processing statistics, CRM Middleware alert monitor, and CRM Middleware trace
• Background jobs such as CRM Middleware reorganization, the Monitoring Cockpit collector, the collector for BDoc message and site statistics, generation status objects, periodical background generation, the administration console subscription agent, and administration console site scheduling

Monitoring Tools and Statistics

The Monitoring Cockpit displays the status of monitoring tools or statistics for CRM Middleware under the Monitoring Tools/Statistics node (Figure 1). The information these tools and statistics provide plays an important role in optimizing the performance of your SAP CRM system. They include:

• BDoc Type/BDoc Service Workload Statistics
• BDoc Message Flow Processing Statistics
• Status of CRM Middleware Alert Monitor
• Trace status

Figure 1

Monitoring elements of the Monitoring Tools/Statistics node

BDoc Type/BDoc Service Workload Statistics

This node provides statistical information about service kernel applications, such as the CPU used and database time for the BDoc message processing. You can see these statistics by double-clicking BDoc Type/BDoc Service Workload Statistics. These statistics can also provide information about the execution time for services that selected BDoc types called.

The definition and scheduling of the standard Computing Center Management System (CCMS) background job COLLECTOR_FOR_PERFMONITOR is required for the kernel application statistics monitor. You can activate and display the kernel application statistics with transaction SMWMFLOW. You can then use the statistical data provided in transaction SMWMFLOW to analyze a service or component, such as the database and CPU that is slow. This information can be very useful for troubleshooting, especially when the processing time for objects or requests is unusually long.

You can use the statistical details with a standard tracing tool, such as performance trace (transaction ST05), to identify the SQL statement that is responsible for the prolonged response time. When the corresponding traffic light in the Monitoring Cockpit is green, it indicates that the BDoc Type/BDoc Service Workload Statistics is activated. When it is yellow, it is not active.

BDoc Message Flow Processing Statistics

The message flow statistics for BDoc types, sites, and queues provide the processing time for BDoc messages in CRM Middleware. This monitor displays the total execution time for a BDoc message. You can activate and display the CRM Middleware flow statistics with transaction SMWMFLOW. Note that the statistical file can grow very large. Therefore, you should delete this file in transaction SMWMFLOW after you review it. When the corresponding traffic light of the Monitoring Cockpit is green, it indicates that BDoc Message Flow Processing Statistics is activated. When it is yellow, it indicates that it is not active.

Status of CRM Middleware Alert Monitor

The Monitoring Cockpit also helps determine the status of the CRM Middleware Alert Monitor, which monitors important processes. These include the processing of:

• BDoc messages in the flow
• Replication and realignment queues
• SAP CRM-specific queued Remote Function Call (qRFC) inbound and outbound queues in the SAP CRM system
• SAP CRM-specific qRFC outbound queues in the SAP R/3 or SAP ERP online transaction processing (OLTP) system

Alerts are generated when critical events occur. These alerts are based on defined threshold values and rules. They are designed to draw your attention to issues that conflict with your defined threshold settings. For example, you can set threshold values for the number of entries in qRFC queues via transaction RZ21 (monitoring: properties and methods). The function module SALK_CRM_QRFC_QUEUE_ENTRIES creates a node for monitoring the number of entries in a queue. For outbound queues, you could set the threshold values for yellow and red alerts as 500,000 and 1,000,000, respectively. For inbound queues, the threshold values for yellow and red alerts could be set to 5,000 and 10,000, respectively.

Alerts are triggered when any of the following events occur:

• A BDoc message has an error status
• Errors are encountered in the queue groups for outbound queues in the SAP CRM server and in the SAP ERP back-end system
• The number of entries in a queue exceeds the defined threshold value
• Queues are unregistered
• Errors are present in the qRFC scheduler of qRFC inbound and outbound queues in the SAP CRM server
• The queue demon of replication and realignment queues is stopped
• Queues are stopped
• The size of a queue exceeds the defined threshold value (as described in my example above)

When the corresponding traffic light of the Monitoring Cockpit is green, it indicates that the CRM Middleware Alert Monitor is active without alerts. When the light is yellow, it is not active. When it is red, it indicates that the CRM Middleware Alert Monitor is active but has an alert you need to check.

Trace Status

If tracing is not properly managed in CRM Middleware, it can adversely affect SAP CRM system performance — especially as it relates to high table growth. You can set different trace levels in the system using the Trace level column in transaction SMWTAD or by double-clicking Trace Status in Figure 1. Figure 2 shows the trace levels, which include:

• Level 0: Error — only critical errors are reported
• Level 1: Warning — only conditions that could lead to errors are reported
• Level 2: Flow Services — provides information about the services running in CRM Middleware
• Level 3: Detail Level 1 — no critical warning. Contains only additional information about executed programs and functions.
• Level 4: Detail Level 2 — contains program-specific information

Figure 2

Trace level settings for a CRM Middleware trace

The Environment column allows you to define a higher granularity for your trace data via transaction SMWTAD (Figure 3). The available trace environments include delta data synchronization, message flow, replication, generation, initial load, test, mass data handling, and extractor. SAP recommends that you set all environments (except the Generation [G] environment) to Level 1. The G environment should be set to Level 4.

Figure 3

Trace environments

When the corresponding traffic light of the Trace status in Figure 1 is green, it indicates that tracing is active and aligns with SAP’s standard default trace level setting. When it is yellow, it indicates that it is active but with a higher trace level than the default value. Note that setting CRM Middleware tracing to a high level of granularity can have an effect on available disk space and therefore system performance. I discuss the deletion of trace records in the next section.

Background Jobs

One of the core competencies of the Monitoring Cockpit is its ability to monitor various background jobs. Background jobs automate administrative tasks that enhance the SAP CRM server performance. Some background jobs are client-specific and some are cross-client. Figure 4 shows the background jobs the Monitoring Cockpit watches:

• Middleware Reorganization
• Collector for Monitoring Cockpit
• Collector for BDoc Messages/Site Statistics
• Check Generation Status of Objects
• Periodical Background Generation
• Administration Console Subscription Agent
• Administration Console Site Scheduling

Figure 4

Monitored background jobs

Middleware Reorganization

Table SMWT_TRC stores trace information. This trace table can grow very large — to the extent that it affects system performance and availability (depending on the trace level defined for the tracing environment).

One way to prevent the table from growing too large is to delete the records in the table as often as possible. After you delete these entries, it is important to perform a reorganization of the table to consolidate free space. The system uses the standard program SMO6_REORG2 to delete the entries in the CRM Middleware trace tables. Program SMO6_REORG2 also manages the reorganization of CRM Middleware traces, BDoc links, and BDoc messages that are reprocessed after encountering errors. Program SMO6_REORG2 calls a number of reports, such as:

• SMO8_FLOW_REORG for deleting flow data
• RSMWM_TRACE_REORG for deleting trace data
• SMO9_CLEAR_KYTBL for deleting key G environment data
• RSMWM_BSTAT_REORG for deleting BDoc statistics
• RSMWM_SESSION_REORG for deleting communication monitor session data
• SMOE_REORG_REPOSITORY for deleting temporary job ID data in the administration console
• SMOE_SCHEDULING_REORG for deleting scheduling data in the administration console
• SMOE_REORG_SUBSCRIPTION_AGENT for the reorganization of logs of subscription agents
• SMOE_REORG_XRR for deleting temporary realignment data for inactive sites
• SMOE_REORG_ADM_OBJECTS for the reorganization of deleted sites, subscriptions, and organizations
• SMOF_REORG_REQUESTS for the reorganization of requests (only one-time requests)
• RSRLDREL for the reorganization of object links for BDocs

The standard SAP variant SAP&_MW_REORG for program SMO6_REORG2 allows the deletion of entries in the table after a week. You can reduce this retention period to between one and six days by creating another variant for the report.

The Monitoring Cockpit provides you with an overview of the status of this background job at any point in time. When the corresponding traffic light of the Monitoring Cockpit is green, it indicates that the background job is scheduled to run or is currently running. When it is yellow, it indicates that the background job is not running.

Collector for Monitoring Cockpit

To use the Monitoring Cockpit for CRM Middleware, one of the programs that you must schedule for execution is SMWP_BATCH. This program updates the displayed runtime information, which is dynamic. The program refreshes all the Monitoring Cockpit nodes. You should schedule this program to run via the background job SAP_MW_COCKPIT_COLLECT every hour. The job must be running or scheduled for execution in order for you to see the current and correct status information in the Monitoring Cockpit. This is client specifics, so you must activate it in all clients in the SAP CRM server. When the corresponding traffic light in Figure 4 is green, it indicates that the background job is scheduled to run or currently running. When it is yellow, it indicates that the background job is not running. When it is red, it indicates that the background job has been cancelled.

Collector for BDoc Messages/Site Statistics

The program RSMWM_BSTAT_COLLECTOR collects data from the mobile client communication monitor and the BDoc message store to generate statistics that are displayed in transactions SMWMCOMM and SMWMFLOW. To ensure that the statistics are activated, you must first activate the background job SAP_COLLECTOR_FOR_PERFMONITOR.

If the middleware message flow is activated during the processing of BDoc types, the system generates log files of the performance data. The program RSMWM_BSTAT_COLLECTOR processes the logs at defined intervals (usually every hour). The execution of RSMWM_BSTAT_COLLECTOR is client specific. You must activate it in each client on the SAP CRM server. When the corresponding traffic light of the Monitoring Cockpit shown in Figure 4 is green, it indicates that the job is scheduled to run or it is currently running. When it is yellow, it indicates that the job is not running.

Check Generation Status of Objects

The program GN_GENERATE_CHECK can check the status of a generation of any object on the SAP CRM server for changes. If changes are made to the template, they are detected and a request is made for a new generation. The job MW_GENERATE_P executes the report GN_GENERATE_CHECK. The job is cross client, so you do not need to activate it in each client in the SAP CRM server. When the corresponding traffic light in Figure 4 is green, it indicates that the job is scheduled to run or it is currently running. When it is yellow, it indicates that the job is not running.

Periodical Background Generation

The generation processes in transaction GENSTATUS create all the runtime objects for the SAP CRM repository. The program GN_WORKLIST_GENERATE starts these processes. The job MW_GENERATE_P executes the report GN_WORKLIST_GENERATE. This job is cross-client, so you do not need to activate it in each client on the SAP CRM server. When the corresponding traffic light in Figure 4 is green, it indicates that the job is running or scheduled to run. When it is yellow, it indicates that the job is not running. When it is red, it indicates that the job is cancelled.

Administration Console Subscription Agent

You can use the report SMOE_SUBSCR_AGENT_EXECUTE_JOB in mobile scenarios for subscription agents, particularly if you use subscription agents to automatically generate subscriptions for mobile clients. The job is client specific, so activate it in all clients on the SAP CRM server. Once again, if the corresponding traffic light in Figure 4 is green, it indicates that the background job is running. When it is yellow, it indicates that the background job is not running.

Administration Console Site Scheduling

Use report SMOE_SCHEDULING_EXECUTE_JOB in field application scenarios for site scheduling. Say that you want to deactivate a site for a defined period of time, such as when there is large volume of data in the outbound queue. You could use report SMOE_SCHEDULING_EXECUTE_JOB for site deactivation in such a scenario. The job is client specific, so activate it on all clients in the CRM server. When the corresponding traffic light in Figure 4 is green, it indicates that the background job is running. When it is yellow, it indicates that the background job is not running.

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
 

You may contact the author at eseyinok@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.