Manage Operations for SAP for Retail - POS Download

Best Practice for Solution Operations

Manage Operations for SAP for Retail POS Download

Dietmar-Hopp-Allee 16 D-69190 Walldorf CS

customer DATE

June 10 2009 SOLUTION MANAGEMENT PHASE

STATUS

published VERSION

3.0 SAP SOLUTION

Operations & Continuous Improvement Best Practices for Solution Operations TOPIC AREA

SOLUTION MANAGER AREA

Application & Integration Management Business Process Operations

Best_Practice_POS_Outbound_V30_upd.doc – 10.06.2009

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Table of Contents 1 Management Summary 1.1 Goal of Using This Best Practice 1.2 Alternative Practices 1.3 Staff and Skills Requirements 1.4 System Requirements 1.5 Duration and Timing 1.6 How to Use This Best Practice 1.7 Best Practice Procedure 1.7.1 Preliminary tasks 1.7.2 Monitoring concepts 1.7.3 Business Process Monitoring in SAP Solution Manager 1.7.4 Monitoring types for Business Process Monitoring in SAP Solution Manager 1.7.4.1 Application monitor 1.7.4.2 Background job 1.7.4.3 ABAP dump collector 1.7.4.4 Dialog performance 1.7.4.5 Update errors 1.7.4.6 Due list log 1.7.4.7 Application log 1.7.4.8 Other CCMS monitors 1.7.4.9 Analysis and monitoring tools 1.7.4.10 Monitoring activities 1.7.4.11 Notifications 1.7.5 Business Process Monitoring process 1.7.6 Legend 2 Business Process Monitoring for a Point of Sale (POS) Download Data Transmission 2.1 Sample Scenario 2.2 Business Process POS Outbound with POS Interface IDocs 2.2.1 Business process step 1: Initialize or dummy initialize new store 2.2.1.1 Description and general information 2.2.1.2 Monitoring requirements 2.2.1.3 Further monitoring objects 2.2.1.4 How to find meaningful thresholds per monitoring object 2.2.2 Business process step 2: Evaluate master data changes, collect and prepare data, create IDoc 2.2.2.1 Description and general information 2.2.2.2 Monitoring requirements 2.2.2.3 Monitoring objects in SAP Solution Manager 2.2.2.4 Further monitoring objects 2.2.2.5 How to find meaningful thresholds per monitoring object 2.2.2.6 Scheduling of background jobs 2.2.3 Business process step 3: Copy IDocs within ECC retail (optional) and send out IDocs from ECC retail 2.2.3.1 Description and general information 2.2.3.2 Monitoring requirements

© 2009 SAP AG

6 6 6 6 7 7 7 8 8 8 8 9 10 10 11 12 13 14 15 17 17 19 19 21 21 22 25 26 28 28 29 29 30 30 30 30 31 31 31 32 32 32 33

page 2/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.3.3 Monitoring objects in SAP Solution Manager 2.2.3.4 How to find meaningful thresholds per monitoring object 2.2.3.5 Scheduling of background jobs 2.2.4 Business process step 4: Monitor, correct, and repeat POS outbound 2.2.4.1 Description 2.2.4.2 Monitoring requirements 2.2.4.3 Monitoring objects in SAP Solution Manager 2.2.4.4 Further monitoring objects 2.2.4.5 How to find meaningful thresholds per monitoring object 2.2.4.6 Error handling per monitoring object 2.2.4.7 Scheduling of background jobs 2.2.5 Business process step 5: Reorganize change pointers, status records, and WIND entries 2.2.5.1 Description and general information 2.2.5.2 Monitoring requirements 2.2.5.3 Monitoring objects in SAP Solution Manager 2.2.5.4 How to find meaningful thresholds per monitoring object 2.2.5.5 Error handling per monitoring object 2.2.5.6 Scheduling of background jobs 2.2.6 Business process step 6: Delete change pointers and status records 2.2.6.1 Description and general information 2.2.6.2 Monitoring requirements 2.2.6.3 Monitoring objects in SAP Solution Manager 2.2.6.4 How to find meaningful thresholds per monitoring object 2.2.6.5 Error handling per monitoring object 2.2.6.6 Scheduling of background jobs 2.2.7 Business process step 7–9: Middleware (enterprise application integration tool): Receive, transform, and send information 2.2.7.1 Description 2.2.7.2 Monitoring requirements 2.2.7.3 Monitoring objects in SAP Solution Manager 2.2.7.4 Further monitoring objects 2.2.7.5 How to find meaningful thresholds per monitoring object 2.2.7.6 Error handling per monitoring object 2.2.8 Business process step 10–11: POS system: Receive information and update database 2.2.8.1 Description and general information 2.2.8.2 Monitoring requirements 2.2.8.3 Monitoring objects in SAP Solution Manager 2.2.8.4 Further monitoring objects 2.2.8.5 How to find meaningful thresholds per monitoring object 2.2.8.6 Error handling per monitoring object 2.3 Business Process POS Outbound with Assortment List 2.3.1 Business process step 1: Run full version to initialize or dummy initialize new store 2.3.1.1 Description and general information 2.3.1.2 Monitoring requirements 2.3.1.3 Further monitoring objects 2.3.1.4 How to find meaningful thresholds per monitoring object

© 2009 SAP AG

34 34 35 35 35 36 42 43 43 43 43 44 44 45 45 45 46 46 46 46 47 47 47 47 47 48 48 48 48 49 49 49 49 49 49 49 50 50 50 50 52 52 52 53 53

page 3/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.1.5 Error handling per monitoring object 2.3.2 Business process step 2: Run change version to evaluate master data changes, collect and prepare data, create IDoc 2.3.2.1 Description and general information 2.3.2.2 Monitoring requirements 2.3.2.3 Monitoring objects in SAP Solution Manager 2.3.2.4 Further monitoring objects 2.3.2.5 How to find meaningful thresholds per monitoring object 2.3.2.6 Error handling per monitoring object 2.3.2.7 Scheduling of background jobs 2.3.3 Business process step 3: Copy IDocs within ECC retail (optional) and send out IDocs from ECC retail 2.3.3.1 Description and general information 2.3.3.2 Monitoring requirements 2.3.3.3 Monitoring objects in SAP Solution Manager 2.3.3.4 How to find meaningful thresholds per monitoring object 2.3.3.5 Error handling per monitoring object 2.3.3.6 Scheduling of background jobs 2.3.4 Business process step 4: Monitor, correct, and repeat data transfer of assortment list 2.3.4.1 Description and general information 2.3.4.2 Monitoring requirements 2.3.4.3 Monitoring objects in SAP Solution Manager 2.3.4.4 Further monitoring objects 2.3.4.5 How to find meaningful thresholds per monitoring object 2.3.4.6 Error handling per monitoring object 2.3.4.7 Scheduling of background jobs 2.3.5 Business process step 5: Reorganize change pointers, status records, and WIND entries 2.3.5.1 Description and general information 2.3.5.2 Monitoring requirements 2.3.5.3 Monitoring objects in SAP Solution Manager 2.3.5.4 How to find meaningful thresholds per monitoring object 2.3.5.5 Error handling per monitoring object 2.3.5.6 Scheduling of background jobs 2.3.6 Business process step 6: Delete change pointers and status records 2.3.6.1 Description and general information 2.3.6.2 Monitoring requirements 2.3.6.3 Monitoring objects in SAP Solution Manager 2.3.6.4 Scheduling of background jobs 2.3.6.5 How to find meaningful thresholds per monitoring object 2.3.6.6 Error handling per monitoring object 2.3.7 Middleware (enterprise application integration tool): Receive, transform, and send information 2.3.7.1 Description 2.3.7.2 Monitoring requirements 2.3.7.3 Monitoring objects in SAP Solution Manager 2.3.7.4 Further monitoring objects 2.3.7.5 How to find meaningful thresholds per monitoring object © 2009 SAP AG

53 54 54 54 55 55 55 55 55 56 56 57 58 58 58 58 59 59 60 65 66 66 66 66 67 67 68 68 68 69 69 69 69 69 70 70 70 70 71 71 71 71 71 71

page 4/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.7.6 Error handling per monitoring object 2.3.8 POS system: Receive information and update database 2.3.8.1 Description and general information 2.3.8.2 Monitoring requirements 2.3.8.3 Monitoring objects in SAP Solution Manager 2.3.8.4 Further monitoring objects 2.3.8.5 How to find meaningful thresholds per monitoring object 2.3.8.6 Error handling per monitoring object 3 Further Information 3.1 Troubleshooting 3.2 Related Best Practice Documents 4 Appendix 4.1 Example Background Job Monitoring 4.2 Example PI Message Process Monitoring 4.3 Example ALE/IDoc Monitoring 4.4 Background Jobs Index of Figures Index of Tables

© 2009 SAP AG

72 72 72 72 72 72 72 72 73 73 73 74 74 76 76 79 81 81

page 5/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

1

Management Summary

1.1

Goal of Using This Best Practice

This 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 and escalation procedures for your business process point of sale (POS) download. These procedures intend to ensure 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 to detect any irregularities or deviations from an ideal business process flow or to detect error situations concerning a core business process at an early stage. This Best Practice contains the recommended approach from SAP which uses whenever possible SAP Solution Manager for the monitoring functionalities. But even if you do not use SAP Solution Manager we recommend to follow the procedures described in this document as much as possible in order to ensure a smooth and reliable flow of your business processes as well as an appropriate response in case of unforeseen errors.

1.2

Alternative Practices

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

1.3

Staff and Skills Requirements

To implement this Best Practice, you require the following teams: Application Management team This team creates the SAP ERP Business Process Monitoring concept and consists of experts from several areas of your company: Business department Solution support organization (for example the basis support or the application support) Implementation project team Business process operations team The business process operations team will be responsible for applying the resulting procedures derived from implementing 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

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

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. 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 Best Practice General Business Process Management, which you can obtain through SAP Solution Manager or the 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 Management

1.4

System Requirements

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

1.5

Duration and Timing

Duration Creating a Business Process Monitoring concept takes approximately one week per business process. Implementing the Business Process Monitoring concept takes approximately an additional week. Timing The best time to apply this Best Practice is during the planning phase or during the implementation phase of your SAP solution.

1.6

How to Use This Best Practice

Here you find a brief description of how you should proceed in using this document: Read through the General Business Process Management Best Practice, available on the SAP Service Marketplace. This document explains the procedures you should use to create a general 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

Best Practice for Solution Operations Manage 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 Procedure

1.7.1

Preliminary tasks

Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in the system: Complete all installation and post-installation actions and procedures including customizing Ensure that the initial download has been successfully executed Apply all SAP recommendations from SAP service sessions and any SAP recommendations resulting from customer problem messages Implement all current SAP support packages upon availability 1.7.2

Monitoring concepts

The monitoring procedures proposed for each business process step are the core of this Best Practice. The monitoring 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 monitoring 2. Performance monitoring 3. Throughput monitoring 4. Backlog monitoring 5. Data consistency monitoring For each of the business process steps you will find the following information: A detailed functional description of the process step Identified monitoring requirements for the process step Defined monitoring objects, alerts, and selection criteria Description of error handling procedures and restartability General monitoring activities that are valid for all or most scenarios are described in the generic part in chapter 1.7.4 Recommendations for performance monitoring can also be found in this chapter. The performance of the most important steps of your core business processes should be monitored on a regular basis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP for Retail solution is generally the same. Therefore, you will only find specific performance monitoring recommendations on selected business process steps. 1.7.3

Business Process Monitoring in SAP Solution Manager

Business Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and processoriented monitoring of the most important or critical business processes, including the observation of all technical and business application specific functions that are required for a steady and stable flow of the business processes.

© 2009 SAP AG

page 8/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

The core business processes that are implemented in a SAP for Retail system or other software and operated by a company are of particular importance, and Business Process Monitoring is intended to ensure a smooth and reliable operation of the business processes and, thereby, that the core business processes meet a company’s business requirements in terms of stability, performance, and completeness. SAP Solution Manager provides a graphic to visualize a company’s (distributed) system and solution landscape and all related business processes. By using Business Process Monitoring, it is possible to define and customize alert situations from a basic set of configurable alerts provided by SAP Solution Manager. These alerts are then visualized by green, yellow, and red alert icons for each individual business process step in the graphical business process representation. Business Process Monitoring is intended to detect and respond to critical situations 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. By the definition of contact persons and escalation paths, Business Process Monitoring can be integrated into the company’s overall strategy for Business Process Management and solution management within their solution support organization. In general, a Business Process Monitoring includes the solution-wide observation of: Business process performance (key performance indicators) Background jobs (Job Scheduling Management tasks) Business application logs (such as any error log, general application log, due list logs etc.) Data transfer via interfaces between software components Data consistency Technical infrastructure and components which are required to run the business processes Required periodic monitoring tasks For further details on Business Process Monitoring please refer to http://service.sap.com/bpm. 1.7.4

Monitoring types for Business Process Monitoring in SAP Solution Manager

