BPM - Setup Guide

8/2/2019 BPM - Setup Guide

http://slidepdf.com/reader/full/bpm-setup-guide 1/82

Business Process Moni t or ing

Set-up and Use r Guidel ine

Business Proc ess Moni t or ing

w i t h SAP Solu t ion Manager

Release ST 4.0 and ST-SER

700_2007_1

November 2007



© Copyright 2007 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®, DB2 Universal Database, OS/2®, Parallel Sysplex®,

MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries,

pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®,

Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM

are

trademarks of IBM Corp. in USA and/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation.

UNIX®, X/Open®, OSF/1®, and Motif ® are registered trademarks of

the Open Group.

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®,

WinFrame®, VideoFrame®, MultiWin® and other Citrix product names

referenced herein are trademarks of Citrix Systems, Inc.

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.

J2EE™ 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, SAP ArchiveLink, SAP Business

Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE,

Management Cockpit, mySAP, mySAP.com, and other SAP products

and services mentioned herein as well as their respective logos are

trademarks or registered trademarks of SAP AG in Germany and in

several other countries all over the world. MarketSet and Enterprise

Buyer are jointly owned trademarks of SAP Markets and Commerce

One. All other product and service names mentioned are the

trademarks of their respective owners.

Disclaimer

Some components of this product are based on Java™. Any code

change in these components may cause unpredictable and severe

malfunctions and is therefore expressively prohibited, as is any

decompilation of these components.

Any Java™ Source Code delivered with this product is only to be used

by SAP’s Support Services and may not be modified or altered in any

way.

Documentation in the SAP Service Marketplace

You can find this documentation at the following address:

http: / /serv ice.sap.com/bpm

SAP AGDietmar-Hopp-Allee 1669190 WalldorfGermanyT +49/18 05/34 34 24F +49/18 05/34 34 20www.sap .com



Business Process Monitoring in the SAP Solution Manager

November 2007 3

TABLE OF CONTENTS

1 INTRODUCTION........................................................................................................................ 7

1.1 Business Process Monitoring.................................................................................................................. 8

1.2 Integration Management and Interface Monitoring ............................................................................... 11

1.3 Service Level Management and Reporting........................................................................................... 11 1.4 Business Process Monitoring Related Services and Best Practice Documents................................... 11

2 TECHNICAL INFRASTRUCTURE........................................................................................... 13

2.1 SAP Solution Manager Infrastructure.................................................................................................... 13

2.2 Computing Center Management System (CCMS)................................................................................ 13

2.3 Data Collection Method......................................................................................................................... 14

2.4 RFC Destinations .................................................................................................................................. 15

2.5 Add-Ons and Plug-Ins........................................................................................................................... 16

2.5.1 SAP Solution Manager System..................................................................................................... 16 2.5.1.1 ST................................ ..................................................... ......................................................................... 17

2.5.1.2 ST-SER .................................................. ....................................................... ............................................ 17 2.5.1.3 ST-PI ............................................... ........................................................ .................................................. 17 2.5.1.4 ST-A/PI................................. ........................................................ ............................................................. 17

2.5.2 Satellite Systems........................................................................................................................... 17 2.5.2.1 ST-PI ............................................... ........................................................ .................................................. 17 2.5.2.2 ST-A/PI................................. ........................................................ ............................................................. 18

3 PREREQUISITES FOR BUSINESS PROCESS MONITORING ............................................. 19

3.1 Business Process Monitoring Infrastructure.......................................................................................... 19

3.1.1 Service Session(s)......................................................................................................................... 19

3.1.2 Service Session Structure............................................................................................................. 19

4 SETUP OF BUSINESS PROCESS MONITORING................................................................. 21

4.1 Review Core Business Processes ........................................................................................................ 21

4.2 Solution Support Organization .............................................................................................................. 21

4.3 Business Processes.............................................................................................................................. 23

4.3.1 Business Process Steps and Interfaces........................................................................................ 24

4.3.2 Monitoring Types........................................................................................................................... 25

4.3.3 Application Monitor........................................................................................................................ 26 4.3.3.1 Real-time alert monitors and User Exit ..................................................... ................................................. 26 4.3.3.2 Throughput and Backlog Indicators (TBIs) ................................................. ............................................... 27

4.3.4 Background Job............................................................................................................................. 28 4.3.4.1 Monitoring Objects .................................................... ........................................................ ........................ 28 4.3.4.2 Monitoring Schedule.......................... ....................................................... ................................................. 31 4.3.4.3 Monitoring Alerts ................................................ ..................................................... .................................. 33 4.3.4.4 Major Job Monitoring Cases.... ....................................................... ........................................................... 34

4.3.5 Dialog Performance....................................................................................................................... 36 4.3.5.1 Monitoring Objects .................................................... ........................................................ ........................ 36 4.3.5.2 Monitoring Alerts ................................................ ..................................................... .................................. 37

4.3.6 Update Errors ................................................................................................................................ 38 4.3.6.1 Monitoring Objects .................................................... ........................................................ ........................ 38 4.3.6.2 Monitoring Alerts ................................................ ..................................................... .................................. 38

4.3.7 Due List Log................................................................................................................................... 38 4.3.7.1 Monitoring Objects .................................................... ........................................................ ........................ 39 4.3.7.2 Monitoring Alerts ................................................ ..................................................... .................................. 39

4.3.8 Application Log.............................................................................................................................. 40

4.3.8.1 Monitoring Objects and Alerts ............................................... .................................................................... 40 4.3.8.2 Alert evaluation remarks................... .................................................... ..................................................... 41




4 November 2007

4.3.9 Document Volume......................................................................................................................... 42 4.3.9.1 Monitoring Objects and Alerts ............................................... .................................................................... 42

4.3.10 Other CCMS Monitors ................................................................................................................... 42

4.3.11 Analysis & Monitoring Tools .......................................................................................................... 43

4.3.12 Monitoring Activities....................................................................................................................... 44

4.3.13 Notifications................................................................................................................................... 45 4.3.13.1 Workflow Notification ....................................................... ...................................................................... 45 4.3.13.2 Support Notifications ....................................................... ...................................................................... 47

4.3.14 Interface Monitoring....................................................................................................................... 48 4.3.14.1 Standard Monitoring Objects in local CCMS ........................................................... .............................. 49 4.3.14.2 Implement Interface Monitoring in SAP Solution Manager...................................................... .............. 62

4.3.15 Generation of Customizing............................................................................................................ 67

4.3.16 Data Collector Frequencies........................................................................................................... 67

4.3.17 Local RFC Destination for Data Collection.................................................................................... 68

4.4 Activate / Deactivate Business Process Monitoring.............................................................................. 68

4.4.1 Activation ....................................................................................................................................... 68

4.4.2 Deactivation................................................................................................................................... 70

5 USE OF BUSINESS PROCESS MONITORING...................................................................... 71

5.1 Alert Rating............................................................................................................................................ 71

5.2 Graphical Overview............................................................................................................................... 72

5.2.1 Alerts related to a Process Step.................................................................................................... 74

5.3 Business Process Monitoring Session.................................................................................................. 75

5.3.1 General Monitoring Object Information ......................................................................................... 76

5.3.2 Alert Information ............................................................................................................................ 76 5.3.2.1 Alert List ............................................... ........................................................ ............................................. 76 5.3.2.2 Alert Confirmation............................. ........................................................ ................................................. 77 5.3.2.3 Service Desk Message........................ ..................................................... ................................................. 78 5.3.2.4 Alert Configuration............................. ..................................................... ................................................... 79 5.3.2.5 Analysis Transaction or URL................................................. .................................................................... 79

5.4 Escalation Path and Error Handling ...................................................................................................... 79

5.5 Service Level Reporting ........................................................................................................................ 80

6 ADDITIONAL INFORMATION FOR USING SAP SOLUTION MANAGER ............................ 81

6.1 SAP Solution Manager Roles and Authorizations................................................................................. 81

6.2 Service Desk Configuration................................................................................................................... 81

6.3 Workflow Configuration ......................................................................................................................... 81

6.3.1 Prerequisites.................................................................................................................................. 81

6.3.2 SAPconnect Administration........................................................................................................... 81 6.4 Important SAP Notes............................................................................................................................. 82




November 2007 5

TABLE OF FIGURES

Figure 2-1 SAP Solution Manager and Satellite Systems............................................................................... 13

Figure 2-2 Technical Infrastructure1................................................................................................................ 14

Figure 2-3 Data collection................................................................................................................................ 15

Figure 3-1 SAP Solution Manager service session......................................................................................... 20

Figure 4-1 Solution Support Organization - Teams......................................................................................... 22

Figure 4-2 Contact maintenance with SAP Solution Manager 4.0.................................................................. 23

Figure 4-3 Monitoring Roles ............................................................................................................................ 23

Figure 4-4 Business Processes....................................................................................................................... 24

Figure 4-5 Business Process Steps ................................................................................................................ 25

Figure 4-6 Weekly Schedule ........................................................................................................................... 31

Figure 4-7 Monthly Schedule........................................................................................................................... 32 Figure 4-8 Monitoring Objects – Dialog Performance ..................................................................................... 37

Figure 4-9 Monitoring Alerts - Dialog Performance......................................................................................... 37

Figure 4-10 Monitoring Objects - Update Errors ............................................................................................. 38

Figure 4-11 Monitoring Object - Due List Log ................................................................................................. 39

Figure 4-12 Monitoring Alert - Due List Log .................................................................................................... 39

Figure 4-13 Monitoring Objects and Alerts - Application Log.......................................................................... 40

Figure 4-14 Monitoring Alerts - Application Log / Critical Messages............................................................... 41

Figure 4-15 Monitoring Objects and Alerts - Document Volume..................................................................... 42

Figure 4-16 Other CCMS Monitors.................................................................................................................. 43

Figure 4-17 Analysis & Monitoring Transactions............................................................................................. 44

Figure 4-18 Analysis & Monitoring URL .......................................................................................................... 44

Figure 4-19 Interface Monitoring in SAP Solution Manager’s Business Process Monitoring.......................... 49

Figure 4-20 ALE/EDI Standard Monitoring Groups......................................................................................... 50

Figure 4-21 qRFC/tRFC Standard Monitoring Groups.................................................................................... 51

Figure 4-22 BDMO - New Entry....................................................................................................................... 52

Figure 4-23 BDMO - Customize Monitoring Object......................................................................................... 52

Figure 4-24 ALE/EDI Specific Monitoring Objects........................................................................................... 54

Figure 4-25 tRFC MTE for ALE processing..................................................................................................... 55

Figure 4-26 qRFC-Customizing / New Entry ................................................................................................... 56

Figure 4-27 qRFC – Customizing / Queue Groups ......................................................................................... 57

Figure 4-28 qRFC – Customizing / Queue Groups – by Queue Entries ......................................................... 57

Figure 4-29 qRFC – Customizing / Queue Groups – by Queue Age.............................................................. 58

Figure 4-30 qRFC - Queue Assignments ........................................................................................................ 58

Figure 4-31 qRFC Specific Monitoring Object................................................................................................. 61

Figure 4-32 Setup Interface Monitoring in SAP Solution Manager ................................................................. 62

Figure 4-33 Use value help to assign ALE/EDI-monitoring object to an interface .......................................... 63




6 November 2007

Figure 4-34 Selection of ALE/EDI related alerts.............................................................................................. 63

Figure 4-35 Assign qRFC-monitoring object to an interface ........................................................................... 64

Figure 4-36 Selection of qRFC related alerts.................................................................................................. 65

Figure 4-37 Configure tRFC monitoring .......................................................................................................... 65

Figure 4-38 Selection of a Interface technique other than ALE/EDI, qRFC or tRFC...................................... 65

Figure 4-39 Retrieval of the MTE name in SAP CCMS................................................................................... 66

Figure 4-40 Other CCMS Alert Monitors ......................................................................................................... 66

Figure 4-41 Business Process Monitoring - Initial screen ............................................................................... 69

Figure 4-42 Business Process Monitoring - After activation............................................................................ 70

Figure 5-1 Possible alert ratings...................................................................................................................... 71

5-2 Changing the Evaluation Hierarchy of Alerts ............................................................................................ 72

Figure 5-3 Current status of Business Process in Business Scenario............................................................ 72

Figure 5-4 Current status on Business Process level ..................................................................................... 73

Figure 5-5 Current status on Business Process step level.............................................................................. 74

Figure 5-6 Open alerts on Business Process step level.................................................................................. 74

Figure 5-7 Business Process Monitoring Session........................................................................................... 75

Figure 5-8 Monitoring activities........................................................................................................................ 76

Figure 5-9 Messages related to an alert.......................................................................................................... 76

Figure 5-10 Alert Confirmation in the session ................................................................................................. 77

Figure 5-11 Alert confirmation in the graphic .................................................................................................. 78

Figure 5-12 Confirmation of parent node in the graphic.................................................................................. 78

Figure 5-13 Create Service Desk Message..................................................................................................... 79




November 2007 7

1 IntroductionBusiness Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and process-oriented monitoring of the most important or critical business processes including the observation of all

technical and business application specific functions that are required for a steady and stable flow of thebusiness processes.

The core business processes that are implemented in an ERP or other software and operated by a companyare of particular importance, and Business Process Monitoring is intended to ensure a smooth and reliableoperation of the business processes and, thereby, that the core business processes meet a company’sbusiness requirements in terms of stability, performance, and completeness. The SAP Solution Managerprovides a graphic to visualize a company’s (distributed) system and solution landscape and all relatedbusiness processes. By using Business Process Monitoring, it is possible to define and customize alertsituations from a basic set of configurable alerts provided by the SAP Solution Manager. These alerts arethen visualized by green, yellow, and red alert icons for each individual business process step in thegraphical business process representation. Business Process Monitoring is intended to detect and respondto critical situations as early as possible in order to solve problems as fast as possible.

In addition, the SAP Solution Manager offers extended functionality for error handling and problemresolution. By the definition of contact persons and escalation paths, Business Process Monitoring can beintegrated into the company’s overall strategy for Business Process Management and Solution Managementwithin their Solution Support Organization.




8 November 2007

1.1 Business Process MonitoringBusiness Process Monitoring (BPMon) – as one essential aspect of Business Process Integration andAutomation Management – means the proactive and process-oriented monitoring of a company’s core

business processes including the observation of all technical and business application-specific functions thatare required for a smooth and reliable flow of the core business processes. Business Process Monitoring isintended to detect problem situations as early as possible in order to solve them as fast as possible, beforethey become critical for the business. A tool for Business Process Monitoring is designed to provide definedmonitoring procedures and to enable the customer’s Solution Support Organization to solve problems moreproactively.

In general, a Business Process Monitoring includes the solution-wide observation of:

• Business process performance (Key Performance Indicators)

• Background jobs (Job Scheduling Management tasks (“Ablaufsteuerung”))

• Business application logs (such as any error log, general application log, due list logs etc.)

• Data transfer via interfaces between software components

• Data consistency (update processing)

• Technical infrastructure and components which are required to run the business processes

• Required periodic monitoring tasks

Since Business Process Monitoring is not considered to be only a tool, it further comprises detailedprocedures for error handling and problem resolution, the precise definition of contact persons andescalation paths, and the tight integration into the customer’s Solution Support Organization.

• Solution Support Organization

The roles and responsibilities, for all persons involved in the customer’s Solution Support and Monitoring

Organization, have to be defined. As an example, during an implementation project there is usually animplementation project team responsible for the Application Support before the Going Live of the project.Hence it is important that there is also someone responsible and doing the Application Support after GoingLive and after the implementation project team left the project. Therefore a handover procedure and a teamresponsible for the Application Support after Going Live have to be defined.

SAP provides a best practice document about ‘General Business Process Management’ in the SAP ServiceMarketplace (URL http://service.sap.com/solutionmanagerbp). The document includes all relevant roleswithin a Solution Support Organization that should be defined and staffed in order to provide an optimal levelof support to a related solution.

• Functional Scope of Business Process Monitoring

The functional scope of Business Process Monitoring within the SAP Solution Manager Release 4.0, ST-

SER 700_2007_1) comprises the following features (i.e., alert monitoring capabilities):

Complete Functional Scope of Business Process Monitoring

