Bestpractice Pos Analytics

BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc – 24.04.2009

Best Practice for Solution Operations

Manage Operations forPOS Data ManagementPOS Analytics Content

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUS

customer publishedDATE VERSION

Mar-19, 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 Operation

Best Practice for Solution OperationsManage Operations for SAP POS Data Management - POS Analytics Content

© 2009 SAP AG - BP_MO_for_POS-DataMgmt_POS-AnalyticsContent_V30.doc page 2/32

Table of Contents1 Management Summary 3

1.1 Goal of Using this Best Practice 31.2 Alternative Practices 31.3 Staff and Skills Requirements 31.4 System Requirements 41.5 Duration and Timing 41.6 How to Use this Best Practice 41.7 Best Practice Procedure 5

1.7.1 Preliminary tasks 51.7.2 Monitoring Concepts 51.7.3 Business Process Monitoring in SAP Solution Manager 51.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 6

1.7.4.1 Application Monitor 71.7.4.2 Background Job 71.7.4.3 ABAP Dump Collector 81.7.4.4 Dialog performance 91.7.4.5 Update errors 111.7.4.6 Application Log 121.7.4.7 Analysis and monitoring tools 131.7.4.8 Monitoring activities 151.7.4.9 Notifications 15

1.7.5 Business Process Monitoring Process 162 Process execution and monitoring for a POS Analytics BI Content scenario 17

2.1 Sample Scenario 172.1.1 Process Step 12: Transfer master data for POS data management to SAP NetWeaver BI 18

2.1.1.1 Description 182.1.1.2 Monitoring objects 232.1.1.3 Error handling per monitoring object 23

2.1.2 Proc. step 7b: Update transactional POS data for POS data management to SAP NetWeaver BI 242.1.2.1 Description 242.1.2.2 Monitoring requirements: 282.1.2.3 Monitoring Objects 282.1.2.4 Error handling per monitoring object 28

3 Further Information 303.1 Related Best Practice Documents 303.2 Background Information and References 30

Index of Figures 31Index of Tables 31



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 POS data managementsolution. The concept aims to define procedures for business process oriented monitoring and error handlingand escalation procedures for your processes in POS analytics content. These procedures intend to ensure asmooth and reliable flow of this core business process so that your business requirements are met.

This Best Practice gives orientation for defining suitable application oriented monitoring objects in order todetect any irregularities or deviations from an ideal business process flow or to detect error situationsconcerning a core business process at an early stage.

This Best Practice contains the recommended approach from SAP which uses whenever possible the SAPSolution Manager for the Monitoring functionalities. But even if you do not use the SAP Solution Manager werecommend to follow the procedures described in this document as much as possible in order to ensure asmooth and reliable flow of your business processes as well as an appropriate response in case ofunforeseen errors.

1.2 Alternative Practices

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

1.3 Staff and Skills 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 areasof 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 derivedfrom 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)



SAP Technology Operations Team

All parties in your solution support organization and IT department involved in monitoring focused on thesystem administration side (program scheduling management, software monitoring team, systemadministration team including the System Administrator)

Business process champion

The business process champion is the person in the business department that is responsible for thesuccessful execution of the business process. He coordinates all activities necessary for the businessprocess. Therefore, he is usually responsible for the escalation paths in case of problems. Often he is asecond level in the escalation procedure, if the application monitoring team needs to escalate an issue.

More information about roles and responsibilities of these teams can be found in the super-ordinate BestPractice General Business Process Management, which you can obtain through SAP Solution Manager orthe SAP Service Marketplace, quicklink /BPM.

Necessary or useful trainings

SM300 Business Process Management and MonitoringE2E300 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, theSAP basis release of the systems to be monitored have to be at least 4.6C. To have all described monitoringobjects available in SAP Solution Manager, the add-on ST-A/PI 01L has to be installed on the SAPNetWeaver BI system.

1.5 Duration and Timing

Duration

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 ofyour 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 BusinessProcess Management concept. This includes the definition and documentation of the core businessprocesses, definition of monitoring objects, definition of monitoring activities including error handlingprocedures, monitoring tools and monitoring frequencies, the definition of communication and escalationprocedures and the assignment of responsibilities.



At the beginning of Chapter 2 you will find a typical flow chart of the core business process explained inthis Best Practice. It is intended to be used as a guideline for writing down your company specific processdocumentation.

