manage operations for s ap scheduling agreements

BP_Scheduling_Agreements_V30.doc – 10.06.2009

Best Practice for Solution Operations

Manage Operations for SAP SchedulingAgreements

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUS

customer publishedDATE VERSION

June 10, 2009 3.0

SOLUTION MANAGEMENT PHASE SAP SOLUTION

Operations & Continuous Improvement Best Practices for Solution Operations

TOPIC AREA SOLUTION MANAGER AREA

Application & Integration Management Business Process Operations

Best Practice for Solution OperationsManage Operations for SAP for Automotive

© 2009 SAP AG page 2/40

Table of Contents1 Management Summary 4

1.1 Goal of Using This Best Practice 41.2 Alternative Practices 41.3 Staff and Skills Requirements 41.4 System Requirements 51.5 Duration and Timing 51.6 How to Use This Best Practice 51.7 Best Practice Procedure 6

1.7.1 Preliminary tasks 61.7.2 Monitoring concepts 61.7.3 Business Process Monitoring in SAP Solution Manager 61.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 7

1.7.4.1 Application monitor 81.7.4.2 Background job 91.7.4.3 ABAP dump collector 91.7.4.4 Dialog performance 101.7.4.5 Update errors 121.7.4.6 Due list log 131.7.4.7 Application log 141.7.4.8 Other CCMS monitors 151.7.4.9 Analysis and monitoring tools 161.7.4.10 Monitoring activities 181.7.4.11 Notifications 18

1.7.5 Business Process Monitoring process 202 Business Process Monitoring for Scheduling Agreement 21

2.1 Sample Scenario 212.2 Business Process Scheduling Agreement 22

2.2.1 Business process step 1: Receive demand 232.2.1.1 Description 232.2.1.2 Monitoring requirements 242.2.1.3 Monitoring objects in SAP Solution Manager 242.2.1.4 Further monitoring objects without SAP Solution Manager 242.2.1.5 Monitoring without SAP Solution Manager 25

2.2.2 Business process step 2: Create delivery 252.2.2.1 Description 252.2.2.2 Monitoring requirements 262.2.2.3 Monitoring objects in SAP Solution Manager 262.2.2.4 Further monitoring objects 272.2.2.5 Monitoring without SAP Solution Manager 27

2.2.3 Business process step 3: Create transport 272.2.3.1 Description 272.2.3.2 Monitoring requirements 282.2.3.3 Monitoring objects in SAP Solution Manager 282.2.3.4 Monitoring without SAP Solution Manager 28

2.2.4 Business process step 4: Create invoice 28


© 2009 SAP AG page 3/40

2.2.4.1 Description 282.2.4.2 Monitoring requirements 292.2.4.3 Monitoring Objects in SAP Solution Manager 302.2.4.4 Further monitoring objects 312.2.4.5 Monitoring without SAP Solution Manager 312.2.4.6 Scheduling of background jobs 31

3 Further Information 323.1 Troubleshooting 323.2 Related Best Practice Documents 323.3 Literature 32

4 Appendix 344.1 Examples for recommended Monitoring Objects 34

4.1.1 Example Background Job Monitoring 344.1.2 Example ABAP Dump Monitoring 35

4.2 Background Jobs 36


© 2009 SAP AG page 4/40

1 Management Summary

1.1 Goal of Using This Best Practice

This Best Practice helps you to set up a Business Process Monitoring concept for your SAP Automotivesolution. The concept aims to define procedures for business process-oriented monitoring and error handlingand escalation procedures for your business process evaluated receipt settlement. These procedures intendto ensure a smooth and reliable flow of this core business process so that your business requirements aremet.

This Best Practice gives orientation for defining suitable application oriented monitoring objects in order todetect any irregularities or deviations from an ideal business process flow or to detect error situationsconcerning a core business process at an early stage.

This Best Practice contains the recommended approach from SAP which uses whenever possible SAPSolution Manager for the monitoring functionalities. But even if you do not use SAP Solution Manager werecommend to follow the procedures described in this document as much as possible in order to ensure asmooth and reliable flow of your business processes as well as an appropriate response in case ofunforeseen errors.

1.2 Alternative Practices

You can have SAP experts deliver this Best Practice on-site by ordering an SAP Solution ManagementOptimization (SMO) service for SAP Business Process Management (BPM). This service is exclusivelyavailable within SAP’s support engagements SAP MaxAttention and SAP Safeguarding. If your companycurrently does not have any support engagements with SAP, it is also possible to get assistance by SAPexperts from SAP Consulting. In this case, please contact your local SAP Consulting representative.

1.3 Staff and Skills Requirements

To implement this Best Practice, you require the following teams:

Application management team

This team creates the ERP Business Process Monitoring concept and consists of experts from several areasof your company: Business department Solution support organization (for example the basis support or the application support) Implementation project team

Business process operations team

The business process operations team will be responsible for applying the resulting procedures derived fromimplementing this Best Practice. They include the following groups: Persons designated to perform business process oriented monitoring and ensure that the process runs

smoothly (e.g. the business process champion for each business process) All parties in your solution support organization and IT department involved in monitoring focused on the

application aspects (application support, development support, Job Scheduling Management)


© 2009 SAP AG page 5/40

SAP technology operations team

All parties in your solution support organization and IT department involved in monitoring focused on thesystem administration side (program scheduling management, software monitoring team, systemadministration team, including the system administrator)

Business process champion

The business process champion is the person in the business department that is responsible for thesuccessful execution of the business process. He coordinates all activities necessary for the businessprocess. Therefore, he is usually responsible for the escalation paths in case of problems. He often servesas a second level in the escalation procedure, if the application monitoring team needs to escalate anissue.

More information about roles and responsibilities of these teams can be found in the super-ordinate BestPractice General Business Process Management, which you can obtain through SAP Solution Manager orthe SAP Service Marketplace, quick link /BPM.

Necessary or useful trainings

SM300 Business Process Management and MonitoringE2E300 End-to-end Business Process Integration and Automation Management

1.4 System Requirements

In order to monitor business processes running in your SAP for Automotive solution via SAP SolutionManager, the SAP basis release of the systems to be monitored have to be at least 4.6C. To have alldescribed monitoring objects available in SAP Solution Manager, the add-on ST-A/PI01L has to be installedon the SAP for Automotive system.

1.5 Duration and Timing

Duration

Creating a Business Process Monitoring concept takes approximately one week per business process. Implementing the Business Process Monitoring concept takes approximately an additional week.

Timing

The best time to apply this Best Practice is during the planning phase or during the implementation phase ofyour SAP solution.

1.6 How to Use This Best Practice

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

Marketplace. This document explains the procedures you should use to create a general BusinessProcess Management concept. This includes the definition and documentation of the core businessprocesses, definition of monitoring objects, definition of monitoring activities (including error handlingprocedures, monitoring tools, and monitoring frequencies), the definition of communication and escalationprocedures, and the assignment of responsibilities.


