Anda di halaman 1dari 82

Best Practice for Solution Operations

Manage Operations for SAP for Retail


POS Download

Dietmar-Hopp-Allee 16
D-69190 Walldorf
CS STATUS
customer published
DATE VERSION
June 10 2009 3.0

SOLUTION MANAGEMENT PHASE SAP SOLUTION


Operations & Continuous Improvement Best Practices for Solution Operations
TOPIC AREA SOLUTION MANAGER AREA
Application & Integration Management Business Process 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 6
1.1 Goal of Using This Best Practice 6
1.2 Alternative Practices 6
1.3 Staff and Skills Requirements 6
1.4 System Requirements 7
1.5 Duration and Timing 7
1.6 How to Use This Best Practice 7
1.7 Best Practice Procedure 8
1.7.1 Preliminary tasks 8
1.7.2 Monitoring concepts 8
1.7.3 Business Process Monitoring in SAP Solution Manager 8
1.7.4 Monitoring types for Business Process Monitoring in SAP Solution Manager 9
1.7.4.1 Application monitor 10
1.7.4.2 Background job 10
1.7.4.3 ABAP dump collector 11
1.7.4.4 Dialog performance 12
1.7.4.5 Update errors 13
1.7.4.6 Due list log 14
1.7.4.7 Application log 15
1.7.4.8 Other CCMS monitors 17
1.7.4.9 Analysis and monitoring tools 17
1.7.4.10 Monitoring activities 19
1.7.4.11 Notifications 19
1.7.5 Business Process Monitoring process 21
1.7.6 Legend 21
2 Business Process Monitoring for a Point of Sale (POS) Download Data Transmission 22
2.1 Sample Scenario 25
2.2 Business Process POS Outbound with POS Interface IDocs 26
2.2.1 Business process step 1: Initialize or dummy initialize new store 28
2.2.1.1 Description and general information 28
2.2.1.2 Monitoring requirements 29
2.2.1.3 Further monitoring objects 29
2.2.1.4 How to find meaningful thresholds per monitoring object 30
2.2.2 Business process step 2: Evaluate master data changes, collect and prepare data, create
IDoc 30
2.2.2.1 Description and general information 30
2.2.2.2 Monitoring requirements 30
2.2.2.3 Monitoring objects in SAP Solution Manager 31
2.2.2.4 Further monitoring objects 31
2.2.2.5 How to find meaningful thresholds per monitoring object 31
2.2.2.6 Scheduling of background jobs 32
2.2.3 Business process step 3: Copy IDocs within ECC retail (optional) and send out IDocs from
ECC retail 32
2.2.3.1 Description and general information 32
2.2.3.2 Monitoring requirements 33

© 2009 SAP AG page 2/82


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

2.2.3.3 Monitoring objects in SAP Solution Manager 34


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

© 2009 SAP AG page 3/82


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

2.3.1.5 Error handling per monitoring object 53


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

© 2009 SAP AG page 4/82


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

2.3.7.6 Error handling per monitoring object 72


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

© 2009 SAP AG 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 process-
oriented 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) SAP Solution Manager Basic Settings.

1.7.4.1 Application monitor

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

Please ensure that the ST-A/PI is installed on the SAP Solution Manager system and on the 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 Media Library).

1.7.4.2 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 sub-
node 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 <XYZ> button, with <XYZ> 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 sub-
object that belongs to it classify each event. The analysis of the logs is similarly object- (or sub-object)
oriented. The name of an object (and/or sub-object) can be found in transaction /nSLG1 together with 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://\\\<server>\..., 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 e-
mail address, an SAP user name in the same system, a remote SAP name or a
shared distribution list. In case of an SMS you need to enter SMS:<cell phone or
pager number>.

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

No. of Yellow Alerts Number of YELLOW alerts that can occur before an automatic notification is
triggered

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

Max Wait Time [h] Once the maximum wait time [hours] has elapsed, a notification is created even if
the thresholds are not exceeded.

RED Only To restrict this mechanism only to red alerts, the flag in column RED Only must be
set.

Detailed Triggers a long text for e-mails or SAPOffice mails, e.g. name of the solution, name
of the business process step, …)