In Chapter 1.7.4 you find further information that is relevant for more than one scenario. In caseinformation from the generic part is relevant for a specific business process step in one of the scenariosyou 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 thesystem: Complete all installation and post-installation actions and procedures including customizing Ensure that the initial download has been successfully executed Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations resulting

from customer problem messages Implement all current 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. Themonitoring procedures help you to ensure that the technical processes meet the requirements for stability,performance and completeness. These procedures cover monitoring for the five areas: Error monitoring Performance monitoring Throughput monitoring 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 inChapter 1.7.4. Recommendations for performance monitoring can also be found in this chapter. Theperformance of the most important steps of your core business processes should be monitored on a regularbasis. The monitoring procedure for performance monitoring of all steps that are executed in an SAPNetWeaver BI solution is generally the same. Therefore, you will only find specific performance monitoringrecommendations on selected business process steps.

1.7.3 Business Process Monitoring in SAP Solution 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 alltechnical and business application specific functions that are required for a steady and stable flow of thebusiness processes.



The core business processes that are implemented in a SAP NetWeaver BI system or other software andoperated by a company are of particular importance, and Business Process Monitoring is intended to ensurea smooth and reliable operation of the business processes and, thereby, that the core business processesmeet a company’s business requirements in terms of stability, performance, and completeness. The SAPSolution Manager provides a graphic to visualize a company’s (distributed) system and solution landscapeand all related business processes. By using Business Process Monitoring, it is possible to define andcustomize 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 processstep in the graphical business process representation. Business Process Monitoring is intended to detect andrespond 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 intothe company’s overall strategy for Business Process Management and Solution Management within theirSolution Support Organization.

In general, a Business Process Monitoring includes the solution-wide observation of: Business process performance (Key Performance Indicators) Background jobs (Job Scheduling Management tasks) Business application logs (such as any error log, general application log, due list logs etc.) Data transfer via interfaces between software components Data consistency Technical infrastructure and components which are required to run the business processes Required periodic monitoring 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 SAPSolution Manager. The below mentioned Monitoring Types are available: Application Monitor (Throughput and Backlog Indicators, Data Consistency Checks, Mass Activity

Monitors, Due List Log, MRP key figures, User Exit) Background Jobs (Jobs running on SAP Systems with an SAP Basis) Dialog Performance (Dialog transaction performance) Update Error (V1 and V2 update errors from SM13 for specific transactions and programs) Due List Log (messages for deliveries and billings) Application Log (messages from the Application Log SLG1) Document Volume (based on table call statistics in ST10) Other CCMS Monitor (all alerts that are configured in the CCMS Alert Monitor)

Depending on what is executed during a specific business process step the relevant monitoring types mustbe selected. In order to receive detailed information on how to set up the monitoring objects in the SAPSolution Manager, please refer to the documentation that is available under http://service.sap.com/bpm.

One prerequisite for setting up Business Process and Interface Monitoring in the SAP Solution Manager isthat all business processes and business process steps are maintained in the respective solution that

http://service.sap.com/bpm.

http://service.sap.com/bpm.



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) 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 ProcessMonitoring. The latest monitoring objects are only provided if the latest ST-A/PI plug-in is installed on thesatellite system. The service tool for ST-A/PI is available via the SAP Service Marketplace quick link/installations Entry by Application Group Plug-Ins SAP Solution Tools ST-A/PI.

Please ensure that the ST-A/PI is installed on the SAP Solution Manager system and on the respectivesatellite 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 ST-SER release is 700_2007_1.

More detailed information about the different Application Monitor functionalities and a detailed description onhow to define self-written monitoring collectors for the user exit are explained in the documents Setup Guide– Application Monitoring and Setup Guide – User Exit respectively (URL http://www.service.sap.com/ AliasBPM Media Library).

1.7.4.1.1 Throughput and Backlog Indicators (TBIs)

As of ST-A/PI 01H a completely new set of Application Monitors has been introduced. While the alreadyestablished monitors are all evaluating specific logs or performance data these new monitors are considering(un-)processed documents in the SAP system and provide so called throughput and backlog indicators.

These TBIs should especially provide Automated and early detection of application error situations and backlogs in the core business processes Automated error and backlog analysis 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 witherror, confirmation pool errors)Plant maintenance (e.g. PM/CS Notifications, PM/CS Orders)

