Your SlideShare is downloading. ×
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Ale monitoring
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ale monitoring

3,362

Published on

1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,362
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
131
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ALE Monitoring Best Practice for Solution Management  Version Date: 16.05.2007 Contents 1  Introduction .............................................................................................................................3  1.1  Applicability, Goals, and Requirements...............................................................................3  1.2  Best Practice Procedure.....................................................................................................5  1.2.1  Motivation for Interface Monitoring .............................................................................5  1.2.2  Preliminary Tasks.......................................................................................................5  1.2.3  Interface Monitoring concept ......................................................................................5  1.2.4  Legend ......................................................................................................................5  1.3  General Overview on ALE/EDI............................................................................................6  1.3.1  ALE (Application Link Enabling) .................................................................................6  1.3.2  EDI (Electronic Data Interchange) ..............................................................................6  1.3.3  IDocs .........................................................................................................................6  1.3.4  Change Pointers: .......................................................................................................7  1.3.5  ALE Processing Modes..............................................................................................7  1.4  Example Business Scenario with ALE...............................................................................15  1.4.1  Interface Monitoring in SAP CCMS and SAP Solution Manager................................15 2  Aspect: Error Monitoring........................................................................................................23  2.1  Manual Error Monitoring ...................................................................................................25  2.2  Automated Error Monitoring..............................................................................................28  2.3  Details on IDoc Batch Job Monitoring ...............................................................................29  2.4  Handling different error statuses ALE/EDI .........................................................................30  2.4.1  Status 02: Error passing data to port.........................................................................30  2.4.2  Status 03:.................................................................................................................30  2.4.3  Status 26: Error during syntax check of IDoc (outbound)...........................................30  2.4.4  Statuses 27, 29, 37: IDOC processing towards tRFC layer has problems .................31  2.4.5  Status 51: Application document not posted .............................................................31  2.4.6  Status 56: IDoc with errors added [anything missing?] ..............................................32  Status 63: Error passing IDoc to application...........................................................................32  2.4.7  Status 60: Error during syntax check of IDoc (inbound).............................................32  2.4.8  Status 65: Error in ALE service.................................................................................32  2.4.9  Reposting of IDocs in Status Error............................................................................33 3  Aspect: Backlog Monitoring ...................................................................................................36  3.1  Manual Backlog Monitoring ..............................................................................................36  3.2  Examples of Backlog Analysis techniques ........................................................................38
  • 2. Best Practice: ALE Monitoring  2  3.2.1  Single IDoc time stamp analysis...............................................................................38  3.3  Automated Backlog Monitoring .........................................................................................39 4  Aspect: Performance Monitoring............................................................................................41  4.1  Manual Performance Monitoring.......................................................................................41  4.1.1  Overview of Available Tools for ALE/EDI Performance Analysis ................................44  4.1.2  Activation of Performance Monitoring With Transaction ST03N ................................48  4.2  Automated Performance Monitoring .................................................................................56 5  Aspect: Resource Monitoring.................................................................................................57  5.1  Manual Resource Monitoring............................................................................................58  5.2  Automated Resource Monitoring.......................................................................................61 6  Aspect: Data Management ....................................................................................................62  6.1  Manual Data Volume Monitoring.......................................................................................64  6.2  Automated Data Volume Monitoring..................................................................................64 7  Generic Part on System Monitoring .......................................................................................65  7.1  Performance Monitoring ...................................................................................................65  7.1.1  General information .................................................................................................65  7.1.2  Procedure ................................................................................................................66  7.1.3  Transaction ST03N ..................................................................................................67  7.1.4  Transaction STAD....................................................................................................68  7.1.5  Transaction ST05.....................................................................................................72  7.1.6  Transaction SE30 ....................................................................................................72  7.1.7  Transaction ST12.....................................................................................................73  7.2  General Monitoring Guidelines for a SAP System .............................................................74 8  Further Information................................................................................................................77© 2007 SAP AG  2 
  • 3. 1 Introduction1.1 Applicability, Goals, and Requirements To ensure that this Best Practice is the one you need, consider the following goals and requirements. Goal of Using this Service This Best Practice helps you set up an Interface Monitoring concept with the focus on ALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitor ALE­based interfaces manually as well as automated by using SAP Solution Manager. Both monitoring approaches aim to detect any irregularities or deviations or to detect error situations at an early stage. These procedures intend to ensure that the interface processing meets the requirements for stability, performance and completeness as well as a smooth and reliable flow of the core business processes so that your business requirements are met. Alternative Practices You can have SAP experts deliver this Best Practice on­site by ordering a Solution Management Optimization (SMO) service for SAP Interface Management. This service is exclusively available within an SAP Support Engagement (that is, SAP MaxAttention, SAP Safeguarding or SAP Premium Support). Staff and Skills Requirements To implement this Best Practice, you require the following teams: Application Management Team This team provides the information on the business background of the interfaces used and knows the needed business requirements for the interfaces: · 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 (for example, 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.
  • 4. Best Practice: ALE Monitoring  4 Necessary or Useful Trainings  q  BIT300 ­ Interface Technology Overview  q  BIT350 ­ ALE Enhancements  q  SMO610 ­ BPM training course  q  ADM105 ­ Advanced R/3 System Administration  q  ADM315 ­ Workload Analysis System Requirements  To setup an automated IDoc monitoring on the SAP Solution Manager, the connected satellite  systems has to be at least of release 4.6C. To have all described monitoring object available in  SAP Solution Manager, add­ons ST­PI and ST­A/PI has to be installed on the SAP satellite  systems. Duration and Timing  Duration  Creating an Interface Monitoring concept depends very much on the complexity of your interface  landscape and could take around one week for about 10 ALE/IDoc interfaces.  Timing  The best time to apply this Best Practice is during the planning phase or during the implementation  phase of your SAP solution. How to use this Best Practice This document gives you an overview on interface monitoring tools and procedures for ALE/EDI monitoring. The aim is not to name all available monitors and tools but to focus on the more suitable monitors and tools for each of the aspects discussed. After having got a general idea on monitoring possibilities you should evaluate which are the critical error situations in your system landscape and individually decide which monitoring procedure is suitable in your case. We do not recommend setting up a full blown monitoring but recommend concentrating on selective alert situations that will inform you in exceptional cases. In the next step you can follow the setup procedure and implement the monitoring on your systems. In case of business process related monitoring objects you have the possibility to setup a business process monitoring focused monitoring concept and involve your application teams in monitoring and error resolution activities. For a better understanding on what should be monitored it is essential to understand the ALE processing mechanism. The first section is supposed to give you a general overview on ALE/EDI and introduces to you the automated ALE monitoring functionality within SAP Solution Manager using the example business process “Processing Purchase Orders”. Sections 2 to 6 list monitoring objects both for manual as well as automated monitoring procedure concentrating on the six major areas: Resource Monitoring, Error Monitoring, Backlog Monitoring, Performance Monitoring and Data Management. The monitoring object tables list the following information:  o  Monitoring object  o  Monitoring transaction or tool  o  Monitoring frequency  o  Indicator for an issue or error  o  Monitoring activity or error handling procedure  o  Responsibility  o  Escalation Procedure The last section Generic Part includes information on scenario independent tools, for example performance monitoring.© 2007 SAP AG  4 
  • 5. Best Practice: ALE Monitoring  5 1.2 Best Practice Procedure 1.2.1 Motivation for Interface Monitoring Today’s system landscapes are often decentralized and can consist of various interfaces. Different SAP systems, legacy environments and business entities are integrated using different interface technologies. All those interfaces need to be monitored in terms of resource availability, processing errors, backlog situations and performance. IT Operation relies completely on the fact of 100% data consistency. With an increased complexity of system landscapes we face an increased risk of data inconsistency. For early detection, specific data consistency reports have to be executed on a regular basis. Also detailed error handling and disaster recovery procedures need to be defined. A proactive interface monitoring helps to identify and avoid inconsistencies. 1.2.2 Preliminary Tasks Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in the system:· Complete all installation and post­installation actions and procedures including customizing· Ensure that the initial download has been successfully executed· Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations  resulting from customer problem messages· Implement all current SAP Support Packages upon availability 1.2.3 Interface Monitoring concept For a successful and efficient Interface Monitoring concept, a process for the execution of the monitoring concept has to be defined. This includes the definition of the roles and responsibilities involved. It has to be defined who is supposed to carry out which activity and how is the communication between the different roles within the support organization supposed to take place. An Interface Monitoring concept has to be tightly integrated with the support organization. This includes the integration with the Incident/Problem Management process and the Change Management process. These processes have to be adjusted so that communication and escalation procedures contained within these processes are adequate to support the Interface Monitoring concept. This includes the final communication of open alerts to SAP. Wherever communication connected with Interface Monitoring happens outside these support processes, separate communication and escalation paths and procedures have to be defined. See the separate Best Practice for General Business Process Management for further details. 1.2.4 Legend  This symbol indicates you a paragraph from where you can navigate to another section of this  document for more detailed information on a topic.  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.© 2007 SAP AG  5 
  • 6. Best Practice: ALE Monitoring  6 1.3 General Overview on ALE/EDI 1.3.1 ALE (Application Link Enabling) Application Link Enabling (ALE) is the technology used by SAP within one company to support distributed business processes across separate application components within the company’s landscape. ALE uses the business scenarios and function modules that allow transfer data to or from an SAP system without developing customer­specific programs. ALE is linked closely with Workflow Management within SAP. The data is not only transferred between the systems; in addition it can also trigger follow­up actions in the SAP system. From the SAP viewpoint, the following data can be exchanged via ALE: • Transaction data, which is data from applications • Master data, such as customer or material master data • Customizing data used for an overall ALE view Data can be exchanged between SAP Systems and external (non­SAP) systems. The following functions and interfaces form the basis of communication: • ALE with all its components such as monitoring, archiving, • Usage of the data container called Intermediate Document (IDoc) • Transactional RFC (tRFC) 1.3.2 EDI (Electronic Data Interchange) EDI is a standard format for exchanging business data. It describes the document exchange with business partners on a technical level. With EDI the technical structure of the document is retained. EDI describes the mapping of the application data structure from the sender into the EDI standard, and from the EDI standard into the application data structure of the recipient. This enables the recipient to automatically process the document by his business software. The standard is ANSI X12 and it was developed by the Data Interchange Standards Association. ANSI X12 is either closely coordinated with or is being merged with an international standard, EDIFACT. 1.3.3 IDocs IDocs are predefined data structures of SAP applications at the interface level. IDoc types form the container for the data to be exchanged. Each application has a special set of IDoc types, which provides data to be exchanged. IDocs can be used to exchange data between two R/3 systems or between R/3 and an external system (non SAP). Instead of calling a program in the destination system directly (RFC), the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. IDoc data exchange is always an asynchronous process. When communicating with an external system (non SAP) an EDI converter or subsystem such as Gentran receives the EDI messages in standardized format (such as EDIFACT), and then converts it to the IDoc format supported by SAP for further processing. ALE enables a controlled exchange of Intermediate Documents (IDocs) between application systems and is used for: · Separation and integration of operational units · Master and transactional data · Exchange with Business Partners via EDI© 2007 SAP AG  6 
  • 7. Best Practice: ALE Monitoring  7 Figure 1­1 Application Link Enabling / IDoc flow 1.3.4 Change Pointers: If you want to distribute master data changes with the SMD tool (Shared Master Data), changes to the master data objects are flagged for distribution by change pointers ( ® Master Data Distribution). Change pointers are basically the key fields of the table that contains the changed field. In ALE Customizing, customers can specify the fields that need to be distributed. The SMD tool is connected to the change document interface. If the master data changes are to be distributed (defined in ALE customizing), the application writes a change document. The contents of this are passed to the SMD tool. The tool writes change pointers, reads the application data and creates the master IDoc. The master IDoc is then passed to the ALE layer, which sends it to all interested systems. 1.3.5 ALE Processing Modes There are two basic ways to send IDocs via tRFC (ALE) or via flat file (EDI). The method of sending is determined by the port type and depends on the technical configuration of the target system. It is configured using transaction WE21 (ports in IDoc processing). The port type is specified in transaction WE20 (partner profiles) choose partner and select relevant outbound parameter. Figure 1­2 Transaction WE20 ­ ALE processing mode© 2007 SAP AG  7 
  • 8. Best Practice: ALE Monitoring  8 1.3.5.1 ALE ­ tRFC Most common between R/3 systems is the (asynchronous) transactional RFC interface (standard ALE scenario)  Ÿ  Integrated business processes across distributed systems within one company  Ÿ  Example: replication of master data between several SAP Systems  Ÿ  Distribution of master data, transactional data, and control data  Ÿ  This occurs during application Customizing The advantages of transactional Remote Function Calls (tRFC) over synchronous and asynchronous RFCs are:  Ÿ  The calls are buffered, even if the recipient partner is not active. When the partner is  available again, a new attempt can be made to transfer the data.  Ÿ  If an SAP system receives the data, the requests are handled as transactions. This  means that all functions called in one tRFC are either processed together or not at all.  Ÿ  Each tRFC is sent exactly once, so that there are no accidental double postings of  application data.  Ÿ  All erroneous attempts to post data are displayed in the tRFC monitor. 1.3.5.2 EDI ­ Flat File Most common between R/3 system and EDI subsystem is the flat file interface (standard EDI scenario). An EDI subsystem/converter maps IDocs to international standard formats  Ÿ  SAP systems use Intermediate Document (IDoc) format to store application  documents for transfer  Ÿ  Examples of standard formats: UN/EDIFACT, ANSI X.12 1.3.5.3 Processing Modes Processing in the application layer and the ALE layer are completed on both the outbound and inbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface to the receiving system where it can be posted. Outbound and Inbound IDocs can either be processed individually (immediate transfer) or as a collection/package using a background job. This setting is made in the partner profile using transaction WE20. 1.3.5.3.1 Outbound IDoc Processing  Transaction WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Outbound Parameter.© 2007 SAP AG  8 
  • 9. Best Practice: ALE Monitoring  9 Figure 1­3 Transaction WE20 – Partner profile outbound When the output mode “Tars Immediately” is activated, IDocs are transferred immediately to the receiver system as soon as IDocs are created. There is a performance overhead associated to this technique as a new connection is opened for each IDoc sent, in addition the same programs,  user contexts, and  database tables are read multiple times. If immediate processing is implemented, the sender also has to wait for an acknowledgement about the success of the processing from the receiver. This could cause performance problems especially if runtime is quite long in the receiving system and could lead to backlogs if the sender is restricted in his parallel processing capabilities. It is recommended where possible (business requirements may dictate that immediate processing is required) to use the output mode “ Collect IDocs” . With the output mode “Collect IDocs” IDocs are collected and set as a package to the receiving system; this can save processing time because it usually avoids the overhead of opening multiple connections (only one connection opened per package) and loading the programs and user contexts, avoids reading common database tables from disk several times and so on. In addition to setting the collect flag “ collect IDocs”  the report RSEOUT00 needs to be scheduled on a regular basis as a background job (TA SM36). Using this report you can enter the maximum number of IDocs that should be transferred before a COMMIT WORK is set and the IDocs become blocked. If too high a number for “max number of IDocs” is selected, it can lead to runtime errors (for example Timeouts). In this case, you must choose a lower value. Packet Size: A general recommendation is between 50 and 100. However, it depends on a number of factors like size of the IDocs (in case of large IDocs a small package size is better) or network bandwidth. The packet size that suits best for a given interface should be carefully investigated using test runs or alternatively as part of an SAP Interface Management Optimization service.  For more information visit: http://service.sap.com/ifm ).© 2007 SAP AG  9 
  • 10. Best Practice: ALE Monitoring  10Figure 1­4 Report RSEOUT00© 2007 SAP AG  10 
  • 11. Best Practice: ALE Monitoring  111.3.5.3.2  Inbound IDoc Processing:  Transaction WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Inbound Parameter. Figure 1­5 Transaction WE20 – Partner Profile inbound Trigger Immediately: Upon receipt inbound IDocs are immediately released for posting. ALE inbound processing splits the IDoc packets into individual IDocs; this results in an overhead such as,. the same programs, user contexts, and database tables are read multiple times. Trigger by Background Program  It is important to note that if the receiver system uses trigger immediately option, whether IDocs are processed in the package or not depends on the character of the Inbound function module (if function module supports mass processing or not is defined in transaction BD51). If mass processing is not supported, IDocs will be posted one by one. Inbound IDocs and IDoc packets are first saved in the database into single IDocs. Single IDocs can be put into packets and then processed this functionality is provided by report RBDAPP01, which allows you to specify the package size for the RFC call. This type of package processing is valid for all IDoc types as there are no special requirements for the inbound function module. However there is limited optimization potential here as a commit is triggered for every processed IDoc because the ALE layer calls the function module several times in the same dialog process. This does however reduce the administrative load on the R/3 System because if packaging was not implemented, each IDoc would be processed in a new dialog process meaning, the same programs, user contexts, and database tables are read multiple times. If you use function modules that can process IDocs in mass, this has a significant optimization potential as overhead is reduced significantly.  This type of package processing can be used depending on the configuration of the Inbound function module used for an IDoc. This can be checked via transaction BD51. If the input type value is set to ‘0’ the function module is enabled for mass processing. In this case, one commit is triggered for all IDocs belonging to a packet. It offers additional© 2007 SAP AG  11 
  • 12. Best Practice: ALE Monitoring  12optimization potential apart from the loading of the programs and users contexts and avoids reading the common database.  It is recommended where possible (business requirements may dictate that immediate  processing is required) to use the inbound processing mode “Trigger by background program”. To do this carry out the steps below in ALE Customizing:  1. Set up background processing:  TA WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Inbound Parameter  Inbound processing mode should be set to: “Trigger by background program”  2. Schedule posting and configure packaging:  Create variants of report RBDAPP01 and schedule as required using transaction SM36. To  specify a package size use field pack size. As a guide, you should use a packet size of between  20 and 100 IDocs. Figure 1­6 Report RBDAPP01 Additionally, ensure that separate batch jobs for report RBDAPP01 are scheduled with variants that include all IDocs that are set to immediate processing; not just those that are set to be ‘triggered by a background program’. This leads to a tighter control on the handling of the incoming IDocs. (IDocs are configured to be posted immediately but if no free dialog work processes are available when Inbound IDocs are created they will remain unprocessed with status 64. IDocs will not be processed unless report RBDAPP01 is scheduled.)© 2007 SAP AG  12 
  • 13. Best Practice: ALE Monitoring  13Figure 1­7­1 Report RBDAPP01 – Parallel processing As illustrated above report RBDAPP01 can be configured to facilitate parallel inbound processing. Parallel processing can be used to improve performance and spread the load to a specific group of application servers. If the indicator “Parallel Processing Active” is set then the inbound processing of the application uses one free dialog process for each IDoc packet on the application server (asynchronous RFC is used for this). This means that the packets can be processed in parallel. If several IDoc packets have been selected, then the IDoc processing can occupy all the dialog processes on the application server. If the indicator is not set then the IDocs will not be processed in parallel. This means that each packet will be passed to the application in turn. Only one work process will be used for this action on the application server. The input field server group defines the RFC Server group which will be used by the report in parallel processing. Server groups are set up using transaction RZ12 below. Figure 1­8­2 Transaction RZ12 – RFC Server Group Maintenance Application servers in a server group can be used in parallel for updating IDocs in the background. There might be only one application server in a server group, however we recommend that you have multiple application servers configured for a server group so that the load can be balanced between the servers of a server group and also it improves availability. By default, a parallel­processed job uses all qualified servers in an SAP System according to automatic resource­allocation rules. However, by defining RFC groups, you can control which servers can be used for parallel­processed jobs. An RFC group specifies the set of allowed servers for a particular parallel­processed job. If you do not specify a server group, all dialog processes in the SAP system are used in parallel. This could result in resource shortages in the application servers.© 2007 SAP AG  13 
  • 14. Best Practice: ALE Monitoring  14Generally, SAP recommends (if resources allow) to have a dedicated group of servers to handle RFC communication and to have separate servers for DIALOG end users. If however, resources are not available, it is also possible to limit the amount of resources used by RFC by limiting the resources of the RFC server group – current resource configuration can be checked by double clicking the Group. (See figure 1­6­3 below). Figure 1­9­3 Transaction RZ12 – Determination of resources You can assign the above RFC resource parameters to these RFC server groups to limit the load generated from RFCs within an SAP system as described in SAP Notes 74141 and 99284  Note:  To implement packaging of IDocs for a flat file (using file port such as,. EDI), it must be verified in advance that the middleware/target system can handle files that include multiple IDocs. In addition a fixed file name should not be used as there is the risk that a file that has not yet been processed will be overwritten in the target system. Therefore the file port (WE21) should be configured to use a function module which generates dynamic file names such as, using a unique number (for example, IDoc number, MSGGUID or original application document number, and so on.). A timestamp would not suffice because if parallel processing was activated there is a possibility of the same timestamp being generated for two different files thus one will overwrite the other.© 2007 SAP AG  14 
  • 15. Best Practice: ALE Monitoring  151.4 Example Business Scenario with ALE For the different aspects of interface monitoring the SAP Solution Manager can be used. In this section we provide you an overview on its functionality with reference to the following example business scenario: PC Express is a midsize company. Its main business is buying PC components, composing them to pre­configured PCs and selling them within Europe. The sales department is divided between Great Britain, other EU countries and non EU European Countries. One of their core business processes is named “Processing Purchase Orders” and is maintained within the SAP Solution Manager.  IDoc  message flowFigure 1­10 Business Process: Processing Purchase Orders In the business process “Processing Purchase Orders” IDocs of message type ‘MATMAS’ (Material Master) are sent from the SAP ECC sender system to the SAP MM receiver system via an ALE distribution model. To monitor the IDoc flow from end­to­end the monitoring on the sending and the receiving system needs to be set up for the IDoc processing – in this example of message type ‘MATMAS’. 1.4.1 Interface Monitoring in SAP CCMS and SAP Solution  Manager For some monitoring activities it is possible to use a tool for automated monitoring. This is also possible with interface monitoring. Such automated monitoring is optimally implemented using Business Process Monitoring or System Monitoring in SAP Solution Manager. Business Process Monitoring (BPMon) within SAP Solution Manager is the proactive and process­ oriented monitoring of the core business processes of your company. It includes the observation of all technical and business application­specific functions that are required for a smooth and reliable flow of the business processes. Business Process Monitoring (BPMon) reveals even slight deviations from a pre­defined ideal business process state which would otherwise remain undetected until the flow of the process would be seriously impacted. It gives automated alerts including the possibility to notify these via various communication means like email, SMS and so on. Types of errors that can be monitored are for example errors from logs (system log, application log and so on), throughput and backlog KPIs for various applications, dialog performance, update errors, and so on The possibility to keep the alerts for a defined time allows to evaluate a kind of history and to identify trends in the alert occurrence at an early state. © 2007 SAP AG  15 
  • 16. Best Practice: ALE Monitoring  16For further details on Business Process Monitoring refer to http://service.sap.com/bpm. Wherever monitoring via SAP Solution Manager is possible you will find a separate table, indicating the relevant automatic monitoring functionalities. The approach of this section is to outline the setup procedure for a selective interface monitoring for messages involved in your core business processes. 1.4.1.1 Standard ALE/EDI Monitoring The Interface Monitoring functionalities are based on the SAP Computing Center Management System or CCMS Alert Monitor (transaction /NRZ20) and could be used independently of the SAP Solution Manager, if needed. The standard CCMS monitors on the satellite system show an ALE/EDI IDoc Monitoring for all message types in inbound and in outbound direction. The standard monitoring group can be found in transaction /NRZ20 ® SAP CCMS Technical Expert Monitors ® System / All Monitoring Segments / All Monitoring Context ® ALE/EDI <SID>(CLIENT) Log.sys ‘name of logical system’. Figure 1­11 CCMS ALE/EDI Standard Monitoring Groups 1.4.1.2 Specific ALE/EDI Monitoring Besides the standard monitoring objects available in SAP CCMS you can setup a specific ALE monitoring. This gives you the possibility to individually monitor IDocs which refer to certain business processes. In our example IDocs of type ‘MATMAS’ are exchanged between two SAP systems. This© 2007 SAP AG  16 
  • 17. Best Practice: ALE Monitoring  17interface is part of the core business process “Processing Purchase Orders” and is a critical interface which needs to be monitored on a regular basis. The customizing of ALE/EDI monitoring objects can be done with transaction BDMO. With transaction BDMO it is possible to create new monitoring objects only for a specific message type and to activate them accordingly. This can be done either in inbound or in outbound direction or both. If two SAP systems are involved you need to do the customizing on both the sending system (outbound direction) as well as the receiving system (inbound direction). System wise, these objects are considered as customizing. Therefore, they have to be set up in the development system and from there transported via the quality assurance system to the productive system. To create a new monitoring object the button Create/activate monitoring objects in the entry screen of transaction BDMO must be used. Figure 1­12 BDMO – Create/Activate Monitoring Objects In the following screen the new entry needs to be entered and set to active. Figure 1­13 BDMO – New Entry In some cases it might be necessary to re­call transaction BDMO to have the new entry available. In the entry screen it is now possible to select the newly created monitoring object. The following screen will pop up: Figure 1­14 BDMO – Customize Monitoring Object The specific message types for the inbound and/or outbound direction of an interface need to be specified. If one direction should not be monitored explicitly, it can be left blank. It is also possible to© 2007 SAP AG  17 
  • 18. Best Practice: ALE Monitoring  18specify more than one message type if needed. The system type of the partner system needs to be maintained as well as the system number from the partner (see transaction WE20). In section Period you can specify the number of days for the age of the IDocs that should be included into the evaluation. In field Wait time status changes OUT or field Wait time status changes IN you can specify a waiting time in minutes to change a status. If this time has not elapsed since the last status change, the previous status is used and not the last one. Use cases might be the following:  a.  Monitoring on the number of IDocs, which are in status 03 for longer than 60 minutes. Those  IDocs are sometimes processed on an hourly basis. Therefore it makes sense to evaluate the  IDocs in status 03 if they have not been processed since longer than 60 minutes.  b.  Monitoring on the number of IDocs, which are in status 51 for longer than 30 minutes. This  way the alerts are suppressed for IDocs which are “temporarily” in error status 51 because  their status might be changed by the next processing retry. But if this is not the case after 30  minutes they are counted as IDocs in status 51. In field Days until now you can specify the age for IDocs in days which won’t be included into the evaluation.  The Monitoring Object is created in a development system and is then regularly transported into  the productive environment. Hence the Partner no. that is specified in the development system  already has to be the connected productive system which should be monitored later on. If the same interface should be monitored on the sending system as well as on the receiving system, it is necessary to create the respective monitoring objects on both these systems; one for the outbound direction and the other for the inbound direction. To be able to assign both monitoring objects to the same interface in the SAP Solution Manager they must have exactly the same names. To actually create the monitoring objects, then choose Monitoring Object / Start all in the entrance screen of transaction BDMO. This will create new entries in the CCMS (transaction /NRZ20) and start the data collection for the ALE/EDI alerts but just once. The scheduling of a periodic background job needs to be done on every satellite system in transaction /NRZ21 ® Technical infrastructure ®method execution ® activate background dispatching. This way the program RBDMONI_CCMS_IDOC is scheduled in the background job SAP_CCMS_MONI_BATCH_DP, per default on an hourly basis. Depending on your requirements you can change the frequency to enable a more real­time alerting.  Test the runtime of this program during peak time and evaluate the additional system load  generated before transporting to your productive system!© 2007 SAP AG  18 
  • 19. Best Practice: ALE Monitoring  19After the program execution the created monitoring objects are generated in SAP CCMS:  Ar ea1  Ar ea 2  Ar ea 3Figure 1­15 ALE/EDI Specific Monitoring Objects Area 1: IDocs are generated via change pointers. Therefore the number of open change pointers is relevant for monitoring. Area 2: An IDoc changes its status during the message processing. In the SAP CCMS the main statuses are grouped together depending on the direction.  Ø  For outbound direction the following groups are available containing the listed statuses:  Ø  For inbound direction the following groups are available containing the listed statuses: Area 3: If the IDoc processing is done via tRFC you can monitor the number of remote calls waiting to be processed. The selection works for the RFC destination specified for the involved partner in the partner profile. To check the processing mode navigate to transaction WE20, select the partner number, select the message type and click on details. © 2007 SAP AG  19 
  • 20. Best Practice: ALE Monitoring  20Figure 1­16 tRFC settings for ALE processing  Per default the threshold values for the SAP CCMS MTEs are usually set too high and need to be adjusted either directly within SAP CCMS or within the SAP Solution Manager. 1.4.1.3 Implement Specific ALE/EDI Monitoring in SAP Solution Manager The setup of interface monitoring will be done in the Setup Business Process Monitoring session. At least one business process with steps on different systems and defined interfaces must be available before it is possible to configure interface monitoring. In node Interface Monitoring all existing interfaces for the corresponding business process and the selected steps are displayed, such as, all pairs of consecutive business process steps on different systems. To customize the interface, the required interface must be selected for Monitoring. To differentiate between the interfaces, Interface Name (per default “<Sender SID>><Receiver SID>”, the Interface Technique (for example, ALE/EDI, qRFC), Initial Step (usually the business process step that sends information), Final Step (usually the business process step that receives information), Sender and Receiver (SID respectively) are displayed. The Interface Name and the Interface Technique can be changed manually.© 2007 SAP AG  20 
  • 21. Best Practice: ALE Monitoring  21After saving the entries for every interface that is selected for monitoring a respective sub­node Interface “<Name of the Interface>“ (<Interface Technique>) will be created. Figure 1­17 Setup Interface Monitoring in SAP Solution Manager This sub­node is either used for loading Monitoring Objects from the connected local CCMS (for ALE/EDI, qRFC and tRFC this is described in the following sub­sections) or the sub­node is empty for all other Interface Techniques. 1.4.1.3.1  Implement ALE/EDI Interface Monitoring If an interface is selected for monitoring with the Interface Technique ALE or EDI, a sub­node appears: Interface “<Name of the Interface>“(<ALE or EDI>). It is now necessary to assign the previously created monitoring objects from the satellite system to the respective interface. This means that the objects must be loaded into the session. This happens with the push­button: Reload CCMS: ALE Mon Objects. All ALE/EDI monitoring objects available on the satellite systems (that is, Outbound­ objects on Sender side and Inbound­objects on Receiver side) are loaded into the session. This is not visible at first, but when the F4 value help is used for either SID or ALE Monitoring Object,  then all reloaded Monitoring Objects appear and can be selected for monitoring. Copy the selected objects and save. Figure 1­18 Use Value Help for ALE/EDI monitoring objects© 2007 SAP AG  21 
  • 22. Best Practice: ALE Monitoring  22A new sub node, Alert Monitors, appears. All Outbound alerts for the Sender system and all Inbound alerts for the Receiver system, relating to the Monitoring Objects selected in the node above, are loaded into the session. Additionally, all the corresponding threshold values are loaded from the local CCMS. The next step is to decide what kind of alert should be selected for monitoring. To transfer the threshold values for a single line from right to left, double­click the copy icon between them. To transfer all the threshold values at once, select "Copy All". It is also possible to change the threshold values for the alerts manually. When saved, the new values are transferred to the local CCMS of the monitored system. Figure 1­19 Selection of ALE/EDI related alerts© 2007 SAP AG  22 
  • 23. Best Practice: ALE Monitoring  232 Aspect: Error Monitoring From the previous sections, you know the general ALE processing mechanism and how to setup selective and automated IDoc monitoring within Business Process Monitoring in the SAP Solution Manager. The next sections will deal with individual aspects of interface monitoring. Error monitoring is intended to detect critical situations and exceptional cases during interface processing. As these incidents can endanger the entire data flow between the involved systems, their identification can be extremely important and time critical. Monitoring procedures should, therefore, ensure a clear visualization and prioritization of incidents to support their fast and effective resolution. Error Monitoring includes the monitoring of all error situations documented within the system. Error situations can be identified by the occurrence of error messages or error statuses. Each step in the processing of the IDoc has a different status number. All IDocs start with status 01 (IDoc generated) in Outbound, and the numbers from 01 to 49 are reserved for Outbound status (50­99 are Inbound status). The various error statuses which can occur for outbound and inbound IDocs and which should be monitored on a daily basis, are detailed below: Possible error statuses for Outbound IDocs  Code  Description  02  Error passing data to port  04  Error within control information of EDI subsystem  05  Error during translation  07  Error during syntax check  09  Error during interchange handling  11  Error during Dispatch  15  Interchange Acknowledgement negative  20  Error triggering EDI subsystem  21  Error passing data for test  23  Error during retransmission  25  Processing despite syntax error (outbound)  26  Error during syntax check of IDoc (outbound)  27  Error in dispatch level (ALE service)  29  Error in ALE Service  30  IDoc ready for dispatch (ALE service)  31  Error ­ no further processing  34  Error in control record of IDoc  36  Electronic signature not performed (timeout)  37  IDoc added incorrectly  40  Application Document not created in receiving system Possible error statuses for Inbound IDocs  Code  Description  51  Error: Application document not posted  52  Application document not fully posted  54  Error during formal application check  56  IDoc with errors added  57  Test IDoc: Error during application check  60  Error during syntax check of IDoc (inbound)© 2007 SAP AG  23 
  • 24. Best Practice: ALE Monitoring  24 61  Processing despite syntax error (inbound)  63  Error passing IDoc to application  65  Error in ALE service  68  Error ­ no further processing Monitoring Requirements: In a typical solution landscape, multiple systems and different interface technology are utilized. There are various tools for monitoring and problem analysis. The figure below shows the various technologies and the SAP tools we can use to monitor ALE/EDI scenarios in a solution landscape manually: Figure 2­1 Standard ALE processing error monitors Monitoring Objects: The figure below shows how data is distributed using ALE. Errors can occur at any of the 5 steps, so these steps represent our monitoring objects, that is: · Application creates IDoc + passes it to the ALE layer (Application layer (sender system)) · Outbound processing in the ALE layer (ALE layer (Sender system)) · IDoc sent to the receiving system in the communication layer (Communication layer)) · Inbound processing in the ALE layer (ALE layer (receiver system)) · IDoc passed to the Application (Application layer (receiver system))© 2007 SAP AG  24 
  • 25. Best Practice: ALE Monitoring  25Figure 2­2 ALE layers 2.1 Manual Error Monitoring As in the above description, the following table documents the handling of errors at the five processing statuses. Monitoring Objects w/o SAP Solution Manager Monitoring  Monitor  Monit.  Indicator  Monitoring Activity or  Respon­  Escalation Object  TA/Tool  Freq.  or Error  Error Handling  sibility  Procedure  Procedure Check if IDocs  BD87  As  IDoc in  Use BD87: enter  Business  Application were created  required  error or no  correct date/time frame  Process  Management successfully  by IDoc  and logical message  Operations  Team / by ‘Application  business  created  type. Double click on  Team /  Business Layer’ (sender  various statuses to get  SAP  Process system)  a list of IDocs. If IDoc is  Technology  Champion  found in failed status,  Operations  review status text for  Team  reason for failure. If  IDoc is not found,  check if interface is  configured to collect  and, if so, check if  background job is  running. IDocs in status  BD87  As  Existence  Call transaction  Business  Application “Error in  required  of the  BD87on receiving  Process  Management Application  by following  system. Choose  Operations  Team / Layer”  business  statuses:  timeframe and various  Team /  Business (receiver  51, 52, 54,  selection criteria. A list  SAP  Process system)  57,  of IDocs will be  Technology  Champion displayed for various  Operations  message types. It is  Team  possible to drill down to  display the IDoc and its  status records (by  double clicking).  For IDocs in status 51  BD87 will state whether  an application log exists  for the IDoc. If this is  the case you can drill  down to display the © 2007 SAP AG  25 
  • 26. Best Practice: ALE Monitoring  26 IDoc. If you double­click  on the IDoc status  record, an application  log pushbutton  becomes available in  the status record  display. If no button is  available, it means that  a detailed log is not  available. It may be  possible, however, to  get some information  using transaction  SLG1. You can specify  <*IDOC NUMBER*> in  field “External ID”. IDocs in status  BD87  As  Existence  Call transaction  Business  Application “Error in ALE  required  of the  BD87on sender  Process  Management layer ” (sender  by following  system. Choose  Operations  Team / system)  business  statuses:  timeframe and various  Team /  Business  02, 21, 26,  selection criteria. A list  SAP  Process  27, 29, 34,  of IDocs will be  Technology  Champion  37  displayed for various  Operations  message types. It is  Team  possible to drill down to  display the IDoc and its  status records (by  double clicking).  Analyze reason  accordingly. IDocs in status  BD87  As  Existence  Call transaction  Business  Application “Error in ALE  required  of the  BD87on receiver  Process  Management layer ”  by following  system. A list of IDocs  Operations  Team / (receiver  business  statuses:  will be displayed for  Team /  Business system)  56, 60, 63 ,  various message types.  SAP  Process  65,  It is possible to drill  Technology  Champion  down to display the  Operations  IDoc and its status  Team  records (by double  clicking).  Analyze  reason accordingly IDocs stuck in  SM58/BD  As  BD87  In BD87, choose  Business  Application commun­  87  required  shows  timeframe and check  Process  Management ication layer ”  by IDocs in  for IDocs in status 03. If  Operations  Team /  business  status 03  there are IDocs in  Team /  Business  status 03, ensure report  SAP  Process  SM58  RBDMOIND  Technology  Champion shows  Is running. If report is  Operations  tRFCs in  running check  Team  error status  transaction SM58 as  below.  In SM58, choose  timeframe to see a list  of tRFCs with errors.  Double­click to get  more details for each  tRFC. © 2007 SAP AG  26 
  • 27. Best Practice: ALE Monitoring  27Error in  BD87  As  Existence  Choose timeframe and  Business  Application external  required  of following  various selection  Process  Management system  by statuses  criteria on the sender  Operations  Team /  business  04, 05, 07,  system and analyze the  Team /  Business  08, 09, 11,  reasons in BD87.  SAP  Process  15, 17, 23,  Technology  Champion  36, 40  Operations  Team Inbound IDocs  WE08  As  Was the  Transaction WE08 ­>  Business  Application from flat file  required  file  double click on  Process  Management  by processed  directory check date of  Operations  Team /  business  recently for  last processing and last  Team /  Business  directory  IDoc/record number. If  SAP  Process  correspond  IDoc was not  Technology  Champion  ing to  processed recently, test  Operations  active EDI  access to specified  Team  scenario? If  directory using  not, there  transaction WE21 ­>  is a  choose file port and  problem.  perform an access test.  In addition check for  errors in BD87. Workflow  SWI2_DI  As  If listed  Call Transaction  Business  Application triggered by  AG  required  workitem it  SWI2_DIAG. Choose  Process  Management Inbound IDocs  by is in error  timeframe and various  Operations  Team /  business  selection criteria. A list  Team /  Business  of workflows will be  SAP  Process  displayed in error  Technology  Champion  status.  Operations  Double click on  Team  individual work items to  find out why they failed IDocs with  WE07  As  IDocs with  Call transaction WE07.  Business  Application errors  required  errors  Choose timeframe and  Process  Management  by various selection  Operations  Team /  business  criteria to display a list  Team /  Business  of IDocs with errors.  SAP  Process  Double click to drill  Technology  Champion  down to display IDoc  Operations  and status records.  Team IDoc  SM37  Once  Jobs with  Validate using  Business  Application background  daily  errors  transaction SM37 that  Process  Management jobs  the various ALE/EDI  Operations  Team /  background jobs are  Team /  Business  scheduled and are  SAP  Process  running successfully as  Technology  Champion listed below (this should  Operations  be done at least once a  Team  day). © 2007 SAP AG  27 
  • 28. Best Practice: ALE Monitoring  282.2 Automated Error Monitoring For details on how to setup the automated error monitoring, refer to the section Interface Monitoring in SAP CCMS and SAP Solution Manager. Automated Monitoring Objects with SAP Solution Manager Monitoring  Monitor  Monit  Indicator or  Monitoring  Respon­  Escalation Object  TA/Tool  Freq.  Error  Activity or  sibility  Procedure  Error  Handling  Procedure Outbound  SAP CCMS  Hourly  IDocs in this  Analyze the  Business  Application IDocs in  / SAP  status  reasons in  Process  Management status “Error  Solution  BD87  Operations  Team / in IDoc  Manager  Team /  Business interface”  SAP  Process (statuses: 02,  Technology  Champion 20, 21, 26,  Operations 27, 29, 34,  Team 37) Outbound  SAP CCMS  Hourly  IDocs in this  Analyze the  Business  Application IDocs in  / SAP  status  reasons in  Process  Management status “Error  Solution  BD87  Operations  Team / in external  Manager  Team /  Business system”  SAP  Process (statuses: 04,  Technology  Champion 05, 07, 08,  Operations 09, 11, 15,  Team 17, 23, 36, 40) Inbound  SAP CCMS  Hourly  IDocs in this  Analyze the  Business  Application IDocs in  / SAP  status  reasons in  Process  Management status “Error  Solution  BD87  Operations  Team / in  Manager  Team /  Business application”  SAP  Process (statuses: 51,  Technology  Champion 54, 57)  Operations  Team Inbound  SAP CCMS  Hourly  IDocs in this  Analyze the  Business  Application IDocs in  / SAP  status  reasons in  Process  Management status “Error  Solution  BD87  Operations  Team / in IDoc  Manager  Team /  Business Interface”  SAP  Process (statuses: 56,  Technology  Champion 60, 63, 65)  Operations  Team Background  SAP  As  Cancellations,  Analyze the  Business  Application jobs for IDoc  Solution  needed  Maximum  reason in  Process  Management processing  Manager  duration  SM37  Operations  Team / listed above  Team /  Business  SAP  Process  Technology  Champion  Operations  Team IDoc  SAP  As  Error  Analyze the  Business  Application processing  Workflow  needed  situations (by  reasons in  Process  Management monitoring  status)  BD87  Operations  Team / using SAP  Team /  Business workflow  SAP  Process© 2007 SAP AG  28 
  • 29. Best Practice: ALE Monitoring  29(refer to SAP  Technology  Champion note 116610)  Operations  Team Update  SAP  Hourly  Update errors  Analyze the  Business  Application errors for  Solution  V1 / V2  reasons in  Process  Management transactions  Manager  SM13  Operations  Team / or programs  Team  Business  Process  Champion tRFC errors  SAP CCMS /  Hourly  Too many  SM58  Business  Application (refer to  SAP  remote calls  Process  Management figure  Solution  waiting  Operations  Team / ALE/EDI  Manager  Team /  Business Specific  SAP  Process Monitoring  Technology  Champion Objects)  Operations  Team 2.3 Details on IDoc Batch Job Monitoring Confirm that the below background jobs are scheduled and are running successfully, using transaction SM37. Monitoring should include an assessment of: · Occurrence of failed/cancelled jobs: The job logs should be investigated to determine what  caused the error. Further information about the cause of the failure may be available in the  system log transaction SM21. · Job runtime: This depends on many factors (Functionality/activity of the job, hardware, system  resources etc). Therefore, we cannot give exact statements about performance indicators. If a  background job is deemed to be running long, investigate using the job log. It is also possible  to perform an ABAP or SQL trace using transaction ST12 see  Section 7 of this document. Typical Inbound jobs run programs:  1.  RBDAPP01 (posts IDocs)  2.  RBDMANI2 (posts status 51 IDocs) Typical Outbound jobs run programs  3.  RSNAST00 – WE15 (If using message control, you can check via partner profile  WE20). Also, validate message control is set up properly via NACE. (Creates IDocs)  4.  RSEOUT00 (sends IDocs – we14)  5.  RSARFCEX (clears IDocs out of ALE/RFC layer)  6.  RBDMOIND (changes IDoc from status 03 to 12)  7.  RBDMIDOC (Change Pointers, can check via BD50)© 2007 SAP AG  29 
  • 30. Best Practice: ALE Monitoring  302.4 Handling different error statuses ALE/EDI There are instructions below on issue resolution for the most important error statuses. 2.4.1 Status 02: Error passing data to port Common causes of error: · Access to the file system does not work, because a user has insufficient authorization to  relevant directory to write a file. · Directory might not exist · File System full. Analysis steps/Solution: Start by checking access to the outbound directory from each application server (WE21). If there is a problem with a specific application server, then the connection from this server to the outbound directory should be checked. Check if the directory exists and there is enough space left in the file system. Ensure that the user has at least assigned authorization object S_DATASET, see also SAP notes 334097 and 90111. 2.4.2 Status 03: Status 03 signifies that an IDoc in the sending system has been passed to tRFC, but it has not yet been input in the receiving system, this means that the tRFC call has not yet been executed. Common causes of error: · Report RBDMOIND not scheduled · tRFC call has failed · No ‘Commit Work’ statement has been issued in the application program which creates the  IDoc. Analysis steps/solution: The report RBDMOIND is responsible for the status change from 03 to 12: If an IDoc has been passed to tRFC (IDoc status 03), but has not yet been transferred to the receiving system.  If the report is running, but you still see a large number of IDocs in status 03 then proceed as follows: Call SM58 to analyze the problem in more detail. You should test the RFC connection. Maybe the network is down, or the receiving system does not have any dialog work processes available or there are other resource issues. If necessary, the Gateway developer trace needs to be reviewed and/or a RFC trace needs to be created and analyzed. To do so, use the transaction SM59, (See the note 532918 for more details). If this does not solve the problem, debug the application program that creates the IDoc. 2.4.3 Status 26: Error during syntax check of IDoc (outbound) Common causes of error: IDOC configuration is not correct; this should not happen in a productive system. Processing discontinued only if  “Cancel Processing After Syntax Error‘ is flagged in WE20 (Partner Profiles). The following checks are performed: · Mandatory segment is missing · Sequence of segments in a group in which the segment appears is incorrect · More segments exist in a segment group for the IDoc as defined for the basic IDoc type© 2007 SAP AG  30 
  • 31. Best Practice: ALE Monitoring  31Analysis steps/solution: · Check IDoc error status using transaction WE02/WE05 · Review IDoc structure using transaction ‘WE30’ · If necessary, debug the application transaction to the function IDOC_OUTPUT_<message  type> (in case of MC) or MASTERIDOC_CREATE_<message type>) (in case of direct  outbound processing). 2.4.4 Statuses 27, 29, 37: IDOC processing towards tRFC layer  has problems IDOC processing towards tRFC layer has problems. Common causes of error: · No relevant entry in partner profile · Receiver fields in IDoc header are not filled correctly Analysis steps/Solution: · Check IDoc error status using transaction WE02/WE05 · Review Partner Profile (WE20) and distribution model (BD64) · Check content of IDoc receiver fields in IDoc header · Debug the application program 2.4.5 Status 51: Application document not posted IDoc could not be posted. Common causes of error: · Problems within Application Customizing · Incorrect IDoc data · Programming errors Analysis steps/Solution: · Check IDoc error status using transaction BD87/WE02/ WE05 · Check Application log: For IDocs in status 51, transaction BD87 will state whether an  application log exists for the IDoc. If this is the case, you can drill down to display the IDoc.  When you double­click on the IDoc status record, an “application log pushbutton” becomes  available in the status record display. If no button is available it means that a detailed  log is not available. It may be possible, however, to get some information using  transaction SLG1 you can specify <*IDOC NUMBER*> in field “External ID”. · Debug the application, by setting a breakpoint in the relevant IDoc inbound function module  (WE20) · If IDocs are in status 51, you can try to reprocess the IDocs:  o  Automatic re­processing RBDMANI2: You can use the report RBDMANI2 to resubmit  the IDoc. The program can also be scheduled as a periodic job, to collect IDocs that  could not be posted because of a lock problem. This does not relieve you of  monitoring the IDocs to make sure that no other errors are present.  o  Resending IDoc: Check if the error can be resolved by changing the business­related  objects. If this is possible, you can reprocess the IDoc. If the error cannot be  corrected, then a new IDoc has to be created and the “old” IDoc has to marked for  deletion.  o  Manually edit IDoc: Check if you can manually correct the IDoc. Keep in mind that  some IDocs must not be changed according to local laws. When this is done, you can© 2007 SAP AG  31 
  • 32. Best Practice: ALE Monitoring  32 reprocess the IDoc. You will find more information below on reprocessing IDocs in  status 51. 2.4.6 Status 56: IDoc with errors added [anything missing?]  Status 63: Error passing IDoc to application Common causes of error: · Missing Inbound Partner Profile or inbound parameters are not defined in the inbound partner  profile. · IDoc contains characters that are not compatible with internal character set · Error in ALE service Analysis steps/Solution: · Check status error message in transaction BD87 or WE02/WE05 · Add or change Inbound Partner profile · Create conversion rule · Automatic re­processing using report RBDAGAI2 2.4.7 Status 60: Error during syntax check of IDoc (inbound) Processing is discontinued, only if “Cancel Processing After Syntax Error” is flagged in partner profile (transaction WE20). Common causes of error: · Mandatory segment is missing · Sequence of segments in a group in which the segment appears is incorrect · More segments exist in a segment group for the IDoc as defined for the basic IDoc type Analysis steps/Solution: · Check IDoc error status using transaction BD87 or WE02/WE05 · Review IDoc structure using transaction ‘WE30’ · In the case of EDI, analyze the structure of the IDoc file and check how the sender system fills  the parameters IDOC_CONTROL_REC_40 and IDOC_DATA_REC_40 of function module  ‘IDOC_INBOUND_ASYNCHRONOUS’ · Automatic re­processing using RBDSYNEI 2.4.8 Status 65: Error in ALE service Common causes of error: Filtering does not work Analysis steps/Solution: · Check IDoc error status using transaction BD87 or WE02/WE05 · Review ALE customizing using transaction ‘SALE’ · Automatic re­processing using RBDAGAI2© 2007 SAP AG  32 
  • 33. Best Practice: ALE Monitoring  332.4.9 Reposting of IDocs in Status  Error  Figure 2­3 Transaction BD87 In the status monitor (BD87), you can choose a particular IDoc to try to reprocess it. If you right­click, you can choose between Process or Restrict and process. If you choose process, you restart the processing of the IDoc(s). If you choose, Restrict and process, you have to make a few more choices, as shown in the figure below. Figure 2­4 BD87 ­ Manual IDoc processing You can further restrict the IDocs you wish to process in this screen. Use the execute button at the top to begin processing. If Bkgd processing is unchecked, you can see the window below. This choice gives you more options to process the IDoc. Process starts the processing of the selected IDoc(s). Delete flag sets the IDoc status to 68, meaning that the IDoc has an error and does not need to be processed again, but can be archived or deleted. IDoc display shows you the payload of the IDoc. ALE/EDI Interface Management.© 2007 SAP AG  33 
  • 34. Best Practice: ALE Monitoring  34Figure 2­5 BD87 ­ Display Status Records If you click IDoc display, you will see the current information on the IDoc. To display the errors in the IDoc, click the Segments with errors button. The next figure shows you a sample error. Figure 2­6 BD87 – Display Status Records Figure 2­7 BD87 – Display Data Records Analyze the error situation. Check if the error can be resolved by changes in the business­related objects so that the IDoc can be reprocessed correctly. If this is not possible, you need to decide what the next steps are: • Either resend corrected data from the sending system and then mark the IDoc for deletion or© 2007 SAP AG  34 
  • 35. Best Practice: ALE Monitoring  35• Manually process the IDoc by entering the corrected IDoc data directly into the appropriate SAP application transaction. Then, mark the IDoc for deletion. Please keep in mind that this is an either or activity, you can’t do both! The appropriate agent also probably needs to decide what steps need to be taken. Figure 2­8 BD87 – Delete Flag By clicking the Delete flag button, you mark the IDoc for archiving or deletion. The status for this is 68. This denotes the fact that the document had an error, was deleted and does not need any further processing. If the IDoc is of type Master data, it is quite easy to resend a new master data IDoc. It is defined in a central system; therefore, we can set the deletion flag and send a new IDoc. However, if the IDoc contains transactional data, it may not be so easy to resend the IDoc. In this case, it is recommended to correct the errors first (that is, customizing error or missing data). After the IDoc is corrected, the IDoc should be reprocessed and should not be deleted. The other option is to modify the IDoc: Figure 2­9 BD87 – Status change after deletion If the IDoc does not contain legally binding data; that is, data that must not be changed according to the local countries law, you have the option to change the data so that it will be processed the next time. You can edit the IDoc content manually by clicking on the ‘notepad’ icon in front of the segment. Then you switch to change mode by clicking Data record ­> Display ­> Change. Once the changes have been made, you can reprocess the IDoc again. To give you a little more understanding on the procedure, we would like to explain a little about what happens in SAP ERP. When you reprocess an IDoc, the following things happen in the system: A copy is created of the org. IDoc. (This is done for documentation purposes). This copy has either status 33 (sender) or 70 (receiver). In addition to this, the copy can not be processed! The original copy gets status 32 (sender) or 69 (receiver). A status record is also created with 32 (sender) or 69 (receiver) and its long text contains the IDoc number of the IDoc copy.© 2007 SAP AG  35 
  • 36. Best Practice: ALE Monitoring  363 Aspect: Backlog Monitoring Backlog monitoring enables you to monitor the number of messages that are processed, or have not been processed in a defined time window. Based on this information, reporting on the interface throughput can be set up. This might serve as an indicator of delays in business critical data flows, as well as an indicator for interacting applications, in case the data volume processed exceeds or falls below defined threshold values. This gives the corresponding organizational units the time necessary to adapt their operations to the upcoming increase or decrease of unfilled work items. Backlog situations for IDocs in non­erroneous statuses can also indicate severe error situations in the ALE processing. 3.1 Manual Backlog Monitoring Monitoring Objects w/o SAP Solution Manager Monitoring  Monitor  Monit  Indicator  Monitoring Activity or  Respon­  Escalation Object  TA/Tool  Freq.  or Error  Error Handling  sibility  Procedure  Procedure tRFC Queue  SM58  As  Slow  Call transaction SM58  Business  Application  required  processing  and specify timeframe.  Process  Management  by Choose execute, look  Operations  Team /  business  at number of entries in  Team / SAP  Business  table. Investigate  Technology  Process  reason for IDoc being  Operations  Champion  stuck in the tRFC  Team  queue.  Specifically look out for  function module  IDOC_INBOUND  ASYNCHRONOUS  which is used to  transfer the IDoc to the  target system. If you  see many entries in the  tRFC queue, which  utilize this function  module, analyze why  tRFC has not been  processed. Status text  “Transaction recorded’  indicates lack of  resources in the target  system  Ensure that  background job  RBDMOIND is  scheduled and running  successfully IDoc display  BD87  As  Slow  In cases were IDocs  Business  Application  required  processing  are configured to be  Process  Management  by sent/posted  Operations  Team /  business  immediately. Call  Team / SAP  Business  transaction  Technology  Process  WE02/WE05. Choose  Operations  Champion various selection  Team  criteria and execute.  Double click on status © 2007 SAP AG  36 
  • 37. Best Practice: ALE Monitoring  37 records of IDoc for  technical information.  On tab “Technical info”  compare timestamps  for various statuses.  See section 3.2.1  below for example.  If processing is found to  be slow, use  techniques detailed in  Section 7 of this  document to investigate  reason for slow  processing. Background  SM37  As  Slow  When IDocs are posted  Business  Application jobs  required  processing  by a background job  Process  Management  by i.e. with the report  Operations  Team /  business  RBDAPP01, you can  Team / SAP  Business  check the processing  Technology  Process  time from the job  Operations  Champion duration using  Team  transaction SM37.  Specify the selection  criteria and execute,  the Job log will show  how many IDocs where  posted. From the  number of posted  IDocs and the job  duration, you can figure  out the throughput. In  case Parallel  processing is in use  SAP Note 547253 must  be implemented. (This  strategy can also work  with outbound jobs  such as RSEOUT00,  RSNAST00 and  RBDMIDOC but  outbound processing is  normally quite fast). If  processing is found to  be slow, use  techniques detailed in  section 7 of this  document to investigate  reason for slow  processing. © 2007 SAP AG  37 
  • 38. Best Practice: ALE Monitoring  383.2 Examples of Backlog Analysis techniques 3.2.1 Single IDoc time stamp analysis In cases were IDocs are configured to be sent/posted immediately. Use transaction WE02/WE05 to select an IDoc and display its status records as below, The status 50 shows that the IDoc has been added to the application and status 53 is when the IDoc has been posted. Subtracting the difference between the timestamps gives the processing duration. If you find that the IDoc processing has taken to long use techniques described in section 7 of this document to analyze reasons it may be of benefit to trace the inbound processing function module i.e. IDOC_INBOUND_ASYNCHRONOUS. Fig 3­1 Single IDoc time stamp analysis© 2007 SAP AG  38 
  • 39. Best Practice: ALE Monitoring  393.3 Automated Backlog Monitoring Depending on your ALE customizing and the IDoc processing, different IDoc statuses can be considered responsible for backlog situations, if their processing doesn’t start in time. The most common statuses therefore, are 03, 30 and 64. A large number of IDocs does not necessarily indicate a backlog situation in the IDoc processing. Therefore, the length of time that the IDoc has been in a certain status needs be considered. With field “Wait time status changes OUT” or field “Wait time status changes IN” you can specify the time which is uncritical for an IDoc to be in a certain status. For details refer to section Specific ALE/EDI Monitoring. If the IDocs are processed by background jobs, their cancellation or long runtimes can be the reason for backlog situations in the IDoc processing. Therefore, background job monitoring can be a better option for monitoring upcoming backlogs. For details on Business Process Monitoring within SAP Solution Manager refer to the setup guides at “ http://service.sap.com/bpm ­> Media Library ­> Technical Information“ or follow those links:  ­  http://service.sap.com/~sapidb/011000358700006137522006E  ­  http://service.sap.com/~sapidb/011000358700006137532006E Automated Monitoring Objects with SAP Solution Manager: Monitoring  Monitor  Monit  Indicator or  Monitoring  Respon­  Escalation Object  TA/Tool  Freq.  Error  Activity or  sibility  Procedure  Error  Handling  Procedure IDocs in  SAP CCMS  Hourly  Number of  Analyze the  Business  Application status “IDoc  / SAP  IDocs in this  reasons in  Process  Management generated”  Solution  status  BD87  Operations  Team / outbound  Manager  Team /  Business (statuses 01,  SAP  Process 25, 32, 42)  Technology  Champion [Refer to  Operations section  Team “Specific ALE/EDI Monitoring”] IDocs in  SAP CCMS  Hourly  Number of  Analyze the  Business  Application status “IDoc  / SAP  IDocs in this  reasons in  Process  Management generated”  Solution  status  BD87  Operations  Team / inbound  Manager  Team /  Business (statuses 50,  SAP  Process 58, 61, 64,  Technology  Champion 66, 69, 70)  Operations [Refer to  Team section “Specific ALE/EDI Monitoring”] IDocs in  SAP CCMS  Hourly  Number of  Analyze the  Business  Application status “Ready  / SAP  IDocs in this  reasons in  Process  Management for dispatch”  Solution  status  BD87  Operations  Team / outbound  Manager  Team /  Business (status 30)  SAP  Process [Refer to  Technology  Championsection  Operations “Specific  Team ALE/EDI Monitoring”] © 2007 SAP AG  39 
  • 40. Best Practice: ALE Monitoring  40Background  SAP  As  Cancellations,  Analyze the  SAP  SAP jobs for IDoc  Solution  needed  Maximum  reason in  Technology  Technology processing  Manager  duration, Start  SM37  Operations  Operations listed above  delay, Out of  Team  Team /  time window,  Application  Job Logs,  Management  Parallel  Team Processing © 2007 SAP AG  40 
  • 41. Best Practice: ALE Monitoring  414 Aspect: Performance Monitoring This section will give you some suggestions on how to monitor your systems’ performance for ALE/EDI. The first step is to understand that we actually need to look at least two systems, depending on the landscape and solution. Optimization steps may need to be done in two systems. The performance of ALE depends on many factors (type of business process, number of messages, activities running on the distributed systems, hardware, and so on). Performance monitoring enables you to monitor for the interface performance and compare it with predefined key performance indicators. Proactively applied performance monitoring notifies you in situations of reduced interface throughput, which, in turn, can avoid backlog situations for performance critical interfaces. Reactive performance monitoring allows for the documentation of the service level delivered. Monitoring Requirements: The first step in measuring Performance is to have a baseline to measure against. There are different ways of using IDocs ­ there is really no simple way to define what is a good performance or bad performance. Therefore, the first step is defining KPIs (Key performance indicators) for the ALE/EDI interfaces. By doing so, you define what minimum performance you require. This depends on a number of factors and is based on your business needs. All parties in the process need to adhere to these KPIs and the actions to be taken if these limits are exceeded. One way to find these KPIs is to use your QA ­system (or the future productive system) and measure it. These numbers might be useful in defining the KPIs. Another method is to analyze your business process. For example, if you need to send 3600 IDocs per hour (each containing the business data for one sales order), so you need to be able to process one IDoc per second. In the following sections we are going to describe some techniques which can be used to measure the performance of the ALE/EDI processing in a SAP R/3 system. There is also a SAP course called “ADM315 Workload Analysis” which covers this and many more performance monitoring topics in greater detail. 4.1 Manual Performance Monitoring Monitoring Objects w/o SAP Solution Manager Monitoring  Monitor  Monit  Indicator  Monitoring  Respon­  Escalation Object  TA/Tool  Freq.  or Error  Activity or  sibility  Procedure  Error Handling  Procedure Performance  ST03N  As  High  SAP  SAP of the ALE  >>  required  processing  Technology  Technology processing –  Workloa  by times  Operations  Operations General  d  business  Call transaction  Team  TeamOverview  Overvie  ST03n ­> switch  w  to Service  Engineer mode  and choose  Workload  Overview. Look  at task type ALE  and RFC for an  overview of  performance of  ALE/EDI to see  where time is  being spent.  See section  4.1.1.1 of this © 2007 SAP AG  41 
  • 42. Best Practice: ALE Monitoring  42 document for  details.  Review section  7 of this  document on  how to further  investigate any  observed  bottlenecks. RFCs/ALE  ST03N  As  High  Analyze the  Business  SAP Function  >> RFC  required  processing  performance of  Process  Technology modules  PROFIL  by times  the various RFC  Operations  Operations  ES  business  function  Team /  Team  modules related  SAP  to IDoc  Technology  processing i.e.  Operations  aRFC_DEST_E  Team  XECUTE,  aRFC_DEST_S  HIP,  aRFC_DEST_C  ONFIRM,  EDI_DATA_INC  OMING,  INBOUND_IDO  C_PROCESS,  IDOC_INBOUN  D_ASYNCHRO  NOUS,  IDOC_START_I  NBOUND. See  Sections 4.1.1.2  and 4.1.1.3  below for  details. RFC,  ST03n  As  High  Business  SAP Function  >>  required  processing  Process  Technology Modules,  Applicat  by times  Operations  Operations Reports/Jobs  ion  business  Analyze the  Team /  Team  Statistic  performance of r  SAP  s  ALE/EDI  Technology  relevant  Operations  transactions/rep  Team  orts to  determine  where time is  being spent.  See section  4.1.1.4 of this  document for  details.  Review section  7 of this  document on  how to further  investigate any  observed  bottlenecks. RFC,  STAD  As  High  Call transaction  Business  SAP© 2007 SAP AG  42 
  • 43. Best Practice: ALE Monitoring  43Function  required  processing  STAD. Choose  Process  Technology Modules,  by times  a time frame for  Operations  Operations Reports/Jobs  business  the analysis and  Team /  Team  the ALE/EDI  SAP  user. On the  Technology  next screen you  Operations  see a list of all  Team  the statistical  records for the  chosen  timeframe.  Select a record  which utilizes  ALE/RFC and is  showing bad  performance.  Double click for  detailed  analysis. RFC,  ST12  As  High  Call transaction  Business  Application Function  required  processing  ST12 and  Process  Management Modules,  by times  specify various  Operations  Team Reports/Jobs  business  selection  Team /  criteria. For  SAP  further  Technology  information on  Operations  how to use  Team  ST12 see  section 7 of this  document. Background  ST03n  As  Slow  Call transaction  Business  Application Jobs  required  processing  ST03N. Switch  Process  Management  by to “Expert  Operations  Team /  business  Mode” and  Team /  Business  choose server  SAP  Process  and from lower  Technology  Champion window choose  Operations  Transaction  Team  Profile ­>  Standard. Sort  by “Task Type”  Background.  Use statistics to  analyze any  performance  bottlenecks for  relevant  background jobs  as listed in  section  IDoc batch job  monitoring.  Further  information is © 2007 SAP AG  43 
  • 44. Best Practice: ALE Monitoring  44 available below  in section 7. Also see section Backlog monitoring. 4.1.1 Overview of Available Tools for ALE/EDI Performance  Analysis 4.1.1.1 ST03N – Workload Overview Once the RFC and ALE/IDOC application statistics have been activated they can be used to analyze ALE/EDI performance. For a general overview of how a specific server is performing choose the relevant server that you want to analyze, time period, and then go to ‘Analysis Views’ >> Workload Overview. Look at task type ALE for an overview of performance. Figur e 4­1 – Wor kload over view with ST03N For a more detailed analysis of ALE/EDI performance use the RFC profiles, select a specific server of interest/or select all servers (Total – as below) and choose a time period i.e. day, week, month.© 2007 SAP AG  44 
  • 45. Best Practice: ALE Monitoring  45 Choose particul profile i Client o Server  Figur e 4­2– RFC pr ofiles – list of called function modules 4.1.1.2 ST03n ­ RFC Client Profile Using the RFC Client profile (choose: Analysis views ­> RFC profiles ­> Choose RFC profile: “RFC Client Profile.”) as illustrated below allows analysis of ALE/EDI communication when this particular server acted as the RFC client. Choosing the tab ‘Function Module’ displays a list of the called RFC function modules for the selected server/servers over the selected time period. As this is the RFC client we should be looking out for long connection times – this can be achieved by sorting by ‘Call Time‘ (average or total, in SAP releases NW2004 and NW2004s these columns is called ‘T Time’ and ‘Ø Time/RFC’) to get those function modules with the longest processing times at the top of the list. Detailed analysis (i.e. RFC trace) should be performed on the function modules where as a rule­of­ thumb the following is true: call time – execution time > 20% (i.e. >20% processing time is spent on establishing a connection). Possible reasons for long connection times include: · Establishment of the connection takes long e.g. RFC server is overloaded or insufficient  number of registrations by the RFC Server programs · Data transfer takes too long e.g. network bandwidth or amount of data to be transferred to  high It is also possible to double click on each function module to access greater detail about the called function module – information available includes local RFC destination, target RFC destination, user who called function module, bytes sent, bytes received see figure below.  Double click  for further   detailsFigur e 4­3 – RFC Client Pr ofile © 2007 SAP AG  45 
  • 46. Best Practice: ALE Monitoring  46Choosing tab ‘Transaction’ allows you to view a list of all RFC spawning transactions. Similar to above double clicking on the transaction provides further information. 4.1.1.3 ST03n ­ RFC Server Profile Using the RFC Server profile (Analysis views ­> RFC profiles ­> Choose RFC profile: “RFC Server Profile.”) as illustrated below allows analysis of ALE/EDI communication when this particular server acted as the RFC server. Choosing the tab ‘Function Module’ displays a list of the called function modules for the selected server/servers over the selected time period. As this is the RFC server you should be looking out for high load function modules i.e. executed frequently and long running function modules. This can be achieved by sorting by ‘Number of calls‘ and ‘Total execution time‘ to get those function modules which impose most load on the RFC server. Sort by ‘Number of RFC Calls‘: · if for example the number of calls for an ALE/EDI function modules within a certain time  frame e.g. 24 hours indicates that it is called every few seconds or with an even higher  frequency it should be analyzed why it is called so often. (Maybe IDoc collection can be  implemented so that function modules are not called so often.). Sort by ‘Total execution time’: · to get those ALE/EDI function modules that cause the highest RFC load on the system –  these should be analyzed in detail using an RFC trace. In the RFC Server Profile it is also possible to double click on each function module to access greater detail about the called function module – information available includes local RFC destination, remote RFC destination, user who called function module, bytes sent, bytes received (see figure below).  Double c for furth detailsFigur e 4­4 –RFC Ser ver  Pr ofile **The Function modules which you should pay particular attention to when analyzing performance of ALE/EDI include: aRFC_DEST_EXECUTE, aRFC_DEST_SHIP, aRFC_DEST_CONFIRM, EDI_DATA_INCOMING, INBOUND_IDOC_PROCESS, IDOC_INBOUND_ASYNCHRONOUS, IDOC_START_INBOUND © 2007 SAP AG  46 
  • 47. Best Practice: ALE Monitoring  474.1.1.4 ST03n – ALE/IDOC Application Statistics To see the ALE/IDOC application statistics, you need to go to the appropriate application server. When you choose the sever another window will appear in the lower right hand side and then you choose the application statistics. Then you see following figure Figure 4­5 ST03n displaying Application statistics Upon double clicking a row further details can be displayed including user who executed the report/transaction see figure below: Fig 4­6 ST03n displaying Application statistics (additional details) With the information above you can detect if there are performance problems database, ABAP. If you can find a high database time then you proceed with a SQL trace ST05 and a high CPU time proceed with the ABAP runtime analysis SE30 see section 7 of this document regarding using SE30 and ST05 .© 2007 SAP AG  47 
  • 48. Best Practice: ALE Monitoring  484.1.2 Activation of Performance Monitoring With Transaction  ST03N ST03n can be used to investigate ALE/EDI performance issues within the SAP system but you have to do some configuration to enable this. The following two sections describe how to enable the monitoring and how to use the tool to monitor ALE/EDI. In the workload monitor ST03N, you can analyze the workload caused by Function Modules relating to ALE/EDI by displaying the RFC profiles, you can answer the following questions: · Which transaction, which function module, and which user caused what workload through  RFC calls as an RFC client or an RFC server? · What workload do the transactions, function modules, or users cause in which local or remote  RFC destinations? For transaction steps with RFC, the kernel writes subrecords with additional information about the processing time, the destination, and the function module used. The parameter stat/rfcrec (default: stat/rfcrec = 5) specifies the maximum number of subrecords of each type (RFC client, RFC server, RFC client destination, and RFC server destination) that the kernel writes. If more RFCs are performed during a transaction step, only the five calls with the longest execution time are therefore logged, which is sufficient for performance analyses. The restriction to a maximum of five records represents a compromise between the required accuracy on one side and the workload created by the performance collector on the other side. A larger value for stat/rfcrec can lead to performance problems in the collector. The RFC client and RFC server records contain data such as execution time and called function for individual RFCs. The RFC destination records contain the total of all RFC calls per destination and therefore no additional information about the called function modules. In addition to RFC profiles it is also possible to activate ALE/IDOC application statistics. The application statistics allow you to analyze resource consumption in detail from an application viewpoint. Using special calls within the ABAP coding, the system collects statistics for individual parts of an application. While the workload statistics always analyze a complete dialog step, you can use the application statistics to analyze the resources used by an individual function within a dialog step (such as price determination). 4.1.2.1 Activating the Statistical Collectors – RFC It is possible that no RFC­statistics are stored, as it is possible to turn them off in the system. The steps to reactivate the monitoring are different for 4.x, NW2004, NW2004s versions of SAP. Here we will describe the different methods of activation. For each system version you need to enter transaction ST03N >> Expert Mode.  a)  For SAP 4.x:  In ST03N, you need to go into the collector branch ­> workload collector ­> Collector and reorg.© 2007 SAP AG  48 
  • 49. Best Practice: ALE Monitoring  49Figur e 4­7 – activation of RFC Statistics with ST03N Push button: Modify parameters. Figur e 4­8 – activation of RFC Statistics with ST03N In this screen SAP suggests that you activate all the check boxes and options. At least the "Cumulate RFC profiles"­entry under "Statistical data to be cumulate & Controls for the collector" has to active. Then save the choices. In addition it is highlighted above how you can modify the residence times for statistical data.© 2007 SAP AG  49 
  • 50. Best Practice: ALE Monitoring  50 b)  For SAP NW2004:  Call transaction ST03N >> then Collector and Performance DB Figur e 4­9 – Activation of RFC Statistics with ST03N In all the mentioned sub screens you have the choice to use the SAP Defaults button. This option will set the parameters to values which are suggested by SAP. Make sure to note which parameters you modified in the system. As everything you have set manually will be erased by the defaults. Choose Performance Database ­> Reorganization here you can modify all the settings relating to the retention times of performance data. Figur e 4­10 – ST03n Retention time for per for mance data Next choose Workload Collector >> Control Data. In this screen you can choose how much data is stored on the local file system. Be aware that there is no exact information on how large the files can get, so please make sure that you have enough disk space available for these logs.© 2007 SAP AG  50 
  • 51. Best Practice: ALE Monitoring  51Figur e 4­11 – ST03n Retention of statistic files Next choose Workload Collector Database>> Statistics to Be Created, here you can choose what data is stored in the system. SAP suggests activating all the checks, but the RFC statistics is the minimum which should be activated. Figur e 4­12  ST03N – Selection of data to cumulate© 2007 SAP AG  51 
  • 52. Best Practice: ALE Monitoring  52 c)  For SAP NW2004s:  Call transaction ST03N >> then Collector and Performance DB Figur e 4­13 – Activation of RFC Statistics with ST03N In all the mentioned sub screens you have the choice to use the SAP Defaults button. This option will set the parameters to values which are suggested by SAP. Make sure to note which parameters you modified in the system. As everything you have set manually will be erased by the defaults. Choose Performance Database ­> Reorganization here you can modify all the settings relating to the retention times of performance data. Figur e 4­14 – ST03n Retention time for per for mance data Choose Workload Collector Database >> Reorganization ­> Control here you can modify all the settings relating to the retention times of aggregated performance data.© 2007 SAP AG  52 
  • 53. Best Practice: ALE Monitoring  53Figur e 4­15 – ST03n maintenance of collector  parameter s (retention periods aggregated data) Choose Workload Collector >> Instance Collector ­> Control here you activate collection of aggregated performance data at instance level. Figur e 4­16 – ST03n maintenance of collector  parameter s (Instance statistics aggr egation) Choose Workload Collector >> Total Collector ­> Control here you activate collection of aggregated performance data at overall system level. Figur e 4­17 – ST03N maintenance of collector  par ameters (Total statistics aggregation) The parameter stat/rfcrec which controls the number of RFC subrecords to be generated is configured using ST03n (Expert mode) >> Collector and Performance DB >> Statistics Records and File >> Online Parameters >> Dialog Step Statistics. (This is the same procedure for all versions of SAP).© 2007 SAP AG  53 
  • 54. Best Practice: ALE Monitoring  54Figur e 4­18 – Configur ing the number  of RFC subr ecor ds 4.1.2.2 Activating the Statistical Collectors – ALE/IDOC Application  Statistics The steps to activate collection of the Application Statistics are described in this section. The first step is to “set” the ST03N to expert mode then navigate as illustrated below to Collector and performance DB >> Statistics records and file >> Online parameters >> Application statistics. Figure 4­19 Then the window below is opened where you can select ALE/IDoc statistics and save the setting. This activates the monitoring for the ALE/EDI RFC functions: IDOC_INBOUND*, INBOUND_IDOC* and EDI_DATA_INCOMING. When these particular calls are made their statistics are summed up and recorded in ST03n.© 2007 SAP AG  54 
  • 55. Best Practice: ALE Monitoring  55Figure 4­20 – Activation of application statistics In addition to the above you need to make sure that in the corresponding instance profile the profile parameter stat/as_level is set to 1(meaning the application tracing is active, 0=not active). If there is ALE activity you can see if application statistics are being measured by checking the file called astat. Goto AL11 , choose the directory data as illustrated below. Figure 4­21 – Transaction AL11 (Checking if application statistics are generated) If the application statistics collection works properly, you will notice that the file called astat will grow. It will grow according to how much data is processed. If there is no traffic then the file remains small.What happens, is that the Kernel writes the statistics into a file called STAT. The application statistics are written into the file called astat. In addition the Job RSSTAT87 is activated, and it writes the application statistics in the table MONI. From which the ST03N can display the data.© 2007 SAP AG  55 
  • 56. Best Practice: ALE Monitoring  564.2 Automated Performance Monitoring Using the SAP Solution Manager and its Business Process Monitoring functionality, you can monitor background jobs for their runtime, start delay, end delay, out of time window etc. If you need to monitor the total response time of a specific function, module or program involved in the IDoc processing, use the “Dialog Performance Monitor” in the SAP Business Process Monitoring functionality, where you can monitor for the average response times for specified function modules and/or programs. For details on Business Process Monitoring within SAP Solution Manager, refer to the setup guides at “http://service.sap.com/bpm ­> Media Library ­> Technical Information“ or follow those links:  ­  http://service.sap.com/~sapidb/011000358700006137522006E  ­  http://service.sap.com/~sapidb/011000358700006137532006E Automated Monitoring Objects with SAP Solution Manager Monitoring  Monitor  Monit  Indicator or  Monitoring  Respon­  Escalation Object  TA/Tool  Freq.  Error  Activity or  sibility  Procedure  Error  Handling  Procedure Background jobs  SAP  As  Maximum  Analyze the  SAP  SAP for IDoc  Solution  needed  duration,  reason in  Technology  Technology processing  Manager  Start Delay  SM37  Operations  Operations  Team  Team /  Application  Management  Team Total Response  SAP  15 High total  Analyze the  SAP  SAP time of specific  Solution  minutes  response  reason in  Technology  Technology function  Manager  time  ST03N,  Operations  Operations modules and/or  STAD,  Team  Team / programs  ST12  Application  Management  Team© 2007 SAP AG  56 
  • 57. Best Practice: ALE Monitoring  575 Aspect: Resource Monitoring Resource monitoring includes the monitoring of the availability of involved components, as well as their resource consumption. This chapter will show you how a resource monitoring for interface monitoring with ALE/IDoc scenarios could be done. In the first subsection you find possibilities on how to do a manual monitoring and error handling. The second subsection outlines possibilities for an automated monitoring. Monitoring Requirements: To enable the successful execution of interfaces, it is important that sufficient resources are available. It is important that the following resources are monitored for availability to ensure optimal interface performance Monitoring Objects: · Work processes · Queues · CPU · Memory · Buffers · Database Figure 5­1 Resource overview in ALE processing© 2007 SAP AG  57 
  • 58. Best Practice: ALE Monitoring  585.1 Manual Resource Monitoring Monitoring Objects w/o SAP Solution Manager Monitoring  Monitor  Monitor  Indicator or  Monitoring Activity or  Responsibility  Escalation Object  TA/Tool  Freq.  Error  Error Handling  Procedure  Procedure aRFC  SARFC  Hourly  Number of  Monitor current state of  SAP  SAP resource  during  aRFC resources  individual work  Technology  Technology monitoring  peak  currently  processes.  Operations  Operations  hours and  available for  Ensure that enough  Team  Team  in case of  asynchronous  work process capacity is  performan  RFC calls  available at peak times.  ce problems  or error  If an application uses a  messages  lot of transactional or  asynchronous RFC, this  can overload the  participating application  servers. It is important  that enough work  processes are available  for both Dialog users  and for RFC  communication.  Resource usage by RFC  can be controlled using  various profile  parameters. See SAP  Note 74141 for tuning  hints regarding resource  configuration for RFC Local work  SM50  Hourly  WP status, WP  Monitor current state of  SAP  SAP process  during  utilization  individual work  Technology  Technology overview  peak  processes.  Operations  Operations  hours and  Ensure that enough  Team  Team  in case of  work process capacity is  performan  available at peak times.  ce problems  or error  messages System­  SM66  Hourly  WP status, long  Similar to SM50 but for  SAP  SAP wide work  during  running jobs  system­wide statistics.  Technology  Technology process  peak  Operations  Operations  hours and  Team  Team  in case of  performan  ce problems Work  SM58  Hourly in  Status Text  Check the target system  SAP  SAP processes  case of  shows  with SM66  Technology  Technology in target  performan  ‘Transaction  Operations  Operations system  ce recorded’  Team  Team problems  indicates lack of  or error  resources in the © 2007 SAP AG  58 
  • 59. Best Practice: ALE Monitoring  59Monitoring  Monitor  Monitor  Indicator or  Monitoring Activity or  Responsibility  Escalation Object  TA/Tool  Freq.  Error  Error Handling  Procedure  Procedure  messages  target system Work  SMQS  Hourly In  Status of the  Check the number of  SAP  SAP processes  case of  destination  work processes  Technology  Technology in sender  performan  ‘WAITCONN’  configured for this  Operations  Operations system  ce indicates lack of  particular destination  Team  Team  problems  rfc resources in  using transaction SMQS  or error  sending system  ­> check the value  messages  assigned to this  specified in column  rfc destination  “Max. Conn” for the  destination.  Check the configured  number of resources  dedicated to RFC  against the number of  available work  processes on sender  system by using  transactions SARFC  and SM50.  Decide if enough work  processes are  configured for  destination Outbound/i  SMQ1/  Hourly In  Status of  Refer to SAP Note  SAP  SAP nbound  SMQ2  case of  queues, if  378903  Technology  Technology Queues  performan  entries in a  Operations  Operations  ce queue are not  Team  Team  problems  processed and  or error  queue remains  messages  in a certain  status for more  than 30mins System  SMGW  During  Error messages  Review  SAP  SAP parameter  & ST11  periods of  in the gateway  recommendations as  Technology  Technology s for a high  very high  trace or other  per SAP Note 384971  Operations  Operations interface  ALE/RFC  developer traces  Team  Teamload  load and  regarding  or  terminations i.e.  performan  SAP­RC=672,  ce R3_LOGIN_FAI  problems  LED, No wp_ca  block received,  No free block  found in the WP  Communication  Area,  MAX_CPIC_CLI  ENTS,  CONN_EXCEE  DED, © 2007 SAP AG  59 
  • 60. Best Practice: ALE Monitoring  60Monitoring  Monitor  Monitor  Indicator or  Monitoring Activity or  Responsibility  Escalation Object  TA/Tool  Freq.  Error  Error Handling  Procedure  Procedure Operating  ST06  Hourly  High paging rate  Monitor the CPU and  SAP  SAP system  (dependin  and CPU  memory consumption.  Technology  Technology monitor  g on the  utilization  A hardware bottleneck  Operations  Operations  business  can have a negative  Team  Team  process)  impact on the overall  and in  response time, as well  case of  as the response time of  performan  an individual business  ce transaction.  problems  Monitor hardware load  during high RFC  transmission times  especially. R/3  ST02  Hourly In  Swaps  Monitor memory  SAP  SAP System  case of  resource usage for  Technology  Technology buffer  performan  specific R/3 application  Operations  Operations monitor  ce servers.  Team  Team  problems  To ensure optimal  or error  performance, check that  messages  the R/3 parameters are  set correctly with  transaction ST02.  Incorrectly sized R/3  buffers or memory  allocation can result in  poor performance. One  such example would be  when a work process  enter PRIV mode. Database  DB02  Weekly  Table sizes,  Ensure that the data  SAP  SAP perform­  and in  table indexes for  quality is sufficient, that  Technology  Technology ance  case of  tRFC and aRFC  there are no missing  Operations  Operations monitor  performan  i.e.  indexes, and that there  Team  Team ce is sufficient space  problems  available.  In general, if table sizes  are larger than 500MB,  reorganize the table and  decrease its size.  See SAP Note 375566.  Monitor the growth of  tables and indexes,  especially on tRFC­ and  qRFC­tables  (ARFCSSTATE  ARFCSDATA  ARFCRSTATE) Since  the tRFC and qRFC  tables shrink and  expand constantly, the  storage quality of the  indexes for these tables  might be inadequate.  This has a negative © 2007 SAP AG  60 
  • 61. Best Practice: ALE Monitoring  61Monitoring  Monitor  Monitor  Indicator or  Monitoring Activity or  Responsibility  Escalation Object  TA/Tool  Freq.  Error  Error Handling  Procedure  Procedure  impact on the  performance 5.2 Automated Resource Monitoring Many of the manual monitoring objects for the general system availability, performance and stability are available within SAP CCMS and SAP Solution Manager. Completely automated technical resource monitoring can be performed individually, per system and instance, within the System Monitoring part of SAP Solution Manager. The setup of System Monitoring within SAP Solution Manager is done in transaction DSWP ­> ‘Operations Setup’ ­> ‘Solution Monitoring’ ­> ‘System Monitoring’ ­> ‘Setup System Monitoring’. For further information consult the following guide: http://service.sap.com/~sapidb/011000358700001872602002E Automated Monitoring Objects with SAP Solution Manager Monitoring  Monitor  Monit  Indicator or  Monitoring  Respon­  Escalation Object  TA/Tool  Freq.  Error  Activity or  sibility  Procedure  Error  Handling  Procedure SAP System  SAP  15 Resource  Analyze the  SAP  SAP resources:  CCMS /  minutes  shortage  system  technology  Technology ­ number of free  SAP  stability and  operations  Operations work processes,  Solution  performance  team  Team­ dialog steps  Manager’s per minute  System ­ CPU utilization  Monitoring ­ Memory usage  part ­ DB key figures etc.) © 2007 SAP AG  61 
  • 62. Best Practice: ALE Monitoring  626 Aspect: Data Management Monitoring Requirements: The Interface relevant tables listed below have a direct impact on performance. These tables grow very quickly, and if they are not managed correctly, they can cause interface(s) to execute slowly. Monitoring Objects: A data management strategy should be set up for the following interface­relevant tables. DB Table Name  Table Description EDIDOC  EDI intermediate document cluster EDIDC  Control records (IDoc) EDID4  IDoc Data Records EDIDS  IDoc Status Records EDI30C  Intermediate document cluster (data records) from 3.0C EDI40  IDoc data records for 4.0 BDCP  IDoc Change pointer BDCPS  IDoc Change pointer status ARFCSSTATE  ARFC Call Status (Sender) ARFCSDATA  ARFC Call Data (Sender) TRFCQOUT  tRFC Queue (outbound) ARFCRSTATE  Status of ARFC Calls on Receiver Side TRFCQDATA  qRFC (inbound queue) TRFCQSTATE  qRFC Call Conditions (Inbound Queue) TRFCQIN  tRFC Queue (Inbound Queue) SWWWIHEAD  Workflow Runtime: Header Table for All Work Item Types SWWLOGHIST  Workflow Runtime: History of a Work Item SWP_HEADER  Workflow Instances: Header Data of a Workflow Execution SWP_NODEWI  WF: Work items for nodes in a workflow definition SWPNODELOG  Workflow: Instance Data of Nodes of a Workflow Execution SWPSTEPLOG  Workflow: Instance Data of Steps of a Workflow Execution SWW_CONT  Workflow Runtime: Work Item Data Container SWW_CONTOB  Workflow Runtime: Work Item Data Container (Only Objects) SWW_WI2OBJ  Workflow Runtime: Relation of Work Item to Object SWWEI  Workflow Runtime: Work Items of Type E (Event Items) SWWWIDEADL  Workflow Runtime: Deadline Data for Work Items SWWUSERWI  Current Work Items Assigned to a User  a)  IDoc related tables  IDocs, like most other SAP objects, need to be archived regularly. Otherwise, they will use up  disk space unnecessarily. Setting up an archiving plan early in the implantation phase,© 2007 SAP AG  62 
  • 63. Best Practice: ALE Monitoring  63 assures you of a well running system. This will reduce the size of the database considerably  once the archived objects are removed.  Recommendation:  Define an archiving strategy for your IDoc tables and implement using transaction SARA.  Further information available at:  http://help.sap.com/saphelp_erp2005vp/helpdata/en/dc/6b81ed43d711d1893e  0000e8323c4f/content.htm  Regarding reorganizing IDoc Change pointer tables run the report RBDCPCLR periodically –  review the below URL for further information:  http://help.sap.com/saphelp_erp2005vp/helpdata/en/12/83e03c19758e71e100  00000a114084/content.htm  The tables IDOCREL and SRRELROLES, which contain links to application documents, for  example, can grow quite large and a data management strategy should also monitor and  manage these tables. Report RSRLDREL can be used to remove obsolete entries from these  two tables. Unlike the IDocs tables, link tables are not required to be archived before they are  deleted. See SAP Note 505608 for further information.  Time stamps for Serialization at IDoc level are stored in table BDSER. This table can grow  quite large.  Report RBDSRCLR should be scheduled to keep this table at a manageable size.  See SAP Note 752194 for further information.  b)  RFC related tables  For RFC tables, such as ARFCSSTATE, ARFCRSTATE, ARFCSDATA, ARFCRDATA,  TRFCQOUT, TRFCQDATA, TRFCQSTATE and TRFCQIN, performance problems often  occur as a result of a large number of blocks allocated for these tables, outdated statistics and  poor storage quality.  Recommendation:  If you find that the tables are large or have poor storage quality, you can improve performance  by reorganizing these tables.  Once that is complete, follow the regular maintenance steps  below:  The following reports are used to delete entries from the RFC tables:  RSARFCDL:   Deletes tRFC Entries from Log File.  This report deletes the error log of the  ARFC in the background.  RSARFC01:  tRFC Reorganization.  RSTRFCES:  Deletes ARFCSSTATE, ARFCSDATA, TRFCQOUT entried.  RSARFCER:  Deletes tRFC in reference to the status  Refer to SAP Note 324545 and 375566 for additional details.  These tables are considered volatile, and statistics should not be collected.  Also, due to the  high volume of data, and frequent changes, the indexes for these tables should be  reorganized on a regular basis.© 2007 SAP AG  63 
  • 64. Best Practice: ALE Monitoring  64 c)  Workflow related tables  The work item tables can grow quickly (tables included are SWWWIHEAD, SWW*). Even if  you are not explicitly using workflow for the IDocs, ALE/EDI can create work items.  Recommendation:  Reorganize the work items. The archiving object is WORKITEM. See SAPHELP for further  information on archiving work items:  http://help.sap.com/saphelp_nw04s/helpdata/en/8d/3e704c462a11d18900000  0e8323d3a/frameset.htm  For workflow tables i.e. SWWW* schedule relevant house keeping jobs or set up archiving  using transaction SARA (SAP Note 49545 explains how to delete unnecessary work items). In the following best­practice document, you will find standard recommendations on the topic data management and specific recommendations for different DB tables including interface­related DB tables: http://service.sap.com/~sapidb/011000358700005044382000E or visit quicklink http://service.sap.com/ilm. 6.1 Manual Data Volume Monitoring Monitoring Objects without SAP Solution Manager Monitoring  Monitor  Monit  Indicator  Monitoring  Respon­  Escalation Object  TA/Tool  Freq.  or Error  Activity or  sibility  Procedure  Error Handling  Procedure Table Growth  DB02,  Daily  Table sizes  Analyze the  SAP  SAP  DB15  and free DB  reasons for the  Technology  Technology  space  DB growth in  Operations  Operations  transactions  Team  Team  DB02 and  DB15.  Specifically look  out for interface  tables listed  above. 6.2 Automated Data Volume Monitoring Automated Monitoring Objects with SAP Solution Manager Monitoring  Monitor  Monit  Indicator  Monitoring  Respon­  Escalation Object  TA/Tool  Freq.  or Error  Activity or  sibility  Procedure  Error  Handling  Procedure DB growth  SAP CCMS /  Daily  Free DB  Analyze the  SAP  SAP (CCMS[transaction  SAP Solution  space  reasons for  Technology  Technology RZ20] ­> DB  Manager’s  the DB  Operations  Operations© 2007 SAP AG  64 
  • 65. Best Practice: ALE Monitoring  65administration ­>  System  growth in  Team  Team / Data archiving)  Monitoring  transaction  Application  DB15,  Management  DB01  Team 7 Generic Part on System Monitoring In this part of the ALE Monitoring Best Practice, you will find information about common monitoring activities that are not specific to special business process steps. The following topics are covered: · Performance Monitoring · General Monitoring Guidelines for a SAP System These sections are referenced in the corresponding business process steps of the scenario specific parts above. 7.1 Performance Monitoring In this section, you will find the description of a general procedure for monitoring the performance of your SAP system. The different transactions that are mentioned in the procedure are described in detail below. Please keep in mind that this is general information. Please also consider the training BC315 Workload Analysis. This course covers topics like workload monitor, statistical records, expensive SQL statements, memory management, database monitor and buffer analysis among others. 7.1.1 General information As part of the daily monitoring activities of your SAP system, you should not only watch system availability, system resource consumption and middleware queues (among others), but also the performance of your SAP system. There are several transactions available with which you can monitor the average performance of the system and analyze the causes of poor performance. Poor performance of a system is generally equal to extremely high response times. This may be related to long lasting transactions steps (dialog steps), background jobs running too long, etc. The response time of a transaction step is the difference in time between the point when the request arrives in the SAP System and the point when the SAP System completes the processing. In addition to this measurement of time, other times, such as waiting times or database times, are still measured in SAP. If you subtract these components from the response time, this leaves the processing time which cannot be measured directly. ABAP programming code is processed during the processing time. Definitions of the most important components of the Response time: Time in work process  Time actually spent in the work process (after the dispatcher has found a free  work process) Wait time  The dispatcher is waiting for a free work process (= dispatcher queue). CPU time  It is only given as a sum per transaction step in the workload statistics DB time  Time for accessing and waiting for the database interface, and therefore for  the underlying database Load/Generating time  Time for loading/generating screens, ABAP programs, and CUA elements (not  for presentation). Roll­in time  Time for rolling in the roll area context of a dialog step Enqueue time  Time for setting a logical SAP enqueue Processing time  This time is calculated as follows:  Processing time = Response time ­ Wait time ­ Load/Generating time ­ DB  time ­ Roll­in time ­ Enqueue time Important: the CPU time should not be added to the above times as it is a total, consisting of parts of the times listed above that cannot be calculated. CPU time is returned by the operating system. The accuracy of the reported value depends on the timer of the operating system (under UNIX, for example, the timer works with 100 Hz so that the CPU time is reported as a multiple of 10 ms). Due to© 2007 SAP AG  65 
  • 66. Best Practice: ALE Monitoring  66this rough resolution of the CPU time, it is possible that a slightly longer CPU time is displayed for a dialog step than for the response time. The Roll­Out time is not part of the response time, as it only occurs after the data is transferred to the presentation server. The Roll wait time is the time a work process is waiting for the response of a RFC. The Roll wait time is processed on a client, whereas the user context is in the roll area. Therefore, neither resource is used up nor does a bottleneck occur here for high Roll wait time. High Roll wait times occur frequently. This may be caused by calls of Windows or other external applications from within the R/3 System. The application of the RFC is started here. The user context enters the roll areas and roll wait time is processed until the application is exited, that is, the RFC connection is cancelled. The transaction step is only exited at this point. They also occur when the R/3 System communicates with the front­end controls. While the data on the front­end is being processed, the R/3 context is rolled out, thus releasing the work process. This can occur several times during a transaction step. If front­end Office applications such as Microsoft Word are started and closed, only after a long time (several minutes), a very long Roll wait time occurs here also. Roll wait is not part of the response time for transaction steps of task type RFC. This is because no resource use occurs for the application server. 7.1.2 Procedure The following table gives you an overview of which transaction you use for which purpose during performance monitoring and a first analysis of performance problems. Transaction  Trans. Code  Use for …  Use when?  General performance overview for  Daily (e.g. 3 times) and upon Workload  ST03N  the different task types and  performance problems monitor  analysis of system workload Workload /  Detailed performance monitoring of  When performance problems statistical  STAD  a short time frame, a single user or  occur records  a specific transaction or program  SQL trace of a specific step, short  When performance problems Performance  ST05  sequence of steps or part of a long  occur with high DB times trace  running job  Getting an overview of the duration  When performance problems ABAP  and performance of the source  occur with high CPU times runtime  SE30  code, from individual statements analysis  up to complete transactions  Get an overview on the time  When performance problems Single  distribution (DB, CPU, which  occur with high DB or CPU Transaction  ST12  Function Module or SQL statement  times Analysis  etc.) Key performance indicators Performance monitoring is most useful if you have previously defined key performance indicators. Generally speaking, Key Performance Indicators are quantifiable measurements, agreed beforehand, that reflect the critical success factors of an organization. In this case, we refer to the system response time for single dialog steps of your core business process(es), for transactions or background jobs. The key performance indicators should be agreed on by the business departments and the systems administrators (happy medium between what is needed for business reasons and what is achievable from the system side).  It is also important to use the right granularity for KPIs. There is no need to define a KPI for the response time of each and every step in the process, but it important that they are not defined in a too general way (e.g. less than 2 sec for each dialog step) as this might be too tight or too  wide for specific needs. Furthermore, performance monitoring should not only refer generally to a task type, but should rather go one or to steps further into single transactions or even steps. For example: Company ABC is using the call center scenario for inbound calling and also using the marketing scenario to create target groups via infoset or BW queries. As the call center agents need very good response times for business partner searches in order to answer a call, and the queries for large target groups may take several seconds, it is not recommended that company ABC just monitors the average response time for dialog transactions.  They should, instead, monitor on transaction or even on dialog step level. Daily monitoring of system performance and the compliance of the response times to the established KPIs should be done using the workload monitor (transaction ST03N). This monitor provides an© 2007 SAP AG  66 
  • 67. Best Practice: ALE Monitoring  67overview of the response times and the components (CPU time, DB time, Wait time, etc). In case of performance problems, you should use this and other transactions for a deeper analysis: · If a single user reports problems, use transaction STAD to find what part of the response time  is particularly high in his case. Compare it with other users to see if it is an isolated problem.  Continue the analysis depending on the result. · If a single dialog step (one step within a transaction) has a bad performance, use transaction  STAD to find what part of the response time is particularly high in this case. Continue the  analysis depending on the result. · If you have a general performance problem, use the system monitors to check resource  consumptions. Use the time profile of transaction ST03N to check if performance has been  decreasing over time or if there are peaks. Use the user profile for a comparison among  different users and user groups, if you follow a useful naming convention. · Get a performance trace (transaction ST05) if you find that the performance problems are  related to high DB times. Get an ABAP runtime analysis (transaction SE30) if you find that the  performance is related to high CPU or high processing times. · In case you can not find the cause of the performance problem or need further assistance for  the analysis contact the next support level or open an OSS message on component XX­SER­  TCC. 7.1.3 Transaction ST03N Transaction ST03N is a very powerful transaction with lots of functions. Therefore, we can only mention a few here, based on what is important for performance monitoring. The workload monitor is used to analyze statistical data from the SAP kernel. When analyzing the performance of a system, you should normally start by analyzing the workload overview. For example, you can display the totals for all instances and then compare the performances of individual instances over specific periods of time. You can quickly determine the source of possible performance problems using the large number of analysis views and the determined data. You can use the workload monitor to display the: · Number of configured instances for each SAP R/3 System · Number of users working on the different instances · Distribution of response times · Distribution of workload by transaction steps, transactions, packages, sub­applications, and  applications · Transactions with the highest response time and database time · Memory usage for each transaction or each user per dialog step · Workload through RFC, listed by transactions, function modules and destinations · Number and volume of spool requests · Statistics about response time distribution, with or without the GUI time · Workload and transactions used listed by users, payroll number, and client · Workload generated by requests from external systems For all of this data, you can display it for a particular instance (not only the one to which you are logged on) or optionally totaled for all instances. Depending on your user mode, you can choose the time period for which you want to display the data; day, week and month (or determine the length of time yourself using the Last Minutes’ Load function). For most analysis views, you can display all task types or only certain ones. The workload monitor has an interface that is divided into two parts. Use the tree structures on the left of the screen for the following settings: · Select the user mode · Select the time period for which you want to display the workload · Select various functions and analysis views (which data you want to display). The system then displays the result on the right of the screen in a standardized ALV Grid Control. For general performance monitoring you can use the following options: · User mode à choose expert mode · Workload à choose the instance and time frame you are interested in. Selection between the  last days, the last weeks and the last months is possible. If you are interested in a particular© 2007 SAP AG  67 
  • 68. Best Practice: ALE Monitoring  68 time within the last 24 hours, choose Detailed Analysis, than Last Minute’s Load and than the  required time frame on the appropriate instance. · In the first workload overview, you find the response times and its components for the different  task types (Background, Dialog, HTTP, RFC, Update, etc). You can now go to Analysis Views  à Transaction Profiles à Standard. Here, you can get a more detailed view, selecting for  instance the task type dialog and the aggregation per transaction. The following screen shot shows transaction ST03N using the options: Expert mode, workload for server us0306_Q4C_02, time frame from 03.01.2005 – 09.01.2005, standard transaction profile, showing dialog transactions sorted by average response time. Figure 7­1 Transaction ST03N 7.1.4 Transaction STAD In the transaction STAD, every step on SAP Application Server is recorded. The records for all instances of a SAP system are displayed. The Business Transactions Analysis (transaction STAD) calculates the system resource usage of individual transactions for SAP R/3 Systems and provides a detailed analysis of a transaction and the dialog steps. The selection criteria include user, transaction, program, task type, start date, and start time. The analyzed time period can be larger than the interval defined by Read Time, as the system analyzes complete transactions as far as possible. However, it is not always possible to perform a complete analysis for long­running transactions. As the business transaction analysis is time­ consuming, you should use as short an interval as possible (around 10 minutes). The aim of this monitor is to analyze in detail how long the response times for particular  steps in a process (or transaction) and are these response times distributed among their components (DB time, CPU time, Wait time, GUI time, etc) have been. If you want to use this transaction to analyze the performance of the steps done by a particular user, proceed as follows: · Tell the user to execute the steps once, slowly one after the other and write down the exact  time at which he executed them.© 2007 SAP AG  68 
  • 69. Best Practice: ALE Monitoring  69 · Go to STAD and display the statistical records relating to this single execution (use the user  name and the appropriate time frame to display the correct records). · Format the output list (button “Sel. Fields”), including the fields ‘GUI time’, ‘CUA reference  program’ and ‘CUA internal command’. The last two fields can help you to identify the single  steps executed. · Use the time stamps of the statistical records and the execution times you wrote down to  assign STAD records to the dialog steps that were performed. · Check which steps are actually having a bad response time and what part is contributing most  to it (DB, CPU, GUI, …). · Depending on the result, proceed with a deeper analysis of the worst steps using, for  example, transaction ST05 (for long DB times), transaction SE30 (for long CPU times) or a  network analysis (not described in this document) in case of high GUI times. · Depending on what you are analyzing, it might be wise to let the user execute all steps twice  and use the second execution for the analysis. This way, you ensure that all buffers (for  example, program buffers) are filled. You can also use this transaction to see what was going on in the system during specific periods of poor performance in detail. With this analysis, you can see if there was a few users having particularly high response times or if there was a general performance problem. Procedure: Go to transaction ST03N and search for the hour with the worst performance or the highest workload using the time profile. Call transaction STAD with the following selection criteria: · Show all statistic records, sorted by start time à Checked · Start date à Today’s date · Read time à 1 hour · Start time à start time of high workload (from ST03N) · User à * · Resp. time à >= 5000 ms · Task type à D (dialog) or B (batch) or R (RFC) or * (all) Please be aware that this query may take several minutes. The following screen shots show the initial screen of STAD with the options: Show all statistic records, sorted by start time, reading of the records for 10 minutes starting from 16:50 hours, for all users (*) that executed dialog transactions lasting longer than 1000 ms.© 2007 SAP AG  69
  • 70. Best Practice: ALE Monitoring  70Figure 7­2 Transaction STAD Below, there are two screen shots showing the result of this query. For each time stamp, you see which program was executed, within which transaction, on which server. For each, the user, response time, time in work process, CPU time, DB time, GUI time, CUA ref. Program and CUA internal command are displayed. These columns are not all part of the first standard output. They where adjusted using the “Select output fields” button (F9).© 2007 SAP AG  70 
  • 71. Best Practice: ALE Monitoring  71To make the following steps easier, you may want to download the list with spreadsheet format. Make sure you have displayed all the columns you need before downloading. Be aware, also, that the STAD records are only kept in the system for a limited period (normally 24 or 48 hours). Go through the list of long lasting dialog steps and search for those dialog steps that are long lasting on average (those appearing several times). You may identify which steps belong together by comparing the transaction, the program, the CUA reference program and the CUA internal command. If you can’t find a CUA ref program or a CUA internal command in this list, or if you are not sure on the assignment, please proceed as described below. Please beware that the table beneath only shows typical CUA internal commands for some common steps. However, these commands can be different in your system depending on customizing settings, user exits, particular system usage, and so on. · Execute the typical steps of your core business processes once. Execute the steps slowly one  after the other and write down the exact time at which you executed them. The steps should  be performed by a key user. · Go to STAD and display the statistical records related to this single execution (use the user  name and the appropriate time frame to display the correct records). · Format the output list (button “Sel. Fields”), including the fields ‘GUI time’, ‘CUA reference  program’ and ‘CUA internal command’. · Use the time stamps of the statistical records and the execution times you wrote down to  assign the “CUA internal commands” or the “CUA reference program” to the dialog steps that  were performed. · Use this information to identify which dialog steps are having extremely high response times  during you peak load time. Use this information to analyse, in detail, what is harming the performance of the corresponding transaction or dialog step. Use also the information on the distribution of the response time (DB time, CPU time, GUI time) given in the list, to identify the cause of the problem. Depending on the result proceed with a deeper analysis of the worst steps using, for example, transaction ST05 (for long DB times), transaction SE30 (for long CPU times) or a network analysis (not described in this document) in case of high GUI times. In addition, search for those taking particularly long (for example, more than 10 seconds). Contact the responsible user to find out what he was doing at that time, if the did some unusual steps or if he noticed a bad response time. If you cannot identify the cause, you may use the procedure described for transaction ST05 for a deeper analysis.  For details on the Performance monitoring on Function Code level and the monitoring setup  procedures use the following link  http://service.sap.com/~sapidb/011000358700003081072005E and navigate to section 2.1.© 2007 SAP AG  71 
  • 72. Best Practice: ALE Monitoring  727.1.5 Transaction ST05 The performance trace tool contains a range of trace functions that you can use to monitor and analyze the performance of the system in database accesses, locking, and remote calls of reports and transactions. It allows you to record database access, locking activities, and remote calls of reports and transactions in a trace file and to display the performance log as a list. It also provides extensive support for analyzing individual trace records. To use the performance trace, you need the authorization to start transaction ST05 and the system authorizations "Change trace switches" (authorization STOM for authorization object S_ADMI_FCD) and "Analyze traces" (authorization STOR, also for authorization object S_ADMI_FCD). The performance trace contains the following tracing options: · SQL Trace: This allows you to monitor the database access of reports and transactions. · Enqueue Trace: This allows you to monitor the locking system. · RFC Trace: This provides information about Remote Function Calls (RFCs) between  instances. The aim of the procedure described below is to find the SQL statements that are causing high response times in the SAP system. If you identified a transaction or a process step that is taking too long, you may use transaction ST05, to find out if one or more SQL statements are causing the performance problem. Procedure: Call transaction ST05 and make sure you are on the same instance as the user you want to trace: · Check the option SQL trace (also Enqueue and RFC trace if needed) · Activate the trace with filter · Enter the user name of the user that will perform the steps · Confirm · Ask the user to perform the relevant steps (and nothing else) · Deactivate the trace · Display the trace. Make sure the user name is correct. Write down the displayed time stamps  (trace period) to be able to find the same trace in the system later on. Use the extended trace  list to display the time stamps for each SQL statement. · Depending on what you are analyzing, it might be wise to let the user execute all steps twice  and use the second execution for the analysis. This way, you make sure that all buffers (for  example, program buffers) are filled. Go trough the trace and search for the statements with a high duration (marked red). Use the ‘explain’ function to see if the correct index is being used for that statement. In case you cannot find the cause of the performance problem, or need further assistance for the analysis, contact the next support level or open an SAP message on component SV­BO. Attach the trace, a detailed description of the performed steps and the related STAD records to the message. 7.1.6 Transaction SE30 The runtime analysis tool allows you to examine the performance of any ABAP programs, such as, reports, subroutines, function modules or classes. It saves its results in performance data files, which you can display as lists. You can use these results to identify runtime­intensive statements, to combine table accesses, and show the hierarchy of program calls. From the results of the runtime analysis, you can identify: · Excessive or unnecessary use of modularization units · CPU­intensive program functions · User­specific functions that could be replaced with ABAP statements · Inefficient or redundant database access.© 2007 SAP AG  72 
  • 73. Best Practice: ALE Monitoring  73Depending on the size of the program, considerable volumes of data can be generated during the runtime analysis. For this reason, this tool is set to Full aggregation by default. This means that only the standard hit list is generated with all calls. The standard hit list does not include Group hit list, Hit list of database tables, Class hit list, Instance hit list, Method hit list, Event hit list, Hit list of internal tables, Call hierarchy and Statistics. To cancel this restriction, switch off aggregation by replacing the standard variant in the initial screen with a temporary variant, for example. In this variant, you can then configure the measurement restrictions according to the selected objects to be measured. The runtime analysis consists of two parts: · Recording performance data · Analyzing the performance data In the first part, the system measures the transaction, program or procedure and writes the result to a performance data file. You can restrict the measurement to certain objects. You can also measure up to ten external processes. In the second part, the performance data is analyzed, and the system displays the results in list form. For more information on this transaction and its use, refer to the application help. The runtime analysis tool measures the CPU time required by the measurable components of a transaction, a program or a procedure. The information is stored in a performance data file, which you can analyze either immediately or at a later date. The CPU time required to measure the runtime is subtracted from the total CPU usage. If you measure the runtime of a program more than once, you are unlikely to get the same result on each occasion. There are various reasons why it is very difficult to obtain identical runtimes. For example, in the first measurement, the system might read data records from the table buffer on the application server, but in a second run, it may have to read them directly from the database. Runtimes also depend on the overall system or network load (for example, the number of jobs or systems currently active in your SAP System). In case you cannot find the cause of the performance problem, or need further assistance for the analysis, contact the next support level or open an SAP message on component SV­BO. Attach the runtime analyses, a detailed description of the performed steps and the related STAD records to the message. For more information on automated performance monitoring via CCMS and SAP Solution Manager, also read section 2.1 of the document Application Monitoring with SAP Solution Manager. 7.1.7 Transaction ST12 The Single Transaction Analysis tool allows you to examine the performance of transactions or ABAP programs, such as reports, subroutines, function modules or classes. You can trace the ABAP coding as well as the database activities (SQL trace / performance trace) in one run. It saves its results in performance data files, which you can display as lists. You can use these results to identify runtime­intensive statements, to combine table accesses, and show the hierarchy of program calls. From the results of the runtime analysis, you can identify: · Excessive or unnecessary use of modularization units · CPU­intensive program functions · User­specific functions that could be replaced with ABAP statements · Inefficient or redundant database access. ST12 allows you to aggregate the ABAP trace data per modularization unit (subroutine, loop, function call …) and gives the possibility to analyze the ABAP trace in different ways with a graphical help for easier identifying the call tree structure from different perspectives. The performance trace and the ABAP trace, if done from within one ST12 trace execution are kept in one named version and can be analyzed together. ST12 comes with the support tools add­on ST­A/PI à see note 69455 for details.© 2007 SAP AG  73 
  • 74. Best Practice: ALE Monitoring  74Note that the ST12 ABAP trace transaction is not officially documented and is only released for use by SAP or certified Service consultants during SAP Service Sessions (for example SAP GoingLive Check or Solution Management Optimization Services). ST12 is only available in two languages (EN/DE). ST­A/PI is small and does not interfere with productive coding. It can be implemented anytime and there is no need to logoff users. For details about the use of transaction ST12, see note 755977. Depending on the size of the program, considerable volumes of data can be generated during the runtime analysis. For this reason, this tool is defaulted to aggregation per calling position. This reduces the volume of records for a loop to the number occurrences in the coding of a loop – instead of separate records for each loop cycle. Note 755977 gives you more details. The runtime analysis consists of two parts: · Recording performance data · Analyzing the performance data In the first part, the system measures the transaction, program, or procedure, and writes the result to a performance data file. You can restrict the measurement to certain objects. You can also measure up to ten external processes. In the second part, the performance data is analyzed, and the system displays the results in list form. For more information on this transaction and its usage please see the application help. For more information on automated performance monitoring via CCMS and SAP Solution Manager please also read the chapter 2.1 of the document Application Monitoring with SAP Solution Manager. 7.2 General Monitoring Guidelines for a SAP System For the administration of an SAP R/3 system, there are a number of monitoring activities we strongly recommend scheduling and supervising on a regular basis. The following list is not complete, especially jobs and tasks for the database administration (such as backups, archiving transaction logs, update statistics for cost base optimizer and so on) are not mentioned, however it gives you an impression of what you have to do in order to keep a system running. If you have further questions on these subjects, please refer to the Solution Management Optimization Service System Administration. The table below lists transactions used for General System Checks: Monitoring  Monitor  Monitor  Monit  Indicator or  Monitoring Activity or  Respon­ Object  TA/Tool  Freq.  or Error  Error Handling Procedure  sibility  Time R/3 System  ST03N  daily  tbd  Average  Review response times in  Software workload  dialog  comparison to system load and  monitoring analysis  response  performance influencing changes  team  time  within the system of the analyzed  < 1000 ms  period.  Identify and improve performance  of any transaction whose response  time exceeds the times defined in  the Service Level Agreement  (SLA), if it exists.  Monitor RFC response time  statistics and Dialog response  times for online transactions. Database  ST04  Weekly  tbd  Increased  Monitor database statistics.  Software perform­  and in  database  Monitor the buffer cache hit ratio  monitoring ance  case of  response  team performa  time /  Check for missing indexes; ensure © 2007 SAP AG  74 
  • 75. Best Practice: ALE Monitoring  75Monitoring  Monitor  Monitor  Monit  Indicator or  Monitoring Activity or  Respon­ Object  TA/Tool  Freq.  or Error  Error Handling Procedure  sibility  Time Analysis  nce  Expensive  that the data quality is sufficient,  problems  SQL  and that there is sufficient space  statements  available. Operating  ST06  Hourly  tbd  High paging  Monitor the CPU and memory  Software system  (dependi  rate and  consumption.  monitoring monitor  ng on the  CPU  A hardware bottleneck can have a  team  business  utilization  negative impact on the overall  process)  response time, as well as the  and in  response time of an individual  case of  business transaction.  performa  nce  Especially monitor hardware load  problems  during high RFC transmission  times. R/3 System  ST02  Weekly  tbd  Swaps  Monitor memory resource usage for  Software buffer  and in  specific R/3 application servers  monitoring monitor  case of  To ensure optimal performance,  team  performa  check that the R/3 parameters are  nce  set correctly with transaction ST02.  problems  Incorrectly sized R/3 buffers or  memory allocation can result in  poor performance. One such  example would be when a work  process enters PRIV mode. Local work  SM50  hourly  tbd  WP status,  Monitor current state of individual  Software process  during  WP  work processes.  monitoring overview  peak  utilization  Ensure that enough work process  team  hours  capacity is available at peak times.  and in  case of  performa  nce  problems  or error  message  s System­  SM66  hourly  tbd  WP status,  Similar to SM50 but for system­  Software wide work  during  long running  wide statistics.  monitoring process  peak  jobs  team overview  hours Database  DB02  Daily and  tbd  Table space  Ensure that the data quality is  Software perform­  in case  sizes, table  sufficient, that there are no missing  monitoring ance  of  indexes for  indexes, and that there is sufficient  team monitor  performa  tRFC and  space available.  nce  aRFC  In general, if table sizes are larger  problems  than 500MB, reorganize the table  and decrease its size.  See SAP Note 375566.  Monitor the growth of tables and  indexes, especially on tRFC­ and  qRFC­tables (ARFCSSTATE  ARFCSDATA  ARFCRSTATE) ABAP dump  ST22  daily and  tbd  Dumps  Check short dumps; analyze  Software analysis  in case  aborted programs.  monitoring  of an  Select a period and click on the List  team errors  button. Select an error, and then  choose Display to see the short  dump. © 2007 SAP AG  75 
  • 76. Best Practice: ALE Monitoring  76Monitoring  Monitor  Monitor  Monit  Indicator or  Monitoring Activity or  Respon­ Object  TA/Tool  Freq.  or Error  Error Handling Procedure  sibility  Time  For SAP developed programs that  experience frequent terminations,  investigate SAPNet for a possible  resolution and if necessary, open a  customer message. For customer  developed programs contact the  appropriate member of the  development team. System log  SM21  daily and  tbd  Entries  Check for general system program  Software  in case  errors and table space errors or  monitoring  of an  transactions that encounter errors.  team  errors  Maintain date/time and select  Reread system log. Position cursor  on a time, and then choose  Display. Update  SM13  daily and  tbd  Status  Check for entries that have status  Software tasks  in case  ‘ERR’.  monitoring  of an  Update records should be  team  errors  monitored regularly and the  appropriate user should be  contacted immediately to resolve  any outstanding updates. Together  with the user, determine whether  the update request can be re­  started or has to be deleted. Display  Transac  In case  tbd  Status  Determine the performance of  Software Statistical  tion  of bad  single statistical records  monitoring Record  STAD  performa  team nce © 2007 SAP AG  76 
  • 77. Best Practice: ALE Monitoring  778 Further Information Troubleshooting  If executing this Best Practice did not produce the desired results, · Search for related notes in the SAPNet. · Open an SAP Customer Message describing your problem (please see the respective  component in section Error Handling, Restartability and Escalation of every step). Literature · For detailed information on how to administer an SAP R/3 system, see the book:  Liane Will, SAP R/3 System Administration, 2003 · For information on how to monitor and tune the general system performance, see the book:  Thomas Schneider, SAP Performance Optimization Guide, 2006.© 2007 SAP AG  77 
  • 78. Best Practice: ALE Monitoring  78© Copyright 2007 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.  ®  ®  ®  ®  ®  ®  ® Microsoft  , WINDOWS  , NT  , EXCEL  , Word  , PowerPoint  and SQL Server  are registered trademarks of Microsoft Corporation.  ®  ®  ®  ®  ®  ®  ®  ®  ®  ®  ® IBM  , DB2  , OS/2  , DB2/6000  , Parallel Sysplex  , MVS/ESA  , RS/6000  , AIX  , S/390  , AS/400  , OS/390  , and  ® OS/400  are registered trademarks of IBM Corporation.  ® ORACLE  is a registered trademark of ORACLE Corporation.  ®  ®  TM INFORMIX  ­OnLine for SAP and Informix  Dynamic Server  are registered trademarks of Informix Software Incorporated.  ®  ®  ®  ® UNIX  , X/Open  , OSF/1  , and Motif  are registered trademarks of the Open Group.  ® HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C  , World Wide Web Consortium, Massachusetts Institute of Technology.  ®  ® JAVA  is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT  is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies. Disclaimer : SAP AG assumes no responsibility for errors or omissions in these materials. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non­infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. 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.© 2007 SAP AG  78 

×