Manage operations for s ap scheduling agreements

2,122 views
1,990 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,122
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
83
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Manage operations for s ap scheduling agreements

  1. 1. Best Practice for Solution Operations Manage Operations for SAP Scheduling Agreements Dietmar-Hopp-Allee 16 D-69190 Walldorf CS STATUS customer published DATE 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 OperationsBP_Scheduling_Agreements_V30.doc – 10.06.2009
  2. 2. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveTable of Contents1 Management Summary 4 1.1 Goal of Using This Best Practice 4 1.2 Alternative Practices 4 1.3 Staff and Skills Requirements 4 1.4 System Requirements 5 1.5 Duration and Timing 5 1.6 How to Use This Best Practice 5 1.7 Best Practice Procedure 6 1.7.1 Preliminary tasks 6 1.7.2 Monitoring concepts 6 1.7.3 Business Process Monitoring in SAP Solution Manager 6 1.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 7 1.7.4.1 Application monitor 8 1.7.4.2 Background job 9 1.7.4.3 ABAP dump collector 9 1.7.4.4 Dialog performance 10 1.7.4.5 Update errors 12 1.7.4.6 Due list log 13 1.7.4.7 Application log 14 1.7.4.8 Other CCMS monitors 15 1.7.4.9 Analysis and monitoring tools 16 1.7.4.10 Monitoring activities 18 1.7.4.11 Notifications 18 1.7.5 Business Process Monitoring process 202 Business Process Monitoring for Scheduling Agreement 21 2.1 Sample Scenario 21 2.2 Business Process Scheduling Agreement 22 2.2.1 Business process step 1: Receive demand 23 2.2.1.1 Description 23 2.2.1.2 Monitoring requirements 24 2.2.1.3 Monitoring objects in SAP Solution Manager 24 2.2.1.4 Further monitoring objects without SAP Solution Manager 24 2.2.1.5 Monitoring without SAP Solution Manager 25 2.2.2 Business process step 2: Create delivery 25 2.2.2.1 Description 25 2.2.2.2 Monitoring requirements 26 2.2.2.3 Monitoring objects in SAP Solution Manager 26 2.2.2.4 Further monitoring objects 27 2.2.2.5 Monitoring without SAP Solution Manager 27 2.2.3 Business process step 3: Create transport 27 2.2.3.1 Description 27 2.2.3.2 Monitoring requirements 28 2.2.3.3 Monitoring objects in SAP Solution Manager 28 2.2.3.4 Monitoring without SAP Solution Manager 28 2.2.4 Business process step 4: Create invoice 28© 2009 SAP AG page 2/40
  3. 3. Best Practice for Solution OperationsManage Operations for SAP for Automotive 2.2.4.1 Description 28 2.2.4.2 Monitoring requirements 29 2.2.4.3 Monitoring Objects in SAP Solution Manager 30 2.2.4.4 Further monitoring objects 31 2.2.4.5 Monitoring without SAP Solution Manager 31 2.2.4.6 Scheduling of background jobs 313 Further Information 32 3.1 Troubleshooting 32 3.2 Related Best Practice Documents 32 3.3 Literature 324 Appendix 34 4.1 Examples for recommended Monitoring Objects 34 4.1.1 Example Background Job Monitoring 34 4.1.2 Example ABAP Dump Monitoring 35 4.2 Background Jobs 36© 2009 SAP AG page 3/40
  4. 4. Best Practice for Solution OperationsManage Operations for SAP for Automotive1 Management Summary1.1 Goal of Using This Best PracticeThis 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 PracticesYou 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 RequirementsTo implement this Best Practice, you require the following teams:Application management teamThis 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 teamBusiness process operations teamThe 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 4/40
  5. 5. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveSAP technology operations team All parties in your solution support organization and IT department involved in monitoring focused on the system administration side (program scheduling management, software monitoring team, system administration team, including the system administrator)Business process champion The business process champion is the person in the business department that is responsible for the successful execution of the business process. He coordinates all activities necessary for the business process. Therefore, he is usually responsible for the escalation paths in case of problems. He often serves as a second level in the escalation procedure, if the application monitoring team needs to escalate an issue.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 Monitoring E2E300 End-to-end Business Process Integration and Automation Management1.4 System RequirementsIn 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 TimingDuration Creating a Business Process Monitoring concept takes approximately one week per business process. Implementing the Business Process Monitoring concept takes approximately an additional week.TimingThe 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 PracticeHere 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 Business Process Management concept. This includes the definition and documentation of the core business processes, definition of monitoring objects, definition of monitoring activities (including error handling procedures, monitoring tools, and monitoring frequencies), the definition of communication and escalation procedures, and the assignment of responsibilities.© 2009 SAP AG page 5/40
  6. 6. Best Practice for Solution OperationsManage Operations for SAP for Automotive At the beginning of chapter 2 you will find a typical flow chart of the core business process explained in this Best Practice. It is intended to be used as a guideline for writing down your company specific process documentation. In chapter 1.7.4 you find further information that is relevant for more than one scenario. In case information from the generic part is relevant for a specific business process step in one of the scenarios, you will find a clear link to the corresponding chapter in the generic part.1.7 Best Practice Procedure1.7.1 Preliminary tasksBefore 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 availability1.7.2 Monitoring conceptsThe 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 monitoringFor 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 restartabilityGeneral 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 ManagerBusiness 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 6/40
  7. 7. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveThe 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 tasksFor 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 ManagerMonitoring 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© 2009 SAP AG page 7/40
  8. 8. Best Practice for Solution OperationsManage Operations for SAP for Automotiveaffected 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 monitorThe 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 /installationsEntry 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 respective satellite. In case of problems refer to SAP Note 915933. The Throughput and Backlog Indicator functionality available as of ST-A/PI 01J* is only working properly 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 indicatorsAs 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 toolsFor 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 with error, 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 checksThe DCC collectors are a subset of the application monitors used to retrieve a stored comparison result fromdata comparison check reports for SAP systems.© 2009 SAP AG page 8/40
  9. 9. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveThere 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 jobThe 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 objectsBefore 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 collectorThe 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 objectsThe 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 alertsPossible 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.© 2009 SAP AG page 9/40
  10. 10. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveFigure 1: Monitoring alerts – Number of ABAP Dumps (Delta)1.7.4.4 Dialog performanceDialog 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 objectsThe 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 10/40
  11. 11. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveFigure 2: Monitoring objects – Dialog performanceMonitoring alertsEach 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 11/40
  12. 12. Best Practice for Solution OperationsManage Operations for SAP for Automotive1.7.4.5 Update errorsChanges 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 objectsMonitoring 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 12/40
  13. 13. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveMonitoring AlertsSince 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 logA 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 objectsThe 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 alertsFor 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 (or back) 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 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.4. 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 to YELLOW (or back) and from YELLOW to RED (or back) must be maintainedFigure 5: Monitoring objects – Due list log© 2009 SAP AG page 13/40
  14. 14. Best Practice for Solution OperationsManage Operations for SAP for Automotive1.7.4.7 Application logThe 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 alertsThe 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 logIt 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 14/40
  15. 15. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveFigure 7: Monitoring alerts – Application log / critical messages1.7.4.8 Other CCMS monitorsWith 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 an MTE of a higher branch-level (collective MTE) is chosen, then the current and open view in the graphics will show the right alerts but without the possibility to process these alerts within the Business Process Monitoring 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 15/40
  16. 16. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveFigure 8: Other CCMS monitors Unlike all other monitoring types, Other CCMS Monitors provides the opportunity to assign MTEs from other 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 toolsIt 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 16/40
  17. 17. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveFigure 9: Analysis and monitoring transactionsOn 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 file servers specify the full file path, using the nomenclature: file://<server>..., for instance, file://server1operations_documentsoperations-handbook.txtFigure 10: Analysis and monitoring URLThe 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 thesebuttons, 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.© 2009 SAP AG page 17/40
  18. 18. Best Practice for Solution OperationsManage Operations for SAP for Automotive1.7.4.10 Monitoring activitiesMonitoring 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. Use value help F4. Frequency Describes how often the responsible person should process the required monitoring activity. Start Time Describes at which time the responsible person should process the required 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 the problem or 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 be maintained here.Table 1: Monitoring objectsYou 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 NotificationsYou 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 18/40
  19. 19. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveWorkflow Notification Sender Must be a user within in the monitoring client of SAP Solution Manager. This user can even 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. Recipient Depending on the recipient type, the recipient name is required. This can be any e-mail Address address, an SAP user name in the same system, a remote SAP 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 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 Yellow Number of YELLOW alerts that can occur before an automatic notification is triggered Alerts No. of Red Alerts Number of RED alerts that can occur before an automatic notification is triggered Max Wait Time Once the maximum wait time [hours] has elapsed, a notification is created even if the [h] 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, …)Table 2: Workflow NotificationSupport 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. The processor must be known within the service desk and must be SAP user name defined as a business partner with role employee. Text Template Text templates can be defined that will then be available for service desk messages manually 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 user name defined as a business partner with role general. Num of Necessary when service desk messages are created automatically, e.g. after ten YELLOW Alerts yellow alerts a service desk message should be created. Num of RED Necessary when service desk messages are created automatically, e.g. after five red Alerts alerts a service desk message should be created.Table 3: Support Notifications© 2009 SAP AG page 19/40
  20. 20. Best Practice for Solution OperationsManage Operations for SAP for Automotive If in addition to Queue, Processor, Priority and Reporter either one of the columns Num of YELLOW Alerts or Num of RED Alerts is filled with a value, the automatic support notification creation is configured. In case that both columns are filled with a value, the automatic support notification creation works with a logical OR operation. Hence, with the figures in the table above the system would create a support notification if there are either more than nine yellow alerts or more than four red alerts for which no support notification has been created yet.1.7.5 Business Process Monitoring processFor 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 20/40
  21. 21. Best Practice for Solution OperationsManage Operations for SAP for Automotive2 Business Process Monitoring for Scheduling AgreementBased 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, FastDeliver2.1 Sample ScenarioFastDeliver 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 invoiceNote: 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 21/40
  22. 22. Best Practice for Solution OperationsManage Operations for SAP for Automotive2.2 Business Process Scheduling Agreement Customer ERP MM Scheduling Inbound delivery Agreement DELFOR DESADV SHPADV DELINS ERP [1] Receive demand Create [2] Create [3] Create [4] Delivery Transport Invoice Production / Delivery Procurement demand demand Stock/Requirement FI/CO ListFigure 11: Business Process Scheduling AgreementSD 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 22/40
  23. 23. Best Practice for Solution OperationsManage Operations for SAP for Automotive(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 customerIt 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 demand2.2.1.1 DescriptionGeneral InformationA 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 23/40
  24. 24. Best Practice for Solution OperationsManage Operations for SAP for Automotivemaintained 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 distributionBut 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 informationCustomer 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 requirementsError monitoringIt is important that the transmissions are processed in SAP correctly. Failed transmissions cause costs and alow customer satisfaction for shipping in time.Backlog monitoringIn 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 Monitoring Selection Criteria Alert Analysis Tool on Monitoring Object Satellite System Frequency / Data Collection IDoc Monitoring Message Type, Basic Delta Number Monitor WE05 Every 15 minutes (IMIDOC01) Type, Partner Number, IDocs in Status “51”Table 4: Business process step 1 – Monitoring objects in SAP Solution Manager2.2.1.4 Further monitoring objects without SAP Solution Manager Monitoring Selection Criteria Alert Analysis Tool on Monitoring Object Satellite System Frequency / Data Collection Number of Scheduling Once per day to scheduling agreements with once per week© 2009 SAP AG page 24/40
  25. 25. Best Practice for Solution OperationsManage Operations for SAP for Automotive Monitoring Selection Criteria Alert Analysis Tool on Monitoring Object Satellite System Frequency / Data Collection agreement releases more than n releases. depending on You should take care release frequency of scheduling agreements having close to 10.000 releases. Number of Scheduling Once per day to document flow agreements with once per week entries more than n document flow entries Outdated scheduling Are there relevant Once per day to lines scheduling lines with once per week a delivery date < today? Difference between Is the target quantity Once per day to target quantity and less than the once per week cumulative delivered cumulative delivered quantity quantity?Table 5: Business process step 1 – Further monitoring objects without SAP Solution Manager2.2.1.5 Monitoring without SAP Solution ManagerIn 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 delivery2.2.2.1 DescriptionGeneral informationThere 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 25/40
  26. 26. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveTo 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.Sample scenario specific informationThe 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.2.2.2.2 Monitoring requirementsError monitoringIt 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 monitoringPerformance problems can lead to a delayed creation of deliveries. Missing or delayed data could causeover-stock situations and bad customer satisfaction.Throughput monitoringFor 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 monitoringThe deliveries have to be processed in a timely manner. Especially the shop floor performance is critical.2.2.2.3 Monitoring objects in SAP Solution Manager Monitoring Selection Criteria Alert Analysis Tool on Monitoring Object Satellite System Frequency / Data Collection Background Jobs for Job Name, Start Time Start Delay, SM37 every 5 minutes delivery creation Maximum Duration, during every job Cancellation execution Throughput: Shipping Point, Outbound Deliveries VL03 Daily Deliveries Delivery Type, Data (created) (KPLE0001) from prev. day, Created by Backlog: Deliveries Shipping Point, Outbound Deliveries VL03 Daily (KPLE0001) Delivery Type, Data (Overdue) from prev. day, Created by Errors: Due List Log Due List Type = No documents V_SA Daily Delivery, User, created, No. of© 2009 SAP AG page 26/40
  27. 27. Best Practice for Solution OperationsManage Operations for SAP for Automotive specific messages Errors: Update Object Type, Object No. of Errs for Red SM13 N.A. Errors Name (Upd1) Performance Transactions used for Response Time STAD Daily manual delivery creation like VL01NTable 6: Business process step 2 –Monitoring objects in SAP Solution Manager2.2.2.4 Further monitoring objectsCheck hourly in transaction ST22 whether short dumps occurred for the delivery process.2.2.2.5 Monitoring without SAP Solution ManagerYou 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 transport2.2.3.1 DescriptionGeneral informationThe 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.Sample scenario specific informationIn 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 27/40
  28. 28. Best Practice for Solution OperationsManage Operations for SAP for Automotivetransport, 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.2.2.3.2 Monitoring requirementsError monitoringIt 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 monitoringAll 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.2.2.3.3 Monitoring objects in SAP Solution Manager Monitoring Selection Criteria Alert Analysis Tool on Monitoring Object Satellite System Frequency / Data Collection Throughput: TransportPlanPt, Shipments Created VT20 Once per day Shipments Shipment type, Data from previous day Throughput: TransportPlanPt, Shipments (overdue) VT20 Once per day Shipments Shipment type, Overdue sinceTable 7: Business process step 3 – Monitoring objects in SAP Solution Manager2.2.3.4 Monitoring without SAP Solution ManagerCheck daily in the overall shipment status monitor (transaction VT20) whether all shipments have beenprocessed as intended.2.2.4 Business process step 4: Create invoice2.2.4.1 DescriptionGeneral informationThe 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 28/40
  29. 29. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveAll 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.Sample scenario specific informationThe 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.2.2.4.2 Monitoring requirementsError monitoringInvoices 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 monitoringIt is vital to ensure customer and end user satisfaction for the performance for transaction VF01.Throughput monitoringFor 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 monitoringInvoices 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 requirementsYou 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 29/40
  30. 30. Best Practice for Solution OperationsManage Operations for SAP for Automotive2.2.4.3 Monitoring Objects in SAP Solution Manager Monitoring Selection Criteria Alert Analysis Tool on Monitoring Object Satellite System Frequency / Data Collection Background Job Job Name, Start Time Start Delay, SM37 every 5 minutes Maximum Duration during every job Cancellation execution Backlog: SD Billing Type, Billing SD Invoices not VF03, VFX3 Daily Invoices (AR) Cat., Sales Org, Dist. posted to FI (KPSD0002) Channel, Division, Created by, older than x days Throughput: SD Billing Type, Billing Sales invoices posted VF03 Daily Invoices (AR) Cat., Sales Org, Dist. per day (KPSD0002) Channel, Division, Created by, data from prvious day Errors: Update Object Type, Object No. of Errs for Red SM13 N.A. Errors Name (Upd1) Performance: Transaction ResponseTime STAD N.A. Performance Monitor (BOPERFMO) or Dialogue Performance Throughput: Due Due List Type = No documents VF04, VF03 N.A. List Log “Billing”, Aggregation: created “per log” Errors: Due List Log Msg Type = E, A No of specific VF04, VF03 N.A. Msg ID = ‘*’ messages Msg. No = ‘*’* Backlog: Messages Application, message Not processed every 5 minutes (Output type, transm. messages Determination) Medium, dispatch (KWMSG001) time, partner function, message partner, output device, print immediately, user name, older than x days Errors: Messages Application, message Incorrectly processed Report RSNAST0F every 5 minutes (Output type, transm. messages Determination) Medium, dispatch (KWMSG001) time, partner function, message partner, output device, print immediately, user name, older than x daysTable 8: Business process step 4 – Monitoring objects in SAP Solution Manager© 2009 SAP AG page 30/40
  31. 31. Best Practice for Solution OperationsManage Operations for SAP for Automotive2.2.4.4 Further monitoring objectsCheck daily in transaction ST22 whether short dumps related to the invoice creation exist.2.2.4.5 Monitoring without SAP Solution ManagerCheck 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 jobsJob scheduling requirementsRecommended or ABAP Variant Sche- Prede- Succes Scheduling ErrorGenerated Job Name Report duling cessor sor Restriction Hand¬ling in Job Job Case of CancellationS_<SIDCLIENT> RV60SBA Daily After delivery_<COUNTRY>_SALES T creation_RV60SBAT_<SALESORG>_DTable 9: Business process step 4 – Job scheduling requirements© 2009 SAP AG page 31/40
  32. 32. Best Practice for Solution OperationsManage Operations for SAP for Automotive3 Further Information3.1 TroubleshootingIf 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 DocumentsThere 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 to create a general Business Process Management concept. This includes the definition and documentation of the core business processes, definition of monitoring objects, definition of monitoring activities including error handling procedures, monitoring tools, monitoring frequencies, the definition of communication and escalation procedures and the assignment of responsibilities. ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus on ALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitor ALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoring approaches 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 recommends as a standardized formal process to support a job request process, including an end user job request form and an approval process. This integrated process will avoid error-prone and time intensive manual processes of copying redundant data from one data source to another (for example, MS excel to MS Excel or MS Excel to job scheduling tool). SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a Business Process Monitoring concept for your SAP ERP solution. The concept aims to define procedures for business process oriented monitoring and error handling and escalation procedures for your company’s ERP core business processes. These procedures intend to ensure a smooth and reliable flow of the core business processes so that your business requirements are met. Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set up background job monitoring properly in the framework of Business Process Monitoring in the SAP Solution Manager.Please note that these documents are also available in the SAP Service Marketplace using alias RunSAPRun SAP Best Practices.3.3 LiteratureFor detailed information on how to administer an SAP R/3 system, see the book: SAP R/3 System Administration by Liane Will, 2003For information on how to monitor and tune the general system performance, see the book: SAP Performance Optimization Guide by Thomas Schneider, 2006For 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)© 2009 SAP AG page 32/40
  33. 33. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveFor 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 Corinna Weidmann and Lars Teuber, 2009 (currently only available in German)© 2009 SAP AG page 33/40
  34. 34. Best Practice for Solution OperationsManage Operations for SAP for Automotive4 AppendixIn the following section, you find examples on how to set up monitoring within SAP Solution Manager.4.1 Examples for recommended Monitoring Objects4.1.1 Example Background Job MonitoringBackground 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_MFigure 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 34/40
  35. 35. Best Practice for Solution OperationsManage Operations for SAP for Automotive On the Job Cancellation tab, you can define whether a yellow or a red alert should be raised when the job is cancelled.Figure 14: Background job monitoring – Define alerts Once you have entered all relevant information for the monitoring objects, generate the monitoring customizing and activate the monitoring within the Business Process Monitoring session.4.1.2 Example ABAP Dump MonitoringThere 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 35/40
  36. 36. Best Practice for Solution OperationsManage Operations for SAP for Automotive Enter a wildcard in fields Runtime Error and Program, since the program can call another FB and the runtime error can be different for each of the called function modules. In our example all runtime errors for users 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 dayFigure 18: ABAP dump monitoring – Define monitoring schedule (1) Once you have entered all relevant information for the monitoring objects, generate the monitoring customizing and activate the monitoring within the Business Process Monitoring session.4.2 Background JobsCertain 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 36/40
  37. 37. Best Practice for Solution OperationsManage Operations for SAP for Automotivejobs 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 jobsIn 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 fully defined. In the case of status Released, the job has been fully defined including a start condition and waits for the condition to fulfill. In the case of status Ready, the start condition of a released job has been met. A job scheduler has put the job in line to wait for an available background work process. In the case of status Active, the job is running and cannot be modified or deleted. Check if the job is within the given timeframe, depending on the data volume to be processed. Check for particular dependencies on 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. Program scheduling management has to check whether the job has run in the given timeframe, and software monitoring 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 following reasons: If an administrator intentionally cancelled the job, clarify why it was necessary to do that and whether (and when) the job has to be re-run. If a program in a job step produced an error such as issuing an ‘E’ or ‘A’ error message, contact the software monitoring team and investigate why the error occurred. In case of an SAP standard program, search for appropriate messages in SAP Net and open a customer message if you cannot solve the problem.Job restartIn 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 proceduresIf 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 37/40
  38. 38. Best Practice for Solution OperationsManage Operations for SAP for AutomotiveIndex 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) ............................................................36Index 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 38/40
  39. 39. Best Practice for Solution OperationsManage Operations for SAP for Automotive© 2009 SAP AG page 39/40
  40. 40. Best Practice for Solution OperationsManage Operations for SAP for Automotive© 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 tradem arks 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 tradem arks 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 agreem ent 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-infringem ent.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.© 2009 SAP AG page 40/40

×