For further information on the different TBIs refer to the document Setup Guide – Application Monitoring (URLhttp://www.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 (go tohttp://service.sap.com/solutionmanagerbp Topic Area Business Process Operations to find a Best Practicedocument Job Scheduling Managemen’). Because of several restrictions regarding background job

http://help.sap.com)/

http://www.service.sap.com/

http://www.service.sap.com/BPM

http://service.sap.com/solutionmanagerbp



scheduling, e.g. time restrictions, restriction of hardware resources (CPU, main memory, …) or existingdependencies between different activities (e.g. invoices can only be created after the corresponding goodsissue is posted, or back order processing and material requirements planning should not run at the sametime) it is very important to ensure the stable run of background jobs. A cancelled background job should beidentified as soon as possible in order to react as fast as possible. Therefore it is also necessary to definerestart procedures and escalation paths.

Monitoring Objects

Before setting up monitoring the monitoring objects must be clearly defined. A monitoring object is a singlebackground job or a group of background jobs. There are four different possibilities to identify a specialbackground job or a group of background jobs. This information needs to be maintained in the sub-nodeBackground Job below a business process step.

A more detailed description (than provided in this document) on the subject what kind of alerts make sense orwhat kind of alerts are possible are discussed in the Best Practice document Background Job Monitoring withSAP Solution Manager which can be found on the SAP Marketplacehttp://service.sap.com/solutionmanagerbp Topic Area Business Process Operation.

1.7.4.3 ABAP Dump Collector

To provide monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors or tocollect 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 errorname, the user who is responsible for the runtime error, the Client on which the runtime error occurs or theProgram which leads to the runtime error.

Monitoring Alerts

Possible alerts types are the number of ABAP Dumps (Delta) – all dumps since the last collector run – andnumber of ABAP Dumps (Reporting) – all runtime errors of specified type, client and program for this day orfor the previous day.

http://service.sap.com/solutionmanagerbp



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 theSAP 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 removetransactions within table Add/Remove Transactions. The monitoring can be performed per SAP instance.Therefore the respective instances have to be selected in table SAP Instances. All instances that aremaintained for a system are listed there. Table Alert Types shows the dialog response time and all parts ofthe response time, like queue time, load and generation time, database request time and the front-endresponse time, that can be monitored. Those times that are relevant for monitoring have to be selected.

After saving this node a sub-node Performance Alerts will appear where the threshold values have to beentered.



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-levelnode, and lists the combinations of specified transaction code and SAP instance.

For each combination of transaction code and instance that should be included in the monitoring, thethreshold values resulting in alert messages for changes from GREEN to YELLOW, from YELLOW to RED,back from RED to YELLOW, and back from YELLOW to GREEN have to be specified.

Since the monitoring object for performance monitoring is created on the satellite system, it might be possiblethat the object already exists there. Therefore you can load the current threshold values from the respectivesystems via the button Load thresholds from XYZ, whereas XYZ represents the SID.

If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for thethreshold values were found for a certain transaction code, default values are set (indicated in columnDefault). To transfer the threshold values for a single line from right to left, the copy icon can be used. Totransfer all at once (all thresholds for all columns and tables) there is an additional button "Copy all".

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 in fullor not at all. If the operation is canceled while the transaction is being executed, or if an error occurs, thetransaction should not make any changes to the database. These activities are handled by the SAP updatesystem.

The SAP system makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2)update errors. This distinction allows the system to process critical database changes before less criticalchanges.

V1 modules describe critical or primary changes; these affect objects that have a controlling function in theSAP system, for example order creation or changes to material stock.

V2 modules describe less critical secondary changes. These are pure statistical updates, for example, suchas result calculations.

Monitoring objects

Monitoring of update errors can be configured for online transactions and/or ABAP programs relevant in abusiness process. This is the object type. The name of the object is the name of a transaction or the name ofthe ABAP program itself. If desired a user executing the transaction or the ABAP program can be specified.If no user is specified explicitly, all users (represented by '*') will be considered in monitoring data evaluation.

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 oneupdate error occurs. This is valid for V1 and for V2 update errors. To raise a red alert for a V1 or a V2 updateerror a threshold must be specified.

1.7.4.6 Application Log

