Best Practice for Solution Operations       Manage Operations for SAP for Retail                POS Download              ...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadTable of Contents1 Management Summ...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download      2.2.3.3 Monitoring objects i...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download      2.3.1.5 Error handling per m...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download       2.3.7.6 Error handling per ...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download1               Management Summary...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadSAP technology operations team   A...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download   At the beginning of chapter 2 y...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadThe core business processes that a...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloadaffected system components. If you...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloaddependencies between different act...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download1.7.4.4             Dialog perform...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloadthreshold values for a single line...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadFigure 4: Monitoring objects – Upd...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadMonitoring alertsFor the monitorin...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadFigure 6: Monitoring objects and a...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download1.7.4.8            Other CCMS moni...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloadoverview in an SAP system, is main...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadWhen using the monitoring during a...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloadthe service desk message serves as...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download Text Template                   T...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download2                Business Process ...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloaddelivered. But this BPM concentrat...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadTools like WIND and BDCP2 are typi...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadThe following steps need to be don...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadThe following chapters takes you s...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadSpecial messages and intermediate ...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadNote: Each chapter will be structu...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download2.2.1.2                Monitoring ...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download2.2.1.4          How to find meani...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadBacklog monitoringIt is important ...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download2.2.2.6             Scheduling of ...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadProgram RWDLCOPY_MANAGE copies the...
Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadThroughput monitoringHere you only...
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Manage operations for sap for retail pos download
Upcoming SlideShare
Loading in...5
×

Manage operations for sap for retail pos download