© 2009 SAP AG page 6/40

At the beginning of chapter 2 you will find a typical flow chart of the core business process explained inthis Best Practice. It is intended to be used as a guideline for writing down your company specific processdocumentation.

In chapter 1.7.4 you find further information that is relevant for more than one scenario. In caseinformation from the generic part is relevant for a specific business process step in one of the scenarios,you will find a clear link to the corresponding chapter in the generic part.

1.7 Best Practice Procedure

1.7.1 Preliminary tasks

Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in thesystem: Complete all installation and post-installation actions and procedures including customizing Ensure that the initial download has been successfully executed Apply all SAP recommendations from SAP service sessions and any SAP recommendations resulting

from customer problem messages Implement all current SAP support packages upon availability

1.7.2 Monitoring concepts

The monitoring procedures proposed for each business process step are the core of this Best Practice. Themonitoring procedures help you to ensure that the technical processes meet the requirements for stability,performance, and completeness. These procedures cover monitoring for the five areas:1. Error monitoring2. Performance monitoring3. Throughput monitoring4. Backlog monitoring5. Data consistency monitoring

For each of the business process steps you will find the following information: A detailed functional description of the process step Identified monitoring requirements for the process step Defined monitoring objects, alerts, and selection criteria Description of error handling procedures and restartability

General monitoring activities that are valid for all or most scenarios are described in the generic part inchapter 1.7.4. Recommendations for performance monitoring can also be found in this chapter. Theperformance of the most important steps of your core business processes should be monitored on a regularbasis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP forAutomotive solution is generally the same. Therefore, you will only find specific performance monitoringrecommendations on selected business process steps.

1.7.3 Business Process Monitoring in SAP Solution Manager

Business 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 alltechnical and business application specific functions that are required for a steady and stable flow of thebusiness processes.


© 2009 SAP AG page 7/40

The core business processes that are implemented in an SAP for Automotive system or other software andoperated by a company are of particular importance, and Business Process Monitoring is intended to ensurea smooth and reliable operation of the business processes and, thereby, that the core business processesmeet a company’s business requirements in terms of stability, performance, and completeness. SAP SolutionManager provides a graphic to visualize a company’s (distributed) system and solution landscape and allrelated business processes. By using Business Process Monitoring, it is possible to define and customizealert situations from a basic set of configurable alerts provided by SAP Solution Manager. These alerts arethen visualized by green, yellow, and red alert icons for each individual business process step in the graphicalbusiness process representation. Business Process Monitoring is intended to detect and respond to criticalsituations as early as possible in order to solve problems as fast as possible.

In addition, SAP Solution Manager offers extended functionality for error handling and problem resolution. Bythe definition of contact persons and escalation paths, Business Process Monitoring can be integrated intothe company’s overall strategy for Business Process Management and solution management within theirsolution support organization.

In general, a Business Process Monitoring includes the solution-wide observation of: Business process performance (key performance indicators) Background jobs (Job Scheduling Management tasks) Business application logs (such as any error log, general application log, due list logs etc.) Data transfer via interfaces between software components Data consistency Technical infrastructure and components which are required to run the business processes Required periodic monitoring tasks

For further details on Business Process Monitoring please refer to http://service.sap.com/bpm.

1.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager

Monitoring types are part of the functional scope of Business Process Monitoring as it is available in SAPSolution Manager. The below mentioned monitoring types are available: Application monitor (throughput and backlog indicators, interface monitoring, 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) 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. In order to receive detailed information on how to set up the monitoring objects in SAP SolutionManager, please refer to the documentation that is available under http://service.sap.com/bpm.

One prerequisite for setting up Business Process and Interface Monitoring in SAP Solution Manager is that allbusiness processes and business process steps are maintained in the respective solution that contains all

http://service.sap.com/bpm.

http://service.sap.com/bpm.


© 2009 SAP AG page 8/40

affected system components. If you want to learn more about how to set this up, please turn tohttp://help.sap.com SAP Solution Manager Basic Settings.

1.7.4.1 Application monitor

The application monitor is just one of many different monitoring types within the Business Process Monitoring.The latest monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the satellite system.The service tool for ST-A/PI is available via the SAP Service Marketplace quick link /installations

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 Throughput and Backlog Indicator functionality available as of ST-A/PI 01J* is only workingproperly with ST-SER 700_2007_1. This is due to changes in the underlying architecture.

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 Setup Guide– Application Monitoring and Setup Guide – User Exit respectively (URL http://www.service.sap.com/ AliasBPM Media Library).

Throughput and backlog indicators

As of ST-A/PI 01H a completely new set of application monitors has been introduced. While the alreadyestablished monitors all evaluate specific logs or performance data these new monitors consider (un-)processed documents in the SAP system and provide so-called throughput and backlog indicators (TBIs).

These TBIs especially provide Automated and early detection of application error situations and backlogs in the core business processes Automated error and backlog analysis tools

For ERP Logistic, the following monitors are available: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 movements posted witherror, confirmation pool errors)Plant Maintenance (e. g. PM/CS notifications, PM/CS orders)

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

Data consistency checks

The DCC collectors are a subset of the application monitors used to retrieve a stored comparison result fromdata comparison check reports for SAP systems.

http://help.sap.com/

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

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


© 2009 SAP AG page 9/40

There are certain consistency check programs that not only are able to output their check result to a list orinto the spool, but can also permanently store a summary in database tables. You can configurecorresponding monitoring objects to retrieve the number of found inconsistencies in the stored summaryinformation and display them as alerts within the SAP Solution Manager Business Process Monitoring(consistency monitoring).