The application log provides an infrastructure for collecting messages, saving them in the database anddisplaying them as a log. Situations can arise at runtime in application programs that must be brought to theattention of the user in some way. These are usually errors. It can also be useful to report a successfulcompletion. The information that arises is called a message. The set of messages is a log. A log usually alsohas header information (log type, creator, creation time, etc.). A transaction can generate several logs. Theapplication 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 allother 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 ofmessages that raises a YELLOW alert and the number of messages changing from a YELLOW to a REDalert must be maintained.

It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs. Toconfigure the monitoring of critical application log messages, the relevant object-sub object combinationsneed to be selected. For each of these combinations the message type, the message ID and the messagenumber as well as the threshold values for the number of critical messages that are supposed to result in



changes from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wildcards.

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 monitoringobject. In case of analysis transactions these should be used to analyze errors or problems either locally inthe SAP Solution Manager system itself (Call Option “1”) or directly in the respective satellite systems (CallOption “2”). Per default some standard transactions are maintained, e.g. transaction SM37, that provides ajob overview in an SAP system, is maintained for background jobs or transaction SLG1 to have a look into theapplication log.

It is also possible to add new transactions; this could be standard transactions or customer self-writtentransactions.



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 thegiven problem. This is especially interesting if you have some knowledge documents linked to a portal. Youdefine a short text and the URL to be called.

For web pages to be called, specify the full URL, e.g. http://help.sap.com. For content available on fileservers 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 stepwhen 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 transactioneither 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. ) contains the short text (limited to

http://help.sap.com./



20 characters) from the set-up session and leads the user to the defined URL in a newly opened browserwindow.

1.7.4.8 Monitoring activities

Monitoring activities should be set up for every monitoring object within a business process step. Allmonitoring objects defined within a business process step are listed here. To ensure effective monitoring andefficient problem resolution the responsibilities should be assigned and problem resolution procedures shouldbe defined as described in the following table. Some information is taken from the previous node SolutionSupport Organization.

Monitoring Team Defines the team that is responsible for monitoring the relevant Monitoringobject. Use value help [F4].

Person Resp. Defines the person who is responsible for monitoring the monitoring object. Usevalue help [F4].

Frequency Describes how often the responsible person should process the requiredmonitoring activity.

Start time Describes at which time the responsible person should process the requiredmonitoring 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 theproblem/correct the error.

Escalation Path Describes the escalation path in case that the person responsible could notsolve the problem. Persons who can be contacted should be maintained here.

Table 1: Responsibilities and problem resolution procedures

Additional information related to this business process step can be entered in the tables MonitoringActivities, Error Handling’, Restart of Step and Escalation Path. Those information would be valid for thewhole business process step and helps users who have to carry out the monitoring and who are not sofamiliar with that particular business process.

1.7.4.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 notificationsallow sending messages in case of alerts to a specified recipient. This could be an e-mail or SAPOffice mail.Support notifications allow setting up a service desk message in case of an alert. The information entered forthe service desk message serves as a template. The service desk message can be created manually orautomatically.

On business process level it is possible to define notifications for the whole business process i.e. as soon asthe business process gets an alert status, notifications will be triggered. Alternative notifications can be



defined for every monitoring Type individually, e.g. all alerts related to all background jobs of the businessprocess are forwarded to a defined e-mail address.

Notifications defined on business process step level will overrule the configuration made on business processlevel for this particular step.

1.7.5 Business Process Monitoring Process

For a successful and efficient Business Process Monitoring concept, a process for the execution of themonitoring concept has to be defined. This includes the definition of the roles and responsibilities involved. Ithas to be defined who is supposed to carry out which activity within the process and how communicationbetween 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. Thisincludes the integration with the Incident/Problem Management process and the Change Managementprocess. These processes have to be adjusted to the Business Process Monitoring concept so thatcommunication and escalation procedures contained within these processes are adequate to support theBusiness Process Monitoring concept. This includes the final communication of open alert to SAP.

Wherever communication connected with Business Process Monitoring happens outside these supportprocesses, separate communication and escalation paths and procedures have to be defined.

Please see the above mentioned separate Best Practice for General Business Process Management forfurther details.



2 Process execution and monitoring for a POS Analytics BI Contentscenario