Monitoring types are part of the functional scope of Business Process Monitoring as it is available in SAP Solution 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 must be selected. In order to receive detailed information on how to set up the monitoring objects in SAP Solution 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 SAP Solution Manager is that all business processes and business process steps are maintained in the respective solution that contains all

© 2009 SAP AG

page 9/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

affected system components. If you want to learn more about how to set this up, please turn to (URL http://help.sap.com) 1.7.4.1

SAP Solution Manager

Basic Settings.

Application monitor

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

Plug-Ins

SAP Solution Tools

Entry by

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 on how 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/BPM 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 already established 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 tools For 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 (URL http://service.sap.com/BPM 1.7.4.2

Media Library).

Background job

The background job monitoring should be part of a Job Scheduling Management concept (URL http://service.sap.com/solutionmanagerbp, topic area Business Process Operations to find a Best Practice document Job Scheduling Management). Because of several restrictions regarding background job scheduling, e.g. time restrictions, restriction of hardware resources (CPU, main memory, …) or existing

© 2009 SAP AG

page 10/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

dependencies between different activities (e.g. invoices can only be created after the corresponding goods issue is posted, or back order processing and material requirements planning should not run at the same time) it is very important to ensure the stable run of background jobs. A cancelled background job should be identified as soon as possible in order to react as fast as possible. Therefore it is also necessary to define restart procedures and escalation paths. Monitoring objects Before setting up monitoring the monitoring objects must be clearly defined. A monitoring object is a single background job or a group of background jobs. There are four different possibilities to identify a special background 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 possible are discussed in the Best Practice document Background Job Monitoring with SAP Solution Manager which can be found on the SAP Service Marketplace http://service.sap.com/solutionmanagerbp, topic area Business Process Operation. 1.7.4.3

ABAP dump collector

The dump collector provides monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors and collects statistical data of ABAP dumps for reporting reasons. Monitoring objects The monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime error name, the user who is responsible for the runtime error, the client on which the runtime error occurs or the program that leads to the runtime error. Monitoring alerts Possible alert types are the Number of ABAP Dumps (Delta) – all dumps since the last collector run – and Number of ABAP Dumps (Reporting) – all runtime errors of specified type, client, and program for this day or for the previous day.

Figure 1: Alert type Number of ABAP Dumps (Delta)

© 2009 SAP AG

page 11/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

1.7.4.4

Dialog performance

Dialog performance implies the monitoring of the dialog transaction performance of any transaction in the SAP system. This can be a standard transaction or a custom-developed transaction. Monitoring objects The monitoring object is the transaction itself. The customizing has to be done in the Dialog Performance node. 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 remove transactions within the Add/Remove Transactions table. The monitoring can be performed per SAP instance. To this end, select the respective instances in the SAP Instances table, which lists all instances that are maintained for a system. The Alert Types table shows the dialog response time and all parts of the response time that can be monitored, like queue time, load and generation time, database request time and the front-end response time. Select those times that are relevant for monitoring. After saving this node, a subnode Performance Alerts will appear where you can enter the threshold values.

Figure 2: Monitoring objects – Dialog performance

Monitoring alerts Each table in the Performance Alerts sub-node corresponds to an alert type chosen in the higher-level node, and lists the combinations of specified transaction code and SAP instance. For each combination of transaction code and instance that you want to include in the monitoring, specify the threshold 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 possible that the object already exists there. Therefore you can load the current threshold values from the respective systems via the Load thresholds from button, with representing the SID. If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for the threshold values were found for a certain transaction code, default values are set (indicated in column Default). To transfer the

© 2009 SAP AG

page 12/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

threshold values for a single line from right to left, the Copy icon can be used. To transfer all at once (all thresholds for all columns and tables) there is an additional Copy all button.

Figure 3: Monitoring alerts - Dialog performance

1.7.4.5

Update errors

Changes to the data in an SAP system caused by a business process should be written to the database completely or not at all. If the operation is canceled while the transaction is being executed, or if an error occurs, the transaction should not make any changes to the database. These activities are handled by the SAP 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 critical changes. V1 modules describe critical or primary changes; these affect objects that have a controlling function in the SAP system, for example order creation or changes to material stock. V2 modules describe less critical secondary changes. These are pure statistical updates, for example result calculations. Monitoring objects Monitoring of update errors can be configured for online transactions and/or ABAP programs, relevant in a business process. This is the object type. The name of the object is the name of a transaction or the name of the ABAP program itself. If desired, a user executing, the transaction or the ABAP program can be specified. If no user is specified explicitly, all users (represented by *) will be considered in monitoring data evaluation.

© 2009 SAP AG

page 13/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Figure 4: Monitoring objects – Update errors

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

Due list log

A due list is a list that contains several entries (documents) depending on selection criteria. There are different types of due lists in an SAP system of which the following three are most important: Delivery (L), billing (F) and picking (K). The delivery due list can be directly accessed via transaction V_SA, the billing due list via transaction V.21. In case of a billing due list, the list contains e.g. a number of sales documents that need to be billed. If the billing due list was processed previously and it is important to know which billing documents were created from this billing due list, it can be displayed in the due list log for this billing run. Monitoring objects The monitoring object is the respective due list type. That can be delivery, billing or picking. If a certain user is processing 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

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Monitoring alerts For 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 log

1.7.4.7

Application log

The application log provides an infrastructure for collecting messages, saving them in the database, and displaying them as a log. Situations can arise at runtime in application programs that must be brought to the attention of the user in some way. These are usually errors. It can also be useful to report a successful completion. The information that arises is called a message. The set of messages is a log. A log usually also has 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 alerts The application log allows an application- or object-oriented recording of events. An object and any subobject 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 all other specific information to that log.

© 2009 SAP AG

page 15/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Figure 6: Monitoring objects and alerts – Application log

It is possible to monitor for the total number of messages belonging to an object. Therefore the number of messages that raises a YELLOW alert and the number of messages changing from a YELLOW to a RED alert must be maintained. It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs. To configure the monitoring of critical application log messages, the relevant object-/sub-object combinations need to be selected. For each of these combinations the message type, the message ID, and the message number as well as the threshold values for the number of critical messages that are supposed to result in changes from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wild cards.

Figure 7: Monitoring alerts – Application log/Critical messages

© 2009 SAP AG

page 16/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

1.7.4.8

Other CCMS monitors

With other CCMS monitors it is possible to assign any CCMS monitoring tree element (MTE) to a business process step. Therefore it is necessary to call transaction RZ20 in the satellite system and to open a monitor that contains the required alert(s). The name of the monitoring tree element (MTE) can be found by choosing F1. The MTE name needs to be copied 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 threshold values 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 no CCMS but is included as one business process step in your business process. Now you could use one MTE in the CCMS of SAP Solution Manager to monitor the heartbeat of the portal. You could then assign the corresponding alert via other CCMS monitoring to business process step running on the portal system. 1.7.4.9

Analysis and monitoring tools

It is possible to specify analysis transactions or URL addresses (including file directories) per monitoring objects. In case of analysis transactions, these should be used to analyze errors or problems either locally in the SAP Solution Manager system itself (Call Option 1) or directly in the respective satellite systems (Call Option 2). Per default some standard transactions are maintained, e.g. transaction SM37, that provides a job © 2009 SAP AG

page 17/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

overview in an SAP system, is maintained for background jobs or transaction SLG1 to have a look into the application log. It is also possible to add new transactions; this could be standard transactions or customer self-written transactions.

Figure 9: Analysis and monitoring transactions

On the second tab strip it is possible to specify a URL which should be called in order to further analyze the given problem. This is especially interesting if you have some knowledge documents linked to a portal. You define 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://\\\\...,

e.g.

file://\\\server1\operations_documents\operations-handbook.txt

Figure 10: Analysis & monitoring URL

© 2009 SAP AG

page 18/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

When using the monitoring during a Business Process Monitoring session, the specified transactions or URLs are 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 Solution Manager (here: SAT) or the connected satellite system (here: CT1), for further analysis. In case of URLs, the button (e.g.

) contains the short text (limited to 20 characters) from the setup session

and opens the defined URL in a new browser window. 1.7.4.10

Monitoring activities

Monitoring activities should be set up for every monitoring object within a business process step. All monitoring objects defined within a business process step are listed there. To ensure effective monitoring and efficient problem resolution, assign responsibilities and define problem resolution procedures as described in the 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 procedures

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

Notifications

You can set up notifications for the whole business process or for each business process step individually. There are two types of notifications: Workflow notifications and support notifications. Workflow notifications allow 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

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

the service desk message serves as a template. The service desk message can be created manually or automatically. On business process level, you can define notifications for the whole business process, i.e. as soon as the business process gets an alert status, notifications will be triggered. Alternatively, notifications can be defined for every monitoring type individually, e.g. all alerts related to background jobs of the business process are forwarded to a defined e-mail address. Notifications defined on business process step level will overrule the configuration made on business process level 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 email 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:.

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 notification

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 defined as a business partner with role employee.

© 2009 SAP AG

page 20/82

Best Practice for Solution Operations Manage 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 Alerts

Necessary when service desk messages are created automatically, e.g. after ten 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 process

For a successful and efficient Business Process Monitoring, you have to define a process for implementing your monitoring concept. This includes the definition of the roles and responsibilities involved. You need to define 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. A Business Process Monitoring concept has to be tightly integrated with the support organization. This includes the integration with the Incident- and Problem Management processes and the Change Management process. These processes have to be adjusted to the Business Process Monitoring concept so that communication and escalation procedures defined within these processes support the Business Process Monitoring concept. This includes the final communication of open alerts to SAP. Wherever communication connected with Business Process Monitoring happens outside these support processes, 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

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2

Business Process Monitoring for a Point of Sale (POS) Download Data Transmission

Point of sale (POS) outbound processing or so called POS download is the business process where the central SAP ERP system in head office, which is the key system for maintenance of retail related master data such 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 POS systems in stores have the right information to be able to perform necessary tasks like selling, goods receipting, calculation of promotions and bonus buys and so on. And very often that information needs to fit to advertisements published. POS download business scenario is usually the pre-condition to be able to run POS inbound or so called POS upload processing to record sales performed. This chapter deals with both available business process variants to support information exchange with POS systems. You can recognize this in two different resulting data record types, so called IDocs. So this document uses the POS download term when referring to the business process independent from the process 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 to transmit master data to POS systems with key focus on article, EAN, and price. The relevant IDoc type is WP_PLU which can be accompanied by other data objects (IDocs) for merchandise categories, EAN references, 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 WBBDLD which is able to transmit more complex information related to article like source of supply, stock etc. This is recommended if additional retailing functions (such as the entry of a goods receipt) also have to be carried out in a store retailing system. The assortment list is usually also known with relevance to other business processes like supporting printed list 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 for assortment list is in scope. Common to both business process variants for POS download is the task to send out data changes. These changes are done by business persons in head office and are relevant for a specific store. Therefore, three processing modes are possible: Initialization, change message, and manual request. The initialization usually needs to be done once for the stores concerned, it sends the full set of all articles listed in the store. Then you only have to plan at regular intervals (usually daily) the program for evaluating changes. The manual request usually 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 ERP system in head office with the local point of sale systems using data transfer tools via internet and phone and also middleware for data mapping and data conversion. An option for data mapping tools is SAP PI to be used and also for POS system to use SAP POS or SAP EPOS with both integrated standard content

© 2009 SAP AG

page 22/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

delivered. But this BPM concentrates on monitoring requirements inside SAP ERP and handles data mapping and POS as black box. SAP ERP provides a separate monitoring transaction to monitor the success of the transmission of data changes. This is the POS interface monitor. The POS interface monitor uses information from the status tables of POS download. It can be used to track each transfer and type of preparation. The POS interface monitor transaction indicates for which stores preparation and transfer of data was completed and IDocs have been created. It also indicates which IDocs contain errors, how many errors are in an IDocs, and also error logs 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 are able to be executed after a POS download run periodically to indicate further issues with POS outbound and assortment list. No customizing settings are necessary to execute these reports but the monitoring team needs to carefully study the background of reports provided. Therefore, these reports available in transaction WPER2 are discussed in greater detail within this document. In addition to the business importance of that process, also the required system performance and throughput is 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. Therefore the POS download and its related areas like listing, pricing, and store formatting need a good and lean set up in project mode and a strong monitoring in production mode. Also technical abilities and functions like performance monitoring, data volume management, and data archiving need to have a strong focus in production mode. In the year 2000 the high performance retailing initiative (HPR) which has been an SAP program to deliver bundled performance enhancements in SAP for Retail and ship to customers had been able to achieve a higher data throughput with SAP for Retail for key business processes. Also the business process of POS download 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 Index in Table WIND

Enhanced Change Pointers Table BDCP2

Normal assortment list

Not possible

Enabled

HPR assortment list

Mandatory (see OSS 603472)

Enabled

POS outbound WP_PLU

Enabled

Enabled

Table 4: HPR version improvements

In this document, both, the normal assortment IDOC processing, and the HPR assortment list processing are considered. In fact, in the real monitoring procedure it does not make a difference.

© 2009 SAP AG

page 23/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Tools like WIND and BDCP2 are typically set up during the implementation project. Therefore, the setup of these 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 increase performance using the improvements from high performance retailing. They need to understand the background 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 chapter Further Information) together with online help are that detailed and comprehensive to enable a project team to 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 the creation of WBBDLD IDoc with modified scope/ content through new SAP transactions. For details regarding the modified scope and especially reduced business functionalities to accommodate for performance, see OSS note 720514. Another result of HPR improvements is the use of the condition document index to find and send changed price conditions. The improvement is facilitated by the new table WIND. Using the WIND table change pointers must not be used anymore for price changes. The system only updates a new work list table as soon as conditions are saved. The change message of IDocs refers to that table. For more information see chapter Further Information with OSS notes mentioned. The WIND technology is enabled through IMG configuration as follows: Select Retail Pricing • Pricing Worklist • Direct Entry for Creating Worklist For customers already using POS download business process and having change pointers for condition changes in tables BDCP and BDCPS, who wants to increase performance by introducing WIND, SAP provides migration reports and procedures. Report RWDBBMIG (see OSS note 603472) to migrate change pointers for condition changes from either BDCP/BDCPV or BDCP2 (depends on setting in table TBDA2) into WIND. Please keep in mind the background 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. The evaluation of conditions changes is also described in OSS note 519685. The description includes the use of report 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 for message 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 the necessary steps with migration transaction BDCPMIG and necessary customizing in BD60 for POS outbound and for assortment list.

© 2009 SAP AG

page 24/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

The 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 WIND

2.1

Sample Scenario

Wonderful Food & Clothes Ltd. is a multi channel retailer founded in Switzerland running stores all over USA and Europe. In Germany, Austria, Switzerland they run company owned stores offering also a wide range of services especially for brides. In the USA they have a lot of small corner stores because Americans like good food from Switzerland. In Italy, Spain, Portugal, Eastern Europe and in Scandinavia they are present using franchisee 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) to give 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 of franchisees. 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 with assortment list IDoc. Because of a bigger number of stores and their smaller range of processes, they decided 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 ERP 2. Maintain merchandise categories and assign to store 3. Maintain articles as master data in SAP ERP, especially main EAN 4. List articles to new store 5. Maintain prices for articles in store The above mentioned process steps are processes done by the business as master data maintenance in category management and are not described on the current BPM but they are the trigger and input for POS outbound process. 1. If a store is a new store in SAP ERP, Wonderful Food & Clothes Ltd. runs an initialization or dummy initialization 2. Run change message for stores to send off daily new articles, new listings, new prices with the created IDocs 3. Copy the IDocs for the US stores and transmit all IDocs 4. Monitor the data transfer, correct the data, and again run change message as well as send IDocs off 5. 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 time 6. Delete the processed change pointers 7. Archive the IDocs 8. Receive IDocs, transform with data mappings and send off files from middleware to POS 9. POS system receiving files via phone line and update central store back office server