For further information, refer to the document Setup Guide – Data Consistency Monitoring (URLhttp://www.service.sap.com/ Technical Information).

1.7.4.2 Background job

The background job monitoring should be part of a Job Scheduling Management concept. Go tohttp://service.sap.com/solutionmanagerbp, topic area Business Process Operations to find the BestPractice for Job Scheduling Management. Because of several restrictions regarding background jobscheduling, e.g. time restrictions, restriction of hardware resources (CPU, main memory, …), or existingdependencies between different activities (e.g. invoices can only be created after the corresponding goodsissue is posted, or backorder processing and material requirements planning should not run at the same time)it is very important to ensure the stable run of background jobs. A cancelled background job should beidentified as soon as possible in order to react as fast as possible. Therefore it is also necessary to definerestart procedures and escalation paths.

Monitoring objects

Before setting up monitoring, the monitoring objects must be clearly defined. A monitoring object is a singlebackground job or a group of background jobs. There are four different possibilities to identify a special back-ground job or a group of background jobs. This information needs to be maintained in the sub-nodeBackground Job below a business process step.

A detailed description of what kinds of alerts make sense or what kinds of alerts are possible is provided inthe Best Practice for Background Job Monitoring with SAP Solution Manager document, which can be foundon the SAP Marketplace http://service.sap.com/solutionmanagerbp, topic area Business Process Opera-tion.

1.7.4.3 ABAP dump collector

The dump collector provides monitoring features for alerting on occurrences of ABAP dumps of specifiedruntime errors and collects statistical data of ABAP dumps for reporting reasons.

Monitoring objects

The monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime errorname, the user who is responsible for the runtime error, the client on which the runtime error occurs or theprogram that leads to the runtime error.

Monitoring alerts

Possible alert types are the Number of ABAP Dumps (Delta) – all dumps since the last collector run – andNumber of ABAP Dumps (Reporting) – all runtime errors of specified type, client and program for this day orfor the previous day.

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

http://service.sap.com/solutionmanagerbp

http://service.sap.com/solutionmanagerbp


© 2009 SAP AG page 10/40

Figure 1: Monitoring alerts – Number of ABAP Dumps (Delta)

1.7.4.4 Dialog performance

Dialog performance implies the monitoring of the dialog transaction performance of any transaction in theSAP system. This can be a standard transaction or a custom-developed transaction.

Monitoring objects

The monitoring object is the transaction itself. The customizing has to be done in the Dialog Performancenode. The Transactions table lists all transactions that are already configured to that business process step.The relevant transactions need to be selected for monitoring. It is also possible to add or to removetransactions within the Add/Remove Transactions table. The monitoring can be performed per SAPinstance. To this end, select the respective instances in the SAP Instances table, which lists all instances thatare maintained for a system. The Alert Types table shows the dialog response time and all parts of theresponse time that can be monitored, like queue time, load and generation time, database request time andthe front-end response time. Select those times that are relevant for monitoring.

After saving this node, a sub-node Performance Alerts will appear where you can enter the threshold values.


© 2009 SAP AG page 11/40

Figure 2: Monitoring objects – Dialog performance

Monitoring alerts

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

For each combination of transaction code and instance that you want to include in the monitoring, specify thethreshold values resulting in alert messages for GREEN to YELLOW, YELLOW to RED, RED to YELLOW,and YELLOW to GREEN.

Since the monitoring object for performance monitoring is created on the satellite system, it might be possiblethat the object already exists there. Therefore you can load the current threshold values from the respectivesystems via the Load thresholds from <XYZ> button, with <XYZ> representing the SID. If successfullyretrieved for an SAP instance, the values are filled in columns. If no active settings for the threshold valueswere found for a certain transaction code, default values are set (indicated in column Default). To transfer thethreshold values for a single line from right to left, the Copy icon can be used.

To transfer all at once (all thresholds for all columns and tables) there is an additional Copy all button.

Figure 3: Monitoring alerts – Dialog performance


© 2009 SAP AG page 12/40

1.7.4.5 Update errors

Changes to the data in an SAP system caused by a business process should be written to the database in fullor 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 prior to lesscritical changes.

V1 modules describe critical or primary changes, that affect objects with a controlling function in the SAPsystem, 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 objects

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 ofthe ABAP program itself. If desired, you can specify a user executing the transaction or the ABAP program.

If no user is specified explicitly, all users (represented by '*') will be considered in monitoring data evaluation.

Figure 4: Monitoring objects – Update errors


© 2009 SAP AG page 13/40

Monitoring Alerts

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.

1.7.4.6 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 the most important: Delivery (L),Billing (F) and Picking (K). The delivery due list can be directly accessed via transaction V_SA, the billing duelist via transaction V.21. In case of a billing due list, the list contains e. g. a number of sales documents thatneed to be billed. If the billing due list was processed previously and it is important to know which billingdocuments were created from this billing due list, you can display it in the due list log for this billing run.

Monitoring objects

The monitoring object is the respective due list type. That can be Delivery, Billing or Picking. You can specifythe name of the user that is responsible to process the due list. If it is user-independent, use a wildcard ‘*’.You also need to define the aggregation level needs to be defined, which can be per day, per hour or per log.

Monitoring alerts

For the monitoring of due list log messages, you can use four different alert types:1. DocumentCreation refers to the status of the document creation itself. The alert rating (YELLOW or

RED) will be raised if no documents were created during a due list run.2. 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 (orback) and from YELLOW to RED (or back) must be maintained.

3. TotalQuantityMsgs refers to the total number of message created during a due list run. The thresholdvalues for the number of messages that result in a change from GREEN to YELLOW (or back) and fromYELLOW to RED (or back) must be maintained.

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

Figure 5: Monitoring objects – Due list log


© 2009 SAP AG page 14/40

1.7.4.7 Application log

The application log provides an infrastructure for collecting messages, saving them in the database anddisplaying them as a log. At runtime, situations can arise in application programs that must be brought to theattention of the user. These are usually errors. It can also be useful to report a successful completion. Theinformation that arises is called a message. A set of messages is a log. A log usually also has headerinformation (log type, creator, creation time, etc.). A transaction can generate several logs. The applicationlog is not written consecutively but as a whole at one point in time.

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 (or sub-object) can be found in transaction /nSLG1 together with all otherinformation specific to that log.

Figure 6: Monitoring objects and alerts – Application log

It is possible to monitor the total number of messages belonging to an object. For each object, the number ofmessages that raise a YELLOW alert and the number of messages changing from YELLOW to RED must bemaintained.

It is also possible to monitor specific messages that are considered as critical in the N° of Critical Messagestable. To configure the monitoring of critical application log messages, select the relevant object-sub objectcombinations. For each of these combinations, you can specify the message type, the message ID and themessage number as well as the threshold values for the number of critical messages that are supposed toresult in changes from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible touse wildcards.


© 2009 SAP AG page 15/40

Figure 7: Monitoring alerts – Application log / critical messages

1.7.4.8 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 MTE can be found by choosing F1. The MTE name needs to be copied into thecorresponding column (see Figure 7).

Under column Monitor Name you can assign an individual name.

The MTE used for monitoring should be an MTE on the lowest leaf-level, i. e. on attribute level. If anMTE of a higher branch-level (collective MTE) is chosen, then the current and open view in the graphicswill show the right alerts but without the possibility to process these alerts within the Business ProcessMonitoring session as the alerts are not replicated there.

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

.

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 the Copy icon.


© 2009 SAP AG page 16/40

Figure 8: Other CCMS monitors

Unlike all other monitoring types, Other CCMS Monitors provides the opportunity to assign MTEs fromother systems than the system the actual business process step is assigned to.

Example: If you are interested in monitoring the availability from a Portal system that possesses no CCMSbut is included as one business process step in your business process, you can use one MTE in the CCMS ofSAP Solution Manager to monitor the heartbeat of the portal. You can then assign the corresponding alert viaOther CCMS Monitors to business process step running on the portal system.

1.7.4.9 Analysis and 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 (Call Option “1”) or directly in the respective satellite systems (CallOption “2”). Per default some standard transactions are maintained. For instance, transaction SM37, thatprovides a job overview in an SAP system, is maintained for background jobs, and transaction SLG1, which isused to have a look into the application log.

It is also possible to add new transactions. These can be standard transactions or transactions written by thecustomer.


© 2009 SAP AG page 17/40

Figure 9: Analysis and monitoring transactions

On the second tab strip, you can specify an URL that should be called in order to further analyze the givenproblem. This is especially interesting if you have knowledge documents that are linked to a portal. You candefine a short text and the URL.

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>\..., for instance,file://\\\server1\operations_documents\operations-handbook.txt

Figure 10: Analysis and 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. When you press these

buttons, for instance , you jump directly into the corresponding transaction, eitherin SAP Solution Manager (here: SAT) or the connected satellite system (here: CT1), for further analysis.

In case of URLs, the button (e.g. ) contains the short text (limited to 20 characters)from the setup session and opens the defined URL in a new browser window.

http://help.sap.com./


© 2009 SAP AG page 18/40

1.7.4.10 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 there. To ensure effective monitoring andefficient problem resolution, assign responsibilities and define problem resolution procedures as described inthe following table. Some information has been taken from the previous Solution Support Organization node.

Monitoring Team Defines the team that is responsible for monitoring the relevant monitoring object.Use value help F4.

Person Resp. Defines the person who is responsible for monitoring the monitoring object. Usevalue help F4.

Frequency Describes how often the responsible person should process the required monitoringactivity.

Start Time Describes at which time the responsible person should process the requiredmonitoring 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 the problem orcorrect the error.

Escalation Path Describes the escalation path in case that the person responsible could not solve theproblem. Persons who can be contacted should be maintained here.

Table 1: Monitoring objects

You can enter additional information related to this business process step in the tables MonitoringActivities, Error Handling, Restart of Step and Escalation Path. That information is valid for the wholebusiness process step and help users who have to carry out the monitoring and who are not familiar with thatparticular business process.

1.7.4.11 Notifications

You can set up notifications 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 to a specified recipient in case of alerts, for instance, 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, you can define notifications for the whole business process, i. e. as soon as thebusiness process gets an alert status, notifications will be triggered. Alternatively, notifications can be definedfor every monitoring type individually, e. g. all alerts related to background jobs of the business process areforwarded to a defined e-mail address. Notifications defined on business process step level will overrule theconfiguration made on business process level for this particular step.


© 2009 SAP AG page 19/40

Workflow Notification

Sender Must be a user within in the monitoring client of SAP Solution Manager. This user caneven be a system user without any roles or profiles, but the user must have a valid e-mail address which the used mail server knows.

RecipientAddress

Depending on the recipient type, the recipient name is required. This can be any e-mailaddress, an SAP user name in the same system, a remote SAP name or a shareddistribution list. In case of an SMS you need to enter “SMS:<cell phone or pagernumber>”.

Reci. Type There are currently five different recipient types: U (e-mail), K (for SMS and pager), B(SAP user name), R (remote SAP name) and C (shared distribution list).

No. of YellowAlerts

Number of YELLOW alerts that can occur before an automatic notification is triggered

No. of Red Alerts Number of RED alerts that can occur before an automatic notification is triggered

Max Wait Time[h]

Once the maximum wait time [hours] has elapsed, a notification is created even if thethresholds 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 ofthe business process step, …)