• R/3 background jobs (running on SAP systems with an R/3 basis)

o Start- and end-delay

o Out of time window

o Maximum Duration

o Cancellation

o Parallel processing of jobs

o Job log messages




November 2007 9

o Monitoring of jobs that are scheduled monthly or via factory calendar

• Dialog transaction performance per instance (as of SAP R/3 4.6B)

o Response time

o Wait time

o Load and Generating time

o Database time

o GUI-time

• Update errors for transactions and programs

o V1 update errors / V2 update errors

• Document volume (of any tables at any time)

o Inserts, updates, deletes

• Application log messages

o Application Log alerts for specific objects and/or sub-objects or MSG type, MSG ID, MSG No

• Application Monitoring of application-specific key figures

o Monitoring of due list logs (e.g. for delivery, picking and billing)

Document Creation

Minimum quantity of documents

Total quantity of messages

Due List log messages

o Monitoring of MRP key figures (SAP R/3 MM/PP)

Availability / existence of a MRP list

Evaluation of a MRP list by plant, controller, exception group

o Monitoring of SAP APO Application Log (MC8K)

Application Log alerts (differentiated by MSG type, MSG ID and MSG No)

Application Log summary (evaluating the amount of errors)

o Performance monitoring of transactions or programs on function code level

Performance for Function Codes being CUA internal commands

Performance for Function Codes transferred in HTTP requests

o Mass Data Monitoring for Mass Activities (e.g. IS-U, FI-CA, IS-T)

Number of Selected Objects (absolute and relative to last run)

Number of successfully processed objects (absolute and relative to last run)

Exceptions (absolute and relative to last run)




10 November 2007

Number of cancelled jobs (if parallelization is used)

Duration of all jobs related to the same mass activity (absolute and relative to lastrun)

o Monitoring of application related Throughput and Backlog Indicators (TBIs) in the following

application areas

ERP Logistic

Sales and Services (e.g. Sales Documents, Invoices)

Warehouse Management (e.g. Transfer Requirements, Transfer Orders)

Inventory Management (e.g. Goods Movements)

Logistics Execution (e.g. Deliveries, Shipments)

Procurement (e.g. Planned Orders, Purchase Requisitions, Purchase Orders)

Manufacturing (e.g. Planned Orders, Production or Process Orders, Autom. GoodsMovements posted with error, Confirmation Pool errors)

Plant Maintenance (e.g. PM/CS Notifications, PM/CS Orders)

CRM

Sales (Sales Documents, Business Activity Tasks)

Services (Service Documents, Business Activity Tasks)

Customer Interaction Center (Outbound Calls, Email Wort Items)

o Customer exit that allows developing customer-specific monitoring objects as extension ofthe available functionality

• All alerts which are configured in the CCMS of the central or one of the satellite systems

Interface Monitoring

• Data transfer via interfaces (effective as of SAP R/3 4.6C)

o EDI / ALE (IDoc)

o qRFC

o tRFC (generic)

Additional Functionality usable for Business Process Monitoring within the SAP Solution Manager

• Service Level Reporting aggregated per day, week or month and business process, businessprocess step, monitoring type, and alert type based on:

o Statistical performance data (EWA) for Service Level Agreements

o “Real" alerts from Business Process Monitoring

• Auto-Reaction e.g. via Email, Fax or SMS (can be created for single alerts)

• Auto-Creation of Service Desk messages (can be triggered automatically for single or multiple alerts)




November 2007 11

• Service Desk including a solution database

1.2 Integration Management and Interface MonitoringIntegration Management comprises all necessary procedures to ensure the reliable and safe operation of allinterfaces included within the business processes with respect to consistency, security and recovery.

One essential part of Integration Management is Interface Monitoring. Interfaces are very often considered tobe a potential risk to their related business processes and are often one reason for failure of the businessprocess flow. When core business processes fail or do not perform as required, it is possible to lose moneywithin a short period of time. Hence Interface Monitoring is very important and aims to check on a regularbasis if an interface is available and working properly. Procedures for Interface Monitoring should include:

• Monitoring tasks that are split up into Technical and Application Support

• Error handling procedures

• Restart and recovery techniques

• Escalation paths

The SAP SMO Service for Interface Management is intended to analyze and optimize essential interfaceswhich are related to the core business processes. Thereby the focus lies on performance, design,configuration and operation aspects.

For details about Interface Monitoring in the SAP Solution Manager, see the chapter about InterfaceMonitoring below.

1.3 Service Level Management and ReportingService Level Management means to measure defined parameters in accordance with Service LevelAgreements committed between two parties, organizational units, or organizations involved in themanagement and operation of a customer’s SAP solution. The following different organizations might beinvolved in a customer's project and therefore should be considered within a Service Level Management:

• Customer himself

• Hardware partner

• Software partner

• Implementation partner

• Outsourcing partner (e.g., for hardware hosting, support, etc.)

The results can be reported by means of Service Level (SL) Reporting in order to verify the adherence to thedefined Service Level Agreements and hence if the committed support levels are met. Moreover, ServiceLevel Reporting might be used to reveal any communication or competence issues between the differentparties involved.

Service Level Agreements can be based on technical indicators such as system availability and databasefree space or on business KPIs such as dialog transaction performance and document throughput. TheService Level Report itself should be prepared on a regular basis including all relevant data and information,and it should be available to all relevant parties.

For details about Service Level Management and Reporting in the SAP Solution Manager, see the chapterabout Service Level Management and Reporting below.

1.4 Business Process Monitoring Related Services and BestPractice Documents

Besides the Solution Management Optimization Service for Business Process Management which is helpingPremium Engagement customers to implement Business Process Monitoring, SAP offers different otherservices and Best Practice documents related to this topic. The following SAP Services are available in thearea of evaluation and assessment of a particular customer’s project or solution:




12 November 2007

• The SAP Technical Integration Check (TIC)

• The SAP Solution Management Assessment (SMA)

• The SAP Operations Readiness Assessment

• The SAP Operations Competence Assessment

The SAP Technical Integration Check (TIC, prior to Going Live) and the SAP Solution ManagementAssessment (SMA, post to Going Live) map the system and solution landscape as well as the core businessprocesses. Additionally both services aim at identifying all related issues and their impact on the system andsolution landscape and the core business processes. As a result these services provide an issue list andaction plan including all necessary steps and recommendations in order to address or solve all problems thatwere found.

The SAP Operations Competence Assessment analyzes the intended handover of support operations fromthe implementation project team to the existing support organization, while the SAP Operations CompetenceAssessment analyzes an existing Solution Support Organization in terms of necessary roles, responsibilitiesand required skills (related to trainings). This service shows required actions that should be taken in order tooperate and support the customer’s SAP solution optimally.

Best practices in managing the SAP solution are for• Knowledge transfer; the employees gain the knowledge to continuously improve their SAP solution

Currently the following Best Practice Documents are available in the area of Business Process Management

• General Business Process ManagementIs a Best Practice Document and describes how to develop and implement an all-inclusive conceptfor Business Process Management and Monitoring for a solution landscape comprising mySAPcomponents.

• Program Scheduling Management

This Best Practice Document provides you a rough roadmap on how to create and install a holisticProgram Scheduling Management concept and lays the groundwork for an optimal Background jobscheduling.

• Background Job Monitoring with SAP Solution Manager

This Best Practice Document is an enhancement to the information regarding the Job Monitoringfunctionality of Business Process Monitoring that is provided within this Setup Guide. The BestPractice document demonstrates and recommends specific monitoring setups in the view of severalpractical business scenarios.

• Further documents are available which are SAP solution specific (e.g. CRM, SCM and SRM)

By using SAP's experience gained in thousands of installations will save time and money because it avoidscomplications from the very beginning.

The documents are available on the SAP Service Marketplace via the URLhttp://service.sap.com/solutionmanagerbp.




November 2007 13

2 Technical InfrastructureFor all SAP Solution Manager Releases, the technical infrastructure used for Solution Monitoring is based onthe CCMS Alert Monitor (see below). The communication technique that is used between the SAP SolutionManager and the corresponding satellite systems is established via the RFC technology. This technique is

used for all parts of Solution Monitoring in the SAP Solution Manager, i.e. for System, Interface, andBusiness Process Monitoring.

2.1 SAP Solution Manager InfrastructureThe SAP Solution Manager obtains all necessary information for System and Business Process Monitoringas well as other Services from so-called satellite systems. These satellite systems can be SAP basissystems connected with application components such as CRM or BW or components from other vendors.

For components from other vendors self-developed CCMS agents are necessary.

Figure 2-1 SAP Solution Manager and Satellite Systems

2.2 Computing Center Management System (CCMS)The Computing Center Management System or CCMS Alert Monitor (transaction /nrz20) provides theunderlying monitoring infrastructure for Business Process Monitoring. Basically, we distinguish betweendifferent CCMS Alert Monitor locations: The CCMS Alert Monitor that is located in the SAP Solution Manageris referred to as central CCMS , the one that is located on each of the satellite systems is referred to as local CCMS .

During the Business Process Monitoring Activation (see below), monitoring objects – so-called Monitoring

Tree Elements or MTEs – are created in either the central or the local CCMS Alert Monitor, depending on thespecific BPMon monitoring type configured. Several monitoring objects are grouped by topic into so-calledMonitor Collections . In the SAP Solution Manager’s CCMS Alert Monitor, all relevant monitoring objects forBusiness Process Monitoring are included in the Monitor Collection called ‘BPM’.

As described above, the SAP Solution Manager’s Solution Monitoring is generally based on the CCMS AlertMonitor, and some of the monitoring functions make use of standard monitoring objects, which are providedby the CCMS Alert Monitor. This concerns all monitoring objects of System and Interface Monitoring as wellas monitoring objects for dialog transaction performance and update errors within Business ProcessMonitoring. These monitoring objects are generally located in the local CCMS of each individual satellitesystem.

