• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
011000358700001130032008 e manage operations for sap for retail pos inbound
 

011000358700001130032008 e manage operations for sap for retail pos inbound

on

  • 1,783 views

 

Statistics

Views

Total Views
1,783
Views on SlideShare
1,783
Embed Views
0

Actions

Likes
0
Downloads
42
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    011000358700001130032008 e manage operations for sap for retail pos inbound 011000358700001130032008 e manage operations for sap for retail pos inbound Document Transcript

    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound Dietmar-Hopp-Allee 16 D-69190 Walldorf CS STATUS internal final DATE VERSION DEC -17 2007 1.0 SOLUTION MANAGEMENT PHASE SAP SOLUTION Operations & Continuous Improvement Best Practices for Solution Operations TOPIC AREA SOLUTION MANAGER AREA Application & Integration Management Business Process Operation
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundDate Alteration Reason VersionDec 1, 2008 Creation 0.1Dec 17, 2008 Finalization 1.0Table of Contents1 Management Summary 5 1.1 Goal of Using this Best Practice 5 1.2 Alternative Practices 5 1.3 Staff and Skills Requirements 5 1.4 System Requirements 6 1.5 Duration and Timing 6 1.6 How to Use this Best Practice 6 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 7 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 11 1.7.4.6 Due List Log 12 1.7.4.7 Application Log 13 1.7.4.8 Other CCMS Monitors 14 1.7.4.9 Analysis and Monitoring Tools 15 1.7.4.10 Monitoring Activities 17 1.7.4.11 Notifications 17 1.7.5 Business Process Monitoring Process 18 1.7.6 Legend 192 Business Process Monitoring for POS Inbound 20 2.1 Business Process POS Inbound 20 2.1.1 Business Process Step 1: Poll and Send Sales Data 21 2.1.1.1 Description 21 2.1.2 Business Process Step 2: Receive, Transform and Send Information 21 2.1.2.1 Description 21 2.1.3 Business Process Step 3: Process Sales Data (P01) 21 2.1.3.1 Description 21 2.1.3.2 Monitoring Requirements: 22 2.1.3.3 Monitoring Objects in SAP Solution Manager 22 2.1.3.4 Monitoring without SAP Solution Manager 23 2.1.3.5 Scheduling of Background Jobs 23 2.1.4 Business Process Step 4: PIPE Processing (P02) 23© 2008 SAP AG page 2/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 2.1.4.1 Description 23 2.1.5 Business Process Step 4a: Checks and Verification in PIPE 24 2.1.5.1 Description 24 2.1.5.2 Monitoring Requirements 24 2.1.5.3 Monitoring Objects in SAP Solution Manager 24 2.1.5.4 Further Monitoring Objects 25 2.1.5.5 Monitoring without SAP Solution Manager 25 2.1.6 Business Process Step 4b: Jobs in One-step Processing 25 2.1.6.1 Description 25 2.1.6.2 Monitoring Requirements: 26 2.1.6.3 Monitoring Objects in SAP Solution Manager 26 2.1.6.4 Monitoring without SAP Solution Manager 26 2.1.6.5 Scheduling of Background Jobs 26 2.1.7 Business Process Step 4c: Jobs in 2-step Processing 27 2.1.7.1 Description 27 2.1.7.2 Monitoring Requirements: 27 2.1.7.3 Monitoring Objects in SAP Solution Manager 27 2.1.7.4 Monitoring without SAP Solution Manager 28 2.1.7.5 Scheduling of Background Jobs 28 2.1.8 Business Process Step 4d: The Message Log Application 28 2.1.8.1 Description 28 2.1.8.2 Monitoring Requirements: 29 2.1.8.3 Monitoring Objects in SAP Solution Manager 29 2.1.8.4 Further Monitoring Objects 29 2.1.8.5 Monitoring without SAP Solution Manager 30 2.1.8.6 Scheduling of Background Jobs 32 2.1.9 Business Process Step 4e: Data Consistency between POS System and PIPE 33 2.1.9.1 Description 33 2.1.9.2 Monitoring Requirements: 33 2.1.9.3 Monitoring Objects in SAP Solution Manager 34 2.1.9.4 Further Monitoring Objects 34 2.1.9.5 Monitoring without SAP Solution Manager 34 2.1.9.6 Scheduling of Background Jobs 35 2.1.10 Business Process Step 5: Send Data to SAP for Retail (P03) 35 2.1.10.1 Description 35 2.1.10.2 Monitoring Requirements: 36 2.1.10.3 Monitoring Objects in SAP Solution Manager 36 2.1.10.4 Further Monitoring Objects 37 2.1.10.5 Monitoring without SAP Solution Manager 37 2.1.10.6 Scheduling of Background Jobs 37 2.1.11 Business Process Step 6: Post data within SAP for Retail (PO4) 37 2.1.11.1 Description 37 2.1.11.2 Monitoring Requirements: 38 2.1.11.3 Monitoring Objects in SAP Solution Manager 38 2.1.11.4 Monitoring without SAP Solution Manager 39 2.1.11.5 Scheduling of Background Jobs 39© 2008 SAP AG page 3/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 2.1.12 Business Process Step 7: Update BI Info Cubes (P05) 39 2.1.12.1 Description 39 2.1.12.2 Monitoring Requirements: 40 2.1.13 Business Process Step 8: Update SAP F&R (P06) 40 2.1.13.1 Description 40 2.1.13.2 Monitoring Requirements: 40 2.1.13.3 Monitoring Objects in SAP Solution Manager 41 2.1.13.4 Further Monitoring Objects 41 2.1.13.5 Monitoring without SAP Solution Manager 41 2.1.13.6 Scheduling of Background Jobs 41 2.1.14 Business Process Step 9: Extraction of Master Data for BI (P07) 42 2.1.14.1 Description 423 Further Information 43 3.1 Troubleshooting 43 3.2 Related Best Practice Documents 43 3.3 Literature 43 3.4 Feedback and Questions 444 Appendix 45 4.1 Example Background Job Monitoring 45 4.2 Example PI Message Process Monitoring 46 4.3 Example ALE / IDoc Monitoring 46 4.4 Example Dialog Performance Monitoring 49 4.5 Example Application Log Monitoring 50 4.6 Background Jobs 51© 2008 SAP AG page 4/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound1 Management Summary1.1 Goal of Using this Best PracticeThis Best Practice helps you to set up a Business Process Monitoring concept for your SAP Retail solution.The concept aims to define procedures for business process oriented monitoring and error handling andescalation procedures for your business process “POS Inbound”. These procedures intend to ensure asmooth and reliable flow of this core business process so that your business requirements are met.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 the SAPSolution Manager for the Monitoring functionalities. But even if you do not use the 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 engagement with SAP, it is also possible to get assistance by SAPexperts from SAP Consulting. If 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)SAP 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. Often he is 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, quicklink /BPM.© 2008 SAP AG page 5/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundNecessary 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 Retail solution via SAP Solution Manager, theSAP Basis Release of the systems to be monitored have to be at least 4.6C. To have all described monitoringobjects available in SAP Solution Manager, the add-on ST-A/PI01L has to be installed on the SAP Retailsystem.1.5 Duration and TimingDurationCreating a Business Process Monitoring concept could take around one week per business process.Implementing the Business Process Monitoring concept might take 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. 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: Error monitoring Performance monitoring Throughput monitoring© 2008 SAP AG page 6/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound Backlog monitoring 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 Retailsolution 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.The core business processes that are implemented in a SAP Retail system or other software and operated bya company are of particular importance, and Business Process Monitoring is intended to ensure a smoothand reliable operation of the business processes and, thereby, that the core business processes meet acompany’s business requirements in terms of stability, performance, and completeness. The 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 the SAP Solution Manager. These alertsare then visualized by green, yellow, and red alert icons for each individual business process step in thegraphical business process representation. Business Process Monitoring is intended to detect and respond tocritical situations as early as possible in order to solve problems as fast as possible.In addition, the SAP Solution Manager offers extended functionality for error handling and problem resolution.By the 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 the SAPSolution Manager. The below mentioned Monitoring Types are available:© 2008 SAP AG page 7/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound Application Monitor (Throughput and Backlog Indicators, Data Consistency Checks, Mass Activity Monitors, Due List Log, MRP key figures, User Exit) Background Jobs (Jobs running on SAP Systems with an SAP Basis) 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 the SAPSolution Manager, 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 the SAP Solution Manager isthat all business processes and business process steps are maintained in the respective solution thatcontains all affected system components. If you want to learn more about how to set this up, please turn to(URL http://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 ProcessMonitoring. The latest Monitoring objects are only provided if the latest ST-A/PI plug-in is installed on thesatellite 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 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).1.7.4.1.1 Throughput and Backlog Indicators (TBIs)As of ST-A/PI 01H a completely new set of Application Monitors has been introduced. While the alreadyestablished monitors are all evaluating specific logs or performance data these new monitors are considering(un-)processed documents in the SAP system and provide so called Throughput and Backlog Indicators.These TBIs should 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)© 2008 SAP AG page 8/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 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’(URL http://www.service.sap.com/BPM Media Library).1.7.4.1.2 SAP Retail Data ConsistencyThe DCC collectors for Retail are data collectors to retrieve a stored comparison result from an SAP ERPRetail system.There are certain consistency check programs, that can compare Retail-specific data between the SAP ERPRetail system and an SAP SCM system. These comparison programs are able to output their check result notonly to a list or into the spool, but can also permanently store a summary to the ST-A/PIs cluster table. Thesemonitoring objects can be configured to retrieve the number of found inconsistencies out of the storedsummary information and display that as alerts within the SAP Solution Manager Business ProcessMonitoring (Consistency Monitoring).Information about Data Consistency Checks are described in detail in the Setup Guide – Data ConsistencyMonitoring (URL http://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 a BestPractice document ‘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 Back Order Processing and Material Requirements Planning should not run at the sametime) 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.1.7.4.2.1 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 specialbackground job or a group of background jobs. This information needs to be maintained in the sub-node‘Background Job’ below a business process step.A more detailed description (than provided in this document) on the subject what kind of alerts make sense orwhat kind of alerts are possible are discussed in the Best Practice document “Background Job Monitoringwith SAP Solution Manager” which can be found on the SAP Marketplacehttp://service.sap.com/solutionmanagerbp Topic Area “Business Process Operation”.1.7.4.3 ABAP Dump CollectorTo provide monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors or tocollect statistical data of ABAP dumps for reporting reasons.© 2008 SAP AG page 9/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound1.7.4.3.1 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 which leads to the runtime error.1.7.4.3.2 Monitoring AlertsPossible Alerts 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.1.7.4.4 Dialog PerformanceDialog Performance implies the monitoring of the dialog transaction performance of any transaction in theSAP System. This could be a standard transaction or an own developed transaction.1.7.4.4.1 Monitoring ObjectsThe monitoring object is the transaction itself. The customizing has to be done in node ‘Dialog Performance’.In table ‘Transactions’ all transactions that are already configured to that business process step are listed.The relevant transactions need to be selected for monitoring. It is also possible to add or to removetransactions within table ‘Add/Remove Transactions’. The monitoring can be performed per SAP instance.Therefore the respective instances have to be selected in table ‘SAP Instances’. All instances that aremaintained for a system are listed there. Table ‘Alert Types’ shows the dialog response time and all parts ofthe response time, like queue time, load and generation time, database request time and the front-endresponse time, that can be monitored. Those times that are relevant for monitoring have to be selected.After saving this node a sub-node ‘Performance Alerts’ will appear where the threshold values have to beentered.© 2008 SAP AG page 10/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundMonitoring Objects – Dialog Performance1.7.4.4.2 Monitoring AlertsEach table in the sub-node ‘Performance Alerts’ 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 should be included in the monitoring, thethreshold values resulting in alert messages for changes from GREEN to YELLOW, from YELLOW to RED,back from RED to YELLOW, and back from YELLOW to GREEN have to be specified.Since the Monitoring Object for Performance Monitoring is created on the satellite system, it might bepossible that the object already exists there. Therefore you can load the current threshold values from therespective systems via the button "Load thresholds from XYZ", whereas “XYZ” represents the SID.If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for thethreshold values were found for a certain transaction code, default values are set (indicated in column"Default"). To transfer the threshold values for a single line from right to left, the copy icon can be used. Totransfer all at once (all thresholds for all columns and tables) there is an additional button "Copy all".Monitoring Alerts - Dialog Performance1.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.© 2008 SAP AG page 11/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundThe SAP System makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2)update errors. This distinction allows the system to process critical database changes before less criticalchanges.V1 modules describe critical or primary changes; these affect objects that have a controlling function in theSAP System, for example order creation or changes to material stock.V2 modules describe less critical secondary changes. These are pure statistical updates, for example, suchas result calculations.1.7.4.5.1 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 a user executing the transaction or the ABAP program can be specified.If no user is specified explicitly, all users (represented by *) will be considered in monitoring data evaluation.Monitoring Objects - Update Errors1.7.4.5.2 Monitoring 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 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 that© 2008 SAP AG page 12/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inboundneed 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, it can be displayed in the due list log for this billing run.1.7.4.6.1 Monitoring ObjectsThe monitoring object is the respective due list type. That can be ‘Delivery’, ‘Billing’ or ‘Picking’. If a certainuser is processing the due list, the name of the user can be specified here. If it is user independent a wildcard ‘*’ can be used. The aggregation level needs to be defined. This could be ‘per day’, ‘per hour’ or ‘perlog’.1.7.4.6.2 Monitoring AlertsFor the monitoring of due list log messages, four different alert types can be used: 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. 4. 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. 5. ‘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 wild cards. 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.1.7.4.7 Application LogThe Application Log provides an infrastructure for collecting messages, saving them in the database anddisplaying them as a log. Situations can arise at runtime in application programs that must be brought to theattention of the user in some way. These are usually errors. It can also be useful to report a successfulcompletion. The information that arises is called a message. The set of messages is a log. A log usually alsohas header information (log type, creator, creation time, etc.). A transaction can generate several logs.The Application Log is not written consecutively but as a whole at one point in time.1.7.4.7.1 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 (and/or subobject) can be found in transaction /nSLG1 together with all otherspecific information to that log.© 2008 SAP AG page 13/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundMonitoring Objects and Alerts - Application LogIt is possible to monitor for the total number of messages belonging to an object. Therefore the number ofmessages that raises a YELLOW alert and the number of messages changing from a YELLOW to a REDalert must be maintained.It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs. Toconfigure the monitoring of critical application log messages, the relevant object-sub object combinationsneed to be selected. For each of these combinations the message type, the message ID and the messagenumber as well as the threshold values for the number of critical messages that are supposed to result inchanges from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wildcards.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 monitoring tree element (MTE) can be found by choosing F1. The MTE name needs to becopied into the corresponding column of the table below (See screenshot “Other CCMS Monitors” below).Under column Monitor Name it is possible to assign an individual name.© 2008 SAP AG page 14/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound The MTE used for monitoring should be a MTE on the lowest leaf-level, i.e. on attribute level. If a 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 it isn’t possible to work on 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, the button can be used.If successfully retrieved, the values are filled in the right-hand columns. If no active settings for the thresholdvalues were found these columns remain empty.To transfer the thresholds values for a single line from right to left double-click on the copy icon.Other CCMS Monitors Unlike all other Monitoring Types the Other CCMS Monitoring provides the opportunity to assign MTEs from other Systems than the one system the actual business process step is assigned to.As an example you could be interested in monitoring the availability from a Portal system that possesses noCCMS but is included as one business process step in your business process. Now you could use one MTEin the CCMS of the SAP Solution Manager to monitor the heartbeat of the Portal. You could then assign thecorresponding alert via Other CCMS Monitoring to business process step running on the Portal system.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 itself (Call Option “1”) or directly in the respective satellite systems (CallOption “2”). Per default some standard transactions are maintained, e.g. transaction SM37, that provides ajob overview in an SAP System, is maintained for Background Jobs or transaction SLG1 to have a look intothe application log.It is also possible to add new transactions; this could be standard transactions or customer self-writtentransactions.© 2008 SAP AG page 15/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundAnalysis & Monitoring TransactionsOn the second tab strip it is possible to specify an URL which should be called in order to further analyze thegiven problem. This is especially interesting if you have some knowledge documents linked to a portal. Youdefine a Short text and the URL to be called. For web pages to be called, specify the full URL, e.g. http://help.sap.com. For content available on file servers specify the full file path, using the nomenclature: file://<server>..., e.g. file://server1operations_documentsoperations-handbook.txtAnalysis & 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. By pressing thesebuttons (e.g. ), the user will jump directly into the corresponding transactioneither in the SAP Solution Manager system (here: SAT) or the connected satellite system (here: CT1) forfurther analysis. For URLs the push-button (e.g. ) contains the Short text (limited to20 characters) from the Set-up session and leads the user to the defined URL in a newly opened browserwindow.© 2008 SAP AG page 16/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound1.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 here. To ensure effective monitoring andefficient problem resolution the responsibilities should be assigned and problem resolution procedures shouldbe defined as described in the following table. Some information is taken from the previous node ‘SolutionSupport Organization’. 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/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.Additional information related to this business process step can be entered in the tables ‘MonitoringActivities’, ‘Error Handling’, ‘Restart of Step’ and ‘Escalation Path’. Those information would be valid for thewhole business process step and helps users who have to carry out the monitoring and who are not sofamiliar with that particular business process.1.7.4.11 NotificationsNotifications can be set up for the whole business process or for each business process step individually.There are two types of notifications: Workflow notifications and Support notifications. Workflow notificationsallow sending messages in case of alerts to a specified Recipient. This could be an e-mail or SAPOffice mail.Support notifications allow setting up a service desk message in case of an alert. The information entered forthe service desk message serves as a template. The service desk message can be created manually orautomatically.On business process level it is possible to define notifications for the whole business process i.e. as soon asthe business process gets an alert status, notifications will be triggered. Alternative notifications can bedefined for every Monitoring Type individually, e.g. all alerts related to all background jobs of the businessprocess are forwarded to a defined e-mail address.Notifications defined on business process step level will overrule the configuration made on business processlevel for this particular step.1.7.4.11.1 Workflow Notification Sender Must be a user within in the monitoring client of SAP Solution Manager. This user can be even a system user without any roles or profiles, but the user must have a valid e-mail address that is known by the used mail-server Recipient Depending on the Recipient Type the recipient name is required. This could Address be any e-mail address, an SAP user name in the same system, a Remote© 2008 SAP AG page 17/53
    • Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 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 5 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 may occur before an automatic notification is Alerts triggered No. of Red Alerts Number of RED alerts that may occur before an automatic notification is triggered Max Wait Time Once the maximum wait time [hours] has elapsed, a notification is created, [h] even if the thresholds are not exceeded RED Only To restrict this mechanism only to red alerts the flag in column RED Only must be set. Detailed Triggers a long text for e-mails or SAPOffice mails, e.g. name of the solution, name of the business process step, …)1.7.4.11.2 Support Notifications Priority Defines the priority of the Support Notification. Queue Defines the support component on which the message is put. This component must exist within the service desk. Processor Defines a default processor who should process the message. The processor must be known within the service desk and must be SAP user name who is 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 when service desk messages are created automatically. Must be a SAP user name who is defined as a Business Partner with role “General”. Num. of YELLOW Necessary when service desk messages are created automatically, e.g. after Alerts 10 yellow alerts a service desk message should be created. Num. of RED Necessary when service desk messages are created automatically, e.g. after Alerts 5 red alerts a service desk message should be created. If in addition to queue, processor, priority and reporter either one of the columns “Num of 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 either exist more than 9 yellow alerts OR more than 4 red alerts for which no Support Notification has been created yet. 1.7.5 Business Process Monitoring Process For a successful and efficient Business Process Monitoring concept, a process for the execution of the monitoring concept has to be defined. This includes the definition of the roles and responsibilities involved. It has to be defined who is supposed to carry out which activity within the process and how communication between the different roles within the support organization is supposed to take place. © 2008 SAP AG page 18/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundA Business Process Monitoring concept has to be tightly integrated with the support organization. Thisincludes the integration with the Incident/Problem Management process and the Change Managementprocess. These processes have to be adjusted to the Business Process Monitoring concept so thatcommunication and escalation procedures contained within these processes are adequate to support theBusiness Process Monitoring concept. This includes the final communication of open alert 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 above mentioned separate Best Practice for General Business Process Management forfurther details.1.7.6 Legend This symbol indicates you a paragraph from where you can navigate to another chapter of this document for more detailed information on a topic. This symbol indicates you a paragraph from where you can navigate to another document within the SAP Service Marketplace for more detailed information on a topic.© 2008 SAP AG page 19/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound2 Business Process Monitoring for POS Inbound2.1 Business Process POS InboundPOS Inbound is the process in which data collected at the Point of sale (POS) is transferred to a centralsystem for subsequent processing. The POS Inbound process is extremely critical in a Retail environmentbecause the core function of a retail system is to manage the distribution of goods to the customer. Thedistribution is mainly influenced by stock levels in the Point of sale (POS) and the calculated requirements foreach POS. The stock levels are managed in SAP ERP for Retail and updated by goods movements andsales activities carried out at the POS. Based on this data, replenishment requirements are calculated on acentral system. In order to avoid expensive surplus or out of stock situations at the store, it is obvious that thepassage of the sales information from the POS System to ERP and to potentially a Forecast &Replenishment tool has to be secured and closely monitored. Besides the update of stock levels, financialaspects also play an important role in this process as it is at the POS where retailers earn their money.Missing data can therefore cause serious irritations in subsequent applications as the turnover reporting maynot reflect the real life showing mainly lower results and results in FI are also not correct. It is vital to theretailers business that no data is lost on the way.The complexity of this process involving various systems and processes underlines the importance of a welldefined monitoring and scheduling landscape. Sales transactions are usually registered at the POS Systemlocated in the stores. This information is extracted on a regular basis (ranging from every x seconds to once aday) and transferred via an EAI middleware and transformation tool to POS Data Management’s centralcomponent called PIPE (POS Inbound processing engine). Within this tool the incoming data is verified andposted to subsequent applications. The design of PIPE allows to process data for each subsequentapplication either immediately or as a bulk process with a self-defined frequency and a customizedaggregation level. Whereas data is mostly transferred in detail to SAP BI to enable detailed analysis and datamining, the data is aggregated by date, store and article in order to update follow-on applications such asSAP for Retail. The most common subsequent applications are SAP BI, SAP ERP and SAP F&R. The flexibledesign of PIPE however enables the possibility to provide other applications in an efficient way. Apart fromsales data, other data generated at the POS such as goods movements or financial transactions as well asstatistical information can be transferred using the same path as the sales data.© 2008 SAP AG page 20/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound2.1.1 Business Process Step 1: Poll and Send Sales Data2.1.1.1 DescriptionGeneral Information:POS Data is generated at a cash desk system in the store. Depending on the product chosen, the recordingapplication can be a thin client without an own database or a full-blown backend system. The sales data canbe either transferred real-time, near real-time meaning every couple of minutes or once a day in a bulkprocess.Depending on the chosen solution and scenario, monitoring requirements can vary. The most commonchallenge in this part of the process is the ability to remotely monitor the high number of cash desk systems inthe environment. It is important to know whether the stores are capable of sending data to the central system.This is why an efficient availability monitoring should be set up that regularly reaches out to the disparateend-points.Example:A Retailer having 800 stores that transfer sales data every 3 minutes in order to enable near real-time stockavailability checks would need an almost unmanageable effort to identify missing transactions if no efficientavailability and status monitoring is set up. The result would be inaccurate stock information.Due to the large variety of possible implementations no general documentation of monitoring can be madeavailable.2.1.2 Business Process Step 2: Receive, Transform and Send Information2.1.2.1 DescriptionGeneral Information:Most cash desk systems are not capable of managing data collection and transfer to a central system in aformat supported by PIPE. That is why in most cases an EAI tool such as SAP PI serves as the middlewareto connect to the disparate stores and takes care of the mapping between the cash desk system’s format andthe PIPE Inbound format. Errors in the actual data transfer and data transformation (mapping) need to betightly monitored to alert expected delays in processing.Example:The local cash desk system stores the transaction data in an own database. SAP PI can be used to transferthe data to a central system and to take care of the mapping. Error messages due to erroneous content ortechnical issues need to be monitored and problems solved as soon as possible.Due to the large variety of possible implementations no general documentation of monitoring can be madeavailable.2.1.3 Business Process Step 3: Process Sales Data (P01)2.1.3.1 DescriptionGeneral Information:Depending on the cash desk systems’ capabilities to send data and the EAI tool used, the following inboundpossibilities can be used to send data to PIPE: 1. IDoc /POSDW/POSTR_CREATEMULTIPLE (other IDoc types such as WPUBON for detailed sales data or WPUUMS for aggregated sales data are possible in PIPE Inbound but not recommended as they do not support the full potential of analysis that can be carried out on detailed POS data) 2. BAPI /POSDW/BAPI_POSTR_CREATE 3. RFC enabled Function Module /POSDW/CREATE_TRANSACTIONS_EXT 4. Webservice generated and implemented for function module /POSDW/CREATE_TRANSACTIONS_EXT 5. Generated and implemented Proxy wrapping function module /POSDW/CREATE_TRANSACTIONS_EXT© 2008 SAP AG page 21/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundPIPE stores the transactions in the so called TLOG tables.Example:The cash desk system is connected to a central PI system that collects the point of sale data every 5 minutes.The data is posted to PIPE via RFC. The aim of this near real-time scenario is to enable a near real-timeavailability check and near real-time reporting (a so-called Flash-reporting) in BI., Near real-time data canonly be accurate if the way and the processing are monitored and problems are handled and escalated in anefficient way.2.1.3.2 Monitoring Requirements:Error Monitoring:Depending on the uploading frequency and the technique used, monitoring needs to be enabled on thesending system in case of real-time interfaces (“trickle feed”) or can be carried out in the receiving system(BI) in case of messages stored in bulk, e.g. once every evening.Performance Monitoring:In order to fulfill the requirements for the typically critical time window for processing POS sales data, keyperformance indicators for the performance of processing an average sales transaction (per line item) shouldbe defined and closely monitored. This KPI will also be a basis for throughput monitoring. Depending on thebusiness process implemented, POS inbound processing is the foundation for follow-up processes likereplenishment and logistics execution, whose disruption may jeopardize the flow of merchandise which is aserious negative impact for retailing business.Throughput Monitoring:Based on performance measurements for every single POS transaction line item, throughput keyperformance indicators should be deduced which can be assessed to have an overview of the ability of thesystem to cope with current and future data volume within the critical path of nightly processing, e.g. peaktransactions for retail business during xmas holiday season.Backlog Monitoring:Unprocessed sales transaction data due to erroneous information or interface failures threatens the businessflow in case of subsequent replenishment and logistics process steps. A backlog of information having failedto process therefore needs to be alerted and addressed accordingly.2.1.3.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Tool on Monitoring Satellite System Frequency / Data CollectionIDoc processing status in Direction, Port, Partner Number of IDocs of WE05 or WE02 every 15 minutescase of IDoc interface number, Partner type, type /POSDW/… Partner function, in an error-status Message type, Basic type, Message code, Message function, IDoc ageXML message status in Depends on the special Number of XML SXMB_MONI orEAI in case of XML Scenario messages in error SXI_MONITORinterfaceXML message status in Depends on the special Number of XML SXMB_MONI orBI in case of XML Scenario messages in error SXI_MONITORTORinterface© 2008 SAP AG page 22/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundInbound BAPI call via /POSDW/BAPI_POSTR_ Response time of ST03N, ST05,RFC: CREATE RFC-enabled STAD/POSDW/BAPI_POSTR_ function callCREATE(Application Monitor:Dialog PerformanceMonitor)Background Job POSDW POS2PIPE Job Runtime, job SM37 every 5 minutesPOSDW POS2PIPE POSLOG, or cancellation, error during every jobPOSLOG (Report /POSDW/IDIS, Start messages in Job execution/POSDW/IDIS, variant Time LogTRANS)2.1.3.4 Monitoring without SAP Solution ManagerMonitoring Objects:In the case of IDocs used to transfer POS Data to PIPE, the processing of incoming data can be monitoredusing transaction WE05 or transaction WE02. The IDoc type is should be/POSDW/POSTR_CREATEMULTIPLE, as this IDoc type offers the full functionality of PIPE. If IDocs arecollected and processed with a job, the corresponding job (an instance of program /POSDW/IDIS) shouldthen be monitored in order to identify potential problems.If XML messages are used, transaction SXI_MONITOR or SXMB_MONITOR can be used to see themessage status.2.1.3.5 Scheduling of Background JobsJob Scheduling Requirements:If POS transactions are posted to PIPE via asynchronous messages based on IDocs or XML messages, a jobis required to post this data to PIPE. In the case of IDocs that need to be processed the IDoc Dispatcherwithin PIPE can be used.During PIPE inbound and outbound processing locks are held on date/store level. If an external schedulingtool is used that offers the possibilities of setting logical locks, periodic jobs for inbound and task processingshould not run in parallel. Also user activity such as changing data in the PIPE monitor can temporarily lockdata.Job Scheduling Requirements Recommended ABAP Variant Schedu- Prede- Suc- Scheduling Error Handling in or Generated Report ling cessor cessor Restriction Case of Job Name Job Job CancellationPOSDW /POSDW TRANS Between - Task Not in parallel Can be restarted ifPOS2PIPE /IDIS every x processi with PIPE system errorPOSLOG minutes ng jobs task and daily processing2.1.4 Business Process Step 4: PIPE Processing (P02)2.1.4.1 DescriptionGeneral Information:PIPE processing steps can be classified according to their purpose of 1) Checking and verifying the received data in PIPE, 2) Processing jobs in one-step processing and© 2008 SAP AG page 23/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 3) Processing jobs in two-step processing. Details about monitoring objects and job setup can be found in the following chapters. You will always find a combination of these types of processing steps according to actual customer requirements. The last subchapter describes how to use the message log program to recognize occurring issues 4) Message log applicationAfter loading the transactional data to SAP POS DM the incoming data needs to be validated by use ofverification tasks. After this successful validation the data processing needs to be triggered for eachprocessing step (or so called task) relevant for the actual information. Additionally the reprocessing for datawhich originally had been loaded with missing master data or other issues needs to be triggered.2.1.5 Business Process Step 4a: Checks and Verification in PIPE2.1.5.1 DescriptionGeneral Information:In most common cases, first several validation tasks are executed automatically by PIPE (via immediate taskprocessing) to validate the incoming data: These tasks include one or several task(s) to check the masterdata, the balancing of each ticket (the accumulated sales amount for one transaction must correspond to theamount of the payment types of the same transaction) and duplicate checking (to make sure data is onlyloaded once).After the verification tasks, processing tasks are executed as described in the following chapters.Depending on the nature of the validation tasks, they might be executed immediately (recommended forupdate frequencies below 5 minutes) or scheduled for later processing once or several times a day (Job(POSDW PIPECHECK). This is described in chapter 2.1.6 as this type of processing complies to 1-step-processing). In order to only process correct transactions the result of the verification tasks are usually usedas conditions for the execution of the following processing tasks. These conditions are maintained in PIPEcustomizing for each task to be executed.2.1.5.2 Monitoring RequirementsError Monitoring:In order to check the status of the processing, the PIPE monitor (or POS Workbench) should be opened orrefreshed every x minutes if data is processed on a real-time or near real-time basis. If POS data istransferred only once a day, the monitor should be checked during and after processing.Performance, Throughput and Backlog Monitoring:The requirements of chapter 2.1.3.2 apply for PIPE processing as well.2.1.5.3 Monitoring Objects in SAP Solution Manager Monitoring Selection Alert Analysis Tool on Monitoring Object Criteria Satellite System Frequency / Data CollectionApplication log Object, Sub-object, Error messages SLG1 Every 60 min user, transaction, provided by PIPE Program Dispatcher© 2008 SAP AG page 24/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound2.1.5.4 Further Monitoring Objects Monitoring Object Selection Alert Analysis Tool on Satellite Monitoring Criteria System Frequency / Data CollectionOnline message Error /POSDW/MON0 ormonitoring messages /POSDW/MON2 provided by POS DM validation frameworkTask processing status as Store, Error /POSDW/DISPLAY_MESSAper chapter 2.1.8 Posting messages GELOG Date, provided Message during Class, Message PIPE Type, processing Message number, Message Category, Rule, Message Priority2.1.5.5 Monitoring without SAP Solution ManagerMonitoring Objects:For monitoring the status of the processed transactions, the following monitoring tools can be used: POS Workbench /POSDW/MON0 to provide an online status for all transactions and drill down into the transactions details The application log for details about the actual processing of the outbound data. The job log to identify issues around job processing Report /POSDW/DISPLAY_MESSAGELOG with specific variants to provide summarized processing messages (including error messages). This is described in more detail in chapter 2.1.8.2.1.6 Business Process Step 4b: Jobs in One-step Processing2.1.6.1 DescriptionGeneral Information:After loading the transactional data to SAP POS DM the data processing needs to be triggered for processingsteps (or tasks) configured for batch processing or for data which had been loaded with missing master dataor other issues. Validation tasks are in most cases executed immediately when data arrives (this is set in thecustomizing of the task). In this case a job (job POSDW PIPECHECK) for these validation tasks is onlyrequired to reprocess transaction in error.There can be multiple occurrences of this job depending on the business scenarios configured. In the end itcomes down to four different types of variants: - processing of data directly to the target system or without impact to batch processes - processing of data during batch processing - processing of validation steps© 2008 SAP AG page 25/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound - processing of data into the POS DM aggregate storage, triggering job for outbound processing (check for additional chapter about 2-step processing)Used variants should be configured for the following processing settings: - to process incorrect tasks - to use parallel processing2.1.6.2 Monitoring Requirements:Error Monitoring:The monitoring requirements of chapter 2.1.5 apply for the jobs POSDW PIPECHECK and POSDWPIPESALES.Performance, Throughput and Backlog Monitoring:The requirements of chapter 2.1.3.2 apply for PIPE one-step processing as well.2.1.6.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Monitoring Tool on Frequency / Satellite Data System CollectionBackground Job POSDW POSDW PIPECHECK, or Job Runtime, SM37 Every 5PIPECHECK (Report /POSDW/PIPE_DISPATCHER, job minutes/POSDW/PIPE_DISPATCHER) Start Time cancellation, during every error job execution messages in Job LogBackground Job POSDW POSDW PIPESALES, or Job Runtime, SM37 Every 5PIPESALES (Report /POSDW/PIPE_DISPATCHER job minutes/POSDW/PIPE_DISPATCHER) Start Time cancellation, during every error job execution messages in Job Log2.1.6.4 Monitoring without SAP Solution ManagerMonitoring Objects:The monitoring objects of chapter 2.1.5 apply for the jobs POSDW PIPECHECK and POSDW PIPESALES2.1.6.5 Scheduling of Background JobsJob Scheduling Requirements:The processing within PIPE is triggered by PIPE Dispatcher. There are two variants possible for the 1-step-processing: (Re-)Processing of validation tasks using job POSDW PIPECHECK as part of the daily batch or on a reoccurring basis Processing of 1-step tasks like the supply of data to SAP BI (job POSDW PIPESALES)© 2008 SAP AG page 26/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundScheduling of Background Jobs Recommended ABAP Variant Schedu- Prede- Suc- Scheduling Error Handling in or Generated Report ling cessor cessor Restriction Case of Job Name Job Job CancellationPOSDW /POSD CHECK Daily as Data - - Can be restartedPIPECHECK W/PIPE S part of loading _DISPA batch to SAP TCHER proces- POS sing DMPOSDW /POSD DAILY Daily as Data - - Can be restartedPIPESALES W/PIPE SALES part of loading _DISPA batch to SAP TCHER proces- POS sing DM2.1.7 Business Process Step 4c: Jobs in 2-step Processing2.1.7.1 DescriptionGeneral Information:The data aggregated into the aggregate tables inside POS DM using the PIPE Dispatcher needs to beprovided to the outbound interfaces. This is done using the outbound dispatcher report collecting theaggregated (condensed) data and transforming it into the interface format.Monitoring of the processing is done by checking the processing results in the POS Workbench restricting onaggregates. From a basis perspective the availability of system resources can be monitored as the data isonly mapped and not touched functionally. Errors will only occur on the system level.2.1.7.2 Monitoring Requirements:Error Monitoring:The monitoring objects of chapter 2.4.1 apply for the jobs POSDW PIPEAGG and POSDW OUTBOUND.Performance, Throughput and Backlog Monitoring:The requirements of chapter 2.1.3.2 apply for PIPE two-step processing as well.2.1.7.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Monitoring Tool on Frequency / Satellite Data Collection SystemBackground Job POSDW POSDW PIPEAGG, or Job Runtime, SM37 Every 5 minutesPIPEAGG (Report /POSDW/PIPE_DISPATCHER, job cancel- during every job/POSDW/PIPE_DISPATCHE Start Time lation, error executionR, variant AGGREGATE) messages in Job LogBackground Job POSDW POSDW OUTBOUND, or Job Runtime, SM37 Every 5 minutesOUTBOUND (Report /POSDW/OUTBOUND_DISPATC job cancel- during every job/POSDW/OUTBOUND_DISP HER, Start Time lation, error executionATCHER, variant DAILY messages inSALES) Job Log© 2008 SAP AG page 27/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound2.1.7.4 Monitoring without SAP Solution ManagerMonitoring Objects:The monitoring requirements of chapter 2.1.5 apply for the jobs POSDW PIPEAGG and POSDWOUTBOUND.2.1.7.5 Scheduling of Background JobsJob Scheduling Requirements:The process of adding data to the aggregate tables (job POSDW PIPEAGG) can be done throughout the day.This means that the aggregate tables are built up during intraday processing. At the end of day (during theactual batch run) the POS data is picked up from the aggregates tables and processed to, for example, ERPfor Retail using job POSDW OUTBOUND. This job is running once during batch processing.Scheduling of Background Jobs Recommended ABAP Variant Schedu- Prede- Suc- Scheduling Error Handling in or Generated Report ling cessor cessor Restriction Case of Job Name Job Job CancellationPOSDW /POSD AGGRE Hourly Data POSD - Can be restartedPIPEAGG W/PIPE GATE loading W _DISPA to SAP OUTBO TCHER POS UND DMPOSDW /POSD DAILY Daily as POSD Not in Can be restartedOUTBOUND W/OUT SALES part of W parallel with BOUND batch PIPEA data loading _DISPA proces- GG TCHER sing2.1.8 Business Process Step 4d: The Message Log Application2.1.8.1 DescriptionGeneral Information:After validating and processing the data inside SAP POS DM, the results need to be provided to variousgroups of recipients to follow up occurring errors, either from a business or a technical point-of-view.During task processing, errors are logged as messages in the individual transactions. The program/POSDW/DISPLAY_MESSAGELOG allows to display these messages based on the filter criteria entered.Example:Problems typically occurring in a productive POS DM environment are: - Master data issues (for example, business: missing or incorrect maintenance of articles and sites, technical: missing master data extraction to BI) - POS DM configuration issues - Data consistency issues (for example, store sending transactions where the payments value does not equal the sales value, duplicate transaction postings) - Data completeness issues (for example, transaction sequence number gaps, imbalance of total value of sales and payments against eon of day data provided by the POS) - Technical issues (for example, missing initialization of BI delta queue, table space extension issues, connectivity issues)© 2008 SAP AG page 28/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound2.1.8.2 Monitoring Requirements:Error Monitoring:Transactions reporting errors within the data validation framework of POS DM (which comprises the tasksand checks as described in the previous chapters) need to be followed up because a detected error stops theactual processing of this single sales ticket. With an increasing number of issues identified the total revenuepostings as well as follow on processes like replenishment or store analytics are heavily affected.This leads to a requirement to automatically distribute the detected errors to the responsible departmentsafter the nightly batch run or within defined repetition periods and trigger follow up activities.Performance, Throughput and Backlog Monitoring:These requirements do not apply for message log review.2.1.8.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Monitoring Tool on Frequency Satellite / Data System CollectionBackground Job POSDW ERRLOG POSDW ERRLOG MC01, or Job SM37 Every 5MC01 (Report /POSDW/DISPLAY_MESSAGELOG, Runtime, minutes/POSDW/DISPLAY_MESSAGELOG, Start Time job cancel- during everyvariant MC01) lation, error job messages execution in Job LogBackground Job POSDW ERRLOG POSDW ERRLOG MC02, or Job SM37 Every 5MC02 (Report /POSDW/DISPLAY_MESSAGELOG, Runtime, minutes/POSDW/DISPLAY_MESSAGELOG, Start Time job cancel- during everyvariant MC02) lation, error job messages execution in Job LogBackground Job POSDW ERRLOG POSDW ERRLOG MC03, or Job SM37 Every 5MC03 (Report /POSDW/DISPLAY_MESSAGELOG, Runtime, minutes/POSDW/DISPLAY_MESSAGELOG) Start Time job cancel- during every lation, error job messages execution in Job LogBackground Job POSDW ERRLOG POSDW ERRLOG MC04, or Job SM37 Every 5MC04 (Report /POSDW/DISPLAY_MESSAGELOG, Runtime, minutes/POSDW/DISPLAY_MESSAGELOG) Start Time job cancel- during every lation, error job messages execution in Job Log2.1.8.4 Further Monitoring Objects Monitoring Selection Alert Analysis Tool on Monitoring Object Criteria Satellite System Frequency / Data CollectionTechnical - task Store, Posting Date, Error messages /POSDW/ After night batchprocessing status Message Class, provided by POS DISPLAY_ or after Message Type, DM validation MESSAGE periodically Message number, framework LOG, Variant for executed Message Category, MC01 processing steps Rule, Message Priority© 2008 SAP AG page 29/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundBusiness -task Store, Posting Date, Error messages /POSDW/ After night batchprocessing status Message Class, provided by POS DISPLAY_ or after Message Type, DM validation MESSAGE periodically Message number, framework LOG, Variant for executed Message Category, MC02 processing steps Rule, Message PriorityApplication - task Store, Posting Date, Error messages /POSDW/ After night batchprocessing status Message Class, provided by POS DISPLAY_ or after Message Type, DM validation MESSAGE periodically Message number, framework LOG, Variant for executed Message Category, MC03 processing steps Rule, Message PriorityData consistency Store, Posting Date, Error messages /POSDW/ After night batch- task processing Message Class, provided by POS DISPLAY_ or afterstatus Message Type, DM validation MESSAGE periodically Message number, framework LOG, Variant for executed Message Category, MC04 processing steps Rule, Message Priority2.1.8.5 Monitoring without SAP Solution ManagerMonitoring Objects: 1. Program /POSDW/DISPLAY_MESSAGELOG Project specific enhanced version of the error report Within the provided SAP POS DM delivery an error report for more detailed error reporting is provided as a template. Due to the nature of the report it has not been fully implemented and needs to be adopted to the project requirements, providing for example capabilities to identify sales values related to errors. All statements mentioned above keep their validity. This report can be found under the following report name: /POSDW/DISPLAY_MESSAGES_AGG If you need help in adopting this report please contact SAP Consulting. 2. Task processing status of transactions and related error log messages. 3. Use POS DM message customizing to define message categories and assign messages, additionally a criticality level can be defined per message using the message priority field. Example: (list is not complete, assignment can change for different projects) /POSDW/IMG/ POS Inbound Processing Messages Message Category MC01Technical or system messages (for example, missing delta queue init) MC02Business related messages (for example, master data) MC03Application related messages (for example, missing configuration) MC04Data consistency messages (for example, missing data or store software issues) /POSDW/IMG/ POS Inbound Processing Messages Error Messages for Error Category MC01 Message ID Msg No. Message /POSDW/COMMON 000 System Error - Please Inform System Administration /POSDW/COMMON 000 Error during archiving /POSDW/COMMON 022 Error decrypting payment card number /POSDW/COMMON 023 Invalid payment card GUID during decryption of payment card number© 2008 SAP AG page 30/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound /POSDW/COMMON 024 Error encrypting payment card number /POSDW/COMMON 025 Duplicate payment card GUID during save of encrypted number /POSDW/COMMON 026 Posting error during save of encrypted payment card number MC02 Message ID Msg No. Message /POSDW/CORE 003 Unknown store number &1 /POSDW/CORE 004 Unknown EAN/UPC number &1 /POSDW/CORE 025 Unknown material number &1 MC03 Message ID Msg No. Message /POSDW/AGGREGATION All All messages /POSDW/CORE 007 Unknown sales item type &1 /POSDW/CORE 008 Unknown tax type &1 /POSDW/CORE 009 Unknown discount type &1 /POSDW/CORE 010 Unknown means of payment type &1 /POSDW/CORE 011 Unknown financial transaction type &1 /POSDW/CORE 012 Unknown goods movement type &1 /POSDW/CORE 013 Unknown reason &1 /POSDW/OUTPUT 005 Other internal errors that occurred during preparation of IDoc /POSDW/OUTPUT 006 Message type WPUBON can only contain sales transactions /POSDW/OUTPUT 007 Transactions can only contain data from the same store /POSDW/OUTPUT 008 No logical system exists /POSDW/OUTPUT 009 Message type WPUWBW can only contain goods movement transactions /POSDW/OUTPUT 010 Only sales or goods receipt transactions may be used for the F&R Engine /POSDW/OUTPUT 011 No connection to remote system or destination not maintained /POSDW/OUTPUT 012 Function module does not exist in the remote system /POSDW/OUTPUT 013 Message type WPUTAB can only contain sales transactions /POSDW/OUTPUT 014 Message type WPUFIB can only contain financial transactions /POSDW/OUTPUT 015 Message type WPUUMS can only contain sales transactions MC04 Message ID Msg No. Message /POSDW/ACTION 000 Sum of items does not equal the payment sum /POSDW/CONDITIONS 000 POS transaction for &1, index &2 already exists for &3© 2008 SAP AG page 31/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound with index &4 /POSDW/CONDITIONS All All messages /POSDW/OUTPUT 016 Credit card settlement: Credit card data is incomplete /POSDW/OUTPUT 017 Credit card number incorrect: Card number & does not go with type & /POSDW/OUTPUT 018 Credit card settlement: Amount & in currency & has already been settled /POSDW/OUTPUT 019 Credit card settlement: Amount & in currency & is not authorized /POSDW/OUTPUT 020 Credit card settlement: No data to transfer to external system /POSDW/OUTPUT 021 Credit card settlement: Error in transfer to external system /POSDW/OUTPUT 022 Credit card settlement: Error connecting to the external system /POSDW/OUTPUT 023 Credit card confirmation: Transaction was not settled completely /POSDW/OUTPUT 024 Credit card confirmation: Settlement status initial or incorrect /POSDW/OUTPUT 025 Credit card confirmation: Credit card details incorrect2.1.8.6 Scheduling of Background JobsJob Scheduling Requirements:Scheduling to collect the messages associated with the mentioned monitoring objects should be done afterthe actual inbound processing. In case of intraday processing (for example, POSDW PIPEAGG or POSDWPIPECHECK) the monitoring jobs can be planned according to the processing schedule of the datadistribution jobs.Scheduling of Background Jobs (run these as a chain of job steps) Recommended ABAP Variant Schedu- Prede- Suc- Scheduling Error Handling in or Generated Report ling cessor cessor Restriction Case of Job Name Job Job CancellationPOSDW /POSDW MC01 Daily, 1 /POSDW - Not in parallel Can be restartedERRLOG MC01 /DISPLA hour after /PIPE_D with POS Y_MESS data ISPATC Data Insertion AGELO processing HER in PIPE or G data processing step, restrict data selection variant by date (volume)POSDW /POSDW MC02 Daily, 1 /POSDW - Not in parallel Can be restartedERRLOG MC02 /DISPLA hour after /PIPEDI with POS Y_MESS data SPATCH Data Insertion AGELO processing ER in PIPE or G data processing step, restrict data selection variant by date (volume)POSDW /POSDW MC03 Daily, 1 /POSDW - Not in parallel Can be restartedERRLOG MC03 /DISPLA hour after /PIPEDI with POS© 2008 SAP AG page 32/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound Y_MESS data SPATCH Data Insertion AGELO processing ER in PIPE or G data processing step, restrict data selection variant by date (volume)POSDW /POSDW MC04 Daily, 1 /POSDW - Not in parallel Can be restartedERRLOG MC04 /DISPLA hour after /PIPEDI with POS Y_MESS data SPATCH Data Insertion AGELO processing ER in PIPE or G data processing step, restrict data selection variant by date (volume)2.1.9 Business Process Step 4e: Data Consistency between POS System and PIPE2.1.9.1 DescriptionGeneral Information:After loading the transactional data to SAP POS DM the completeness of this information needs to beconfirmed. This is done to ensure that no transactions or transaction details are lost during the data transfer.Example:A cashier processes 50 transactions during working hours. At the end of day the POS calculates the totalfigures and sends them to SAP POS DM. Within POS DM the validation framework compares the incomingtotals with the collected transactional data.In a second step the check report is going to check for the existence of transactional data and totals for thecurrent date. An error message is provided whenever only one of the data streams has arrived. All situationswhere a store is not communicating at all should be handled within the interface monitoring.Additionally, the sequence of the POS transactions can be verified. In most cases transactions are created ina logical and timely sequence, e.g. starting with 123 and ending with 173. Additionally sequences across daycan be detected, where the day closing transaction number is 173 and the next day’s opening transactionnumber needs to be 174. Depending on the POS solution provided the numbering could be based on Store,POS or different transaction types.2.1.9.2 Monitoring Requirements:Error Monitoring:In order to verify the content of transactions after store closing, the monitoring can be done using the totalsbalancing functionality provided with SAP POS DM. The inbound interface supports the receiving ofcalculated end of day figures for various KPIs like total sales value by sales type or total payment value bypayment type, as well as discounts,taxes and total number of transactions. These will be compared againstthe detailed transactional data by summarizing on the same level of granularity. This can be done onlineusing the POS Workbench or by using a scheduled job to check the messages of the corresponding task.Additionally a check needs to be carried out to verify for each store/day combination if transactional and totalsdata have been received at the end of day.In order to verify the transaction sequence, the monitoring can be done using the sequencing pre-conditionfunctionality provided with SAP POS DM. This is attached against a processing step and will raise a warning© 2008 SAP AG page 33/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inboundmessage against the next transaction after the gap. The processing of the sequencing check task can bedone online using the POS Workbench or by using a scheduled job.Performance, Throughput and Backlog Monitoring:These requirements do not apply for the data consistency check.2.1.9.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Monitoring Tool on Frequency Satellite / Data System CollectionBackground Job POSDW POSDW PIPECHECK, or Job SM37 Every 5PIPECHECK (Report /POSDW/PIPE_DISPATCH Runtime, minutes/POSDW/PIPE_DISPATCHER) ER, Start Time job cancel- during every lation, error job messages execution in Job LogBackground Job POSDW ERRLOG POSDW ERRLOG MC04, Job SM37 Every 5MC04 (Report or Runtime, minutes/POSDW/DISPLAY_MESSAGELOG) /POSDW/DISPLAY_MESS job cancel- during every AGELOG, Start Time lation, error job messages execution in Job Log2.1.9.4 Further Monitoring Objects Monitoring Selection Alert Analysis Tool on Monitoring Object Criteria Satellite System Frequency / Data CollectionOnline totals Error messages /POSDW/MON0 or Onlinebalancing and provided by /POSDW/MON2transaction POS DMsequence validationmonitoring frameworkData consistency - Store, Posting Date, Error messages /POSDW/ After end of daytask processing Message Class, provided by DISPLAY_ processingstatus Message Type, POS DM MESSAGE Message number, validation LOG, Variant MC04 Message Category, framework Rule, Message Priority2.1.9.5 Monitoring without SAP Solution ManagerMonitoring Objects: 1. Online balancing using Totals balancing in the POS Workbench 2. Use the data validation framework in SAP POS DM to balance the transactional data against the provided totals data 3. Use POS DM message log report to check if specific totals balancing errors occurred. List of messages, e.g. to be combined in a message category: Message class: /POSDW/CONDITIONS 003&1: Number of counted items (&2) &3 higher than in totals record (&4) 004&1: Number of counted items (&2) is &3 lower than in totals record (&4) 005&1: Value of counted items (&2) is &3 higher than in totals record (&4) 006&1: Value of counted items (&2) is &3 lower than in totals record (&4)For the sequencing check, the following monitoring objects exist:© 2008 SAP AG page 34/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 1. Use the pre-condition functionality of the POS DM data validation framework to perform sequence checking. 2. Use POS DM message log report to check whether sequencing errors occurred. List of messages, e.g. to be combined in a message category: Message class: /POSDW/CONDITIONS 002 POS transaction &3 is missing: POS &1, type &22.1.9.6 Scheduling of Background JobsJob Scheduling Requirements:Data consistency checking should be run once a day after store closing to make sure that no data got stuckon the way to the center so that follow on processes can rely on this information. The variant for the dataconsistency check should contain the totals balancing task as well as the transaction sequencing task. Thejob name would be POSDW CONSCHECKS.Scheduling of Background Jobs Recommended ABAP Variant Schedu- Prede- Suc- Scheduling Error Handling in or Generated Report ling cessor cessor Restriction Case of Job Name Job Job CancellationPOSDW /POSDW CONSC Daily as Data - - Can be restartedPIPECHECK /PIPE_DI HECKS part of loading SPATCH batch to SAP ER processing POS DMPOSDW /POSDW MC04 Daily, after POSDW - Not in parallel Can be restartedERRLOG MC04 /DISPLA data PIPETO with POS Y_MESS processing TALS Data AGELO Insertion in G PIPE or data processing step, restrict data selection variant by date (volume)2.1.10 Business Process Step 5: Send Data to SAP for Retail (P03)2.1.10.1 DescriptionGeneral Information:The data validated in POS DM needs to be selected, condensed and transferred to the ERP system. Onlyafter having received the full amount of data in ERP, can the replenishment process in ERP begin. It istherefore important that the available time window for this process is kept. The IDoc types generated for SAPfor Retail are:WPUBON for detailed transaction dataWPUUMS for aggregated sales informationWPUWBW for goods movement dataWPUTAB for aggregated payment type dataWPUFIB for financial transaction data.Depending on the project implementation not all of these IDoc types might apply.For performance reasons, IDocs should not be transferred immediately but collected and sent as a bulk toERP. In order to activate the collection of IDocs, the corresponding partner agreement should be set to“collect IDocs” using transaction WE20.Example:The replenishment in ERP needs to be started at 1 am at the latest. The stores send their sales data at 10pm in the evening. At around 11 pm the data is completely transferred to POS DM. In this example, there is a© 2008 SAP AG page 35/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inboundtime window of 2 hours for collection, aggregation, sending of the POS data and the inbound processing ofthis data on the ERP side.2.1.10.2 Monitoring Requirements:Error Monitoring:It is important that the data is fully transferred and arrives on time in the ERP system. Every missing ordelayed data falsifies the replenishment calculation in ERP. In the project landscape two major approachescan be found. Some projects have requirements for real-time or near real-time processing. In this scenariothe handling of errors needs to be organized and the system needs to be monitored on a constant basis. Inorder to reduce manual work in this process, automated monitoring capabilities using CCMS alerts and/orsolution manager are vital.Most projects use POS Data in a bulk process, where the data is processed once during the evening hours ofthe day. In this scenario alerts are requested more to notify the status of the overall processing whereas forreal-time processing alerts are expected for the arriving messages individually shortly after their posting to theapplication.Real-time scenarios bare special requirements to automation and performance. Please refer to SAPConsulting for further hints and guidance in this process.Performance, Throughput and Backlog Monitoring:The requirements of chapter 2.1.3.2 apply for SAP Retail processing as well.2.1.10.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Monitoring Tool on Frequency Satellite / Data System CollectionIDoc Creation Status Direction, Port, Partner number, Number of Transaction Daily after Partner type, Partner function, WPUUMS, WE05 in execution of Message type, Basic type, WPUTAB, POS DM the relevant Message code, Message WPUBON, system task function, IDoc age. (in hours) WPUWBW IDocs in status ‘error’IDoc transmission status Direction, Port, Partner number, Number of Transaction Daily after Partner type, Partner function, contained SM58 in execution of Message type, Basic type, entries POS DM the relevant Message code, Message system task function, IDoc age. (in hours)Background Job POSDW POSDW PIPE2ERP SALES, or Job SM37 Every 5PIPE2ERP SALES (Report /POSDW/PIPEDISPATCHER, Runtime, minutes/POSDW/PIPEDISPATCHER) Start Time job cancel- during every lation, error job messages execution in Job LogBackground Job POSDW POSDW IDOC2ERP SALES, or Job SM37 Every 5IDOC2ERP SALES (Report RSEOUT00, Start Time Runtime, minutesRSEOUT00) job cancel- during every lation, error job messages execution in Job Log© 2008 SAP AG page 36/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound2.1.10.4 Further Monitoring Objects Monitoring Selection Alert Analysis Tool on Monitoring Object Criteria Satellite System Frequency / Data CollectionSales transaction Number of Sales /POSDW/MON2 Every hour or dailystatus transactions in error in POS DM depending on uploading scenarioTask processing Number of sales /POSDW/MON0 in Daily after executionstatus transactions in error POS DM of the relevant task after processing2.1.10.5 Monitoring without SAP Solution ManagerMonitoring Objects: 1. The status of the sales transactions posted to the POS DM solution. In order to only display erroneous transactions, transaction /POSDW/MON2 can be used. The transaction should not show one transaction in error. If some usual errors occur, an error handling list should be established. For example unknown EAN codes in the range of 415… are always to be replaced by the generic EAN code x. 2. After executing the job to create the POS IDocs WPUUMS for aggregated sales data, WPUTAB for aggregated payment type information, the status of the corresponding task needs to be checked with transaction /POSDW/MON0 3. After execution of the IDoc transfer job, the IDoc status needs to be checked. 4. After execution of the job, the RFC layer needs to be checked via transaction SM582.1.10.6 Scheduling of Background JobsJob Scheduling Requirements:To transfer data via IDocs from POS DM to SAP for Retail several steps are required starting with thecreation of the IDocs with the PIPE task-processing program, the program that transfers these IDocs to SAPfor Retail and the program that posts these IDocs to the target modules in SAP for Retail (see next chapter).These steps are usually organized in a sequence of depending jobs. Depending on the update frequency thissequence can be run only once in the evening/night or for some IDoc types the sequence might be requiredto run several times up to every couple of minutes in exceptional cases. In order to achieve the highest levelof line item aggregation and in order to reduce the number of follow-on documents in SAP for Retail, dailybulk processing should be used wherever possible.Scheduling of Background Jobs Recommended ABAP Variant Schedu- Prede- Suc- Schedu- Error Handling in or Generated Report ling cessor cessor ling Re- Case of Job Name Job Job striction CancellationPOSDW /POSDW SALES_ Daily at POS Job for Not in Can be restarted ifPIPE2ERP /PIPEDI DAILY 22:30 IDoc IDoc parallel system errorSALES SPATCH Inbound sending with POS ER Job if Data applicabl Insertion in e PIPEPOSDW RSEOU SALES_ Daily at POSDW IDoc None Can be restartedIDOC2ERP T00 DAILY 23:00 PIPE2E Inbound inSALES RP ERP SALES2.1.11 Business Process Step 6: Post data within SAP for Retail (PO4)2.1.11.1 DescriptionGeneral Information:The IDocs WPUBON, WPUUMS, WPUWBW, WPUFIB and other Retail-specific IDocs are© 2008 SAP AG page 37/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inboundprocessed and passed to: - MM/FI in order to update the stock levels and values and to post to the appropriate accounts in FI - SD/FI in order to create invoicing documents and to post to the appropriate accounts in FI (here, the standard single-step replenishment scenario is described). -While parallel processing using the standard IDoc dispatcher RBDAPP01 is feasible for small data volumes, itis highly recommended to use the dedicated POS Inbound dispatcher RWPOS_PARA_ENQUEUE for thispurpose because of its enhanced retail-specific dynamic parallelization mechanism (which takes into accountarticle/site lock situations). Additionally, this program is capable of refreshing its work list once started. Thisway – contrary to RBDAPP01 – IDocs are taken into account, which arrive after the program has beenstarted.Criticality:As for the processing in PIPE, long runtimes, cancelled IDocs due to lock situations, missing data orcustomizing are critical for the daily business. Unprocessed IDocs may endanger the data integrity for thereplenishment follow-on process. In case of erroneous IDoc error states, timely escalation routines should bein place for this processing. It is important to know however that retail specific POS IDoc-Types (WPU*) inerror does not necessarily mean that nothing has been processed as it is the case for most other IDoc types,Retail POS IDocs can be partially processed. The ECC POS Monitor (transaction WPER), which is a levelhigher in the business function hierarchy, is able to serve as an application-level error monitoring andhandling tool. The ECC POS Monitor shows, per IDoc, the number of errors and can give an impression atwhat extent incoming IDocs were or were not processed. Therefore it is important not to copy IDocs forreprocessing as this may result in duplicate postings in SAP for Retail.2.1.11.2 Monitoring Requirements:Error Monitoring:Errors in IDoc processing should be followed and the reasons for the processing errors corrected. The errorrate during processing should be continuously improved to zero. This is very important as processing iscarried out in most cases in an automated, nightly job sequence without the possibility of manual interventionor correction. In order to guarantee an availability of correct data in the morning hours, canceled jobs shouldbe alerted and the jobs restarted immediately.Performance, Throughput and Backlog Monitoring:The requirements of chapter 2.1.3.2 apply for this process step in SAP Retail as well.2.1.11.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Tool on Monitoring Satellite System Frequency / Data CollectionInbound IDocs WPUxxx: Direction, Port, Partner Amount of sent WE05, STAD, Every 15Collective number, Partner type, IDocs Processing RWPOS_PARA_EN minutesprocessing Partner function, time of IDocs from QUEUE, applicationruntime Message type, Basic end-to-end, Average log (spool) type, Message code, time required for Message function, IDoc processing an IDoc, age. (in hours) Total Thruput, Minimal/Maximal processing Time© 2008 SAP AG page 38/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundInbound IDocs WPUxx: Direction, Port, Partner IDoc application WPER POS Monitor Every 15Application number, Partner type, errors while final minutespostings check Partner function, processing to ECC Message type, Basic application type, Message code, Message function, IDoc age. (in hours)IDoc Inbound processing Direction, Port, Partner Cancelled job for SM37 Every 15status number, Partner type, program minutes Partner function, RWPOS_PARA_EN Message type, Basic QUEUE type, Message code, Message function, IDoc age. (in hours)Background Job POS POS INBOUND Job Runtime, job SM37 Every 5 minutesINBOUND DISPATCHER, DISPATCHER, or cancellation, error during every job(Report RWPOS_PARA_ENQUE messages in Job executionRWPOS_PARA_ENQUE UE, Start Time LogUE)2.1.11.4 Monitoring without SAP Solution ManagerMonitoring Objects: 1. The status of the processed and to be processed IDocs can be checked with transaction WPER and the generic IDoc monitoring transactions. Also the creation of related documents can be followed and monitored here. 2. The jobs used to transfer and post the IDocs must be monitored.2.1.11.5 Scheduling of Background JobsJob Scheduling Requirements:The program RWPOS_PARA_ENQUEUE should be used in order to post Retail specific POS Inbound IDocs.The possibility of refreshing the IDoc work list during runtime should be used in order to make sure thatarriving IDocs are processed as soon as possible even if the job already started before the IDocs arrived.Scheduling of Background Jobs Recommended ABAP Variant Schedu- Prede- Suc- Schedu- Error Handling in or Generated Report ling cessor cessor ling Re- Case of Job Name Job Job striction CancellationPOS INBOUND RWPOS SALES_ Daily at IDoc Job for Not in Can be restarted ifDISPATCHER _PARA_ DAILY 24:00 creation IDoc parallel to system error ENQUE and sending other UE transfer goods jobs in movements PIPE for stores2.1.12 Business Process Step 7: Update BI Info Cubes (P05)2.1.12.1 DescriptionGeneral Information:Data is put into the delta queue by PIPE task processing. Data is transferred to BW using normal BI Datatransfer processes. This process should be monitored to guarantee that BI reporting shows accurate valueson the following day.The data sources used by the POS DM Analytics content are:0RT_PA_TRAN_CONTROL© 2008 SAP AG page 39/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound0RT_PA_TRAN_GDS_MOV0RT_PA_TRAN_MOV_FIN0RT_PA_TRAN_TOTALSFor monitoring of BI Data transfer processes please refer to the generic BI documentation ‘Periodic Jobs andTasks in SAP BW” under https://service.sap.com/solutionmanagerbp.2.1.12.2 Monitoring Requirements:Error Monitoring:Missing or inaccurate BI updates of POS sales endanger the validity of business decisions relying on thisdata. Reviewing the statuses of BI data loads therefore should be an integral part of daily monitoring routine.Performance and Throughput Monitoring:Runtimes and throughput KPIs should be established and regularly monitored to detect possible negativetrends of update performance, e.g. caused by increasing data volume, as early as possible.Backlog Monitoring:Backlog requirements for BI updates apply like error monitoring (e.g. pending erroneous update packagesprevent subsequent packages from becoming active for reporting).2.1.13 Business Process Step 8: Update SAP F&R (P06)2.1.13.1 DescriptionGeneral Information:SAP F&R (SAP Forecasting and Replenishment) receives daily consumption information for F&R relevantstores and articles from PIPE. The consumption data is based on the following information provided by thestore: Sales information, including applied discounts, promotion numbers etc. Goods movements, including goods receipts, goods issues, stock adjustments.The interface used to connect to SAP F&R is a RFC call to the time series interface/FRE/BIF_TSD_INBOUND2. This interface is populated using a PIPE task.2.1.13.2 Monitoring Requirements:As the interface to F&R is implemented as a processed task like every other follow-on processing in PIPE forthe monitoring all requirements apply as before: the POS Workbench for application and technical messages,application log for PIPE Dispatcher messages, the job log for more general issues and spool information andthe POS DM message log report. Additionally basic RFC monitoring applies here.Error Monitoring:Erroneous sales data in F&R jeopardizes correct forecasting values, thus endangering the optimalmerchandise flow when too few or too many items are replenished by F&R.Performance and Throughput Monitoring:Depending on the cutoff times for internal (stock transfer oders) or external (purchase orders to vendor)replenishment, the timely execution of tasks within F&R is critical for an undisrupted business flow.Performance and throughput KPIs to assess F&R time series updates therefore are needed to ensure thesecutoff times can be kept, through iterative monitoring and tuning where applicable.Backlog Monitoring:As with error Monitoring, Backlogs in F&R time series data to be posted may render forecasting values to beincorrect for the business (order quantities too low or too high for fulfilling customer demands). Backlogstherefore need to be addressed immediately for the next F&R run to process correctly.© 2008 SAP AG page 40/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound2.1.13.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Monitoring Tool on Frequency / Satellite Data System CollectionApplication log Object, Sub-object, Error messages SLG1 Every 60 user, transaction, provided by minutes Program PIPE DispatcherPIPE Dispatcher Job Job Name, Start Time Spool entries SM37 Every 5 minutes during every job executionJob POSDW PIPE2CONS POSDW Job Runtime, SM37 Every 5 minutes(Report PIPE2CONS, or job cancellation, during every job/POSDW/PIPEDISPATCHER, /POSDW/PIPEDISPA error messages executionVariant DAILYCONS) TCHER, Start Time in Job Log2.1.13.4 Further Monitoring Objects Monitoring Selection Alert Analysis Tool on Monitoring Object Criteria Satellite System Frequency / Data CollectionOnline message Error messages /POSDW/MON0 or Onlinemonitoring provided by POS /POSDW/MON2 DM validation frameworkTask processing Store, Posting Error messages Report Online or batchstatus as per Date, Message provided during /POSDW/DISPLAY_chapter 2.4.4 Class, Message PIPE MESSAGELOG Type, Message number, Message Category, Rule, Message Priority2.1.13.5 Monitoring without SAP Solution ManagerMonitoring Objects: 1. The status of the sales transactions posted to the POS DM solution. In order to only display erroneous transactions, transaction /POSDW/MON2 can be used. 2. After executing the PIPE dispatcher job to supply the relevant data to F&R, the status of the job and the corresponding task needs to be checked with transaction /POSDW/MON0 or the message log application2.1.13.6 Scheduling of Background JobsJob Scheduling Requirements:The job needs to be scheduled according to F&R requirements, usually some time after data loading butbefore the FRP run.© 2008 SAP AG page 41/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundScheduling of Background Jobs Recommended ABAP Variant Schedu- Prede- Suc- Scheduling Error Handling in or Generated Report ling cessor cessor Restriction Case of Job Name Job Job CancellationPOSDW /POSDW DAILY Daily de- - - Not in parallel Can be restarted ifPIPE2CONS /PIPEDI CONS pending on with POS system error SPATCH F&R Data Insertion ER timelines in PIPEAdditional information can be found in the F&R related Best Practice document for Solution Management“Manage Operations for an IS-Retail Solution Forecast & Replenishment”.2.1.14 Business Process Step 9: Extraction of Master Data for BI (P07)2.1.14.1 DescriptionGeneral Information:In order to verify the incoming data in PIPE, master data needs to be extracted from SAP for Retail. This dataneeds to be extracted on a regular basis. If the data is not extracted correctly, POS transaction may run intoerrors the following day as some articles might be unknown to POS DM.Example:POS Sales transactions use, in most cases, EAN numbers as a reference for the sold article. In order to beable to enrich this data for reporting information like merchandise categories, article types and so on, thecurrent stock levels are required.The relevant info objects are:0material, 0plant, 0rpa_mean, 0rpa_marm, DSO (data storage object) for 0mat_plantFor monitoring of BI Data transfer processes please refer to the generic BI documentation ‘Periodic Jobs andTasks in SAP BW” under https://service.sap.com/solutionmanagerbp.© 2008 SAP AG page 42/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound3 Further Information3.1 TroubleshootingIf executing this Best Practice did not produce the desired results: Search for related notes in SAPNet. 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 “RunSAP” RunSAP Best Practices.3.3 Literature For detailed information on how to administer an SAP R/3 system see the book: Liane Will, SAP R/3 System Administration, 2003 For information on how to monitor and tune the general system performance see the book: Thomas Schneider, SAP Performance Optimization Guide, 2006.© 2008 SAP AG page 43/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound3.4 Feedback and QuestionsSend any feedback by formulating an SAP customer message to component SV-SMG-MON-BPM. You cando this at http://service.sap.com/message.© 2008 SAP AG page 44/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound4 AppendixIn the following section you find for each of the Monitoring Tools one example how you can set up theMonitoring within the SAP Solution Manager.In the following section you find for each of the Monitoring Tools one example how you can set up theMonitoring within the SAP Solution Manager. You will only get a short overview about the Setup, if you needmore information see the Documentation in Service Marketplace.4.1 Example Background Job MonitoringBackground Job Monitoring of Background Job POSDW POS2PIPE POSLOG (Report /POSDW/IDIS) in SAPSolution Manager the setup for the other Jobs is except of the Job specific parameters quite similar. For moreinformation see the Best Practice Document Background Job Monitoring.1. Call the SAP Solution Manager (trx DSWP or SOLUTION_MANAGER).2. Choose your solution.3. Go to Operation Setup and navigate to Solution Monitoring => Business Process Monitoring.4. Check Business Processes: select a business process for application monitoring.5. Check for your chosen business process: choose process steps to monitor.6. Check for your chosen step: Choose type of monitor, here Background Job.7. Enter the information to be used to identify the job in this case the Job Name POSDW POS2PIPE POSLOG or the ABAP Program Name /POSDW/IDIS8. Choose the key figures Job Cancellation and Job Log Messages to monitor error messages in Job Log© 2008 SAP AG page 45/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound You find the information about the Message class and Message number in the Job Log of the Job you want to monitor. Choose the job form the F4 input help and specify the message type E for Error. Wildcard can be used for the other parameters. If you want to receive YELLOW alerts, leave this field blank or set the same value as the threshold for RED. If you do not want to receive RED alerts, leave this field blank or set it to a value that will never be reached.9. The Monitoring Schedule should be ones a day10. 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 Example PI Message Process MonitoringThe message flow via SP PI can be very complex passing different components (such as adapter engine(s)with the module processor and messaging system, integration engine(s) with their pipeline processingincluding Java&ABAP proxies, business process engine) and using different adapter types (such as File-,JMS-, IDoc, RNIF-adapters etc.). This complexity makes it difficult to track and monitor the flow of a specificmessage. The information how you can set up the Business Process Monitoring for PI Messages for alldifferent scenarios you can find in chapter 9 “SAP PI Message Processing Monitoring” in the Setup GuideInterface Monitoring in the SAP Solution Manager.4.3 Example ALE / IDoc MonitoringExample IDoc Monitoring for IDocs /POSDW/POSTR_CREATEMULTIPLE, WPUBON and WPUUMS in SAPSolution Manager the setup for other IDoc Types is very similar. Please look into the Setup Guide InterfaceMonitoring if you need more information regarding the setup procedure.The setup of IDoc monitoring will be done in the Setup Business Process Monitoring session. At least onebusiness process with steps on different systems and defined interfaces must be available before it ispossible to configure IDoc monitoring. 1.Select Monitoring Type Navigate to the business process you intend to monitor and go to node ‘Interface Monitoring’. Select the interface to be monitored by flagging the checkbox in the ‘Select’-field.© 2008 SAP AG page 46/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 2.Select Key Figures The next open node (‘<Monitoring Object Name>’) lists the available key figures. Select Delta Number Monitor and / or Total Number Monitor depending on your IDoc monitoring concept. In tab ‘Detail Information’ the selection criteria of the key figures have to be specified. Double-click on the counter ‘001’ to open a selection screen where you maintain header information of this monitoring object. Parameters ‘Direction’ and ‘IDoc Age (in hours)’ are mandatory.© 2008 SAP AG page 47/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS InboundThe customizing of the data collection can be done in tab ‘Monitoring Schedule’. Here, you can adjust timeand frequency of the data collection. The flag for ‘Data Collection in Background’ is set automatically, as thedata collector reads EDI tables which can grow very large. Thus, dialog processing of the data collectionwould impact the performance of the satellite system too much. The data collection frequency for IDoc Monitoring is hard coded to 15 minutes. However, the column Period [min] determines the frequency how often the measured value is evaluated. It is therefore recommended to set that value higher or equal to 15 minutes. 3.Specify Key Figures After saving the subnodes ‘Delta Number Monitor’ and / or ‘Total Number Monitor’ will appear. Again double-click on the counter in tab ‘Key Figures’ to specify further details of the monitoring. Parameter ‘Status Number(s)’ is mandatory.Customizing example:- Status Number(s): e.g. 51 for IDoc in error- Status Message Qualifier: The field identifies the origin of the messages which are transmitted in the status. E.g. SAP messages are identified with SAP.- Status Message ID: e.g. E0- Status Message Number: e.g. 099- Status Age (in min): e.g. 5 minutes- Status Counter: e.g. 2 (This means, the IDoc has to be at least 2 times in status 51 before being alerted.)After you have entered and confirmed your selection criteria, the tab ‘Parameter Value Ranges’ will appearwhere an overview of your customizing is displayed. Return to tab ‘Delta Number Monitor’ / ‘Total NumberMonitor’ to specify the thresholds for alerting. You can define threshold values in both directions, for morethan and less than at the same time. If only one direction should be evaluated leave the other field blank! 4.Generate and activate the customizing afterwards.© 2008 SAP AG page 48/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound4.4 Example Dialog Performance MonitoringExample Dialog Performance Monitoring. Please take a look at the Setup Guide … 1. Choose the Monitoring Type “Application Monitor”. 2. Choose the Application Monitor Dialog Performance Monitor with the technical name “BOPERFMO” 3. Choose the Key Figure “Total response time”. 4. In the second tab strip of node Dialog Performance Monitor you specify the data collector period in column DC Period, i.e. how often the data collector is supposed to run. This is the time window in which the corresponding statistical records are summarized and for which an average value is calculated. The smallest possible value is 5 minutes which is usually most appropriate for the Dialog Performance Monitor. The default value is 60 minutes. 5. For call type R (RFC), RFC statistics are evaluated. Enter the called program name in the “Value 1 “ field and enter the function module in the “Value 2” field. You can maintain the program name and function module together or individually.© 2008 SAP AG page 49/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 5.Generate and activate the customizing afterwards.4.5 Example Application Log MonitoringFor detail info how to Setup the Application Log Monitoring see Setup Guide Business Process Monitoring inService Marketplace. 1. Choose the Monitoring Object Application Log. The application log monitor allows you to evaluate logs, and must be configured in a such a way that it can detect critical situations for step"TLOG".© 2008 SAP AG page 50/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 2. Select the alert types you want to configure and specify the combinations of object, subobjects, user, transaction, program, and aggregation.The object must be specified explicitly. You can use the wild card "*" for all other fields except the aggregation. Unless otherwise specified, the wild card "*" is set automatically. Use the F4 input help to select the level of aggregation on which data evaluation is to be carried out (per "L"og, "D"ay, or "H"our). Unless otherwise specified, aggregation is automatically set to "L".Note: If transactions have been specified for the business process step in the Solution Directory, the inputhelp (F4) for the object and subobject may contain some suggestions. Choose Object = /POSDW/PIPE (Logfor POS Data Management) and the right Sub-object e.g. XML_IN (Import POS Transactions as XML File). 3. Monitoring Schedule 4. You can configure data collection to run on either a weekly or monthly basis. To switch between these two options, choose the required schedule type from the input help (F4) for the first column on the "Monitoring Schedule" tab page and save your entries.4.6 Background JobsCertain jobs must run periodically in a production SAP Retail System - for example, deleting obsolete jobs orspool objects. If these periodic jobs do not run, system performance may get worse over time. Unfortunately,there is currently no easy-to-use support for such jobs in Basis Customizing. Therefore, the jobs must bescheduled manually. For more information, see SAP Note 16083. Note that a daily monitoring of the job logusing Solution Manager is recommended.Error Handling Procedures for Batch Jobs In case one of the scheduled jobs fails, if one of the necessary jobs is not scheduled, or even if a scheduled job has finished, check for the current job status (refer to SAP R/3 documentation CD, component BC-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.© 2008 SAP AG page 51/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound 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 currently running and cannot be modified or deleted anymore. 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 exceeded the given timeframe, contact the software monitoring team. In the case of status finished, all steps that make up this job have completed successfully. Program scheduling management has to check whether the job ran in the given timeframe, and software monitoring team and/ 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 abnormally, which can happen in two ways. If an administrator intentionally cancelled the job, clarify why he did so and whether (and if, 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 SAPNet and open a customer message if you cannot solve the problem.Job RestartabilityIn case of the cancellation of a background job, possible succeeding jobs or dependencies on other jobs mustbe considered when restarting the aborted job. The start of succeeding jobs might be also delayed due to therestart 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 a customer problem message in the SAPNet R/3 front-end system.© 2008 SAP AG page 52/53
    • Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound© Copyright 2008 SAP AG. All Rights Reserved.No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.Microsoft, Windows, 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.© 2008 SAP AG page 53/53