A retailer is using POS data management to poll, control and send sales data to SAP NetWeaver BI. POSdata management is the combination of the POS Inbound Processing Engine (PIPE) and a preconfiguredbusiness 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 isextracted on a regular basis (ranging from every x seconds to once a day) and transferred via an EAImiddleware and transformation tool (i.e. SAP PI) to POS data management’s central component called PIPE(POS Inbound Processing Engine). Within this tool the incoming data is verified and posted to subsequentapplications. The design of PIPE allows to process data for each subsequent application either immediatelyor 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 statisticalinformation can be transferred using the same path as the sales data. The delivered POS Analytics contentdata 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 ofaggregation 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 dataavailable in SAP NetWeaver BI. The required master data can be for example extracted from SAP ERP forRetail (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) non-aggregated in detail to SAP NetWeaver BI to enable detailed analysis. The transactional data is put into theBI delta queue of the BI DataSource 0RT_PA_TRAN_CONTROL by PIPE task processing (process 7b infollowing pictures).

The upload of the non-aggregated POS transaction data and the master data into the business content datatargets is triggered with standard BI Data transfer processes (InfoPackages and DTP’s).

The retailer is analyzing the data aggregated on store/article/day level using InfoCube 0RPA_C01.



These upload processes (transactional & master data) should be monitored to guarantee that BI reportingshows accurate values on the following day.

Following figure provides an overview of the exemplary process that will be used within this document (step7b. update BI and step 12. transfer master data):

SAP POS DM / BI System

PIPE

EAI

SAP ERP for RetailPOS System

2. Send Sales Data

1. Poll Sales Data

SAP SCM F&R4. Transform Information

3. Receive Information

5. Send Information

6. Post Sales Data

8. Post IDocs

7a. Send IDocsTLOG9. Post Goods Movement

7b. Update BI 10. Create Billing Document

11. Create FI Document

7c. Update Sales Data

BI Master Data

12. Transfer Master Data:Sites, Articles, EAN

Assignment, Unit Conversion

Figure 9: Overview of the exemplary process

For managing and monitoring the operations of the preceding POS Inbound processes, please refer to thegeneric 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 NetWeaverBI

2.1.1.1 Description

General information:

To deliver the full set of functionality, SAP POS data management requires the availability of specific masterdata in SAP NetWeaver BI. In the sample scenario, this data is available in SAP ERP for Retail and can beuploaded into SAP NetWeaver BI using standard IS Retail Business Content extractors (except for0RPA_MEAN and 0RPA_MARM; follow SAP Note 835111).

The following InfoObjects are required by POS data management

https://service.sap.com/solutionmanagerbp



BW Info Object Description Remarks

0MATERIAL Material (article) extraction of Attributes

0PLANT Plant (store) extraction of Attributes

0RPA_MARM Units of measure for article extraction of Attributes

0RPA_MEAN EAN assignment to article extraction of Attributes

0MAT_PLANT or

DSO 0RT_DS01

Plant material

Product and Location Attributes

without data extraction, only activate the Info Object

DSO activated from Business Content

0SALESORG Sales Organisation extraction of Attributes

0COMP_CODE Company Code extraction of Attributes

0FISCPER &

0FISCVARNT

Fiscal Period

Fiscal Year Variant

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 DataSourcesupwards

Even if SAP does not deliver preconfigured process chains for the POS Analytics business content, it ishighly recommended to create process chains to upload the master data from ERP for Retail on a daily basebefore the transactional data are uploaded.



Figure 10: Example for daily master data process chains setup

This example process chain executes InfoPackages to upload all necessary master data InfoObject attributesin the correct sequence. The attribute change run as final step of the process chain executes the master datamodificatons 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 waythat will be described in more detail. If the master data are not updated regularly, the risk of erroneous datauploads is high. Additionally, PIPE is executing master data lookups to check and enrich the transactionalPOS data internally. As master and transactional data staging can not be handled individually regarding thefunctionality of POS data management, a regular monitoring of the master data uploads is mandatory toestablish a stable system environment (find further details in the following chapter Error, Throughput andBacklog Monitoring). If a customer is using customer InfoObjects instead of the delivered standardInfoObjects, 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.



0FISCPER & 0FISCVARNT