Table 2: Workflow Notification

Support Notifications

Priority Defines the priority of the support notification.

Queue Defines the support component on which the message is put. This component mustexist within the service desk.

Processor Defines a default processor who should process the message. The processor must beknown within the service desk and must be SAP user name defined as a businesspartner with role employee.

Text Template Text templates can be defined that will then be available for service desk messagesmanually created for alerts.

Automatic Support notifications will be created automatically depending on the alert thresholds.

Reporter Necessary if service desk messages are created automatically. Must be a SAP username defined as a business partner with role general.

Num ofYELLOW Alerts

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

Num of REDAlerts

Necessary when service desk messages are created automatically, e.g. after five redalerts a service desk message should be created.

Table 3: Support Notifications


© 2009 SAP AG page 20/40

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 notification creationworks with a logical OR operation. Hence, with the figures in the table above the system would create asupport notification if there are either more than nine yellow alerts or more than four red alerts for whichno support notification has been created yet.

1.7.5 Business Process Monitoring process

For a successful and efficient Business Process Monitoring, you have to define a process for implementingyour monitoring concept. This includes the definition of the roles and responsibilities involved. You need todefine who is supposed to carry out which activity within the process and how communication between thedifferent roles within the support organization is supposed to take place.

A Business Process Monitoring concept has to be tightly integrated with the support organization. Thisincludes the integration with the Incident- and Problem Management processes and the ChangeManagement process. These processes have to be adjusted to the Business Process Monitoring concept sothat communication and escalation procedures defined within these processes support the Business ProcessMonitoring concept. This includes the final communication of open alerts to SAP.

Wherever communication connected with Business Process Monitoring happens outside these supportprocesses, separate communication and escalation paths and procedures have to be defined.

Please see the separate Best Practice for General Business Process Management for further details.


© 2009 SAP AG page 21/40

2 Business Process Monitoring for Scheduling Agreement

Based on a sample process, this chapter will show you how business process monitoring for an SAP ERPsystem can look like. It will introduce you to generic thoughts and ideas of how to identify a business processstep you need to keep an eye on and makes you familiar with how to choose the most promising monitoringpossibilities from the available ones.

To make this most visible to you, we have situated the sample process in a fictional company, FastDeliver

2.1 Sample Scenario

FastDeliver is a midsize company. Its main business is producing components for the automotive industry inthe demanded quantity. To be able to optimize their own stock and to perform a planning they receiveforecasts from their customers. For the delivery they receive delivery demand. Without these calls aproduction and delivery is not possible, because of missing customer demand. After receiving the forecast isforwarded to the production/procurement.

The next process steps are to receive the scheduling agreement release to deliver the demand, to create adelivery and report it to the customer with IDoc DESADV, to create a transport and report it via IDoc SHPADV(if necessary) and to create the invoice as a final step.

To be sure to receive and to process the demand through SAP, the following process steps are necessary:1. Receive the demand from the customer2. Forward the production/procurement demand3. Forward the delivery demand4. Create a delivery and send it with DESADV5. Create a transport and send the information via with SHPADV6. Create an invoice

Note: Each chapter will be structured in the following way

2.2.X.1 Description 2.2.X.2 Monitoring requirements 2.2.X.3 Monitoring objects in SAP Solution Manager – In this table you will find all monitoring objects in

