Data Collector for SAP Advanced Planner and Optimizer (APO) Status: 12/09/08

Transcription

1 Data Collector for SAP Advanced Planner and Optimizer (APO) Status: 12/09/08

2 Contents THE DATA COLLECTOR FOR SAP APO FEATURES 3 THE FOLLOWING SECTIONS DESCRIBE THE MAIN MONITORING FEATURES:...4 APO CIF Monitoring...4 livecache Monitoring...5 The Optimizer...7 General Checks...8 The APO data collector is available for the following APO versions:...9 Performance Data...9 Copyright REALTECH 2008 Page 2 of 9

3 The Data Collector for SAP APO Features Advanced Planner and Optimizer is a Supply Chain Management (SCM) application that consists of the following modules: Demand Planning (DP) Production Planning & Detailed Scheduling (PPS) Supply Network Planning & Developing (SNP) Global Availability to Promise (GATP) Supply Chain Cockpit (SCC) Requirements such as rapid data access and the bi-directional exchange of data between the Supply Chain application and, in particular, the R/3 core modules FI, SD and HR, call for a new architecture that is somewhat different that R/3's current architecture. The APO server, the heart of the application, consists of a standard R/3 system. The server is extended by tables that are specific to planning and BW analyses. It contains all of the necessary functions (transactions, reports...) for APO and BW in a multi-tier software model (APO => BW => application base => Basis). APO uses key technology such as qrfc to communicate with the linked R/3 systems and connect the APO server to the so-called livecache. livecache is a main memory database that stores data in SAP DB's relational database. The application server processes connect to livecache in the same way that other SAP DB client applications do, whilst at the same time maintaining a connection to the APO server's relational database. Rapid access is achieved by storing the relevant business objects and modification programs in main memory as COM objects. The programs, which are loaded when the database is started, are stored on the livecache server in Dynamic Link Libraries (DLLs). Forecasts are stored in the APO system; however, the main transaction volume is stored in livecache. In the event of a failure, the data that is stored in livecache can be recovered. However, such a recovery is very time consuming because the transactional data can only be retrieved from the R/3 systems it's stored in. When livecache is properly shutdown, the data is written to the SAP DB database, which is normally only run in DEMO mode (no logging). Copyright REALTECH 2008 Page 3 of 9

4 The Optimizer is an external component that optimizes livecache by collecting and evaluating statistical data. Every problem that occurs on the APO server or livecache will disrupt the operation of R/3 applications on the satellite systems. To ensure the systems continued high-availability, monitoring and timely corrective action are of particular importance. The following components should be monitored: qrfc connections (e.g. queue length) livecache (e.g. configuration, runtime performance) SAP DB (e.g. fill rate) Backup routines Optimizer Consistency of the SAP Core Interface (CIF) Optimal results are obtained by using both the REALTECH APO, and for special DB monitoring, the REALTECH SAP DB data collectors. The following sections describe the main monitoring features: APO CIF Monitoring qrfc Ping This connection test is twofold: First the availability of the connection to the APO clients is tested in the APO system itself, and then the so-called external CIF connections (RFC lines) of the R/3 systems that are connected to APO are tested. The collector automatically recognizes all of the connections that need to be tested and requests them periodically based on a user-definable interval (the default is 5 minutes). A red alert is generated if a connection failure is found. qrfc Queue Length Among other things, the number of entries per destination queue provides an indication of the APO system's processing speed. If there are problems processing a queue, the jobs may be assigned to another queue. Threshold values that determine the number of queue entries that are required to generate a yellow or red alert are specified in a customization table. The collector is scheduled to run at user-definable intervals (the default is 5 minutes). qrfc Queue State A queue that is being processed can show a number of statuses. The collector checks if a queue has a failure status, in which case a red alert is generated. Copyright REALTECH 2008 Page 4 of 9

5 qrfc Runtime The runtime of a queue's job also provides an indication of the APO system's processing speed. If a queue's currently active job exceeds a pre-defined runtime (e.g. APO's upload program has fallen into an endless loop or the process has halted) a yellow or red alert will be generated based on the settings. By default, a yellow alert is generated is the job's runtime exceeds 5 minutes and a red alert is generated if the job's runtime exceeds 15 minutes. Both of these threshold values are user-definable. Logging/Debugging The collector checks the current logging and debugging settings of the user that is registered in the RFC connection for all CIF connections. Logging and debugging default values can be individually defined for each user. A red alert is generated as soon as the actual value deviates from the default. Consistency of the SAP Core Interface (CIF) The collector checks the consistency of the SAP Core Interface. For the check, the data collector examines the APO-specific tables for inconsistencies. If inconsistencies will be found the data collector generates alerts providing information about how many inconsistencies have been found and which logical systems (SAP R/3) are affected. livecache Monitoring External Heartbeat The collector uses an external program (DBMCLI) to periodically check if an SAP instance is able to access livecache. A red alert is generated when a failure occurs. Heartbeat livecache can have a number of statuses. livecache is working properly when it has a status of WARM. By default, the status is checked every 5 minutes; however, this value is userdefinable. A red alert is generated if any other status then WARM is detected. System Error Messages At user-definable intervals (the default is every 5 minutes), the collector reads the System Error Message log file. Every error message is reported as a red alert. A customization table is used to suppress notification of specific error messages and/or to modify how error messages are evaluated. Copyright REALTECH 2008 Page 5 of 9