The creation and maintenance (e.g. of alert thresholds) of all monitoring objects specified and configured inthe SAP Solution Manager (and hence necessary for System, Interface, or Business Process Monitoring can

be controlled by the SAP Solution Manager itself. Hence manual (direct) changes of a monitoring object’sproperties directly in the CCMS are not necessary.




14 November 2007

Figure 2-2 Technical Infrastructure1

2.3 Data Collection MethodFor data collection there will be standard methods used which are provided by the CCMS. Additionally thereare data collectors which are exclusively written for Business Process Monitoring. The difference is that thealerts build with the standard methods are stored in the local CCMS on every satellite system while the otheralerts (BPMon specific) are built in the central CCMS on the SAP Solution Manager.

1. The local CCMS on each satellite system comprises information about performance (dialogtransaction), update errors (V1 and V2), other CCMS monitoring and interfaces.

2. The central CCMS comprises information about background jobs, application monitoring, applicationlog, due list log as well as document volumes.

Solution Mana er

Solution Landsca e

Monitoring Graphic Monitoring Session

Monitoring Infrastructure

RZ20 MonitoringInfrastructure

Solution ManagerMonitoring Engine

RZ20 MonitoringInfrastructure

SAP R/3

datacollector

APO

datacollector

BW

datacollector

CRM

datacollector

EBP

datacollector




November 2007 15

Figure 2-3 Data collection

The frequency of how often the data will be collected can be customized for the alerts that are centrally builtduring the set up of Business Process Monitoring. The frequency cannot be changed for alerts that arelocally built.

2.4 RFC DestinationsThere are some RFC destinations that are relevant for the operation of Business Process Monitoring withinthe SAP Solution Manager. Usually those RFC destinations will be created and assigned when a newsatellite system is connected to the SAP Solution Manager (This can be set up and checked in transaction /nSMSY). There need to be two RFC destinations created and assigned for monitoring for every satellitesystem. In the following <SID> and <CLIENT> describe the SID and Client of the satellite system to bemonitored:

SM_<SID>CLNT<CLIENT>_READ

The RFC-connection is necessary for the data collection. During the generation of the RFCdestination a user (SOLMAN<SID><CLIENT>) with the correct authorizations is created on thesatellite system and assigned to this RFC destination. If the RFC destination is created manually in /nSM59, this user has to be created manually, too. In this case please observe the latest version ofSAP Note 455356 for the necessary authorization for the user. Of special importance for themonitoring (e.g. maintaining thresholds in the satellite system) is the combination S_RZL_ADMACTVT 01 and 16.

SM_<SID>CLNT<CLIENT>_LOGINThis RFC-connection is for a remote login to the satellite system. It will be used during the BusinessProcess Monitoring when it is necessary to perform a further analysis on the remote system in caseof a problem. This RFC-connection provides the possibility to jump into the corresponding satellitesystem and to call a transaction directly. (It is recommended to use a login connection to protectunauthorized access to a productive system. But if there is a trusted relationship between the SAPSolution Manager and the respective satellite system it is also possible to use theSM_<SID>CLNT<CLIENT>_TRUSTED RFC-connection.)




16 November 2007

In transaction /nRZ21 in the SAP Solution Manager the correctness of the assigned RFC destinations can bechecked (Topology -> System Overview). In the column Read Destination Data you should find an entrySM_<SID>CLNT<CLIENT>_READ and in column Destination Analysis you should find an entrySM_<SID>CLNT<CLIENT>_LOGIN for the corresponding System you want to monitor. If this is not the casethen click on the white paper button (Monitor Remote System ) or go to RZ21 Technical Infrastructure Create remote monitoring entry. On the following screen you enter the SID for the satellite system to be

monitored, SM_<SID>CLNT<CLIENT>_READ as Collecting Data and SM_<SID>CLNT<CLIENT>_LOGINas Executing Analysis Method .

It is also possible to create the RFC destinations manually on the SAP Solution Manager system viatransaction SM59 and assign them for monitoring in transaction RZ21. In this case it would be necessary toobserve SAP Note 455356 for the necessary authorization for user SOLMAN<SID><CLIENT>.

For technical reasons, the Business Process Monitoring function requires a local RFC destinationBPM_LOCAL_<CLIENT> within the SAP Solution Manager system, where <CLIENT> stands for the Clientin which the Business Process Monitoring is set up. This RFC-connection can be created from within theSetup Business Process Monitoring Session. A respective user needs to exist to create the connection. Thisuser (for example, SM_BPMO) needs to have the authorization profile S_CSMREG (transaction SU01,"Profiles" tab page) or the SAP_S_CSMREG role (transaction SU01, "Roles" tab page). SAP Note 455356 provides detailed information.

In addition the following roles have to be assigned to the user (transaction SU01, "Roles" tab page):

• SAP_SUPPDESK_CREATE (required for automatic creation of service desk messages)

• SAP_IDOC_EVERYONE (required for triggering automatic workflow notifications)

Furthermore the user’s personal time zone has to correspond to the system's time zone

In case Business Process Monitoring will be used in different clients, every client needs to have a local RFC-connection that points into the client.

2.5 Add-Ons and Plug-InsIn order to operate and use Business Process Monitoring, certain technical requirements must be met, i.e.some technical components must be installed on the SAP Solution Manager System and the connectedsatellite systems that will be monitored. The relevant Add-Ons and Plug-Ins are listed in the followingsections. It is recommended and important for Business Process Monitoring to stay current with thecorresponding Add-Ons, Plug-Ins, and their related Support Packages. The newest Releases and latestversions are always available via the SAP Service Marketplace by using the URLhttp://service.sap.com/swdc.

2.5.1 SAP Solution Manager System

SAP Solution Manager Release ST 4.0 must be installed as well as the add-on ST-SER (recommendedrelease 700_2007_1) that includes the Business Process Monitoring functionality (see SAP Note 521820 for

details regarding the available Releases).

Technical background: The monitoring data collection in the satellite system is triggered by theAutoABAP SAPMSSY6, which runs in client 000 of the SAP Solution Manager system and is executed bythe standard user SAPSYS. This user, however, does not have the authorization to call other systems via

RFC and is not able to parallelize the data collection via aRFCs. Therefore, the RFC destinationBPM_LOCAL_<CLIENT> which points from client 000 to the Business Process Monitoring setup client onthe SAP Solution Manager system is used in order to transfer the task of actually calling the satellitesystem to the user maintained in the RFC destination BPM_LOCAL_<CLIENT>. This user has thenecessary authorizations (profile S_CSMREG) and triggers the data collection on the satellite systems.




November 2007 17

2.5.1.1 ST

The SAP Solution Manager Add-On itself is called ST (abbreviation for Support Tool). This Add-On can beinstalled on each SAP R/3 or Web Application Server (WAS) system.

2.5.1.2 ST-SER

The Add-On SAP Solution Manager Service Tools (ST-SER) is part of SAP Solution Manager and containsthe services that are available in the SAP Solution Manager.

2.5.1.3 ST-PI

For technical reasons it is necessary to install the latest version of the Solution Tools Plug-In (ST-PI) on theSAP Solution Manager itself. The ST-PI is available via the SAP Service Marketplace Quick Link /SUPPORTTOOLS.

For more information refer to SAP Notes 539977, 560475 and 560630.

2.5.1.4 ST-A/PI

In order to be able to make use of the Application Monitor functionality also the latest version of theApplications Plug-In (ST-A/PI) must be installed on the SAP Solution Manager system itself. The ServiceTool for ST-A/PI is available via the SAP Service Marketplace Quick Link /SUPPORTTOOLS

More information can be found in SAP Note 69455.

The latest Throughput and Backlog Indicator functionality available with ST-A/PI 01J* is only workingproperly with ST-SER 700_2007_1. This is due to changes in the underlying architecture.

2.5.2 Satellite Systems

For SAP Systems the newest Release of the Plug-In ST-PI and ST-A/PI are required. Business ProcessMonitoring with SAP Solution Manager is possible since SAP R/3 Rel. 4.0B. Dialog transaction performanceas well as interface monitoring is possible since SAP R/3 Rel. 4.6B.It is also possible to include non-SAP Systems into the monitoring. Therefore special CCMS data collectorsneed to be written that provide the required monitoring information into the CCMS of the SAP SolutionManager system. A documentation of how to write a data collector is ‘CCMS Agents: Features, Installationand Usage’ (URL: http://service.sap.com/monitoring Monitoring in Detail).

2.5.2.1 ST-PI

The newest version of the Solution Tools Plug-In (ST-PI) must be installed in the satellite systems. The ST-PI is available via the SAP Service Marketplace Quick Link /supporttools Installations and Upgrades. Inaddition, SAP Notes 545661, 546283, 545920 have to be applied.

The add-on Solution Tools Plug-In (ST-PI) provides Basis and Trace Tools, which are required for servicedelivery and system monitoring.

The Solution Tools Plug-In contains the latest version of:

• Function modules for data collection

• Transaction SDCC (Service Data Control Center) *

• Transaction SQLR (SQL Trace Interpreter) *

*SDCC and SQLR are included in ST-PI for releases 4.0B - 4.6D. For release SAP Web AS 6.10 and higher

the transactions are included in the SAP Basis. Changes are shipped by basis support packages.




18 November 2007

2.5.2.2 ST-A/PI

The newest version of the Applications Plug-In (ST-A/PI) must be installed in the satellite systems. TheService Tool for ST-A/PI is available via the SAP Service Marketplace Quick Link /supporttools Installations and Upgrades. It contains the latest versions of:

• All content of Application Monitors, especially Throughput and Backlog Indicators

• Transaction ST14 (Application monitor)

• Report RTCCTOOL (Service tools Update)

• Transaction ST12 (ABAP trace for EarlyWatch/GoingLive)

• Transaction ST13 (Launch pad for further analysis tools) • new SDCC data collectors for BW, APO, CRM and databases




November 2007 19

3 Prerequisites for Business Process MonitoringBusiness Process Monitoring is not just activated by pressing a button in the SAP Solution Manager andtherefore the configuration of Business Process Monitoring is currently not intended as a customer self-service. Instead, the procedure to set up Business Process Monitoring in the SAP Solution Manager is rather

realized by the delivery of the SAP Solution Management Optimization (SMO) Service for BusinessProcess Management due to the complex nature of the overall configuration of Business Process Monitoring.However, it is possible (but not recommended) for customers to configure Business Process Monitoring bythemselves without any guidance of SAP.

This SMO service is exclusively available within an SAP Support Engagement (e.g. SAPMaxAttention, SAP Safeguarding or SAP Premium Support).

A prerequisite for the delivery of the SMO Service for Business Process Management is the precedingdelivery of a Solution Management Assessment (SMA) or Technical Integration Check (TIC) Service,which captures all necessary system and solution landscape as well as business process information in theSAP Solution Manager. Since Business Process Monitoring includes more than the functionality providedwithin the SAP Solution Manager, this guideline cannot replace the SMO Service for Business ProcessManagement and is not intended to do so.

In addition to the SMO Service for Business Process Management, SAP provides the training “SMO610 -Business Process Management and Monitoring”. This training enables to internalize the method andconcept of Business Process Management and it qualifies to set up and use the Business ProcessMonitoring for the daily work (URL http://www.service.sap.com/ Quick Link ‘Education’ (Online TrainingCatalog)).

3.1 Business Process Monitoring InfrastructureAll business process and business process step information is stored in the Solution Directory.

3.1.1 Service Session(s)

All relevant data related to Business Process Management will be entered in the SAP Solution Manager viaso-called Service Sessions. There are basically three different Service Sessions in the context of BusinessProcess Monitoring:

• Set Up Business Process Monitoring Session

o Used for BPMon configuration and Customizing

• Business Process Monitoring Session(s)

o Will be generated for each individual business process (for which the monitoring customizinghas been generated) and keeps current and historic monitoring data

• Service Level Reporting Session

o SL Reporting as a part of Service Level Management

3.1.2 Service Session Structure

A session is generally split into three areas. On the left hand side there is a tree containing nodes and sub-nodes that map the structure of the session content. Depending on the entries, the structure of the tree maychange.




20 November 2007

Figure 3-1 SAP Solution Manager service session

The right hand side of an SAP session is split into the Action Description (upper part) and the Area of Table Entries . The Action Description contains the description about what has to be entered into the respectivetables in the area of table entries. Additional background information as well as important SAP Notescompletes this section.The area of table entries offers the possibility to enter information. There may be one or more tables forentering information. Depending on the entries, the tree on the left hand side may change automatically(usually only after saving).




November 2007 21

4 Setup of Business Process MonitoringThe Setup of Business Process Monitoring is done in the Setup Business Process Monitoring session. Thissession can be found in the area Operations Setup / Solution Monitoring / Business Process

Monitoring within the SAP Solution Manager. In this session the monitoring customizing for all businessprocesses and interfaces belonging to this solution landscape can be maintained. There is only one Setup Business Process Monitoring session per solution landscape and at least one business process must existwithin that solution landscape.

Usually, the solution landscape and the business processes in the SAP Solution Manager have been set upduring a Solution Management Assessment (SMA) Service. However it is possible to set up the solutionlandscape and the business processes independently. Information about how to set up a solution landscapeand how to enter business processes will be found under a link which will be announced shortly.

It is not guaranteed that the existing landscapes with the corresponding business processes are up to date.Maybe the SMA and the entry of the business processes respectively have taken place a long time ago andsomething has changed in the customer’s core business processes. Therefore it is recommended to reviewthe system landscape and the business processes before setting up Business Process Monitoring.

4.1 Review Core Business ProcessesIn general, the SAP Solution Management Assessment (SMA) Service should be used to get the necessaryinformation regarding the system and solution landscape as well as the core business processes in the SAPSolution Manager.

However the business processes should be reviewed before setting up the monitoring in order to make surethat all data regarding the business processes and their related steps are available. This task requires thetechnical and functional knowledge of the flow of a particular business process as well as detailedinformation about the business process itself. Members of the application support team and members of thebusiness department should provide this knowledge.

It is therefore recommended to make use of the SAP Solution Management Optimization (SMO) Service for

Business Process Management (BPM). However, if the business process review is performed without anySAP assistance, make sure that you acquire the following information about:

• Processes (such as Internet Sales, Purchasing Goods, Creating Demand Plan, …)

• Process steps per process (such as create sales order, create purchase order, … )

• Processing types per process step (as dialog or as background)

• Monitoring Objects (such as specific background jobs, transactions, application logs, …)

• Interfaces (such as from ERP to ERP, from ERP to CRM, from ERP to BW, …)

• Make sure that the corresponding data is entered and hence available in the SAP Solution Managerfor all core business processes to be monitored. If necessary, complete the corresponding data.

4.2 Solution Support OrganizationThe first section of the Setup Business Process Monitoring session is dedicated to the Solution SupportOrganization. Within this section it is possible to build up the customers solution support organizationinvolving the different monitoring teams and monitoring roles. Regarding the concept of Business ProcessManagement it is essential to clearly define the roles and responsibilities for the members of the specialsupport teams. Those teams, respectively the members of those teams can be used later on to define ordocument escalation paths and error handling procedures for respective monitoring objects.The figure below shows the table where the different teams should be maintained.




22 November 2007

Figure 4-1 Solution Support Organization - Teams

After the teams are documented and saved, every single team will appear as a separate entry in the tree onthe left hand side. For proceeding, each entry must be selected and the required information needs to befilled out.Each team has individual team members and one or more roles which can be assigned.

Contact persons are created in the Solution Directory under path Operations Setup / SolutionLandscape / Solution Landscape Maintenance.

In SAP Solution Manager 4.0 you navigate via the push-button to an own maintenance

environment. There it is either possible to maintain contacts directly with the corresponding information orget existing users which were already maintained in transaction SU01.




November 2007 23

Figure 4-2 Contact maintenance with SAP Solution Manager 4.0

Monitoring roles can be assigned for every team. The following monitoring roles are available:

System Monitoring

Software Monitoring

Development Monitoring

Business Process Monitoring

Program Scheduling Management

Other Monitoring

Figure 4-3 Monitoring Roles

4.3 Business ProcessesFor all business processes that are already defined within the solution landscape, Business ProcessMonitoring can be set up. All existing processes are listed in a table. It is recommended to setup BusinessProcesses Monitoring for the core business processes of a company. A core business process is aprocess that is essential for business success. The sum of all core business processes is what generates thebulk of a company's revenue.

Business Process Monitoring is the proactive and process-oriented monitoring of acompany’s core business processes. The goals are to detect critical situations as early aspossible and to enable the customer’s support organization to respond to and solve problemsas fast as possible.

Referring to the definition of Business Process Monitoring at that point is to emphasize, that it makes lesssense to set up Business Process Monitoring for non-critical business processes. Business ProcessMonitoring is a real-time-monitoring tool. Only those business processes that are really business criticalshould be taken into consideration.

The following figure shows the selection of some business processes. The business processes will bemarked as planned until they are set to productive. This has to be done during the maintenance of thebusiness processes.

As of SAP Solution Manager 3.20 the whole Business Scenario that includes the business processmust be set to productive as well (within the Solution Directory).




24 November 2007

Setup of Business Process Monitoring for planned processes is possible but it is not possible toactivate the monitoring. Before activating Business Process Monitoring the process must be changedfrom planned to productive.

For every selected business process a sub-node will be generated after saving. The name is always BPMon: <process name>.

Figure 4-4 Business Processes

4.3.1 Business Process Steps and Interfaces

Once a business process is selected for monitoring the next step will be to define which business processsteps are relevant for monitoring. All steps of a business process are available in table ‘Steps of Business Process’. The names of the different steps together with the System ID, System Type, Release and Clientinformation of the system on which the step is performed are displayed here. It is not possible to change thatinformation in this table. Therefore it would be necessary to change the definition of the business processwithin the SAP Solution Manager.

For every selected business process step a respective sub-node will be created after saving the entries. Themonitoring will be set up individually for each business process step.




November 2007 25

All Interfaces belonging to that business process are listed in a separate table ‘Interfaces in Business Process’ . The table contains the information about the name of the interface, the interface technique, theinitial step, the final step as well as the sender and the receiver information. The configuration of InterfaceMonitoring will be done later.

For documentation purposes the tables ‘Description of Process’ and ‘Restart of Process’ are available. If the

business process has been described during the set up of the business process inside the SAP SolutionManager, the information would be displayed in table ‘Description of Process’ .Restart procedures are important in case of a breakup of the process. Employees from within the supportcan react immediately and re-start the process again. The restart procedures must be entered in table‘Restart of Process’.

The following chapters and sub-chapters will describe all possibilities that can be set up for a single businessprocess.

Figure 4-5 Business Process Steps

4.3.2 Monitoring Types

Monitoring Types are part of the functional scope of Business Process Monitoring. The below mentionedMonitoring Types are available:

Application Monitor (Throughput and Backlog Indicators, Data Consistency Checks, Mass Activity

Monitors, Due List Log, MRP key figures, User Exit)

Background Jobs (Jobs running on SAP Systems with an SAP Basis)




26 November 2007

Dialog Performance (Dialog transaction performance)

Update Error (V1 and V2 update errors from SM13 for specific transactions and programs)

Due List Log (messages for deliveries and billings)

Application Log (messages from the Application Log SLG1)

Document Volume (based on table call statistics in ST10)

Other CCMS Monitor (all alerts that are configured in the CCMS Alert Monitor)

Depending on what is executed during a specific business process step the relevant Monitoring Types mustbe selected. E.g. if a step is performed just via dialog transaction it makes no sense to select the MonitoringType Background Job or if there is no information about application logs regarding a step it makes no senseto select Application Log as a Monitoring Type.According to the selected Monitoring Types several sub-checks will be created after saving the check. Withinthose sub-checks the details concerning the specific monitoring objects e.g. transactions, background jobs,different tables etc. must be maintained. If there are monitoring objects it is possible to define alert objects e.g. thresholds for transaction performance or a start delay for background jobs.

4.3.3 Application Monitor

The Application Monitor is just one of many different Monitoring Types within the Business ProcessMonitoring. For using this Monitoring Type the respective entry for a specific Business Process step has tobe flagged and saved. In the then appearing sub-node you can load Monitoring objects from thecorresponding satellite system on which the Business Process step is executed. The latest Monitoringobjects are only provided if the latest ST-A/PI plug-in is installed on the satellite system. The Service Tool forST-A/PI is available via the SAP Service Marketplace Quick Link /PATCHES Entry by Application Group -> Plug-Ins SAP Solution Tools ST-A/PI.

Please ensure that the ST-A/PI is installed on the SAP Solution Manager system and on the respectivesatellite. In case of problems refer to SAP Note 915933.

The latest Throughput and Backlog Indicator functionality available with ST-A/PI 01J* is only workingproperly with ST-SER 700_2007_1. This is due to changes in the underlying architecture.

4.3.3.1 Real-time alert monitors and User Exit

Currently the following Application Monitors are available:

• Dialog Performance Monitoring on Function Code Level – which is especially interesting for the SAPNew Dimension products like CRM, SCM and SRM where complex transactions (e.g. CIC0, SDP94,BBPSC02) provide many different functions so that a general average response time evaluation is oflittle benefit.

• APO Demand Planning Application Log – which makes an automatic evaluation of the /SAPAPO/MC8K transaction possible

• MRP Key Figure – which provides an automatic evaluation of MRP runs with more sophisticatedmonitoring possibilities as of 4.7 Enterprise Edition

• Due List Log Monitoring – which provides an automatic evaluation of the due list logs for delivery orbilling. This functionality is identical to the “normal” due list log monitoring of Business ProcessMonitoring.

• Mass Data Monitoring for Mass Activity – which provides some automatic key figure evaluation forMass activities in IS-U, IS-T, IS-Banking and FI-CA, e.g. for Payment, Billing, Invoicing or DunningProposal Runs

• User Exit – which provides an easy possibility to include self-written monitoring collectors in the

Business Process Monitoring




November 2007 27

Monitor Available as of ST-A/PI release

Dialog Performance Monitor ST-A/PI 01F

APO Demand Planning Application Log ST-A/PI 01F

MRP Key Figure ST-A/PI 01F

Due List Log Monitoring ST-A/PI 01D

Mass Data Monitoring for Mass Activity ST-A/PI 01G

User Exit ST-A/PI 01E

With the user exit it is possible to define other monitoring objects specific to a transaction or application. It ispossible to develop own data collectors and display the alerts in the SAP Solution Manager together with therest of the standard monitoring alerts.

The monitoring object is defined by the customer according to their needs, and its parameters aremaintained to specify its details, i.e. object type, aggregation level.

After the new monitoring object has been defined, the next step is the definition of the alerts types that aredesired for that monitoring object, i.e. ‘maximal number of entries reached’ or ‘too many IDocs with errorstatus’.

The alert types are maintained in the customizing via the key figures. The parameters of those key figuresare specified in the customizing too, and they will define the output fields and the alert details, i.e. the alertmessage that will be displayed, timestamp of the alert, etc.

More detailed information about the different Application Monitor functionalities and a detailed description onhow to define self-written monitoring collectors for the user exit are explained in the documents ‘Application Monitor - Setup Guide ’ and ‘User Exit – Setup Guide’ respectively (URL http://www.service.sap.com/ AliasBPM Media Library).

4.3.3.2 Throughput and Backlog Indicators (TBIs)

As of ST-A/PI 01H a completely new set of Application Monitors has been introduced. While the alreadyestablished monitors described in section 5.3.3.1 are all evaluating specific logs or performance data thesenew monitors are considering (un-)processed documents in the SAP system and provide so calledThroughput and Backlog Indicators. These TBIs should especially provide

• Automated and early detection of application error situations and backlogs in the core businessprocesses

• Automated error and backlog analysis tools

Currently there are available monitors in the following application areas:

ERP Logistic

Sales and Services (e.g. Sales Documents, Invoices)

Warehouse Management (e.g. Transfer Requirements, Transfer Orders)

Inventory Management (e.g. Goods Movements)

Logistics Execution (e.g. Deliveries, Shipments)

Procurement (e.g. Planned Orders, Purchase Requisitions, Purchase Orders)

Manufacturing (e.g. Planned Orders, Production or Process Orders, Autom. Goods Movementsposted with error, Confirmation Pool errors)




28 November 2007

Plant Maintenance (e.g. PM/CS Notifications, PM/CS Orders)

CRM

Sales (Sales Documents, Business Activity Tasks)

Services (Service Documents, Business Activity Tasks)

Customer Interaction Center (Outbound Calls, Email Wort Items)

As an example we take the application area Procurement. In this area you could evaluate the following:

• The number of Planned Order with start today

• The number of Planned Orders with Start in the past

• The number of Purchase Requisitions item created (today)

• The number of open Purchase Requisitions items

•

The number of overdue Purchase Requisition items• The number of Purchase Order item created (today)

• The number of open Purchase Order items

• The number of overdue Purchase Order items

You can customize the selection options depending on the chosen Throughput and Backlog Indicator, e.g.the Purchase Order related TBIs can be evaluated per Purchasing Organization, Plant, Document Category,Item Category and Document Type.

For further information on the different TBIs refer to the document ‘Application Monitor - Setup Guide ’ (URLhttp://www.service.sap.com/ BPM Media Library).

4.3.4 Background Job

The background job monitoring should be part of a Job Scheduling Management concept (go tohttp://service.sap.com/solutionmanagerbp “Topic Area” to find a Best Practice document ‘Program Scheduling Management ’). Because of several restrictions regarding background job scheduling, e.g. timerestrictions, restriction of hardware resources (CPU, main memory, …) or existing dependencies betweendifferent activities (e.g. invoices can only be created after the corresponding goods issue is posted, or Back

Order Processing and Material Requirements Planning should not run at the same time) it is very importantto ensure the stable run of background jobs. A canceled background job should be identified as soon aspossible in order to react as fast as possible. Therefore it is also necessary to define restart procedures andescalation path.

A more detailed description (than provided in this document) on the subject what kind of alerts make senseor what kind of alerts are possible are discussed in the Best Practice document “Job Monitoring with SAPSolution Manager” which can be found on the SAP Marketplace http://service.sap.com/solutionmanagerbp “Topic Area”.

4.3.4.1 Monitoring Objects

Before setting up the monitoring the monitoring objects must be clearly defined. A monitoring object is a

single background job or a group of background jobs. There are four different possibilities to identify aspecial background job or a group of background jobs. This information needs to be maintained in the sub-




November 2007 29

node ‘Background Job’ below a business process step. All following information is stored in table ‘Job Monitoring Objects’ .

1. Job nameThis is the name of the background job as it is scheduled in SM37. It is crucial that this information iscorrect in order to ensure a proper identification of the job. It is possible to specify a group of jobs by

using ‘*’, e.g. if there are several jobs starting with the same name and just differ in some digits ornumbers.In addition to the job name it is possible to specify the name of an ABAP program or the name of anexternal program, e.g. if there are several jobs with similar names but just some of these jobs executinga specific program, need to be monitored. The other possibility is that a program is executed fromdifferent jobs but just the program in combination with a background job is relevant. See ABAP programor external program for more details.

2. ABAP programA background job can be identified just by the name of an ABAP program that is executed during a stepof the job. It is important to maintain the number of the step in which the program is executed. If thewrong step number is maintained, the job cannot be found.In addition to a program name a special variant can be selected that is used by the program. A variantmust not include ‘*’.

As described above, the name of the job is not mandatory while using program names but it could berelevant when monitoring special combinations.

3. External programIt is used the same way as described under ABAP program. It is important to maintain the step number.In addition external parameters can be specified. External parameters must not include ‘*’.

4. Special RulesRules for job names are applicable to identify groups of background jobs if the job names follow morecomplicated naming conventions, and cannot be mapped by the simple procedures mentioned beforebecause they are not flexible enough.For example, for step1 you are interested in the monitoring of the background jobs with thenames job1,..., job10 , whereas for step2 the background jobs with the name job11, ..., job20 arerelevant . Another example would be that the names of the jobs are build dynamically with data from atable. In this case it is not possible to define the name of the jobs prior their execution.

To use customer-specific job name rules, create include ZXDSWP_BPM_RULES in function moduleDSWP_BPM_JOBNAME_BY_CUSTOM. In this function module, you can find a short description of theway in which a rule must be implemented. Each rule must have a unique, triple-digit rule number. Whenrules are used, all other information specified for job identification during monitoring data collection willbe ignored. Reactivate the function module.

When rules are used, all other information specified for job identification during monitoring datacollection will be ignored.

The following table shows the fields with a short explanation of table ‘Job Monitoring Objects’ .

Select To use function “Check Job Identification” that fills out some fields of the tableautomatically (see 5.3.4.1.1)

Job Identifier Can be assigned individual, e.g. if the job name is very cryptically. This nameis used to represent the background job on a higher-level node. If not specifiedexplicitly, the job name is filled in automatically. If the job name is not specified,the name of the ABAP program is used. If neither job name nor ABAP programwas filled in, the name of the external program is taken automatically.

Job Name Name of the background job

Job Step. No. Step in which a program is executed. Mandatory when using programs

ABAP Program Name of the executed ABAP program




30 November 2007

Variant Name of a special variant

Job Schedule Indicates whether the job(s) is (are) scheduled on a weekly or on a monthlybasis.

Critical Job? To flag a job as critical job has influence on the data collection for this job. Per

default the data collection for critical jobs is 5 minutes and for non-critical jobsthe data collection is 60 minutes. Those values can be changed as describedin chapter ‘Data Collector Frequencies’.

User A user executing the job can be specified. If no user is maintained explicitly, allusers ('*') are taken into account.

Start Procedure The start procedure determines how the job is planned to run. In column ‘startprocedure’ there are four different possibilities to enter: 1=by time, 2=byevent, 3=by preceding job and 4=‘use job start condition’ (see 5.3.4.1.2)).

Planned Start Mandatory if the job is expected to start at a certain time (start procedure = "1")

Event ID Mandatory if the job is expected to be started by an event (start procedure ="2"). If applicable, also specify the event parameter. The preceding job must

remain blank. The event ID and parameter are optional parameter for startoptions "1" and "4".

Event Parameter Optional if the job is expected to be started by an event (start procedure = "2"),and if the event ID is also specified.

Preceding Job Mandatory if the job is expected to be started by a preceding job (startprocedure = "3"). The event ID and parameter must remain blank. Thepreceding job is an optional parameter for start options "1" and "4".

Parallel Jobs? If the processing is done in parallel it must be specified in the drop-down list.

External Program Name of an executed external program

External Parameter Can be used, when an external program is specified

Rule for Job Name Existing rule number when custom specific rules are used

4.3.4.1.1 Check Job Identification

The button offers the possibility to retrieve job information from the correspondingsatellite system. Therefore at least one of the fields for the job name, the ABAP program name, or the nameof the external program must be specified. The result will be shown in a pop-up with all the jobs that exist inthe corresponding system as of the day before yesterday until now and that meet the information that isalready specified. The following information is used as a filter:

• job name,

• job step number,

• job execution user,

• ABAP program name and variant,

• external program and parameters,

• name of the preceding job,

• event ID and parameter,

• job name rule.




November 2007 31

4.3.4.1.2 Start procedures in detail

In column ‘start procedure’ there are four different possibilities to enter.

1. The first one and probably the most common one is the start procedure by time . In this case the planned start time of the job is known, e.g. the job runs every day at 10 pm, and need to be entered in column

‘planned start’. The columns event ID and parameter or preceding job are optional parameters.

The planned start time should not be greater than the actual start time because no job would beidentified in that case.

2. The second start procedure is by event . In this case a system event triggers the scheduling of abackground job. Therefore the event ID and existing event parameters must be maintained. It is alsopossible to enter a start time. The other columns will be ignored.

3. If a job is triggered by a preceding job , the name of this preceding job is necessary. All other columns willbe ignored.

4. The last possibility is to choose the start procedure use job start start condition . The start procedure isused when the start time or any other start procedure of a job is not known. As soon as this job is scheduled

in SM37 the monitoring would recognize the job and starts the monitoring. This can also be used to monitor jobs that are scheduled via an external job scheduler. All other columns will be ignored.

4.3.4.2 Monitoring Schedule

Depending on what is entered in the parent table ‘Job Monitoring Objects’ in field ‘Job Schedule‘ theschedule on a weekly basis or the schedule on a monthly basis will be displayed.

4.3.4.2.1 Job Monitoring on a weekly basis

Figure 4-6 Weekly Schedule

Weekly Schedule (columns Mo, Tu, ... Su): Indicate the days of the week that are relevant for job monitoring. If not specified explicitly, the weekdaysMonday to Friday are set automatically. If data evaluation should be performed periodically during the day(i.e. a job runs more than once per day with a fixed frequency), the period (in minutes) must be specified.

Period [min]: A value is required only if the job monitoring schedule requires a period shorter than one day (less than 1440




32 November 2007

min). Daily or weekly monitoring schedules can be covered by selecting the desired week day(s). For jobsthat are monitored with start procedure "use job start condition" (option "4") this field should be left blank.

4.3.4.2.2 Job Monitoring on a monthly basis

This is relevant for jobs that are scheduled on a monthly basis or for jobs that are planned according to anexisting factory calendar.A factory calendar must be specified within the customizing on the corresponding satellite system, e.g. thestandard factory calendar is 01 where all days are working days except weekends and public holidays.Another example can be, that a factory calendar specifies all days as working days except Sundays andMondays.

If no factory calendar is specified every day of a month is taken as a workday.

With this option it is possible to monitor jobs that are running on a dedicated working day every monthrelated to the beginning or the end of a month, e.g. month-end closing is performed on the last working dayof every month. For this example the information that needs to be entered is for working day = 1 and relative to month’s… = end. It is possible to define on which month this entry is effective, e.g. January and the period

for the example above must be 1. If a job runs every other month the period must be 2 and so on.It is either possible to monitor just one specific day within a month or to monitor every working day of aspecific factory calendar.

Figure 4-7 Monthly Schedule

Factory Calendar ID: The valid factory calendar ID must be entered. If no ID is specified, each day of the month is regarded as aworkday.

The corresponding factory calendar has to be maintained in transaction SPRO on the respectivesatellite system NOT the SAP Solution Manager system.

Workday and Relative to Month's...:The workday on which the data evaluation should take place in terms of the number of days relative to theend or the beginning of the month must be specified. Otherwise, the day will be calculated relative to thebeginning of the month. If no number is specified, the data evaluation will take place on each working day inthe factory calendar. If "All working days" is specified, the "Relative to Month's#" field and the fields for thefirst month and the period are irrelevant, whereas the factory calendar ID is mandatory.




November 2007 33

1st Month:First month that needs to be taken into account to calculate the job monitoring schedule. Initial value is thecurrent month.

Period [# Months]:Time period in months to calculate the job monitoring schedule. If not specified explicitly, a period of one

month is taken.

Example:The job runs bimonthly, always on the last workday of the month. The relevant months are July, September,November, and so on:Workday = 1, Relative to month's end, 1st month = July, period = 2

4.3.4.3 Monitoring Alerts

The following description of the monitoring alerts shows the full range of possibilities. The question what kindof alert makes sense or what kind of alert is possible will be shortly discussed in chapter ‘Major JobMonitoring Cases’. A more detailed description on this subject will be discussed in a new Best Practicedocument “Job Monitoring with SAP Solution Manager” which will be available around August 2005. Socheck the SAP Marketplace http://service.sap.com/solutionmanagerbp “Topic Area” for new Best Practicedocuments.

The monitoring checks for alerts on the same day and the day before. Therefore thresholds must havea value between 1 minute and (2880 minutes – start time).

4.3.4.3.1 Start delay

If a background job has a defined start time, thresholds can be defined to generate a yellow or a red alert incase of a delayed start of the job. The time has to be entered in minutes.

If the job is scheduled via the start procedure ‘use job start condition’ only a ‘technical start delay’ willbe monitored. A technical start delay is the time that the job needs to wait for a free work process andis the shown delay time in transaction SM37. The time difference between the customized start timeand the actual start time would not be recorded.If you use the start procedure ‘by time ’ and the job starts earlier than the customized plannedstart time, then the job won’t be considered for monitoring, i.e. the data collector won’t find thecorresponding job!

4.3.4.3.2 End delay

The end delay can be monitored if a planned end time is known. The planned end time needs to be enteredin this table as well. The thresholds to generate a yellow or a red alert can be entered here.

It is not possible to monitor an end delay for periodic jobs and start procedure = 4 ('use job startcondition')..

4.3.4.3.3 Not started on timeAs mentioned above if you have chosen start condition ‘use job start condition’ you can only monitor atechnical start delay which is of no business value. Sometimes you do not know at what time exactly a jobshould run but you know that it should have been started at least until a certain time That is when you canuse the alert ‘Not started on time’. If a job was not yet started at the specified check time or only after thecheck time, an alert will be raised.

4.3.4.3.4 Out of Time Window

In some cases a job needs to run in a certain time window, e.g. the job needs to run between 3 am and 6 ambecause after 6 am the daily business is going to start. The time window has to be defined with a start timeand an end time. The threshold for a yellow and a red alert has to be entered in minutes. Alerts will be raisedif the job is (partly) running outside the specified time window, e.g. start before 3 am or finish after 6 am.




34 November 2007

Alerts won’t be raised if the corresponding job did not run at all or the job started before a customizedstart time, i.e. the start time defined as start condition for the job NOT the start time of the timewindow. Hence this type of alert is of special interest for all jobs where the start time is not known.Otherwise you could better use a combination of “Start delay” and “End delay”.

4.3.4.3.5 Maximum Duration

If the runtime of a job exceeds a specified duration a yellow or red alert respectively can be raised. Aprerequisite to get this kind of alert is that the job was started.

4.3.4.3.6 Parallel Processing

This tab strip does not appear if in the parent node under Job Details (see section 5.3.4.1) “No” waschosen in column “Parallel Jobs?”.

The alert for parallel processing should be specified if it is necessary that background jobs start in parallel. It

is not possible to monitor in general if certain background jobs are running at the same time. Jobs areconsidered to be parallel if they start within 2 minutes tolerance.The name of the job must be the same or wild cards ‘*’ can be used. In addition the number of jobs that runor should run in parallel can be specified. If this number is not known it can be evaluated if at least two ormore jobs started within the 2 minutes tolerance.

In case “Yes, number known” was chosen in column “Parallel Jobs?” in the parent node under Job Details(see section 5.3.4.1.1) two entries have to be made. One is the decision if the corresponding alert should bevaluated Red or Yellow. The other is to specify the exact number of parallel running jobs to be expected.This number has to be greater or equal to 2.

In case “Yes, but number unknown” was chosen in column “Parallel Jobs?” in the parent node under JobDetails (see section 5.3.4.1.1) the only entry to be made is the decision if the corresponding alert should bevaluated Red or Yellow.

4.3.4.3.7 Job Cancellation

The cancellation of a job can be specified with a yellow or a red alert.

4.3.4.3.8 Job Log Messages

It is possible to monitor the job log for messages, e.g. for messages belonging to a certain message class/idor for messages with a specified message number. At least a wild card (‘*’) must be entered here. This canbe done for all message types or for single message types like all error messages (‘E’) or all warnings (‘W’).More message types are available over the F4-help.The number of messages for a yellow alert as well as the number for a red alert needs to be defined at thatpoint too.

4.3.4.3.9 Job Log Content

This alert type makes it possible to monitor specific job log messages in a special way: Some applications(e.g. in IS-U) create messages that provide information about a processed document volume or a number oferrors that occurred during the execution of the background job. This volume information (counters),provided in the messages, can be used to trigger alerts. The volumes are accumulated if a job log messageoccurs several times.

The decision whether an alert needs to be created or not is based on the evaluation of all messages in the job log of the identified job. It does not matter how many steps the job has.

4.3.4.4 Major Job Monitoring Cases

In the following sub chapters a summarization of the most common cases for background jobs aredescribed. For every sort of job it is described what kind of alerts are possible. Moreover a typical examplefrom a business point of view should clarify the usage of those jobs.




November 2007 35

4.3.4.4.1 Singular job

The job starts at a certain point in time and it is running for a known period. The job is not periodic. The startprocedure can be any of the four different possibilities ‘by time’, ‘by event, ‘by preceding job’ or ‘use job start condition’ .

Possible and meaningful Alerts: start delay, end delay, maximum duration, job cancellation, parallel processing

Example:MRP-run, BOP-run

4.3.4.4.2 Periodic job

The job starts at a certain point in time and it is running for a known period. The job is periodic with a period< 24 hours (e.g. every 2 hours). The start procedure can be any of the four different possibilities ‘by time’, ‘by event, ‘by preceding job’ or ‘use job start condition’ . It is mandatory to define a start time.

Possible and meaningful Alerts: start delay, maximum duration, job cancellation, parallel processing

Note: It is not possible to define an ‘end delay’ alert for periodic jobs. Moreover it is important to know, that incase of a delayed start, the alerts are always assigned to the last customized and not yet satisfied runtime ofthe job. In case you have several customized jobs still waiting for a fitting job to be run and assigned, theminimum of the two is taken.

Example: periodical IDoc processing in batch mode, periodical creation of sales orders

4.3.4.4.3 Job with time window

The job should run in a given time window. We do not know the exact starting time. The job is runningnonrecurring or periodically. The start procedure can be any of the four different possibilities ‘by time’, ‘by event, ‘by preceding job’ or ‘use job start condition’ .

t

2 m 4 m1 m

2 m 4 m 6 m1 m

t

t

2 m 4 m 6 m1 m




36 November 2007

Possible and meaningful Alerts: maximum duration, out of time window, job cancellation, parallel processing

Example: Business Warehouse data extraction for reporting at a specific time, data reorganization during specificmaintenance time windows

4.3.4.4.4 Start time of the job is not known

In all cases where the start time is not defined (either because of an external job scheduler or the start timeis just not known), the job need to be defined with the start procedure ‘use job start condition’ . This could bea singular job or a periodic job. As soon as a job is scheduled within the SAP system (SM36, SM37) it is

considered for monitoring.Because the actual start of the job is not known it makes no sense to define a start time (otherwise anotherstart condition could be used). However it is possible to monitor the technical start delay, i.e. the delay timeshown in SM37. The technical start delay is the time spent between a background job is released and theactually start time (e.g. waiting for a free work process). For getting this technical delay it is necessary todefine an (arbitrary) value for a start delay.

Possible and meaningful Alerts:(technical) start delay, end delay, not started on time, maximum duration, job cancellation, out of timewindow (if time window defined)

4.3.5 Dialog Performance

Dialog Performance implies the monitoring of the dialog transaction performance of any transaction in theSAP System. This could be a standard transaction or an own developed transaction.


The monitoring object is the transaction itself. The customizing has to be done in node ‘ Dialog Performance’.In table ‘Transactions’ all transactions that are already configured to that business process step are listed.The relevant transactions need to be selected for monitoring. It is also possible to add or to removetransactions within table ‘Add/Remove Transactions’ . The monitoring can be performed per SAP instance.Therefore the respective instances have to be selected inside table ‘SAP Instances’ . All instances that are

maintained for a system are listed there. Table ‘Alert Types’ shows the dialog response time and all parts ofthe response time, like queue time, load and generation time, database request time and the front-end

given time window

t

2 m 4 m 6 m1 m

External job scheduler /start time unknown




November 2007 37

response time, that can be monitored. Those times that are relevant for monitoring have to be selected.After saving this node a sub-node ‘Performance Alerts’ will appear where the thresholds have to be entered.

Figure 4-8 Monitoring Objects – Dialog Performance


Each table in the sub-node ‘Performance Alerts’ corresponds to an alert type chosen in the higher-levelnode, and lists the combinations of specified transaction code and SAP instance.

For each combination of transaction code and instance that should be included in the monitoring, thethreshold values resulting in alert messages for changes from GREEN to YELLOW, from YELLOW to RED,back from RED to YELLOW, and back from YELLOW to GREEN have to be specified.

Since the Monitoring Object for Performance Monitoring is created on the satellite system, it might bepossible that the object already exists there. Therefore you can load the current threshold values from therespective systems via the button "Load thresholds from XYZ ".If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for thethreshold values were found for a certain transaction code, default values are set (indicated in column"Default").To transfer the threshold values for a single line from right to left, the copy icon can be used. To transfer allat once (all thresholds for all columns and tables) there is an additional button "Copy all".

Figure 4-9 Monitoring Alerts - Dialog Performance




38 November 2007

4.3.6 Update Errors

Changes to the data in an SAP system caused by a business process should be written to the database infull or not at all. If the operation is canceled while the transaction is being executed, or if an error occurs, thetransaction should not make any changes to the database. These activities are handled by the SAP updatesystem.

The SAP System makes a distinction between primary, time-critical (V1) and secondary, non-time-critical(V2) update errors. This distinction allows the system to process critical database changes before less criticalchanges.

V1 modules describe critical or primary changes; these affect objects that have a controlling function in theSAP System, for example order creation or changes to material stock.

V2 modules describe less critical secondary changes. These are pure statistical updates, for example, suchas result calculations.


Monitoring of Update Errors can be configured for online transactions and/or ABAP programs relevant in abusiness process. This is the object type. The name of the object is the name of a transaction or the name of

the ABAP program itself. If desired a user executing the transaction or the ABAP program can be specified.If no user is specified explicitly, all users (represented by '*') will be considered in monitoring data evaluation.

Figure 4-10 Monitoring Objects - Update Errors


Since update errors are usually very critical the default configuration is to raise a yellow alert as soon as oneupdate error occurs. This is valid for V1 and for V2 update errors. To raise a red alert for a V1 or a V2 updateerror a threshold must be specified.

4.3.7 Due List Log

A due list is a list that contains several entries (documents) depending on selection criteria. There aredifferent types of due lists in an SAP system of which the following three are most important: delivery (L),billing (F) and picking (K). The delivery due list can be directly accessed via transaction V_SA, the billing due

list via transaction V.21.In case of a billing due list, the list contains e.g. a number of sales documents that need to be billed. If the




November 2007 39

billing due list was processed previously and it is important to know which billing documents were createdfrom this billing due list, it can be displayed in the due list log for this billing run.


The monitoring object is the respective due list type. That can be ‘Delivery’ , ‘Billing’ or ‘Picking’ . If a certainuser is processing the due list, the name of the user can be specified here. If it is user independent a wildcard ‘*’ can be used. The aggregation level needs to be defined. This could be ‘per day’ , ‘per hour’ or ‘per log’ .

Figure 4-11 Monitoring Object - Due List Log


For the monitoring of due list log messages, four different alert types can be used:

‘DocumentCreation’refers to the status of the document creation itself. The alert rating (YELLOW or RED) will be raisedif no documents were created during a Due List run.

‘MinQuantityDocs’

refers to a minimum number of documents that should be created during a Due List run.The threshold values for the number of documents that result in a change from GREEN to YELLOW(or back) and from YELLOW to RED (or back) must be maintained.

‘TotalQuantityMsgs’refers to the total number of message created during a Due List run.The threshold values for the number of messages that result in a change from GREEN to YELLOW(or back) and from YELLOW to RED (or back) must be maintained.

‘DLLogMsgs’refers to specific due list log messages.The message type, the message ID and the number can be specified. It is also possible to use wildcards. The threshold values for the number of messages that result in a change from GREEN toYELLOW (or back) and from YELLOW to RED (or back) must be maintained.

Figure 4-12 Monitoring Alert - Due List Log




40 November 2007

4.3.8 Application Log

The Application Log provides an infrastructure for collecting messages, saving them in the database anddisplaying them as a log.

Situations can arise at runtime in application programs that must be brought to the attention of the user insome way. These are usually errors. It can also be useful to report a successful completion. The informationthat arises is called a message. The set of messages is a log. A log usually also has header information (logtype, creator, creation time, etc.). A transaction can generate several logs.The Application Log is not written consecutively but as a whole at one point in time.

4.3.8.1 Monitoring Objects and Alerts

The Application Log allows an application- or object-oriented recording of events. An object and any sub-object that belongs to it classify each event. The analysis of the logs is similarly object (or sub-object)oriented. The name of an object (and/or subobject) can be found in transaction /nSLG1 together with allother specific information to that log.

Depending on the transaction code that you might have maintained for the specific business process

step the F4 value help suggests some object/subobject combination.

The information about object and subobject to be monitored needs to be entered in node ‘Application Log’ aswell as the aggregation level for the monitoring data collection. The aggregation levels for an object – subobject combination are

• per log – the data collector evaluates customized thresholds for every single log file

• per hour – the data collector evaluates customized thresholds for the aggregate of all log files withinone clock hour

• per day – the data collector evaluates customized thresholds for the aggregate of all log files withinone calendar day

If a user is associated with the log the name can be entered here or it is also possible to use wild cards.

Figure 4-13 Monitoring Objects and Alerts - Application Log

It is possible to monitor for the total number of messages belonging to an object. Therefore the number ofmessages that raises a YELLOW alert and the number of messages changing from a YELLOW to a REDalert must be maintained.

It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs . Toconfigure the monitoring of critical application log messages, the relevant object-sub object combinationsneed to be selected. For each of these combinations the message type, the message ID and the messagenumber as well as the threshold values for the number of critical messages that are supposed to result in




November 2007 41

changes from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to usewild cards.

Figure 4-14 Monitoring Alerts - Application Log / Critical Messages

Note:

For both tab strips the following applies

• If just the threshold for a red alert is specified then the same threshold is copied into the column foryellow automatically

• If just the threshold for a yellow alert is specified the column for a red alert is automatically filled with99999999.

4.3.8.2 Alert evaluation remarks

The data collector evaluates all specified Application Log files (according to the customized aggregationlevel) per business process step that were newly written between two collector runs. Hence every Object – Sub-object combination within one business process step gets its own alert.

The only exception exists for GREEN alerts. If two or more Object – Sub-object combinations within onebusiness process step are configured of which only one combination exceeds thresholds for YELLOW orRED and all the others are GREEN, then the GREEN alerts are loaded into the session at all. This isbecause the underlying CCMS infrastructure considers “GREEN alerts” as no alerts at all. This circumstanceleads to another phenomenon that GREEN alerts never have a log name (Object, Sub-object) assigned,even if you monitor per hour or per day.

If several logs are evaluated GREEN within one business process step, there's just one (collective) GREENalert for all of them.

Example for an aggregation per day:

Every 90 minutes 50 messages of an <Object> <Sub-object> combination are written into the ApplicationLog. The collector runs with a frequency of 60 minutes. The threshold for YELLOW is 200 and for RED it is300. After 6 collector-runs the aggregated number of messages reaches 200 and a YELLOW alert is raisedduring the 7

thcollector run. After 9 collector-runs the aggregated number of messages reaches 300 and a

RED alert is raised during the 10th

collector run.




42 November 2007

4.3.9 Document Volume

This monitoring type Document Volume allows the monitoring of document volumes in terms of update,insertion, and/or deletion operations on single tables. The information is based on the table call statistics(transaction /nST10, report RSSTAT90).There are two types of alert monitoring: In the first one, “MaxRecordsAffected”, a number of operations isdefined which should not be exceeded, e.g. there shouldn’t be more than 10 deletions on table VBAK perday. The second one, minimum records, defines a number of table operations that should be at leastperformed. Example:In some company there are around 3000 sales orders processed on a normal working day before 3 pm. Ifthere are just 500 sales orders processed by this time on some specific day something might have gonewrong. Therefore it is possible to set a threshold, that at least 2000 updates on VBAK should be processeduntil 1pm.

4.3.9.1 Monitoring Objects and Alerts

Any table can be included into the monitoring and there can be also different tables assigned to onebusiness process step. For every table an operation (insert, delete or update) needs to be selected. Thenumber of records to raise a YELLOW and a RED alert as well as any clock hour and the respective daysmust be maintained at that point.This is valid for the tables "MaxRecordsAffected" and "MinRecordsAffected ”.

Figure 4-15 Monitoring Objects and Alerts - Document Volume

4.3.10 Other CCMS Monitors

With other CCMS Monitors it is possible to assign any CCMS monitoring tree element (MTE) to a businessprocess step. Therefore it is necessary to call transaction RZ20 in the Satellite System and to open a monitorthat contains the required alert(s).The name of the monitoring tree element (MTE) can be found by choosing F1. The MTE name needs to becopied into the corresponding column of the table below (Figure 5-21 Other CCMS Monitors).Under column Monitor Name it is possible to assign an individual name.

The MTE used for monitoring should be a MTE on the lowest leaf-level, i.e. on attribute level. If aMTE of a higher branch-level (collective MTE) is chosen then the current and open view in the

Collector run: 1 2 3 4 5 6 7 8 9 10

New Application Log entries:

Total for the day:

50

50

50

100

50

150

50

200

50

250

50

300




November 2007 43

graphics will show the right alerts but it isn’t possible to work on these alerts within the BusinessProcess Monitoring session as the alerts are not replicated there.

In order to load the threshold values that are currently valid in the corresponding system, the button

can be used.If successfully retrieved, the values are filled in the right-hand columns. If no active settings for the thresholdvalues were found these columns remain empty.To transfer the thresholds values for a single line from right to left double-click on the copy icon.

Figure 4-16 Other CCMS Monitors

Unlike all other Monitoring Types the Other CCMS Monitoring provides the opportunity to assignMTEs from other Systems than the one system the actual business process step is assigned to.

As an example you could be interested in monitoring the availability from a Portal system that possesses noCCMS but is included as one business process step in your business process. Now you could use one MTE

in the CCMS of the SAP Solution Manager to monitor the heartbeat of the Portal. You could then assign thecorresponding alert via Other CCMS Monitoring to business process step running on the Portal system.

4.3.11 Analysis & Monitoring Tools

It is possible to specify analysis transactions or URL addresses (including file directories) per monitoringobject. In case of analysis transactions these should be used to analyze errors or problems either locally inthe SAP Solution Manager system itself (Call Option “1”) or directly in the respective satellite systems (Call Option “2”). Per default some standard transactions are maintained, e.g. transaction SM37, that provides a job overview in an SAP System, is maintained for Background Jobs or transaction SLG1 to have a look intothe application log.It is also possible to add new transactions; this could be standard transactions or customer self-writtentransactions.




44 November 2007

Figure 4-17 Analysis & Monitoring Transactions

On the second tab strip it is possible to specify an URL which should be called in order to further analyze thegiven problem. This is especially interesting if you have some knowledge documents linked to a portal. Youdefine a Short text and the URL to be called.

For web pages to be called, specify the full URL, e.g. http://help.sap.com . For content available on fileservers specify the full file path, using the nomenclature: file://\\\<server>\..., e.g.file://\\\server1\operations_documents\operations-handbook.txt

Figure 4-18 Analysis & Monitoring URL

The specified transactions or URLs will be available in the form of buttons within a business process stepwhen using the monitoring later on inside the Business Process Monitoring Session . By pressing these

buttons (e.g. ), the user will jump directly into the corresponding transactioneither in the SAP Solution Manager system (here: SAT) or the connected satellite system (here: CT1) for

further analysis. For URLs the push-button (e.g. ) contains the Short text (limited to20 characters) from the Set-up session and leads the user to the defined URL in a newly opened browserwindow.

4.3.12 Monitoring Activities

Monitoring activities should be set up for every Monitoring Object within a business process step. Allmonitoring objects defined within a business process step are listed here. To ensure effective monitoring and




November 2007 45

efficient problem resolution the responsibilities should be assigned and problem resolution proceduresshould be defined as described in the following table. Some information is taken from the previous node‘Solution Support Organization’.

Monitoring Team Defines the team that is responsible for monitoring the relevantMonitoring Object. Use value help [F4].

Person Resp. Defines the Person who is responsible for monitoring the MonitoringObject. Use value help [F4].

Frequency Describes how often the responsible person should process the requiredmonitoring activity.

Start Time Describes at which time the responsible person should process therequired monitoring activity.

Problem Indicator A description about what indicates a problem.

Error Handling Describes how to react on problems or errors, i.e. how to solve theproblem/correct the error.

Escalation Path Describes the escalation path in case that the person responsible could

not solve the problem. Persons who can be contacted should bemaintained here.

Additional information related to this business process step can be entered in the tables ‘MonitoringActivities’, ‘Error Handling’, ‘Restart of Step’ and ‘Escalation Path’. Those information would be valid for thewhole business process step and helps users who have to carry out the monitoring and who are not sofamiliar with that particular business process.

4.3.13 Notifications

Notifications can be set up for the whole business process or for each business process step individually.There are two types of notifications: Workflow notifications and Support notifications. Workflow notificationsallow sending messages in case of alerts to a specified Recipient. This could be an e-mail or SAPOffice mail.Support notifications allow setting up a service desk message in case of an alert. The information entered forthe service desk message serves as a template. The service desk message can be created manually orautomatically.

On business process level it is possible to define notifications for the whole business process i.e. as soon asthe business process gets an alert status, notifications will be triggered. Alternative notifications can bedefined for every Monitoring Type individually, e.g. all alerts related to all background jobs of the businessprocess are forwarded to a defined e-mail address.Notifications defined on business process step level will override the configuration made on businessprocess level for this particular step.

4.3.13.1 Workflow Notification

Sender Must be a user within in the monitoring client of SAP Solution Manager. Thisuser can be even a system user without any roles or profiles, but the usermust have a valid e-mail address that is known by the used mail-server

RecipientAddress

Depending on the Recipient Type the recipient name is required. This couldbe any e-mail address, an SAP user name in the same system, a RemoteSAP name or a shared distribution list. In case of an SMS you need to enter“SMS:<cell phone or pager number>”

Reci. Type There are currently 5 different Recipient Types: U (e-mail), K (for SMS andPager), B (SAP user name), R (Remote SAP name) and C (shareddistribution list).




46 November 2007

No. of YellowAlerts

Number of YELLOW alerts that may occur before an automatic notification istriggered

No. of Red Alerts Number of RED alerts that may occur before an automatic notification istriggered

Max Wait Time[h] Once the maximum wait time [hours] has elapsed, a notification is created,even if the thresholds are not exceeded

RED Only To restrict this mechanism only to red alerts the flag in column 'RED Only'must be set.

Detailed Triggers a long text for e-mails or SAPOffice mails, e.g. name of the solution,name of the business process step, …)

The subject of an e-mail is always the same no matter if you flagged the “Detailed” column or not. It containsthe following information <Alert level> <Monitoring type> <Solution name> <Process>, as an example “RedBackground Job – SOLMAN DEMO - Business Process 1”.

The content of the e-mail itself differs a lot:

Without “Detailed”:

Step 1 Table VBSK : Number of inserted rows ( 22 ) exceeded maximum ( 3 )

With “Detailed”:

Solution no. : CTW/0120007986/0003152100_0120007986

Solution name : GAIER - 04.04.2005 -BPM

Process : Prozess1 Dokument Volume

Process step : Step 1

System : CT1

Monitoring type : Doc. volume

Alert level : Red

Alert date : 20051005

Alert time : 150052

Alert message : Table VBSK : Number of inserted rows ( 30 ) exceeded maximum ( 3 )

In case that you encounter alerts but no email is sent please refer also to SAP Notes 944737 and 949361.

In case that you want to use a Shared distribution list you have to define it in the Business Workplace(transaction SO01 or SBWP) in the monitoring client of SAP Solution Manager. In general you can useevery Recipient Type that is available for the Business Workplace. The following table is taken from

http://help.sap.com:

Recipient Type Example of Recipient Address Indicator Address name Anna Wilson -

SAP user name Wilsona B External address Edward Miller A Private distribution list Favorite colleagues P




November 2007 47

Shared distribution list Archiving project C Fax number USA 123 456 7890 ( <country code - fax number>) F Internet address [email protected] U Organizational object Purchasing (Organizational unit) H Business object Office folder J Remote SAP name: C11:000:wilson ( <System name:Client:Name>) R X.400 address g=anna;s=wilson;o=c11;ou1=m000;p=company;a=dbp;c=us X LDAP address C=usa/o=c11/ou=m000/cn=… D

4.3.13.2 Support Notifications

Priority Defines the priority of the Support Notification.

Queue Defines the support component on which the message is put. This

component must exist within the service desk.

Processor Defines a default processor who should process the message. Theprocessor must be known within the service desk and must be SAP username who is defined as a Business Partner with role “Employee”.

Text Template Text templates can be defined that will then be available for service deskmessages manually created for alerts.

Automatic Support Notifications will be created automatically depending on the alertthresholds.

Reporter Necessary when service desk messages are created automatically. Must bea SAP user name who is defined as a Business Partner with role “General”.

Num. of YELLOWAlerts

Necessary when service desk messages are created automatically, e.g. after10 yellow alerts a service desk message should be created.

Num. of REDAlerts

Necessary when service desk messages are created automatically, e.g. after5 red alerts a service desk message should be created.

If in addition to queue, processor, priority and reporter either one of the columns “Num of YELLOWAlerts” or “Num of RED Alerts” is filled with a value the automatic Support Notification creation isconfigured. In case that both columns are filled with a value the automatic Support Notificationcreation works with a logical OR operation. Hence, with the figures in the table above the systemwould create a .Support Notification if there either exist more than 9 yellow alerts OR more than 4 redalerts for which no Support Notification has been created yet.




48 November 2007

4.3.14 Interface Monitoring

Interface Monitoring, as part of Integration Management is an important part in the concept of BusinessProcess Management. The definition of Integration Management is as follows:

Integration Management comprises all necessary procedures to ensure the reliable and safeoperation of all interfaces included within the business processes with respect to consistency,security, and recovery.

In order to meet business requirements a Business Process and Interface monitoring concept shouldconsider the following monitoring types:

• Error Monitoring: This includes the monitoring of all error situations documented within the system.Error situation can be identified by the occurrence of error messages or error statuses during themessage processing. Purpose of this monitoring is to recognize and resolve error situations.

• Throughput Monitoring: This includes the monitoring of processing volumes for business processsteps and interfaces. Purpose of this monitoring is to recognize a business critical increase or decrease

in the processed data volume.• Backlog Monitoring: This includes the monitoring of backlogs within the solution. Purpose of this

monitoring is to recognize growing backlogs which indicate that the business process is not functioningproperly or that end users bypass the defined business process.

• Performance Monitoring: This includes the monitoring of processing times. Purpose of this monitoringis to identify a business critical increase in processing times.

The aim of this section is to outline possibilities on how to setup an automated monitoring and alerting forimportant interfaces. The Interface Monitoring functionality is available within SAP CCMS and can beimplemented within SAP Solution Manager’s Business Process Monitoring.

The focus of this section is on the usage of Business Process Monitoring within SAP Solution Manager forthe data exchange of connected systems. In general an automated Interface Monitoring is possible for thefollowing interface technologies:

ALE/EDI

qRFC

(tRFC)

We use an “Order Management & Execution” scenario as an example which contains two businessprocesses: “Outbound Telesales with CRM Sales Orders” and “Processing Purchase Orders”.




November 2007 49

Figure 4-19 Interface Monitoring in SAP Solution Manager’s Business Process Monitoring

In the business process “Outbound Telesales with CRM Sales Order” the monitoring for qRFC is set up. Foran end-to-end approach the monitoring needs to be setup for the involved queues on the SAP CRM sendersystem as well as the SAP ECC receiver system. In the above example on the sending system SAP CRMthe queue group “ORDERS_CRM->ECC(400)” for outbound direction and the queue group“ORDERS_CRM->ECC(800)” for inbound on SAP ECC are created. For details refer to section “Automated

qRFC-Monitoring”.

In the business process “Processing Purchase Orders” IDocs of message type ‘MATMAS’ are send from theSAP ECC sender system to the SAP MM receiver system. To monitor the IDoc flow from end-to-end themonitoring on the sending and the receiving system needs to be set up for the IDoc processing. For detailsrefer to section “Automated ALE/EDI-Monitoring”.

4.3.14.1 Standard Monitoring Objects in local CCMS

The Interface Monitoring functionalities are based on the Computing Center Management System or CCMSAlert Monitor (transaction /nrz20) and could be used independently of the SAP Solution Manager, if needed.It was introduced that it will be distinguished between the central CCMS located on the SAP SolutionManager System and the local CCMS that is placed on every satellite system.

qRFC queueIDocs of type

MATMAS




50 November 2007

The data for Interface Monitoring will be stored in the local CCMS as the Interface Monitoring is already partof the SAP CCMS Alert monitoring. The approach of this section is to outline the setup procedure for aselective interface monitoring for messages involved in your core business processes. The standard CCMSmonitors show an ALE/EDI IDoc Monitoring for all message types in inbound and in outbound direction. Thestandard monitoring group can be found in transaction /nrz20 SAP CCMS Technical Expert Monitors ->System / All Monitoring Segments / All Monitoring Context ALE/EDI <SID>(CLIENT) Log.sys ‘name of

logical system’ .

Figure 4-20 ALE/EDI Standard Monitoring Groups

At that point it is not possible to define for a dedicated business process step what kind of message is sentvia the respective interface.

The same applies also for qRFC-Monitoring and tRFC-Monitoring. All information regarding inbound andoutbound data will be stored in standard monitoring groups. This can be found in transaction /nrz20 -> SAPCCMS Technical Expert Monitors System / All Monitoring Segments / All Monitoring Context Transactional RFC and Queued RFC.




November 2007 51

Figure 4-21 qRFC/tRFC Standard Monitoring Groups

For Business Process Monitoring it is necessary to specify the required interface in more detail. Therefore itis possible to define specific monitoring objects for ALE/EDI-Monitoring and for qRFC-Monitoring. FortRFC-Monitoring this is not possible so far.




52 November 2007

4.3.14.1.1 Specific ALE/EDI-Monitoring

The customizing of ALE/EDI monitoring objects can be done with transaction BDMO. With transaction BDMOit is possible to create new monitoring objects only for a specific message type and to activate themaccordingly. This can be done either in inbound or in outbound direction or both. If two SAP systems areinvolved you need to do the customizing on both the sending system (outbound direction) as well as the

receiving system (inbound direction).

System wise, these objects are considered as customizing. Therefore, they have to be set up in thedevelopment system and from there transported via the quality assurance system to the productive system.

To create a new monitoring object the button ‘Create/activate monitoring objects’ in the entry screen oftransaction BDMO must be used.

In the following screen the new entry needs to be entered and set to active.

Figure 4-22 BDMO - New Entry

In some cases it might be necessary to re-call transaction BDMO to have the new entry available. In theentry screen it is now possible to select the newly created monitoring object. The following screen will popup:

Figure 4-23 BDMO - Customize Monitoring Object




November 2007 53

The specific message types for the inbound and/or outbound direction of an interface need to be specified. Ifone direction should not be monitored explicitly, it can be left blank. It is also possible to specify more thanone message type if needed. The system type of the partner system needs to be maintained as well as thesystem number from the partner (see transaction WE20).

In section ‘Period’ you can specify the number of days for the age of the IDocs that should be included into

the evaluation.In field “Wait time status changes OUT” or field “Wait time status changes IN” you can specify a waiting timein minutes to change a status. If this time has not elapsed since the last status change, the previous status isused and not the last one.

Use cases might be the following:a. Monitoring on the number of IDocs which are in status 03 for longer than 60 minutes. Those IDocs

are sometimes processed on an hourly basis. Therefore it makes only sense to evaluate the IDocs instatus 03 if they have not been processed since longer than 60 minutes.

b. Monitoring on the number of IDocs which are in status 51 for longer than 30 minutest. This way thealerts are suppressed for IDocs which are “temporarily” in error status 51 because their status mightbe changed by the next processing retry. But if this is not the case after 30 minutes they are countedas IDocs in status 51.

In field “Days until now” you can specify the age for IDocs in days which won’t be included into theevaluation.

The Monitoring Object is created in a development system and is then regularly transported into theproductive environment. Hence the Partn. number that is specified in the development system alreadyhas to be the connected productive system which should be monitored later on.

If the same interface should be monitored on the sending system as well as on the receiving system, it isnecessary to create the respective monitoring objects on both these systems. One for the outbound directionand the other for the inbound direction.

To actually create the monitoring objects then choose Monitoring Object / Start all in the entrance screen

of transaction BDMO. This will create new entries in the CCMS (transaction /nrz20) and start the datacollection for the ALE/EDI alerts but just once. The scheduling of a periodic background job needs to bedone on every satellite system in transaction /nrz21 Technical infrastructure method execution activate background dispatching .

This way the program ‘RBDMONI_CCMS_IDOC’ is scheduled in the background job‘SAP_CCMS_MONI_BATCH_DP’, per default on an hourly basis. Depending on your requirements you canchange the frequency to enable a more real-time alerting.

Please test the runtime of this program during peak time and evaluate the additional system loadgenerated before transporting to your productive system!

After the program execution the created monitoring objects are generated in SAP CCMS:




54 November 2007

Figure 4-24 ALE/EDI Specific Monitoring Objects

Area 1: IDocs are generated via change pointers. Therefore the number of open change pointers is relevantfor monitoring.

Area 2: An IDoc changes its status during the message processing. In the SAP CCMS the main statuses aregrouped together depending on the direction.

For outbound direction the following groups are available containing the listed statuses:

For inbound direction the following groups are available containing the listed statuses:

Area 3: If the IDoc processing is done via tRFC you can monitor the number of remote calls waiting to be

processed. The selection works for the RFC destination specified for the involved partner in the partner

Area1

Area 2

Area 3




November 2007 55

profile. To check the processing mode navigate to transaction WE20, select the partner number, select themessage type and click on details.

Figure 4-25 tRFC MTE for ALE processing

Per default the threshold values for the SAP CCMS MTEs are usually set too high and need to beadjusted either directly within SAP CCMS or within the SAP Solution Manager.




56 November 2007

4.3.14.1.2 Automated qRFC-monitoring

As per the outlined example the interface technology used between the SAP CRM and SAP ECC systems isqRFC. For both the outbound and the inbound queues the following monitoring key figures can be set up tobe alerted if:

The queue status is blocked

The number of entries in the queue group exceeds a defined value There is at least one entry in the queue group that is older than a defined time period

The qRFC Monitoring in the satellite system is set up via transaction RZ21 -> Technical infrastructure -> Configure qRFC monitoring groups . SAP Note 441269 provides the detailed procedure.Since the monitoring objects created on the satellite system are considered as customizing, they have to becreated on the development system first and from there be transported to the productive system.

A. Creation of a setting owner

Figure 4-26 qRFC-Customizing / New Entry

B. Creation of a queue group

A new entry can be entered here and set to active by a capital ‘X’. Observe that only one owner can beactive at a time. To navigate in transaction RZ21, always mark the respective line in the table on the righthand side and then choose the next sub-check in the check tree on the left hand side.

a) Customizing for qRFC monitoring of blocked queues

With the following customizing you can get alerted whenever there is a queue in status “blocked”which is part of the specified queue group.

In the sub tree ‘Queue Groups’ the owner need to be selected and a name for the queue groupneeds to be given.

For a minimal customizing only the name, as it should appear in CCMS, must be entered (MTEclass) and the type of queue must be defined ( Inbound/ Outbound).




November 2007 57

Figure 4-27 qRFC – Customizing / Queue Groups

b) Customizing for qRFC monitoring by the number of queue entries Besides an alerting on blocked queues it is possible to get notified if the number of queue entriesexceeds a certain threshold value. Specify the function module“SALK_CRM_QRFC_QUEUE_ENTRIES” in field “Exit FM”.

Figure 4-28 qRFC – Customizing / Queue Groups – by Queue Entries

c) Customizing for qRFC monitoring by the queue age

If you have the need to get alerted not only if there is a queue within the queue group that is blockedbut also if there is at least one queue that is older than a specified threshold value you can specifyan exit function module “SALK_CRM_QUEUE_AGE” for the outbound direction(“SALK_CRM_QUEUE_AGE_INBOUND” for the inbound direction) with the exit parameter“MAXIMUM_QUEUE_AGE” and a parameter figure, e.g. 3 for the age of the queue.




58 November 2007

Figure 4-29 qRFC – Customizing / Queue Groups – by Queue Age

C. Assignment of queues to a queue group

In the sub tree ‘Queue Assignments’ the owner, the name of the queue group need to be selected and theactual name of the queue to be monitored must be specified. It is allowed to use ‘*’. Also, the client must bemaintained.

By setting an ‘X’ in field “Deact.Monitor” you can exclude specific queue(s) from being monitored within thespecified queue group.

Different queues can be grouped together by specifying the first characters of their name followed by a‘*’. Example: name the group “R3AD_SALES*” to group all queues that start withR3AD_SALESDO0000001001, R3AD_SALESDO0000001002 etc.

Figure 4-30 qRFC - Queue Assignments




November 2007 59

D. Alert Value Shifts (optional) For each of the specified queue(s) and/or a specified status a function module can be named to beexecuted. This entry is optional and provides the possibility to activate an individual evaluation before thealert creation. You can change the color of the reported alerts in accordance with your needs for each ofthese queues, e.g. from red to a lower level. If, for example, STOP alerts for queues whose names beginwith CRM_SITES* are not important to you, you can change the value of the alert from red (alert generated)

to green (message reported, but no alert generated). The function module requires the interface of theexample module SALK_SMPL_ALERTSHIFT_CALLBACK.

Use the F1-Help for details on the different fields.

E. Activation of the qRFC monitoring

After saving the newly created monitoring objects will be created by an hourly job. To trigger this job, chooseTechnical Infrastructure / Method execution / Activate Background Dispatching in transaction RZ21.

Per default the data collection is done with function module ‘SALK_TRFC_DATENKOLLEKTOR’ triggeredvia background job ‘SAP_CCMS_MONI_BATCH_DP’ which is executed on an hourly basis.

If you need to get alerted more often you can change the execution mode for method“CCMS_tRFC_Collector” in transaction RZ21. Click on Display overview and navigate to method“CCMS_tRFC_Collector”.




60 November 2007

Change the execute method in tab Control from “Periodically in background process” to “Periodically indialog process”.

Please test the runtime of this program during peak time and evaluate the additional system loadgenerated before transporting to your productive system!




November 2007 61

F. Results of the qRFC Monitoring within SAP CCMS

Figure 4-31 qRFC Specific Monitoring Object

G. Statuses of blocked queues

The MTE for the number of blocked queues summarizes queues in different statuses.

The following statuses are immediately identified as “blocking”:

CPICERROR (for Inbound/Outbound, error text available)

SYSFAIL (for Inbound/Outbound, error text available)

STOP (for Inbound/Outbound, no error text)

ANORETRY (for Inbound/Outbound, error text available)

WAITSTOP (for Inbound/Outbound, error text available)

ARETRY (for Inbound/Outbound, error text available)

RETRY (always for inbound, for outbound as of qRFC version 6.10.040, error text available)

SYSLOAD (for outbound, up to qRFC version 6.10.033, no error text)

The following statuses are identified as “blocking” if they remain unchanged for longer than 30 minutes:

READY (for inbound/outbound, no error text)

RUNNING (for inbound/outbound, no error text)

WAITUPDA (for outbound, no error text)

EXECUTED (for inbound/outbound, no error text)

MTE for blockedqueue(s)

MTEs for blockedqueue(s) and age

alerts

MTEs for blockedqueue(s) and queue

entries




62 November 2007

4.3.14.2 Implement Interface Monitoring in SAP Solution Manager

The setup of interface monitoring will be done in the Setup Business Process Monitoring session . At leastone business process with process steps on different systems and defined interfaces must be availablebefore it is possible to configure interface monitoring.In node Interface Monitoring all existing interfaces for the corresponding business process and the selected

steps are displayed, i.e. all pairs of consecutive business process steps on different systems. To customizethe interface, the required interface must be selected for Monitoring . To differentiate between the interfaces,Interface Name (per default “<Sender SID> ><Receiver SID> ”, the Interface Technique (e.g. ALE/EDI,qRFC), Initial Step (i.e. usually the business process step that sends information), Final Step (i.e. usually thebusiness process step that receives information), Sender and Receiver (SID respectively) are displayed. TheInterface Name and the Interface Technique can be changed manually.After saving the entries for every interface that is selected for monitoring a respective sub-node Interface “<Name of the Interface>“ (<Interface Technique> ) will be created.

Figure 4-32 Setup Interface Monitoring in SAP Solution Manager

This sub-node is either used for loading Monitoring Objects from the connected local CCMS (for ALE/EDI,qRFC and tRFC this is described in the following sub-sections) or the sub-node is empty for all otherInterface Techniques .

4.3.14.2.1 Implement ALE/EDI Interface Monitoring

In case an interface is selected for monitoring with the Interface Technique ALE or EDI a sub-node appearsInterface “<Name of the Interface>“ (<ALE or EDI> ). Now it is necessary to assign the previously createdmonitoring objects from the satellite system to the respective interface. Therefore the objects must be loadedinto the session. This happens with the push-button: Reload CCMS: ALE Mon Objects . All ALE/EDImonitoring objects available on the satellite systems (i.e. Outbound-objects on Sender side and Inbound-

objects on Receiver side) are loaded into the session. This itself is not visible at first but when the F4 valuehelp is either used for SID or ALE Monitoring Object then all reloaded Monitoring Objects appear and can beselected for monitoring. Copy the selected objects and save.




November 2007 63

Figure 4-33 Use value help to assign ALE/EDI-monitoring object to an interface

A new sub node Alert Monitors appears. All Outbound alerts for the Sender system and all Inbound alerts forthe Receiver system, which are related to the Monitoring Objects selected in the node above, are loaded intothe session. Additionally all the corresponding threshold values are loaded from the local CCMS as well. Thenext step will be to decide what kind of alert should be selected for monitoring. To transfer the thresholdvalues for a single line from right to left, double-click the copy icon between them. To transfer all thethreshold values at once, choose "Copy All". It is also possible to change the threshold values for the alertsmanually. After saving the new values are transferred to the local CCMS of the monitored system.

Figure 4-34 Selection of ALE/EDI related alerts




64 November 2007

4.3.14.2.2 Implement qRFC Interface Monitoring

In case an interface is selected for monitoring with the Interface Technique qRFC a sub-node appearsInterface “<Name of the Interface>“ (qRFC ).Now it is necessary to assign the previously created monitoringobjects from the satellite system to the respective interface. Therefore the objects must be loaded into thesession. This happens with the push-button: Reload CCMS: Cust. Queue Grp . All qRFC monitoring objects

available on the satellite systems (i.e. Outbound-objects on Sender side and Inbound-objects on Receiverside) are loaded into the session. This itself is not visible at first but when the F4 value help is either used forSID, Customizing Queue group name or Queue Type then all reloaded Monitoring Objects appear and canbe selected for monitoring. Copy the selected objects and save.

Figure 4-35 Assign qRFC-monitoring object to an interface

A new sub node Alert Monitors appears. All Outbound alerts for the Sender system and all Inbound alerts forthe Receiver system, which are related to the Monitoring Objects selected in the node above, are loaded intothe session. Additionally all the corresponding threshold values are loaded from the local CCMS as well. Thenext step will be to decide what kind of alert should be selected for monitoring. To transfer the thresholdvalues for a single line from right to left, double-click the copy icon between them. To transfer all the

threshold values at once, choose "Copy All". It is also possible to change the threshold values for the alertsmanually.




November 2007 65

Figure 4-36 Selection of qRFC related alerts

4.3.14.2.3 Implement tRFC Interface Monitoring

For tRFC Interfaces no dedicated monitoring objects are available so far. It is just possible to monitorCPICERR, SYSLOAD and SYSFAIL errors generically. It is not possible to distinguish between different RFCdestinations. In case an interface is selected for monitoring with the Interface Technique tRFC a sub-nodeappears Interface “<Name of the Interface>“ (tRFC ).Under this sub-node another node Alert Monitors appears. There push the button: Reload CCMS: tRFC Alerts . All three default tRFC monitoring objects onthe satellite systems (i.e. Outbound-objects on Sender side and Inbound-objects on Receiver side) areloaded into the session. To transfer all the automatically loaded threshold values at once, choose "Copy All".It is also possible to change the threshold values for the alerts manually.

Figure 4-37 Configure tRFC monitoring

4.3.14.2.4 Interface Monitoring Setup for other interface technologies

It is possible to assign any CCMS monitoring tree element (MTE) to a business process step or an interfacewithin System- or Business Process Monitoring of the SAP Solution Manager, e.g. if the interface technologyis other than ALE/EDI, qRFC or tRFC.

Figure 4-38 Selection of a Interface technique other than ALE/EDI, qRFC or tRFC




66 November 2007

Therefore it is necessary to call transaction RZ20 in the Satellite System and to open a monitor that containsthe required alert(s).The name of the monitoring tree element (MTE) can be found by pressing the F1 key.

Figure 4-39 Retrieval of the MTE name in SAP CCMS

The MTE used for monitoring should be a MTE on the lowest leaf-level, i.e. on attribute level. If aMTE of a higher branch-level (collective MTE) is chosen then the current and open view in the

graphics will show the right alerts but it isn’t possible to work on these alerts within the BusinessProcess Monitoring session as the alerts are not replicated there.

The MTE name needs to be copied into the field “MTE (Monitoring Tree Element)”.Under column Monitor Name it is possible to assign an individual name.

In order to load the threshold values that are currently valid in the corresponding system, the button

can be used.

If successfully retrieved, the values are filled in the right-hand columns. If no active settings for the thresholdvalues were found these columns remain empty.

To transfer the thresholds values for a single line from right to left double-click on the copy icon.

Figure 4-40 Other CCMS Alert Monitors

In the chapters mentioned above (regarding the setup of ALE/EDI, qRFC and tRFC monitoring) thereappeared a second tab strip Other CCMS Alert Monitors in the sub-node Alert Monitors. In case adifferent Interface technique was chosen, the table Other CCMS Alert Monitors is the only one thatappears.




November 2007 67

4.3.15 Generation of Customizing

The node ‘Generate Monitoring Customizing’ appears by default for every business process. Before carryingon with the generation some information needs to be checked:

1. The information in node Data Collector Frequencies has to be complete and correct

2. The information in node Local RFC Destination for Data Collection has to be complete and correct

During the generation of the customizing the entries will be checked for plausibility and transferred intointernal tables for later use. This will be done by pressing the button:

When this is done for the first time, a new session called Business Process Monitoring Session with thename of the respective business process will be generated in background, where the actual activation of theBusiness Process Monitoring has to be done. This session is located in the Operations Area of the SAPSolution Manager and will be described in a later chapter.

Nothing happened so far on the connected satellite systems, the information is stored only on the SAPSolution Manager system.

The actual customizing can be changed at any point in time. If there is already an active monitoring thechanges would have no effect to the current monitoring. To activate the new monitoring customizing themonitoring of the business process must be deactivated and reactivated.

In table Protocol information about the generation will be displayed. This could be just messages, warningsor error messages. Typical problems are described in chapter FAQs.

Next to the “Generate” button is another button which can be used after theinitial Activation (described in section 5.4). This simplifies and speeds-up the Generation and Activationprocedure (as it is performed in just one step) once you do some minor changes to your monitoring.

The button “Generate + Activate Monitoring” only appears if the Business Process Monitoring Session

for the business process has been created. This session is created after to the Operations part of thesolution has been accessed for the first time after the monitoring customizing as been generated.

4.3.16 Data Collector Frequencies

Table ‘Data Collection Periods’ lists all R/3 based SAP systems that are used in at least one of the businessprocesses chosen for monitoring together with a monitoring type. For each combination of system andmonitoring type a suitable time period for the runs of the corresponding monitoring data collector has to bespecified.

If no entries are made, default values will be used automatically. The minimum allowed value is 5 min. Othervalues must be a multiple of 5.

Due to technical reasons the data collection time periods for the following monitoring types cannot bechanged:

Dialog Performance

Update Error

Other CCMS Monitor

Document Volume




68 November 2007

4.3.17 Local RFC Destination for Data Collection

For technical reasons, the Business Process Monitoring function requires a local RFC destination within theSAP Solution Manager system.In table ‘Local RFC Dest. for Data Collection’ a green symbol for the status indicates that a suitable RFCdestination already exists.

A double-click on the Destination field (here the entry BPM_LOCAL_200) leads you directly to thecorresponding RFC connection in transaction SM59 so that this connection can be easily tested. Adouble-click on the User name (here CSMREG) leads you directly to corresponding user profile in

transaction SU01.

If no RFC destination is available (red symbol in column Status) it is possible to create it in this node. You

enter the user, press the -button and enter a new password for this user.

It is important that the entered user has the authorization profile S_CSMREG. For detailed informationregarding profile S_CSMREG, refer to the latest version of SAP Note 455356. Normally, the usedRFC-user is either called CSMREG or SM_BPMO, which must be defined in the SAP SolutionManager system.

4.4 Activate / Deactivate Business Process MonitoringThe activation as well as the deactivation of Business Process Monitoring has to be done for every business

process separately in the Business Process Monitoring session.Every business process has his own session that can be found in the area Operations / SolutionMonitoring / Business Process Monitoring within the SAP Solution Manager.For every business process that exists and for that the customizing was generated at least once, arespective Business Process Monitoring session exists.This session will be entered over the graphical interface in the process overview. A little icon in the upper leftcorner of the box indicates the availability of a business process monitoring session. By clicking on that iconthe session will be entered. If the session is initial the icon looks like a little match.

If the monitoring is active, the icon has the status of the highest alert inside the session.

4.4.1 Activation

After entering the session for the first time, only node Activation is available. Before activating the BusinessProcess Monitoring the retention times of the monitoring data and the language of the alert messages needto be specified.For the retention times the number of days can be entered for:

How long data is to be kept that is not aggregated




November 2007 69

The time, after which the aggregation of monitoring data starts (the number of days must be smalleror equal to the time not aggregated monitoring data is to be kept)

The time, the aggregated monitoring data is to be kept

It is possible to define the language in which the error messages are brought up. By using the F4-help thecurrently available languages are displayed.

The protocol displays information regarding the status of the Business Process Monitoring and who activatedor de-activated for the last time. Warnings end errors are displayed as well. More information about the errormessages can be found in chapter ‘Errors, Warnings and Messages – Activation’.

Pressing the button will activate the Business Process Monitoring.

Figure 4-41 Business Process Monitoring - Initial screen

After the activation an additional node Business Process”process_name” appears. This node includes allsteps of a business process as sub-nodes for which the monitoring was customized. Every step comprisesall Monitoring Objects that are set up for monitoring.

When a business process is activated initially, monitoring data will be collected from the time the processwas activated. Depending on the frequencies and the set up of the monitoring types it takes some time untilthe first results will be displayed in the session.

If a business process has been deactivated and activated again, all information that have not beenreorganised so far will be displayed in the session.

The session will be refreshed as soon as it will be opened again or by using the refresh button inside thenode of a monitoring object.




November 2007 71

5 Use of Business Process MonitoringThis chapter will explain how to use Business Process Monitoring once it is active for one or more businessprocesses. Within SAP Solution Manager this can be found in the area Operations / Solution Monitoring /

Business Process Monitoring. This follows the strategy of the SAP Solution Manager that everything thatneeds to be customized is done in the operations setup area and the usage of what was set up has to bedone in the operations part of SAP Solution Manager.The navigation within the graphical overview will be described as well as the interpretation and operationwith the monitoring alerts inside the Business Process Monitoring Session. Furthermore the handling withthe service desk messages and the functionality of the SL Reporting will be introduced.First of all the rating strategy will be explained in the following chapter.

5.1 Alert RatingIn order to evaluate a situation for any defined alert, there are four different possible alert ratings. Theimportance of an alert is indicated by the corresponding color of the alert rating. For instance, there is agreen alert for monitoring without any problems and red alerts for very critical situations. The following table

lists the different alert ratings:

ALERTS / WARNING MESSAGE

Alert!Very critical situation

Status is not defined.Critical situation

Warning.Checking necessary.

O.K.

Figure 5-1 Possible alert ratings

The alert rating enables focusing on critical systems, significant business processes, major business processsteps and interfaces. The rating for each alert that appears is depending on the alert customizing that wasmade within the Setup Business Process Monitoring Session. It shows the alerts from high priority to lowpriority.

This definition is valid for all monitoring areas. Alerts will be found in the software overview, in the overviewof the hardware and, what this document focuses on, the business process overview.

It is also possible to change the alert hierarchy as it is shown in the table above. Once you enteredtransaction DSWP you can navigate via the menu Settings Solution Monitoring Evaluation Hierarchy.There the level of the gray alert in the alert hierarchy for the solution can be changed.




72 November 2007

5-2 Changing the Evaluation Hierarchy of Alerts

5.2 Graphical OverviewWith SAP Solution Manager release 4.0 the graphical overview is a html format which can also be published

in the SAP Enterprise Portal or even as an ordinary website. Please refer to SAP Notes 705947 and 778933respectively.

It might happen that you get a pop-up window every time you request a html graphic for the first time.

You can avoid this by entering transaction SICF, execute (F8) and push button .Then go to default_host /sap/bc/solman/defaultuser and double-click on it. Enter a user in theAnonymous Logon Data, e.g. user CONTENTSERV or SOLARSERVICE as mentioned in SAP Note752570.

All business processes that are defined in the SAP Solution Manager within your solution landscape can befound in the process overview under Operations / Solution Monitoring / Business Process Monitoring.They are assigned to a business scenario, e.g. like Purchasing or in ths case Sales .

Figure 5-3 Current status of Business Process in Business Scenario




November 2007 73

This is the highest level of the graphical view. On this level a little icon in the upper left corner in the box ofthe business process indicates the overall status of an active business process. Always the highest alert willbe reported. The refresh period of the monitoring objects can be customized in the settings of the solution.

It is also possible to jump to the hardware overview or to the software overview. The overall status ofthose different views is displayed as well in the status bar.

There are two possibilities to navigate:

1. By clicking on the alert itself the Business Process Monitoring session is called as described in chapter‘Business Process Monitoring Session’.

2. By clicking on the name of the process, the process with all its underlying business process steps isdisplayed as seen in the following picture. There are alert icons for business process steps, for interfaces

and for systems. The alerts indicates again the highest alert of the corresponding component, e.g. thealert for a business process step indicates the highest alert of the customized monitoring objects of thatbusiness process step. The detailed view is shown in the following chapter.

Figure 5-4 Current status on Business Process level




74 November 2007

Unlike earlier releases it is also possible to change between Open Alerts and Current Status onBusiness Scenario Level and Business Process level. Compare the Figures above.

5.2.1 Alerts related to a Process Step

All customized alerts for a business process step are displayed in the detailed view of the SAP SolutionManager. Every Monitoring Object has an entry with the current status, a description of the alert and thereturn value. It is possible to toggle between the current view and the view that shows the open alerts.

The first screen that appears shows all monitoring types related to the respective business process step.

Figure 5-4 Monitoring objects related to a business process step

The current status of the alert types for the respective monitoring type (here for object BackgroundProcessing) are displayed in the following screen:

Figure 5-5 Current status on Business Process step level

When toggling to the open alerts view all alerts that have not yet been processed are displayed. Those alertsare not confirmed yet. It is also possible to confirm the alerts directly in that view.

Figure 5-6 Open alerts on Business Process step level




November 2007 75

It is only possible to jump into the Business Process Monitoring Session from the current view.

5.3 Business Process Monitoring Session

The Business Process Monitoring Session was already introduced in one of the previous chapters when itcame to the activation of a business process. It was already mentioned but it should be repeated at thatpoint: Every business process has its own Business Process Monitoring Session. This chapter focuses on detailed information on alerts related to an active business process.

Figure 5-7 Business Process Monitoring Session

Starting point is node Business Process “process name” . This node provides some general informationabout the business process. The rating is propagated from the sub nodes.The table ‘Business Process Steps’ and the two text fields ‘Description of Process’ and ‘Restart of Process’ cannot be changed. That information is coming from the Setup Business Process Monitoring Session. Table‘Business Process Steps’ lists all business process steps defined for the business process. The processsteps that were chosen for monitoring are indicated in column 'Monitoring?' .The text ‘Description of Process’ provides the description of the business process (if available) and the text‘Restart of Process’ the description of how to restart the business process in case of a breakdown (ifspecified). More detailed information is available in chapter ‘Escalation Path and Error Handling Procedures’.

Due to technical reasons it may happen that the monitoring session has a delay of up to five minutescompared to the alerts in CCMS, which is shown in the graphic.




76 November 2007

5.3.1 General Monitoring Object Information

All monitoring objects for that Business Process Monitoring was set up are displayed as sub-nodes directlyunder a business process step. The structure of these sub-nodes is the same. The highest level of amonitoring object shows the table Monitoring Activities .This information is helpful to find a team or a person who is responsible for a particular monitoring object.

The time when the object should be checked as well as the frequency how often it should be checked can benoted here.For people who are not familiar with this monitoring object, information about a problem indicator, the errorhandling procedures and an escalation path is necessary to react fast and effective on problems that cameup.

Figure 5-8 Monitoring activities

5.3.2 Alert Information

The actual alerts with the detailed monitoring information are located under each monitoring object. Themonitoring object can be for example a background job. In this example the alert types start delay andmaximum duration are set up. Every alert type will have an own node. The structure of those nodes is for allalert types the same and consists of the following areas:

Alert List

Alert Confirmation

Support Notification

Alert Configuration

Analysis Transactions

The topics will be introduced in the following chapters.

5.3.2.1 Alert List

The table Alert List lists all open and confirmed alerts available after the activation of Business ProcessMonitoring. Alerts that are already reorganized according to the settings made in a previous node are notdisplayed anymore.The table is divided into columns that only display messages and information related to the correspondingalert, and into columns that deal with the documentation of changes in accordance to solve the problem. Thesecond part will be described during the next chapters. The first part is shown in the following graphic:

Figure 5-9 Messages related to an alert

Selection Select box for Alert ConfirmationRating The first column indicates the rating of the alert. The highest rating will




November 2007 77

determine the rating for the node. Confirmed alerts are not taken intoaccount. The rating is not to be set manually.

Confirmed by/on/at Information about the confirmation

Date Specifies the date when the data collector was running that detected thealert.

Time Specifies the time when the data collector was running that detected thealert.

<ObjectInformation>

Depending on the monitoring object different information is displayedhere, e.g. in case of Background Job Monitoring the name of the job, theactual start date and time as well as a user will be displayed. In case ofthe monitoring object Application Log the log number and object/ subobject will be displayed, etc.

Alert Message Information about what caused the alert can be found.

5.3.2.2 Alert Confirmation

5.3.2.2.1 Alert Confirmation in the session

To confirm an alert it is possible to check the box in column Selection and choose the button

.

After saving, the alert disappears from the Alert List and will be considered as a green rating. Neverthelessthe rating icon in the first column will not change. Confirmed alerts can be displayed via the push-button

Unless all red and/ or all yellow alerts are confirmed the rating of the whole node will not be changed.It is possible to change all yellow or all red alerts at once. Therefore the following must be chosen

.

It is also possible to hide all green alerts in order to minimize the Alert List overview.

To help track the changes the user who confirmed should enter a comment in column Comment . The personwho confirmed the alert will be entered with date and time automatically in column Conformed by/on/at .A statistic about how many alerts have been confirmed can be generated when using Service LevelReporting.

Figure 5-10 Alert Confirmation in the session




78 November 2007

5.3.2.2.2 Alert Confirmation in the graphic

It is also possible to confirm open alerts directly in the graphic. Just mark the open alerts that should be

confirmed and push the button.

Figure 5-11 Alert confirmation in the graphic

The confirmation is synchronized with the session, i.e. if the session is entered after the confirmation in thegraphic then the corresponding open alerts are also confirmed in the Business Process Monitoring sessionand vice versa.

It is also possible to confirm all alerts at once by confirming the parent node in the graphic.

Figure 5-12 Confirmation of parent node in the graphic

5.3.2.3 Service Desk Message

If the problem cannot be located or solved it is also possible to create a Service Desk Message. ServiceDesk Messages can be created directly in the Business Process Monitoring session. It can also be createdautomatically as soon as an alert comes up. This is depending on the customizing in the Setup BusinessProcess Monitoring session.The advantage of the Service Desk Message is that a lot of information is already filled-in like the involvedsolution, the business process and the business process step as well as information about the monitoringobject, alert timestamp and the alert message that was created for this alert. The information about theprocessor and message component will be used from the customizing information of the Setup Business

Process Monitoring session or if not available, it can be filled in here.

Manual creation:

Mark the alerts for which a Service Desk Message should be created. It is possible to include several alertsof the same alert type in one Service Desk Message. To create a support notification the following buttonmust be used:

A dialog box appears where the notification can be edited and sent.

After saving the Service Desk Message the column Msg. Status changes to ‘Open’ and the notificationnumber will be entered in column Service Desk Msg. It is possible to display and to edit the notification by

double-clicking on the notification number. The current status will be always displayed in column Msg.Status .




80 November 2007

5.5 Service Level ReportingService Level (SL) Reporting as part of the Service Level Management of the SAP Solution Manager offersthe possibility to report on essential system data and related alerts on a weekly basis based on theEarlyWatch Alert information and it is possible to include data that comes from Business Process Monitoring.Service Level Reporting will be set-up and activated by use of the Service Level Reporting Session.

It is possible to set up ‘Service Level Reporting’, based on the historic alerts from the ‘Business ProcessMonitoring’ session. This reporting enables for example, to compare agreed Key Performance Indicatorsweekly, between your IT- and operating department. Service level management (SLM) is the discipline ofusing proactive methodology and procedures to ensure that adequate levels of service are delivered to all ITusers in accordance with business priorities and at an acceptable cost.

The goal of using SLM is to:

•Improve your IT staff’s understanding of business process requirements

•Improve IT service quality in terms of:

Availability

Performance

Accuracy

Reporting

•Increase business department satisfaction

•Improve the motivation of your IT staff

•Facilitate internal resource allocation planning.




November 2007 81

6 Additional Information for Using SAP SolutionManager

6.1 SAP Solution Manager Roles and AuthorizationsThere exists an extensive SAP note that gives a detailed description about available roles and authorizationsin the SAP Solution Manager. In the attached Excel files of the SAP note you will also find an overview aboutnecessary roles and authorizations depending on which scenario you are going to use in the SAP SolutionManager.

SAP Note 834534 “SAP Solution Manager Roles in Release 4.0”

6.2 Service Desk ConfigurationThe Service Desk in the SAP Solution Manager provides a central message-handling tool for a customer’s

solution landscape. Messages or Support Notifications created in the satellite systems can be automaticallytransferred to the Service Desk in the Solution Manager where processors can either solve the problem orforward the message to SAP. In addition to that, it is also possible to create messages in the BusinessProcess Monitoring Session for monitoring-objects-related alerts that can be handled via the Service Desk.In order to use the Service Desk functionality of the SAP Solution Manager the Service Desk has to be setup explicitly in the SAP Solution Manager system. Since the Service Desk uses CRM functionality thisincludes the implementation of CRM-customizing as well as the setup of RFC destinations in order totransfer messages between the various systems, the creation of business partners and the generating of theIBase. For details please see the 'Implementation Guide for Service Desk in the SAP Solution Manager itself.

For the creation of Business Partner the corresponding user needs the role SAP_SUPPDESK_ADMIN.

6.3 Workflow ConfigurationA workflow notification is a standard method within the CCMS that can trigger so called ‘auto-reaction-methods’ such as sending e-mails or calling a pager via SMTP (Simple Mail Transfer Protocol). The SAPsystem transfers those e-mails to a specified mail server. Since SAP Release 6.20 fax and SMS/pagingmessages can also be sent.The SMTP functions must be activated on the application server of an SAP system. In this case the SAPSolution Manager System is the sending system. For those alerts that are built within the satellite systemsadditional agents have to be installed as explained later in that chapter.

To make use of this feature within the SAP Solution Manager some configuration has to be done.

6.3.1 Prerequisites

• The customizing, that means the set up of SAPconnect, has to be done in the client where themonitoring will be set up.

• Every user who wants to use the auto-reaction-methods must have a defined Internet mail addressin his user profile. This address is for receiving e-mails and is also used as the senders address.This could be any e-mail address in the WWW but it is depending on the settings for the mail server(For example: Only e-mail addresses that are known within the specified mail server are allowed).

6.3.2 SAPconnect Administration

The customizing of SAPconnect has to be done with transaction /nSCOT . In this case, SAPconnect has tobe configured in the monitoring client of SAP Solution Manager.After calling the transaction the view must be ‘system status’. If this is not the case, the view has to bechanged in the menu bar under View->system status .

Under the node INT there must be an entry ‘SMTP’. This should be already available in every SAP system.




After a double click on this node the general node data has to be entered. If it is not explicitly mentioned herethe default values can be taken.

General information

− The ‘maximum waiting time for repeat send attempt procedure’ should be set to 1 minute.

−

The ‘Node in use’ must be ticked.SMTP Connection

− The ‘mail host’ and the ‘mail port’ to which outbound mails are to be transferred need to be specified(If a user has not maintained an Internet mail address in his master record the mail host is takentogether with the user name as a senders address. It could be also necessary to define the defaultdomain that can be found under ‘Settings’ in the main menu. Usually it is the same address as themail host).

− A code page has to be selected e.g. 1100 SAP internal, like ISO 8859-1

Supported address types

− The Internet flag must be ticked and under ‘Set’ there is the address area where a ‘*’ has to be

entered.All e-mails which should be sent from the SAP system are put into a queue. A periodically runningbackground job processes those e-mails. To set up this job the following has to be done:

− Changing the view to ‘jobs’ in the menu displays the jobs that are already scheduled (displayed as acalendar icon).

− With Job -> Create, a new job can be specified.

− The cursor has to be set on ‘SAP&CONNECTALL’ variant and ‘Schedule Job’ must be chosen.

− ‘Schedule periodically’

− A time needs to be specified (e.g. 5 minutes) and then ‘Create’

See also SAP Note 455140 for more information.

If paging/SMS messages are also to be sent via SMTP:

− Choose "Set" adjacent to "Pager(SMS)".

− Specify address areas of recipient addresses that are to be reached via this node (usually "*" if allpaging/SMS messages are to be sent via SMTP).

− For "Conversion into Internet Address", enter the domain of the paging/SMS server or paging/SMSprovider. The local part of the Internet address is generated automatically by the system. Theaddress then has the form "SMS=+recipientnumber@domain".

BPM - Setup Guide

Documents

Transcript of BPM - Setup Guide