are used in the start routines and the field routines that are mapped between the source fieldBUSINESSDAYDATE and the target fields 0FISCPER and 0FISCVARNT of the transformations between theDataSources 0RT_PA_TRAN_CONTROL, 0RT_PA_TRAN_GDS_MOV, 0RT_PA_TRAN_MOV_FIN and0RT_PA_TRAN_TOTALS and their assigned InfoSources. During the upload of the transactional data to thedata 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 valuescan 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 andvariants 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 areused to enrich the moving average cost price on store article level in SAP NetWeaver BI. In the start routineof the transformation between the DataSource 0RT_PA_TRAN_CONTROL the FMRSBCT_RPA_MOVING_AVERAGE_GET is called that tries to get the moving average cost price from InfoObject0MAT_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, TradeIndustries, Trade Foundation, General Settings). If this routine fails, the processed data package will raiseand error or warning. It is possible, to influence the system behavior in that area by maintaining the BIcustomizing cockpit under the same path. When the missing data for article and plant - critical flag is set, theexecuted data upload will raise an error. If it is not flagged, only a warning is given and the data are availablein 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 datacheck and to enrich additional data in PIPE related to the article. In the standard, PIPE is reading the attribute0BASE_UOM to check whether the article sales unit combination in the transactional data is valid. Theattribute 0MATL_GROUP is read for each SAP article number and enriched into the transactional data. ThePIPE 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 ispossible to turn the master data check off in general or for each check profile (under path Check Profiles). Incase that the master data check is not executed, the PIPE will enrich automatically the PIPE field materialnumber with the value of the field itemid in case that the itemidqualifier was set to ‘SAP article number’. Thesame enrichment will be executed into the field merchandisecategory in case that the itemidqualifier wasset 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 profile0006 ‘Master Data Check’ for the parameters for task, NO_CHECK_FOR_MATERIAL in that way, that nochecks 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



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 transactionaldata. An error occurs in PIPE internally only, if the parameter group in the PIPE customizing /n/POSDW/IMGunder Tasks, One step processing, Define Parameters for Tasks for Parameter Profile 0006 ‘Master DataCheck’ for the parameters for task NO_CHECK_FOR_STORE_CURRENCY is maintained in that way, thatno 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 valuewith 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, thefield routine of the transformations on 0PLANT raises a warning message when the try fails to get a storecurrency by reading the attribute from 0SALESORG and 0COMP_CODE. Therefore it is also necessary toload information to the Company Code and Sales Organisation InfoObject. Please refer for further details toSAP Notes 811393 and 1273520

0RPA_MARM and 0RPA_MEAN are InfoObjects that are used by PIPE in case that EAN’s are deliveredfrom the POS system. PIPE delivers the standard functionality to enrich for EAN’s the SAP article numberand SAP material group by executing a lookup in 0RPA_MEAN. Additionally, PIPE recalculates the quantitiessold in base unit of measure by looking up in 0RPA_MARM. Like this, sales data can be delivered in salesand base units of measure to SAP NetWeaver BI. As the business content in SAP ERP for Retail and SAPNetWeaver BI does not deliver preconfigured extractors, please follow SAP Note 835111 to create owngeneric master data extractors for 0RPA_MEAN). For InfoObject 0RPA_MARM the DataSource0MAT_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 DataStorage Upload with BW 3.x’ and ‘SAP BW 3.x Data Target Upload’ underhttps://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 contentdata 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 beforetransactional POS data can be uploaded to SAP NetWeaver BI. The master data are extracted from thesource system by executing the InfoPackages of the corresponding DataSources and the DTP’s into theInfoObjects.

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, youshould 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 chainyou can use the Process Chain Overview (transaction RSPC). Here you have an overview about the

https://service.sap.com/solutionmanagerbp.



progress of your process chains and which processes are taking place at the moment. You see anoverview about the process steps done so far for each process. From here, you can jump to more detailedmonitors 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 (transactionCHANGERUNMONI).

Open Hub Monitor: For problems with Open Hub Service and InfoSpokes you can use the Open HubMonitor. Similar to the Upload Monitor the Open Hub Monitor shows the progress of each request and thesingle process steps.

Performance Monitoring:

To ensure a high availability of master data, it can be useful to regularly check the system performanceduring the upload execution. For further details please refer to the generic Run SAP - Best Practices forSolution Management documentation ‘Periodic Jobs and Tasks in SAP BW’ underhttps://service.sap.com/solutionmanagerbp.