the SAP Solution Manager that you should use to monitor your solution. 2.2.X.4 Further monitoring objects – In this table you find the monitoring objects you should monitor using

special reports or transactions. 2.2.X.5 Monitoring without SAP Solution Manager – All aspects which are described within this subsection

are descriptions of how you can monitor your system without SAP Solution Manager.

It is a strongly recommended best practice to use SAP Solution Manager to monitor these objects asdescribed in the respective section 2.2.X.3.


© 2009 SAP AG page 22/40

2.2 Business Process Scheduling Agreement

Customer ERP

Production /Procurementdemand

Deliverydemand

Stock/RequirementList

CreateDelivery

CreateTransport

ERP

CreateInvoice

[1]

[2] [3] [4]

MM SchedulingAgreement

DE

LFOR

DELIN

S

Inbound delivery

DES

ADV

SHP

ADV

Receive demand

FI/CO

Figure 11: Business Process Scheduling Agreement

SD Scheduling agreements in the ERP system are updated with the forecasts (DELFOR) and the deliverydemand (DELINS) from the customer for a long period. When the customer sends a new transmission, thedata from the old transmission is replaced by the new data from the new transmission. The transmissionsinclude requested goods receipt date and quantity. Further information like price, ship to party, sold to party,customer material number in the scheduling agreement does not change. The scheduling agreement istypically used for a long time. After the demand is received it is forwarded to the different departments(production, procurement, distribution).

Axiomatically it is possible to work only with DELFORs. DELFORs can be used to populate the stock/requirement list and they can be used for the distribution. IDocs of type DELINS are not required, but mostcustomers differentiate between forecast and delivery demand. In this case the DELFORs are used for theforecasts and the DELINS are used for the delivery demand. It depends on the transmissions the customersends whether the supplier needs to work with DELFORs and DELINS or only with DELFORs.

In a first step the customer sends the forecasts (DELFOR). This is the basis for the production andprocurement and impact the stock/requirement list. Normally they include information for a very long period


© 2009 SAP AG page 23/40

(sometimes even years). The MRP run evaluates the requirements and creates production or procurementproposals, so-called receipt elements.

The forecasts are sent normally once a day only, because they are only relevant for the planning and not forthe actual deliveries. Some customers send them only once a week. In case the customer is sending onlyDELFORs, these transmissions can be sent more than once a day.

Additional to the forecasts the customer sends delivery demand (DELINS). This transmission contains thegoods receipt date and the quantity of a material. This information is also updated in the schedulingagreement and the other information remains unchanged. These transmissions normally are relevant for thedelivery and enable to ship the right material at the right timeslot. But it is also possible to use them for theplanning in the production and procurement department. It depends on the way the production andprocurement departments are working.

On basis of this information a delivery is created. Tasks in the delivery are: Picking Packing Print outs Goods issue Transmission (DESADV) about goods issue to the customer

It is possible to post the goods issue and to send the transmission (DESADV) at a later moment with thefunctionality of the transport.

After the deliveries are created, they are combined into one shipment. It is possible to process the follow upsteps to delivery creation like packing over all included deliveries. Documents can be created and the goodsissue can be posted. With the posting of the goods issue a transmission (SHPADV) can be send to the shipto party, to inform them about the material and the quantities on the transport.

After the posting of the goods issue the deliveries become relevant for invoicing. It is not relevant where thegoods issue took place (in the delivery or on the transport). After the goods issue all deliveries are containedin the billing due list. It is possible to create the invoices automatically via a batch job or manually. All requiredinformation is copied out of the deliveries and scheduling agreements. The invoices are printed in themoment the invoice is saved. Also the FI/CO documents are created containing the relevant invoiceinformation.

2.2.1 Business process step 1: Receive demand

2.2.1.1 Description

General Information

A scheduling agreement is a contractual agreement between a sales organization and a sold-to party aboutdelivering products at defined prices. The sold-to party sends the quantities and times via EDI using messagetypes DELFOR (forecasts) and DELINS (JIT delivery schedules). The DELFORs are used to update thedemands visible in the stock/requirements list and the DELINS are used for the Release Against Outlineagreement. The processing of these transmissions in the SAP system is defined in the partner profiles as


© 2009 SAP AG page 24/40

maintained in transaction WE20. A process code can be assigned to the different message types DELFORand DELINS and so it is possible to process them in different ways.

Further possible scenarios are: DELFORs are used for the distribution and to populate the stock/requirement list. DELINS are not used. DELINS update the requirements as visible in the stock/requirement list and create releases up to a given

date. Further requirements after this date are generated by DELFORs. DELINS are used for requirement updates and distribution up to a given date and after this date the

DELFORs fill up the stock/requirement list and are used for the distribution

But in all scenarios the DELFORs/DELINS must be received and this needs to be monitored, because theyare the basis for the production and procurement as well as the actual delivery.

Sample scenario specific information

Customer sends DELFORs and DELINS. The DELINS fill up the stock/requirement list and are used for thedistribution up to the JIT horizon and after the JIT horizon the DELFORs create entries in the stock/requirement list.

2.2.1.2 Monitoring requirements

Error monitoring

It is important that the transmissions are processed in SAP correctly. Failed transmissions cause costs and alow customer satisfaction for shipping in time.

Backlog monitoring

In the transaction EMFOR it is possible to review and process all received transmissions. Erroneoustransmissions are figured out and can be fixed.

2.2.1.3 Monitoring objects in SAP Solution Manager

MonitoringObject

Selection Criteria Alert Analysis Tool onSatellite System

MonitoringFrequency / DataCollection

IDoc Monitoring(IMIDOC01)

Message Type, BasicType, PartnerNumber, IDocs inStatus “51”

Delta Number Monitor WE05 Every 15 minutes

Table 4: Business process step 1 – Monitoring objects in SAP Solution Manager

2.2.1.4 Further monitoring objects without SAP Solution Manager

MonitoringObject



Number ofscheduling

Schedulingagreements with

Once per day toonce per week


© 2009 SAP AG page 25/40

MonitoringObject



agreement releases more than n releases.You should take careof schedulingagreements havingclose to 10.000releases.

depending onrelease frequency

Number ofdocument flowentries

Schedulingagreements withmore than ndocument flow entries


Outdated schedulinglines

Are there relevantscheduling lines witha delivery date <today?


Difference betweentarget quantity andcumulative deliveredquantity

Is the target quantityless than thecumulative deliveredquantity?


Table 5: Business process step 1 – Further monitoring objects without SAP Solution Manager

2.2.1.5 Monitoring without SAP Solution Manager

In the transaction EMFOR all received transmissions are shown. It is also possible to rework faultytransmissions and to have a look to the content of the IDOC.

Check regularly the demand in the stock/requirement list whether the demand exists for all schedulingagreement releases.

2.2.2 Business process step 2: Create delivery

2.2.2.1 Description

General information