Table 2: Workflow 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 Necessary when service desk messages are created automatically, e.g. after ten
Alerts yellow alerts a service desk message should be created.

Num of RED Alerts Necessary when service desk messages are created automatically, e.g. after five
red alerts a service desk message should be created.

Table 3: Support notifications

If in addition to Queue, Processor, Priority and Reporter either one of the columns Num of YELLOW
Alerts or Num of RED Alerts is filled with a value, the automatic support notification creation is
configured. In case that both columns are filled with a value, the automatic support notification creation
works with a logical OR operation. Hence, with the figures in the table above the system would create a
support notification if there are either more than nine yellow alerts or more than four red alerts for which
no support notification has been created yet.

1.7.5 Business Process Monitoring 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 Enhanced Change Pointers


Index in Table WIND 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 Object Message Type to Be Activated


Is to Be Sent

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 Selection Alert Analysis Tool on Monitoring Frequency/ Data


Object Criteria Satellite System Collection

Report RWDPOSIN, Long job runtime, job cancellation , SM37 Runs usually once when new
RWDPOSIN date of job time out, error messages in job log, store opened; when job is
(initialization (usually current job canceled or delayed running, monitor in periodic
execution) date) intervals system/runtime
performance

Report RWDPOSDU, Job cancellation; long runtime is not SM37 Usually once when new store
RWDPOSDU date of job likely as this job just creates one opened (as an alternative to
(dummy (usually current table entry in table WDLS. RWDPOSIN when store
initialization date) database has full data already
execution) copied from other store back
office server etc.

Processing status Date of job Look for tree branch in outbound WPER After job execution
of initialization in finished and processing – not fully processed –
POS monitor outbound preparation mode I = initializations:
application POS Double click to read system log text
with error message

© 2009 SAP AG page 29/82


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 Monitoring


Satellite System Frequency/ Data
Collection

Background job S_DE_R_RWDPOS Long job runtime, job SM37 Every five minutes
S_DE_R_RWDPOSUP_D UP_D, RWDPOSUP cancellation , time out, error during every job
(Report RWDPOSUP) messages in job log execution
(changes message execution)

2.2.2.4 Further monitoring objects

Monitoring Object Selection Criteria Alert Analysis Tool on Monitoring


Satellite System Frequency/ Data
Collection

Processing status of change Date of job finished Look for tree branch in WPER After job execution
message in POS monitor and outbound outbound processing – not
application POS fully processed – preparation
mode u = update double-
click to read system log text
with error message

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 ABAP Variant Scheduling Predecessor Successor Scheduling Error Handling in


or Generated Report Job Job Restriction Case of
Job Name Cancellation

S_DE_R_RWDP RWDPOSUP To be Runs usually daily; S_DE_R_RS Root cause


1
OSUP_D defined monitor when job is EOUT00_D if analysis required,
running in periodic IDocs are not potentially a
intervals system/ sent restart might be
runtime performance automatically sufficient

S_DE_R_RSEO RSEOUT00 Daily S_DE_R_RW Restart job


UT00_D DPOSUP_D

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 Monitoring Frequency/


Satellite System Data Collection

Background job S_DE_R_RWDLCOPY_M Long job runtime, job SM37 Every five minutes
S_DE_R_RWDLCOPY_ ANAGE_D, cancellation, time out, error during every job
MANAGE_D (report RWDLCOPY_MANAGE, messages in job log execution
RWDLCOPY_MANAGE
)

Background job S_DE_R_RSEOUT00_D, Long job runtime, job SM37 Every five minutes
S_DE_R_RSEOUT00_ RSEOUT00, cancellation, time out, error during every job
D messages in job log execution
(Report RSEOUT00)
(IDoc transmission off
ECC )

IDoc processing status Direction, port, partner Number of IDocs of type WE05 or WE02 Every 15 minutes
in case of IDoc interface number, partner type, WPDWGR, WP_PLU,
partner function, message WP_EAN, WPDSET,
type, basic type, message WPDNAC, WPDCUR,
code, message function, WPD_TAX, WP_PER,
IDoc age WPDREB in an error-status

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 ABAP Report Variant Scheduling Predecessor Successor Scheduling Error Handling in
Generated Job Job Job Restriction Case of
Name Cancellation

S_DE_R_RWDLC RWDLCOPY_M Daily S_DE_R_RW S_DE_R_RS


OPY_MANAGE_D ANAGE DPOSUP_D EOUT00_D

S_DE_R_RSEOU RSEOUT00 Daily S_DE_R_RW


T00_D DLCOPY_MA
NAGE_D

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

2.2.4.1 Description

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 Alert Analysis Tool on Monitoring Frequency/


Satellite System Data Collection

Background job S_DE_R_RWDLCOPY_MA Long job runtime, job SM37 Every five minutes during
S_DE_R_RWDLCOPY NAGE_D, cancellation , time out, error every job execution
_MANAGE_D (report RWDLCOPY_MANAGE messages in job log
RWDLCOPY_MANAG
E)

Background job S_DE_R_RWDPOSAN, Long job runtime, job WPMA If corrected data are
S_DE_R_RWDPOSAN RWDPOSAN cancellation , time out, error urgently needed at POS
(report RWDPOSAN) messages in job log SM37 back office server in store.
Every five minutes during
every job execution

Background job S_DE_R_RWDPOSUP, Long job runtime, job WPMU If several data had been
S_DE_R_RWDPOSUP RWDPOSUP cancellation , time out, error corrected and are also
(Report RWDPOSUP) messages in job log SM37 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_ If report shows an object with WPER2, Every five minutes during
S_DE_R_ RWDREORGCHECK _M, action to perform need to every job execution
RWDREORGCHECK RWDREORGCHECK make decision how to act SM37
_M (Report
RWDREORGCHECK)

Background job S_DE_R_ If report shows an object with WPER2, Every five minutes during
S_DE_R_ RWDREPROCESS2_M, action to perform need to every job execution
RWDREPROCESS2_M WDREPROCESS2 make decision how to act SM37
(Report
RWDREPROCESS2)

IDoc processing status Direction, port, partner Number of IDocs of type WE05 or W E02 Every 15 minutes
in case of IDoc number, partner type, WPDWGR, WP_PLU,
interface partner function, message WP_EAN, WPDSET,
type, basic type, message WPDNAC, WPDCUR,
code, message function, WPD_TAX, WP_PER,
idoc age WPDREB in an error-status

© 2009 SAP AG 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 Monitoring Frequency/


Satellite System Data Collection

WPER POS monitor Date of job (usually Appear in tree branch WPER Daily after RWDPOSUP and
current date); for Not fully RWDPOSIN and WPMA
application POS and processes transaction
look for store in
question

Report Object to be checked If the report shows an WPER2 As required


RWDDOWNLOAD object with an action
to be performed, a
Object analysis decision needs to be
taken on how to react

Report RWDIDOCPOS Object to be checked If the report shows an WPER2 As required


object with an action
IDoc analysis to be performed, a
decision needs to be
taken on how to react

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

Recomm- ABAP Variant Sche- Predecessor Successor Scheduling Error Handling


ended or Report duling Job Job Restriction in Case of
Generated Cancellation
Job Name

S_DE_R_RW RWDPOSA Manual by article On request S_DE_R_RWD After manual


DPOSAN_R N restriction LCOPY_MANA variant
GE_D or adjustment
S_DE_R_RSE
OUT00_R

S_DE_R_RW RWDPOSU On request S_DE_R_RWD


DPOSUP_R P LCOPY_MANA
GE_D or
S_DE_R_RSE
OUT00_R

S_DE_R_RW RWDLCOP On request S_DE_R_RWDP S_DE_R_RSE


DLCOPY_MA Y_MANAGE OSUP_R or OUT00_R
NAGE_D S_DE_R_RWDP
OSAN_R

S_DE_R_RSE RSEOUT00 On request S_DE_R_RWDL


OUT00_R COPY_MANAG
E_D or
S_DE_R_RWDP
OSUP_R

S_DE_R_ RWDREOR 1 or 2
RWDREORGC GCHECK times a
HECK _M month

S_DE_R_ RWDREPR 1 or 2
RWDREPROC OCESS2 times a
ESS2_M month

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 Monitoring Frequency/ Data
Satellite System Collection

Report Job Date (usually Long Job Runtime, Job SM37 Every five minutes during
RWDPOSRS current date) Cancellation , Time Out, every job execution
(Reorganize POS Error messages in Job Log
Interface)

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 ABAP Variant Sche- Predece- Successor Scheduling Error Handling in


or Generated Report duling ssor Job Job Restriction Case of
Job Name Cancellation

S_DE_R_ RWDPOSRS Daily


RWDPOSRS_D

2.2.6 Business process step 6: Delete change pointers and status records

2.2.6.1 Description and general information

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 Monitoring Frequency/


Satellite System Data Collection

Background Job S_DE_R_ Long job runtime, job SM37 Every five minutes during
S_DE_R_ RBDCPCLR RBDCPCLR _W, cancellation , time out, every job execution
_W, RBDCPCLR , Job error messages in job log,
Date delayed
(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 ABAP Variant Sche- Predece- Successor Scheduling Error Handling in


Generated Job Report duling ssor Job Job Restriction Case of Cancellation
Name

S_DE_R_ RBDCPCL Daily or S_DE_R_


RBDCPCLR _W R weekly RWDPOSR
S_D

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 Monitoring Frequency/


Satellite System 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 Monitoring Frequency/


Satellite System 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 Monitoring Frequency/


Satellite System 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 Monitoring Frequency/


Satellite System 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 Monitoring Frequency/ Data
Satellite System Collection

Report RWDBBINI or Date of job (usually Long job runtime, job SM37 Runs usually once when new
RWDBBINI_HPR current date) cancellation, time out, error store opened; monitor when
(initialization messages in job log, delayed job is running in periodic
execution) intervals system/runtime
performance
During runtime

Report RWDSLDUM Date of job (usually Job cancellation; long runtime is SM37 Usually once when new store
(dummy initialization current date) not likely as this job just creates opened (as alternative to
execution) one table entry in table WDLS RWDPOSIN when store
database has full data already
copied from other store back
office server etc.

Processing status of Date of job finished Look for tree branch in outbound WPER After job execution
initialization in POS and outbound processing – not fully processed
monitor application SL – preparation mode I =
initializations: Double click to
read system log text with error
message

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 Selection Criteria Alert Analysis Tool on Monitoring Frequency/


Object Satellite System Data Collection

Report RWDBBUPD or Date of job (usually Long job runtime, job SM37 Runs usually daily; monitor
RWDBBUPD_HPR current date) cancellation , time out, when job is running in periodic
(changes message error messages in job log intervals system/ runtime
execution) performance

2.3.2.4 Further monitoring objects

Monitoring Object Selection Criteria Alert Analysis Tool on Monitoring Frequency/


Satellite System Data Collection

Processing status of Date of job finished Look for tree branch in WPER After job execution
change message in and outbound outbound processing – not
POS monitor application SL fully processed – preparation
mode U = update double
click to read system log text
with error message

2.3.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 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 ABAP Variant Scheduling Predece- Successor Scheduling Error Handling


Generated Job Report ssor Job Job Restriction in Case of
Name Cancellation

S_DE_R_ RWDBBUPD Daily


RWDBBUPD_D or
RWDBBUPD
_HPR

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 Selection Alert Analysis Tool on Monitoring Frequency/


Object Criteria Satellite System Data Collection

Report Date of job Long job runtime, SM37 Runs daily


RWDLCOPY_MA (usually current job cancellation ,
NAGE (optional: date) time out, error
copy IDoc from messages in job
reference store) log

Report Date of job Long job runtime, SM37 Runs daily


RSEOUT00 (IDoc (usually current job cancellation ,
transmission off date) time out, error
ECC ) messages in job
log

IDoc processing Direction, port, Number of IDocs of WE05 or WE02 every 15 minutes
status in case of partner number, type WBBDLD in
IDoc interface partner type, an error-status
partner function,
message type,
basic type,
message code,
message
function, idoc age

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 Variant Scheduling Predece- Successor Scheduling Error Hand-


or Generated Report ssor Job Job Restriction ling in Case
Job Name of
Cancellation

S_DE_R_RWDL RWDLCO Daily


COPY_MANAG PY_MAN
E_D AGE

S_DE_R_RSEO RSEOUT Daily


UT00_D 00

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

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

Manual request of Date of job (usually current Long job runtime, job WDBM If corrected data are
corrected data date); corrected data cancellation , time out, urgently needed at POS
error messages in job log back office server in
store.

RWDBBUPD or Date of job (usually current Long job runtime, job WDBU or If several data had been
RWDBBUPD_HPR date); cancellation , time out, WDBU_HPR corrected and is also
(change version) error messages in job log needed in store quickly
and cannot wait until
processing next day or if
lead time is too short.

Report Reorganization check If the report shows an object WPER2 On demand – but to
RWDREORGCHEC with an action to be avoid performance
K2 performed, a decision needs issues once or twice a
to be taken on how to react
month

Report Reprocess If the report shows an object WPER2 On demand – but to


RWDREPROCESS with an action to be avoid performance
2 performed, a decision needs issues once or twice a
to be taken on how to react
month

IDoc processing Direction, port, partner Number of IDocs of type WE05 or WE02 Every 15 minutes
status in case of number, Partner type, WBBDLD in an Error
IDoc interface partner function, message status
type, basic type, message
code, message function,
IDoc age

© 2009 SAP AG 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 Monitoring Frequency/


Satellite System Data Collection

WPER POS monitor Date of job (usually Appear in tree WPER Daily after RWDPOSUP
current date); branch for Not fully and RWDPOSIN and
Application SL and processes WPMA transaction
look for store in
question

Report IDoc analysis If the report shows an WPER2 On Need


RWDIDOCSL object with an action to
be performed, a
decision needs to be
taken on how to react

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 ABAP Report Variant Sche- Predecessor Successor Job Scheduling Error Handling
Generated Job duling Job Restriction in Case of
Name Cancellation

S_DE_R_RWDBBM RWDBBMAN Manual On S_DE_R_RWDLC After manual


AN_R by article request OPY_MANAGE_D variant
restriction or adjustment
S_DE_R_RSEOUT
00_R

S_DE_R_RWDBBU RWDBBUPD or On S_DE_R_RWDLC


PD_R or RWDBBUPD_H request OPY_MANAGE_R
S_DE_R_RWDBBU PR
PD_HPR_R

S_DE_R_RWDLCO RWDLCOPY_M On S_DE_R_RW S_DE_R_RSEOUT


PY_MANAGE_R ANAGE request DBBUPD_R or 00_R
S_DE_R_RW
DBBUPD_HP
R_R

S_DE_R_RSEOUT0 RSEOUT00 On S_DE_R_RW


0_R request DLCOPY_MA
NAGE_R

S_DE_R_RWDREO RWDREORGC Once or


RGCHECK2_M HECK2 twice a
month

S_DE_R_RWDREP RWDREPROC Once or


ROCESS2_M ESS2 twice a
month

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 Monitoring Frequency/


Satellite System Data Collection

Report RWDPOSRS Job date (usually Long job runtime, job SM37 Daily
(Reorganize POS current date) cancellation , time out,
Interface) error messages in job log

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 ABAP Variant Sche- Predecessor Successor Scheduling Error Handling in


Generated Job Name Report duling Job Job Restriction Case of Cancellation

S_DE_R_RWDPOSRS_D RWDPOSRS 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 Monitoring Frequency/


Satellite System Data Collection

Report RBDCPCLR Job date Long job runtime, job SM37 At least once a week,
(Deletion change pointer) cancellation , time out, error during runtime
messages in job log, delayed

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 ABAP Variant Scheduling Predecessor Successor Scheduling Error Handling in


Generated Job Name Report Job Job Restriction Case of Cancellation

S_DE_R_ RBDCPC Daily or


RBDCPCLR_D LR weekly

2.3.6.5 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 Monitoring Frequency/


Satellite System 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 Monitoring Frequency/


Satellite System 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 Monitoring Frequency/


Satellite System 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 Monitoring Frequency/


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

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

© 2009 SAP AG 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 non-
infringem 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