2.1.1.2 Monitoring objects

Monitoring Object Analysis Tool onSatellite System

Monitoring Frequency / DataCollection

Master data upload process chains RSPC during InfoPackage and DTPexecution

Master data upload RSMO during InfoPackage and DTPexecution

Change run execution after master dataupload

CHANGERUNMONI during InfoPackage and DTPexecution

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 thefollowing analyzing tools

Monitoring Object Analysis tool on satellite system Monitoring frequency / datacollection

System Log SM21 after InfoPackage and DTPexecution

ABAP Runtime Errors ST22 after InfoPackage and DTPexecution

Table 4: Transfer master data – Error handling per monitoring object

https://service.sap.com/solutionmanagerbp.



Further details about monitoring tools in SAP NetWeaver BI are available as generic Run SAP - BestPractices 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 withSAP Solution Manager’

2.1.2 Proc. step 7b: Update transactional POS data for POS data management to SAPNetWeaver BI

2.1.2.1 Description

General information:

A POS generates different types of transactions like sales transactions, goods movements and financialtransactions as well as statistical information. The design of PIPE allows to process these data to SAPNetWeaver BI either immediately or as a bulk process with a self-defined frequency and a customizedaggregation 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 usingtransformations. The POS Analytics content delivers preconfigured data flows for the DataSources0RT_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 availableto InfoSource level. The upload from the PSA tables to the InfoCubes is executed by DTP’s via preconfiguredtransformations. In the transformation between the DataSource and its corresponding InfoSource, the logicfor the key figure calculation is encapsulated in ABAP service classes. The instantiation of the tradefoundation service classes are called in the start routine of the transformation. Additionally each key figuresimply calls a the same method with a unique key figure name. Depending on the key figure name a differentcalculation logic is executed. It is possible to create own implementations for service classes for own keyfigures. Using this concept has the benefit, that established and productive data flows for transactional datawill 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 uploadof the transactional data into the InfoCubes, analyses of the POS data can be executed on different levelsand 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.


http://service.sap.com/~sapidb/011000358700000194902009E).



Sample scenario specific information:

Sales data delivered from POS are sent from PIPE to the SAP NetWeaver BI delta queue0RT_PA_TRAN_CONTROL. The transactional data is extracted from the BI delta queue into the InfoCube0RPA_C01 (store/article/day)

Figure 11: Process chain

Even if SAP does not deliver preconfigured process chains for the POS Analytics business content, it ishighly recommended to create process chains to upload the transactional data regularly from the delta queueinto the POS Analytics InfoCube after the master data loads are executed.

Example for a regularly executed transactional data process chains setup:



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 andthe volumes of data transferred into SAP NetWeaver BI are critical. So a regular monitoring of thetransactional data uploads is mandatory to establish a stable system environment (please refer to thedescribed monitoring tools in chapter Error, Throughput and Backlog Monitoring). Because of these hugevolumes, a detailed view on the used staging areas in SAP NetWeaver BI is useful to decide measure toavoid critical redundancies and to enable a performing data upload, staging and reporting process in SAPNetWeaver BI.

BI delta queue

The transactional data from PIPE are stored in the delta queue to establish a delta scenario to uploadunprocessed data to the PSA table. Please pay attention that a full upload is not supported to update theSAP NetWeaver BI data targets from PIPE. To establish the delta queue, it is mandatory to create andexecute at the first time an InfoPackage to initialize the delta process without data transfer.

Figure 13: Initialize delta process



After the delta queue is initialized, the deltas are uploaded to the PSA table with a separate InfoPackage fordelta upload.

Figure 14: Delta update

PSA table

The persistent staging area table is keeping the original transactional data from the SAP NetWeaver BI deltaqueue. The PSA table ensures an easy reprocessing of data into InfoCubes or other data targets without theneed of affecting other source systems in case that data have been processed incorrectly or have beendeleted.

InfoCube

The InfoCube is storing the data on the required level for long term usage for reporting. The scenarioInfoCube 0RPA_C01 is storing POS data on the level store/article/day. Two additional InfoCubes are storingthe data on higher timely aggregation (week and month).

Recommendations