There are a lot of possibilities to create a delivery related to a scheduling agreement. The transaction VL01Ncan be used or the delivery can be created directly out of the scheduling agreement. But with thesetransactions it is very easy to forget a delivery demand, because you have to know which schedulingagreement you want to deliver.

To use the delivery due list (transactions VL10X) is the easier way. In the VL10X transactions the systemshows up the whole delivery demand for a given period. VL10X can be executed in dialog mode or morecommonly used as a background process. Further steps in the delivery process are: Picking (with or without transfer orders) Packing Creation of delivery note Creation of label Send EDI transmission (DESADV) to the ship-to party Goods issue


© 2009 SAP AG page 26/40

To do the packing automatically packing instructions are and determination records are required.

The picking and creation of delivery note are necessary at this step, but the packing, creation of labels andthe posting of goods issues are also possible in the shipment.

To perform some of these steps in background as well, the master data mentioned at the different steps isneeded.


The delivery is created via the transaction VL10E in the dialog. The picking is done without transfer orders,handling units are created, the delivery note and the labels are printed. There is no DESADV, because thegoods issue will be posted in the transport and not in the delivery.


Error monitoring

It is important that the jobs creating the delivery are finished in time and do not cancel. Furthermore, noexceptions should be issued during the processing which indicates that a sales order could not be delivered.

Performance monitoring

Performance problems can lead to a delayed creation of deliveries. Missing or delayed data could causeover-stock situations and bad customer satisfaction.

Throughput monitoring

For the success of the business process execution the throughput of deliveries is critical. It has to be ensuredthat enough deliveries are created each day to prevent overstock and backlog situations.

Backlog monitoring

The deliveries have to be processed in a timely manner. Especially the shop floor performance is critical.


MonitoringObject



Background Jobs fordelivery creation

Job Name, Start Time Start Delay,Maximum Duration,Cancellation

SM37 every 5 minutesduring every jobexecution

Throughput:Deliveries(KPLE0001)

Shipping Point,Delivery Type, Datafrom prev. day,Created by

Outbound Deliveries(created)

VL03 Daily

Backlog: Deliveries(KPLE0001)

Shipping Point,Delivery Type, Datafrom prev. day,Created by

Outbound Deliveries(Overdue)

VL03 Daily

Errors: Due List Log Due List Type =Delivery, User,

No documentscreated, No. of

V_SA Daily


© 2009 SAP AG page 27/40

specific messages

Errors: UpdateErrors

Object Type, ObjectName

No. of Errs for Red(Upd1)

SM13 N.A.

Performance Transactions used formanual deliverycreation like VL01N

Response Time STAD Daily

Table 6: Business process step 2 –Monitoring objects in SAP Solution Manager

2.2.2.4 Further monitoring objects

Check hourly in transaction ST22 whether short dumps occurred for the delivery process.


You should check the log files of the delivery creation every day whether any errors occurred usingtransactions SM37 and V_SA. The collective run type to be used in transaction V_SA is L.

Check the run time of the jobs for delivery creation manually in transaction SM37 and compare it with yourtime window at least once per day.

Use transactions ST04 and STAD to check the response times of important manual transactions.

Check hourly in transaction SM13 whether update errors occurred.

Check hourly using transaction ST22 whether short dumps related to the delivery process occurred.

2.2.3 Business process step 3: Create transport

2.2.3.1 Description

General information

The creation of a shipment is not required to deliver the goods to the ship-to party but it is used quite often tocombine deliveries into a single transport.

One transport can include a lot of deliveries. Combining several deliveries into one shipment allows to do anoverall delivery picking or to pack items from different deliveries combined in a single transport in one packingmaterial.

The activities performed for a transport are captured by status information where each status corresponds toanother activity being processed. Typical activities are the posting of the goods issue or to send the SHPADVto the ship to party.

It is not only possible to send the SHPADV to the ship to party during the saving of a transport with a specificstatus, but to process and start the transmission with a background job and starts the transmission.


In our example the transport functionality is used. There are several deliveries combined on one transport.Material from different deliveries needs to be packed on one pallet. Additional print outs are created out of the


© 2009 SAP AG page 28/40

transport, because the pallet is not known in the deliveries. They are printed in the moment the transport issaved the first time.

After saving the transport with the reached status shipment start the goods issue will be posted and thetransmission with the message type SHPADV is sent to the ship to party.

To enable SAP to send the SHPADV to the ship-to party an entry in the transaction WE20 for the ship-toparty must be created. Only with this entry it is possible to send an SHPADV to the ship-to party.


Error monitoring

It is very important to be sure that all deliveries have goods issue posted and the SHPADV is sent to the ship-to party. The reason for this is that on customer side the SHPADV creates an inbound delivery and when thetransport arrives the goods receipt is posted against this inbound delivery.

One other important point is, our stock is not in balance and it is not possible to create an invoice.

Backlog monitoring

All deliveries on a transport must have a goods issue. So a monitoring is needed for the deliveries on atransport. Also a monitoring is needed for the SHPADV which could not be processed completely.


MonitoringObject



Throughput:Shipments

TransportPlanPt,Shipment type, Datafrom previous day

Shipments Created VT20 Once per day

Throughput:Shipments

TransportPlanPt,Shipment type,Overdue since

Shipments (overdue) VT20 Once per day



Check daily in the overall shipment status monitor (transaction VT20) whether all shipments have beenprocessed as intended.

2.2.4 Business process step 4: Create invoice

2.2.4.1 Description

General information

The billing due list is populated automatically during the posting of the goods issue. It does not matterwhether the goods issue was posted in the transport or directly in the delivery. It is only important that thegoods issue took place.


© 2009 SAP AG page 29/40

All deliveries with a goods issue are shown in transaction VF04. Out of this transaction it is possible to createan individual billing document or a collective billing document. The collective billing document can be createdin the background or in the dialog.

Another way to create the billing document is the transaction VF06. This transaction creates a backgroundjob to apply the invoice automatically. The protocol of the background job is shown with the transaction V.21.

In case that all master data are maintained the FI/CO documents should be created automatically whilesaving the invoice if you have not set a posting block in customizing of the invoice type.

To post documents in case a billing block has been used or errors occurred during the automated posting usethe transaction VFX3.


The goods issue is posted in the transport, not in the delivery. The transaction VF06 is used to create thebilling documents automatically in the background. After the background the transaction V.21 shows noentries so the background job runs successfully without mistakes.


Error monitoring

Invoices not created or transferred to FI will result in a delay of the customer payment potentially causing lossof money and affecting the cash flow. Therefore, it is important to monitor the scheduled jobs for cancellationand for any update errors or short dumps during the invoice creation.

Performance monitoring

It is vital to ensure customer and end user satisfaction for the performance for transaction VF01.

Throughput monitoring