© 2009 SAP AG

page 25/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

The following chapters takes you step by step through these business processes, explaining where and how you can identify focus points for Business Process Monitoring. For each business process step the most effective ways for Business Process Monitoring in the context of the example are highlighted.

2.2

Business Process POS Outbound with POS Interface IDocs

As stated above the POS outbound IDocs are used to supply simple POS systems in stores with updated data at regular intervals. The SAP ECC system formats the data in question in IDoc format for the POS outbound interface, taking account of the current store assortment and transfers these IDocs to the store systems using ALE (application link enabling) technology. This is usually done in the evenings and covers a specific lead time period (usually a few days to prepare data changes ahead). The system determines which data have changed up to the current date and which data are going to change during the configured lead time. The system formats data specifically for individual stores, which means each store only receives data that 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

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Special messages and intermediate documents (IDocs) for POS systems are defined for the following objects: 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 data distribution, 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 the following correlations for the activation of change pointers: Logical Message Type That Is to Be Sent

Object

Message Type to Be Activated

WPDWGR

Merchandise categories

WPDWGR

WP_PLU

Article master

WP_PLU

WP_EAN

EAN/UPC References

WP_EAN WP_PLU

WPDSET

Set assignments

WPDSET WP_PLU

WDPNAC

Follow-On Items

WPDSET (!) WP_PLU

WP_PER

Personnel Data

WP_PER

WPDTAX

Taxes

No activation required as no change pointer analysis is necessary

WPDCUR

Exchange rates

No activation required as no change pointer analysis is necessary

WPDREB

Promotion discount

No activation required as change pointers are created directly from the application and not using the ALE layer

Table 5: Correlations for activation of change pointers

© 2009 SAP AG

page 27/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Note: Each chapter will be structured in the following way: 2.1.1.1

Description and general information

2.1.1.2

Monitoring requirements

2.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 as described in section 2.1.1.3. 2.2.1

Business process step 1: Initialize or dummy initialize new store

2.2.1.1

Description and general information

The initialization is the prerequisite for transferring change messages. It transmits all listed articles in a store with all related data. In most cases several IDocs are created. Normally, when a new store opens and gets a new store back office server you would expect the store back office server to be empty and therefore needing this data provided by SAP ECC. To run initialization start transaction WPMI and plan the program RWDPOSIN initialization in the background as you can expect a long runtime. Scenario-specific sample Usually you select one store by the other by creating a job variant per store if you would need to initialize more 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 the database of an already existing store back office server was copied to the new store back office server – a dummy initialization can be done, using program RWDPOSDU. The system does not transfer any data to the POS systems, but only creates special entries in the status table WDLS of the POS outbound. These entries allow the system to start creating change messages after the dummy initialization.

© 2009 SAP AG

page 28/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.1.2

Monitoring requirements

Error monitoring It 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 be created. You see the status in POS monitor as Format Status. Background job for RWDPOSIN and RWDPOSDU Check the job log SM37 for cancellations. Check POS monitor WPER for status and error logs. For error monitoring for initialization mainly the POS monitor transaction WPER is used. If initialization failed you need to correct data and repeat the execution at a later point in time if necessary. The dummy initialization is not critical at all because it just sets a flag in a table and it is very likely that no error will occur. Performance monitoring For performance monitoring of an initialization you need to watch the runtime of the job. The only thing you can do in advance is to plan no other system resource consuming jobs at the same time and optionally, apply extraordinary basis parameters. While the job runs for a store, it needs to create and find all articles. It neither can run in parallel nor can it be split by article number ranges. Throughput monitoring In 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 back office server database with IDocs. After that you run dummy initialization to set the status correctly. Backlog monitoring See comments on throughput monitoring. 2.2.1.3

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Report RWDPOSIN (initialization execution)

RWDPOSIN, date of job (usually current date)

Long job runtime, job cancellation , time out, error messages in job log, job canceled or delayed

SM37

Runs usually once when new store opened; when job is running, monitor in periodic intervals system/runtime performance

Report RWDPOSDU (dummy initialization execution)

RWDPOSDU, date of job (usually current date)

Job cancellation; long runtime is not likely as this job just creates one table entry in table WDLS.

SM37

