Bestpractice Pos Analytics

Best Practice for Solution Operations
Manage Operations for POS Data Management POS Analytics Content
Dietmar-Hopp-Allee 16 D-69190 Walldorf

CS STATUS
customer
DATE
published
VERSION
Mar-19, 2009
SOLUTION MANAGEMENT PHASE
3.0
SAP SOLUTION
Operations & Continuous Improvement Best Practices for Solution Operations

TOPIC AREA SOLUTION MANAGER AREA
Application & Integration Management Business Process Operation
BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc 24.04.2009

Manage Operations for SAP POS Data Management - POS Analytics Content
Table of Contents
1 Management Summary 1.1 Goal of Using this Best Practice 1.2 Alternative Practices 1.3 Staff and Skills Requirements 1.4 System Requirements 1.5 Duration and Timing 1.6 How to Use this Best Practice 1.7 Best Practice Procedure 1.7.1 Preliminary tasks 1.7.2 Monitoring Concepts 1.7.3 Business Process Monitoring in SAP Solution Manager 1.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 1.7.4.1 Application Monitor 1.7.4.2 Background Job 1.7.4.3 ABAP Dump Collector 1.7.4.4 Dialog performance 1.7.4.5 Update errors 1.7.4.6 Application Log 1.7.4.7 Analysis and monitoring tools 1.7.4.8 Monitoring activities 1.7.4.9 Notifications 1.7.5 Business Process Monitoring Process 2 Process execution and monitoring for a POS Analytics BI Content scenario 2.1 Sample Scenario 2.1.1 Process Step 12: Transfer master data for POS data management to SAP NetWeaver BI 2.1.1.1 Description 2.1.1.2 Monitoring objects 2.1.1.3 Error handling per monitoring object 2.1.2 Proc. step 7b: Update transactional POS data for POS data management to SAP NetWeaver BI 2.1.2.1 Description 2.1.2.2 Monitoring requirements: 2.1.2.3 Monitoring Objects 2.1.2.4 Error handling per monitoring object 3 Further Information 3.1 Related Best Practice Documents 3.2 Background Information and References Index of Figures Index of Tables 3 3 3 3 4 4 4 5 5 5 5 6 7 7 8 9 11 12 13 15 15 16 17 17 18 18 23 23 24 24 28 28 28 30 30 30 31 31
2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc
page 2/32

1
1.1
Management Summary
Goal of Using this Best Practice
This Best Practice helps you set up a Business Process Monitoring concept for your POS data management solution. The concept aims to define procedures for business process oriented monitoring and error handling and escalation procedures for your processes in POS analytics content. 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 the SAP Solution Manager for the Monitoring functionalities. But even if you do not use the 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 Solution Management Optimization (SMO) service for SAP Business Process Management (BPM). This service is exclusively available within SAPs support engagements SAP MaxAttention and SAP Safeguarding. If your company currently does not have any support engagement with SAP, it is also possible to get assistance by SAP experts from SAP Consulting. If 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 retail 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)
page 3/32

SAP Technology Operations Team All parties in your solution support organization and IT department involved in monitoring focused on the system administration side (program scheduling management, software monitoring team, system administration team including the System Administrator) Business process champion The business process champion is the person in the business department that is responsible for the successful execution of the business process. He coordinates all activities necessary for the business process. Therefore, he is usually responsible for the escalation paths in case of problems. Often he is a second level in the escalation procedure, if the application monitoring team needs to escalate an issue. More information about roles and responsibilities of these teams can be found in the super-ordinate Best Practice General Business Process Management, which you can obtain through SAP Solution Manager or the SAP Service Marketplace, quicklink /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 POS DM 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/PI 01L has to be installed on the SAP NetWeaver BI system.
1.5
Duration
Duration and Timing
Creating a Business Process Monitoring concept could take around one week per business process. Implementing the Business Process Monitoring concept might take approximately an additional week. 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 SAP 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.
page 4/32

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
1.7.1
Best Practice Procedure

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 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: Error monitoring Performance monitoring Throughput monitoring Backlog monitoring 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 NetWeaver BI solution is generally the same. Therefore, you will only find specific performance monitoring recommendations on selected business process steps. 1.7.3 Business Process Monitoring in SAP Solution Manager
Business Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and processoriented monitoring of the most important or critical business processes including the observation of all technical and business application specific functions that are required for a steady and stable flow of the business processes.
page 5/32