For the success of the business process execution the throughput of invoices is critical. It has to be ensuredthat enough invoices are created each day to generate enough revenue. If an invoice is delayed the customerwill have to pay later resulting in financials losses and delayed cash flow.

Backlog monitoring

Invoices have to be transferred to Financial Accounting for the needed follow-up procedures like receiving theincoming payment, starting dunning procedures if the incoming payment is overdue.

Data consistency requirements

You should ensure the consistency between SD and FI. Inconsistencies between SD and FI could indicatemissing open items or duplicate billing to the customer if you use one step posting.


© 2009 SAP AG page 30/40

2.2.4.3 Monitoring Objects in SAP Solution Manager

MonitoringObject



Background Job Job Name, Start Time Start Delay,Maximum DurationCancellation

SM37 every 5 minutesduring every jobexecution

Backlog: SDInvoices (AR)(KPSD0002)

Billing Type, BillingCat., Sales Org, Dist.Channel, Division,Created by, olderthan x days

SD Invoices notposted to FI

VF03, VFX3 Daily

Throughput: SDInvoices (AR)(KPSD0002)

Billing Type, BillingCat., Sales Org, Dist.Channel, Division,Created by, data fromprvious day

Sales invoices postedper day

VF03 Daily

Errors: UpdateErrors

Object Type, ObjectName

No. of Errs for Red(Upd1)

SM13 N.A.

Performance:PerformanceMonitor(BOPERFMO) orDialoguePerformance

Transaction ResponseTime STAD N.A.

Throughput: DueList Log

Due List Type =“Billing”, Aggregation:“per log”

No documentscreated

VF04, VF03 N.A.

Errors: Due List Log Msg Type = E, AMsg ID = ‘*’Msg. No = ‘*’*

No of specificmessages

VF04, VF03 N.A.

Backlog: Messages(OutputDetermination)(KWMSG001)

Application, messagetype, transm.Medium, dispatchtime, partner function,message partner,output device, printimmediately, username, older than xdays

Not processedmessages

every 5 minutes

Errors: Messages(OutputDetermination)(KWMSG001)

Application, messagetype, transm.Medium, dispatchtime, partner function,message partner,output device, printimmediately, username, older than xdays

Incorrectly processedmessages

Report RSNAST0F every 5 minutes



© 2009 SAP AG page 31/40

2.2.4.4 Further monitoring objects

Check daily in transaction ST22 whether short dumps related to the invoice creation exist.


Check daily for update errors related to the invoice creation using transaction SM13.

Check regularly the performance of transactions executed in dialog using transactions STAD and ST03N.

Check the correct execution for any background jobs you have scheduled for invoice creation usingtransaction SM37. In addition, you should check the job log of these executions in transaction SM37.

Check daily in transaction ST22 whether short dumps related to the invoice creation exist.

The transaction V.21 shows the result of the background job for billing documents created with thetransaction VF06. Here is it possible to get the protocol of the background job.

The transaction VFX3 shows the billing documents without FI/CO document.

Check the spool for unprocessed and erroneous messages for application V3.

2.2.4.6 Scheduling of background jobs

Job scheduling requirements

Recommended orGenerated Job Name

ABAPReport

Variant Sche-duling

Prede-cessorJob

SuccessorJob

SchedulingRestriction

ErrorHand¬ling inCase ofCancellation

S_<SIDCLIENT>_<COUNTRY>_SALES_RV60SBAT_<SALESORG>_D

RV60SBAT

Daily After deliverycreation

Table 9: Business process step 4 – Job scheduling requirements


© 2009 SAP AG page 32/40

3 Further Information

3.1 Troubleshooting

If executing this Best Practice did not produce the desired results Search for related notes in the SAP Service Marketplace. Open an SAP customer message describing your problem (please see the respective component in

section Error Handling, Restartability and Escalation of every step).

3.2 Related Best Practice Documents

There are several other Best Practice documents available on the Service Marketplace underhttps://service.sap.com/solutionmanagerbp that relate to this Best Practice document. These documents are:

General Business Process Management: This document explains the procedures you should use tocreate a general Business Process Management concept. This includes the definition and documentationof the core business processes, definition of monitoring objects, definition of monitoring activities includingerror handling procedures, monitoring tools, monitoring frequencies, the definition of communication andescalation procedures and the assignment of responsibilities.ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus onALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitorALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoringapproaches aim to detect any irregularities or deviations or to detect error situations at an early stage.Job Scheduling Management: This Best Practice provides a detailed description what SAP recommendsas a standardized formal process to support a job request process, including an end user job request formand an approval process. This integrated process will avoid error-prone and time intensive manualprocesses of copying redundant data from one data source to another (for example, MS excel to MS Excelor MS Excel to job scheduling tool).SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a BusinessProcess Monitoring concept for your SAP ERP solution. The concept aims to define procedures forbusiness process oriented monitoring and error handling and escalation procedures for your company’sERP core business processes. These procedures intend to ensure a smooth and reliable flow of the corebusiness processes so that your business requirements are met.Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set upbackground job monitoring properly in the framework of Business Process Monitoring in the SAP SolutionManager.

Please note that these documents are also available in the SAP Service Marketplace using alias RunSAPRun SAP Best Practices.

3.3 Literature

For detailed information on how to administer an SAP R/3 system, see the book:SAP R/3 System Administration by Liane Will, 2003

For information on how to monitor and tune the general system performance, see the book:SAP Performance Optimization Guide by Thomas Schneider, 2006

For information on how to monitor your business processes using SAP Solution Manager, see the book:Business Process Monitoring mit dem SAP Solution Manager by Thomas Schroeder, 2009 (currently

only available in German)

https://service.sap.com/solutionmanagerbp


© 2009 SAP AG page 33/40

For information on how to set up general system monitoring using SAP Solution Manager, see the book:Konzeption und Einrichtung des Systemmmonitorings mit dem SAP Solution Manager by CorinnaWeidmann and Lars Teuber, 2009 (currently only available in German)


© 2009 SAP AG page 34/40

4 Appendix

In the following section, you find examples on how to set up monitoring within SAP Solution Manager.

4.1 Examples for recommended Monitoring Objects

4.1.1 Example Background Job Monitoring

Background job monitoring of background job RVV50R10C in SAP Solution Manager is used as a sample.The setup for the other jobs is quite similar, except for the job-specific parameters. Call SAP Solution Manager (trx DSWP or SOLUTION_MANAGER). Select your solution. Go to Operation Setup and navigate to Solution Monitoring • Business Process Monitoring. Check Business Processes: Select a business process for application monitoring. Check for your chosen business process: Choose process steps to monitor. Check for your chosen step: Choose type of monitor, here Background Job. Enter the information to be used to identify the job, in this case the job name S_PRD001_UK_SALES_

RVV50R10C_1000_M

Figure 12: Background job monitoring – Identify job