6 Synchronous BAPI Logging & Archive Logging A customization table is used to set the logging level ( livecache logging switched off, "synchronous logging turned on") and the archive logging (ON/OFF) for each client. A red alert is generated as soon as the actual value deviates from the default. Connection to livecache The connection to livecache is checked according to the specified interval. In addition to the connection tests, the system also checks if the appropriate entries for LDA (primary connection for multi-connect) and LCA (secondary connection) are present in the DBCON table. OMS Data Cache, Converter Cache The Object Management System (OMS) stores and manages the business objects. The data blocks are stored in cache for rapid access, and the references to the physical blocks are stored in the SYSTEMDEVSAPCE. Storing the references in the so-called converted cache enables them to be accessed more quickly. After each run, the collector reports the actual OMS data cache usage values and hit ratio as well as the hit ratio for the converter cache. These values can be used for creating a performance graphic. Status Checks The collector periodically checks the status of: Database Full YES/NO Diagnosis Monitoring ON/OFF Monitoring ON/OFF Vtrace ON/OFF A red alert is generated as soon as the actual value deviates from the default, which is black and bold. Initialization Log File The initialization log file is refreshed every time livecache is started and initialized. The collector searches the last log file for errors. The strings that the collector searches for in the log file are defined in a customization table. The "*" (asterisk) wildcard can be used in the string definitions. The alert threshold can be determined at the string level. Copyright REALTECH 2008 Page 6 of 9

7 Functional Check / Simulation A report is used to check livecache's function ability. Test data is written to and read and deleted from the LC. A red alert is generated if an error occurs during the simulation. The last erroneous log file is always saved so that analyses can be performed at a later stage. COM Routines Application functions are implemented in livecache as C++/COM routines. These functions enable the objects to be modified directly in memory. Trace Level The collector checks if at least one trace level is active. A red alert is generated when an active trace level is found. Runtime (COM routines) A COM routine's average runtime can provide an indication of the system's utilization. A customization table is used to define a COM routine's average response time. A red alert is generated when a defined response time is exceeded. The Optimizer Connection to the APO System The collector checks if the RFC connection to the individual Optimizers is available. All of the configured and active Optimizers are checked. A red alert is generated if one of the Optimizers cannot be reached. Runtime In general, an Optimizer is manually started and should only be active for a limited period so that it doesn't decrease system performance. An entry is written to the APO log file every time an Optimizer is started. The collector checks the age of the entries in the log table. A yellow or red alert is generated if the entry in the log table is older than the defined threshold value. This does not necessarily mean that the Optimizer is still active, but rather that the system could not delete the entry. Problems can occur if an entry cannot be made for a specific Optimizer because its maximum number of 10 entries has been reached. Copyright REALTECH 2008 Page 7 of 9

8 General Checks Application Log The application log is periodically read. A customization table is used to define a log file's selection criteria. The system uses the object, sub-object and problem class to determine if a yellow or red alert must be generated. The "*" (asterisk) wildcard can be used in the object and sub-object fields. Copyright REALTECH 2008 Page 8 of 9

9 The APO data collector is available for the following APO versions: SAP APO 2.0, 3.0, 3.1 Since version 4.0, the functionality of the SAP R/3 Enterprise data collector is integrated into the APO data collector. With it, the APO data collector provides monitoring functionality above the R/3 data collector. Performance Data Performance statistics for SAP activities according to Transaction Groups, User Groups or Job Groups are monitored with an additional data collector (SAP Performance DC). This one is precondition for alerting, for reporting and for Service Level Analysis on these objects. Details can be found in the Technical White Paper" on ABAP-Suite ". The SAP Performance DC is a package with the SAP R/3, SAP R/3 Enterprise, APO, CRM and BW data collectors. All target availabilities published in this brochure refer to predicted, non-binding general availability dates of a product or a product component! Knowledge powered by REALTECH Further information about REALTECH S software solutions: REALTECH AG Industriestraße 39c Walldorf Germany Tel Fax customerservices@realtech.com Copyright REALTECH 2008 Page 9 of 9