Usually once when new store opened (as an alternative to RWDPOSIN when store database has full data already copied from other store back office server etc.

Processing status of initialization in POS monitor

Date of job finished and outbound application POS

Look for tree branch in outbound processing – not fully processed – preparation mode I = initializations: Double click to read system log text with error message

WPER

After job execution

© 2009 SAP AG

page 29/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.1.4

How to find meaningful thresholds per monitoring object

Every error that occurred is critical as it will lead to wrong information in the registers of the stores. Errors occurred if table WDLS shows in field GESST H. A processing without errors or hints is indicated by X in this field. 2.2.2

Business process step 2: Evaluate master data changes, collect and prepare data, create IDoc

2.2.2.1

Description and general information

This step runs the job for the daily change message which collects the changes becoming valid in future in the lead time or done by business in daily online transactions like article maintenance, listing, price maintenance, customer maintenance. The changes are evaluated and the data which needs to be transferred is prepared and completed and saved in an IDoc. Here too, the distinction depending on configuration takes place if HPR features like WIND or BDCP2 are evaluated. Scenario-specific sample The data are prepared for the stores selected in the job variant. The data, i.e. what kind of IDocs should be prepared, come from configuration of POS outbound profiles which is assigned to the store. So in most cases WP_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 are evaluated. 2.2.2.2

Monitoring requirements

Error monitoring For error monitoring of change messages mainly the POS monitor transaction WPER is used. It is also necessary to monitor the job in SM37. Background job for RWDPOSUP Check the job log for cancellations and runtime. If the job finishes correctly it will not show application errors in 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 monitoring For performance monitoring of a change message you need to watch the runtime of the job. Throughput monitoring To increase throughput, parallelization should be used. In the report RWDPOSUP you can set the flag for parallelization, select relevant stores, enter a server group on which a parallel process shall run, and enter the maximum number of parallel processes.

© 2009 SAP AG

page 30/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Backlog monitoring It is important to watch the runtime of the job regularly. If a job takes too much time, it is not finished. This is critical since IDocs are not created and the prices and other data cannot be sent to the store in time. That increases 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 the operating team aware when they are going to change lots of data at one point in time and POS outbound is likely to work with much more changes than normal. For example, when a new season with new prices starts or new collections are listed, the operator would need to change starting time of RWDPOSUP to accommodate for longer runtime because of a larger amount of data. Scenario-specific sample It 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 that RWDPOSUP is finished at 07:00. 2.2.2.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Background job S_DE_R_RWDPOSUP_D (Report RWDPOSUP) (changes message execution)

S_DE_R_RWDPOS UP_D, RWDPOSUP

Long job runtime, job cancellation , time out, error messages in job log

SM37

Every five minutes during every job execution

2.2.2.4

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Processing status of change message in POS monitor

Date of job finished and outbound application POS

Look for tree branch in outbound processing – not fully processed – preparation mode u = update doubleclick to read system log text with error message

WPER

After job execution

2.2.2.5

How to find meaningful thresholds per monitoring object

You can determine the threshold when POS outbound needs to be finished depending on your business needs. Therefore, you need to work backwards on your timetable under consideration of the time for conversion and for transmission as well as some security time to determine when RWDPOSUP has to be finished at the latest. Then you need to work out with business how many changes they do on average and look how long a job takes on average and work backwards. If business leaves average due to business reason you need again to accommodate threshold and start the job earlier.

© 2009 SAP AG

page 31/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.2.6

Scheduling of background jobs

This job is usually scheduled on a daily basis in the evening after all master data changes have been carried out in the system. Job scheduling requirements Recommended or Generated Job Name

ABAP Report

S_DE_R_RWDP RWDPOSUP 1 OSUP_D

S_DE_R_RSEO UT00_D

RSEOUT00

Variant

Scheduling

To be defined

Runs usually daily; monitor when job is running in periodic intervals system/ runtime performance Daily

Predecessor Job

Successor Job

Scheduling Restriction

S_DE_R_RS EOUT00_D if IDocs are not sent automatically S_DE_R_RW DPOSUP_D

Error Handling in Case of Cancellation Root cause analysis required, potentially a restart might be sufficient Restart job

2.2.3

Business process step 3: Copy IDocs within ECC retail (optional) and send out IDocs from ECC retail

2.2.3.1

Description and general information

From many stores the POS download IDocs (POS outbound IDocs and assortment list IDocs) are identical or only differ very slightly. This means to optimize performance and decrease runtime it is not necessary to generate IDocs for all stores but just for certain reference stores. Then these IDocs created for the reference stores with RWDPOSUP can be distributed according to certain rules. It can significantly improve performance. The following chapter describes how this copying mechanism is set up. Please note that this solution 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 for the initial supply of a new store, if the stores can be grouped and a reference store can be determined. Then for 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 programming interface port must be assigned to the reference recipient. Define an ABAP programming interface port in the port description (IDoc and EDI basis) and assign it to the function module WDL_COPY_LOG. File ports must be assigned to the recipients of the copies. All recipients that are assigned to a reference must be assigned to one and the same file port. The partner profiles for the recipients must be maintained in such a way that IDocs are collected first. The IDoc copy management tool sends the IDocs automatically. Various applications generate outbound IDocs for the reference recipients. Using the programming interface port, which is assigned to each reference customer within the partner profile, the SAP system logs these reference 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 Management to be found under https://service.sap.com/solutionmanagerbp. The nam e indicates: S for SAP standard coding, DE for the involved organizational 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

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Program RWDLCOPY_MANAGE copies the reference IDocs to the recipients (customers) that are assigned to it using the copy rule. It then generates trigger files for the individual recipients for each message type if this is set in the copy rule. The tool optimizes its performance internally using asynchronous processes. Multiple scheduling is therefore not recommended. Another program is RSEOUT00, which sends out the collected IDocs in ECC database as files to the following conversion tool. RSEOUT00 is required if in the partner agreement configuration in WE20 the IDocs are set to collect IDocs. SAP strongly recommends this for performance and monitoring reasons and as stated above mandatory for the IDoc copy management tool. 2.2.3.2

Monitoring requirements

Error monitoring You need to monitor the job for report RWDLCOPY_MANAGE and check the log for potential errors. You also 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 tools

Performance monitoring You need to monitor the runtime of jobs for both reports but usually they are not performance critical. The most performance critical job is RWDPOSUP which is described earlier in this document.

© 2009 SAP AG

page 33/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Throughput monitoring Here you only have to make sure that RWDLCOPY_MANAGE and RSEOUT00 are planned in time – before data are required in store for selling and under consideration of the required time for data conversion and transmission outside ECC. Backlog monitoring Make 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 Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Background job S_DE_R_RWDLCOPY_ MANAGE_D (report RWDLCOPY_MANAGE )

S_DE_R_RWDLCOPY_M ANAGE_D, RWDLCOPY_MANAGE,

Long job runtime, job cancellation, time out, error messages in job log

SM37

Every five minutes during every job execution

Background job S_DE_R_RSEOUT00_ D

S_DE_R_RSEOUT00_D, RSEOUT00,

Long job runtime, job cancellation, time out, error messages in job log

SM37

Every five minutes during every job execution

Direction, port, partner number, partner type, partner function, message type, basic type, message code, message function, IDoc age

Number of IDocs of type WPDWGR, WP_PLU, WP_EAN, WPDSET, WPDNAC, WPDCUR, WPD_TAX, WP_PER, WPDREB in an error-status

WE05 or WE02

Every 15 minutes

(Report RSEOUT00) (IDoc transmission off ECC ) IDoc processing status in case of IDoc interface

2.2.3.4

How to find meaningful thresholds per monitoring object

You can determine the threshold when the POS assortment list needs to be finished depending on your business 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 when RWDLCOPY_MANAGE and RSEOUT00 must be finished at the latest.

© 2009 SAP AG

page 34/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.3.5

Scheduling of background jobs

If copy management is used, the jobs are scheduled after the POS download on a daily basis. Job scheduling requirements Recommended or Generated Job Name

ABAP Report

S_DE_R_RWDLC OPY_MANAGE_D

Variant

Scheduling Predecessor Job

Successor Job

Scheduling Restriction

RWDLCOPY_M ANAGE

Daily

S_DE_R_RW DPOSUP_D

S_DE_R_RS EOUT00_D

S_DE_R_RSEOU T00_D

RSEOUT00

Daily

S_DE_R_RW DLCOPY_MA NAGE_D

2.2.4

Business process step 4: Monitor, correct, and repeat POS outbound

2.2.4.1

Description

Error Handling in Case of Cancellation

General information The business process for POS download has a separate transaction for the operator role, the POS monitor. The POS monitor transaction should be viewed daily after processing the report RWDPOSUP change message and report RWDPOSIN initialization and a manual request report RWDPOSAN. The POS monitor is not only used to view errors, it is also a good tool to check for successful transmissions. Moreover, it is used to find the corresponding IDocs after a report or request for POS outbound was performed. This can be valuable for tracking a request and the corresponding IDoc number through the process steps outside SAP ECC,as it helps you to find out when and with which content the IDoc was created. Scenario-specific sample You can verify the following information using the POS monitor: The recipient of the IDoc The system type the IDocs belongs to (POS outbound or assortment list) When IDocs are created for the recipient The type of preparation (for example initialization, change message) Whether preparation and transfer of data was completed How many IDocs were created for each recipient Whether the IDocs were created completely for each recipient To which IDoc type the IDoc in question belongs (for example, article master, EAN/UPC references) The key (IDoc number) under which the IDocs can be found in the database How many segments the IDoc contains Which IDocs contain errors, and how many errors occurred (you can display an error log for incorrect IDocs) Which data areas are contained in the IDoc (smallest and largest object key) Which data an IDoc contains

© 2009 SAP AG

page 35/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Screenshot of POS monitor (POS outbound):

Figure 13: Screenshot of POS monitor (POS outbound)

2.2.4.2

Monitoring requirements

Error monitoring using POS monitor transaction WPER Mainly the operator has to deal with the not successful transmissions. The operator has to view error messages to delegate the actions to either IT or business to get business errors and data corrected. Then the operator is able to repeat transmission. If there was a problem – classified as error in format status with data preparation (in step 2 with RWDPOSUP or already in step 1 with RWDPOSIN) – mostly, no IDoc will be created. These requests are visible in the sub-tree for not fully processed requests. The error text can be read from system log by a double click. Another possibility is to use the transaction SLG1. The error message can just be a warning. An IDoc was created and the operator has to decide if the business needs to be involved for a change.

© 2009 SAP AG

page 36/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Figure 14: Display logs

Once all errors, which had been displayed for POS download messages in POS monitor, have been corrected, choose Repeat preparation in the POS outbound log. As a result, all data that were not transferred because of errors will be re-processed and transferred. In terms of performance this procedure is a better way than preparing all the data again. If a large number of errors occurred, a runtime error may cancel the preparation. In this case, you should repeat the entire POS outbound processing RWDPOSUP. You can do this by executing the relevant batch report RWDPOSUP immediately during day time. Or you can wait for the next change message, which will include the data that was not transferred. It is possible to wait for the next day if there is enough lead time: The lead time sends down data becoming valid in future. If the lead time is five, a price is sent down four days in advance, including the current day. If you wait for the next change message (running one day later than the current change message), it is only three days in advance at the store back office server but still early enough. Scenario-specific sample Transmission of data, which were not successfully transmitted, will be repeated on the next day. Therefore it is very important to solve the occurring issues and to save the entire record successfully into the status tables (WDLS tables). This highlights the necessity of correcting the errors every day: If an error is not corrected and the error status remains for a long time all the data from the previous days will be analyzed and transmitted. This has an enormous impact on performance of RWDPOSUP.

© 2009 SAP AG

page 37/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

It has also an impact on outstanding steps of business process step 5 and 6 as the change pointers and status records are not reorganized and deleted. Error monitoring using POS object analysis in transaction WPER2 In addition to the daily monitoring on POS monitor, there is a central group report that you can run to analyze data constellations for generating POS outbound IDocs and assortment list IDocs. This group report is accessible through transaction WPER2 and consists of several individual reports. The individual reports can be seen in this screenshot:

Figure 15: Individual reports

Please note that dummy initialization has been discussed already in step 1 and will not be discussed in this chapter. WPER2: Object analysis in the POS outbound This report checks the IDoc types to be exported via POS outbound processing and determines whether the program will encounter any errors. This means this program enables you to check whether objects, which need to be prepared and sent by the POS outbound within certain IDoc types, are correctly and completely maintained from master data management. This report can be used for specific sites and/or articles. Scenario-specific sample If an article for a store is not sent in the POS outbound IDoc, the article and store numbers can be entered and the report started. If the article has not been correctly maintained, at least one indicator appears in the output list. The highlighted column provides information as to why the object (material) was not prepared.

© 2009 SAP AG

page 38/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

For example, the article chosen in the screenshot has no EAN, so EAN is marked as missing since this is mandatory for creation of WP_PLU IDoc. The article is also not listed in the store selected and has no price for the store selected. That is why WLK1 table for listing and price is marked.

Figure 16: Object analysis POS outbound

WPER2: Reorganization check in the POS outbound For various reasons, the reorganization program of POS outbound can fail while running the retail-specific report RWDPOSRS (see coming step 5 below). This leads among other things to a dramatic increase in the volume of data and therefore a reduction of performance. This report enables a reason analysis and, if necessary, the elimination of the reason.

Figure 17: POS outbound reorganization check

WPER2: IDoc analysis in the POS outbound It often happens that you need to find a specific object among thousands of IDocs and in the segments of the IDoc. This report provides a quick and easy way to search for such an object. The alternative transaction WE09 would be less easy to handle in this case.

© 2009 SAP AG

page 39/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Scenario-specific sample If you need to search for a special article and its price in an IDoc segment because the store back office server does not show the correct price, which is maintained in master data management in SAP ECC, you can use this report. It helps you to find out in which IDoc and at which point in time an article left the SAP ECC system. This information is required to search in the other subsystems for issues related to data mapping, conversion, and connectivity. For POS outbound and for assortment lists this is hard to find since IDocs are generated daily for each store. So the required article has to be found inside of many IDocs. The report enables a quick and simple object search with regard to the POS outbound basis IDoc, using various selection criteria and combinations from a set selection of any size.

Figure 18: IDoc analysis POS outbound selection screen

Figure 19: IDoc analysis POS outbound result

© 2009 SAP AG

page 40/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

WPER2: Reprocess in the POS outbound When troubleshooting, you have to reproduce errors. This enables you to determine how to fix them. The Report RWDREPROCESS2 enables this. This report allows you to do a test rerun using the same change pointers that were handled in the previous download. There is usually some time delay (perhaps a few days) between the POS run and the analysis, during which time the system may detect new change pointers. This may cause the reprocessing report to include more articles than the original download. This new data is in addition to all the previous data. None of the previous data will be omitted. This report does not work if the change pointers were already deleted after the previous run. By changing the status, you can resend data or prevent redundant data from being sent. The following status changes are possible: Changing the status from X or H to status W means that all objects from the last download, which were triggered by change pointers, will be resent in the next download. Changing the status from W or E to status H means that only those objects that have been changed since the previous download will be sent. You can reverse unwanted status changes without any consequences under condition that a download in the form of a change analysis has not taken place in the meantime. Performance monitoring During actions described in this chapter, no performance monitoring is necessary since these are online monitoring transactions themselves. Using these reports regularly, especially the reorganization check, is essential since this has a positive impact on performance of RWDPOSUP. Scenario-specific sample The background is that the processing of the change pointers keeps change pointers valid until the change had been transmitted to all stores. If for any reason a store did not have a change run for a longer time (POS outbound profile assigned and initialization done so that valid WDLS entry exists with I for initialization but then no update RWDPOSUP done for long or failed) this change pointer does not get set processed in step 5. So the change pointer will not be deleted. In that case, the change pointer table keeps growing due to the fact that this one store has not been processed. If a store has an error message for a topic which is not solved, two things will happen: For this store, the changes starting from that point in time in the past when the error happened are processed every day until the error is resolved. The change pointers related to that erroneous business change cannot be deleted and thus influence – because of a higher number of change pointers – the processing for the other stores as well. Throughput monitoring Please see comments on performance monitoring. Backlog monitoring using reorganization check option in transaction WPER2 Please see comments on performance monitoring.

© 2009 SAP AG

page 41/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.4.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Background job S_DE_R_RWDLCOPY _MANAGE_D (report RWDLCOPY_MANAG E)

Background job S_DE_R_RWDPOSAN (report RWDPOSAN)

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

S_DE_R_RWDLCOPY_MA Long job runtime, job NAGE_D, cancellation , time out, error RWDLCOPY_MANAGE messages in job log

SM37

Every five minutes during every job execution

S_DE_R_RWDPOSAN, RWDPOSAN

WPMA

If corrected data are urgently needed at POS back office server in store.

Long job runtime, job cancellation , time out, error messages in job log

SM37

Every five minutes during every job execution Background job S_DE_R_RWDPOSUP (Report RWDPOSUP)

S_DE_R_RWDPOSUP, RWDPOSUP

Long job runtime, job cancellation , time out, error messages in job log

WPMU SM37

If several data had been corrected and are also needed in store quickly and can not wait until processing next day or if lead time is too short. Every five minutes during every job execution

Background job S_DE_R_ RWDREORGCHECK _M (Report RWDREORGCHECK)

S_DE_R_ RWDREORGCHECK _M, RWDREORGCHECK

If report shows an object with WPER2, action to perform need to SM37 make decision how to act

Every five minutes during every job execution

Background job S_DE_R_ S_DE_R_ RWDREPROCESS2_M, RWDREPROCESS2_M WDREPROCESS2 (Report RWDREPROCESS2)

If report shows an object with WPER2, action to perform need to SM37 make decision how to act

Every five minutes during every job execution

IDoc processing status in case of IDoc interface

Number of IDocs of type WPDWGR, WP_PLU, WP_EAN, WPDSET, WPDNAC, WPDCUR, WPD_TAX, WP_PER, WPDREB in an error-status

© 2009 SAP AG

Direction, port, partner number, partner type, partner function, message type, basic type, message code, message function, idoc age

WE05 or W E02

Every 15 minutes

page 42/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.4.4

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

WPER POS monitor

Date of job (usually current date); application POS and look for store in question

Appear in tree branch for Not fully processes

WPER

Daily after RWDPOSUP and RWDPOSIN and WPMA transaction

Report RWDDOWNLOAD

Object to be checked

If the report shows an object with an action to be performed, a decision needs to be taken on how to react

WPER2

As required

Object to be checked

If the report shows an object with an action to be performed, a decision needs to be taken on how to react

WPER2

As required

Object analysis

Report RWDIDOCPOS IDoc analysis

2.2.4.5

How to find meaningful thresholds per monitoring object

An error mostly indicates that the master data has not been maintained correctly by the business users. 2.2.4.6

Error handling per monitoring object

Use transaction WPER and WPER2 like described above. Usually errors are shown when the system has not been able to create IDocs. The error message in POS outbound often says Intermediate Document missing which means no IDoc has been created. The POS outbound does only transmit an article and create an IDoc when the article is listed, has a main EAN, and a sales price. This is one reason why SAP has developed the report for the object analysis in transaction WPER2. It is to supply more details why the intermediate document has not been created. 2.2.4.7

Scheduling of background jobs

If manual corrections have been finished, a job chain containing the change analysis and IDoc creation program, the copy management, and the IDoc distribution program can be started. These jobs are usually not scheduled daily at a certain time, but scheduled by request after manual interventions have been necessary. When corrections have been carried out, the involved article(s) might either be sent out again explicitly using program RWDPOSAN or by re-executing the change run with program RWDPOSUP.

© 2009 SAP AG

page 43/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Job scheduling requirements

Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

S_DE_R_RW DPOSAN_R

RWDPOSA N

Manual by article On request restriction

S_DE_R_RW DPOSUP_R

RWDPOSU P

On request

S_DE_R_RWD LCOPY_MANA GE_D or S_DE_R_RSE OUT00_R

S_DE_R_RW DLCOPY_MA NAGE_D

RWDLCOP Y_MANAGE

On request S_DE_R_RWDP OSUP_R or S_DE_R_RWDP OSAN_R

S_DE_R_RSE OUT00_R

S_DE_R_RSE OUT00_R

RSEOUT00

On request S_DE_R_RWDL COPY_MANAG E_D or S_DE_R_RWDP OSUP_R

S_DE_R_ RWDREOR RWDREORGC GCHECK HECK _M

1 or 2 times a month

S_DE_R_ RWDREPROC ESS2_M

1 or 2 times a month

RWDREPR OCESS2

Predecessor Job

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

S_DE_R_RWD After manual LCOPY_MANA variant GE_D or adjustment S_DE_R_RSE OUT00_R

2.2.5

Business process step 5: Reorganize change pointers, status records, and WIND entries

2.2.5.1

Description and general information

As stated already above, changes are recorded using change pointers in table BDCP or BDCP2. These change pointers indicate that change had been performed and master data need to be transmitted to stores in question. When all stores have received the information the change pointers are no longer required and can be deleted. As mentioned before, change pointer can be valid for several objects (IDoc types) and also for several stores. The report RWDPOSRS checks for a change pointer if it is still needed for above reasons or not. If the report comes to the conclusion that the change pointer is not needed anymore, then the flag for the change pointer is set to the status processed. At the same time, the report reorganizes the status records in table WDLS*. It only keeps the latest successful transmission record in order to give the next run of the report RWDPOSUP information from where to start. It also reorganizes the WIND table entries, if condition changes are recorded using the WIND improvement from the HPR initiative.

© 2009 SAP AG

page 44/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.5.2

Monitoring requirements

Error monitoring Please read the error log of the background job for report RWDPOSRS. Performance monitoring Read the log of the background job for RWDPOSRS. It should say that at least some numbers of change pointers are set to processed and some status records are deleted. If no change pointers have been set to the status processed, then please use immediately the transaction WPER2 for reorganization check in order to find out whether one store is blocking change pointers to be set to processed. Scenario-specific sample See comments on WPER2 report for reorganization check. Throughput monitoring Ideally, all change pointers are set to processed if for all stores the changed data had been transmitted successfully and if no errors are shown in POS monitor (transaction WPER). If all change pointers are set to to be processed, they will be deleted in next step 6 Backlog monitoring It is not immediately observable if all change pointers are set in time to the status processed. In order to ensure smooth performance, it makes sense to use report WPER2 for reorganization check from time to time. This allows seeing possible reasons why change pointers were not set to status processed and thus were not deleted. The report also allows seeing the stores which were affected. In addition, the reprocess report can also be used to identify stores with problems in the past. It also allows setting an old erroneous WDLS record explicitly to the status successful in order to avoid that this erroneous WDLS record is blocking the reorganization of further change pointers. In the backlog monitoring, it is also possible to check with transaction SE16 directly in the table BDCP/BDCPS or BDCP2 how many change pointers without processed flag exist in total. It can be analyzed backwards at which date those change pointers had been created and it can be checked if a data object like an article is not maintained correctly. 2.2.5.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Report RWDPOSRS (Reorganize POS Interface)

Job Date (usually current date)

Long Job Runtime, Job Cancellation , Time Out, Error messages in Job Log

SM37

Every five minutes during every job execution

2.2.5.4

How to find meaningful thresholds per monitoring object

Ideally, all change pointers from previous days should be set to reprocessed.

© 2009 SAP AG

page 45/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.5.5

Error handling per monitoring object

Background job for report RWDPOSRS Check the job log for cancellations and errors. The job log says if change pointers and how many of them have been reorganized. In case no change pointers would have been reorganized it makes sense to turn to transaction WPER2 and check the reports Reprocess and Reorganization Check. 2.2.5.6

Scheduling of background jobs

The job sets the processing status of change pointers, that have been successfully used, to processed. This job should be carried out after all IDocs have been created. Job scheduling requirements

Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

Predecessor Job

Successor Job

Scheduling Restriction

S_DE_R_ RWDPOSRS_D

RWDPOSRS

2.2.6

Business process step 6: Delete change pointers and status records

2.2.6.1

Description and general information

Error Handling in Case of Cancellation

Daily

When change pointers are set to status processed in step 5, they will be finally deleted with report RBDCPCLR. The report deletes change pointers from the change pointer table. If change pointers are deleted regularly the change pointer table becomes smaller. In order to guarantee a high throughput for the POS outbound process, the change pointer table has to be kept as small as possible. An increase in its size should therefore be discovered at an early stage. Scenario-specific sample The report has two options to delete change pointers: Either with the status processed or obsolete change pointers. For deletion it is recommended to choose option processed because they are surely not in use anymore since the system has set the status in the previous step. Normally, if all process steps are carefully executed, i.e. the change message job runs regularly for all stores every day without errors, everything is fine. In case of errors, it is important that the errors are corrected for all stores and the change message run is repeated. If this is the case, the process of reorganization and deletion of change pointers works automatically to keep change pointer table slim. Nevertheless, a job should be scheduled regularly with the task to delete obsolete change pointers older then X days. According to the customer’s specific business it needs to be decided how many days are appropriate for X days, in order to ensure that no changes are deleted which might still be needed.

© 2009 SAP AG

page 46/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.6.2

Monitoring requirements

Error monitoring View job log for report RBDCPCLR in SM37. Performance monitoring The deletion of change pointers improves the performance of RWDPOSUP. If you regularly delete change pointers with RBDCPCLR, you will also encounter no problems with RWDPOSUP. Therefore, SAP strongly recommends performing step 6 at least once a week. Throughput monitoring See comments on performance monitoring. Backlog monitoring See comments on performance monitoring. 2.2.6.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Background Job S_DE_R_ RBDCPCLR _W,

S_DE_R_ RBDCPCLR _W, RBDCPCLR , Job Date

Long job runtime, job cancellation , time out, error messages in job log, delayed

SM37

Every five minutes during every job execution

(Report RBDCPCLR)

2.2.6.4

How to find meaningful thresholds per monitoring object

See comments on performance monitoring. 2.2.6.5

Error handling per monitoring object

Background job for RBDCPCLR Check the job log for cancellations. The job log says if change pointers and how many of them have been deleted. In case no deletion it makes sense to start the report to reorganize change pointers. If reorganization is done and still no change pointers were deleted, it makes sense to turn to transaction WPER2 and check the reports Reprocess and Reorganization Check. 2.2.6.6

Scheduling of background jobs

After having set the status of the change pointers to processed, the processed change pointers can be deleted. The corresponding program RBDCPCLR should therefore be scheduled after the job RWDPOSRS explained earlier in business process step 5 (2.2.5). Depending on the data volume the job might be scheduled daily or weekly.

© 2009 SAP AG

page 47/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Job scheduling requirements

Recommended or Generated Job Name

ABAP Report

S_DE_R_ RBDCPCLR _W

RBDCPCL R

Variant

Scheduling

Predecessor Job

Daily or weekly

S_DE_R_ RWDPOSR S_D

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

2.2.7

Business process step 7–9: Middleware (enterprise application integration tool): Receive, transform, and send information

2.2.7.1

Description

General information In most cases, the collected POS download data, as they are contained in the IDocs, are not yet ready for direct processing in the POS store system. It has to be mapped (equal to pure conversion of data formats) or transformed (for example business-oriented conversion of specific EANs, which is necessary to enable the POS system to data in the POS database). As initially stated, the monitoring of this process step depends on the tool used and is therefore not detailed in this document. 2.2.7.2

Monitoring requirements

Error monitoring No general statement possible since it depends on the chosen platform. SAP PI offers tools for monitoring success of transformation. Performance monitoring No general statement possible since it depends on the chosen platform. SAP PI offers tools for monitoring success of transformation. Throughput monitoring No general statement possible since it depends on the chosen platform. SAP PI offers tools for monitoring success of transformation. Backlog monitoring No general statement possible since it depends on the chosen platform. SAP PI offers tools for monitoring success of transformation. 2.2.7.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

N/A

N/A

N/A

N/A

N/A

© 2009 SAP AG

page 48/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.7.4

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

N/A

N/A

N/A

N/A

N/A

2.2.7.5

How to find meaningful thresholds per monitoring object

Usually, each transformation should be error free as urgently required on EPOS system. So the target is zero errors. But if the look-up tables are not completely maintained errors can occur. 2.2.7.6

Error handling per monitoring object

No general statement possible since it depends on the chosen platform. SAP PI offers tools for monitoring success of transformation. 2.2.8

Business process step 10–11: POS system: Receive information and update database

2.2.8.1

Description and general information

After data mapping and conversion is finished (which is probably done in a kind of central head office system), the files has to be transmitted physically to each store. These files update the local POS back office server database. Now the POS cash registers can use the new data. 2.2.8.2

Monitoring requirements

Error monitoring No general statement possible since it depends on chosen store POS system used. Performance monitoring No general statement possible since it depends on chosen store POS system used. Throughput monitoring No general statement possible since it depends on chosen store POS system used. Backlog monitoring No general statement possible since it depends on chosen store POS system used. 2.2.8.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

N/A

N/A

N/A

N/A

N/A

© 2009 SAP AG

page 49/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.2.8.4

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

N/A

N/A

N/A

N/A

N/A

2.2.8.5

How to find meaningful thresholds per monitoring object

Usually, each transformation should be error free as data are urgently required on EPOS system. So the target is zero errors. But if the look-up tables are not completely maintained, errors can occur. 2.2.8.6

Error handling per monitoring object

No general statement possible since it depends on chosen store POS system used.

2.3

Business Process POS Outbound with Assortment List

Information about listed articles in a store together with additional information like prices, stocks, shelf-edge labels etc. often has to be made available in a variety of media (printout, PC file, or EDI message) for all articles in an assortment and for articles for which changes have been made, or for an even more specific subset of data. In SAP for Retail, the assortment list fulfills this function. Please see the following process steps diagram which is very similar to POS outbound:

Figure 20: Process flow point of sale outbound variant 2 with assortment list IDoc

© 2009 SAP AG

page 50/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Conventionally, an assortment list is produced as a printout. SAP for Retail also supports assortment list output in the form of an electronic message for distributed retailing purposes (when a store-based merchandise management system is in place). If you want to use the assortment list, you can choose between the classic version and the high performance retailing version (HPR). Depending on the version, the SAP ERP system uses different IDoc categories: The older (classic) IDoc type WBBDLD03 permits only one price per data record. So if, for example, you have a September price for school notebooks and you change this price in October, the system generates two article data record segments for the same article, each with a different price sub segment. The newer (HPR) IDoc type WBBDLD04 can handle multiple prices. In the example above, the system only uses this IDoc type to generate one article segment for school notebooks that contains both price segments. This reduces the total number of IDoc segments that need to be transmitted and therefore the amount of time needed to run the assortment list. IDoc type WBBDLD05 is the same as IDoc type WBBDLD04, but also contains a segment for the article hierarchy assignment. IDoc type WBBDLD06 is the same as IDoc type WBBDLD03, but also contains a segment for the article hierarchy assignment. Like already stated in the introduction, the high performance retailing assortment list (HPR assortment list) processes most – but not all – master data that are processed by the normal assortment list. An advantage of the HPR assortment list therefore is that it allows a higher processing speed. The reduced data are sufficient for most retailers. If you require this missing data (specifically: classification data, old labeling data, and layout modules for space management), you must implement a user exit to include this additional data. Please refer once more to OSS note 720514, explanations on HPR assortment list and gap list as well as OSS note 808776, GAP list of HPR assortment list to finally decide about using the HPR assortment list. To allow both ways, the assortment list in SAP for Retail is a standard solution that can be configured with a high degree of flexibility. Different assortment list types can be defined (e.g., food and non-food) Assortment list profiles can be assigned to sites Different creation and transmission cycles can be defined The assortment list can generate an output using a number of different media (printout, EDI, file transfer) An assortment list can therefore easily be tailored to fit your individual company requirements. The assortment list type divides articles contained in the same message creation cycle into groups. A message creation cycle is, for example, the interval in which a message is created. An article is assigned to one assortment list type at client level. The exact date on which an assortment list is created, is calculated from the last creation date for the site plus the cycle time defined for the relevant assortment list type. When using the assortment list IDoc to provide data to POS systems, please note that the cycle time is usually not considered. This is because SAP recommends to run the report for creation of the assortment list change version with the flag do not consider cycle time activated. The recipient (site) of the message is assigned to an assortment list profile that controls the assortment list mode (this determines how the message is used for version management or for data interchange).

© 2009 SAP AG

page 51/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.1

Business process step 1: Run full version to initialize or dummy initialize new store

2.3.1.1

Description and general information

The initialization is the prerequisite for transferring change messages. It transmits all listed articles in a store with all related data. In most cases, several IDocs are created. Normally, when a new store opens and gets a new store back office server, you would expect the store back office server to be empty and therefore needing this data provided by SAP ECC. There are different transactions and reports available for the full version depending on the fact if you use the classic or the HPR assortment list. Classic assortment list To run initialization, start transaction WDBI and plan the program RWDBBINI initialization in the background as you can expect a long runtime. HPR assortment list To run initialization, start transaction WDBI_HPR and plan the program RWDBBINI_HPR initialization in the background as you can expect a long runtime. For both types of assortment lists, use the program RWDSLDUM for the dummy initialization. Scenario-specific sample If you have to initialize more than one store at once, you usually select one store by the other by creating a job variant per store. If the POS system contains all the necessary data in the first start-up of the POS download (maybe the database of an already existing store back office server was copied to new store back office server), a dummy initialization can be executed by using the program RWDSLDUM. The system does not transfer any data to the POS systems, but only creates special entries in the status table WDLS. These entries allow the system to start creating change messages after the dummy initialization. 2.3.1.2

Monitoring requirements

Error monitoring It is very important to know that the program must finish with the status X (error free) or H (notes). This means the preparation is OK (field WDLS-GESST is X or H). Otherwise, no change messages will be created. You see the status in the POS monitor as Format Status. For error monitoring of an initialization, the POS monitor transaction WPER is used mainly. If initialization failed, you have to correct the data and repeat the execution at a later point in time if necessary. Performance monitoring For performance monitoring of an initialization you have to watch the runtime of the job. The only thing to do in advance is to make sure that no other resource consuming jobs are running at the same time. You may also want to assign extraordinary basis parameters. The job itself runs for all articles of a store. It cannot be split by article number ranges and parallelized.

© 2009 SAP AG

page 52/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Throughput monitoring The throughput can be critical in times of a high number of changes. If you try to meet the maximum allowed time window because of a high volume of articles, you can only run manual requests with article number ranges to fill store back office server database with IDocs. After that you run dummy initialization to set the status correctly. Backlog monitoring See comments on throughput monitoring. 2.3.1.3

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Report RWDBBINI or RWDBBINI_HPR (initialization execution)

Date of job (usually current date)

Long job runtime, job cancellation, time out, error messages in job log, delayed

SM37

Runs usually once when new store opened; monitor when job is running in periodic intervals system/runtime performance During runtime

Report RWDSLDUM (dummy initialization execution)

Date of job (usually current date)

Job cancellation; long runtime is not likely as this job just creates one table entry in table WDLS

SM37

Usually once when new store opened (as alternative to RWDPOSIN when store database has full data already copied from other store back office server etc.

Processing status of initialization in POS monitor

Date of job finished and outbound application SL

Look for tree branch in outbound processing – not fully processed – preparation mode I = initializations: Double click to read system log text with error message

WPER

After job execution

2.3.1.4

How to find meaningful thresholds per monitoring object

All items should be error free (field WDLS-GESST is X or H). 2.3.1.5

Error handling per monitoring object

Background job for RWDBBINI and RWDBBINI_HPR Check the job log SM37 for cancellations. Check the POS monitor WPER for status and error logs.

© 2009 SAP AG

page 53/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.2

Business process step 2: Run change version to evaluate master data changes, collect and prepare data, create IDoc

2.3.2.1

Description and general information

This step runs the job for the daily change version which collects the changes done by business in daily online transactions like article maintenance, listing, price maintenance, customer maintenance. It selects the changes done recently and the changes becoming valid in the customized relevant period. The changes are evaluated and the data, which need to be transferred, are prepared, completed, and saved in an IDoc. Here too, the distinction depending on configuration takes place if HPR features like WIND or BDCP2 are evaluated. The following transactions and reports are used: Classic assortment list: WDBU Report RWDBBUPD HPR assortment list: WDBU_HPR Report RWDBBUPD: HPR Scenario-specific sample The data are prepared for the stores selected in the job variant. For the process of the assortment list supporting the data transmission to a POS system, a daily data update to POS is usually the best business practice. Therefore, both reports for the change version have the option to ignore the cycle time of the assortment list. The cycle time is usually only important for the printed assortment list and if full versions and change version follow each other or get together in a mixed version. This is not required for the work with the assortment list sent to the POS system, because the POS system needs the changes daily or even immediately. 2.3.2.2

Monitoring requirements

Error monitoring For error monitoring of a change message, the POS monitor transaction WPER is used mainly. It is also necessary to monitor the job in SM37. Performance monitoring For performance monitoring of a change message, you have to watch the runtime of the job. Throughput monitoring To increase throughput, parallel processing should be used. The reports for creating change versions allow you to select several stores and to set the flag for parallelization and enter a server group where parallel process can run on and also the maximum number of parallel processes. Backlog monitoring It is important to watch the runtime of the job regularly. If a job takes too long, it must be considered that, as long as it is not finished, the IDocs are not created and the prices and other data cannot be sent to the store in time. That would increase the risk that stores are selling articles which are incorrectly priced. The operator has to be in touch with the business process champion so the business can inform the operating team about large data changes at one time. Otherwise, POS outbound is likely to work with much

© 2009 SAP AG

page 54/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

more changes than necessary. For example, when a new season with new prices starts or new collections are listed, the operator has to change the starting time of the report RWDBBUPD or RWDBBUPD_HPR to accommodate for longer runtime caused by a larger amount of data. Scenario-specific sample It is import that RWDPOSUP finishes in time before stores are opening and require correct prices. So if stores open at 8.00 o’clock and transmission and conversion need around one hour it must be ensured that the report RWDBBUPD or RWDBBUPD_HPR is finished not later than 7.00 o’clock. 2.3.2.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Report RWDBBUPD or RWDBBUPD_HPR (changes message execution)

Date of job (usually current date)

Long job runtime, job cancellation , time out, error messages in job log

SM37

Runs usually daily; monitor when job is running in periodic intervals system/ runtime performance

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

2.3.2.4

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Processing status of change message in POS monitor

Date of job finished and outbound application SL

WPER Look for tree branch in outbound processing – not fully processed – preparation mode U = update double click to read system log text with error message

2.3.2.5

After job execution

How to find meaningful thresholds per monitoring object

You can determine the threshold when POS outbound needs to be finished depending on your business needs. Therefore, you need to work backwards on your timetable under consideration of the time for conversion and for transmission as well as some security time to determine when RWDPOSUP has to be finished latest. Then you need to work out with business how many changes they do on average and look how long job takes on average and work backwards. If business leaves average due to business reason, you have to accommodate threshold once more and start the job earlier. 2.3.2.6

Error handling per monitoring object

Background job for RWDBBUPD or RWDBBUPD_HPR Check the job log for cancellations and runtime. 2.3.2.7

Scheduling of background jobs

This job is usually scheduled on a daily basis in the evening after all master data changes have been carried out in the system. Depending on the version used, either the program RWDBBUPD or the program RWDBBUPD_HPR is used. © 2009 SAP AG

page 55/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Job scheduling requirements

Recommended or Generated Job Name

ABAP Report

S_DE_R_ RWDBBUPD_D

RWDBBUPD or RWDBBUPD _HPR

Variant

Scheduling

Predecessor Job

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

Daily

2.3.3

Business process step 3: Copy IDocs within ECC retail (optional) and send out IDocs from ECC retail

2.3.3.1

Description and general information

The POS download IDocs (POS outbound IDocs and assortment list IDocs) from many stores are identical or only differ very slightly. To optimize performance and decrease runtime it is not necessary to generate IDocs for all stores but just for certain reference stores. Then, those IDocs created for the reference stores with RWDPOSUP in step before, can be copied according to certain rules. This can significantly improve performance. The following chapter describes how this works. Note, that this is optional. IDoc copy management is not possible for all customers (for example, if store individual prices exist). In addition, for the initial supply of a new store you can use IDoc copy management as a one-off for the initialization (as described in step 1) if the stores can be grouped and a reference store can be determined. Then for 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 programming interface port must be assigned to the reference recipient. Define an ABAP programming interface port in the port description (IDoc and EDI basis) and assign it to the function module WDL_COPY_LOG. File ports must be assigned to the recipients of the copies. All recipients that are assigned to a reference must be assigned to one and the same file port. The partner profiles for the recipients must be maintained in such a way that IDocs are collected first. The IDoc copy management tool sends the IDocs automatically. Various applications generate outbound IDocs for the reference recipients. Using the programming interface port, which is assigned to each reference customer within the partner profile, the SAP system logs these reference IDocs in table WDLCOPY. The IDoc copy management tool uses this log. The program RWDLCOPY_MANAGE copies the reference IDocs to the recipients (customers) that are assigned to it using the copy rule. It then generates trigger files for the individual recipients for each message type if this is set in the copy rule. The tool optimizes its performance internally using asynchronous processes. Multiple scheduling is therefore not recommended.

© 2009 SAP AG

page 56/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

A second program, which is mandatory, is the program RSEOUT00 which sends out the collected IDocs in the SAP ECC database as files to the following conversion tool. RSEOUT00 is only necessary if in the partner agreement configuration in WE20 the IDocs are set to collect IDocs. SAP strongly recommends this because of performance and monitoring reasons and as stated above, it is mandatory for the IDoc copy management tool. 2.3.3.2

Monitoring requirements

Error monitoring You have to control the logs and monitor the jobs for the reports RWDLCOPY_MANAGE and RSEOUT00 See screenshot how the job’s log for the report RWDLCOPY_MANAGEMENT looks like:

Figure 21: Result of IDoc copy management tools

Performance monitoring You need to monitor the runtime of jobs for both reports but usually they are not performance critical. The most performance critical is RWDBBUPD or RWDBBUPD_HPR POSUP in the step before. Throughput monitoring Just make sure that RWDLCOPY_MANAGE and RSEOUT00 are planned in time before the data are required in the store for selling and under consideration of required time for data conversion and transmission outside SAP ECC.

© 2009 SAP AG

page 57/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Backlog monitoring Just make sure that RWDLCOPY_MANAGE and RSEOUT00 are planned in time before the data are needed in the store. 2.3.3.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Report RWDLCOPY_MA NAGE (optional: copy IDoc from reference store)

Date of job (usually current date)

Long job runtime, job cancellation , time out, error messages in job log

SM37

Runs daily

Report RSEOUT00 (IDoc transmission off ECC )

Date of job (usually current date)

Long job runtime, job cancellation , time out, error messages in job log

SM37

Runs daily

IDoc processing status in case of IDoc interface

Direction, port, partner number, partner type, partner function, message type, basic type, message code, message function, idoc age

Number of IDocs of type WBBDLD in an error-status

WE05 or WE02

every 15 minutes

2.3.3.4

How to find meaningful thresholds per monitoring object

You have to determine the thresholds depending on your business needs when POS outbound has to be finished. So if necessary, you can backwards schedule the jobs RWDLCOPY_MANAGE and RSEOUT00 under consideration of the time needed for conversion and transmission and with some security time reserve 2.3.3.5

Error handling per monitoring object

Background job for RWDLCOPY_MANAGE and RSEOUT00 Check the job log for cancellations and runtime. 2.3.3.6

Scheduling of background jobs

If copy management is used, the jobs are usually scheduled daily after the assortment list was generated.

© 2009 SAP AG

page 58/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Job scheduling requirements

Recommended ABAP or Generated Report Job Name

Variant

Scheduling Predece- Successor Scheduling Error Handssor Job Job Restriction ling in Case of Cancellation

S_DE_R_RWDL RWDLCO COPY_MANAG PY_MAN AGE E_D

Daily

S_DE_R_RSEO RSEOUT UT00_D 00

Daily

2.3.4

Business process step 4: Monitor, correct, and repeat data transfer of assortment list

2.3.4.1

Description and general information

For the operator role, the business process for the assortment list has a separate transaction, the POS monitor. This transaction should be viewed daily after processing of the change version, after initialization and after manual request. The POS monitor is not only to view errors, it is also a great tool to view the successful transmissions and also to enable to find the corresponding IDocs after a report or request for POS assortment list has been performed. This can be valuable also to track a request and the corresponding IDoc number through the process steps outside SAP ECC that you know when and with which content IDoc was created. Scenario-specific sample You can verify the following information using the POS monitor: The recipient of the IDoc The system type that the IDocs belong to (POS outbound or assortment list) When IDocs are created for the recipient The type of preparation (for example, initialization, change message) Whether preparation and transfer of data was completed Number of IDocs which were created for each recipient Whether the IDocs were created completely for each recipient To which IDoc type the IDoc in question belongs (for example, article master, EAN/UPC references) The key (IDoc number) under which the IDocs can be found in the database How many segments the IDoc contains Which IDocs contain errors, and how many errors (you can display an error log for incorrect IDocs) Which data areas are contained in the IDoc (smallest and largest object key) Which data an IDoc contains

© 2009 SAP AG

page 59/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

See screenshot how POS monitor looks like for assortment list:

Figure 22: POS monitor for assortment list

2.3.4.2

Monitoring requirements

Error monitoring using POS monitor transaction WPER Mainly the operator has to deal with the unsuccessful transmissions and needs to view error messages to delegate the actions to either IT or to business. To get business errors and data corrected is necessary for a transmission repeat. In most cases, if there has been a problem with data preparation in step 2 with RWDPOSUP or even in step 1 with RWDPOSIN, then mostly no IDoc will be created (as a result if the problem is classified as an error in the format status). Then you see these requests in the sub-tree for not fully processed requests. With double click or transaction SLG1, the error text can be read from the system log. The error message can be a warning only. An IDoc is created but the operator has to decide if the business must be involved for changing (e.g. article).

© 2009 SAP AG

page 60/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Figure 23: Display logs

Once all errors, which have been displayed for the assortment list messages in the POS monitor, have been processed and data have been corrected you can rerun the change version. You can do this by executing the relevant batch report RWDBBUPD or RWDBBUPD_HPR immediately during day time or with the next change message, which will include the data that was not transferred. It is also possible to wait for the next day’s change version of the assortment list. Scenario-specific sample Data, which was not successfully transmitted, will be repeated on the next day. It is very important and demonstrates the need of an every-day error correcting and consequently of getting the whole record successfully into the status tables (WDLS). All uncorrected errors accumulate every day so the number of errors which have to be analyzed and transmitted increases. This has a noticeable impact on performance of RWDBBUPD or RWDBBUPD_HPR. Moreover, it has an impact on outstanding steps of the business process step 5 and step 6 since the change pointers and status records are not reorganized and deleted. Error monitoring using POS object analysis in transaction WPER2 In addition to the daily monitoring on POS monitor, there is a central group report that you can run to analyze data for generating the POS outbound and the assortment lists. This group report is accessible through transaction WPER2. It comprises several individual reports.

© 2009 SAP AG

page 61/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

The individual reports can be seen in this screenshot:

Figure 24: Individual reports

Please note that dummy initialization has already been discussed in step 1. WPER2: Reorganization check in the assortment list For various reasons a reorganization in the assortment list sometimes fails if you use the retail-specific report RWDPOSRS (see Business Process step 5). This could lead among other things to a dramatic increase in the volume of data and therefore a reduction in performance. This report enables a reasonable analysis and, if necessary, the elimination of the reason.

© 2009 SAP AG

page 62/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Figure 25: Assortment list reorganization check

WPER2: IDoc analysis in the assortment list It often happens that you are looking for a specific object among thousands of IDocs and in the segments of the IDoc. This report provides a quick and easy way to search for such an object. The alternative transaction WE09 would be less easy to handle in this case. Scenario-specific sample You search for a specific article and its price in an IDoc because the store back office server does not show the correct price which is maintained in master data management in SAP ECC. You have to find out in which IDoc and at which point in time the article left the SAP ECC system. This information is necessary to let the search run through other subsystems for data mapping ,conversion, and connectivity. For the POS outbound and for the assortment lists this is difficult since IDocs are generated daily for each store. So the required article has to be found among thousands of IDocs. The report enables a quick and simple object search with regard to the POS outbound basis IDoc, using various selection criteria and combinations from a set selection of any size.

© 2009 SAP AG

page 63/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Figure 26: IDoc analysis assortment list

WPER2: Reprocess in the assortment list When troubleshooting, you have to reproduce errors. This enables you to determine how to fix them. This report allows you to do a test rerun using the same change pointers that were handled in the previous download. Usually, there is some time delay (perhaps even a few days) between the POS run and the analysis, during which time the system may detect new change pointers. This may cause the reprocessing report to include more articles than the original download. This new data is added to all the previous data. None of the previous data will be omitted. This report does not work if the change pointers were already deleted after the previous run. By changing the status, you can resend data or avoid sending redundant data. The following status changes are possible: Changing the status from X or H to status W means that all objects from the last download, which were triggered by change pointers, will be resent in the next download. Changing the status from W or E to status H means that only those objects that have been changed since the previous download will be sent. You can reverse unwanted status changes without any consequences, provided a download in the form of a change analysis has not taken place in the meantime. Performance monitoring During actions described in this chapter, no performance monitoring is necessary as this is monitoring online transactions themselves. Using these reports regularly has a positive effect on the performance of RWDPOSUP. So it is essential to work with these reports. Especially the reorganization check can have enormous impact on the performance. Scenario-specific sample The background is that the processing of the change pointers works with one change pointer for several objects. This change pointer is kept valid until the change had been transmitted to all stores. If for any reason a store did not have a change run for a longer time and initialization had been done, for which reason valid WDLS entry exists, this change pointer does not get set processed in step 5 and not deleted. Therefore the change pointer table remains large which can be caused by one store not being in use anymore. Another possibility is, a store had an error message for a topic which is not solved. Two things can happen:

© 2009 SAP AG

page 64/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

For this store the changes starting from that point in time in the past when the error happened are processed every day until the error is resolved. The change pointers related to that erroneous business change cannot be deleted and thus influence – because of a higher number of change pointers – the processing for the other stores as well. Throughput monitoring Please see comments on performance monitoring. Backlog monitoring using reorganization check option in transaction WPER2 Please see comments on performance monitoring. 2.3.4.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Monitoring Frequency/ Satellite System Data Collection

Date of job (usually current Long job runtime, job Report SM37 RWDLCOPY_MAN date) cancellation , time out, AGE (optional: Copy error messages in job log IDoc from reference store)

Runs daily

Manual request of corrected data

Date of job (usually current Long job runtime, job WDBM date); corrected data cancellation , time out, error messages in job log

If corrected data are urgently needed at POS back office server in store.

RWDBBUPD or RWDBBUPD_HPR (change version)

Date of job (usually current Long job runtime, job WDBU or date); cancellation , time out, WDBU_HPR error messages in job log

If several data had been corrected and is also needed in store quickly and cannot wait until processing next day or if lead time is too short.

Reorganization check Report RWDREORGCHEC K2

If the report shows an object WPER2 with an action to be performed, a decision needs to be taken on how to react

On demand – but to avoid performance issues once or twice a month

If the report shows an object WPER2 with an action to be performed, a decision needs to be taken on how to react

On demand – but to avoid performance issues once or twice a month

Report RWDREPROCESS 2

Reprocess

IDoc processing status in case of IDoc interface

Number of IDocs of type Direction, port, partner WBBDLD in an Error number, Partner type, partner function, message status type, basic type, message code, message function, IDoc age

© 2009 SAP AG

WE05 or WE02

Every 15 minutes

page 65/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.4.4

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

WPER POS monitor

Date of job (usually current date); Application SL and look for store in question

Appear in tree branch for Not fully processes

WPER

Daily after RWDPOSUP and RWDPOSIN and WPMA transaction

Report RWDIDOCSL

IDoc analysis

If the report shows an object with an action to be performed, a decision needs to be taken on how to react

WPER2

On Need

2.3.4.5

How to find meaningful thresholds per monitoring object

Ideally would be no error at all, what means that business maintained master correctly. 2.3.4.6

Error handling per monitoring object

Use transaction WPER and WPER2. The transaction WPER, which is the POS monitor, gives sophisticated indications about incorrect master data for the assortment list to the user. In that sense, the assortment list is more detailed then POS outbound using POS IDocs. See comments about error handling in chapter 2.2.4.6. For assortment list errors the system states clearly, for example: Article not listed in period X,Y,Z Article has no sales price 2.3.4.7

Scheduling of background jobs

If corrections have been made, the changes need to be evaluated and transmitted to the stores. To do this, a job chain containing the change analysis and IDoc creation program, the copy management and the IDoc distribution program can be started. These jobs are usually not scheduled daily at a certain time, but scheduled by request after manual interventions have been necessary. The manual request program RWDBBMAN or transaction WDBM might also be carried out online and not as a job. In this case, only the copy management and the IDoc distribution might be started as jobs.

© 2009 SAP AG

page 66/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Job scheduling requirements

Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

S_DE_R_RWDBBM AN_R

RWDBBMAN

Manual by article restriction

S_DE_R_RWDBBU PD_R or S_DE_R_RWDBBU PD_HPR_R

Predecessor Job

Successor Job

Scheduling Restriction

On request

S_DE_R_RWDLC OPY_MANAGE_D or S_DE_R_RSEOUT 00_R

After manual variant adjustment

RWDBBUPD or RWDBBUPD_H PR

On request

S_DE_R_RWDLC OPY_MANAGE_R

S_DE_R_RWDLCO PY_MANAGE_R

RWDLCOPY_M ANAGE

On request

S_DE_R_RW DBBUPD_R or S_DE_R_RW DBBUPD_HP R_R

S_DE_R_RSEOUT0 0_R

RSEOUT00

On request

S_DE_R_RW DLCOPY_MA NAGE_R

S_DE_R_RWDREO RGCHECK2_M

RWDREORGC HECK2

Once or twice a month

S_DE_R_RWDREP ROCESS2_M

RWDREPROC ESS2

Once or twice a month

Error Handling in Case of Cancellation

S_DE_R_RSEOUT 00_R

2.3.5

Business process step 5: Reorganize change pointers, status records, and WIND entries

2.3.5.1

Description and general information

As already stated above, changes are recorded by using change pointers in table BDCP or BDCP2. These change pointers indicate that changes have been performed and master data need to be transmitted to stores in question. After all stores have received the information, the change pointers are not needed anymore and can be deleted. As aforementioned, a change pointer can be valid for several objects (IDoc types) and also for several stores. The report RWDPOSRS checks for a change pointer if it is still needed for above reasons or not. If the report comes to the conclusion that the change pointer is not needed anymore, then the flag for the change pointer is set to the status processed. At the same time, the report reorganizes the status records in table WDLS*. It only keeps the latest successful transmission record in order to give the next run of the assortment list information from where to start. It also reorganizes the WIND table entries, if condition changes are recorded using the WIND improvement from the HPR initiative.

© 2009 SAP AG

page 67/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.5.2

Monitoring requirements

Error monitoring Read the error log of the background job for report RWDPOSRS. Performance monitoring Read the log of the background job for RWDPOSRS. It should say that at least some numbers of change pointers are set to processed and some status records are deleted. If nothing is set to processes, turn immediately to transaction WPER2 for reorganization. Check if one store is blocking the change pointers to be set to status processed. Scenario-specific sample See the comments on report WPER2 for reorganization check. Throughput monitoring Ideally, all change pointers should be set to status processed if all stores have transmitted changed data successfully and if no uncorrected errors are in the WPER POS monitor visible. If all change pointers are set to processed they will be deleted in the following step. Backlog monitoring It is not immediately observable if all change pointers are set in time to the status processed. In order to ensure smooth performance, it makes sense to use report WPER2 for reorganization check from time to time. This allows seeing possible reasons why change pointers were not set to status processed and thus were not deleted. The report also allows seeing the stores which were affected. In addition, the reprocess report can also be used to identify stores with problems in the past. It also allows to set an old erroneous WDLS record explicitly to the status successful in order to avoid that this erroneous WDLS record is blocking the reorganization of further change pointers. In the backlog monitoring, it is also possible to check with transaction SE16 directly in the table BDCP/BDCPS or BDCP2 how many change pointers without processed flag exist in total. It can be analyzed backwards at which date those change pointers had been created and it can be checked if a data object like an article is not maintained correctly. 2.3.5.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Report RWDPOSRS (Reorganize POS Interface)

Job date (usually current date)

Long job runtime, job cancellation , time out, error messages in job log

SM37

Daily

2.3.5.4

How to find meaningful thresholds per monitoring object

Ideally, all change pointers from the previous days are set to processed.

© 2009 SAP AG

page 68/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.5.5

Error handling per monitoring object

Background job for report RWDPOSRS Check the job log for cancellations and errors. The job log says whether change pointers and how many of them has been reorganized. In case no change pointers have been reorganized it makes sense to turn to transaction WPER2 and check the reports Reprocess and Reorganization Check. 2.3.5.6

Scheduling of background jobs

The job sets the processing status of change pointers, which have successfully been set to processed. This job should be carried out after all IDocs have been created. Job scheduling requirements

Recommended or Generated Job Name

ABAP Report

S_DE_R_RWDPOSRS_D

RWDPOSRS

Variant

Scheduling

Predecessor Job

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

Daily

2.3.6

Business process step 6: Delete change pointers and status records

2.3.6.1

Description and general information

After the change pointers were set to the status processed in step 5 they are finally deleted by the report RBDCPCLR. The report deletes change pointers from the change pointer table. If change pointers are deleted regularly, the change pointer table becomes smaller. Keeping the change pointer table small has a positive impact on the performance of the POS download. Scenario-specific sample The report has two options to delete change pointers: Either the processed or obsolete change pointers. It is recommended to choose the first option, to delete processed change pointers. They are surely not used anymore because the system has set the status in the step before. If all process steps are carefully done, there are no errors messages. In case of errors, they are corrected for all stores and the change message is repeated. Then the process of reorganization and deletion of change pointers works automatically to keep the change pointer table slim. Nevertheless, a job should be planned (preferable in a test version first) to delete obsolete change pointers elder then X days. The business has to decide how many days X days are to be sure to delete no changes that are still required. 2.3.6.2

Monitoring requirements

Error monitoring View the job log for the report RBDCPCLR in SM37.

© 2009 SAP AG

page 69/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Performance monitoring The deletion of change pointers improves the performance of a changed version. If you regularly delete change pointers with RBDCPCLR, you will also encounter no issues with RBDCPCLR. So BPM strongly recommends performing step 6 at least once a week. Throughput monitoring See the comments on performance monitoring. Backlog monitoring See the comments on performance monitoring. 2.3.6.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Report RBDCPCLR (Deletion change pointer)

Job date

Long job runtime, job cancellation , time out, error messages in job log, delayed

SM37

At least once a week, during runtime

2.3.6.4

Scheduling of background jobs

After having set the status of the change pointers to processed, the processed change pointers can be deleted. The corresponding program RBDCPCLR should therefore be scheduled after the job (as explained before). Job scheduling requirements

Recommended or Generated Job Name

ABAP Report

S_DE_R_ RBDCPCLR_D

RBDCPC LR

2.3.6.5

Variant

Scheduling

Predecessor Job

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

Daily or weekly

How to find meaningful thresholds per monitoring object

See the comments on performance monitoring. 2.3.6.6

Error handling per monitoring object

Background job for RBDCPCLR Check the job log for cancellations. The job log says if change pointers and how many change pointers have been deleted. In case of no deletion, it makes sense to start the report to reorganize change pointers. If reorganization is done and still no deletion of change pointers took place, use the transaction WPER2 and check the reports Reprocess and Reorganization Check.

© 2009 SAP AG

page 70/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.7

Middleware (enterprise application integration tool): Receive, transform, and send information

2.3.7.1

Description

General information In most cases, the collected POS download data in form of IDocs is not ready yet for direct processing in the POS store system. It has to be mapped (equal to pure conversion of data formats) or transformed (for example business-oriented conversion of specific EANs. It is necessary to enable the POS system to load data into the POS database. 2.3.7.2

Monitoring requirements

Error monitoring No general statement possible as this depends on the chosen platform in use. SAP PI offers tools for monitoring the success of transformation. Performance monitoring No general statement possible as this depends on the chosen platform in use. SAP PI offers tools for monitoring the success of transformation. Throughput monitoring No general statement possible as this depends on the chosen platform in use. SAP PI offers tools for monitoring the success of transformation. Backlog monitoring No general statement possible as this depends on the chosen platform in use. SAP PI offers tools for monitoring the success of transformation. 2.3.7.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

N/A

N/A

N/A

N/A

N/A

2.3.7.4

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

N/A

N/A

N/A

N/A

N/A

2.3.7.5

How to find meaningful thresholds per monitoring object

Usually, each transformation should be absolutely error free since data are urgently required on EPOS system.

© 2009 SAP AG

page 71/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

2.3.7.6

Error handling per monitoring object

No general statement possible as this depends on the chosen platform in use. SAP PI offers tools for monitoring the success of transformation. 2.3.8

POS system: Receive information and update database

2.3.8.1

Description and general information

After data mapping and conversion is finished (which is probably done in a kind of central head office system), the files have to be transmitted physically to each store. These files update the local POS back office server database. Now the POS cash registers can use the new data. 2.3.8.2

Monitoring requirements

Error monitoring No general statement is possible as this depends on the chosen store POS system in use. Performance monitoring No general statement is possible as this depends on the chosen store POS system in use. Throughput monitoring No general statement is possible as this depends on the chosen store POS system in use. Backlog monitoring No general statement is possible as this depends on the chosen store POS system in use. 2.3.8.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

N/A

N/A

N/A

N/A

N/A

2.3.8.4

Further monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

N/A

N/A

N/A

N/A

N/A

2.3.8.5

How to find meaningful thresholds per monitoring object

Usually, each transformation should be error free since data are urgently required on the EPOS system. So the target is zero error. But if the look-up tables are not completely maintained, errors can occur. 2.3.8.6

Error handling per monitoring object

No general statement is possible as this depends on the chosen store POS system in use.

© 2009 SAP AG

page 72/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

3

Further Information

3.1

Troubleshooting

In the following notes on the SAP Service Marketplace, you can find additional information about specific implementation or upgrade project related topics for POS outbound and for assortment list high performance retail features and for migration topics: 1167070 380814 603472 720514 519685 513454 305462 208669

3.2

Related Best Practice Documents

There are several other Best Practice documents available on the SAP Service Marketplace under https://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, error handling, and escalation procedures for your company’s SAP 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 SAP Solution Manager. Please note that these documents are also available at SAP Service Marketplace, alias RunSAP

RunSAP

Best Practices.

© 2009 SAP AG

page 73/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

4

Appendix

In the following section you find one example for each of the monitoring tools. It demonstrates how you can set up the monitoring within SAP Solution Manager.

4.1

Example Background Job Monitoring

Background job monitoring of the background job RWDPOSUP in SAP Solution Manager: The setup for the other jobs is, besides the job specific parameters, quite similar. 1. Call 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 the process steps to monitor. 6. Check for your chosen step: Choose the type of monitor, here Background Job. 7. Enter the information to be used to identify the job, in this case the job name _S_DE_R_RWDPOSUP_D or the ABAP program name RWDPOSUP.

Figure 27: Customize the background job monitoring with ABAP program name RWDPOSUP

Figure 28: Customize the delay time for starting

© 2009 SAP AG

page 74/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Figure 29: Job cancellation

8. Choose the key figures the job cancellation and the job log messages to monitor error messages in the job log.

Figure 30: Customize the job log monitoring

You find the information about the message class and message number in the job log of the job you want to monitor.

Figure 31: Message class, message number

Choose the job from the F4 input help and specify the message type E for error. A 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.

© 2009 SAP AG

page 75/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

9. The monitoring schedule should be once a day.

Figure 32: Monitoring schedule

10. 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 Monitoring

The message flow via SP PI can be very complex passing different components (such as adapter engines with the module processor and messaging system, integration engines with their pipeline processing, including Java and ABAP proxies, business process engine) and using different adapter types (such as file-, JMS-, IDoc-, RNIF-adapters etc.). The complexity makes it difficult to track and monitor the flow of a specific message. The information how you can set up the Business Process Monitoring for PI messages for all different scenarios you can find in chapter 9 SAP PI Message Processing Monitoring in the Setup Guide Interface Monitoring in the SAP Solution Manager.

4.3

Example ALE/IDoc Monitoring

Example: IDoc monitoring for IDocs WPDWGR, WP_PLU, WP_EAN, WPDSET, WPDNAC, WPDCUR, WPD_TAX, WP_PER, WPDREB and WBBDLD in SAP Solution Manager . The setup for other IDoc types is very similar. Please look into the Setup Guide Interface Monitoring if you need more information regarding the setup procedure. The setup of IDoc monitoring will be done in the setup session of Business Process Monitoring. At least one business process with steps on different systems and defined interfaces must be available before it is possible to configure IDoc monitoring.

© 2009 SAP AG

page 76/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

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 field Select.

Figure 33: Select monitoring type

© 2009 SAP AG

page 77/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

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 opens a selection screen where you maintain header information of this monitoring object. Parameters Direction and IDoc Age (in hours) are mandatory.

Figure 34: Select key figures I

The customizing of the data collection can be done in tab Monitoring Schedule. Here, you can adjust time and frequency of the data collection. The flag for Data Collection in Background is set automatically, as the data collector reads EDI tables which can grow very large. Thus, dialog processing of the data collection would 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.

Figure 35: Select key figures II

© 2009 SAP AG

page 78/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

3. Specify key figures After saving the sub-nodes, Delta number monitor and/or Total number monitor will appear. A double click on the counter in tab Key Figures shows further details of the monitoring. The 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. five minutes Status Counter: E.g. 2 (This means, the IDoc has to be at least 2 times in status 51 before being alerted.)

Figure 36: Specify key figures

After you have entered and confirmed your selection criteria, the tab Parameter Value Ranges will appear where an overview of your customizing is displayed. Return to tab Delta number monitor/Total number monitor to specify the thresholds for alerting. You can define threshold values in both directions, for more than 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.

4.4

Background Jobs

Certain jobs must run periodically in a production SAP for Retail system, for example, deleting obsolete jobs or spool 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 be scheduled manually. For more information, see SAP note 16083. Note that a daily monitoring of the job log using SAP Solution Manager is recommended.

© 2009 SAP AG

page 79/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

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: 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. Status released: The job has been fully defined, including a start condition and waits for the condition to fulfill. 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. 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. Status finished: All steps that make up this job have successfully been executed. 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.). Status cancelled: The job has terminated abnormally, which can happen in two ways: First, if an administrator intentionally cancelled the job, clarify why he did so and whether (and if, when) the job has to be re-run. Second, 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 at SAP portal and open a customer message if you cannot solve the problem. Job restartability In case of the cancellation of a background job, possible succeeding jobs or dependencies on other jobs must be considered when restarting the aborted job. The start of succeeding jobs might be also delayed due to the restart of the aborted job. Escalation procedures If it is not possible for any of your support levels to provide a solution for a particular problem, it is recommended to open a customer problem message in the SAPNet R/3 front-end system.

© 2009 SAP AG

page 80/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

Index of Figures Figure 1: Alert type Number of ABAP Dumps (Delta) Figure 2: Monitoring objects – Dialog performance Figure 3: Monitoring alerts - Dialog performance Figure 4: Monitoring objects – Update errors Figure 5: Monitoring objects – Due list log Figure 6: Monitoring objects and alerts – Application log Figure 7: Monitoring alerts – Application log/Critical messages Figure 8: Other CCMS monitors Figure 9: Analysis and monitoring transactions Figure 10: Analysis & monitoring URL Figure 11: Process flow point of sale outbound variant 1 with POS interface IDocs Figure 12: Results of IDoc copy management tools Figure 13: Screenshot of POS monitor (POS outbound) Figure 14: Display logs Figure 15: Individual reports Figure 16: Object analysis POS outbound Figure 17: POS outbound reorganization check Figure 18: IDoc analysis POS outbound selection screen Figure 19: IDoc analysis POS outbound result Figure 20: Process flow point of sale outbound variant 2 with assortment list IDoc Figure 21: Result of IDoc copy management tools Figure 22: POS monitor for assortment list Figure 23: Display logs Figure 24: Individual reports Figure 25: Assortment list reorganization check Figure 26: IDoc analysis assortment list Figure 27: Customize the background job monitoring with ABAP program name RWDPOSUP Figure 28: Customize the delay time for starting Figure 29: Job cancellation Figure 30: Customize the job log monitoring Figure 31: Message class, message number Figure 32: Monitoring schedule Figure 33: Select monitoring type Figure 34: Select key figures I Figure 35: Select key figures II Figure 36: Specify key figures

11 12 13 14 15 16 16 17 18 18 26 33 36 37 38 39 39 40 40 50 57 60 61 62 63 64 74 74 75 75 75 76 77 78 78 79

Index of Tables Table 1: Problem resolution procedures Table 2: Workflow notification Table 3: Support notifications Table 4: HPR version improvements Table 5: Correlations for activation of change pointers

© 2009 SAP AG

19 20 21 23 27

page 81/82

Best Practice for Solution Operations Manage Operations for SAP for Retail – POS Download

© Copyright 2009 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 tradem arks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation. 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 Citrix Systems, Inc. HTML, XML, XHTML and W3C are tradem arks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute 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 by Netscape. 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 their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational 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 form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreem ent with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be 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 the information, 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 noninfringem ent. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may 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 may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

© 2009 SAP AG

page 82/82