Choose the key figures Job Cancellation and Maximum Duration to monitor the runtime of the job. On the Maximum Duration tab, you can enter thresholds that raise a yellow or a red alert, respectively,

when exceeded.

Figure 13: Background job monitoring – Enter thresholds


© 2009 SAP AG page 35/40

On the Job Cancellation tab, you can define whether a yellow or a red alert should be raised when the jobis cancelled.

Figure 14: Background job monitoring – Define alerts

Once you have entered all relevant information for the monitoring objects, generate the monitoringcustomizing and activate the monitoring within the Business Process Monitoring session.

4.1.2 Example ABAP Dump Monitoring

There are different possibilities to monitor ABAP dumps within SAP Solution Manager: You can use thescheduling user and monitor all ABAP dumps which are created from this scheduling user, or you can monitora special dump that occurs again and again, or you can monitor if a dump occurs in a special program orfunction module. The following describes the setup procedure for a scheduling user. Call SAP Solution Manager (TA: DSWP or SOLUTION_MANAGER). Select your solution. Go to Operation Setup and navigate to Solution Monitoring • Business Process Monitoring. Check Business Processes: Select a business process for application monitoring. Check for your chosen business process: Choose process steps to monitor. Check for your chosen step: Choose type of monitor, here Application Monitor. Choose the application monitor ABAP Dump Collector. Choose Number of ABAP Dumps (Delta).

Figure 15: ABAP dump monitoring – Select key figure

This key figure will collect all dumps since the last run of the collector.


© 2009 SAP AG page 36/40

Enter a wildcard in fields Runtime Error and Program, since the program can call another FB and theruntime error can be different for each of the called function modules. In our example all runtime errors forusers that have a user ID starting with UK will be monitored.

Figure 16: ABAP dump monitoring – Define criteria (1)

You should always be informed if a dump occurs.

Figure 17: ABAP dump monitoring – Define criteria (2)

In the Monitoring Schedule tab, enter that the scheduling should be once a day

Figure 18: ABAP dump monitoring – Define monitoring schedule (1)

Once you have entered all relevant information for the monitoring objects, generate the monitoringcustomizing and activate the monitoring within the Business Process Monitoring session.

4.2 Background Jobs

Certain jobs must run periodically in a productive SAP for Automotive system, for example, deleting obsoletejobs or spool objects. If these periodic jobs do not run, system performance may decrease over time.Unfortunately, there is currently no easy-to-use support for such jobs in Basis Customizing. Therefore, the


© 2009 SAP AG page 37/40

jobs must be scheduled manually. For more information, see SAP Note 16083. Note that a daily monitoring ofthe job log using SAP Solution Manager is recommended.

Error handling procedures for batch jobs

In case one of the scheduled jobs fails or if one of the necessary jobs is not scheduled, and even if ascheduled job has finished, check for the current job status (refer to SAP R/3 documentation CD, componentBC-CCM, chapter Background Processing) and proceed as follows: In the case of status Scheduled, the job steps have already been defined, but the start condition has not

yet been defined. Contact the program scheduling management in order to clarify when the job will be fullydefined.

In the case of status Released, the job has been fully defined including a start condition and waits for thecondition to fulfill.

In the case of status Ready, the start condition of a released job has been met. A job scheduler has putthe job in line to wait for an available background work process.

In the case of status Active, the job is running and cannot be modified or deleted. Check if the job is withinthe given timeframe, depending on the data volume to be processed. Check for particular dependencieson other jobs. If the job exceeds the given timeframe, contact the software monitoring team.

In the case of status Finished, all steps that make up the job have completed successfully. Programscheduling management has to check whether the job has run in the given timeframe, and softwaremonitoring team or application support have to check the respective job results, such as spool output lists,message logs, updates, etc.

In the case of status Cancelled, the job has terminated before completion caused by one of the followingreasons: If an administrator intentionally cancelled the job, clarify why it was necessary to do that andwhether (and when) the job has to be re-run. If a program in a job step produced an error such as issuingan ‘E’ or ‘A’ error message, contact the software monitoring team and investigate why the error occurred.In case of an SAP standard program, search for appropriate messages in SAP Net and open a customermessage if you cannot solve the problem.

Job restart

In case of the cancellation of a background job, possible succeeding jobs or dependencies on other jobsmust be considered when restarting the aborted job. The start of succeeding jobs might be also delayed dueto the restart of the aborted job.

Escalation procedures

If it is not possible for any of your support levels to provide a solution for a particular problem, it isrecommended to open an SAP customer problem message.


© 2009 SAP AG page 38/40

Index of FiguresFigure 1: Monitoring alerts – Number of ABAP Dumps (Delta)......................................................................10Figure 2: Monitoring objects – Dialog performance.......................................................................................11Figure 3: Monitoring alerts – Dialog performance .........................................................................................11Figure 4: Monitoring objects – Update errors................................................................................................12Figure 5: Monitoring objects – Due list log ....................................................................................................13Figure 6: Monitoring objects and alerts – Application log ..............................................................................14Figure 7: Monitoring alerts – Application log / critical messages....................................................................15Figure 8: Other CCMS monitors ...................................................................................................................16Figure 9: Analysis and monitoring transactions.............................................................................................17Figure 10: Analysis and monitoring URL.......................................................................................................17Figure 11: Business Process Scheduling Agreement....................................................................................22Figure 12: Background job monitoring – Identify job .....................................................................................34Figure 13: Background job monitoring – Enter thresholds.............................................................................34Figure 14: Background job monitoring – Define alerts...................................................................................35Figure 15: ABAP dump monitoring – Select key figure..................................................................................35Figure 16: ABAP dump monitoring – Define criteria (1).................................................................................36Figure 17: ABAP dump monitoring – Define criteria (2).................................................................................36Figure 18: ABAP dump monitoring – Define monitoring schedule (1) ............................................................36

Index of TablesTable 1: Monitoring objects ..........................................................................................................................18Table 2: Workflow Notification......................................................................................................................19Table 3: Support Notifications ......................................................................................................................19Table 4: Business process step 1 – Monitoring objects in SAP Solution Manager.........................................24Table 5: Business process step 1 – Further monitoring objects without SAP Solution Manager ....................25Table 6: Business process step 2 –Monitoring objects in SAP Solution Manager..........................................27Table 7: Business process step 3 – Monitoring objects in SAP Solution Manager.........................................28Table 8: Business process step 4 – Monitoring objects in SAP Solution Manager.........................................30Table 9: Business process step 4 – Job scheduling requirements ................................................................31


© 2009 SAP AG page 40/40

© Copyright 2009 SAP AG. All Rights ReservedNo 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, Outlook, and PowerPoint 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, and Informix are trademarks or registered trademarks of IBMCorporation.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.MaxDB is a trademark of MySQL AB, Sweden.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Allother product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide anywarranty whatsoever relating to third-party Web pages.