Pos Inbound

Best Practice for Solution OperationsManage Operations for SAP for Retail: POS Inbound Dietmar-Hopp-Allee 16 D-69190 Walldorf CS STATUS internal final DATE VERSION DEC -17 2007 1.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 Operations Manage Operations for SAP for Retail: POS Inbound Date Dec 1, 2008 Dec 17, 2008 Alteration Reason Creation Finalization Version 0.1 1.0 Table of Contents 1 Management Summary 1.1 Goal of Using this Best Practice 1.2 Alternative Practices 1.3 Staff and Skills Requirements 1.4 System Requirements 1.5 Duration and Timing 1.6 How to Use this Best Practice 1.7 Best Practice Procedure 1.7.1 Preliminary Tasks 1.7.2 Monitoring Concepts 1.7.3 Business Process Monitoring in SAP Solution Manager 1.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 1.7.4.1 Application Monitor 1.7.4.2 Background Job 1.7.4.3 ABAP Dump Collector 1.7.4.4 Dialog Performance 1.7.4.5 Update Errors 1.7.4.6 Due List Log 1.7.4.7 Application Log 1.7.4.8 Other CCMS Monitors 1.7.4.9 Analysis and Monitoring Tools 1.7.4.10 Monitoring Activities 1.7.4.11 Notifications 1.7.5 Business Process Monitoring Process 1.7.6 Legend 2 Business Process Monitoring for POS Inbound 2.1 Business Process POS Inbound 2.1.1 Business Process Step 1: Poll and Send Sales Data 2.1.1.1 Description 2.1.2 Business Process Step 2: Receive, Transform and Send Information 2.1.2.1 Description 2.1.3 Business Process Step 3: Process Sales Data (P01) 2.1.3.1 Description 2.1.3.2 Monitoring Requirements: 2.1.3.3 Monitoring Objects in SAP Solution Manager 2.1.3.4 Monitoring without SAP Solution Manager 2.1.3.5 Scheduling of Background Jobs 2.1.4 Business Process Step 4: PIPE Processing (P02) 5 5 5 5 6 6 6 6 6 6 7 7 8 9 9 10 11 12 13 14 15 17 17 18 19 20 20 21 21 21 21 21 21 22 22 23 23 23 © 2008 SAP AG page 2/53 Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2.1.4.1 Description 2.1.5 Business Process Step 4a: Checks and Verification in PIPE 2.1.5.1 Description 2.1.5.2 Monitoring Requirements 2.1.5.3 Monitoring Objects in SAP Solution Manager 2.1.5.4 Further Monitoring Objects 2.1.5.5 Monitoring without SAP Solution Manager 2.1.6 Business Process Step 4b: Jobs in One-step Processing 2.1.6.1 Description 2.1.6.2 Monitoring Requirements: 2.1.6.3 Monitoring Objects in SAP Solution Manager 2.1.6.4 Monitoring without SAP Solution Manager 2.1.6.5 Scheduling of Background Jobs 2.1.7 Business Process Step 4c: Jobs in 2-step Processing 2.1.7.1 Description 2.1.7.2 Monitoring Requirements: 2.1.7.3 Monitoring Objects in SAP Solution Manager 2.1.7.4 Monitoring without SAP Solution Manager 2.1.7.5 Scheduling of Background Jobs 2.1.8 Business Process Step 4d: The Message Log Application 2.1.8.1 Description 2.1.8.2 Monitoring Requirements: 2.1.8.3 Monitoring Objects in SAP Solution Manager 2.1.8.4 Further Monitoring Objects 2.1.8.5 Monitoring without SAP Solution Manager 2.1.8.6 Scheduling of Background Jobs 2.1.9 Business Process Step 4e: Data Consistency between POS System and PIPE 2.1.9.1 Description 2.1.9.2 Monitoring Requirements: 2.1.9.3 Monitoring Objects in SAP Solution Manager 2.1.9.4 Further Monitoring Objects 2.1.9.5 Monitoring without SAP Solution Manager 2.1.9.6 Scheduling of Background Jobs 2.1.10 Business Process Step 5: Send Data to SAP for Retail (P03) 2.1.10.1 Description 2.1.10.2 Monitoring Requirements: 2.1.10.3 Monitoring Objects in SAP Solution Manager 2.1.10.4 Further Monitoring Objects 2.1.10.5 Monitoring without SAP Solution Manager 2.1.10.6 Scheduling of Background Jobs 2.1.11 Business Process Step 6: Post data within SAP for Retail (PO4) 2.1.11.1 Description 2.1.11.2 Monitoring Requirements: 2.1.11.3 Monitoring Objects in SAP Solution Manager 2.1.11.4 Monitoring without SAP Solution Manager 2.1.11.5 Scheduling of Background Jobs 23 24 24 24 24 25 25 25 25 26 26 26 26 27 27 27 27 28 28 28 28 29 29 29 30 32 33 33 33 34 34 34 35 35 35 36 36 37 37 37 37 37 38 38 39 39 © 2008 SAP AG page 3/53 Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2.1.12 Business Process Step 7: Update BI Info Cubes (P05) 2.1.12.1 Description 2.1.12.2 Monitoring Requirements: 2.1.13 Business Process Step 8: Update SAP F&R (P06) 2.1.13.1 Description 2.1.13.2 Monitoring Requirements: 2.1.13.3 Monitoring Objects in SAP Solution Manager 2.1.13.4 Further Monitoring Objects 2.1.13.5 Monitoring without SAP Solution Manager 2.1.13.6 Scheduling of Background Jobs 2.1.14 Business Process Step 9: Extraction of Master Data for BI (P07) 2.1.14.1 Description 3 Further Information 3.1 Troubleshooting 3.2 Related Best Practice Documents 3.3 Literature 3.4 Feedback and Questions 4 Appendix 4.1 Example Background Job Monitoring 4.2 Example PI Message Process Monitoring 4.3 Example ALE / IDoc Monitoring 4.4 Example Dialog Performance Monitoring 4.5 Example Application Log Monitoring 4.6 Background Jobs 39 39 40 40 40 40 41 41 41 41 42 42 43 43 43 43 44 45 45 46 46 49 50 51 © 2008 SAP AG page 4/53 Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 1 1.1 Management Summary Goal of Using this Best Practice This Best Practice helps you to set up a Business Process Monitoring concept for your SAP Retail solution. The concept aims to define procedures for business process oriented monitoring and error handling and escalation procedures for your business process “POS Inbound”. 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 SAP Solution Management Optimization (SMO) service for SAP Business Process Management (BPM). This service is exclusively available within SAP’s support engagements SAP MaxAttention and SAP Safeguarding. If your company currently does not have any support 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 ERP Business Process Monitoring concept and consists of experts from several areas of your company: Business department Solution support organization (for example the Basis Support or the Application Support) Implementation project team Business Process Operations Team The Business Process Operations team will be responsible for applying the resulting procedures derived from implementing this best practice. They include the following groups: Persons designated to perform business process oriented monitoring and ensure that the process runs smoothly (e.g. the Business Process Champion for each business process) All parties in your Solution Support Organization and IT department involved in monitoring focused on the application aspects (Application Support, Development Support, Job Scheduling Management) 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. © 2008 SAP AG page 5/53 7. Here you find a brief description of how you should proceed in using this document: 1. definition of monitoring objects. This document explains the procedures you should use to create a general Business Process Management concept. To have all described monitoring objects available in SAP Solution Manager. It is intended to be used as a guideline for writing down your company specific process documentation. The monitoring procedures help you to ensure that the technical processes meet the requirements for stability.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Necessary or Useful Trainings SM300 Business Process Management and Monitoring E2E300 End-to-end Business Process Integration and Automation Management 1.2 Monitoring Concepts The monitoring procedures proposed for each business process step are the core of this Best Practice. the definition of communication and escalation procedures and the assignment of responsibilities.4 System Requirements In order to monitor business processes running in your SAP Retail solution via SAP Solution Manager. available on the SAP Service Marketplace. In Chapter 1.1 Preliminary Tasks Before performing this Best Practice. the add-on ST-A/PI01L has to be installed on the SAP Retail system. These procedures cover monitoring for the five areas: Error monitoring Performance monitoring Throughput monitoring © 2008 SAP AG page 6/53 . definition of monitoring activities including error handling procedures.4 you find further information that is relevant for more than one scenario. monitoring tools and monitoring frequencies. This includes the definition and documentation of the core business processes. 1. ensure that you perform the following preliminary tasks or checks in the system: Complete all installation and post-installation actions and procedures including customizing Ensure that the initial download has been successfully executed Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations resulting from customer problem messages Implement all current SAP Support Packages upon availability 1. Timing The best time to apply this Best Practice is during the planning phase or during the implementation phase of your SAP solution.7 Best Practice Procedure 1. 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.7.6C.6 How to Use this Best Practice Read through the General Business Process Management Best Practice. 1. Implementing the Business Process Monitoring concept might take approximately an additional week. At the beginning of Chapter 2 you will find a typical flow chart of the core business process explained in this Best Practice. performance and completeness.7.5 Duration and Timing Duration Creating a Business Process Monitoring concept could take around one week per business process. the SAP Basis Release of the systems to be monitored have to be at least 4. the SAP Solution Manager offers extended functionality for error handling and problem resolution. By using Business Process Monitoring.7. 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. yellow. The below mentioned Monitoring Types are available: © 2008 SAP AG page 7/53 . due list logs etc. and Business Process Monitoring is intended to ensure a smooth and reliable operation of the business processes and. 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.com/bpm. Recommendations for performance monitoring can also be found in this chapter. The core business processes that are implemented in a SAP Retail system or other software and operated by a company are of particular importance.7. 1. The performance of the most important steps of your core business processes should be monitored on a regular basis.7. Therefore. In general. By the definition of contact persons and escalation paths. 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.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 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. performance.3 Business Process Monitoring in SAP Solution Manager Business Process Monitoring (BPMon).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. 1. it is possible to define and customize alert situations from a basic set of configurable alerts provided by the SAP Solution Manager.) 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. general application log. In addition. These alerts are then visualized by green. Business Process Monitoring can be integrated into the company’s overall strategy for Business Process Management and Solution Management within their Solution Support Organization.4. thereby. The monitoring procedure for performance monitoring of all steps that are executed in an SAP Retail solution is generally the same. The SAP Solution Manager provides a graphic to visualize a company’s (distributed) system and solution landscape and all related business processes.sap. 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. you will only find specific performance monitoring recommendations on selected business process steps. and completeness. that the core business processes meet a company’s business requirements in terms of stability. and red alert icons for each individual business process step in the graphical business process representation. In order to receive detailed information on how to set up the Monitoring Objects in the SAP Solution Manager.1 Throughput and Backlog Indicators (TBIs) As of ST-A/PI 01H a completely new set of Application Monitors has been introduced. 1. The latest Monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the satellite system.com/bpm.g.g. Transfer Requirements.sap.User Exit’ respectively (URL http://www. 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 . Deliveries.sap. Mass Activity Monitors. MRP key figures. Data Consistency Checks. 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.7. Shipments) © 2008 SAP AG page 8/53 . The Throughput and Backlog Indicator functionality available as of ST-A/PI 01J* is only working properly with ST-SER 700_2007_1. In case of problems refer to SAP Note 915933. 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.4. Due List Log. 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 contains all affected system components. please refer to the documentation that is available under http://service. 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.7.com) SAP Solution Manager Basic Settings. Goods Movements) Logistics Execution (e. Please ensure that the ST-A/PI is installed on the SAP Solution Manager system and on the respective satellite. 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 ERP Logistic the following monitors are available: Sales and Services (e. 1. This is due to changes in the underlying architecture.com/ Alias BPM Media Library). Sales Documents.4. Transfer Orders) Inventory Management (e. please turn to (URL http://help. Invoices) Warehouse Management (e.1.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Application Monitor (Throughput and Backlog Indicators.1 Application Monitor The Application Monitor is just one of many different Monitoring Types within the Business Process Monitoring.sap.g.service.g. If you want to learn more about how to set this up. There are four different possibilities to identify a special background job or a group of background jobs.g.g.1.sap.service. 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.com/BPM Media Library). Information about Data Consistency Checks are described in detail in the Setup Guide – Data Consistency Monitoring (URL http://www. 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. e.2 Background Job The background job monitoring should be part of a Job Scheduling Management concept (go to http://service.4. Goods Movements posted with error. …) or existing dependencies between different activities (e. but can also permanently store a summary to the ST-A/PI's cluster table. Planned Orders. This information needs to be maintained in the sub-node ‘Background Job’ below a business process step. that can compare Retail-specific data between the SAP ERP Retail system and an SAP SCM system.sap. Planned Orders.7.7.sap. Confirmation Pool errors) Plant Maintenance (e. PM/CS Orders) For further information on the different TBIs refer to the document ‘Setup Guide . time restrictions.3 ABAP Dump Collector 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. 1.com/) -> Technical Information. Purchase Requisitions. There are certain consistency check programs.4. PM/CS Notifications.service. © 2008 SAP AG page 9/53 . 1. main memory.1 Monitoring Objects Before setting up monitoring the monitoring objects must be clearly defined.g. A monitoring object is a single background job or a group of background jobs. These comparison programs are able to output their check result not only to a list or into the spool. Therefore it is also necessary to define restart procedures and escalation paths. Because of several restrictions regarding background job scheduling.Application Monitoring’ (URL http://www.com/solutionmanagerbp Topic Area “Business Process Operation”.g. Purchase Orders) Manufacturing (e.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Procurement (e. 1.4. These monitoring objects can be configured to retrieve the number of found inconsistencies out of the stored summary information and display that as alerts within the SAP Solution Manager Business Process Monitoring (Consistency Monitoring).4.g.7.2 SAP Retail Data Consistency The DCC collectors for Retail are data collectors to retrieve a stored comparison result from an SAP ERP Retail system. Autom. Production or Process Orders. invoices can only be created after the corresponding goods issue is posted.7.sap.2. 1. A cancelled background job should be identified as soon as possible in order to react as fast as possible.com/solutionmanagerbp Topic Area “Business Process Operations” to find a Best Practice document ‘Job Scheduling Management’). restriction of hardware resources (CPU. that can be monitored.4.3. © 2008 SAP AG page 10/53 .1 Monitoring Objects The monitoring object is the transaction itself.7. In table ‘Transactions’ all transactions that are already configured to that business process step are listed. 1.4 Dialog Performance Dialog Performance implies the monitoring of the dialog transaction performance of any transaction in the SAP System. 1. This could be a standard transaction or an own developed transaction. The monitoring can be performed per SAP instance. load and generation time.4. This runtime error can be specified via the runtime error name.4. the Client on which the runtime error occurs or the Program which leads to the runtime error. Those times that are relevant for monitoring have to be selected. It is also possible to add or to remove transactions within table ‘Add/Remove Transactions’. Therefore the respective instances have to be selected in table ‘SAP Instances’.4.3. 1. The customizing has to be done in node ‘Dialog Performance’. Table ‘Alert Types’ shows the dialog response time and all parts of the response time.1 Monitoring Objects The monitoring object is an ABAP runtime error.7. After saving this node a sub-node ‘Performance Alerts’ will appear where the threshold values have to be entered. All instances that are maintained for a system are listed there. the user who is responsible for the runtime error.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 1.2 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. The relevant transactions need to be selected for monitoring.4.7. database request time and the front-end response time. like queue time.7. client and program for this day or for the previous day. the transaction should not make any changes to the database. To transfer all at once (all thresholds for all columns and tables) there is an additional button "Copy all". whereas “XYZ” represents the SID. For each combination of transaction code and instance that should be included in the monitoring.2 Monitoring Alerts Each table in the sub-node ‘Performance Alerts’ corresponds to an alert type chosen in the higher-level node. To transfer the threshold values for a single line from right to left. If no active settings for the threshold values were found for a certain transaction code. the copy icon can be used.7. back from RED to YELLOW.4.4. If the operation is canceled while the transaction is being executed. If successfully retrieved for an SAP instance. These activities are handled by the SAP update system. or if an error occurs. Therefore you can load the current threshold values from the respective systems via the button "Load thresholds from XYZ". © 2008 SAP AG page 11/53 . Monitoring Alerts . Since the Monitoring Object for Performance Monitoring is created on the satellite system.4. the threshold values resulting in alert messages for changes from GREEN to YELLOW.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.7. and lists the combinations of specified transaction code and SAP instance. the values are filled in columns.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Monitoring Objects – Dialog Performance 1.Dialog Performance 1. and back from YELLOW to GREEN have to be specified. it might be possible that the object already exists there. default values are set (indicated in column "Default"). from YELLOW to RED. the list contains e. 1.21. these affect objects that have a controlling function in the SAP System. This is the object type.Update Errors 1.7. a number of sales documents that © 2008 SAP AG page 12/53 . for example order creation or changes to material stock. The delivery due list can be directly accessed via transaction V_SA. The name of the object is the name of a transaction or the name of the ABAP program itself.2 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. all users (represented by '*') will be considered in monitoring data evaluation. There are different types of due lists in an SAP system of which the following three are most important: delivery (L).5. such as result calculations.4. V1 modules describe critical or primary changes. the billing due list via transaction V.6 Due List Log A due list is a list that contains several entries (documents) depending on selection criteria.7. for example.4. Monitoring Objects .7.g. This distinction allows the system to process critical database changes before less critical changes. billing (F) and picking (K). These are pure statistical updates. If no user is specified explicitly. non-time-critical (V2) update errors. In case of a billing due list.4. If desired a user executing the transaction or the ABAP program can be specified. This is valid for V1 and for V2 update errors. time-critical (V1) and secondary. 1.5. To raise a red alert for a V1 or a V2 update error a threshold must be specified.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound The SAP System makes a distinction between primary. V2 modules describe less critical secondary changes.1 Monitoring Objects Monitoring of Update Errors can be configured for online transactions and/or ABAP programs relevant in a business process. 4. four different alert types can be used: 1. It can also be useful to report a successful completion.7. This could be ‘per day’. saving them in the database and displaying them as a log. ‘per hour’ or ‘per log’.4. the message ID and the number can be specified. etc. 1.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound need to be billed.2 Monitoring Alerts For the monitoring of due list log messages. If a certain user is processing the due list.4. creation time. ‘MinQuantityDocs’ refers to a minimum number of documents that should be created during a Due List run. The alert rating (YELLOW or RED) will be raised if no documents were created during a Due List run. The name of an object (and/or subobject) can be found in transaction /nSLG1 together with all other specific information to that log.1 Monitoring Objects and Alerts The Application Log allows an application. ‘Billing’ or ‘Picking’. ‘TotalQuantityMsgs’refers to the total number of message created during a Due List run.6. If the billing due list was processed previously and it is important to know which billing documents were created from this billing due list. 1. 2.7. A transaction can generate several logs. 3. The Application Log is not written consecutively but as a whole at one point in time.7. 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 threshold values for the number of messages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. The threshold values for the number of documents that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. the name of the user can be specified here. © 2008 SAP AG page 13/53 . The message type. 5. creator. 1.7. That can be ‘Delivery’. The aggregation level needs to be defined. ‘DocumentCreation’ refers to the status of the document creation itself. A log usually also has header information (log type. These are usually errors. The threshold values for the number of messages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. The information that arises is called a message.4. It is also possible to use wild cards.7.7 Application Log The Application Log provides an infrastructure for collecting messages. it can be displayed in the due list log for this billing run.or object-oriented recording of events.1 Monitoring Objects The monitoring object is the respective due list type. 1.6.4.). Situations can arise at runtime in application programs that must be brought to the attention of the user in some way. If it is user independent a wild card ‘*’ can be used. The set of messages is a log. ‘DLLogMsgs’ refers to specific due list log messages. 4. Monitoring Alerts .7. 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. the message ID and the message number as well as the threshold values for the number of critical messages that are supposed to result in changes from GREEN to YELLOW and from YELLOW to RED can be specified. For each of these combinations the message type.Application Log It is possible to monitor for the total number of messages belonging to an object. the relevant object-sub object combinations need to be selected. It is also possible to use wild cards. It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs.Application Log / Critical Messages 1. The MTE name needs to be copied into the corresponding column of the table below (See screenshot “Other CCMS Monitors” below).Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Monitoring Objects and Alerts . Under column Monitor Name it is possible to assign an individual name. © 2008 SAP AG page 14/53 . The name of the monitoring tree element (MTE) can be found by choosing F1. Therefore it is necessary to call transaction RZ20 in the Satellite System and to open a monitor that contains the required alert(s).8 Other CCMS Monitors With other CCMS Monitors it is possible to assign any CCMS monitoring tree element (MTE) to a business process step. To configure the monitoring of critical application log messages. It is also possible to add new transactions. Per default some standard transactions are maintained. If no active settings for the threshold values were found these columns remain empty. If a MTE of a higher branch-level (collective MTE) is chosen then the current and open view in the graphics will show the right alerts but it isn’t possible to work on these alerts within the Business Process Monitoring session as the alerts are not replicated there. is maintained for Background Jobs or transaction SLG1 to have a look into the application log. © 2008 SAP AG page 15/53 . If successfully retrieved. this could be standard transactions or customer self-written transactions. 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”). e. As an example you could be interested in monitoring the availability from a Portal system that possesses no CCMS but is included as one business process step in your business process. 1. To transfer the thresholds values for a single line from right to left double-click on the copy icon.g. In order to load the threshold values that are currently valid in the corresponding system.7.e. Other CCMS Monitors Unlike all other Monitoring Types the Other CCMS Monitoring provides the opportunity to assign MTEs from other Systems than the one system the actual business process step is assigned to. on attribute level. i.4.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound The MTE used for monitoring should be a MTE on the lowest leaf-level. transaction SM37. the button can be used.9 Analysis and Monitoring Tools It is possible to specify analysis transactions or URL addresses (including file directories) per monitoring object. Now you could use one MTE in the CCMS of the SAP Solution Manager to monitor the heartbeat of the Portal. You could then assign the corresponding alert via Other CCMS Monitoring to business process step running on the Portal system. that provides a job overview in an SAP System. the values are filled in the right-hand columns. com.txt 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. For web pages to be called. For URLs the push-button (e.sap.g. e.g. file://\\\server1\operations_documents\operations-handbook. This is especially interesting if you have some knowledge documents linked to a portal.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 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..g. specify the full URL. http://help.. ). window. You define a Short text and the URL to be called. using the nomenclature: file://\\\<server>\. 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 content available on file servers specify the full file path. By pressing these buttons (e. 20 characters) from the Set-up session and leads the user to the defined URL in a newly opened browser © 2008 SAP AG page 16/53 . Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 1. The information entered for the service desk message serves as a template. as soon as the business process gets an alert status. This could be an e-mail or SAPOffice mail. Use value help [F4]. Describes how often the responsible person should process the required monitoring activity. On business process level it is possible to define notifications for the whole business process i. an SAP user name in the same system. 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. Workflow notifications allow sending messages in case of alerts to a specified Recipient.g. e. Defines the Person who is responsible for monitoring the Monitoring Object. notifications will be triggered. but the user must have a valid e-mail address that is known by the used mail-server Depending on the Recipient Type the recipient name is required. Monitoring Team Person Resp.e.10 Monitoring Activities Monitoring activities should be set up for every Monitoring Object within a business process step. A description about what indicates a problem. Persons who can be contacted should be maintained here. All monitoring objects defined within a business process step are listed here.7.11. ‘Restart of Step’ and ‘Escalation Path’. how to solve the problem/correct the error.7. Notifications defined on business process step level will overrule the configuration made on business process level for this particular step. Additional information related to this business process step can be entered in the tables ‘Monitoring Activities’.1 Workflow Notification Sender Must be a user within in the monitoring client of SAP Solution Manager. all alerts related to all background jobs of the business process are forwarded to a defined e-mail address. Use value help [F4].e.4. 1. Describes the escalation path in case that the person responsible could not solve the problem. i.4. ‘Error Handling’. 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. a Remote Recipient Address © 2008 SAP AG page 17/53 . Alternative notifications can be defined for every Monitoring Type individually. There are two types of notifications: Workflow notifications and Support notifications. Describes at which time the responsible person should process the required monitoring activity. This user can be even a system user without any roles or profiles.7. This could be any e-mail address.11 Notifications Notifications can be set up for the whole business process or for each business process step individually.4. Frequency Start Time Problem Indicator Error Handling Escalation Path Defines the team that is responsible for monitoring the relevant Monitoring Object. Support notifications allow setting up a service desk message in case of an alert. 1. Some information is taken from the previous node ‘Solution Support Organization’. The service desk message can be created manually or automatically. Describes how to react on problems or errors. name of the business process step. priority and reporter either one of the columns “Num of YELLOW Alerts” or “Num of RED Alerts” is filled with a value the automatic Support Notification creation is configured. Necessary when service desk messages are created automatically. Text templates can be defined that will then be available for service desk messages manually created for alerts. This component must exist within the service desk. e. Necessary when service desk messages are created automatically. …) No. of Alerts No. Hence. a notification is created. Priority Queue Processor Text Template Automatic Reporter Num. after 10 yellow alerts a service desk message should be created. Type There are currently 5 different Recipient Types: U (e-mail).7. Triggers a long text for e-mails or SAPOffice mails. In case of an SMS you need to enter “SMS:<cell phone or pager number>” Reci. e. Necessary when service desk messages are created automatically. Defines a default processor who should process the message.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound SAP name or a shared distribution list. of YELLOW Alerts Num. e. even if the thresholds are not exceeded To restrict this mechanism only to red alerts the flag in column 'RED Only' must be set. Must be a SAP user name who is defined as a Business Partner with role “General”. after 5 red alerts a service desk message should be created. processor.g. Defines the support component on which the message is put. of Red Alerts Max Wait Time [h] RED Only Detailed 1. Alerts of RED If in addition to queue. R (Remote SAP name) and C (shared distribution list). In case that both columns are filled with a value the automatic Support Notification creation works with a logical OR operation.7. name of the solution. 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. © 2008 SAP AG page 18/53 .g.11. Yellow Number of YELLOW alerts that may occur before an automatic notification is triggered Number of RED alerts that may occur before an automatic notification is triggered Once the maximum wait time [hours] has elapsed. 1. This includes the definition of the roles and responsibilities involved.4.2 Support Notifications Defines the priority of the Support Notification. The processor must be known within the service desk and must be SAP user name who is defined as a Business Partner with role “Employee”. K (for SMS and Pager). Support Notifications will be created automatically depending on the alert thresholds. B (SAP user name).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. with the figures in the table above the system would create a .g.Support Notification if there either exist more than 9 yellow alerts OR more than 4 red alerts for which no Support Notification has been created yet. 6 Legend This symbol indicates you a paragraph from where you can navigate to another chapter of this document for more detailed information on a topic. separate communication and escalation paths and procedures have to be defined.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound A Business Process Monitoring concept has to be tightly integrated with the support organization. © 2008 SAP AG page 19/53 . 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. Wherever communication connected with Business Process Monitoring happens outside these support processes. This includes the integration with the Incident/Problem Management process and the Change Management process. This symbol indicates you a paragraph from where you can navigate to another document within the SAP Service Marketplace for more detailed information on a topic.7. Please see the above mentioned separate Best Practice for General Business Process Management for further details. This includes the final communication of open alert to SAP. 1. The most common subsequent applications are SAP BI. financial aspects also play an important role in this process as it is at the POS where retailers earn their money.1 Business Process Monitoring for POS Inbound Business Process POS Inbound POS Inbound is the process in which data collected at the Point of sale (POS) is transferred to a central system for subsequent processing. The flexible design of PIPE however enables the possibility to provide other applications in an efficient way. Missing data can therefore cause serious irritations in subsequent applications as the turnover reporting may not reflect the real life showing mainly lower results and results in FI are also not correct. 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.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2 2. Sales transactions are usually registered at the POS System located in the stores. Whereas data is mostly transferred in detail to SAP BI to enable detailed analysis and data mining. 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. it is obvious that the passage of the sales information from the POS System to ERP and to potentially a Forecast & Replenishment tool has to be secured and closely monitored. In order to avoid expensive surplus or out of stock situations at the store. Based on this data. 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 to POS Data Management’s central component called PIPE (POS Inbound processing engine). The distribution is mainly influenced by stock levels in the Point of sale (POS) and the calculated requirements for each POS. Within this tool the incoming data is verified and posted to subsequent applications. © 2008 SAP AG page 20/53 . The complexity of this process involving various systems and processes underlines the importance of a well defined monitoring and scheduling landscape. It is vital to the retailers business that no data is lost on the way. The stock levels are managed in SAP ERP for Retail and updated by goods movements and sales activities carried out at the POS. Besides the update of stock levels. SAP ERP and SAP F&R. Apart from sales data. the data is aggregated by date. The POS Inbound process is extremely critical in a Retail environment because the core function of a retail system is to manage the distribution of goods to the customer. replenishment requirements are calculated on a central system. store and article in order to update follow-on applications such as SAP for Retail. Due to the large variety of possible implementations no general documentation of monitoring can be made available. It is important to know whether the stores are capable of sending data to the central system. Transform and Send Information 2.1 Description General Information: Depending on the cash desk systems’ capabilities to send data and the EAI tool used. near real-time meaning every couple of minutes or once a day in a bulk process.1.1.1. Depending on the product chosen. RFC enabled Function Module /POSDW/CREATE_TRANSACTIONS_EXT 4. Example: A Retailer having 800 stores that transfer sales data every 3 minutes in order to enable near real-time stock availability checks would need an almost unmanageable effort to identify missing transactions if no efficient availability and status monitoring is set up.1 Business Process Step 1: Poll and Send Sales Data 2.3 Business Process Step 3: Process Sales Data (P01) 2.1. That is why in most cases an EAI tool such as SAP PI serves as the middleware to connect to the disparate stores and takes care of the mapping between the cash desk system’s format and the PIPE Inbound format.1. The most common challenge in this part of the process is the ability to remotely monitor the high number of cash desk systems in the environment. 2. the recording application can be a thin client without an own database or a full-blown backend system. The sales data can be either transferred real-time. This is why an efficient availability monitoring should be set up that regularly reaches out to the disparate end-points.1 Description General Information: POS Data is generated at a cash desk system in the store. monitoring requirements can vary. Example: The local cash desk system stores the transaction data in an own database.2.1. SAP PI can be used to transfer the data to a central system and to take care of the mapping.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2. The result would be inaccurate stock information. Depending on the chosen solution and scenario. BAPI /POSDW/BAPI_POSTR_CREATE 3. Error messages due to erroneous content or technical issues need to be monitored and problems solved as soon as possible. Webservice generated and implemented for function module /POSDW/CREATE_TRANSACTIONS_EXT 5.1 Description General Information: Most cash desk systems are not capable of managing data collection and transfer to a central system in a format supported by PIPE. 2. the following inbound possibilities can be used to send data to PIPE: 1.3. IDoc /POSDW/POSTR_CREATEMULTIPLE (other IDoc types such as WPUBON for detailed sales data or WPUUMS for aggregated sales data are possible in PIPE Inbound but not recommended as they do not support the full potential of analysis that can be carried out on detailed POS data) 2. Due to the large variety of possible implementations no general documentation of monitoring can be made available. Generated and implemented Proxy wrapping function module /POSDW/CREATE_TRANSACTIONS_EXT © 2008 SAP AG page 21/53 .1.2 Business Process Step 2: Receive. Errors in the actual data transfer and data transformation (mapping) need to be tightly monitored to alert expected delays in processing. monitoring needs to be enabled on the sending system in case of real-time interfaces (“trickle feed”) or can be carried out in the receiving system (BI) in case of messages stored in bulk. Message function. e. Example: The cash desk system is connected to a central PI system that collects the point of sale data every 5 minutes. whose disruption may jeopardize the flow of merchandise which is a serious negative impact for retailing business. Backlog Monitoring: Unprocessed sales transaction data due to erroneous information or interface failures threatens the business flow in case of subsequent replenishment and logistics process steps. Performance Monitoring: In order to fulfill the requirements for the typically critical time window for processing POS sales data. IDoc age Depends on the special Scenario Depends on the special Scenario Number of IDocs of type /POSDW/… in an error-status XML message status in EAI in case of XML interface XML message status in BI in case of XML interface Number of XML messages in error Number of XML messages in error SXMB_MONI or SXI_MONITOR SXMB_MONI or SXI_MONITORTOR © 2008 SAP AG page 22/53 .Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound PIPE stores the transactions in the so called TLOG tables..g.3. throughput key performance indicators should be deduced which can be assessed to have an overview of the ability of the system to cope with current and future data volume within the critical path of nightly processing. Partner type. This KPI will also be a basis for throughput monitoring. 2. key performance indicators for the performance of processing an average sales transaction (per line item) should be defined and closely monitored. POS inbound processing is the foundation for follow-up processes like replenishment and logistics execution. Depending on the business process implemented. Partner number.1. Basic type.g. A backlog of information having failed to process therefore needs to be alerted and addressed accordingly. Port. Partner function.1. Throughput Monitoring: Based on performance measurements for every single POS transaction line item. Message type. The aim of this near real-time scenario is to enable a near real-time availability check and near real-time reporting (a so-called Flash-reporting) in BI. e. The data is posted to PIPE via RFC.3.2 Monitoring Requirements: Error Monitoring: Depending on the uploading frequency and the technique used. once every evening. peak transactions for retail business during xmas holiday season. Near real-time data can only be accurate if the way and the processing are monitored and problems are handled and escalated in an efficient way.3 Monitoring Objects in SAP Solution Manager Selection Criteria Alert Analysis Tool on Satellite System WE05 or WE02 Monitoring Object Monitoring Frequency / Data Collection every 15 minutes IDoc processing status in case of IDoc interface Direction. Message code. 2. variant TRANS) /POSDW/BAPI_POSTR_ CREATE Response time of RFC-enabled function call ST03N. Job Scheduling Requirements Recommended ABAP Variant or Generated Report Job Name POSDW POS2PIPE POSLOG /POSDW /IDIS TRANS Scheduling Between every x minutes and daily Predecessor Job - Successor Job Task processi ng jobs Scheduling Restriction Not in parallel with PIPE task processing Error Handling in Case of Cancellation Can be restarted if system error 2. job cancellation. the corresponding job (an instance of program /POSDW/IDIS) should then be monitored in order to identify potential problems.5 Scheduling of Background Jobs Job Scheduling Requirements: If POS transactions are posted to PIPE via asynchronous messages based on IDocs or XML messages. error messages in Job Log SM37 every 5 minutes during every job execution 2. If XML messages are used.3. STAD POSDW POS2PIPE POSLOG. a job is required to post this data to PIPE. periodic jobs for inbound and task processing should not run in parallel.4 Business Process Step 4: PIPE Processing (P02) 2.3. Start Time Job Runtime. During PIPE inbound and outbound processing locks are held on date/store level. the processing of incoming data can be monitored using transaction WE05 or transaction WE02. If an external scheduling tool is used that offers the possibilities of setting logical locks. In the case of IDocs that need to be processed the IDoc Dispatcher within PIPE can be used. If IDocs are collected and processed with a job.1.1. ST05.4.1.4 Monitoring without SAP Solution Manager Monitoring Objects: In the case of IDocs used to transfer POS Data to PIPE. The IDoc type is should be /POSDW/POSTR_CREATEMULTIPLE. 2) Processing jobs in one-step processing and © 2008 SAP AG page 23/53 . transaction SXI_MONITOR or SXMB_MONITOR can be used to see the message status. 2.1. Also user activity such as changing data in the PIPE monitor can temporarily lock data. or /POSDW/IDIS.1 Description General Information: PIPE processing steps can be classified according to their purpose of 1) Checking and verifying the received data in PIPE.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Inbound BAPI call via RFC: /POSDW/BAPI_POSTR_ CREATE (Application Monitor: Dialog Performance Monitor) Background Job POSDW POS2PIPE POSLOG (Report /POSDW/IDIS. as this IDoc type offers the full functionality of PIPE. This is described in chapter 2. first several validation tasks are executed automatically by PIPE (via immediate task processing) to validate the incoming data: These tasks include one or several task(s) to check the master data. Throughput and Backlog Monitoring: The requirements of chapter 2.2 apply for PIPE processing as well.5. Program Monitoring Object Application log Alert Analysis Tool on Satellite System SLG1 Monitoring Frequency / Data Collection Every 60 min Error messages provided by PIPE Dispatcher © 2008 SAP AG page 24/53 . In order to only process correct transactions the result of the verification tasks are usually used as conditions for the execution of the following processing tasks. After the verification tasks. the balancing of each ticket (the accumulated sales amount for one transaction must correspond to the amount of the payment types of the same transaction) and duplicate checking (to make sure data is only loaded once).1.5. The last subchapter describes how to use the message log program to recognize occurring issues 4) Message log application After loading the transactional data to SAP POS DM the incoming data needs to be validated by use of verification tasks.5 Business Process Step 4a: Checks and Verification in PIPE 2.1. Additionally the reprocessing for data which originally had been loaded with missing master data or other issues needs to be triggered.5. After this successful validation the data processing needs to be triggered for each processing step (or so called task) relevant for the actual information. they might be executed immediately (recommended for update frequencies below 5 minutes) or scheduled for later processing once or several times a day (Job (POSDW PIPECHECK). You will always find a combination of these types of processing steps according to actual customer requirements. Details about monitoring objects and job setup can be found in the following chapters.1 Description General Information: In most common cases. transaction. 2. 2. If POS data is transferred only once a day.2 Monitoring Requirements Error Monitoring: In order to check the status of the processing.1.1.1. the monitor should be checked during and after processing.3 Monitoring Objects in SAP Solution Manager Selection Criteria Object. user. 2.3. Sub-object.6 as this type of processing complies to 1-stepprocessing). Depending on the nature of the validation tasks. These conditions are maintained in PIPE customizing for each task to be executed. processing tasks are executed as described in the following chapters. Performance.1. the PIPE monitor (or POS Workbench) should be opened or refreshed every x minutes if data is processed on a real-time or near real-time basis.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 3) Processing jobs in two-step processing. 4 Further Monitoring Objects Monitoring Object Selection Criteria Alert Analysis Tool on Satellite System Monitoring Frequency / Data Collection Online message monitoring Error messages provided by POS DM validation framework Store.5. The job log to identify issues around job processing Report /POSDW/DISPLAY_MESSAGELOG with specific variants to provide summarized processing messages (including error messages).8. Message Type.1.6.5 Monitoring without SAP Solution Manager Monitoring Objects: For monitoring the status of the processed transactions.1. the following monitoring tools can be used: POS Workbench /POSDW/MON0 to provide an online status for all transactions and drill down into the transactions details The application log for details about the actual processing of the outbound data.processing of validation steps © 2008 SAP AG page 25/53 .1 Description General Information: After loading the transactional data to SAP POS DM the data processing needs to be triggered for processing steps (or tasks) configured for batch processing or for data which had been loaded with missing master data or other issues.5. Message Priority /POSDW/MON0 or /POSDW/MON2 Task processing status as per chapter 2.1. Message Class. There can be multiple occurrences of this job depending on the business scenarios configured. Validation tasks are in most cases executed immediately when data arrives (this is set in the customizing of the task).Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2. Message number. Posting Date.1.1.8 Error messages provided during PIPE processing /POSDW/DISPLAY_MESSA GELOG 2.1. Rule. 2.processing of data directly to the target system or without impact to batch processes . Message Category.6 Business Process Step 4b: Jobs in One-step Processing 2. In the end it comes down to four different types of variants: .processing of data during batch processing . This is described in more detail in chapter 2. In this case a job (job POSDW PIPECHECK) for these validation tasks is only required to reprocess transaction in error. Performance.1.to use parallel processing 2. 2. error messages in Job Log Background Job POSDW PIPESALES (Report /POSDW/PIPE_DISPATCHER) POSDW PIPESALES.2 apply for PIPE one-step processing as well. job cancellation.2 Monitoring Requirements: Error Monitoring: The monitoring requirements of chapter 2.3.1. or /POSDW/PIPE_DISPATCHER Start Time SM37 Every 5 minutes during every job execution 2.1. error messages in Job Log Job Runtime.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound - processing of data into the POS DM aggregate storage.5 apply for the jobs POSDW PIPECHECK and POSDW PIPESALES 2. job cancellation.1.1.5 apply for the jobs POSDW PIPECHECK and POSDW PIPESALES.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Tool on Satellite System SM37 Monitoring Frequency / Data Collection Every 5 minutes during every job execution Background Job POSDW PIPECHECK (Report /POSDW/PIPE_DISPATCHER) POSDW PIPECHECK. Throughput and Backlog Monitoring: The requirements of chapter 2.4 Monitoring without SAP Solution Manager Monitoring Objects: The monitoring objects of chapter 2.6.1.6.6. There are two variants possible for the 1-stepprocessing: (Re-)Processing of validation tasks using job POSDW PIPECHECK as part of the daily batch or on a reoccurring basis Processing of 1-step tasks like the supply of data to SAP BI (job POSDW PIPESALES) © 2008 SAP AG page 26/53 . Start Time Job Runtime.1.6.to process incorrect tasks .5 Scheduling of Background Jobs Job Scheduling Requirements: The processing within PIPE is triggered by PIPE Dispatcher. triggering job for outbound processing (check for additional chapter about 2-step processing) Used variants should be configured for the following processing settings: . or /POSDW/PIPE_DISPATCHER. or /POSDW/PIPE_DISPATCHER. variant DAILY SALES) POSDW PIPEAGG.1. 2.2 Monitoring Requirements: Error Monitoring: The monitoring objects of chapter 2.7.1 apply for the jobs POSDW PIPEAGG and POSDW OUTBOUND. Throughput and Backlog Monitoring: The requirements of chapter 2. job cancellation. variant AGGREGATE) Background Job POSDW OUTBOUND (Report /POSDW/OUTBOUND_DISP ATCHER.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Scheduling of Background Jobs Recommended ABAP Variant or Generated Report Job Name Scheduling Daily as part of batch processing Daily as part of batch processing POSDW PIPECHECK /POSD W/PIPE _DISPA TCHER /POSD W/PIPE _DISPA TCHER CHECK S POSDW PIPESALES DAILY SALES Predecessor Job Data loading to SAP POS DM Data loading to SAP POS DM Successor Job - Scheduling Restriction - Error Handling in Case of Cancellation Can be restarted - - Can be restarted 2. Start Time Job Runtime. Performance. 2. From a basis perspective the availability of system resources can be monitored as the data is only mapped and not touched functionally.3. Start Time SM37 © 2008 SAP AG page 27/53 . This is done using the outbound dispatcher report collecting the aggregated (condensed) data and transforming it into the interface format. or /POSDW/OUTBOUND_DISPATC HER.7.2 apply for PIPE two-step processing as well. error messages in Job Log POSDW OUTBOUND. Errors will only occur on the system level.7.1 Description General Information: The data aggregated into the aggregate tables inside POS DM using the PIPE Dispatcher needs to be provided to the outbound interfaces.3 Monitoring Objects in SAP Solution Manager Selection Criteria Alert Analysis Tool on Satellite System SM37 Monitoring Object Monitoring Frequency / Data Collection Every 5 minutes during every job execution Every 5 minutes during every job execution Background Job POSDW PIPEAGG (Report /POSDW/PIPE_DISPATCHE R.1. Monitoring of the processing is done by checking the processing results in the POS Workbench restricting on aggregates. job cancellation.7 Business Process Step 4c: Jobs in 2-step Processing 2. error messages in Job Log Job Runtime.4.1.1.1. imbalance of total value of sales and payments against eon of day data provided by the POS) Technical issues (for example. Example: Problems typically occurring in a productive POS DM environment are: Master data issues (for example.1. technical: missing master data extraction to BI) POS DM configuration issues Data consistency issues (for example. store sending transactions where the payments value does not equal the sales value.4 Monitoring without SAP Solution Manager Monitoring Objects: The monitoring requirements of chapter 2. transaction sequence number gaps. During task processing.5 apply for the jobs POSDW PIPEAGG and POSDW OUTBOUND. business: missing or incorrect maintenance of articles and sites. This means that the aggregate tables are built up during intraday processing.1 Description General Information: After validating and processing the data inside SAP POS DM. missing initialization of BI delta queue. errors are logged as messages in the individual transactions.5 Scheduling of Background Jobs Job Scheduling Requirements: The process of adding data to the aggregate tables (job POSDW PIPEAGG) can be done throughout the day.8 Business Process Step 4d: The Message Log Application 2. either from a business or a technical point-of-view.1. connectivity issues) © 2008 SAP AG page 28/53 . 2.7.1.1.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2. This job is running once during batch processing. The program /POSDW/DISPLAY_MESSAGELOG allows to display these messages based on the filter criteria entered.7. the results need to be provided to various groups of recipients to follow up occurring errors. for example. At the end of day (during the actual batch run) the POS data is picked up from the aggregates tables and processed to. duplicate transaction postings) Data completeness issues (for example. ERP for Retail using job POSDW OUTBOUND.1.8. Scheduling of Background Jobs Recommended ABAP Variant or Generated Report Job Name Scheduling Hourly POSDW PIPEAGG /POSD W/PIPE _DISPA TCHER /POSD W/OUT BOUND _DISPA TCHER AGGRE GATE POSDW OUTBOUND DAILY SALES Daily as part of batch processing Predecessor Job Data loading to SAP POS DM POSD W PIPEA GG Successor Job POSD W OUTBO UND Scheduling Restriction - Error Handling in Case of Cancellation Can be restarted Not in parallel with data loading Can be restarted 2. table space extension issues. Performance. Rule. Throughput and Backlog Monitoring: These requirements do not apply for message log review. This leads to a requirement to automatically distribute the detected errors to the responsible departments after the nightly batch run or within defined repetition periods and trigger follow up activities.1.task processing status Store. variant MC02) POSDW ERRLOG MC02.1. With an increasing number of issues identified the total revenue postings as well as follow on processes like replenishment or store analytics are heavily affected. Variant for MC01 Error messages provided by POS DM validation framework Monitoring Frequency / Data Collection After night batch or after periodically executed processing steps © 2008 SAP AG page 29/53 . or /POSDW/DISPLAY_MESSAGELOG.1.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2. error messages in Job Log Job Runtime.2 Monitoring Requirements: Error Monitoring: Transactions reporting errors within the data validation framework of POS DM (which comprises the tasks and checks as described in the previous chapters) need to be followed up because a detected error stops the actual processing of this single sales ticket.4 Further Monitoring Objects Monitoring Selection Object Criteria Technical . Message Category. or /POSDW/DISPLAY_MESSAGELOG. or /POSDW/DISPLAY_MESSAGELOG. Start Time SM37 Background Job POSDW ERRLOG MC04 (Report /POSDW/DISPLAY_MESSAGELOG) POSDW ERRLOG MC04. Message Class.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Tool on Satellite System SM37 Monitoring Frequency / Data Collection Every 5 minutes during every job execution Every 5 minutes during every job execution Every 5 minutes during every job execution Every 5 minutes during every job execution Background Job POSDW ERRLOG MC01 (Report /POSDW/DISPLAY_MESSAGELOG. Start Time SM37 Background Job POSDW ERRLOG MC03 (Report /POSDW/DISPLAY_MESSAGELOG) POSDW ERRLOG MC03. Message number. Posting Date. or /POSDW/DISPLAY_MESSAGELOG.8.8. Message Priority Alert Analysis Tool on Satellite System /POSDW/ DISPLAY_ MESSAGE LOG. 2. job cancellation. Message Type. error messages in Job Log Job Runtime. job cancellation. Start Time Job Runtime.8. variant MC01) POSDW ERRLOG MC01. Start Time SM37 2. error messages in Job Log Background Job POSDW ERRLOG MC02 (Report /POSDW/DISPLAY_MESSAGELOG. error messages in Job Log Job Runtime. job cancellation. job cancellation. 5 Monitoring without SAP Solution Manager Monitoring Objects: 1.8. 000 000 022 023 Message System Error .1. master data) MC03Application related messages (for example. additionally a criticality level can be defined per message using the message priority field. Variant for MC02 /POSDW/ DISPLAY_ MESSAGE LOG. Message number. This report can be found under the following report name: /POSDW/DISPLAY_MESSAGES_AGG If you need help in adopting this report please contact SAP Consulting. Variant for MC03 /POSDW/ DISPLAY_ MESSAGE LOG. Due to the nature of the report it has not been fully implemented and needs to be adopted to the project requirements. All statements mentioned above keep their validity. assignment can change for different projects) /POSDW/IMG/ POS Inbound Processing Messages Message Category MC01Technical or system messages (for example. Message Class. missing delta queue init) MC02Business related messages (for example.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Business -task processing status Store. Message number. Message Type. missing configuration) MC04Data consistency messages (for example. Message Type. Task processing status of transactions and related error log messages. 2. 3. providing for example capabilities to identify sales values related to errors. Rule. Rule. Rule. Program /POSDW/DISPLAY_MESSAGELOG Project specific enhanced version of the error report Within the provided SAP POS DM delivery an error report for more detailed error reporting is provided as a template. Message Class. Use POS DM message customizing to define message categories and assign messages. Message Priority Store. Message Priority Error messages provided by POS DM validation framework /POSDW/ DISPLAY_ MESSAGE LOG. Message Priority Store. Message Class. Variant for MC04 After night batch or after periodically executed processing steps After night batch or after periodically executed processing steps After night batch or after periodically executed processing steps Application . Posting Date. Message number. Message Category. Message Category. Example: (list is not complete. Posting Date.task processing status Error messages provided by POS DM validation framework 2. Message Type. Posting Date.Please Inform System Administration Error during archiving Error decrypting payment card number Invalid payment card GUID during decryption of payment card number © 2008 SAP AG page 30/53 . Message Category. missing data or store software issues) /POSDW/IMG/ MC01 Message ID /POSDW/COMMON /POSDW/COMMON /POSDW/COMMON /POSDW/COMMON POS Inbound Processing Messages Error Messages for Error Category Msg No.task processing status Error messages provided by POS DM validation framework Data consistency . index &2 already exists for &3 © 2008 SAP AG page 31/53 . 003 004 025 Unknown store number &1 Message Unknown EAN/UPC number &1 Unknown material number &1 MC03 Message ID /POSDW/AGGREGATION /POSDW/CORE /POSDW/CORE /POSDW/CORE /POSDW/CORE /POSDW/CORE /POSDW/CORE /POSDW/CORE /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT Msg No. 000 000 Message Sum of items does not equal the payment sum POS transaction for &1.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound /POSDW/COMMON /POSDW/COMMON /POSDW/COMMON 024 025 026 Error encrypting payment card number Duplicate payment card GUID during save of encrypted number Posting error during save of encrypted payment card number MC02 Message ID /POSDW/CORE /POSDW/CORE /POSDW/CORE Msg No. All 007 008 009 010 011 012 013 005 006 007 008 009 010 011 012 013 014 015 All messages Message Unknown sales item type &1 Unknown tax type &1 Unknown discount type &1 Unknown means of payment type &1 Unknown financial transaction type &1 Unknown goods movement type &1 Unknown reason &1 Other internal errors that occurred during preparation of IDoc Message type WPUBON can only contain sales transactions Transactions can only contain data from the same store No logical system exists Message type WPUWBW can only contain goods movement transactions Only sales or goods receipt transactions may be used for the F&R Engine No connection to remote system or destination not maintained Function module does not exist in the remote system Message type WPUTAB can only contain sales transactions Message type WPUFIB can only contain financial transactions Message type WPUUMS can only contain sales transactions MC04 Message ID /POSDW/ACTION /POSDW/CONDITIONS Msg No. 1 hour after data processing /POSDW /PIPE_D ISPATC HER - Scheduling Restriction Not in parallel with POS Data Insertion in PIPE or data processing step. restrict data selection variant by date (volume) Not in parallel with POS Data Insertion in PIPE or data processing step.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound with index &4 /POSDW/CONDITIONS /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT /POSDW/OUTPUT All 016 017 018 019 020 021 022 023 024 All messages Credit card settlement: Credit card data is incomplete Credit card number incorrect: Card number & does not go with type & Credit card settlement: Amount & in currency & has already been settled Credit card settlement: Amount & in currency & is not authorized Credit card settlement: No data to transfer to external system Credit card settlement: Error in transfer to external system Credit card settlement: Error connecting to the external system Credit card confirmation: Transaction was not settled completely Credit card confirmation: Settlement status initial or incorrect Credit card confirmation: Credit card details incorrect /POSDW/OUTPUT 025 2. 1 hour after /POSDW /PIPEDI - Can be restarted © 2008 SAP AG page 32/53 . 1 hour after data processing /POSDW /PIPEDI SPATCH ER - Can be restarted POSDW ERRLOG MC03 /POSDW /DISPLA MC03 Daily. POSDW PIPEAGG or POSDW PIPECHECK) the monitoring jobs can be planned according to the processing schedule of the data distribution jobs.1. Scheduling of Background Jobs (run these as a chain of job steps) Recommended ABAP Variant ScheduPredeSucor Generated Report ling cessor cessor Job Name Job Job POSDW ERRLOG MC01 /POSDW /DISPLA Y_MESS AGELO G MC01 Daily.6 Scheduling of Background Jobs Job Scheduling Requirements: Scheduling to collect the messages associated with the mentioned monitoring objects should be done after the actual inbound processing. In case of intraday processing (for example. restrict data selection variant by date (volume) Not in parallel with POS Error Handling in Case of Cancellation Can be restarted POSDW ERRLOG MC02 /POSDW /DISPLA Y_MESS AGELO G MC02 Daily.8. This can be done online using the POS Workbench or by using a scheduled job to check the messages of the corresponding task. Additionally. where the day closing transaction number is 173 and the next day’s opening transaction number needs to be 174. e.9 Business Process Step 4e: Data Consistency between POS System and PIPE 2.g. 2.9. This is done to ensure that no transactions or transaction details are lost during the data transfer. Additionally a check needs to be carried out to verify for each store/day combination if transactional and totals data have been received at the end of day. This is attached against a processing step and will raise a warning © 2008 SAP AG page 33/53 . the monitoring can be done using the sequencing pre-condition functionality provided with SAP POS DM. Example: A cashier processes 50 transactions during working hours. At the end of day the POS calculates the total figures and sends them to SAP POS DM. In most cases transactions are created in a logical and timely sequence. All situations where a store is not communicating at all should be handled within the interface monitoring. starting with 123 and ending with 173.9. restrict data selection variant by date (volume) Can be restarted 2.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Y_MESS AGELO G data processing SPATCH ER POSDW ERRLOG MC04 /POSDW /DISPLA Y_MESS AGELO G MC04 Daily. restrict data selection variant by date (volume) Not in parallel with POS Data Insertion in PIPE or data processing step. Depending on the POS solution provided the numbering could be based on Store. In a second step the check report is going to check for the existence of transactional data and totals for the current date. An error message is provided whenever only one of the data streams has arrived.1.1 Description General Information: After loading the transactional data to SAP POS DM the completeness of this information needs to be confirmed. The inbound interface supports the receiving of calculated end of day figures for various KPIs like total sales value by sales type or total payment value by payment type.1.taxes and total number of transactions. 1 hour after data processing /POSDW /PIPEDI SPATCH ER - Data Insertion in PIPE or data processing step. In order to verify the transaction sequence. POS or different transaction types. Additionally sequences across day can be detected. the monitoring can be done using the totals balancing functionality provided with SAP POS DM.2 Monitoring Requirements: Error Monitoring: In order to verify the content of transactions after store closing. the sequence of the POS transactions can be verified. Within POS DM the validation framework compares the incoming totals with the collected transactional data.1. These will be compared against the detailed transactional data by summarizing on the same level of granularity. as well as discounts. error messages in Job Log Job Runtime.1.1.9. Posting Date. or /POSDW/PIPE_DISPATCH ER. Use POS DM message log report to check if specific totals balancing errors occurred.1. 2. to be combined in a message category: Message class: /POSDW/CONDITIONS 003&1: Number of counted items (&2) &3 higher than in totals record (&4) 004&1: Number of counted items (&2) is &3 lower than in totals record (&4) 005&1: Value of counted items (&2) is &3 higher than in totals record (&4) 006&1: Value of counted items (&2) is &3 lower than in totals record (&4) For the sequencing check. Message number. Online balancing using Totals balancing in the POS Workbench 2. Rule. or /POSDW/DISPLAY_MESS AGELOG. Use the data validation framework in SAP POS DM to balance the transactional data against the provided totals data 3.5 Monitoring without SAP Solution Manager Monitoring Objects: 1. Message Category. error messages in Job Log Background Job POSDW ERRLOG MC04 (Report /POSDW/DISPLAY_MESSAGELOG) POSDW ERRLOG MC04.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound message against the next transaction after the gap. Throughput and Backlog Monitoring: These requirements do not apply for the data consistency check.g. List of messages. Performance. job cancellation.9. Variant MC04 After end of day processing 2. the following monitoring objects exist: © 2008 SAP AG page 34/53 .4 Further Monitoring Objects Selection Criteria Alert Analysis Tool on Satellite System /POSDW/MON0 or /POSDW/MON2 Monitoring Object Online totals balancing and transaction sequence monitoring Data consistency task processing status Monitoring Frequency / Data Collection Online Store. The processing of the sequencing check task can be done online using the POS Workbench or by using a scheduled job. job cancellation.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Tool on Satellite System SM37 Monitoring Frequency / Data Collection Every 5 minutes during every job execution Every 5 minutes during every job execution Background Job POSDW PIPECHECK (Report /POSDW/PIPE_DISPATCHER) POSDW PIPECHECK.9. Message Priority Error messages provided by POS DM validation framework Error messages provided by POS DM validation framework /POSDW/ DISPLAY_ MESSAGE LOG. Start Time Job Runtime. Start Time SM37 2. e. Message Class. Message Type. after data processing Scheduling Predecessor Job Data loading to SAP POS DM POSDW PIPETO TALS Successor Job - Scheduling Restriction - Error Handling in Case of Cancellation Can be restarted POSDW ERRLOG MC04 MC04 - Not in parallel with POS Data Insertion in PIPE or data processing step. to be combined in a message category: Message class: /POSDW/CONDITIONS 002 POS transaction &3 is missing: POS &1. Only after having received the full amount of data in ERP. type &2 2. there is a © 2008 SAP AG page 35/53 . Depending on the project implementation not all of these IDoc types might apply. restrict data selection variant by date (volume) Can be restarted 2. The job name would be POSDW CONSCHECKS. Use the pre-condition functionality of the POS DM data validation framework to perform sequence checking.9.1 Description General Information: The data validated in POS DM needs to be selected. The stores send their sales data at 10 pm in the evening. The variant for the data consistency check should contain the totals balancing task as well as the transaction sequencing task.1. condensed and transferred to the ERP system. IDocs should not be transferred immediately but collected and sent as a bulk to ERP. For performance reasons.g. Use POS DM message log report to check whether sequencing errors occurred.6 Scheduling of Background Jobs Job Scheduling Requirements: Data consistency checking should be run once a day after store closing to make sure that no data got stuck on the way to the center so that follow on processes can rely on this information. Scheduling of Background Jobs Recommended ABAP Variant or Generated Report Job Name POSDW PIPECHECK /POSDW /PIPE_DI SPATCH ER /POSDW /DISPLA Y_MESS AGELO G CONSC HECKS Daily as part of batch processing Daily. Example: The replenishment in ERP needs to be started at 1 am at the latest. the corresponding partner agreement should be set to “collect IDocs” using transaction WE20.10. In this example. The IDoc types generated for SAP for Retail are: WPUBON for detailed transaction data WPUUMS for aggregated sales information WPUWBW for goods movement data WPUTAB for aggregated payment type data WPUFIB for financial transaction data. In order to activate the collection of IDocs.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 1. At around 11 pm the data is completely transferred to POS DM.1. 2. List of messages. It is therefore important that the available time window for this process is kept. can the replenishment process in ERP begin.10 Business Process Step 5: Send Data to SAP for Retail (P03) 2. e.1. Every missing or delayed data falsifies the replenishment calculation in ERP. aggregation. job cancellation.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Tool on Satellite System Transaction WE05 in POS DM system Monitoring Frequency / Data Collection Daily after execution of the relevant task IDoc Creation Status Direction. Partner type.1. error messages in Job Log Job Runtime. WPUWBW IDocs in status ‘error’ Number of contained entries Transaction SM58 in POS DM system SM37 Daily after execution of the relevant task Every 5 minutes during every job execution Every 5 minutes during every job execution Background Job POSDW PIPE2ERP SALES (Report /POSDW/PIPEDISPATCHER) Job Runtime. Performance. Port. 2. In this scenario alerts are requested more to notify the status of the overall processing whereas for real-time processing alerts are expected for the arriving messages individually shortly after their posting to the application. IDoc age.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound time window of 2 hours for collection. WPUBON. or /POSDW/PIPEDISPATCHER. Port. In this scenario the handling of errors needs to be organized and the system needs to be monitored on a constant basis. Message function.1. Message type. Most projects use POS Data in a bulk process. WPUTAB. job cancellation. (in hours) IDoc transmission status Direction. Message function. automated monitoring capabilities using CCMS alerts and/or solution manager are vital. Real-time scenarios bare special requirements to automation and performance. Message code. 2.10. Basic type. Start Time SM37 © 2008 SAP AG page 36/53 . Basic type. IDoc age. where the data is processed once during the evening hours of the day. error messages in Job Log Background Job IDOC2ERP SALES RSEOUT00) POSDW (Report POSDW IDOC2ERP SALES. sending of the POS data and the inbound processing of this data on the ERP side. Message type. Partner number. Some projects have requirements for real-time or near real-time processing. Throughput and Backlog Monitoring: The requirements of chapter 2. Please refer to SAP Consulting for further hints and guidance in this process.1. or RSEOUT00. Partner type.10. In order to reduce manual work in this process. Partner function. Partner function. Message code. (in hours) POSDW PIPE2ERP SALES.2 Monitoring Requirements: Error Monitoring: It is important that the data is fully transferred and arrives on time in the ERP system.3. In the project landscape two major approaches can be found. Partner number. Start Time Number of WPUUMS.2 apply for SAP Retail processing as well. WPUUMS.1.6 Scheduling of Background Jobs Job Scheduling Requirements: To transfer data via IDocs from POS DM to SAP for Retail several steps are required starting with the creation of the IDocs with the PIPE task-processing program.11. For example unknown EAN codes in the range of 415… are always to be replaced by the generic EAN code x. daily bulk processing should be used wherever possible.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2. After execution of the job. WPUTAB for aggregated payment type information. transaction /POSDW/MON2 can be used.4 Further Monitoring Objects Monitoring Selection Object Criteria Sales transaction status Task processing status Alert Analysis Tool on Satellite System /POSDW/MON2 in POS DM /POSDW/MON0 in POS DM Monitoring Frequency / Data Collection Every hour or daily depending on uploading scenario Daily after execution of the relevant task Number of Sales transactions in error Number of sales transactions in error after processing 2. In order to only display erroneous transactions.10. In order to achieve the highest level of line item aggregation and in order to reduce the number of follow-on documents in SAP for Retail.10.1 Description General Information: The IDocs WPUBON. The status of the sales transactions posted to the POS DM solution. 4. WPUWBW. the RFC layer needs to be checked via transaction SM58 2.1. the program that transfers these IDocs to SAP for Retail and the program that posts these IDocs to the target modules in SAP for Retail (see next chapter). After execution of the IDoc transfer job. Depending on the update frequency this sequence can be run only once in the evening/night or for some IDoc types the sequence might be required to run several times up to every couple of minutes in exceptional cases. The transaction should not show one transaction in error.10. the IDoc status needs to be checked. an error handling list should be established. 2. After executing the job to create the POS IDocs WPUUMS for aggregated sales data.1. WPUFIB and other Retail-specific IDocs are © 2008 SAP AG page 37/53 .5 Monitoring without SAP Solution Manager Monitoring Objects: 1. Scheduling of Background Jobs Recommended ABAP Variant or Generated Report Job Name POSDW PIPE2ERP SALES /POSDW /PIPEDI SPATCH ER SALES_ DAILY Daily at 22:30 Scheduling Predecessor Job POS IDoc Inbound Job if applicabl e POSDW PIPE2E RP SALES Successor Job Job for IDoc sending Scheduling Restriction Not in parallel with POS Data Insertion in PIPE None Error Handling in Case of Cancellation Can be restarted if system error POSDW IDOC2ERP SALES RSEOU T00 SALES_ DAILY Daily at 23:00 IDoc Inbound in ERP Can be restarted 2.1. If some usual errors occur. These steps are usually organized in a sequence of depending jobs.1.11 Business Process Step 6: Post data within SAP for Retail (PO4) 2. the status of the corresponding task needs to be checked with transaction /POSDW/MON0 3. per IDoc. (in hours) Amount of sent IDocs Processing time of IDocs from end-to-end. It is important to know however that retail specific POS IDoc-Types (WPU*) in error does not necessarily mean that nothing has been processed as it is the case for most other IDoc types. cancelled IDocs due to lock situations. The ECC POS Monitor shows. 2. In order to guarantee an availability of correct data in the morning hours.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound processed and passed to: . the standard single-step replenishment scenario is described). While parallel processing using the standard IDoc dispatcher RBDAPP01 is feasible for small data volumes. Additionally. the number of errors and can give an impression at what extent incoming IDocs were or were not processed. The error rate during processing should be continuously improved to zero. Criticality: As for the processing in PIPE. Average time required for processing an IDoc. timely escalation routines should be in place for this processing. Performance. application log (spool) © 2008 SAP AG page 38/53 . Partner number. Retail POS IDocs can be partially processed.1.11.MM/FI in order to update the stock levels and values and to post to the appropriate accounts in FI . Message function. it is highly recommended to use the dedicated POS Inbound dispatcher RWPOS_PARA_ENQUEUE for this purpose because of its enhanced retail-specific dynamic parallelization mechanism (which takes into account article/site lock situations). long runtimes. Port.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Tool on Satellite System Monitoring Frequency / Data Collection Every 15 minutes Inbound IDocs WPUxxx: Collective processing runtime Direction. Therefore it is important not to copy IDocs for reprocessing as this may result in duplicate postings in SAP for Retail. The ECC POS Monitor (transaction WPER). which is a level higher in the business function hierarchy.11. Total Thruput. Unprocessed IDocs may endanger the data integrity for the replenishment follow-on process. Minimal/Maximal processing Time WE05. Partner type. Message type. which arrive after the program has been started.1. In case of erroneous IDoc error states. Message code.2 apply for this process step in SAP Retail as well. nightly job sequence without the possibility of manual intervention or correction.3.SD/FI in order to create invoicing documents and to post to the appropriate accounts in FI (here. this program is capable of refreshing its work list once started. IDoc age. is able to serve as an application-level error monitoring and handling tool.1. This is very important as processing is carried out in most cases in an automated. Partner function. Throughput and Backlog Monitoring: The requirements of chapter 2. This way – contrary to RBDAPP01 – IDocs are taken into account. canceled jobs should be alerted and the jobs restarted immediately. STAD. Basic type. 2.2 Monitoring Requirements: Error Monitoring: Errors in IDoc processing should be followed and the reasons for the processing errors corrected. RWPOS_PARA_EN QUEUE. missing data or customizing are critical for the daily business. 1. error messages in Job Log SM37 Every 5 minutes during every job execution 2.1. Message function.1. job cancellation. Message function. Also the creation of related documents can be followed and monitored here.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Inbound IDocs WPUxx: Application postings check Direction. The possibility of refreshing the IDoc work list during runtime should be used in order to make sure that arriving IDocs are processed as soon as possible even if the job already started before the IDocs arrived.12 Business Process Step 7: Update BI Info Cubes (P05) 2. (in hours) Direction. The status of the processed and to be processed IDocs can be checked with transaction WPER and the generic IDoc monitoring transactions. IDoc age. or RWPOS_PARA_ENQUE UE. Start Time IDoc application errors while final processing to ECC application WPER POS Monitor Every 15 minutes IDoc Inbound processing status Cancelled job for program RWPOS_PARA_EN QUEUE SM37 Every 15 minutes Background Job POS INBOUND DISPATCHER. Partner number. 2. Scheduling of Background Jobs Recommended ABAP Variant or Generated Report Job Name POS INBOUND DISPATCHER RWPOS _PARA_ ENQUE UE SALES_ DAILY Scheduling Daily at 24:00 Predecessor Job IDoc creation and transfer jobs in PIPE Successor Job Job for IDoc sending Scheduling Restriction Not in parallel to other goods movements for stores Error Handling in Case of Cancellation Can be restarted if system error 2. Port. Port.4 Monitoring without SAP Solution Manager Monitoring Objects: 1. The jobs used to transfer and post the IDocs must be monitored. Partner type. Basic type. 2. Partner type. Message type. Message type.1 Description General Information: Data is put into the delta queue by PIPE task processing. Basic type.11.1.12. This process should be monitored to guarantee that BI reporting shows accurate values on the following day.5 Scheduling of Background Jobs Job Scheduling Requirements: The program RWPOS_PARA_ENQUEUE should be used in order to post Retail specific POS Inbound IDocs. Message code. (Report RWPOS_PARA_ENQUE UE) Job Runtime. The data sources used by the POS DM Analytics content are: 0RT_PA_TRAN_CONTROL © 2008 SAP AG page 39/53 . Partner function.11. (in hours) POS INBOUND DISPATCHER. IDoc age. Partner number. Data is transferred to BW using normal BI Data transfer processes. Message code. Partner function. through iterative monitoring and tuning where applicable. including goods receipts. 2. Backlog Monitoring: Backlog requirements for BI updates apply like error monitoring (e.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 0RT_PA_TRAN_GDS_MOV 0RT_PA_TRAN_MOV_FIN 0RT_PA_TRAN_TOTALS For monitoring of BI Data transfer processes please refer to the generic BI documentation ‘Periodic Jobs and Tasks in SAP BW” under https://service. Error Monitoring: Erroneous sales data in F&R jeopardizes correct forecasting values. application log for PIPE Dispatcher messages. Performance and Throughput Monitoring: Runtimes and throughput KPIs should be established and regularly monitored to detect possible negative trends of update performance. Backlog Monitoring: As with error Monitoring.g. thus endangering the optimal merchandise flow when too few or too many items are replenished by F&R.1 Description General Information: SAP F&R (SAP Forecasting and Replenishment) receives daily consumption information for F&R relevant stores and articles from PIPE. the job log for more general issues and spool information and the POS DM message log report. e.13. as early as possible. 2.sap. including applied discounts.com/solutionmanagerbp.13 Business Process Step 8: Update SAP F&R (P06) 2. stock adjustments. Backlogs therefore need to be addressed immediately for the next F&R run to process correctly.12.g. Performance and throughput KPIs to assess F&R time series updates therefore are needed to ensure these cutoff times can be kept.1. 2. Performance and Throughput Monitoring: Depending on the cutoff times for internal (stock transfer oders) or external (purchase orders to vendor) replenishment. The consumption data is based on the following information provided by the store: Sales information. The interface used to connect to SAP F&R is a RFC call to the time series interface /FRE/BIF_TSD_INBOUND2. caused by increasing data volume. goods issues. Backlogs in F&R time series data to be posted may render forecasting values to be incorrect for the business (order quantities too low or too high for fulfilling customer demands).2 Monitoring Requirements: As the interface to F&R is implemented as a processed task like every other follow-on processing in PIPE for the monitoring all requirements apply as before: the POS Workbench for application and technical messages.1. pending erroneous update packages prevent subsequent packages from becoming active for reporting).13. This interface is populated using a PIPE task.2 Monitoring Requirements: Error Monitoring: Missing or inaccurate BI updates of POS sales endanger the validity of business decisions relying on this data.1. Reviewing the statuses of BI data loads therefore should be an integral part of daily monitoring routine. © 2008 SAP AG page 40/53 .1. Additionally basic RFC monitoring applies here. Goods movements. the timely execution of tasks within F&R is critical for an undisrupted business flow. promotion numbers etc. 1.1. Message Type. 2.13. Message number.4 Error messages provided during PIPE Report /POSDW/DISPLAY_ MESSAGELOG Online or batch 2.4 Further Monitoring Objects Monitoring Selection Object Criteria Online message monitoring Alert Analysis Tool on Satellite System /POSDW/MON0 or /POSDW/MON2 Monitoring Frequency / Data Collection Online Error messages provided by POS DM validation framework Store.1. Variant DAILYCONS) POSDW PIPE2CONS.13. Sub-object.5 Monitoring without SAP Solution Manager Monitoring Objects: 1.4.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2. transaction /POSDW/MON2 can be used. Program Job Name. Start Time Job Runtime. After executing the PIPE dispatcher job to supply the relevant data to F&R. Rule. Start Time Error messages provided by PIPE Dispatcher Spool entries PIPE Dispatcher Job SM37 Every 5 minutes during every job execution Every 5 minutes during every job execution Job POSDW PIPE2CONS (Report /POSDW/PIPEDISPATCHER. transaction.1. or /POSDW/PIPEDISPA TCHER. The status of the sales transactions posted to the POS DM solution. the status of the job and the corresponding task needs to be checked with transaction /POSDW/MON0 or the message log application 2. usually some time after data loading but before the FRP run. error messages in Job Log SM37 2. Message Priority Task processing status as per chapter 2. Posting Date. © 2008 SAP AG page 41/53 .13. user. Message Category. Message Class. In order to only display erroneous transactions.3 Monitoring Objects in SAP Solution Manager Monitoring Object Selection Criteria Alert Analysis Tool on Satellite System SLG1 Monitoring Frequency / Data Collection Every 60 minutes Application log Object.6 Scheduling of Background Jobs Job Scheduling Requirements: The job needs to be scheduled according to F&R requirements.13. job cancellation. Example: POS Sales transactions use.14. 0rpa_marm. This data needs to be extracted on a regular basis. 0plant.com/solutionmanagerbp. the current stock levels are required. 0rpa_mean. POS transaction may run into errors the following day as some articles might be unknown to POS DM.sap.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound Scheduling of Background Jobs Recommended ABAP Variant or Generated Report Job Name POSDW PIPE2CONS /POSDW /PIPEDI SPATCH ER DAILY CONS Scheduling Daily depending on F&R timelines Predecessor Job - Successor Job - Scheduling Restriction Not in parallel with POS Data Insertion in PIPE Error Handling in Case of Cancellation Can be restarted if system error Additional information can be found in the F&R related Best Practice document for Solution Management “Manage Operations for an IS-Retail Solution Forecast & Replenishment”. If the data is not extracted correctly. The relevant info objects are: 0material.1. article types and so on.1. In order to be able to enrich this data for reporting information like merchandise categories. EAN numbers as a reference for the sold article. master data needs to be extracted from SAP for Retail. DSO (data storage object) for 0mat_plant For monitoring of BI Data transfer processes please refer to the generic BI documentation ‘Periodic Jobs and Tasks in SAP BW” under https://service.1 Description General Information: In order to verify the incoming data in PIPE.14 Business Process Step 9: Extraction of Master Data for BI (P07) 2. in most cases. 2. © 2008 SAP AG page 42/53 . definition of monitoring objects. 2006. This document will outline possibilities on how to optimally monitor ALE-based interfaces manually as well as automated by using SAP Solution Manager.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 3 3. monitoring frequencies. monitoring tools. 3. Please note that these documents are also available in the SAP Service Marketplace using alias “RunSAP” RunSAP Best Practices. 2003 For information on how to monitor and tune the general system performance see the book: Thomas Schneider. 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. definition of monitoring activities including error handling procedures. The concept aims to define procedures for business process oriented monitoring and error handling and escalation procedures for your company’s ERP core business processes.sap. 3. SAP Performance Optimization Guide.2 Related Best Practice Documents There are several other Best Practice documents available on the Service Marketplace under https://service.3 Literature For detailed information on how to administer an SAP R/3 system see the book: Liane Will. MS excel to MS Excel or MS Excel to job scheduling tool). 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. SAP R/3 System Administration. These procedures intend to ensure a smooth and reliable flow of the core business processes so that your business requirements are met. This integrated process will avoid error-prone and time intensive manual processes of copying redundant data from one data source to another (for example. the definition of communication and escalation procedures and the assignment of responsibilities.1 Further Information Troubleshooting If executing this Best Practice did not produce the desired results: Search for related notes in SAPNet. Restartability and Escalation of every step). These documents are: General Business Process Management: This document explains the procedures you should use to create a general Business Process Management concept.com/solutionmanagerbp that relate to this Best Practice document. ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus on ALE Monitoring for your SAP solution. SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a Business Process Monitoring concept for your SAP ERP solution. © 2008 SAP AG page 43/53 . This includes the definition and documentation of the core business processes. Open an SAP Customer Message describing your problem (please see the respective component in section Error Handling. com/message.sap. You can do this at http://service.4 Feedback and Questions Send any feedback by formulating an SAP customer message to component SV-SMG-MON-BPM.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 3. © 2008 SAP AG page 44/53 . Check 'Business Processes': select a business process for application monitoring. Check for your chosen business process: choose process steps to monitor. here 'Background Job'. You will only get a short overview about the Setup. 7. Choose the key figures Job Cancellation to monitor error messages in Job Log and Job Log Messages © 2008 SAP AG page 45/53 . Choose your solution. Enter the information to be used to identify the job in this case the Job Name POSDW POS2PIPE POSLOG or the ABAP Program Name /POSDW/IDIS 8. For more information see the Best Practice Document Background Job Monitoring. 1. In the following section you find for each of the Monitoring Tools one example how you can set up the Monitoring within the SAP Solution Manager. 6. 5. 3. Check for your chosen step: Choose type of monitor. 2. 4. 4.1 Example Background Job Monitoring Background Job Monitoring of Background Job POSDW POS2PIPE POSLOG (Report /POSDW/IDIS) in SAP Solution Manager the setup for the other Jobs is except of the Job specific parameters quite similar. Call the SAP Solution Manager (trx DSWP or SOLUTION_MANAGER). Go to 'Operation Setup' and navigate to 'Solution Monitoring' => 'Business Process Monitoring'.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 4 Appendix In the following section you find for each of the Monitoring Tools one example how you can set up the Monitoring within the SAP Solution Manager. if you need more information see the Documentation in Service Marketplace. 9. Select the interface to be monitored by flagging the checkbox in the ‘Select’-field. IDoc. business process engine) and using different adapter types (such as File-. If you do not want to receive RED alerts. message type E for Error. The setup of IDoc monitoring will be done in the Setup Business Process Monitoring session. The Monitoring Schedule should be ones a day 10. This complexity makes it difficult to track and monitor the flow of a specific message.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound You find the information about the Message class and Message number in the Job Log of the Job you Choose the job form the F4 input help and specify the want to monitor. The information how you can set up the Business Process Monitoring for PI Messages for all different scenarios you can find in chapter 9 “SAP PI Message Processing Monitoring” in the Setup Guide Interface Monitoring in the SAP Solution Manager. 4. leave this field blank or set the same value as the threshold for RED. At least one business process with steps on different systems and defined interfaces must be available before it is possible to configure IDoc monitoring. Wildcard can be used for the other parameters. generate the monitoring customizing and activate the monitoring within the 'Business Process Monitoring' session. RNIF-adapters etc.2 Example PI Message Process Monitoring The message flow via SP PI can be very complex passing different components (such as adapter engine(s) with the module processor and messaging system.). Please look into the Setup Guide Interface Monitoring if you need more information regarding the setup procedure. JMS-. 4. If you want to receive YELLOW alerts. WPUBON and WPUUMS in SAP Solution Manager the setup for other IDoc Types is very similar. Once you have entered all relevant information for the monitoring objects. integration engine(s) with their pipeline processing including Java&ABAP proxies. leave this field blank or set it to a value that will never be reached.3 Example ALE / IDoc Monitoring Example IDoc Monitoring for IDocs /POSDW/POSTR_CREATEMULTIPLE. 1.Select Monitoring Type Navigate to the business process you intend to monitor and go to node ‘Interface Monitoring’. © 2008 SAP AG page 46/53 . © 2008 SAP AG page 47/53 .Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2.Select Key Figures The next open node (‘<Monitoring Object Name>’) lists the available key figures. Parameters ‘Direction’ and ‘IDoc Age (in hours)’ are mandatory. Double-click on the counter ‘001’ to open a selection screen where you maintain header information of this monitoring object. In tab ‘Detail Information’ the selection criteria of the key figures have to be specified. Select Delta Number Monitor and / or Total Number Monitor depending on your IDoc monitoring concept. Here. you can adjust time and frequency of the data collection.g.Status Counter: e. E. It is therefore recommended to set that value higher or equal to 15 minutes. .Generate and activate the customizing afterwards. Customizing example: . 51 for IDoc in error . SAP messages are identified with SAP. Again double-click on the counter in tab ‘Key Figures’ to specify further details of the monitoring.) After you have entered and confirmed your selection criteria. 5 minutes . as the data collector reads EDI tables which can grow very large.g. However.Status Message ID: e. The data collection frequency for IDoc Monitoring is hard coded to 15 minutes. © 2008 SAP AG page 48/53 . 3.Status Age (in min): e. for 'more than' and 'less than' at the same time. You can define threshold values in both directions.Status Message Qualifier: The field identifies the origin of the messages which are transmitted in the status. The flag for ‘Data Collection in Background’ is set automatically. E0 . If only one direction should be evaluated leave the other field blank! 4. Thus.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound The customizing of the data collection can be done in tab ‘Monitoring Schedule’. the column 'Period [min]' determines the frequency how often the measured value is evaluated. Parameter ‘Status Number(s)’ is mandatory.g. 099 . Return to tab ‘Delta Number Monitor’ / ‘Total Number Monitor’ to specify the thresholds for alerting. 2 (This means.g. the tab ‘Parameter Value Ranges’ will appear where an overview of your customizing is displayed.Specify Key Figures After saving the subnodes ‘Delta Number Monitor’ and / or ‘Total Number Monitor’ will appear.g.Status Message Number: e. dialog processing of the data collection would impact the performance of the satellite system too much.Status Number(s): e. the IDoc has to be at least 2 times in status 51 before being alerted.g. Enter the called program name in the “Value 1 “ field and enter the function module in the “Value 2” field. Choose the Application Monitor Dialog Performance Monitor with the technical name “BOPERFMO” 3. Please take a look at the Setup Guide … 1. 4. how often the data collector is supposed to run.e.4 Example Dialog Performance Monitoring Example Dialog Performance Monitoring. 2. This is the time window in which the corresponding statistical records are summarized and for which an average value is calculated. You can maintain the program name and function module together or individually. Choose the Key Figure “Total response time”. The smallest possible value is 5 minutes which is usually most appropriate for the Dialog Performance Monitor. RFC statistics are evaluated. For call type R (RFC). Choose the Monitoring Type “Application Monitor”. i. The default value is 60 minutes. © 2008 SAP AG page 49/53 .Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 4. 5. In the second tab strip of node Dialog Performance Monitor you specify the data collector period in column DC Period. © 2008 SAP AG page 50/53 . 1. 4.Generate and activate the customizing afterwards.5 Example Application Log Monitoring For detail info how to Setup the Application Log Monitoring see Setup Guide Business Process Monitoring in Service Marketplace. Choose the Monitoring Object Application Log.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 5. and must be configured in a such a way that it can detect critical situations for step"TLOG". The application log monitor allows you to evaluate logs. XML_IN (Import POS Transactions as XML File). Unless otherwise specified. 3. user. the jobs must be scheduled manually. see SAP Note 16083. check for the current job status (refer to SAP R/3 documentation CD.for example. Unfortunately. Contact the program scheduling management in order to clarify when the job will be fully defined. choose the required schedule type from the input help (F4) for the first column on the "Monitoring Schedule" tab page and save your entries. program. or even if a scheduled job has finished. Note that a daily monitoring of the job log using Solution Manager is recommended. the wild card "*" is set automatically. chapter background processing) and proceed as follows: In the case of status scheduled. You can configure data collection to run on either a weekly or monthly basis. subobjects. system performance may get worse over time. the job has been fully defined including a start condition and waits for the condition to fulfill.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound 2. Use the F4 input help to select the level of aggregation on which data evaluation is to be carried out (per "L"og. Unless otherwise specified. the input help (F4) for the object and subobject may contain some suggestions. aggregation is automatically set to "L". "D"ay.g. Select the alert types you want to configure and specify the combinations of object. If these periodic jobs do not run. deleting obsolete jobs or spool objects. component BC-CCM. transaction. Error Handling Procedures for Batch Jobs In case one of the scheduled jobs fails. 4. or "H"our). Choose Object = /POSDW/PIPE (Log for POS Data Management) and the right Sub-object e. Therefore. Note: If transactions have been specified for the business process step in the Solution Directory. if one of the necessary jobs is not scheduled. For more information. and aggregation. but the start condition has not yet been defined.6 Background Jobs Certain jobs must run periodically in a production SAP Retail System . © 2008 SAP AG page 51/53 .The object must be specified explicitly. In the case of status released. the job steps have already been defined. To switch between these two options. there is currently no easy-to-use support for such jobs in Basis Customizing. Monitoring Schedule 4. You can use the wild card "*" for all other fields except the aggregation. Program scheduling management has to check whether the job ran in the given timeframe. contact the software monitoring team. contact the software monitoring team and investigate why the error occurred. clarify why he did so and whether (and if. when) the job has to be re-run. etc. the start condition of a released job has been met. the job has terminated abnormally. In case of an SAP standard program search for appropriate messages in SAPNet and open a customer message if you cannot solve the problem.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound In the case of status ready. updates. If the job exceeded the given timeframe. The start of succeeding jobs might be also delayed due to the restart of the aborted job. message logs. In the case of status cancelled. possible succeeding jobs or dependencies on other jobs must be considered when restarting the aborted job. Check if the job is within the given timeframe. If a program in a job step produced an error such as issuing an ‘E’ or ‘A’ error message. Escalation Procedures If it is not possible for any of your support levels to provide a solution for a particular problem. depending on the data volume to be processed. © 2008 SAP AG page 52/53 . and software monitoring team and/ or application support have to check the respective job results (such as spool output lists. If an administrator intentionally cancelled the job. In the case of status active. Job Restartability In case of the cancellation of a background job. the job is currently running and cannot be modified or deleted anymore. all steps that make up this job have completed successfully. Check for particular dependencies on other jobs. which can happen in two ways.). it is recommended to open a customer problem message in the SAPNet R/3 front-end system. A job scheduler has put the job in line to wait for an available background work process. In the case of status finished. and/or development. links. SAP does not warrant the accuracy or completeness of the information. Parallel Sysplex. Outlook. UNIX. WinFrame. or noninfringement. X/Open. S/390.Best Practice for Solution Operations Manage Operations for SAP for Retail: POS Inbound © Copyright 2008 SAP AG. This limitation shall not apply in cases of intent or gross negligence. The information in this document is proprietary to SAP. used under license for technology invented and implemented by Netscape. XML. Data contained in this document serves informational purposes only. and Motif are registered trademarks of the Open Group. OS/400. OS/390. fitness for a particular purpose. National product specifications may vary. or transmitted in any form or for any purpose without the express prior written permission of SAP AG. and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business. product strategy. No part of this document may be reproduced. Program Neighborhood. All other product and service names mentioned are the trademarks of their respective companies. R/3. indirect. DB2. pSeries. Java is a registered trademark of Sun Microsystems. Inc. MaxDB is a trademark of MySQL AB. xSeries. Tivoli. Please note that this document is subject to change and may be changed by SAP at any time without notice. XHTML and W3C are trademarks or registered trademarks of W3C®. xApp. World Wide Web Consortium. 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. or consequential damages that may result from the use of these materials. The statutory liability for personal injury and defective products is not affected. including but not limited to the implied warranties of merchantability. OS/2. SAP shall have no liability for damages of any kind including without limitation direct. MetaFrame. HTML. AIX. mySAP. © 2008 SAP AG page 53/53 . Netfinity. xApps. Citrix. WebSphere. graphics. JavaScript is a registered trademark of Sun Microsystems. or other items contained within this material. Massachusetts Institute of Technology. This document is provided without a warranty of any kind. Intelligent Miner. AS/400. and MultiWin are trademarks or registered trademarks of Citrix Systems. VideoFrame. text. developments. Microsoft. Inc. SAP. SAP NetWeaver. and Informix are trademarks or registered trademarks of IBM Corporation. All Rights Reserved. z/OS. AFP. The information contained herein may be changed without prior notice. Inc. special. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. This document contains only intended strategies. OSF/1. IBM. iSeries.. SAP assumes no responsibility for errors or omissions in this document. Sweden. mySAP. zSeries.com. DB2 Universal Database. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. copied. Windows. and PowerPoint are registered trademarks of Microsoft Corporation. MVS/ESA. 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. ICA. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. Oracle is a registered trademark of Oracle Corporation. either express or implied.