As POS data management processes high volume data, a concept for avoiding redundancies and retentionperiods is mandatory. A detailed view, for how long time data have to be kept in the delta queue and the PSAtable 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 storagesolutions can completely avoid performance issues during data processing in the whole POS Analytics dataflow. The retention period of POS data to be available in PIPE must be taken into consideration dependant onthe quality of data delivered in a production environment (the more erroneous data from POS, the longer theretention period in PIPE). The InfoCubes should not store more then 100 million records when the classicreporting environment is in use. If a BIA (SAP NetWeaver BI Accelerator) is available, the InfoCube caneasily manage much more data.



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 usageof monitoring tools is helpful.

Sample scenario specific:

Check the data upload and staging performance for the delta queue and PSA table of DataSource0RT_PA_TRAN_CONTROL and InfoProvider 0RPA_C01. Monitor the execution of the InfoPackage thattransfers the data from the BW delta queue into the 0RT_PA_TRAN_CONTROL PSA table and the DTP thattransfers 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 performanceduring the upload execution. To optimize the system performance, please refer to the described details in thegeneric Run SAP – Best Practices for Solution Management documentation and ‘Background Job monitoringwith SAP Solution Manager’ chapters: Performance Data management

2.1.2.3 Monitoring Objects

Monitoring Object Analysis Tool on SatelliteSystem

Monitoring Frequency/Data Collection

Transactional Data upload process chains RSPC during InfoPackage and DTPexecution

Transactional Data upload RSMO during InfoPackage and DTPexecution

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 usingthe following analyzing tools

Monitoring Object Analysis Tool onSatellite System

Monitoring Frequency/Data Collection

System Log SM21 after InfoPackage and DTP execution

ABAP Runtime Errors ST22 after InfoPackage and DTP execution

Table 6: Update transactional POS data – Error handling per monitoring object



Further details about monitoring tools in SAP NetWeaver BI are available as generic Run SAP – BestPractices 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 withSAP Solution Manager’




3 Further Information

3.1 Related Best Practice Documents

There are several other Best Practice documents available on the SAP Service Marketplace underhttps://service.sap.com/solutionmanagerbp that relate to this Best Practice document. These documents are:

General Business Process Management: This document explains the procedures you should use tocreate a general c concept. This includes the definition and documentation of the core businessprocesses, definition of monitoring objects, definition of monitoring activities including error handlingprocedures, monitoring tools, monitoring frequencies, the definition of communication and escalationprocedures and the assignment of responsibilities.ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus onALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitorALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoringapproaches 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 recommendsas a standardized formal process to support a job request process, including an end user job request formand an approval process. This integrated process will avoid error-prone and time intensive manualprocesses of copying redundant data from one data source to another (for example, MS excel to MS Excelor MS Excel to job scheduling tool).SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a BusinessProcess Monitoring concept for your SAP ERP solution. The concept aims to define procedures forbusiness process oriented monitoring and error handling and escalation procedures for your company’sERP core business processes. These procedures intend to ensure a smooth and reliable flow of the corebusiness processes so that your business requirements are met.Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set upbackground job monitoring properly in the framework of Business Process Monitoring in the SAP SolutionManager.

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


http://service.sap.com/~sapidb/011000358700000194902009E



Index of FiguresFigure 1: Monitoring alert types 9Figure 2: Monitoring objects – dialog performance 10Figure 3: Monitoring alerts – dialog performance 10Figure 4: Monitoring objects – update errors 11Figure 5: Monitoring objects and alerts - application log 12Figure 6: Monitoring alert – application log/critical messages 13Figure 7: Analysis & monitoring transactions 14Figure 8: Analysis & monitoring url 14Figure 9: Overview of the exemplary process 18Figure 10: Example for daily master data process chains setup 20Figure 11: Process chain 25Figure 12: Example for a regularly executed transactional data process chains setup 26Figure 13: Initialize delta process 26Figure 14: Delta update 27

Index of TablesTable 1: Responsibilities and problem resolution procedures 15Table 2: InfoObjects required by POS data management 19Table 3: Transfer master data – Monitoring objects 23Table 4: Error handling per monitoring object 23Table 5: Update transactional POS data – Monitoring objects 28Table 6: Error handling per monitoring object 28



© Copyright 2009 SAP AG. All Rights ReservedNo part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBMCorporation.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.MaxDB is a trademark of MySQL AB, Sweden.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Allother product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide anywarranty whatsoever relating to third-party Web pages.