3,897

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,897
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
250
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Manage operations for sap for retail pos download"

  1. 1. Best Practice for Solution Operations Manage Operations for SAP for Retail POS Download Dietmar-Hopp-Allee 16 D-69190 Walldorf CS STATUS customer published DATE VERSION June 10 2009 3.0 SOLUTION MANAGEMENT PHASE SAP SOLUTION Operations & Continuous Improvement Best Practices for Solution Operations TOPIC AREA SOLUTION MANAGER AREA Application & Integration Management Business Process OperationsBest_Practice_POS_Outbound_V30_upd.doc – 10.06.2009
  2. 2. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadTable of Contents1 Management Summary 6 1.1 Goal of Using This Best Practice 6 1.2 Alternative Practices 6 1.3 Staff and Skills Requirements 6 1.4 System Requirements 7 1.5 Duration and Timing 7 1.6 How to Use This Best Practice 7 1.7 Best Practice Procedure 8 1.7.1 Preliminary tasks 8 1.7.2 Monitoring concepts 8 1.7.3 Business Process Monitoring in SAP Solution Manager 8 1.7.4 Monitoring types for Business Process Monitoring in SAP Solution Manager 9 1.7.4.1 Application monitor 10 1.7.4.2 Background job 10 1.7.4.3 ABAP dump collector 11 1.7.4.4 Dialog performance 12 1.7.4.5 Update errors 13 1.7.4.6 Due list log 14 1.7.4.7 Application log 15 1.7.4.8 Other CCMS monitors 17 1.7.4.9 Analysis and monitoring tools 17 1.7.4.10 Monitoring activities 19 1.7.4.11 Notifications 19 1.7.5 Business Process Monitoring process 21 1.7.6 Legend 212 Business Process Monitoring for a Point of Sale (POS) Download Data Transmission 22 2.1 Sample Scenario 25 2.2 Business Process POS Outbound with POS Interface IDocs 26 2.2.1 Business process step 1: Initialize or dummy initialize new store 28 2.2.1.1 Description and general information 28 2.2.1.2 Monitoring requirements 29 2.2.1.3 Further monitoring objects 29 2.2.1.4 How to find meaningful thresholds per monitoring object 30 2.2.2 Business process step 2: Evaluate master data changes, collect and prepare data, create IDoc 30 2.2.2.1 Description and general information 30 2.2.2.2 Monitoring requirements 30 2.2.2.3 Monitoring objects in SAP Solution Manager 31 2.2.2.4 Further monitoring objects 31 2.2.2.5 How to find meaningful thresholds per monitoring object 31 2.2.2.6 Scheduling of background jobs 32 2.2.3 Business process step 3: Copy IDocs within ECC retail (optional) and send out IDocs from ECC retail 32 2.2.3.1 Description and general information 32 2.2.3.2 Monitoring requirements 33© 2009 SAP AG page 2/82
  3. 3. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download 2.2.3.3 Monitoring objects in SAP Solution Manager 34 2.2.3.4 How to find meaningful thresholds per monitoring object 34 2.2.3.5 Scheduling of background jobs 35 2.2.4 Business process step 4: Monitor, correct, and repeat POS outbound 35 2.2.4.1 Description 35 2.2.4.2 Monitoring requirements 36 2.2.4.3 Monitoring objects in SAP Solution Manager 42 2.2.4.4 Further monitoring objects 43 2.2.4.5 How to find meaningful thresholds per monitoring object 43 2.2.4.6 Error handling per monitoring object 43 2.2.4.7 Scheduling of background jobs 43 2.2.5 Business process step 5: Reorganize change pointers, status records, and WIND entries 44 2.2.5.1 Description and general information 44 2.2.5.2 Monitoring requirements 45 2.2.5.3 Monitoring objects in SAP Solution Manager 45 2.2.5.4 How to find meaningful thresholds per monitoring object 45 2.2.5.5 Error handling per monitoring object 46 2.2.5.6 Scheduling of background jobs 46 2.2.6 Business process step 6: Delete change pointers and status records 46 2.2.6.1 Description and general information 46 2.2.6.2 Monitoring requirements 47 2.2.6.3 Monitoring objects in SAP Solution Manager 47 2.2.6.4 How to find meaningful thresholds per monitoring object 47 2.2.6.5 Error handling per monitoring object 47 2.2.6.6 Scheduling of background jobs 47 2.2.7 Business process step 7–9: Middleware (enterprise application integration tool): Receive, transform, and send information 48 2.2.7.1 Description 48 2.2.7.2 Monitoring requirements 48 2.2.7.3 Monitoring objects in SAP Solution Manager 48 2.2.7.4 Further monitoring objects 49 2.2.7.5 How to find meaningful thresholds per monitoring object 49 2.2.7.6 Error handling per monitoring object 49 2.2.8 Business process step 10–11: POS system: Receive information and update database 49 2.2.8.1 Description and general information 49 2.2.8.2 Monitoring requirements 49 2.2.8.3 Monitoring objects in SAP Solution Manager 49 2.2.8.4 Further monitoring objects 50 2.2.8.5 How to find meaningful thresholds per monitoring object 50 2.2.8.6 Error handling per monitoring object 50 2.3 Business Process POS Outbound with Assortment List 50 2.3.1 Business process step 1: Run full version to initialize or dummy initialize new store 52 2.3.1.1 Description and general information 52 2.3.1.2 Monitoring requirements 52 2.3.1.3 Further monitoring objects 53 2.3.1.4 How to find meaningful thresholds per monitoring object 53© 2009 SAP AG page 3/82
  4. 4. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download 2.3.1.5 Error handling per monitoring object 53 2.3.2 Business process step 2: Run change version to evaluate master data changes, collect and prepare data, create IDoc 54 2.3.2.1 Description and general information 54 2.3.2.2 Monitoring requirements 54 2.3.2.3 Monitoring objects in SAP Solution Manager 55 2.3.2.4 Further monitoring objects 55 2.3.2.5 How to find meaningful thresholds per monitoring object 55 2.3.2.6 Error handling per monitoring object 55 2.3.2.7 Scheduling of background jobs 55 2.3.3 Business process step 3: Copy IDocs within ECC retail (optional) and send out IDocs from ECC retail 56 2.3.3.1 Description and general information 56 2.3.3.2 Monitoring requirements 57 2.3.3.3 Monitoring objects in SAP Solution Manager 58 2.3.3.4 How to find meaningful thresholds per monitoring object 58 2.3.3.5 Error handling per monitoring object 58 2.3.3.6 Scheduling of background jobs 58 2.3.4 Business process step 4: Monitor, correct, and repeat data transfer of assortment list 59 2.3.4.1 Description and general information 59 2.3.4.2 Monitoring requirements 60 2.3.4.3 Monitoring objects in SAP Solution Manager 65 2.3.4.4 Further monitoring objects 66 2.3.4.5 How to find meaningful thresholds per monitoring object 66 2.3.4.6 Error handling per monitoring object 66 2.3.4.7 Scheduling of background jobs 66 2.3.5 Business process step 5: Reorganize change pointers, status records, and WIND entries 67 2.3.5.1 Description and general information 67 2.3.5.2 Monitoring requirements 68 2.3.5.3 Monitoring objects in SAP Solution Manager 68 2.3.5.4 How to find meaningful thresholds per monitoring object 68 2.3.5.5 Error handling per monitoring object 69 2.3.5.6 Scheduling of background jobs 69 2.3.6 Business process step 6: Delete change pointers and status records 69 2.3.6.1 Description and general information 69 2.3.6.2 Monitoring requirements 69 2.3.6.3 Monitoring objects in SAP Solution Manager 70 2.3.6.4 Scheduling of background jobs 70 2.3.6.5 How to find meaningful thresholds per monitoring object 70 2.3.6.6 Error handling per monitoring object 70 2.3.7 Middleware (enterprise application integration tool): Receive, transform, and send information 71 2.3.7.1 Description 71 2.3.7.2 Monitoring requirements 71 2.3.7.3 Monitoring objects in SAP Solution Manager 71 2.3.7.4 Further monitoring objects 71 2.3.7.5 How to find meaningful thresholds per monitoring object 71© 2009 SAP AG page 4/82
  5. 5. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download 2.3.7.6 Error handling per monitoring object 72 2.3.8 POS system: Receive information and update database 72 2.3.8.1 Description and general information 72 2.3.8.2 Monitoring requirements 72 2.3.8.3 Monitoring objects in SAP Solution Manager 72 2.3.8.4 Further monitoring objects 72 2.3.8.5 How to find meaningful thresholds per monitoring object 72 2.3.8.6 Error handling per monitoring object 723 Further Information 73 3.1 Troubleshooting 73 3.2 Related Best Practice Documents 734 Appendix 74 4.1 Example Background Job Monitoring 74 4.2 Example PI Message Process Monitoring 76 4.3 Example ALE/IDoc Monitoring 76 4.4 Background Jobs 79Index of Figures 81Index of Tables 81© 2009 SAP AG page 5/82
  6. 6. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download1 Management Summary1.1 Goal of Using This Best PracticeThis Best Practice helps you set up a Business Process Monitoring concept for your SAP for Retail solution.The concept aims to define procedures for business process oriented monitoring and error handling andescalation procedures for your business process point of sale (POS) download. These procedures intend toensure a smooth 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 SAPSolution Manager for the monitoring functionalities. But even if you do not use SAP Solution Manager werecommend to follow the procedures described in this document as much as possible in order to ensure asmooth and reliable flow of your business processes as well as an appropriate response in case ofunforeseen errors.1.2 Alternative PracticesYou can have SAP experts deliver this Best Practice on-site by ordering an SAP Solution ManagementOptimization (SMO) service for SAP Business Process Management (BPM). This service is exclusivelyavailable within SAP’s support engagements SAP MaxAttention and SAP Safeguarding. If your companycurrently does not have any support engagements with SAP, it is also possible to get assistance by SAPexperts from SAP Consulting. In this case, please contact your local SAP Consulting representative.1.3 Staff and Skills RequirementsTo implement this Best Practice, you require the following teams:Application Management teamThis team creates the SAP ERP Business Process Monitoring concept and consists of experts from severalareas of your company: Business department Solution support organization (for example the basis support or the application support) Implementation project teamBusiness process operations teamThe business process operations team will be responsible for applying the resulting procedures derived fromimplementing this Best Practice. They include the following groups: Persons designated to perform business process oriented monitoring and ensure that the process runs smoothly (e.g. the business process champion for each business process) All parties in your solution support organization and IT department involved in monitoring focused on the application aspects (application support, development support, Job Scheduling Management)© 2009 SAP AG page 6/82
  7. 7. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadSAP technology operations team All parties in your solution support organization and IT department involved in monitoring focused on the system administration side (program scheduling management, software monitoring team, system administration team, including the system administrator)Business process champion The business process champion is the person in the business department that is responsible for the successful execution of the business process. He coordinates all activities necessary for the business process. Therefore, he is usually responsible for the escalation paths in case of problems. He often serves as a second level in the escalation procedure, if the application monitoring team needs to escalate an issue.More information about roles and responsibilities of these teams can be found in the super-ordinate BestPractice General Business Process Management, which you can obtain through SAP Solution Manager orthe SAP Service Marketplace, quick link/BPM.Necessary or useful trainings SM300 Business Process Management and Monitoring E2E300 End-to-End Business Process Integration and Automation Management1.4 System RequirementsIn order to monitor business processes running in your SAP for 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 for Retailsystem.1.5 Duration and TimingDuration Creating a Business Process Monitoring concept takes approximately one week per business process. Implementing the Business Process Monitoring concept takes approximately an additional week.TimingThe best time to apply this Best Practice is during the planning phase or during the implementation phase ofyour SAP solution.1.6 How to Use This Best PracticeHere you find a brief description of how you should proceed in using this document: Read through the General Business Process Management Best Practice, available on the SAP Service Marketplace. This document explains the procedures you should use to create a general Business Process Management concept. This includes the definition and documentation of the core business processes, definition of monitoring objects, definition of monitoring activities (including error handling procedures, monitoring tools, and monitoring frequencies), the definition of communication and escalation procedures, and the assignment of responsibilities.© 2009 SAP AG page 7/82
  8. 8. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download At the beginning of chapter 2 you will find a typical flow chart of the core business process explained in this Best Practice. It is intended to be used as a guideline for writing down your company specific process documentation. In chapter 1.7.4 you find further information that is relevant for more than one scenario. In case information from the generic part is relevant for a specific business process step in one of the scenarios, you will find a clear link to the corresponding chapter in the generic part.1.7 Best Practice Procedure1.7.1 Preliminary tasksBefore performing this Best Practice, ensure that you perform the following preliminary tasks or checks in thesystem: Complete all installation and post-installation actions and procedures including customizing Ensure that the initial download has been successfully executed Apply all SAP recommendations from SAP service sessions and any SAP recommendations resulting from customer problem messages Implement all current SAP support packages upon availability1.7.2 Monitoring conceptsThe monitoring procedures proposed for each business process step are the core of this Best Practice. Themonitoring procedures help you to ensure that the technical processes meet the requirements for stability,performance, and completeness. These procedures cover monitoring for the five areas:1. Error monitoring2. Performance monitoring3. Throughput monitoring4. Backlog monitoring5. Data consistency monitoringFor each of the business process steps you will find the following information: A detailed functional description of the process step Identified monitoring requirements for the process step Defined monitoring objects, alerts, and selection criteria Description of error handling procedures and restartabilityGeneral monitoring activities that are valid for all or most scenarios are described in the generic part inchapter 1.7.4 Recommendations for performance monitoring can also be found in this chapter. Theperformance of the most important steps of your core business processes should be monitored on a regularbasis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP forRetail solution is generally the same. Therefore, you will only find specific performance monitoringrecommendations on selected business process steps.1.7.3 Business Process Monitoring in SAP Solution ManagerBusiness Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and process-oriented monitoring of the most important or critical business processes, including the observation of alltechnical and business application specific functions that are required for a steady and stable flow of thebusiness processes.© 2009 SAP AG page 8/82
  9. 9. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadThe core business processes that are implemented in a SAP for Retail system or other software and operatedby a 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. SAP SolutionManager provides a graphic to visualize a company’s (distributed) system and solution landscape and allrelated business processes. By using Business Process Monitoring, it is possible to define and customizealert situations from a basic set of configurable alerts provided by SAP Solution Manager. These alerts arethen visualized by green, yellow, and red alert icons for each individual business process step in the graphicalbusiness process representation. Business Process Monitoring is intended to detect and respond to criticalsituations as early as possible in order to solve problems as fast as possible.In addition, SAP Solution Manager offers extended functionality for error handling and problem resolution. Bythe definition of contact persons and escalation paths, Business Process Monitoring can be integrated intothe company’s overall strategy for Business Process Management and solution management within theirsolution support organization.In general, a Business Process Monitoring includes the solution-wide observation of: Business process performance (key performance indicators) Background jobs (Job Scheduling Management tasks) Business application logs (such as any error log, general application log, due list logs etc.) Data transfer via interfaces between software components Data consistency Technical infrastructure and components which are required to run the business processes Required periodic monitoring tasksFor further details on Business Process Monitoring please refer to http://service.sap.com/bpm.1.7.4 Monitoring types for Business Process Monitoring in SAP Solution ManagerMonitoring types are part of the functional scope of Business Process Monitoring as it is available in SAPSolution Manager. The below mentioned monitoring types are available: Application monitor (Throughput and backlog indicators, data consistency checks, mass activity monitors, due list log, MRP key figures, user exit) Background jobs (jobs running on SAP systems with an SAP basis) Dialog performance (dialog transaction performance) Update error (V1 and V2 update errors from SM13 for specific transactions and programs) Due list log (messages for deliveries and billings) Application log (messages from the application log SLG1) Document volume (based on table call statistics in ST10) Other CCMS monitor (all alerts that are configured in the CCMS alert monitor)Depending on what is executed during a specific business process step, the relevant monitoring types mustbe selected. In order to receive detailed information on how to set up the monitoring objects in SAP SolutionManager, please refer to the documentation that is available under http://service.sap.com/bpm.One prerequisite for setting up Business Process and Interface Monitoring in SAP Solution Manager is that allbusiness processes and business process steps are maintained in the respective solution that contains all© 2009 SAP AG page 9/82
  10. 10. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloadaffected system components. If you want to learn more about how to set this up, please turn to (URLhttp://help.sap.com) SAP Solution Manager Basic Settings.1.7.4.1 Application monitorThe application monitor is just one of many different monitoring types within the Business Process Monitoring.The latest monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the satellite system.The service tool for ST-A/PI is available via the SAP Service Marketplace quick link/installations Entry byApplication 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://service.sap.com/BPMMedia 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 SAP ERP logistic the following monitors are available: Sales and services (e.g. sales documents, invoices) Warehouse management (e.g. transfer requirements, transfer orders) Inventory management (e.g. goods movements) Logistics execution (e.g. deliveries, shipments) Procurement (e.g. planned orders, purchase requisitions, purchase orders) Manufacturing (e.g. planned orders, production or process orders, autom. goods movements posted with error, confirmation pool errors) Plant maintenance (e.g. PM/CS notifications, PM/CS orders)For further information on the different TBIs refer to the document Setup Guide – Application Monitoring (URLhttp://service.sap.com/BPM Media Library).1.7.4.2 Background jobThe background job monitoring should be part of a Job Scheduling Management concept (URLhttp://service.sap.com/solutionmanagerbp, topic area Business Process Operations to find a Best Practicedocument Job Scheduling Management). Because of several restrictions regarding background jobscheduling, e.g. time restrictions, restriction of hardware resources (CPU, main memory, …) or existing© 2009 SAP AG page 10/82
  11. 11. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloaddependencies 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.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 on the subject what kind of alerts make sense or what kind of alerts are possibleare discussed in the Best Practice document Background Job Monitoring with SAP Solution Manager whichcan be found on the SAP Service Marketplace http://service.sap.com/solutionmanagerbp, topic areaBusiness Process Operation.1.7.4.3 ABAP dump collectorThe dump collector provides monitoring features for alerting on occurrences of ABAP dumps of specifiedruntime errors and collects statistical data of ABAP dumps for reporting reasons.Monitoring objectsThe monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime errorname, the user who is responsible for the runtime error, the client on which the runtime error occurs or theprogram that leads to the runtime error.Monitoring alertsPossible alert types are the Number of ABAP Dumps (Delta) – all dumps since the last collector run – andNumber of ABAP Dumps (Reporting) – all runtime errors of specified type, client, and program for this day orfor the previous day.Figure 1: Alert type Number of ABAP Dumps (Delta)© 2009 SAP AG page 11/82
  12. 12. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download1.7.4.4 Dialog performanceDialog performance implies the monitoring of the dialog transaction performance of any transaction in theSAP system. This can be a standard transaction or a custom-developed transaction.Monitoring objectsThe monitoring object is the transaction itself. The customizing has to be done in the Dialog Performancenode. The Transactions table lists all transactions that are already configured to that business process step.The relevant transactions need to be selected for monitoring. It is also possible to add or to removetransactions within the Add/Remove Transactions table. The monitoring can be performed per SAPinstance. To this end, select the respective instances in the SAP Instances table, which lists all instances thatare maintained for a system. The Alert Types table shows the dialog response time and all parts of theresponse time that can be monitored, like queue time, load and generation time, database request time andthe front-end response time. Select those times that are relevant for monitoring. After saving this node, a sub-node Performance Alerts will appear where you can enter the threshold values.Figure 2: Monitoring objects – Dialog performanceMonitoring alertsEach table in the Performance Alerts sub-node corresponds to an alert type chosen in the higher-level node,and lists the combinations of specified transaction code and SAP instance.For each combination of transaction code and instance that you want to include in the monitoring, specify thethreshold values resulting in alert messages for GREEN to YELLOW, YELLOW to RED, RED to YELLOW,and YELLOW to GREEN.Since the monitoring object for performance monitoring is created on the satellite system, it might be possiblethat the object already exists there. Therefore you can load the current threshold values from the respectivesystems via the Load thresholds from <XYZ> button, with <XYZ> representing the SID. If successfullyretrieved for an SAP instance, the values are filled in columns. If no active settings for the threshold valueswere found for a certain transaction code, default values are set (indicated in column Default). To transfer the© 2009 SAP AG page 12/82
  13. 13. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloadthreshold values for a single line from right to left, the Copy icon can be used. To transfer all at once (allthresholds for all columns and tables) there is an additional Copy all button.Figure 3: 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 databasecompletely or not at all. If the operation is canceled while the transaction is being executed, or if an erroroccurs, the transaction should not make any changes to the database. These activities are handled by theSAP update system.The SAP system makes a distinction between primary, time-critical (V1), and secondary, non-time-critical(V2) update errors. This distinction allows the system to process critical database changes before less criticalchanges.V1 modules describe critical or primary changes; these affect objects that have a controlling function in theSAP system, for example order creation or changes to material stock.V2 modules describe less critical secondary changes. These are pure statistical updates, for example resultcalculations.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.© 2009 SAP AG page 13/82
  14. 14. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadFigure 4: Monitoring objects – Update errorsMonitoring 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 thatneed to be billed. If the billing due list was processed previously and it is important to know which billingdocuments were created from this billing due list, it can be displayed in the due list log for this billing run.Monitoring objectsThe monitoring object is the respective due list type. That can be delivery, billing or picking. If a certain user isprocessing the due list, the name of the user can be specified here. If it is user independent, a wild card (*)can be used. The aggregation level needs to be defined. This could be per day, per hour or per log.© 2009 SAP AG page 14/82
  15. 15. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadMonitoring 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.Figure 5: Monitoring objects – Due list log1.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.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 sub-object) can be found in transaction /nSLG1 together with allother specific information to that log.© 2009 SAP AG page 15/82
  16. 16. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadFigure 6: Monitoring 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 usewild cards.Figure 7: Monitoring alerts – Application log/Critical messages© 2009 SAP AG page 16/82
  17. 17. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download1.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. The MTE used for monitoring should be an MTE on the lowest leaf-level, i.e. on attribute level. If an MTE of a higher branch-level (collective MTE) is chosen, then the current and open view in the graphics will show the right alerts but it is not 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.Figure 8: 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 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 monitoringobjects. 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 a job© 2009 SAP AG page 17/82
  18. 18. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloadoverview in an SAP system, is maintained for background jobs or transaction SLG1 to have a look into theapplication log.It is also possible to add new transactions; this could be standard transactions or customer self-writtentransactions.Figure 9: Analysis and monitoring transactionsOn the second tab strip it is possible to specify a 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.txtFigure 10: Analysis & monitoring URL© 2009 SAP AG page 18/82
  19. 19. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadWhen using the monitoring during a Business Process Monitoring session, the specified transactions or URLsare available as buttons within a business process step. When you press these buttons, for instance , you jump directly into the corresponding transaction, either in SAP SolutionManager (here: SAT) or the connected satellite system (here: CT1), for further analysis. In case of URLs, thebutton (e.g. ) contains the short text (limited to 20 characters) from the setup sessionand opens the defined URL in a new browser window.1.7.4.10 Monitoring activitiesMonitoring activities should be set up for every monitoring object within a business process step. Allmonitoring objects defined within a business process step are listed there. To ensure effective monitoring andefficient problem resolution, assign responsibilities and define problem resolution procedures as described inthe following table. Some information has been taken from the previous Solution Support Organization node. Monitoring Team Defines the team that is responsible for monitoring the relevant monitoring object. Use value help F4. Person Resp. Defines the person who is responsible for monitoring the monitoring object. Use value help F4. Frequency Describes how often the responsible person should process the required monitoring activity. Start Time Describes at which time the responsible person should process the required monitoring activity. Problem Indicator A description about what indicates a problem. Error Handling Describes how to react on problems or errors, i.e. how to solve the problem or correct the error. Escalation Path Describes the escalation path in case that the person responsible could not solve the problem. Persons who can be contacted should be maintained here.Table 1: Problem resolution proceduresYou can enter additional information related to this business process step in the tables MonitoringActivities, Error Handling, Restart of Step and Escalation Path. That information is valid for the wholebusiness process step and help users who have to carry out the monitoring and who are not familiar with thatparticular business process.1.7.4.11 NotificationsYou can set up notifications for the whole business process or for each business process step individually.There are two types of notifications: Workflow notifications and support notifications. Workflow notificationsallow sending messages to a specified recipient in case of alerts, for instance, an e-mail or SAPOffice mail.Support notifications allow setting up a service desk message in case of an alert. The information entered for© 2009 SAP AG page 19/82
  20. 20. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloadthe service desk message serves as a template. The service desk message can be created manually orautomatically.On business process level, you can define notifications for the whole business process, i.e. as soon as thebusiness process gets an alert status, notifications will be triggered. Alternatively, notifications can be definedfor every monitoring type individually, e.g. all alerts related to background jobs of the business process areforwarded to a defined e-mail address.Notifications defined on business process step level will overrule the configuration made on business processlevel for this particular step.Workflow notification Sender Must be a user within in the monitoring client of SAP Solution Manager. This user can even be a system user without any roles or profiles, but the user must have a valid e-mail address which the used mail server knows. Recipient Address Depending on the recipient type, the recipient name is required. This can be any e- mail address, an SAP user name in the same system, a remote SAP name or a shared distribution list. In case of an SMS you need to enter SMS:<cell phone or pager number>. Reci. Type There are currently five different recipient types: U (e-mail), K (for SMS and pager), B (SAP user name), R (remote SAP name) and C (shared distribution list). No. of Yellow Alerts Number of YELLOW alerts that can occur before an automatic notification is triggered No. of Red Alerts Number of RED alerts that can occur before an automatic notification is triggered Max Wait Time [h] Once the maximum wait time [hours] has elapsed, a notification is created even if 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, …)Table 2: Workflow notificationSupport notifications Priority Defines the priority of the support notification. Queue Defines the support component on which the message is put. This component must exist within the service desk. Processor Defines a default processor who should process the message. The processor must be known within the service desk and must be SAP user name defined as a business partner with role employee.© 2009 SAP AG page 20/82
  21. 21. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download Text Template Text templates can be defined that will then be available for service desk messages manually created for alerts. Automatic Support notifications will be created automatically depending on the alert thresholds. Reporter Necessary if service desk messages are created automatically. Must be a SAP user name defined as a business partner with role general. Num of YELLOW Necessary when service desk messages are created automatically, e.g. after ten Alerts yellow alerts a service desk message should be created. Num of RED Alerts Necessary when service desk messages are created automatically, e.g. after five red alerts a service desk message should be created.Table 3: Support notifications If in addition to Queue, Processor, Priority and Reporter either one of the columns Num of YELLOW Alerts or Num of RED Alerts is filled with a value, the automatic support notification creation is configured. In case that both columns are filled with a value, the automatic support notification creation works with a logical OR operation. Hence, with the figures in the table above the system would create a support notification if there are either more than nine yellow alerts or more than four red alerts for which no support notification has been created yet.1.7.5 Business Process Monitoring processFor a successful and efficient Business Process Monitoring, you have to define a process for implementingyour monitoring concept. This includes the definition of the roles and responsibilities involved. You need todefine who is supposed to carry out which activity within the process and how communication between thedifferent roles within the support organization is supposed to take place.A Business Process Monitoring concept has to be tightly integrated with the support organization. Thisincludes the integration with the Incident- and Problem Management processes and the ChangeManagement process. These processes have to be adjusted to the Business Process Monitoring concept sothat communication and escalation procedures defined within these processes support the Business ProcessMonitoring concept. This includes the final communication of open alerts to SAP.Wherever communication connected with Business Process Monitoring happens outside these supportprocesses, separate communication and escalation paths and procedures have to be defined.Please see the separate Best Practice for General Business Process Management for further details.1.7.6 Legend This symbol indicates a paragraph from where you can navigate to another chapter of this document for more detailed information on a topic. This symbol indicates a paragraph from where you can navigate to another document within the SAP Service Marketplace for more detailed information on a topic.© 2009 SAP AG page 21/82
  22. 22. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download2 Business Process Monitoring for a Point of Sale (POS) Download Data TransmissionPoint of sale (POS) outbound processing or so called POS download is the business process where thecentral SAP ERP system in head office, which is the key system for maintenance of retail related master datasuch as articles and prices, prepares and sends the relevant data to the stores.The POS download process is extremely critical in a retail environment because it ensures that the local POSsystems in stores have the right information to be able to perform necessary tasks like selling, goodsreceipting, calculation of promotions and bonus buys and so on. And very often that information needs to fit toadvertisements published.POS download business scenario is usually the pre-condition to be able to run POS inbound or so calledPOS upload processing to record sales performed.This chapter deals with both available business process variants to support information exchange with POSsystems. You can recognize this in two different resulting data record types, so called IDocs. So thisdocument uses the POS download term when referring to the business process independent from theprocess variants which are POS outbound IDoc types and assortment list IDoc types.First option is to use the standard POS outbound interface which is a set of functionalities and IDocs totransmit master data to POS systems with key focus on article, EAN, and price. The relevant IDoc type isWP_PLU which can be accompanied by other data objects (IDocs) for merchandise categories, EANreferences, promotions and bonus buys, currencies, taxes, customers, and bill of materials.The second option is the so called assortment list. This is a set of functionalities around the IDoc WBBDLDwhich is able to transmit more complex information related to article like source of supply, stock etc. This isrecommended if additional retailing functions (such as the entry of a goods receipt) also have to be carriedout in a store retailing system.The assortment list is usually also known with relevance to other business processes like supporting printedlist of SKUs in stores on paper or to support SAP for Retail Store online connectivity of back office in store.But for that BPM procedure these business processes are out of scope. Only the transmission of IDoc forassortment list is in scope.Common to both business process variants for POS download is the task to send out data changes. Thesechanges are done by business persons in head office and are relevant for a specific store. Therefore, threeprocessing modes are possible: Initialization, change message, and manual request. The initialization usuallyneeds to be done once for the stores concerned, it sends the full set of all articles listed in the store. Then youonly have to plan at regular intervals (usually daily) the program for evaluating changes. The manual requestusually is for exceptions or error handling and does not interfere with change message.The POS outbound process links usually at least three technical systems/ platforms; the central SAP ERPsystem in head office with the local point of sale systems using data transfer tools via internet and phone andalso middleware for data mapping and data conversion. An option for data mapping tools is SAP PI to beused and also for POS system to use SAP POS or SAP EPOS with both integrated standard content© 2009 SAP AG page 22/82
  23. 23. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Downloaddelivered. But this BPM concentrates on monitoring requirements inside SAP ERP and handles data mappingand POS as black box.SAP ERP provides a separate monitoring transaction to monitor the success of the transmission of datachanges. This is the POS interface monitor. The POS interface monitor uses information from the statustables of POS download. It can be used to track each transfer and type of preparation. The POS interfacemonitor transaction indicates for which stores preparation and transfer of data was completed and IDocs havebeen created. It also indicates which IDocs contain errors, how many errors are in an IDocs, and also errorlogs for faulty IDocs are displayed in order to allow corrective actions.To enable you to monitor SAP ERP POS download processes even better, an additional transaction WPER2,providing several individual reports for troubleshooting, has been delivered by SAP. These checking tools areable to be executed after a POS download run periodically to indicate further issues with POS outbound andassortment list. No customizing settings are necessary to execute these reports but the monitoring teamneeds to carefully study the background of reports provided. Therefore, these reports available in transactionWPER2 are discussed in greater detail within this document.In addition to the business importance of that process, also the required system performance and throughputis critical in retail environment. This is because of the potentially high number of Stock Keeping Units (SKUs)in a store and SKUs changing in seasons and also usually a high number of stores in a retail chain.Moreover, all this can go along with more or less complex price rules up to store specific pricing. Thereforethe POS download and its related areas like listing, pricing, and store formatting need a good and lean set upin project mode and a strong monitoring in production mode. Also technical abilities and functions likeperformance monitoring, data volume management, and data archiving need to have a strong focus inproduction mode.In the year 2000 the high performance retailing initiative (HPR) which has been an SAP program to deliverbundled performance enhancements in SAP for Retail and ship to customers had been able to achieve ahigher data throughput with SAP for Retail for key business processes. Also the business process of POSdownload for both variants, POS outbound and assortment list had been key areas of improvements.The following table highlights the improvements delivered with the HPR version in bold and the possible use: Condition Change Document Enhanced Change Pointers Index in Table WIND Table BDCP2Normal assortment list Not possible EnabledHPR assortment list Mandatory (see OSS 603472) EnabledPOS outbound WP_PLU Enabled EnabledTable 4: HPR version improvementsIn this document, both, the normal assortment IDOC processing, and the HPR assortment list processing areconsidered. In fact, in the real monitoring procedure it does not make a difference.© 2009 SAP AG page 23/82
  24. 24. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadTools like WIND and BDCP2 are typically set up during the implementation project. Therefore, the setup ofthese tools is not in the scope of this solution operations document.But also the operators, using this monitoring BPM need to be aware of possible potential to increaseperformance using the improvements from high performance retailing. They need to understand thebackground why this BPM gives for assortment list business process different reports and transactions.Hence, the introduction in chapter 2 highlights the HPR improvements to the audience of this document.The reports and features (mentioned in the following chapter) and the OSS notes (mentioned in chapterFurther Information) together with online help are that detailed and comprehensive to enable a project teamto migrate to new HPR improvements if operator recommends to increase performance.An achievement of the HPR initiative was the introduction of the HPR assortment list which facilitates thecreation of WBBDLD IDoc with modified scope/ content through new SAP transactions. For details regardingthe modified scope and especially reduced business functionalities to accommodate for performance, seeOSS note 720514.Another result of HPR improvements is the use of the condition document index to find and send changedprice conditions. The improvement is facilitated by the new table WIND. Using the WIND table changepointers must not be used anymore for price changes. The system only updates a new work list table as soonas conditions are saved. The change message of IDocs refers to that table. For more information see chapterFurther Information with OSS notes mentioned.The WIND technology is enabled through IMG configuration as follows:Select Retail Pricing • Pricing Worklist • Direct Entry for Creating WorklistFor customers already using POS download business process and having change pointers for conditionchanges in tables BDCP and BDCPS, who wants to increase performance by introducing WIND, SAPprovides migration reports and procedures.Report RWDBBMIG (see OSS note 603472) to migrate change pointers for condition changes from eitherBDCP/BDCPV or BDCP2 (depends on setting in table TBDA2) into WIND. Please keep in mind thebackground of OSS note 603472 (WIND is mandatory for using HPR assortment list).For POS outbound, you need to follow the procedures described in the online help for POS outbound. Theevaluation of conditions changes is also described in OSS note 519685. The description includes the use ofreport RMEBEIN4 and especially of report RMEBEMIG to set the migrated flag.When intending to use WIND technology for POS outbound, you may not forget to delete all records formessage type WP_PLU and object COND_A with transaction BD52.A further improvement of HPR initiative is a new table for change pointers for non-condition-related changes– instead of BDCP and BDCPS the new table BDCP2 is used. See OSS note 305462, describing thenecessary steps with migration transaction BDCPMIG and necessary customizing in BD60 for POS outboundand for assortment list.© 2009 SAP AG page 24/82
  25. 25. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadThe following steps need to be done if you want to use full advantage of high performance retailing: Archive (delete) processed or old change pointers Activate BDCP2 for IDocs, according note 305462 Migrate BDCP to BDCP2 Activate WIND Migrate BDCP2 to WIND2.1 Sample ScenarioWonderful Food & Clothes Ltd. is a multi channel retailer founded in Switzerland running stores all over USAand Europe. In Germany, Austria, Switzerland they run company owned stores offering also a wide range ofservices especially for brides. In the USA they have a lot of small corner stores because Americans like goodfood from Switzerland. In Italy, Spain, Portugal, Eastern Europe and in Scandinavia they are present usingfranchisee business. The franchisees use different kinds of EPOS systems from various vendors.Therefore, Wonderful Food & Clothes Ltd. decided to use POS outbound IDocs (among others WP_PLU) togive their franchisees the possibility to support the various requirements of different EPOS systems.Data mapping from IDocs to the various POS solutions is done with various tools in the responsibility offranchisees. For their own stores they use a POS solution from SAP with integrated content and SAP PI.They also plan to use SAP for Retail Store starting next year. They use the POS outbound process withassortment list IDoc. Because of a bigger number of stores and their smaller range of processes, theydecided to use HPR assortment list for the US stores.So they run the following core business processes:1. Maintain (new) store as master data called site in SAP ERP2. Maintain merchandise categories and assign to store3. Maintain articles as master data in SAP ERP, especially main EAN4. List articles to new store5. Maintain prices for articles in storeThe above mentioned process steps are processes done by the business as master data maintenance incategory management and are not described on the current BPM but they are the trigger and input for POSoutbound process.1. If a store is a new store in SAP ERP, Wonderful Food & Clothes Ltd. runs an initialization or dummy initialization2. Run change message for stores to send off daily new articles, new listings, new prices with the created IDocs3. Copy the IDocs for the US stores and transmit all IDocs4. Monitor the data transfer, correct the data, and again run change message as well as send IDocs off5. Reorganize change pointers with deletion of status records in table WDLS to keep next change run smooth and avoid change pointers to be processed a second time6. Delete the processed change pointers7. Archive the IDocs8. Receive IDocs, transform with data mappings and send off files from middleware to POS9. POS system receiving files via phone line and update central store back office server© 2009 SAP AG page 25/82
  26. 26. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadThe following chapters takes you step by step through these business processes, explaining where and howyou can identify focus points for Business Process Monitoring. For each business process step the mosteffective ways for Business Process Monitoring in the context of the example are highlighted.2.2 Business Process POS Outbound with POS Interface IDocsAs stated above the POS outbound IDocs are used to supply simple POS systems in stores with updateddata at regular intervals. The SAP ECC system formats the data in question in IDoc format for the POSoutbound interface, taking account of the current store assortment and transfers these IDocs to the storesystems using ALE (application link enabling) technology. This is usually done in the evenings and covers aspecific lead time period (usually a few days to prepare data changes ahead). The system determines whichdata have changed up to the current date and which data are going to change during the configured leadtime. The system formats data specifically for individual stores, which means each store only receives datathat is relevant to that store.Please see following process flow:Figure 11: Process flow point of sale outbound variant 1 with POS interface IDocs© 2009 SAP AG page 26/82
  27. 27. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadSpecial messages and intermediate documents (IDocs) for POS systems are defined for the followingobjects: Merchandise categories (IDoc category: WPDWGR01) Articles (IDoc category: WP_PLU02 or WP_PLU03 if article hierarchy is used) EAN/UPC references (IDoc category: WP_EAN01) Set assignments (IDoc category: WPDSET01) Follow-on items (IDoc category: WPDNAC01) Exchange rates (IDoc category: WPDCUR01) Taxes (IDoc category: WPDTAX01) Person data (IDoc category: WP_PER01) Bonus buys (IDoc category: WPDBBY01) Promotion discount (IDoc type: WPDREB01)Some of these objects are time-dependent which means that their data can change within the lead time.Other objects have data that does not change during the lead time. Unlike standard ALE master datadistribution, POS outbound does not work with one, but with nine message types simultaneously.It is important to be aware of this fact if you do not want to send certain message types. In this case, note thefollowing correlations for the activation of change pointers:Logical Message Type That Object Message Type to Be ActivatedIs to Be SentWPDWGR Merchandise categories WPDWGRWP_PLU Article master WP_PLUWP_EAN EAN/UPC References WP_EAN WP_PLUWPDSET Set assignments WPDSET WP_PLUWDPNAC Follow-On Items WPDSET (!) WP_PLUWP_PER Personnel Data WP_PERWPDTAX Taxes No activation required as no change pointer analysis is necessaryWPDCUR Exchange rates No activation required as no change pointer analysis is necessaryWPDREB Promotion discount No activation required as change pointers are created directly from the application and not using the ALE layerTable 5: Correlations for activation of change pointers© 2009 SAP AG page 27/82
  28. 28. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadNote: Each chapter will be structured in the following way:2.1.1.1 Description and general information2.1.1.2 Monitoring requirements2.1.1.3 Monitoring objects in SAP Solution Manager (in this table you will find all monitoring objects in SAP Solution Manager you should use to monitor your solution)2.1.1.4 Further monitoring objects (in this table you find the monitoring objects you should monitor using special reports or transactions)2.1.1.5 How to find meaningful thresholds per monitoring object (all aspects which are described within this subsection are hints how you could find thresholds for the monitoring objects you should monitor.)2.1.1.6 Scheduling of background jobs (in this table you find all relevant information to schedule the jobs in the recommended way)It is a strongly recommended Best Practice to use SAP Solution Manager to monitor these objects asdescribed in section 2.1.1.3.2.2.1 Business process step 1: Initialize or dummy initialize new store2.2.1.1 Description and general informationThe initialization is the prerequisite for transferring change messages. It transmits all listed articles in a storewith all related data. In most cases several IDocs are created. Normally, when a new store opens and gets anew store back office server you would expect the store back office server to be empty and therefore needingthis data provided by SAP ECC.To run initialization start transaction WPMI and plan the program RWDPOSIN initialization in the backgroundas you can expect a long runtime.Scenario-specific sampleUsually you select one store by the other by creating a job variant per store if you would need to initializemore than one store in one point in time.If the POS system contains all the necessary data in the first start-up of the POS outbound – maybe thedatabase of an already existing store back office server was copied to the new store back office server – adummy initialization can be done, using program RWDPOSDU. The system does not transfer any data to thePOS systems, but only creates special entries in the status table WDLS of the POS outbound. These entriesallow the system to start creating change messages after the dummy initialization.© 2009 SAP AG page 28/82
  29. 29. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download2.2.1.2 Monitoring requirementsError monitoringIt is very important to know that the program must be completed with the status X (error free) or H (notes).This means preparation is OK (field WDLS-GESST is X or H). Otherwise no change messages will becreated. You see the status in POS monitor as Format Status.Background job for RWDPOSIN and RWDPOSDUCheck the job log SM37 for cancellations. Check POS monitor WPER for status and error logs. For errormonitoring for initialization mainly the POS monitor transaction WPER is used. If initialization failed you needto correct data and repeat the execution at a later point in time if necessary. The dummy initialization is notcritical at all because it just sets a flag in a table and it is very likely that no error will occur.Performance monitoringFor performance monitoring of an initialization you need to watch the runtime of the job. The only thing youcan do in advance is to plan no other system resource consuming jobs at the same time and optionally, applyextraordinary basis parameters. While the job runs for a store, it needs to create and find all articles. It neithercan run in parallel nor can it be split by article number ranges.Throughput monitoringIn case the time window for an initialization run might be not sufficient for the relevant article data volume,there is the possibility to run manual requests with article number ranges. This allows providing the store backoffice server database with IDocs. After that you run dummy initialization to set the status correctly.Backlog monitoringSee comments on throughput monitoring.2.2.1.3 Further monitoring objectsMonitoring Selection Alert Analysis Tool on Monitoring Frequency/ DataObject Criteria Satellite System CollectionReport RWDPOSIN, Long job runtime, job cancellation , SM37 Runs usually once when newRWDPOSIN date of job time out, error messages in job log, store opened; when job is(initialization (usually current job canceled or delayed running, monitor in periodicexecution) date) intervals system/runtime performanceReport RWDPOSDU, Job cancellation; long runtime is not SM37 Usually once when new storeRWDPOSDU date of job likely as this job just creates one opened (as an alternative to(dummy (usually current table entry in table WDLS. RWDPOSIN when storeinitialization date) database has full data alreadyexecution) copied from other store back office server etc.Processing status Date of job Look for tree branch in outbound WPER After job executionof initialization in finished and processing – not fully processed –POS monitor outbound preparation mode I = initializations: application POS Double click to read system log text with error message© 2009 SAP AG page 29/82
  30. 30. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download2.2.1.4 How to find meaningful thresholds per monitoring objectEvery error that occurred is critical as it will lead to wrong information in the registers of the stores. Errorsoccurred if table WDLS shows in field GESST H. A processing without errors or hints is indicated by X in thisfield.2.2.2 Business process step 2: Evaluate master data changes, collect and prepare data, create IDoc2.2.2.1 Description and general informationThis step runs the job for the daily change message which collects the changes becoming valid in future inthe lead time or done by business in daily online transactions like article maintenance, listing, pricemaintenance, customer maintenance. The changes are evaluated and the data which needs to be transferredis prepared and completed and saved in an IDoc.Here too, the distinction depending on configuration takes place if HPR features like WIND or BDCP2 areevaluated.Scenario-specific sampleThe data are prepared for the stores selected in the job variant. The data, i.e. what kind of IDocs should beprepared, come from configuration of POS outbound profiles which is assigned to the store. So in most casesWP_PLU IDoc plus several others are created with that job according to POS outbound profile.Here too, the distinction depending on configuration takes place if HPR features like WIND or BDCP2 areevaluated.2.2.2.2 Monitoring requirementsError monitoringFor error monitoring of change messages mainly the POS monitor transaction WPER is used. It is alsonecessary to monitor the job in SM37.Background job for RWDPOSUPCheck the job log for cancellations and runtime. If the job finishes correctly it will not show application errorsin job log as the application errors will be shown in POS monitor transaction with long text and description.For more information please refer to chapter 2.2.4.Performance monitoringFor performance monitoring of a change message you need to watch the runtime of the job.Throughput monitoringTo increase throughput, parallelization should be used. In the report RWDPOSUP you can set the flag forparallelization, select relevant stores, enter a server group on which a parallel process shall run, and enterthe maximum number of parallel processes.© 2009 SAP AG page 30/82
  31. 31. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadBacklog monitoringIt is important to watch the runtime of the job regularly. If a job takes too much time, it is not finished. This iscritical since IDocs are not created and the prices and other data cannot be sent to the store in time. Thatincreases risk that stores are selling articles being priced incorrect.The operator also needs to be in touch with the business process champion. So business can make theoperating team aware when they are going to change lots of data at one point in time and POS outbound islikely to work with much more changes than normal. For example, when a new season with new prices startsor new collections are listed, the operator would need to change starting time of RWDPOSUP toaccommodate for longer runtime because of a larger amount of data.Scenario-specific sampleIt is import that RWDPOSUP finished in time before stores are opening and require correct prices.Transmission and conversion need about one hour. So if stores open at 08:00 clock, it must be assured thatRWDPOSUP is finished at 07:00.2.2.2.3 Monitoring objects in SAP Solution ManagerMonitoring Object Selection Criteria Alert Analysis Tool on Monitoring Satellite System Frequency/ Data CollectionBackground job S_DE_R_RWDPOS Long job runtime, job SM37 Every five minutesS_DE_R_RWDPOSUP_D UP_D, RWDPOSUP cancellation , time out, error during every job(Report RWDPOSUP) messages in job log execution(changes message execution)2.2.2.4 Further monitoring objectsMonitoring Object Selection Criteria Alert Analysis Tool on Monitoring Satellite System Frequency/ Data CollectionProcessing status of change Date of job finished Look for tree branch in WPER After job executionmessage in POS monitor and outbound outbound processing – not application POS fully processed – preparation mode u = update double- click to read system log text with error message2.2.2.5 How to find meaningful thresholds per monitoring objectYou can determine the threshold when POS outbound needs to be finished depending on your businessneeds. Therefore, you need to work backwards on your timetable under consideration of the time forconversion and for transmission as well as some security time to determine when RWDPOSUP has to befinished at the latest. Then you need to work out with business how many changes they do on average andlook how long a job takes on average and work backwards. If business leaves average due to businessreason you need again to accommodate threshold and start the job earlier.© 2009 SAP AG page 31/82
  32. 32. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS Download2.2.2.6 Scheduling of background jobsThis job is usually scheduled on a daily basis in the evening after all master data changes have been carriedout in the system.Job scheduling requirementsRecommended ABAP Variant Scheduling Predecessor Successor Scheduling Error Handling inor Generated Report Job Job Restriction Case ofJob Name CancellationS_DE_R_RWDP RWDPOSUP To be Runs usually daily; S_DE_R_RS Root cause 1OSUP_D defined monitor when job is EOUT00_D if analysis required, running in periodic IDocs are not potentially a intervals system/ sent restart might be runtime performance automatically sufficientS_DE_R_RSEO RSEOUT00 Daily S_DE_R_RW Restart jobUT00_D DPOSUP_D2.2.3 Business process step 3: Copy IDocs within ECC retail (optional) and send out IDocs from ECC retail2.2.3.1 Description and general informationFrom many stores the POS download IDocs (POS outbound IDocs and assortment list IDocs) are identical oronly differ very slightly. This means to optimize performance and decrease runtime it is not necessary togenerate IDocs for all stores but just for certain reference stores. Then these IDocs created for the referencestores with RWDPOSUP can be distributed according to certain rules. It can significantly improveperformance. The following chapter describes how this copying mechanism is set up. Please note that thissolution is optional and does not apply for customers where for example store individual prices exist.In addition, you can use IDoc copy management as a one-off for the initialization as described in step 1 forthe initial supply of a new store, if the stores can be grouped and a reference store can be determined. Thenfor the stores which are able to get a copied IDoc only a dummy initialization is required.To enable copy management for IDocs there must be a copy rule in the SAP system. A programminginterface port must be assigned to the reference recipient. Define an ABAP programming interface port in theport description (IDoc and EDI basis) and assign it to the function module WDL_COPY_LOG. File ports mustbe assigned to the recipients of the copies. All recipients that are assigned to a reference must be assignedto one and the same file port. The partner profiles for the recipients must be maintained in such a way thatIDocs are collected first. The IDoc copy management tool sends the IDocs automatically.Various applications generate outbound IDocs for the reference recipients. Using the programming interfaceport, which is assigned to each reference customer within the partner profile, the SAP system logs thesereference IDocs in table WDLCOPY. The IDoc copy management tool uses this log.1 The name is defined in accordance with the naming convention specified in the Best Practice document Job Scheduling Managementto be found under https://service.sap.com/solutionmanagerbp. The nam e indicates: S for SAP standard coding, DE for the involvedorganizational information, R for the involved business/application area, RWDPOSUP is the ABAP report, D for the daily job frequency.© 2009 SAP AG page 32/82
  33. 33. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadProgram RWDLCOPY_MANAGE copies the reference IDocs to the recipients (customers) that are assignedto it using the copy rule. It then generates trigger files for the individual recipients for each message type ifthis is set in the copy rule.The tool optimizes its performance internally using asynchronous processes. Multiple scheduling is thereforenot recommended.Another program is RSEOUT00, which sends out the collected IDocs in ECC database as files to thefollowing conversion tool. RSEOUT00 is required if in the partner agreement configuration in WE20 the IDocsare set to collect IDocs. SAP strongly recommends this for performance and monitoring reasons and asstated above mandatory for the IDoc copy management tool.2.2.3.2 Monitoring requirementsError monitoringYou need to monitor the job for report RWDLCOPY_MANAGE and check the log for potential errors. Youalso have to monitor the job for report RSEOUT00 and check in the log if everything is alright.See screenshot how the job’s log for the report RWDLCOPY_MANAGEMENT looks like:Figure 12: Results of IDoc copy management toolsPerformance monitoringYou need to monitor the runtime of jobs for both reports but usually they are not performance critical. Themost performance critical job is RWDPOSUP which is described earlier in this document.© 2009 SAP AG page 33/82
  34. 34. Best Practice for Solution OperationsManage Operations for SAP for Retail – POS DownloadThroughput monitoringHere you only have to make sure that RWDLCOPY_MANAGE and RSEOUT00 are planned in time – beforedata are required in store for selling and under consideration of the required time for data conversion andtransmission outside ECC.Backlog monitoringMake sure that RWDLCOPY_MANAGE and RSEOUT00 are planned in time before data are needed in store.2.2.3.3 Monitoring objects in SAP Solution ManagerMonitoring Object Selection Criteria Alert Analysis Tool on Monitoring Frequency/ Satellite System Data CollectionBackground job S_DE_R_RWDLCOPY_M Long job runtime, job SM37 Every five minutesS_DE_R_RWDLCOPY_ ANAGE_D, cancellation, time out, error during every jobMANAGE_D (report RWDLCOPY_MANAGE, messages in job log executionRWDLCOPY_MANAGE)Background job S_DE_R_RSEOUT00_D, Long job runtime, job SM37 Every five minutesS_DE_R_RSEOUT00_ RSEOUT00, cancellation, time out, error during every jobD messages in job log execution(Report RSEOUT00)(IDoc transmission offECC )IDoc processing status Direction, port, partner Number of IDocs of type WE05 or WE02 Every 15 minutesin case of IDoc interface number, partner type, WPDWGR, WP_PLU, partner function, message WP_EAN, WPDSET, type, basic type, message WPDNAC, WPDCUR, code, message function, WPD_TAX, WP_PER, IDoc age WPDREB in an error-status2.2.3.4 How to find meaningful thresholds per monitoring objectYou can determine the threshold when the POS assortment list needs to be finished depending on yourbusiness needs. Therefore, you need to work backwards on the timetable from when you need the data,under consideration of the time for conversion and transmission and some security time to determine whenRWDLCOPY_MANAGE and RSEOUT00 must be finished at the latest.© 2009 SAP AG page 34/82

×