The core business processes that are implemented in a SAP NetWeaver BI 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 companys business requirements in terms of stability, performance, and completeness. The SAP Solution Manager provides a graphic to visualize a companys (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 the 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, the SAP Solution Manager offers extended functionality for error handling and problem resolution. By the definition of contact persons and escalation paths, Business Process Monitoring can be integrated into the companys 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 the 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 the 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 the SAP Solution Manager is that all business processes and business process steps are maintained in the respective solution that
page 6/32

contains all affected system components. If you want to learn more about how to set this up, please turn to (URL http://help.sap.com) 1.7.4.1 SAP Solution Manager Basic Settings.
Application Monitor
The Application Monitor is just one of many different monitoring types within the Business Process Monitoring. The latest monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the satellite system. The service tool for ST-A/PI is available via the SAP Service Marketplace quick link /installations 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 system. In case of problems refer to SAP Note 915933. For the throughput and backlog indicator functionality available as of ST-A/PI 01J*, the minimum STSER release is 700_2007_1. 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://www.service.sap.com/ Alias 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 example, in ERP Logistics 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://www.service.sap.com/BPM 1.7.4.2 Background Job Media Library).
The background job monitoring should be part of a job scheduling management concept (go to http://service.sap.com/solutionmanagerbp Topic Area Business Process Operations to find a Best Practice document Job Scheduling Managemen). Because of several restrictions regarding background job
page 7/32

scheduling, e.g. time restrictions, restriction of hardware resources (CPU, main memory, ) or existing 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 (than provided in this document) 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 Marketplace http://service.sap.com/solutionmanagerbp 1.7.4.3 ABAP Dump Collector Topic Area Business Process Operation.
To provide monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors or to collect 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 which leads to the runtime error. Monitoring Alerts Possible alerts 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.
page 8/32

Figure 1: Monitoring alert types
1.7.4.4
Dialog performance
Dialog performance implies the monitoring of the dialog transaction performance of any transaction in the SAP System. This could be a standard transaction or an own developed transaction. Monitoring objects The monitoring object is the transaction itself. The customizing has to be done in node Dialog Performance. In table Transactions all transactions that are already configured to that business process step are listed. The relevant transactions need to be selected for monitoring. It is also possible to add or to remove transactions within table Add/Remove Transactions. The monitoring can be performed per SAP instance. Therefore the respective instances have to be selected in table SAP Instances. All instances that are maintained for a system are listed there. Table Alert Types shows the dialog response time and all parts of the response time, like queue time, load and generation time, database request time and the front-end response time, that can be monitored. Those times that are relevant for monitoring have to be selected. After saving this node a sub-node Performance Alerts will appear where the threshold values have to be entered.
page 9/32

Figure 2: Monitoring objects dialog performance
Monitoring alerts Each table in the sub-node Performance Alerts corresponds to an alert type chosen in the higher-level node, and lists the combinations of specified transaction code and SAP instance. For each combination of transaction code and instance that should be included in the monitoring, the threshold values resulting in alert messages for changes from GREEN to YELLOW, from YELLOW to RED, back from RED to YELLOW, and back from YELLOW to GREEN have to be specified. Since the monitoring object for performance monitoring is created on the satellite system, it might be possible that the object already exists there. Therefore you can load the current threshold values from the respective systems via the button Load thresholds from XYZ, whereas XYZ represents the SID. If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for the threshold values were found for a certain transaction code, default values are set (indicated in column Default). To transfer the threshold values for a single line from right to left, the copy icon can be used. To transfer all at once (all thresholds for all columns and tables) there is an additional button "Copy all".
Figure 3: Monitoring alerts dialog performance
page 10/32

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 in full 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, such as 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.
Figure 4: Monitoring objects update errors
page 11/32

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 Application Log
The application log provides an infrastructure for collecting messages, saving them in the database and displaying them as a log. Situations can arise at runtime in application programs that must be brought to the attention of the user in some way. These are usually errors. It can also be useful to report a successful completion. The information that arises is called a message. The set of messages is a log. A log usually also has header information (log type, creator, creation time, etc.). A transaction can generate several logs. The application log is not written consecutively but as a whole at one point in time. Monitoring objects and alerts The application log allows an application- or object-oriented recording of events. An object and any subobject that belongs to it classify each event. The analysis of the logs is similarly object (or sub-object) oriented. The name of an object (and/or sub object) can be found in transaction /nSLG1 together with all other specific information to that log.
Figure 5: 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
page 12/32

changes from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wild cards.
Figure 6: Monitoring alert application log/critical messages
1.7.4.7
Analysis and monitoring tools
It is possible to specify analysis transactions or URL addresses (including file directories) per monitoring object. 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 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.
page 13/32

Figure 7: Analysis & monitoring transactions
On the second tab strip it is possible to specify an 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 8: Analysis & monitoring url
The specified transactions or URLs will be available in the form of buttons within a business process step when using the monitoring later on inside the Business Process Monitoring session. By pressing these buttons (e.g. ), the user will jump directly into the corresponding transaction ) contains the short text (limited to
either in the SAP Solution Manager system (here: SAT) or the connected satellite system (here: CT1) for further analysis. For URLs the push-button (e.g.
page 14/32

20 characters) from the set-up session and leads the user to the defined URL in a newly opened browser window. 1.7.4.8 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 here. To ensure effective monitoring and efficient problem resolution the responsibilities should be assigned and problem resolution procedures should be defined as described in the following table. Some information is taken from the previous node Solution Support Organization. Monitoring Team Defines the team that is responsible for monitoring the relevant Monitoring object. Use value help [F4]. Defines the person who is responsible for monitoring the monitoring object. Use value help [F4]. Describes how often the responsible person should process the required monitoring activity. Describes at which time the responsible person should process the required monitoring activity. A description about what indicates a problem. Describes how to react on problems or errors, i.e. how to solve the problem/correct the error. Describes the escalation path in case that the person responsible could not solve the problem. Persons who can be contacted should be maintained here.
Person Resp.
Frequency
Start time
Problem Indicator Error handling
Escalation Path
Table 1: Responsibilities and problem resolution procedures
Additional information related to this business process step can be entered in the tables Monitoring Activities, Error Handling, Restart of Step and Escalation Path. Those information would be valid for the whole business process step and helps users who have to carry out the monitoring and who are not so familiar with that particular business process. 1.7.4.9 Notifications
Notifications can be set up for the whole business process or for each business process step individually. There are two types of notifications: Workflow notifications and support notifications. Workflow notifications allow sending messages in case of alerts to a specified recipient. This could be an e-mail or SAPOffice mail. Support notifications allow setting up a service desk message in case of an alert. The information entered for the service desk message serves as a template. The service desk message can be created manually or automatically. On business process level it is possible to define notifications for the whole business process i.e. as soon as the business process gets an alert status, notifications will be triggered. Alternative notifications can be
page 15/32

defined for every monitoring Type individually, e.g. all alerts related to all 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. 1.7.5 Business Process Monitoring Process
For a successful and efficient Business Process Monitoring concept, a process for the execution of the monitoring concept has to be defined. This includes the definition of the roles and responsibilities involved. It has to be defined who is supposed to carry out which activity within the process and how communication between the different roles within the support organization is supposed to take place. A Business Process Monitoring concept has to be tightly integrated with the support organization. This includes the integration with the Incident/Problem Management process and the Change Management process. These processes have to be adjusted to the Business Process Monitoring concept so that communication and escalation procedures contained within these processes are adequate to support the Business Process Monitoring concept. This includes the final communication of open alert 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 above mentioned separate Best Practice for General Business Process Management for further details.
page 16/32

Process execution and monitoring for a POS Analytics BI Content scenario
A retailer is using POS data management to poll, control and send sales data to SAP NetWeaver BI. POS data management is the combination of the POS Inbound Processing Engine (PIPE) and a preconfigured business content data model called POS Analytics Content in SAP NetWeaver BI. Sales transactions are usually registered at the POS system located in the stores. This information is extracted on a regular basis (ranging from every x seconds to once a day) and transferred via an EAI middleware and transformation tool (i.e. SAP PI) to POS data managements central component called PIPE (POS Inbound Processing Engine). Within this tool the incoming data is verified and posted to subsequent applications. The design of PIPE allows to process data for each subsequent application either immediately or as a bulk process with a self-defined frequency and a customized aggregation level. Apart from sales data, other data generated at the POS such as goods movements or financial transactions as well as statistical information can be transferred using the same path as the sales data. The delivered POS Analytics content data sources to extract these data to SAP NetWeaver BI are: 0RT_PA_TRAN_CONTROL 0RT_PA_TRAN_CON_REM 0RT_PA_TRAN_GDS_MOV 0RT_PA_GDS_REMOTE 0RT_PA_TRAN_MOV_FIN 0RT_PA_FIN_REMOTE 0RT_PA_TRAN_TOTALS 0RT_PA_TOTALS_REM 0RT_PA_TRAN_INDEX 0RT_PA_TRAN_LOYALTY After the extraction of the POS data to SAP NetWeaver BI, the data can be analyzed on different levels of aggregation in the predefined data targets of POS Analytics content.
2.1
Sample Scenario
To enable the POS data management solution in general, the retailer has to make specific master data available in SAP NetWeaver BI. The required master data can be for example extracted from SAP ERP for Retail (process 12 in following picture) also using standard BI business content. The retailer transfers the POS data from PIPE immediately after data consistency checks (master data check, duplicate check, sequencing gap check, transaction balancing check and totals balancing check) nonaggregated in detail to SAP NetWeaver BI to enable detailed analysis. The transactional data is put into the BI delta queue of the BI DataSource 0RT_PA_TRAN_CONTROL by PIPE task processing (process 7b in following pictures). The upload of the non-aggregated POS transaction data and the master data into the business content data targets is triggered with standard BI Data transfer processes (InfoPackages and DTPs). The retailer is analyzing the data aggregated on store/article/day level using InfoCube 0RPA_C01.
page 17/32

These upload processes (transactional & master data) should be monitored to guarantee that BI reporting shows accurate values on the following day. Following figure provides an overview of the exemplary process that will be used within this document (step 7b. update BI and step 12. transfer master data):
POS System
1. Poll Sales Data 6. Post Sales Data 2. Send Sales Data
SAP POS DM / BI System PIPE
SAP ERP for Retail
8. Post IDocs
TLOG
7a. Send IDocs 9. Post Goods Movement
7b. Update BI
10. Create Billing Document
EAI
3. Receive Information
BI Master Data
11. Create FI Document
SAP SCM F&R

4. Transform Information
12. Transfer Master Data: Sites, Articles, EAN Assignment, Unit Conversion
5. Send Information 7c. Update Sales Data
Figure 9: Overview of the exemplary process
For managing and monitoring the operations of the preceding POS Inbound processes, please refer to the generic business process documentation Manage operations for IS Retail POS Inbound under https://service.sap.com/solutionmanagerbp
2.1.1
Process Step 12: Transfer master data for POS data management to SAP NetWeaver BI Description
2.1.1.1
General information: To deliver the full set of functionality, SAP POS data management requires the availability of specific master data in SAP NetWeaver BI. In the sample scenario, this data is available in SAP ERP for Retail and can be uploaded into SAP NetWeaver BI using standard IS Retail Business Content extractors (except for 0RPA_MEAN and 0RPA_MARM; follow SAP Note 835111). The following InfoObjects are required by POS data management
page 18/32

BW Info Object
0MATERIAL 0PLANT 0RPA_MARM 0RPA_MEAN 0MAT_PLANT or DSO 0RT_DS01 0SALESORG 0COMP_CODE 0FISCPER & 0FISCVARNT
Description
Material (article) Plant (store) Units of measure for article EAN assignment to article Plant material Product and Location Attributes Sales Organisation Company Code Fiscal Period Fiscal Year Variant
Remarks
extraction of Attributes extraction of Attributes extraction of Attributes extraction of Attributes without data extraction, only activate the Info Object DSO activated from Business Content extraction of Attributes extraction of Attributes Maintained in customizing table
Table 2: InfoObjects required by POS data management
Legend: Mandatory for PIPE dependant on used material level handled by POS DM Mandatory for PIPE to be available in active version; availability of data not mandatory Not mandatory for PIPE, but used in SAP NetWeaver BI dataflow form POS Analytics DataSources upwards
Even if SAP does not deliver preconfigured process chains for the POS Analytics business content, it is highly recommended to create process chains to upload the master data from ERP for Retail on a daily base before the transactional data are uploaded.
page 19/32

Figure 10: Example for daily master data process chains setup
This example process chain executes InfoPackages to upload all necessary master data InfoObject attributes in the correct sequence. The attribute change run as final step of the process chain executes the master data modificatons on the SAP BW reporting layer in case of changed master data attributes. The transactional data flow in SAP NetWeaver BI is referring to some of the mentioned InfoObjects in a way that will be described in more detail. If the master data are not updated regularly, the risk of erroneous data uploads is high. Additionally, PIPE is executing master data lookups to check and enrich the transactional POS data internally. As master and transactional data staging can not be handled individually regarding the functionality of POS data management, a regular monitoring of the master data uploads is mandatory to establish a stable system environment (find further details in the following chapter Error, Throughput and Backlog Monitoring). If a customer is using customer InfoObjects instead of the delivered standard InfoObjects, it is necessary to set up the PIPE as described in SAP Note 732579 The following InfoObjects are used internally in PIPE or in the data flow.
page 20/32

0FISCPER & 0FISCVARNT are used in the start routines and the field routines that are mapped between the source field BUSINESSDAYDATE and the target fields 0FISCPER and 0FISCVARNT of the transformations between the DataSources 0RT_PA_TRAN_CONTROL, 0RT_PA_TRAN_GDS_MOV, 0RT_PA_TRAN_MOV_FIN and 0RT_PA_TRAN_TOTALS and their assigned InfoSources. During the upload of the transactional data to the data targets, the delivered coding tries to execute the method rtf/cl_time=>get_retail_fpers_from_date to derive a valid fiscal variant and period from the table /MAP/TC_FISCYV. The maintenance of these values can be executed in the BI customizing cockpit with transaction SPRO under the path IMG, SAP NetWeaver, Business Intelligence Settings for Business Content Trade Industries, Retailing, Set Fiscal Year Variant. Valid values can be checked and maintained using the transaction code OB29. If no valid fiscal periods and variants can be derived during the data upload, the upload will fail with an error. See SAP Note 782745. 0MAT_PLANT or DSO 0RT_DS01 have to be available in active version to use the full functionality of POS data management. These objects are used to enrich the moving average cost price on store article level in SAP NetWeaver BI. In the start routine of the transformation between the DataSource 0RT_PA_TRAN_CONTROL the FM
RSBCT_RPA_MOVING_AVERAGE_GET is called that tries to get the moving average cost price from InfoObject
0MAT_PLANT or the DSO 0RT_DS01 (the specific target has to be specified in the customizing cockpit /nSPRO under the path IMG, SAP NetWeaver Business Intelligence Settings for Business Content, Trade Industries, Trade Foundation, General Settings). If this routine fails, the processed data package will raise and error or warning. It is possible, to influence the system behavior in that area by maintaining the BI customizing cockpit under the same path. When the missing data for article and plant - critical flag is set, the executed data upload will raise an error. If it is not flagged, only a warning is given and the data are available in the data targets for reporting. See SAP Notes 1159170, 819464, 1120082 and 1253582. 0MATERIAL is a mandatory InfoObject in SAP NetWeaver BI that is used internally in PIPE to execute the master data check and to enrich additional data in PIPE related to the article. In the standard, PIPE is reading the attribute 0BASE_UOM to check whether the article sales unit combination in the transactional data is valid. The attribute 0MATL_GROUP is read for each SAP article number and enriched into the transactional data. The PIPE customizing allows the user a setup, which does not execute that check in the described detail (/n/POSDW/IMG under path general setting, master data filter and checks using check profiles flag). It is possible to turn the master data check off in general or for each check profile (under path Check Profiles). In case that the master data check is not executed, the PIPE will enrich automatically the PIPE field material number with the value of the field itemid in case that the itemidqualifier was set to SAP article number. The same enrichment will be executed into the field merchandisecategory in case that the itemidqualifier was set to SAP Material group. It is necessary to customize the parameter group in the PIPE customizing /n/POSDW/IMG under path Tasks, One step processing, define parameters for tasks for parameter profile 0006 Master Data Check for the parameters for task, NO_CHECK_FOR_MATERIAL in that way, that no checks are executed for the material. This parameter profile must be assigned to the task supply BW. Please refer for further details to SAP Notes 811393 and 1273520
page 21/32

The InfoObject 0PLANT is mandatory in SAP NetWeaver BI in a similar way as described for 0MATERIAL. PIPE is internally checking the attribute 0LOC_CURRCY to enrich the store currency into the transactional data. An error occurs in PIPE internally only, if the parameter group in the PIPE customizing /n/POSDW/IMG under Tasks, One step processing, Define Parameters for Tasks for Parameter Profile 0006 Master Data Check for the parameters for task NO_CHECK_FOR_STORE_CURRENCY is maintained in that way, that no checks are executed for the plant. This parameter profile must be assigned to the task supply BW. The validity of the store is checked in PIPE by reading the attribute 0RT_CUSTPL and comparing the value with the transactional data value in the PIPE field RETAILSTOREID. If 0PLANT does not get a value for the attribute 0LOC_CURRCY from the extract on 0PLANT_ATTR, the field routine of the transformations on 0PLANT raises a warning message when the try fails to get a store currency by reading the attribute from 0SALESORG and 0COMP_CODE. Therefore it is also necessary to load information to the Company Code and Sales Organisation InfoObject. Please refer for further details to SAP Notes 811393 and 1273520 0RPA_MARM and 0RPA_MEAN are InfoObjects that are used by PIPE in case that EANs are delivered from the POS system. PIPE delivers the standard functionality to enrich for EANs the SAP article number and SAP material group by executing a lookup in 0RPA_MEAN. Additionally, PIPE recalculates the quantities sold in base unit of measure by looking up in 0RPA_MARM. Like this, sales data can be delivered in sales and base units of measure to SAP NetWeaver BI. As the business content in SAP ERP for Retail and SAP NetWeaver BI does not deliver preconfigured extractors, please follow SAP Note 835111 to create own generic master data extractors for 0RPA_MEAN). For InfoObject 0RPA_MARM the DataSource 0MAT_UNIT_ATTR can be used to feed the necessary attributes to the InfoObject. For further details about master data staging in SAP NetWeaver BI, please refer to the generic Run SAP Best Practices for Solution Management documentation SAP BW Master Data Upload, Operational Data Storage Upload with BW 3.x and SAP BW 3.x Data Target Upload under https://service.sap.com/solutionmanagerbp. Error, Throughput and Backlog Monitoring: For successfully executed checks of POS data in PIPE and the processing into the POS Analytics content data targets the availability of up to date and correct master data is mandatory. Sample Scenario specific: The master data upload of the described InfoObject attributes must be executed successfully before transactional POS data can be uploaded to SAP NetWeaver BI. The master data are extracted from the source system by executing the InfoPackages of the corresponding DataSources and the DTPs into the InfoObjects. The following monitors and tools are important for data staging: Upload Monitor: To have an overview about all upload processes running on your BW system, you should use the Upload Monitor (transaction RSMO). In the detail monitor of each request (upload process) the progress of this upload and the single process steps are shown. Process Chain Overview: For the application-side analysis of the processes executed via process chain you can use the Process Chain Overview (transaction RSPC). Here you have an overview about the
page 22/32

progress of your process chains and which processes are taking place at the moment. You see an overview about the process steps done so far for each process. From here, you can jump to more detailed monitors of single processes (Open Hub Monitor, Upload Monitor) or to the job log of the processes. Changerun Monitor: For problems with changeruns you can use the monitor for changeruns (transaction CHANGERUNMONI). Open Hub Monitor: For problems with Open Hub Service and InfoSpokes you can use the Open Hub Monitor. Similar to the Upload Monitor the Open Hub Monitor shows the progress of each request and the single process steps. Performance Monitoring: To ensure a high availability of master data, it can be useful to regularly check the system performance during the upload execution. For further details please refer to the generic Run SAP - Best Practices for Solution Management documentation Periodic Jobs and Tasks in SAP BW under https://service.sap.com/solutionmanagerbp. 2.1.1.2 Monitoring objects Analysis Tool on Satellite System RSPC Monitoring Frequency / Data Collection during InfoPackage and DTP execution during InfoPackage and DTP execution during InfoPackage and DTP execution
Monitoring Object
Master data upload process chains
Master data upload
RSMO
Change run execution after master data upload
CHANGERUNMONI
Table 3: Transfer master data Monitoring objects
2.1.1.3
Error handling per monitoring object
If the upload of the master data process chains is failing, the reason for the error can be found by using the following analyzing tools Monitoring Object Analysis tool on satellite system Monitoring frequency / data collection after InfoPackage and DTP execution after InfoPackage and DTP execution
System Log
SM21
ABAP Runtime Errors
ST22
Table 4: Transfer master data Error handling per monitoring object
page 23/32

Further details about monitoring tools in SAP NetWeaver BI are available as generic Run SAP - Best Practices for solution management documentation in https://service.sap.com/solutionmanagerbp under Monitoring for BI Basis (ABAP and Java), Monitoring for BI Reporting and Background Job monitoring with SAP Solution Manager 2.1.2 Proc. step 7b: Update transactional POS data for POS data management to SAP NetWeaver BI Description
2.1.2.1
General information: A POS generates different types of transactions like sales transactions, goods movements and financial transactions as well as statistical information. The design of PIPE allows to process these data to SAP NetWeaver BI either immediately or as a bulk process with a self-defined frequency and a customized aggregation level. The PIPE data are transferred to the BI delta queues of the following POS Analytics DataSources: 0RT_PA_TRAN_CONTROL (sales transactions) 0RT_PA_TRAN_GDS_MOV (goods movements) 0RT_PA_TRAN_MOV_FIN (financial transactions) 0RT_PA_TRAN_TOTALS (statistical information) Since SAP NetWeaver BI CONT 7.03 SP6, this data is extracted to the PSA tables of the DataSources using transformations. The POS Analytics content delivers preconfigured data flows for the DataSources 0RT_PA_TRAN_CONTROL and 0RT_PA_TRAN_TOTALS on InfoSource and InfoCube (MultiCube) level. For the DataSources 0RT_PA_TRAN_GDS_MOV and 0RT_PA_TRAN_MOV_FIN, data flows are available to InfoSource level. The upload from the PSA tables to the InfoCubes is executed by DTPs via preconfigured transformations. In the transformation between the DataSource and its corresponding InfoSource, the logic for the key figure calculation is encapsulated in ABAP service classes. The instantiation of the trade foundation service classes are called in the start routine of the transformation. Additionally each key figure simply calls a the same method with a unique key figure name. Depending on the key figure name a different calculation logic is executed. It is possible to create own implementations for service classes for own key figures. Using this concept has the benefit, that established and productive data flows for transactional data will not get inactive, when content or development changes are imported into the SAP NetWeaver BI system (for further details, please refer to the following document: How to Use Service Classes for Keyfigure Transformations (http://service.sap.com/~sapidb/011000358700000194902009E). After the upload of the transactional data into the InfoCubes, analyses of the POS data can be executed on different levels and views using content queries. The POS Analytics content delivers reporting possibilities on cashier, receipt, and store/article (day/week/month) level. For further information please see SAP Note 811393.
page 24/32

Sample scenario specific information: Sales data delivered from POS are sent from PIPE to the SAP NetWeaver BI delta queue 0RT_PA_TRAN_CONTROL. The transactional data is extracted from the BI delta queue into the InfoCube 0RPA_C01 (store/article/day)
Figure 11: Process chain
Even if SAP does not deliver preconfigured process chains for the POS Analytics business content, it is highly recommended to create process chains to upload the transactional data regularly from the delta queue into the POS Analytics InfoCube after the master data loads are executed. Example for a regularly executed transactional data process chains setup:
page 25/32

Figure 12: Example for a regularly executed transactional data process chains setup
As POS data management is designed to handle huge volumes of transactional data generated at POS and the volumes of data transferred into SAP NetWeaver BI are critical. So a regular monitoring of the transactional data uploads is mandatory to establish a stable system environment (please refer to the described monitoring tools in chapter Error, Throughput and Backlog Monitoring). Because of these huge volumes, a detailed view on the used staging areas in SAP NetWeaver BI is useful to decide measure to avoid critical redundancies and to enable a performing data upload, staging and reporting process in SAP NetWeaver BI. BI delta queue The transactional data from PIPE are stored in the delta queue to establish a delta scenario to upload unprocessed data to the PSA table. Please pay attention that a full upload is not supported to update the SAP NetWeaver BI data targets from PIPE. To establish the delta queue, it is mandatory to create and execute at the first time an InfoPackage to initialize the delta process without data transfer.
Figure 13: Initialize delta process
page 26/32

After the delta queue is initialized, the deltas are uploaded to the PSA table with a separate InfoPackage for delta upload.
Figure 14: Delta update
PSA table The persistent staging area table is keeping the original transactional data from the SAP NetWeaver BI delta queue. The PSA table ensures an easy reprocessing of data into InfoCubes or other data targets without the need of affecting other source systems in case that data have been processed incorrectly or have been deleted. InfoCube The InfoCube is storing the data on the required level for long term usage for reporting. The scenario InfoCube 0RPA_C01 is storing POS data on the level store/article/day. Two additional InfoCubes are storing the data on higher timely aggregation (week and month). Recommendations As POS data management processes high volume data, a concept for avoiding redundancies and retention periods is mandatory. A detailed view, for how long time data have to be kept in the delta queue and the PSA table can support the customer in avoiding large overheads in the processing and staging of POS data. Integrating a corporate memory DSO (1:1 copy of the PSA table for mid term storage) or near line storage solutions can completely avoid performance issues during data processing in the whole POS Analytics data flow. The retention period of POS data to be available in PIPE must be taken into consideration dependant on the quality of data delivered in a production environment (the more erroneous data from POS, the longer the retention period in PIPE). The InfoCubes should not store more then 100 million records when the classic reporting environment is in use. If a BIA (SAP NetWeaver BI Accelerator) is available, the InfoCube can easily manage much more data.
page 27/32

2.1.2.2
Monitoring requirements:
Backlog monitoring: To get a good overview over the data staging and database performance situation of the system, the usage of monitoring tools is helpful. Sample scenario specific: Check the data upload and staging performance for the delta queue and PSA table of DataSource 0RT_PA_TRAN_CONTROL and InfoProvider 0RPA_C01. Monitor the execution of the InfoPackage that transfers the data from the BW delta queue into the 0RT_PA_TRAN_CONTROL PSA table and the DTP that transfers the transactional data form the PSA table to the InfoCube 0RPA_C01 Performance Monitoring: To ensure a high availability of transactional data, it can be useful to regularly check the system performance during the upload execution. To optimize the system performance, please refer to the described details in the generic Run SAP Best Practices for Solution Management documentation and Background Job monitoring with SAP Solution Manager chapters: Performance Data management 2.1.2.3 Monitoring Objects Analysis Tool on Satellite System
RSPC RSMO
Monitoring Object
Transactional Data upload process chains Transactional Data upload
Monitoring Frequency/ Data Collection

during InfoPackage and DTP execution during InfoPackage execution and DTP
Table 5: Update transactional POS data Monitoring objects
2.1.2.4
Error handling per monitoring object
If the upload of the transactional data process chains is failing, the reason for the error can be found by using the following analyzing tools Monitoring Object Analysis Tool on Satellite System SM21 ST22 Monitoring Frequency/Data Collection
System Log ABAP Runtime Errors
after InfoPackage and DTP execution after InfoPackage and DTP execution
Table 6: Update transactional POS data Error handling per monitoring object
page 28/32

Further details about monitoring tools in SAP NetWeaver BI are available as generic Run SAP Best Practices for Solution Management documentation in https://service.sap.com/solutionmanagerbp under Monitoring for BI Basis (ABAP and Java), Monitoring for BI Reporting and Background Job monitoring with SAP Solution Manager
page 29/32

3
3.1
Further Information
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 c concept. This includes the definition and documentation of the core business processes, definition of monitoring objects, definition of monitoring activities including error handling procedures, monitoring tools, monitoring frequencies, the definition of communication and escalation procedures and the assignment of responsibilities. ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus on ALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitor ALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoring approaches aim to detect any irregularities or deviations or to detect error situations at an early stage. Job Scheduling Management: This Best Practice provides a detailed description what SAP recommends as a standardized formal process to support a job request process, including an end user job request form and an approval process. This integrated process will avoid error-prone and time intensive manual processes of copying redundant data from one data source to another (for example, MS excel to MS Excel or MS Excel to job scheduling tool). SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a Business Process Monitoring concept for your SAP ERP solution. The concept aims to define procedures for business process oriented monitoring and error handling and escalation procedures for your companys ERP core business processes. These procedures intend to ensure a smooth and reliable flow of the core business processes so that your business requirements are met. Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set up background job monitoring properly in the framework of Business Process Monitoring in the SAP Solution Manager. Please note that these documents are also available in the SAP Service Marketplace using alias RunSAP RunSAP Best Practices.
3.2
Background Information and References
How to Use Service Classes for Keyfigure Transformations available under: http://service.sap.com/~sapidb/011000358700000194902009E
page 30/32

Index of Figures
Figure 1: Monitoring alert types Figure 2: Monitoring objects dialog performance Figure 3: Monitoring alerts dialog performance Figure 4: Monitoring objects update errors Figure 5: Monitoring objects and alerts - application log Figure 6: Monitoring alert application log/critical messages Figure 7: Analysis & monitoring transactions Figure 8: Analysis & monitoring url Figure 9: Overview of the exemplary process Figure 10: Example for daily master data process chains setup Figure 11: Process chain Figure 12: Example for a regularly executed transactional data process chains setup Figure 13: Initialize delta process Figure 14: Delta update 9 10 10 11 12 13 14 14 18 20 25 26 26 27
Index of Tables
Table 1: Responsibilities and problem resolution procedures Table 2: InfoObjects required by POS data management Table 3: Transfer master data Monitoring objects Table 4: Error handling per monitoring object Table 5: Update transactional POS data Monitoring objects Table 6: Error handling per monitoring object 15 19 23 23 28 28
page 31/32

Copyright 2009 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered tradem arks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are tradem arks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreem ent with SAP. This document contains only intended strategies, developments, and functionalities of the SAP product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or noninfringem ent. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.
page 32/32

Bestpractice Pos Analytics

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Bestpractice Pos Analytics

Enviado por

Direitos autorais:

Formatos disponíveis

Best Practice for Solution Operations

Manage Operations for POS Data Management POS Analytics Content

Dietmar-Hopp-Allee 16 D-69190 Walldorf

Operations & Continuous Improvement Best Practices for Solution Operations

Application & Integration Management Business Process Operation

Best Practice for Solution Operations

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Staff and Skills Requirements

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Duration and Timing

How to Use this Best Practice

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Best Practice Procedure

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Throughput and Backlog Indicators (TBIs)

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Figure 1: Monitoring alert types

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Figure 2: Monitoring objects dialog performance

Figure 3: Monitoring alerts dialog performance

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Figure 4: Monitoring objects update errors

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Figure 5: Monitoring objects and alerts - application log

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Figure 6: Monitoring alert application log/critical messages

Analysis and monitoring tools

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Figure 7: Analysis & monitoring transactions

Figure 8: Analysis & monitoring url

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Problem Indicator Error handling

Table 1: Responsibilities and problem resolution procedures

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

Process execution and monitoring for a POS Analytics BI Content scenario

2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc

Best Practice for Solution Operations

SAP POS DM / BI System PIPE

SAP ERP for Retail

7a. Send IDocs 9. Post Goods Movement

10. Create Billing Document

11. Create FI Document

SAP SCM F&R

5. Send Information 7c. Update Sales Data

Figure 9: Overview of the exemplary process