This action might not be possible to undo. Are you sure you want to continue?
Best Practice for Solution Management
Version Date: 16.05.2007
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
Best Practice: ALE Monitoring
3.2.1 Single IDoc time stamp analysis...............................................................................38 3.3 Automated Backlog Monitoring .........................................................................................39 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 Aspect: Resource Monitoring.................................................................................................57 5.1 Manual Resource Monitoring............................................................................................58 5.2 Automated Resource Monitoring.......................................................................................61 Aspect: Data Management ....................................................................................................62 6.1 Manual Data Volume Monitoring.......................................................................................64 6.2 Automated Data Volume Monitoring..................................................................................64 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 Further Information................................................................................................................77
© 2007 SAP AG
1.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 ALEbased 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.
You can have SAP experts deliver this Best Practice onsite 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.
the connected satellite systems has to be at least of release 4. How to use this Best Practice This document gives you an overview on interface monitoring tools and procedures for ALE/EDI monitoring. 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”. In the next step you can follow the setup procedure and implement the monitoring on your systems. for example performance monitoring. © 2007 SAP AG 4 . Timing The best time to apply this Best Practice is during the planning phase or during the implementation phase of your SAP solution. To have all described monitoring object available in SAP Solution Manager. 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. We do not recommend setting up a full blown monitoring but recommend concentrating on selective alert situations that will inform you in exceptional cases. Performance Monitoring and Data Management. 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. 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. Backlog Monitoring. Error Monitoring.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. addons STPI and STA/PI has to be installed on the SAP satellite systems.6C. For a better understanding on what should be monitored it is essential to understand the ALE processing mechanism. 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. Sections 2 to 6 list monitoring objects both for manual as well as automated monitoring procedure concentrating on the six major areas: Resource Monitoring.
Also detailed error handling and disaster recovery procedures need to be defined. This includes the integration with the Incident/Problem Management process and the Change Management process.2 Best Practice Procedure 1. See the separate Best Practice for General Business Process Management for further details.2. specific data consistency reports have to be executed on a regular basis. 1. An Interface Monitoring concept has to be tightly integrated with the support organization. 1. This includes the definition of the roles and responsibilities involved. separate communication and escalation paths and procedures have to be defined. © 2007 SAP AG 5 . IT Operation relies completely on the fact of 100% data consistency.3 Interface Monitoring concept For a successful and efficient Interface Monitoring concept. All those interfaces need to be monitored in terms of resource availability. For early detection.2. With an increased complexity of system landscapes we face an increased risk of data inconsistency.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. ensure that you perform the following preliminary tasks or checks in the system: · · · · Complete all installation and postinstallation 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.Best Practice: ALE Monitoring 5 1.1 Motivation for Interface Monitoring Today’s system landscapes are often decentralized and can consist of various interfaces. 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. Wherever communication connected with Interface Monitoring happens outside these support processes. These processes have to be adjusted so that communication and escalation procedures contained within these processes are adequate to support the Interface Monitoring concept.2 Preliminary Tasks Before performing this Best Practice. This includes the final communication of open alerts to SAP. A proactive interface monitoring helps to identify and avoid inconsistencies. Different SAP systems.2.2. 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. backlog situations and performance. a process for the execution of the monitoring concept has to be defined. processing errors. legacy environments and business entities are integrated using different interface technologies.
the following data can be exchanged via ALE: • Transaction data. which provides data to be exchanged.3 IDocs IDocs are predefined data structures of SAP applications at the interface level. Each application has a special set of IDoc types. EDIFACT. 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). It describes the document exchange with business partners on a technical level. ALE uses the business scenarios and function modules that allow transfer data to or from an SAP system without developing customerspecific programs. The standard is ANSI X12 and it was developed by the Data Interchange Standards Association.3. The data is not only transferred between the systems; in addition it can also trigger followup actions in the SAP system. EDI describes the mapping of the application data structure from the sender into the EDI standard. IDocs can be used to exchange data between two R/3 systems or between R/3 and an external system (non SAP). From the SAP viewpoint. 1.2 EDI (Electronic Data Interchange) EDI is a standard format for exchanging business data.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. such as customer or material master data • Customizing data used for an overall ALE view Data can be exchanged between SAP Systems and external (nonSAP) systems.3. ANSI X12 is either closely coordinated with or is being merged with an international standard. and then converts it to the IDoc format supported by SAP for further processing. IDoc data exchange is always an asynchronous process. The following functions and interfaces form the basis of communication: • ALE with all its components such as monitoring. 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 .Best Practice: ALE Monitoring 6 1. Instead of calling a program in the destination system directly (RFC). archiving. 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 data is first packed into an IDoc and then sent to the receiving system. With EDI the technical structure of the document is retained. • Usage of the data container called Intermediate Document (IDoc) • Transactional RFC (tRFC) 1. where it is analyzed and properly processed. IDoc types form the container for the data to be exchanged. which is data from applications • Master data.3 General Overview on ALE/EDI 1. ALE is linked closely with Workflow Management within SAP.3.
4 Change Pointers: If you want to distribute master data changes with the SMD tool (Shared Master Data). Change pointers are basically the key fields of the table that contains the changed field. Figure 12 Transaction WE20 ALE processing mode © 2007 SAP AG 7 . It is configured using transaction WE21 (ports in IDoc processing). The SMD tool is connected to the change document interface. customers can specify the fields that need to be distributed. reads the application data and creates the master IDoc. The master IDoc is then passed to the ALE layer. In ALE Customizing. The port type is specified in transaction WE20 (partner profiles) choose partner and select relevant outbound parameter. 1. changes to the master data objects are flagged for distribution by change pointers ( ® Master Data Distribution).3. The tool writes change pointers. The contents of this are passed to the SMD tool.Best Practice: ALE Monitoring 7 Figure 11 Application Link Enabling / IDoc flow 1. The method of sending is determined by the port type and depends on the technical configuration of the target system. If the master data changes are to be distributed (defined in ALE customizing).3. which sends it to all interested systems. the application writes a change document.5 ALE Processing Modes There are two basic ways to send IDocs via tRFC (ALE) or via flat file (EDI).
1. 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.5.3. Outbound and Inbound IDocs can either be processed individually (immediate transfer) or as a collection/package using a background job.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.2 EDI Flat File Most common between R/3 system and EDI subsystem is the flat file interface (standard EDI scenario).5.12 1. 1. Ÿ Each tRFC is sent exactly once. 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. transactional data. even if the recipient partner is not active. so that there are no accidental double postings of application data.3. 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. When the partner is available again. Ÿ If an SAP system receives the data.3. This setting is made in the partner profile using transaction WE20. a new attempt can be made to transfer the data. Ÿ All erroneous attempts to post data are displayed in the tRFC monitor.3.5. the requests are handled as transactions.5.Best Practice: ALE Monitoring 8 1.3.3 Processing Modes Processing in the application layer and the ALE layer are completed on both the outbound and inbound processing sides. © 2007 SAP AG 8 .1 Outbound IDoc Processing Transaction WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Outbound Parameter. This means that all functions called in one tRFC are either processed together or not at all.
Packet Size: A general recommendation is between 50 and 100. 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 immediate processing is implemented. 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). There is a performance overhead associated to this technique as a new connection is opened for each IDoc sent. If too high a number for “max number of IDocs” is selected.sap. 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. in addition the same programs. 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 can lead to runtime errors (for example Timeouts). user contexts. avoids reading common database tables from disk several times and so on. © 2007 SAP AG 9 . and database tables are read multiple times. IDocs are transferred immediately to the receiver system as soon as IDocs are created. 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. It is recommended where possible (business requirements may dictate that immediate processing is required) to use the output mode “ Collect IDocs” . the sender also has to wait for an acknowledgement about the success of the processing from the receiver. In this case.com/ifm ). For more information visit: http://service. 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. However.Best Practice: ALE Monitoring 9 Figure 13 Transaction WE20 – Partner profile outbound When the output mode “Tars Immediately” is activated. you must choose a lower value.
Best Practice: ALE Monitoring 10 Figure 14 Report RSEOUT00 © 2007 SAP AG 10 .
3. If mass processing is not supported. If you use function modules that can process IDocs in mass. one commit is triggered for all IDocs belonging to a packet. and database tables are read multiple times.2 Inbound IDoc Processing: Transaction WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Inbound Parameter. It offers additional © 2007 SAP AG 11 . Single IDocs can be put into packets and then processed this functionality is provided by report RBDAPP01.Best Practice: ALE Monitoring 11 1. This type of package processing is valid for all IDoc types as there are no special requirements for the inbound function module. Trigger by Background Program It is important to note that if the receiver system uses 'trigger immediately' option.5. This type of package processing can be used depending on the configuration of the Inbound function module used for an IDoc. Figure 15 Transaction WE20 – Partner Profile inbound Trigger Immediately: Upon receipt inbound IDocs are immediately released for posting. this has a significant optimization potential as overhead is reduced significantly. and database tables are read multiple times. user contexts. IDocs will be posted one by one. Inbound IDocs and IDoc packets are first saved in the database into single IDocs. This can be checked via transaction BD51. 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. the same programs.3. the same programs. which allows you to specify the package size for the RFC call. In this case. ALE inbound processing splits the IDoc packets into individual IDocs; this results in an overhead such as. user contexts. 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 the input type value is set to ‘0’ the function module is enabled for mass processing. each IDoc would be processed in a new dialog process meaning. This does however reduce the administrative load on the R/3 System because if packaging was not implemented.
Best Practice: ALE Monitoring 12 optimization potential apart from the loading of the programs and users contexts and avoids reading the common database. This leads to a tighter control on the handling of the incoming IDocs. IDocs will not be processed unless report RBDAPP01 is scheduled. As a guide. 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. 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’.) © 2007 SAP AG 12 . you should use a packet size of between 20 and 100 IDocs. Schedule posting and configure packaging: Create variants of report RBDAPP01 and schedule as required using transaction SM36. To do this carry out the steps below in ALE Customizing: 1. It is recommended where possible (business requirements may dictate that immediate processing is required) to use the inbound processing mode “Trigger by background program”. Figure 16 Report RBDAPP01 Additionally. (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. To specify a package size use field pack size.
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. Server groups are set up using transaction RZ12 below. then the IDoc processing can occupy all the dialog processes on the application server. 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). by defining RFC groups. This could result in resource shortages in the application servers. 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. An RFC group specifies the set of allowed servers for a particular parallelprocessed job. you can control which servers can be used for parallelprocessed jobs. Only one work process will be used for this action on the application server. However. Figure 182 Transaction RZ12 – RFC Server Group Maintenance Application servers in a server group can be used in parallel for updating IDocs in the background.Best Practice: ALE Monitoring 13 Figure 171 Report RBDAPP01 – Parallel processing As illustrated above report RBDAPP01 can be configured to facilitate parallel inbound processing. If several IDoc packets have been selected. The input field server group defines the RFC Server group which will be used by the report in parallel processing. © 2007 SAP AG 13 . a parallelprocessed job uses all qualified servers in an SAP System according to automatic resourceallocation rules. all dialog processes in the SAP system are used in parallel. If you do not specify a server group. There might be only one application server in a server group. This means that the packets can be processed in parallel. By default. Parallel processing can be used to improve performance and spread the load to a specific group of application servers.
resources are not available. Figure 193 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. IDoc number. 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. 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.). If however. 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. using a unique number (for example. MSGGUID or original application document number. it must be verified in advance that the middleware/target system can handle files that include multiple IDocs. (See figure 163 below). and so on. © 2007 SAP AG 14 . EDI).. 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.Best Practice: ALE Monitoring 14 Generally. Therefore the file port (WE21) should be configured to use a function module which generates dynamic file names such as.
Types of errors that can be monitored are for example errors from logs (system log. © 2007 SAP AG 15 . Business Process Monitoring (BPMon) reveals even slight deviations from a predefined ideal business process state which would otherwise remain undetected until the flow of the process would be seriously impacted. update errors. This is also possible with interface monitoring. Business Process Monitoring (BPMon) within SAP Solution Manager is the proactive and process oriented monitoring of the core business processes of your company. Such automated monitoring is optimally implemented using Business Process Monitoring or System Monitoring in SAP Solution Manager. throughput and backlog KPIs for various applications. dialog performance. It includes the observation of all technical and business applicationspecific functions that are required for a smooth and reliable flow of the business processes. composing them to preconfigured PCs and selling them within Europe.1 Interface Monitoring in SAP CCMS and SAP Solution Manager For some monitoring activities it is possible to use a tool for automated monitoring. The sales department is divided between Great Britain.4 Example Business Scenario with ALE For the different aspects of interface monitoring the SAP Solution Manager can be used. One of their core business processes is named “Processing Purchase Orders” and is maintained within the SAP Solution Manager. 1. 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.Best Practice: ALE Monitoring 15 1. To monitor the IDoc flow from endtoend 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’. application log and so on). IDoc message flow Figure 110 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. other EU countries and non EU European Countries. 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. Its main business is buying PC components.4. It gives automated alerts including the possibility to notify these via various communication means like email. SMS and so on.
4.2 Specific ALE/EDI Monitoring Besides the standard monitoring objects available in SAP CCMS you can setup a specific ALE monitoring. if needed. This © 2007 SAP AG 16 .4. 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. Figure 111 CCMS ALE/EDI Standard Monitoring Groups 1.1.com/bpm. The standard CCMS monitors on the satellite system show an ALE/EDI IDoc Monitoring for all message types in inbound and in outbound direction. indicating the relevant automatic monitoring functionalities. 1.Best Practice: ALE Monitoring 16 For further details on Business Process Monitoring refer to http://service.1. In our example IDocs of type ‘MATMAS’ are exchanged between two SAP systems. The approach of this section is to outline the setup procedure for a selective interface monitoring for messages involved in your core business processes.sap. This gives you the possibility to individually monitor IDocs which refer to certain business processes.sys ‘name of logical system’.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. Wherever monitoring via SAP Solution Manager is possible you will find a separate table.
This can be done either in inbound or in outbound direction or both. Figure 112 BDMO – Create/Activate Monitoring Objects In the following screen the new entry needs to be entered and set to active. In the entry screen it is now possible to select the newly created monitoring object. it can be left blank. The following screen will pop up: Figure 114 BDMO – Customize Monitoring Object The specific message types for the inbound and/or outbound direction of an interface need to be specified. these objects are considered as customizing. The customizing of ALE/EDI monitoring objects can be done with transaction BDMO. 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). To create a new monitoring object the button Create/activate monitoring objects in the entry screen of transaction BDMO must be used. System wise.Best Practice: ALE Monitoring 17 interface is part of the core business process “Processing Purchase Orders” and is a critical interface which needs to be monitored on a regular basis. It is also possible to © 2007 SAP AG 17 . they have to be set up in the development system and from there transported via the quality assurance system to the productive system. With transaction BDMO it is possible to create new monitoring objects only for a specific message type and to activate them accordingly. Figure 113 BDMO – New Entry In some cases it might be necessary to recall transaction BDMO to have the new entry available. If one direction should not be monitored explicitly. Therefore.
This will create new entries in the CCMS (transaction /NRZ20) and start the data collection for the ALE/EDI alerts but just once. 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. The system type of the partner system needs to be maintained as well as the system number from the partner (see transaction WE20). In field Days until now you can specify the age for IDocs in days which won’t be included into the evaluation. which are in status 03 for longer than 60 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.Best Practice: ALE Monitoring 18 specify more than one message type if needed. that is specified in the development system already has to be the connected productive system which should be monitored later on. If this time has not elapsed since the last status change. To actually create the monitoring objects. per default on an hourly basis. b. Those IDocs are sometimes processed on an hourly basis. Monitoring on the number of IDocs. the previous status is used and not the last one. The Monitoring Object is created in a development system and is then regularly transported into the productive environment. But if this is not the case after 30 minutes they are counted as IDocs in status 51. 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. Therefore it makes sense to evaluate the IDocs in status 03 if they have not been processed since longer than 60 minutes. 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 . In section Period you can specify the number of days for the age of the IDocs that should be included into the evaluation. This way the program RBDMONI_CCMS_IDOC is scheduled in the background job SAP_CCMS_MONI_BATCH_DP. Depending on your requirements you can change the frequency to enable a more realtime alerting. Monitoring on the number of IDocs. 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. then choose Monitoring Object / Start all in the entrance screen of transaction BDMO. which are in status 51 for longer than 30 minutes. To be able to assign both monitoring objects to the same interface in the SAP Solution Manager they must have exactly the same names. Hence the Partner no. Use cases might be the following: a. If the same interface should be monitored on the sending system as well as on the receiving system.
select the message type and click on details. © 2007 SAP AG 19 .Best Practice: ALE Monitoring After the program execution the created monitoring objects are generated in SAP CCMS: 19 Ar ea1 Ar ea 2 Ar ea 3 Figure 115 ALE/EDI Specific Monitoring Objects Area 1: IDocs are generated via change pointers. Therefore the number of open change pointers is relevant for monitoring. In the SAP CCMS the main statuses are grouped together depending on the direction. Area 2: An IDoc changes its status during the message processing. Ø 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. select the partner number. To check the processing mode navigate to transaction WE20.
the Interface Technique (for example. the required interface must be selected for Monitoring. The Interface Name and the Interface Technique can be changed manually. all pairs of consecutive business process steps on different systems. To customize the interface. Initial Step (usually the business process step that sends information). At least one business process with steps on different systems and defined interfaces must be available before it is possible to configure interface monitoring. © 2007 SAP AG 20 . Sender and Receiver (SID respectively) are displayed. In node Interface Monitoring all existing interfaces for the corresponding business process and the selected steps are displayed. 1. ALE/EDI. such as. To differentiate between the interfaces.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. Final Step (usually the business process step that receives information). qRFC). Interface Name (per default “<Sender SID>><Receiver SID>”.1.Best Practice: ALE Monitoring 20 Figure 116 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.4.
This is not visible at first. a subnode appears: Interface “<Name of the Interface>“(<ALE or EDI>).1 Implement ALE/EDI Interface Monitoring If an interface is selected for monitoring with the Interface Technique ALE or EDI. Outbound objects on Sender side and Inboundobjects on Receiver side) are loaded into the session. qRFC and tRFC this is described in the following subsections) or the subnode is empty for all other Interface Techniques.Best Practice: ALE Monitoring After saving the entries for every interface that is selected for monitoring a respective subnode Interface “<Name of the Interface>“ (<Interface Technique>) will be created. 21 Figure 117 Setup Interface Monitoring in SAP Solution Manager This subnode is either used for loading Monitoring Objects from the connected local CCMS (for ALE/EDI. Copy the selected objects and save.4.3.1. 1. This happens with the pushbutton: Reload CCMS: ALE Mon Objects. but when the F4 value help is used for either SID or ALE Monitoring Object. 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. All ALE/EDI monitoring objects available on the satellite systems (that is. Figure 118 Use Value Help for ALE/EDI monitoring objects © 2007 SAP AG 21 . then all reloaded Monitoring Objects appear and can be selected for monitoring.
To transfer all the threshold values at once. It is also possible to change the threshold values for the alerts manually. relating to the Monitoring Objects selected in the node above. appears. Alert Monitors. the new values are transferred to the local CCMS of the monitored system. The next step is to decide what kind of alert should be selected for monitoring. When saved. Figure 119 Selection of ALE/EDI related alerts © 2007 SAP AG 22 . All Outbound alerts for the Sender system and all Inbound alerts for the Receiver system. all the corresponding threshold values are loaded from the local CCMS.Best Practice: ALE Monitoring 22 A new sub node. doubleclick the copy icon between them. are loaded into the session. Additionally. select "Copy All". To transfer the threshold values for a single line from right to left.
ensure a clear visualization and prioritization of incidents to support their fast and effective resolution. All IDocs start with status 01 (IDoc generated) in Outbound. Each step in the processing of the IDoc has a different status number. Error Monitoring includes the monitoring of all error situations documented within the system. therefore. and the numbers from 01 to 49 are reserved for Outbound status (5099 are Inbound status). are detailed below: Possible error statuses for Outbound IDocs Code 02 04 05 07 09 11 15 20 21 23 25 26 27 29 30 31 34 36 37 40 Description Error passing data to port Error within control information of EDI subsystem Error during translation Error during syntax check Error during interchange handling Error during Dispatch Interchange Acknowledgement negative Error triggering EDI subsystem Error passing data for test Error during retransmission Processing despite syntax error (outbound) Error during syntax check of IDoc (outbound) Error in dispatch level (ALE service) Error in ALE Service IDoc ready for dispatch (ALE service) Error no further processing Error in control record of IDoc Electronic signature not performed (timeout) IDoc added incorrectly Application Document not created in receiving system Possible error statuses for Inbound IDocs Code 51 52 54 56 57 60 © 2007 SAP AG Description Error: Application document not posted Application document not fully posted Error during formal application check IDoc with errors added Test IDoc: Error during application check Error during syntax check of IDoc (inbound) 23 . Error monitoring is intended to detect critical situations and exceptional cases during interface processing. The next sections will deal with individual aspects of interface monitoring. 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. Monitoring procedures should.Best Practice: ALE Monitoring 23 2 Aspect: Error Monitoring From the previous sections. The various error statuses which can occur for outbound and inbound IDocs and which should be monitored on a daily basis. Error situations can be identified by the occurrence of error messages or error statuses. As these incidents can endanger the entire data flow between the involved systems. their identification can be extremely important and time critical.
Errors can occur at any of the 5 steps. 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 21 Standard ALE processing error monitors Monitoring Objects: The figure below shows how data is distributed using ALE. multiple systems and different interface technology are utilized. so these steps represent our monitoring objects. There are various tools for monitoring and problem analysis. 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 .Best Practice: ALE Monitoring 24 61 63 65 68 Processing despite syntax error (inbound) Error passing IDoc to application Error in ALE service Error no further processing Monitoring Requirements: In a typical solution landscape.
If this is the case you can drill down to display the Respon sibility Business Process Operations Team / SAP Technology Operations Team Escalation Procedure Application Management Team / Business Process Champion Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion © 2007 SAP AG 25 . If IDoc is found in failed status. If IDoc is not found. if so. Choose timeframe and various selection criteria.1 Manual Error Monitoring As in the above description. the following table documents the handling of errors at the five processing statuses. Double click on various statuses to get a list of IDocs. 52. check if background job is running. A list of IDocs will be displayed for various message types. or Error Check if IDocs BD87 were created successfully by ‘Application Layer’ (sender system) As required by business IDoc in error or no IDoc created IDocs in status BD87 “Error in Application Layer” (receiver system) As required by business Existence of the following statuses: 51. For IDocs in status 51 BD87 will state whether an application log exists for the IDoc. check if interface is configured to collect and. It is possible to drill down to display the IDoc and its status records (by double clicking). Indicator Object TA/Tool Freq. 54. Monitoring Activity or Error Handling Procedure Use BD87: enter correct date/time frame and logical message type. Call transaction BD87on receiving system.Best Practice: ALE Monitoring 25 Figure 22 ALE layers 2. Monitoring Objects w/o SAP Solution Manager Monitoring Monitor Monit. review status text for reason for failure. 57.
an application log pushbutton becomes available in the status record display. Choose timeframe and various selection criteria. to get some information using transaction SLG1. It may be possible. however. You can specify <*IDOC NUMBER*> in field “External ID”. choose timeframe and check for IDocs in status 03. Analyze reason accordingly Business Process Operations Team / SAP Technology Operations Team 26 Application Management Team / Business Process Champion IDocs in status BD87 “Error in ALE layer ” (receiver system) As required by business Existence of the following statuses: 56. It is possible to drill down to display the IDoc and its status records (by double clicking). Call transaction BD87on receiver system.Best Practice: ALE Monitoring IDoc. 65. 27. ensure report SM58 RBDMOIND shows Is running. Doubleclick to get more details for each tRFC. If report is tRFCs in running check error status transaction SM58 as below. 34. it means that a detailed log is not available. It is possible to drill down to display the IDoc and its status records (by double clicking). Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion IDocs stuck in commun ication layer ” SM58/BD As 87 required by business BD87 shows IDocs in status 03 In BD87. 60. 21. Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion © 2007 SAP AG 26 . Analyze reason accordingly. If you doubleclick on the IDoc status record. 26. IDocs in status BD87 “Error in ALE layer ” (sender system) As required by business Existence of the following statuses: 02. A list of IDocs will be displayed for various message types. A list of IDocs will be displayed for various message types. 37 Call transaction BD87on sender system. 29. 63 . choose timeframe to see a list of tRFCs with errors. If there are IDocs in status 03. If no button is available. In SM58.
Double click on individual work items to find out why they failed Call transaction WE07. 08. 36. Double click to drill down to display IDoc and status records. test Operations active EDI access to specified Team scenario? If directory using not. If SAP correspond IDoc was not Technology ing to processed recently. 15. Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion Business Process Operations Team / SAP Technology Operations Team Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion Application Management Team / Business Process Champion © 2007 SAP AG 27 . Choose timeframe and various selection criteria.Best Practice: ALE Monitoring 27 Error in external system BD87 As required by business Existence of following statuses 04. Choose timeframe and various selection criteria to display a list of IDocs with errors. there transaction WE21 > is a choose file port and problem. 05. 40 Inbound IDocs WE08 from flat file As required by business Business Process Operations Team / SAP Technology Operations Team Was the Transaction WE08 > Business file double click on Process processed directory check date of Operations recently for last processing and last Team / directory IDoc/record number. A list of workflows will be displayed in error status. Validate using transaction SM37 that the various ALE/EDI background jobs are scheduled and are running successfully as listed below (this should be done at least once a day). Application Management Team / Business Process Champion Application Management Team / Business Process Champion Workflow SWI2_DI triggered by AG Inbound IDocs As required by business If listed workitem it is in error IDocs with errors WE07 As required by business IDocs with errors IDoc background jobs SM37 Once daily Jobs with errors Call Transaction SWI2_DIAG. 09. 07. 17. perform an access test. In addition check for errors in BD87. 23. 11. Choose timeframe and various selection criteria on the sender system and analyze the reasons in BD87.
37) Outbound SAP CCMS Hourly IDocs in this Analyze the IDocs in / SAP status reasons in status “Error Solution BD87 in external Manager system” (statuses: 04. 57) Inbound IDocs in status “Error in IDoc Interface” (statuses: 56. 26. 40) Inbound SAP CCMS Hourly IDocs in this Analyze the IDocs in / SAP status reasons in status “Error Solution BD87 in Manager application” (statuses: 51. 21. 65) Background jobs for IDoc processing listed above SAP CCMS / SAP Solution Manager Hourly IDocs in this status Analyze the reasons in BD87 Respon sibility Escalation Procedure Business Process Operations Team / SAP Technology Operations Team Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion Application Management Team / Business Process Champion SAP Solution Manager As Cancellations. 23. 17. 29. 36. 27. refer to the section Interface Monitoring in SAP CCMS and SAP Solution Manager. needed Maximum duration Analyze the reason in SM37 IDoc processing monitoring using SAP workflow SAP Workflow As Error needed situations (by status) Analyze the reasons in BD87 Business Process Operations Team / SAP Technology Operations Team Business Process Operations Team / SAP Technology Operations Team Business Process Operations Team / SAP Technology Operations Team Business Process Operations Team / SAP Application Management Team / Business Process Champion Application Management Team / Business Process Champion Application Management Team / Business Process Champion Application Management Team / Business Process 28 © 2007 SAP AG . Automated Monitoring Objects with SAP Solution Manager Monitoring Monitor Monit Indicator or Monitoring Object TA/Tool Freq. Error Activity or Error Handling Procedure Outbound SAP CCMS Hourly IDocs in this Analyze the IDocs in / SAP status reasons in status “Error Solution BD87 in IDoc Manager interface” (statuses: 02. 15. 34. 11. 60. 05. 20. 54. 09.2 Automated Error Monitoring For details on how to setup the automated error monitoring. 08. 07.Best Practice: ALE Monitoring 28 2. 63.
validate message control is set up properly via NACE. It is also possible to perform an ABAP or SQL trace using transaction ST12 see Section 7 of this document. Job runtime: This depends on many factors (Functionality/activity of the job. (Creates IDocs) 4.Best Practice: ALE Monitoring (refer to SAP note 116610) Update errors for transactions or programs SAP Solution Manager Hourly Update errors V1 / V2 Analyze the reasons in SM13 Technology Operations Team Business Process Operations Team Champion 29 tRFC errors (refer to figure ALE/EDI Specific Monitoring Objects) SAP CCMS / Hourly SAP Solution Manager Too many remote calls waiting SM58 Application Management Team / Business Process Champion Business Application Process Management Operations Team / Team / Business SAP Process Technology Champion Operations Team 2. RBDMANI2 (posts status 51 IDocs) Typical Outbound jobs run programs 3. · Typical Inbound jobs run programs: 1. RSEOUT00 (sends IDocs – we14) 5. RSNAST00 – WE15 (If using message control. hardware. Further information about the cause of the failure may be available in the system log transaction SM21. RSARFCEX (clears IDocs out of ALE/RFC layer) 6. we cannot give exact statements about performance indicators. RBDMIDOC (Change Pointers. Therefore. RBDMOIND (changes IDoc from status 03 to 12) 7. using transaction SM37. Also. Monitoring should include an assessment of: · Occurrence of failed/cancelled jobs: The job logs should be investigated to determine what caused the error. you can check via partner profile WE20). investigate using the job log.3 Details on IDoc Batch Job Monitoring Confirm that the below background jobs are scheduled and are running successfully. If a background job is deemed to be running long. RBDAPP01 (posts IDocs) 2. can check via BD50) © 2007 SAP AG 29 . system resources etc).
Check if the directory exists and there is enough space left in the file system. 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 . 2. 2.Best Practice: ALE Monitoring 30 2.4. If necessary. (See the note 532918 for more details). then the connection from this server to the outbound directory should be checked. 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).4. 2. the Gateway developer trace needs to be reviewed and/or a RFC trace needs to be created and analyzed.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.4. see also SAP notes 334097 and 90111.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. because a user has insufficient authorization to relevant directory to write a file. or the receiving system does not have any dialog work processes available or there are other resource issues. this means that the tRFC call has not yet been executed. use the transaction SM59. Ensure that the user has at least assigned authorization object S_DATASET. debug the application program that creates the IDoc. If there is a problem with a specific application server. If the report is running.4 Handling different error statuses ALE/EDI There are instructions below on issue resolution for the most important error statuses. but has not yet been transferred to the receiving system. Analysis steps/Solution: Start by checking access to the outbound directory from each application server (WE21). 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. If this does not solve the problem. Maybe the network is down.1 Status 02: Error passing data to port Common causes of error: · Access to the file system does not work. Processing discontinued only if “Cancel Processing After Syntax Error‘ is flagged in WE20 (Partner Profiles). · Directory might not exist · File System full. To do so.
Best Practice: ALE Monitoring Analysis steps/solution: · Check IDoc error status using transaction WE02/WE05 · Review IDoc structure using transaction ‘WE30’ · If necessary.5 Status 51: Application document not posted IDoc could not be posted. If the error cannot be corrected. to collect IDocs that could not be posted because of a lock problem. however. by setting a breakpoint in the relevant IDoc inbound function module (WE20) If IDocs are in status 51. If no button is available it means that a detailed log is not available. 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.4 Statuses 27. you can reprocess the IDoc. When you doubleclick on the IDoc status record. If this is possible. 31 2. then a new IDoc has to be created and the “old” IDoc has to marked for deletion. you can drill down to display the IDoc.4. transaction BD87 will state whether an application log exists for the IDoc. o Resending IDoc: Check if the error can be resolved by changing the businessrelated objects. When this is done. you can try to reprocess the IDocs: o Automatic reprocessing RBDMANI2: You can use the report RBDMANI2 to resubmit the IDoc. The program can also be scheduled as a periodic job. It may be possible. · Debug the application. 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). o Manually edit IDoc: Check if you can manually correct the IDoc. 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. 29. 37: IDOC processing towards tRFC layer has problems IDOC processing towards tRFC layer has problems. an “application log pushbutton” becomes available in the status record display. to get some information using transaction SLG1 you can specify <*IDOC NUMBER*> in field “External ID”.4. This does not relieve you of monitoring the IDocs to make sure that no other errors are present. Keep in mind that some IDocs must not be changed according to local laws. you can © 2007 SAP AG 31 · . If this is the case.
Best Practice: ALE Monitoring reprocess the IDoc. You will find more information below on reprocessing IDocs in status 51. 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. · 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 reprocessing using report RBDAGAI2 2.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.4.4. only if “Cancel Processing After Syntax Error” is flagged in partner profile (transaction WE20).7 Status 60: Error during syntax check of IDoc (inbound) Processing is discontinued.4. 32 2.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 reprocessing using RBDAGAI2 © 2007 SAP AG 32 . 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 reprocessing using RBDSYNEI 2.
Best Practice: ALE Monitoring 33 2. IDoc display shows you the payload of the IDoc. Process starts the processing of the selected IDoc(s). you can see the window below. you restart the processing of the IDoc(s). If you rightclick. you can choose a particular IDoc to try to reprocess it. This choice gives you more options to process the IDoc. Figure 24 BD87 Manual IDoc processing You can further restrict the IDocs you wish to process in this screen. © 2007 SAP AG 33 .4. If you choose. as shown in the figure below. If you choose process. Delete flag sets the IDoc status to 68.9 Reposting of IDocs in Status Error Figure 23 Transaction BD87 In the status monitor (BD87). If Bkgd processing is unchecked. you have to make a few more choices. meaning that the IDoc has an error and does not need to be processed again. Use the execute button at the top to begin processing. ALE/EDI Interface Management. you can choose between Process or Restrict and process. but can be archived or deleted. Restrict and process.
To display the errors in the IDoc. you will see the current information on the IDoc. click the Segments with errors button. Check if the error can be resolved by changes in the businessrelated objects so that the IDoc can be reprocessed correctly.Best Practice: ALE Monitoring 34 Figure 25 BD87 Display Status Records If you click IDoc display. Figure 26 BD87 – Display Status Records Figure 27 BD87 – Display Data Records Analyze the error situation. The next figure shows you a sample error. 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 . If this is not possible.
This copy has either status 33 (sender) or 70 (receiver). When you reprocess an IDoc. This denotes the fact that the document had an error. we can set the deletion flag and send a new IDoc. you can reprocess the IDoc again. Once the changes have been made. Please keep in mind that this is an either or activity. In addition to this. The status for this is 68. Then. the following things happen in the system: A copy is created of the org. you mark the IDoc for archiving or deletion. © 2007 SAP AG 35 . was deleted and does not need any further processing. we would like to explain a little about what happens in SAP ERP. Then you switch to change mode by clicking Data record > Display > Change. you can’t do both! The appropriate agent also probably needs to decide what steps need to be taken. It is defined in a central system; therefore. data that must not be changed according to the local countries law. The other option is to modify the IDoc: Figure 29 BD87 – Status change after deletion If the IDoc does not contain legally binding data; that is. You can edit the IDoc content manually by clicking on the ‘notepad’ icon in front of the segment. A status record is also created with 32 (sender) or 69 (receiver) and its long text contains the IDoc number of the IDoc copy. If the IDoc is of type Master data. the IDoc should be reprocessed and should not be deleted. IDoc. In this case. you have the option to change the data so that it will be processed the next time.Best Practice: ALE Monitoring • Manually process the IDoc by entering the corrected IDoc data directly into the appropriate SAP application transaction. After the IDoc is corrected. it may not be so easy to resend the IDoc. To give you a little more understanding on the procedure. mark the IDoc for deletion. However. it is quite easy to resend a new master data IDoc. 35 Figure 28 BD87 – Delete Flag By clicking the Delete flag button. it is recommended to correct the errors first (that is. if the IDoc contains transactional data. the copy can not be processed! The original copy gets status 32 (sender) or 69 (receiver). (This is done for documentation purposes). customizing error or missing data).
Backlog situations for IDocs in nonerroneous statuses can also indicate severe error situations in the ALE processing. Call transaction WE02/WE05. which utilize this function module. This gives the corresponding organizational units the time necessary to adapt their operations to the upcoming increase or decrease of unfilled work items. analyze why tRFC has not been processed. Investigate reason for IDoc being stuck in the tRFC queue.Best Practice: ALE Monitoring 36 3 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. Choose various selection criteria and execute. Double click on status Respon sibility Business Process Operations Team / SAP Technology Operations Team Escalation Procedure Application Management Team / Business Process Champion IDoc display BD87 As required by business Slow processing Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion © 2007 SAP AG 36 . look at number of entries in table. in case the data volume processed exceeds or falls below defined threshold values. as well as an indicator for interacting applications. This might serve as an indicator of delays in business critical data flows.1 Manual Backlog Monitoring Monitoring Objects w/o SAP Solution Manager Monitoring Monitor Monit Indicator Object TA/Tool Freq. or Error tRFC Queue SM58 As required by business Slow processing Monitoring Activity or Error Handling Procedure Call transaction SM58 and specify timeframe. Status text “Transaction recorded’ indicates lack of resources in the target system Ensure that background job RBDMOIND is scheduled and running successfully In cases were IDocs are configured to be sent/posted immediately. 3. Specifically look out for function module IDOC_INBOUND ASYNCHRONOUS which is used to transfer the IDoc to the target system. Choose execute. If you see many entries in the tRFC queue.
(This strategy can also work with outbound jobs such as RSEOUT00. with the report RBDAPP01. you can check the processing time from the job duration using transaction SM37. From the number of posted IDocs and the job duration. 37 See section 3. the Job log will show how many IDocs where posted.2. On tab “Technical info” compare timestamps for various statuses. In case Parallel processing is in use SAP Note 547253 must be implemented. RSNAST00 and RBDMIDOC but outbound processing is normally quite fast). When IDocs are posted by a background job i.e. you can figure out the throughput. Specify the selection criteria and execute.Best Practice: ALE Monitoring records of IDoc for technical information. use techniques detailed in Section 7 of this document to investigate reason for slow processing. use techniques detailed in Background jobs SM37 As required by business Slow processing Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion section 7 of this document to investigate reason for slow processing.1 below for example. If processing is found to be slow. If processing is found to be slow. © 2007 SAP AG 37 .
2 Examples of Backlog Analysis techniques 3.e.2. IDOC_INBOUND_ASYNCHRONOUS. Subtracting the difference between the timestamps gives the processing duration. The status 50 shows that the IDoc has been added to the application and status 53 is when the IDoc has been posted. Fig 31 Single IDoc time stamp analysis © 2007 SAP AG 38 .Best Practice: ALE Monitoring 38 3. Use transaction WE02/WE05 to select an IDoc and display its status records as below.1 Single IDoc time stamp analysis In cases were IDocs are configured to be sent/posted immediately. 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.
Error Activity or Error Handling Procedure IDocs in SAP CCMS Hourly Number of Analyze the status “IDoc / SAP IDocs in this reasons in generated” Solution status BD87 outbound Manager (statuses 01. If the IDocs are processed by background jobs. if their processing doesn’t start in time. Therefore.com/~sapidb/011000358700006137532006E Automated Monitoring Objects with SAP Solution Manager: Monitoring Monitor Monit Indicator or Monitoring Object TA/Tool Freq. background job monitoring can be a better option for monitoring upcoming backlogs. 42) [Refer to section “Specific ALE/EDI Monitoring”] IDocs in SAP CCMS Hourly Number of Analyze the status “IDoc / SAP IDocs in this reasons in generated” Solution status BD87 inbound Manager (statuses 50. For details on Business Process Monitoring within SAP Solution Manager refer to the setup guides at “ http://service. 69. 61. Therefore. the length of time that the IDoc has been in a certain status needs be considered. 32. 66.Best Practice: ALE Monitoring 39 3.com/~sapidb/011000358700006137522006E http://service. A large number of IDocs does not necessarily indicate a backlog situation in the IDoc processing. 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. 30 and 64. 64. are 03. For details refer to section Specific ALE/EDI Monitoring.3 Automated Backlog Monitoring Depending on your ALE customizing and the IDoc processing.sap. different IDoc statuses can be considered responsible for backlog situations.com/bpm > Media Library > Technical Information“ or follow those links: http://service.sap. their cancellation or long runtimes can be the reason for backlog situations in the IDoc processing. 25.sap. 70) [Refer to section “Specific ALE/EDI Monitoring”] IDocs in SAP CCMS Hourly Number of Analyze the status “Ready / SAP IDocs in this reasons in for dispatch” Solution status BD87 outbound Manager (status 30) [Refer to section “Specific ALE/EDI Monitoring”] Respon sibility Escalation Procedure Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion © 2007 SAP AG 39 . The most common statuses therefore. 58.
Start SM37 delay. Analyze the Maximum reason in duration. Out of time window. Parallel Processing SAP Technology Operations Team SAP Technology Operations Team / Application Management Team © 2007 SAP AG 40 .Best Practice: ALE Monitoring 40 Background jobs for IDoc processing listed above SAP Solution Manager As needed Cancellations. Job Logs.
The first step is to understand that we actually need to look at least two systems. Performance monitoring enables you to monitor for the interface performance and compare it with predefined key performance indicators. the first step is defining KPIs (Key performance indicators) for the ALE/EDI interfaces. Optimization steps may need to be done in two systems.Best Practice: ALE Monitoring 41 4 Aspect: Performance Monitoring This section will give you some suggestions on how to monitor your systems’ performance for ALE/EDI. number of messages. hardware. Reactive performance monitoring allows for the documentation of the service level delivered. There is also a SAP course called “ADM315 Workload Analysis” which covers this and many more performance monitoring topics in greater detail. Another method is to analyze your business process. Therefore.1. For example. activities running on the distributed systems. All parties in the process need to adhere to these KPIs and the actions to be taken if these limits are exceeded. which. depending on the landscape and solution.1 Manual Performance Monitoring Monitoring Objects w/o SAP Solution Manager Monitoring Monitor Monit Indicator Object TA/Tool Freq. Look at task type ALE and RFC for an overview of performance of ALE/EDI to see where time is being spent. or Error Monitoring Activity or Error Handling Procedure Respon sibility Escalation Procedure Performance of the ALE processing – General Overview ST03N >> Workloa d Overvie w As required by business High processing times Call transaction ST03n > switch to Service Engineer mode and choose Workload Overview. in turn. Monitoring Requirements: The first step in measuring Performance is to have a baseline to measure against. One way to find these KPIs is to use your QA system (or the future productive system) and measure it. 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.1 of this SAP Technology Operations Team SAP Technology Operations Team © 2007 SAP AG 41 . By doing so. and so on). See section 4. you define what minimum performance you require.1. if you need to send 3600 IDocs per hour (each containing the business data for one sales order). 4. These numbers might be useful in defining the KPIs. can avoid backlog situations for performance critical interfaces. so you need to be able to process one IDoc per second. Proactively applied performance monitoring notifies you in situations of reduced interface throughput. The performance of ALE depends on many factors (type of business process. There are different ways of using IDocs there is really no simple way to define what is a good performance or bad performance. This depends on a number of factors and is based on your business needs.
1. Review section 7 of this document on how to further investigate any observed bottlenecks. aRFC_DEST_E XECUTE. See Sections 4.1.3 below for details. Function Modules.1.1.Best Practice: ALE Monitoring document for details.e. Review section 7 of this document on how to further investigate any observed bottlenecks. STAD As High Business SAP 42 © 2007 SAP AG . aRFC_DEST_C ONFIRM. IDOC_INBOUN D_ASYNCHRO NOUS.1. aRFC_DEST_S HIP. INBOUND_IDO C_PROCESS. EDI_DATA_INC OMING. IDOC_START_I NBOUND. See section 4.2 and 4. Business Process Operations Team / SAP Technology Operations Team SAP Technology Operations Team RFC.1. Reports/Jobs ST03n >> Applicat ion Statistic s As required by business High processing times Business Process Operations Analyze the Team / performance of r SAP ALE/EDI Technology relevant Operations transactions/rep Team orts to determine where time is being spent. Call transaction SAP Technology Operations Team RFC.4 of this document for details. RFCs/ALE Function modules ST03N >> RFC PROFIL ES As required by business High processing times 42 Analyze the performance of the various RFC function modules related to IDoc processing i.
Function Modules. Call transaction ST12 and specify various selection criteria.Best Practice: ALE Monitoring Function Modules. On the next screen you see a list of all the statistical records for the chosen timeframe. Double click for detailed analysis. Use statistics to analyze any performance bottlenecks for relevant background jobs as listed in section Business Process Operations Team / SAP Technology Operations Team Application Management Team / Business Process Champion IDoc batch job monitoring. For further information on how to use ST12 see 43 Process Technology Operations Operations Team / Team SAP Technology Operations Team RFC. Reports/Jobs ST12 As required by business High processing times Business Application Process Management Operations Team Team / SAP Technology Operations Team Background Jobs ST03n As required by business Slow processing section 7 of this document. Reports/Jobs required by business processing times STAD. Choose a time frame for the analysis and the ALE/EDI user. Select a record which utilizes ALE/RFC and is showing bad performance. Call transaction ST03N. Further information is © 2007 SAP AG 43 . Sort by “Task Type” Background. Switch to “Expert Mode” and choose server and from lower window choose Transaction Profile > Standard.
Best Practice: ALE Monitoring available below 44 in section 7.1 Overview of Available Tools for ALE/EDI Performance Analysis 4. month. Figur e 41 – Wor kload over view with ST03N For a more detailed analysis of ALE/EDI performance use the RFC profiles. day. week. Look at task type ALE for an overview of performance.1 ST03N – Workload Overview Once the RFC and ALE/IDOC application statistics have been activated they can be used to analyze ALE/EDI performance.e. For a general overview of how a specific server is performing choose the relevant server that you want to analyze. select a specific server of interest/or select all servers (Total – as below) and choose a time period i. and then go to ‘Analysis Views’ >> Workload Overview.1.1.1. Also see section Backlog monitoring. 4. time period. © 2007 SAP AG 44 .
”) as illustrated below allows analysis of ALE/EDI communication when this particular server acted as the RFC client. 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.g. user who called function module.1.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. Double click for further details Figur e 43 – RFC Client Pr ofile © 2007 SAP AG 45 . Detailed analysis (i.Best Practice: ALE Monitoring 45 Choose particul profile i Client o Server Figur e 42– RFC pr ofiles – list of called function modules 4. Choosing the tab ‘Function Module’ displays a list of the called RFC function modules for the selected server/servers over the selected time period. RFC server is overloaded or insufficient number of registrations by the RFC Server programs Data transfer takes too long e. RFC trace) should be performed on the function modules where as a ruleof thumb the following is true: call time – execution time > 20% (i. Possible reasons for long connection times include: · · Establishment of the connection takes long e.e. >20% processing time is spent on establishing a connection). bytes sent.e.1. 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.2 ST03n RFC Client Profile Using the RFC Client profile (choose: Analysis views > RFC profiles > Choose RFC profile: “RFC Client Profile. bytes received see figure below. target RFC destination.
IDOC_START_INBOUND © 2007 SAP AG 46 .g. remote RFC destination.).”) as illustrated below allows analysis of ALE/EDI communication when this particular server acted as the RFC server. aRFC_DEST_CONFIRM. Similar to above double clicking on the transaction provides further information. 4. INBOUND_IDOC_PROCESS. executed frequently and long running function modules. aRFC_DEST_SHIP. Double c for furth details Figur e 44 –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.e. As this is the RFC server you should be looking out for high load function modules i. 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. 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. 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. (Maybe IDoc collection can be implemented so that function modules are not called so often. bytes sent. IDOC_INBOUND_ASYNCHRONOUS.Best Practice: ALE Monitoring 46 Choosing tab ‘Transaction’ allows you to view a list of all RFC spawning transactions. user who called function module. EDI_DATA_INCOMING.1. Choosing the tab ‘Function Module’ displays a list of the called function modules for the selected server/servers over the selected time period.1.3 ST03n RFC Server Profile Using the RFC Server profile (Analysis views > RFC profiles > Choose RFC profile: “RFC Server Profile. bytes received (see figure below). 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 ‘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.
4 ST03n – ALE/IDOC Application Statistics To see the ALE/IDOC application statistics. Then you see following figure Figure 45 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 46 ST03n displaying Application statistics (additional details) With the information above you can detect if there are performance problems database.1. When you choose the sever another window will appear in the lower right hand side and then you choose the application statistics.1. you need to go to the appropriate application server.Best Practice: ALE Monitoring 47 4. 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 . ABAP. © 2007 SAP AG 47 .
a) For SAP 4.1. only the five calls with the longest execution time are therefore logged.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. or users cause in which local or remote RFC destinations? · For transaction steps with RFC. you can use the application statistics to analyze the resources used by an individual function within a dialog step (such as price determination). you can analyze the workload caused by Function Modules relating to ALE/EDI by displaying the RFC profiles. © 2007 SAP AG 48 .1. The RFC client and RFC server records contain data such as execution time and called function for individual RFCs. which is sufficient for performance analyses. NW2004. Using special calls within the ABAP coding. RFC client destination. RFC server.2. you can answer the following questions: · Which transaction. you need to go into the collector branch > workload collector > Collector and reorg. The steps to reactivate the monitoring are different for 4.Best Practice: ALE Monitoring 48 4. function modules. the kernel writes subrecords with additional information about the processing time. The parameter stat/rfcrec (default: stat/rfcrec = 5) specifies the maximum number of subrecords of each type (RFC client. In addition to RFC profiles it is also possible to activate ALE/IDOC application statistics. which function module. While the workload statistics always analyze a complete dialog step. In the workload monitor ST03N. The following two sections describe how to enable the monitoring and how to use the tool to monitor ALE/EDI. the system collects statistics for individual parts of an application.x: In ST03N. as it is possible to turn them off in the system. The application statistics allow you to analyze resource consumption in detail from an application viewpoint. and RFC server destination) that the kernel writes. the destination. Here we will describe the different methods of activation. A larger value for stat/rfcrec can lead to performance problems in the collector. 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. The RFC destination records contain the total of all RFC calls per destination and therefore no additional information about the called function modules. NW2004s versions of SAP.1 Activating the Statistical Collectors – RFC It is possible that no RFCstatistics are stored. For each system version you need to enter transaction ST03N >> Expert Mode. and the function module used.x. and which user caused what workload through RFC calls as an RFC client or an RFC server? What workload do the transactions. If more RFCs are performed during a transaction step. 4.
At least the "Cumulate RFC profiles"entry under "Statistical data to be cumulate & Controls for the collector" has to active. Then save the choices. © 2007 SAP AG 49 .Best Practice: ALE Monitoring 49 Figur e 47 – activation of RFC Statistics with ST03N Push button: Modify parameters. In addition it is highlighted above how you can modify the residence times for statistical data. Figur e 48 – activation of RFC Statistics with ST03N In this screen SAP suggests that you activate all the check boxes and options.
© 2007 SAP AG 50 . so please make sure that you have enough disk space available for these logs. Make sure to note which parameters you modified in the system. In this screen you can choose how much data is stored on the local file system. Choose Performance Database > Reorganization here you can modify all the settings relating to the retention times of performance data. Be aware that there is no exact information on how large the files can get. As everything you have set manually will be erased by the defaults. Figur e 410 – ST03n Retention time for per for mance data Next choose Workload Collector >> Control Data. This option will set the parameters to values which are suggested by SAP.Best Practice: ALE Monitoring 50 b) For SAP NW2004: Call transaction ST03N >> then Collector and Performance DB Figur e 49 – Activation of RFC Statistics with ST03N In all the mentioned sub screens you have the choice to use the SAP Defaults button.
here you can choose what data is stored in the system. Figur e 412 ST03N – Selection of data to cumulate © 2007 SAP AG 51 . but the RFC statistics is the minimum which should be activated.Best Practice: ALE Monitoring 51 Figur e 411 – ST03n Retention of statistic files Next choose Workload Collector Database>> Statistics to Be Created. SAP suggests activating all the checks.
As everything you have set manually will be erased by the defaults. Make sure to note which parameters you modified in the system. Figur e 414 – 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. Choose Performance Database > Reorganization here you can modify all the settings relating to the retention times of performance data. © 2007 SAP AG 52 . This option will set the parameters to values which are suggested by SAP.Best Practice: ALE Monitoring 52 c) For SAP NW2004s: Call transaction ST03N >> then Collector and Performance DB Figur e 413 – Activation of RFC Statistics with ST03N In all the mentioned sub screens you have the choice to use the SAP Defaults button.
Best Practice: ALE Monitoring 53 Figur e 415 – 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. © 2007 SAP AG 53 . Figur e 417 – 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. Figur e 416 – 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. (This is the same procedure for all versions of SAP).
2 Activating the Statistical Collectors – ALE/IDOC Application Statistics The steps to activate collection of the Application Statistics are described in this section. When these particular calls are made their statistics are summed up and recorded in ST03n. 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. © 2007 SAP AG 54 . INBOUND_IDOC* and EDI_DATA_INCOMING. This activates the monitoring for the ALE/EDI RFC functions: IDOC_INBOUND*.Best Practice: ALE Monitoring 54 Figur e 418 – Configur ing the number of RFC subr ecor ds 4.1.2. Figure 419 Then the window below is opened where you can select ALE/IDoc statistics and save the setting.
What happens. Figure 421 – Transaction AL11 (Checking if application statistics are generated) If the application statistics collection works properly. © 2007 SAP AG 55 . If there is no traffic then the file remains small. Goto AL11 . 0=not active). It will grow according to how much data is processed. The application statistics are written into the file called astat. If there is ALE activity you can see if application statistics are being measured by checking the file called astat. In addition the Job RSSTAT87 is activated. is that the Kernel writes the statistics into a file called STAT.Best Practice: ALE Monitoring 55 Figure 420 – 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. From which the ST03N can display the data. you will notice that the file called astat will grow. choose the directory data as illustrated below. and it writes the application statistics in the table MONI.
module or program involved in the IDoc processing. end delay.Best Practice: ALE Monitoring 56 4. use the “Dialog Performance Monitor” in the SAP Business Process Monitoring functionality. For details on Business Process Monitoring within SAP Solution Manager. you can monitor background jobs for their runtime. Operations Operations STAD. where you can monitor for the average response times for specified function modules and/or programs.2 Automated Performance Monitoring Using the SAP Solution Manager and its Business Process Monitoring functionality. out of time window etc. refer to the setup guides at “http://service. Team Team / ST12 Application Management Team SAP Technology Operations Team © 2007 SAP AG 56 . reason in processing Manager Start Delay SM37 Respon sibility Escalation Procedure Total Response time of specific function modules and/or programs SAP Solution Manager 15 minutes High total response time SAP Technology Operations Team / Application Management Team Analyze the SAP SAP reason in Technology Technology ST03N.sap.com/~sapidb/011000358700006137522006E http://service. If you need to monitor the total response time of a specific function. Error Activity or Error Handling Procedure Background jobs SAP As Maximum Analyze the for IDoc Solution needed duration.com/bpm > Media Library > Technical Information“ or follow those links: http://service.com/~sapidb/011000358700006137532006E Automated Monitoring Objects with SAP Solution Manager Monitoring Monitor Monit Indicator or Monitoring Object TA/Tool Freq.sap.sap. start delay.
This chapter will show you how a resource monitoring for interface monitoring with ALE/IDoc scenarios could be done.Best Practice: ALE Monitoring 57 5 Aspect: Resource Monitoring Resource monitoring includes the monitoring of the availability of involved components. 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 the following resources are monitored for availability to ensure optimal interface performance Monitoring Objects: · Work processes · Queues · CPU · Memory · Buffers · Database Figure 51 Resource overview in ALE processing © 2007 SAP AG 57 . as well as their resource consumption. it is important that sufficient resources are available.
peak hours and in case of performan ce problems Hourly in case of performan ce problems or error SAP Technology Operations Team SAP Technology Operations Team SM58 Work processes in target system Status Text Check the target system SAP shows with SM66 Technology ‘Transaction Operations recorded’ Team indicates lack of resources in the SAP Technology Operations Team © 2007 SAP AG 58 . Indicator or Error Monitoring Activity or Error Handling Procedure Responsibility Escalation Procedure SARFC Hourly aRFC resource during monitoring peak hours and in case of performan ce problems or error messages Number of aRFC resources currently available for asynchronous RFC calls Monitor current state of individual work processes. WP during utilization peak hours and in case of performan ce problems or error messages Monitor current state of individual work processes.1 Manual Resource Monitoring Monitoring Objects w/o SAP Solution Manager Monitoring Monitor Monitor Object TA/Tool Freq. this can overload the participating application servers.Best Practice: ALE Monitoring 58 5. Resource usage by RFC can be controlled using various profile parameters. Ensure that enough work process capacity is available at peak times. long Similar to SM50 but for during running jobs systemwide statistics. See SAP Note 74141 for tuning hints regarding resource configuration for RFC SAP Technology Operations Team SAP Technology Operations Team Local work SM50 process overview Hourly WP status. It is important that enough work processes are available for both Dialog users and for RFC communication. If an application uses a lot of transactional or asynchronous RFC. SAP Technology Operations Team SAP Technology Operations Team SM66 System wide work process Hourly WP status. Ensure that enough work process capacity is available at peak times.
CONN_EXCEE DED. Indicator or Error Monitoring Activity or Error Handling Procedure 59 Responsibility Escalation Procedure messages target system SMQS Hourly In Work processes case of in sender performan system ce problems or error messages Status of the destination ‘WAITCONN’ indicates lack of rfc resources in sending system assigned to this rfc destination Check the number of work processes configured for this particular destination using transaction SMQS > check the value specified in column “Max. Decide if enough work processes are configured for destination Outbound/i SMQ1/ Hourly In nbound SMQ2 case of Queues performan ce problems or error messages Status of queues. 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. SAP Technology Operations Team SAP Technology Operations Team © 2007 SAP AG 59 .Best Practice: ALE Monitoring Monitoring Monitor Monitor Object TA/Tool Freq.e. No wp_ca block received. if entries in a queue are not processed and queue remains in a certain status for more than 30mins Refer to SAP Note 378903 SAP Technology Operations Team SAP Technology Operations Team SAP Technology Operations Team SAP Technology Operations Team System SMGW During Error messages Review parameter & ST11 periods of in the gateway recommendations as s for a high very high trace or other per SAP Note 384971 interface ALE/RFC developer traces load load and regarding or terminations i. Conn” for the destination. MAX_CPIC_CLI ENTS. ce R3_LOGIN_FAI problems LED. performan SAPRC=672. No free block found in the WP Communication Area.
Hourly In Swaps case of performan ce problems or error messages Monitor memory resource usage for specific R/3 application servers. Incorrectly sized R/3 buffers or memory allocation can result in poor performance. the storage quality of the indexes for these tables might be inadequate. reorganize the table and decrease its size. and that there is sufficient space available. check that the R/3 parameters are set correctly with transaction ST02. In general. as well case of as the response time of performan an individual business ce transaction. To ensure optimal performance. that there are no missing indexes. problems Monitor hardware load during high RFC transmission times especially. SAP Technology Operations Team SAP Technology Operations Team © 2007 SAP AG 60 .Best Practice: ALE Monitoring Monitoring Monitor Monitor Object TA/Tool Freq. especially on tRFC and qRFCtables (ARFCSSTATE ARFCSDATA ARFCRSTATE) Since the tRFC and qRFC tables shrink and expand constantly. See SAP Note 375566. One such example would be when a work process enter PRIV mode. Ensure that the data quality is sufficient. Monitor the growth of tables and indexes. g on the utilization A hardware bottleneck business can have a negative process) impact on the overall and in response time. if table sizes are larger than 500MB. Indicator or Error Monitoring Activity or Error Handling Procedure 60 Responsibility Escalation Procedure Operating system monitor ST06 Hourly High paging rate Monitor the CPU and (dependin and CPU memory consumption. table indexes for tRFC and aRFC i.e. This has a negative SAP Technology Operations Team SAP Technology Operations Team R/3 System buffer monitor ST02 SAP Technology Operations Team SAP Technology Operations Team Database perform ance monitor DB02 Weekly and in case of performan ce problems Table sizes.
Solution performance dialog steps Manager’s per minute System CPU utilization Monitoring Memory usage part DB key figures etc.2 Automated Resource Monitoring Many of the manual monitoring objects for the general system availability. Error Activity or Error Handling Procedure SAP System SAP 15 Resource Analyze the resources: CCMS / minutes shortage system number of free SAP stability and work processes.Best Practice: ALE Monitoring Monitoring Monitor Monitor Object TA/Tool Freq.sap. Completely automated technical resource monitoring can be performed individually.) Respon sibility Escalation Procedure SAP technology operations team SAP Technology Operations Team © 2007 SAP AG 61 . Indicator or Error Monitoring Activity or Error Handling Procedure 61 Responsibility Escalation Procedure impact on the performance 5. within the System Monitoring part of SAP Solution Manager. per system and instance.com/~sapidb/011000358700001872602002E Automated Monitoring Objects with SAP Solution Manager Monitoring Monitor Monit Indicator or Monitoring Object TA/Tool Freq. For further information consult the following guide: http://service. The setup of System Monitoring within SAP Solution Manager is done in transaction DSWP > ‘Operations Setup’ > ‘Solution Monitoring’ > ‘System Monitoring’ > ‘Setup System Monitoring’. performance and stability are available within SAP CCMS and SAP Solution Manager.
DB Table Name Table Description EDIDOC EDIDC EDID4 EDIDS EDI30C EDI40 BDCP BDCPS ARFCSSTATE ARFCSDATA TRFCQOUT ARFCRSTATE TRFCQDATA TRFCQSTATE TRFCQIN SWWWIHEAD EDI intermediate document cluster Control records (IDoc) IDoc Data Records IDoc Status Records Intermediate document cluster (data records) from 3. need to be archived regularly. These tables grow very quickly. Otherwise. like most other SAP objects. and if they are not managed correctly.0C IDoc data records for 4.Best Practice: ALE Monitoring 62 6 Aspect: Data Management Monitoring Requirements: The Interface relevant tables listed below have a direct impact on performance.0 IDoc Change pointer IDoc Change pointer status ARFC Call Status (Sender) ARFC Call Data (Sender) tRFC Queue (outbound) Status of ARFC Calls on Receiver Side qRFC (inbound queue) qRFC Call Conditions (Inbound Queue) tRFC Queue (Inbound Queue) 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. they will use up disk space unnecessarily. Monitoring Objects: A data management strategy should be set up for the following interfacerelevant tables. Setting up an archiving plan early in the implantation phase. © 2007 SAP AG 62 . they can cause interface(s) to execute slowly.
link tables are not required to be archived before they are deleted. Unlike the IDocs tables. ARFCSDATA. and statistics should not be collected. Recommendation: If you find that the tables are large or have poor storage quality. Further information available at: http://help. RSTRFCES: Deletes ARFCSSTATE. performance problems often occur as a result of a large number of blocks allocated for these tables. outdated statistics and poor storage quality. such as ARFCSSTATE. This table can grow quite large. Also. TRFCQOUT. b) RFC related tables For RFC tables. These tables are considered volatile. © 2007 SAP AG 63 . RSARFCER: Deletes tRFC in reference to the status Refer to SAP Note 324545 and 375566 for additional details. you can improve performance by reorganizing these tables. for example. and frequent changes. TRFCQOUT entried.htm Regarding reorganizing IDoc Change pointer tables run the report RBDCPCLR periodically – review the below URL for further information: http://help.com/saphelp_erp2005vp/helpdata/en/dc/6b81ed43d711d1893e 0000e8323c4f/content. Report RSRLDREL can be used to remove obsolete entries from these two tables. ARFCRSTATE. can grow quite large and a data management strategy should also monitor and manage these tables. 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. which contain links to application documents. See SAP Note 752194 for further information. RSARFC01: tRFC Reorganization. ARFCRDATA. TRFCQDATA. See SAP Note 505608 for further information.com/saphelp_erp2005vp/helpdata/en/12/83e03c19758e71e100 00000a114084/content.htm The tables IDOCREL and SRRELROLES. Report RBDSRCLR should be scheduled to keep this table at a manageable size.sap.sap.Best Practice: ALE Monitoring 63 assures you of a well running system. ARFCSDATA. the indexes for these tables should be reorganized on a regular basis. due to the high volume of data. TRFCQSTATE and TRFCQIN. This will reduce the size of the database considerably once the archived objects are removed. Once that is complete. This report deletes the error log of the ARFC in the background. Time stamps for Serialization at IDoc level are stored in table BDSER. Recommendation: Define an archiving strategy for your IDoc tables and implement using transaction SARA.
Best Practice: ALE Monitoring 64 c) Workflow related tables The work item tables can grow quickly (tables included are SWWWIHEAD. See SAPHELP for further information on archiving work items: http://help.sap.e. or Error Monitoring Activity or Error Handling Procedure Table sizes Analyze the and free DB reasons for the space DB growth in transactions DB02 and DB15. SWW*). you will find standard recommendations on the topic data management and specific recommendations for different DB tables including interfacerelated DB tables: http://service. Specifically look out for interface tables listed above. Recommendation: Reorganize the work items. The archiving object is WORKITEM.sap.com/~sapidb/011000358700005044382000E or visit quicklink http://service. In the following bestpractice document. 6.com/saphelp_nw04s/helpdata/en/8d/3e704c462a11d18900000 0e8323d3a/frameset.com/ilm. or Error Activity or sibility Error Handling Procedure DB growth SAP CCMS / Daily Free DB Analyze the SAP (CCMS[transaction SAP Solution space reasons for Technology RZ20] > DB Manager’s the DB Operations © 2007 SAP AG Escalation Procedure SAP Technology Operations 64 .1 Manual Data Volume Monitoring Monitoring Objects without SAP Solution Manager Monitoring Monitor Monit Indicator Object TA/Tool Freq. ALE/EDI can create work items. Respon sibility Escalation Procedure Table Growth DB02.htm For workflow tables i. DB15 Daily SAP Technology Operations Team SAP Technology Operations Team 6. SWWW* schedule relevant house keeping jobs or set up archiving using transaction SARA (SAP Note 49545 explains how to delete unnecessary work items).2 Automated Data Volume Monitoring Automated Monitoring Objects with SAP Solution Manager Monitoring Monitor Monit Indicator Monitoring Respon Object TA/Tool Freq. Even if you are not explicitly using workflow for the IDocs.sap.
statistical records. system resource consumption and middleware queues (among others). consisting of parts of the times listed above that cannot be calculated. 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. background jobs running too long.1 General information As part of the daily monitoring activities of your SAP system. In addition to this measurement of time. Due to © 2007 SAP AG 65 . Please keep in mind that this is general information. This course covers topics like workload monitor. 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. you will find the description of a general procedure for monitoring the performance of your SAP system. Please also consider the training BC315 Workload Analysis. this leaves the processing time which cannot be measured directly. 7. CPU time is returned by the operating system. the timer works with 100 Hz so that the CPU time is reported as a multiple of 10 ms). ABAP programs. but also the performance of your SAP system. memory management. you will find information about common monitoring activities that are not specific to special business process steps. Poor performance of a system is generally equal to extremely high response times. expensive SQL statements. other times. for example. This may be related to long lasting transactions steps (dialog steps). database monitor and buffer analysis among others. are still measured in SAP. you should not only watch system availability. 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). ABAP programming code is processed during the processing time. 7. Rollin 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 Rollin time Enqueue time Important: the CPU time should not be added to the above times as it is a total. and therefore for the underlying database Load/Generating time Time for loading/generating screens.1 Performance Monitoring In this section.1. The different transactions that are mentioned in the procedure are described in detail below. 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. etc.Best Practice: ALE Monitoring administration > Data archiving) System Monitoring growth in transaction DB15. If you subtract these components from the response time. The accuracy of the reported value depends on the timer of the operating system (under UNIX. and CUA elements (not for presentation). There are several transactions available with which you can monitor the average performance of the system and analyze the causes of poor performance. such as waiting times or database times. DB01 Team 65 Team / Application Management Team 7 Generic Part on System Monitoring In this part of the ALE Monitoring Best Practice.
but it important that they are not defined in a too general way (e. Furthermore. This can occur several times during a transaction step. Generally speaking. Code ST03N Use for … General performance overview for the different task types and analysis of system workload Detailed performance monitoring of a short time frame. In this case. it is not recommended that company ABC just monitors the average response time for dialog transactions. it is possible that a slightly longer CPU time is displayed for a dialog step than for the response time. 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). as it only occurs after the data is transferred to the presentation server. Key Performance Indicators are quantifiable measurements. It is also important to use the right granularity for KPIs. thus releasing the work process. a very long Roll wait time occurs here also.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. The user context enters the roll areas and roll wait time is processed until the application is exited. This may be caused by calls of Windows or other external applications from within the R/3 System. a single user or a specific transaction or program SQL trace of a specific step. 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). The application of the RFC is started here. short sequence of steps or part of a long running job Getting an overview of the duration and performance of the source code. which Function Module or SQL statement etc. The Roll wait time is processed on a client. They also occur when the R/3 System communicates with the frontend controls.g. that is. Roll wait is not part of the response time for transaction steps of task type RFC. 7. from individual statements up to complete transactions Get an overview on the time distribution (DB. While the data on the frontend is being processed. the R/3 context is rolled out. The RollOut time is not part of the response time. neither resource is used up nor does a bottleneck occur here for high Roll wait time.1. only after a long time (several minutes). They should. 3 times) and upon performance problems When performance problems occur When performance problems occur with high DB times When performance problems occur with high CPU times STAD Performance ST05 trace ABAP runtime analysis Single Transaction Analysis SE30 ST12 When performance problems occur with high DB or CPU times Key performance indicators Performance monitoring is most useful if you have previously defined key performance indicators. As the call center agents need very good response times for business partner searches in order to answer a call. There is no need to define a KPI for the response time of each and every step in the process. monitor on transaction or even on dialog step level. CPU. but should rather go one or to steps further into single transactions or even steps.Best Practice: ALE Monitoring 66 this rough resolution of the CPU time.) Use when? Daily (e. that reflect the critical success factors of an organization. for transactions or background jobs. Therefore. This is because no resource use occurs for the application server. The Roll wait time is the time a work process is waiting for the response of a RFC. If frontend Office applications such as Microsoft Word are started and closed. This monitor provides an © 2007 SAP AG 66 . whereas the user context is in the roll area. instead. performance monitoring should not only refer generally to a task type. and the queries for large target groups may take several seconds. The transaction step is only exited at this point. Transaction Workload monitor Workload / statistical records Trans. High Roll wait times occur frequently. agreed beforehand. we refer to the system response time for single dialog steps of your core business process(es). less than 2 sec for each dialog step) as this might be too tight or too wide for specific needs. the RFC connection is cancelled. 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.g.
· 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 XXSER TCC.Best Practice: ALE Monitoring 67 overview of the response times and the components (CPU time. you can choose the time period for which you want to display the data; day. payroll number. subapplications. Get an ABAP runtime analysis (transaction SE30) if you find that the performance is related to high CPU or high processing times. The system then displays the result on the right of the screen in a standardized ALV Grid Control. Use the user profile for a comparison among different users and user groups. etc). we can only mention a few here. you can display all task types or only certain ones. you should use this and other transactions for a deeper analysis: · If a single user reports problems. 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). you can display it for a particular instance (not only the one to which you are logged on) or optionally totaled for all instances. Continue the analysis depending on the result.1. The workload monitor has an interface that is divided into two parts. You can quickly determine the source of possible performance problems using the large number of analysis views and the determined data. and client · Workload generated by requests from external systems For all of this data. Selection between the last days. · If you have a general performance problem. with or without the GUI time · Workload and transactions used listed by users. transactions. you can display the totals for all instances and then compare the performances of individual instances over specific periods of time. function modules and destinations · Number and volume of spool requests · Statistics about response time distribution. based on what is important for performance monitoring. Wait time. if you follow a useful naming convention. listed by transactions. 7. the last weeks and the last months is possible. 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. Continue the analysis depending on the result. · Get a performance trace (transaction ST05) if you find that the performance problems are related to high DB times. When analyzing the performance of a system. Therefore. For example. For most analysis views. DB time. · 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 his case. Use the time profile of transaction ST03N to check if performance has been decreasing over time or if there are peaks. packages. The workload monitor is used to analyze statistical data from the SAP kernel. you should normally start by analyzing the workload overview. 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. Depending on your user mode. use transaction STAD to find what part of the response time is particularly high in this case. use the system monitors to check resource consumptions. week and month (or determine the length of time yourself using the Last Minutes’ Load function). Compare it with other users to see if it is an isolated problem.3 Transaction ST03N Transaction ST03N is a very powerful transaction with lots of functions. 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. If you are interested in a particular © 2007 SAP AG 67 . In case of performance problems.
slowly one after the other and write down the exact time at which he executed them. Wait time. 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. you can get a more detailed view. task type. etc). it is not always possible to perform a complete analysis for longrunning transactions.2005. Figure 71 Transaction ST03N 7. time frame from 03. The following screen shot shows transaction ST03N using the options: Expert mode. GUI time.2005 – 09. 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. and start time. Dialog. you find the response times and its components for the different task types (Background. every step on SAP Application Server is recorded. showing dialog transactions sorted by average response time.Best Practice: ALE Monitoring 68 · time within the last 24 hours.4 Transaction STAD In the transaction STAD. selecting for instance the task type dialog and the aggregation per transaction. HTTP. You can now go to Analysis Views à Transaction Profiles à Standard. as the system analyzes complete transactions as far as possible. However. © 2007 SAP AG 68 . The selection criteria include user. Update.01. The analyzed time period can be larger than the interval defined by Read Time. RFC. choose Detailed Analysis. The records for all instances of a SAP system are displayed. If you want to use this transaction to analyze the performance of the steps done by a particular user. you should use as short an interval as possible (around 10 minutes). workload for server us0306_Q4C_02. etc) have been. As the business transaction analysis is time consuming. standard transaction profile. transaction. program. Here. proceed as follows: · Tell the user to execute the steps once.1. than Last Minute’s Load and than the required time frame on the appropriate instance. In the first workload overview. start date. CPU time.01.
you ensure that all buffers (for example. Fields”). © 2007 SAP AG 69 . Check which steps are actually having a bad response time and what part is contributing most to it (DB. This way. 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. including the fields ‘GUI time’. sorted by start time. ‘CUA reference program’ and ‘CUA internal command’. Depending on what you are analyzing. transaction SE30 (for long CPU times) or a network analysis (not described in this document) in case of high GUI times. · · · · You can also use this transaction to see what was going on in the system during specific periods of poor performance in detail. CPU. GUI. for example. 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. With this analysis. The following screen shots show the initial screen of STAD with the options: Show all statistic records. …). program buffers) are filled. Depending on the result. it might be wise to let the user execute all steps twice and use the second execution for the analysis. proceed with a deeper analysis of the worst steps using. Call transaction STAD with the following selection criteria: · · · · · Show all statistic records. 69 Format the output list (button “Sel. 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. transaction ST05 (for long DB times). 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. reading of the records for 10 minutes starting from 16:50 hours. The last two fields can help you to identify the single steps executed. for all users (*) that executed dialog transactions lasting longer than 1000 ms.Best Practice: ALE Monitoring · · 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).
response time. the user. They where adjusted using the “Select output fields” button (F9).Best Practice: ALE Monitoring 70 Figure 72 Transaction STAD Below. For each. you see which program was executed. within which transaction. CUA ref. time in work process. These columns are not all part of the first standard output. GUI time. CPU time. For each time stamp. DB time. on which server. Program and CUA internal command are displayed. © 2007 SAP AG 70 . there are two screen shots showing the result of this query.
or if you are not sure on the assignment. If you can’t find a CUA ref program or a CUA internal command in this list. Use also the information on the distribution of the response time (DB time. If you cannot identify the cause. search for those taking particularly long (for example.Best Practice: ALE Monitoring 71 To make the following steps easier. Depending on the result proceed with a deeper analysis of the worst steps using. CPU time. 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). 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. and so on. However. that the STAD records are only kept in the system for a limited period (normally 24 or 48 hours). also. what is harming the performance of the corresponding transaction or dialog step. In addition. please proceed as described below.1. the program. if the did some unusual steps or if he noticed a bad response time. You may identify which steps belong together by comparing the transaction. The steps should be performed by a key user. you may want to download the list with spreadsheet format. transaction ST05 (for long DB times). for example.sap. · · · Use this information to identify which dialog steps are having extremely high response times during you peak load time. you may use the procedure described for transaction ST05 for a deeper analysis.com/~sapidb/011000358700003081072005E and navigate to section 2. to identify the cause of the problem. 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. Execute the steps slowly one after the other and write down the exact time at which you executed them. © 2007 SAP AG 71 . these commands can be different in your system depending on customizing settings. · For details on the Performance monitoring on Function Code level and the monitoring setup procedures use the following link http://service. particular system usage. ‘CUA reference program’ and ‘CUA internal command’. GUI time) given in the list. more than 10 seconds). Be aware. Contact the responsible user to find out what he was doing at that time. the CUA reference program and the CUA internal command. Fields”). including the fields ‘GUI time’. Please beware that the table beneath only shows typical CUA internal commands for some common steps. Use this information to analyse. transaction SE30 (for long CPU times) or a network analysis (not described in this document) in case of high GUI times. · Execute the typical steps of your core business processes once. user exits. in detail. Make sure you have displayed all the columns you need before downloading.
program buffers) are filled. Depending on what you are analyzing. It allows you to record database access. 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. · RFC Trace: This provides information about Remote Function Calls (RFCs) between instances. The performance trace contains the following tracing options: · SQL Trace: This allows you to monitor the database access of reports and transactions. function modules or classes.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. a detailed description of the performed steps and the related STAD records to the message. and show the hierarchy of program calls. to combine table accesses. · Go trough the trace and search for the statements with a high duration (marked red). This way. such as. 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. which you can display as lists. or need further assistance for the analysis. 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. Attach the trace. Use the extended trace list to display the time stamps for each SQL statement.1. you can identify: · · · · Excessive or unnecessary use of modularization units CPUintensive program functions Userspecific functions that could be replaced with ABAP statements Inefficient or redundant database access. If you identified a transaction or a process step that is taking too long. In case you cannot find the cause of the performance problem. you may use transaction ST05. subroutines. Use the ‘explain’ function to see if the correct index is being used for that statement. also for authorization object S_ADMI_FCD). The aim of the procedure described below is to find the SQL statements that are causing high response times in the SAP system. Write down the displayed time stamps (trace period) to be able to find the same trace in the system later on.6 Transaction SE30 The runtime analysis tool allows you to examine the performance of any ABAP programs. it might be wise to let the user execute all steps twice and use the second execution for the analysis. reports. To use the performance trace. From the results of the runtime analysis. and remote calls of reports and transactions. You can use these results to identify runtimeintensive statements. 7. Make sure the user name is correct.Best Practice: ALE Monitoring 72 7. to find out if one or more SQL statements are causing the performance problem. © 2007 SAP AG 72 . · Enqueue Trace: This allows you to monitor the locking system. contact the next support level or open an SAP message on component SVBO.1. It saves its results in performance data files. locking activities. you make sure that all buffers (for example.
Best Practice: ALE Monitoring
Depending 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 SVBO. 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 runtimeintensive 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 CPUintensive program functions Userspecific 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 addon STA/PI à see note 69455 for details.
© 2007 SAP AG
Best Practice: ALE Monitoring
Note 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). STA/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 Object TA/Tool Freq. R/3 System ST03N workload analysis daily Monit or Time tbd Indicator or Monitoring Activity or Error Error Handling Procedure Average dialog response time < 1000 ms Respon sibility
Review response times in Software comparison to system load and monitoring team performance influencing changes within the system of the analyzed 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. Monitor database statistics. Monitor the buffer cache hit ratio Check for missing indexes; ensure Software monitoring team
Database perform ance
Weekly tbd and in case of performa
Increased database response time /
© 2007 SAP AG
Best Practice: ALE Monitoring
Monitoring Monitor Monitor Object TA/Tool Freq. Analysis nce problems ST06 Hourly tbd (dependi ng on the business process) and in case of performa nce problems Weekly tbd and in case of performa nce problems Monit or Time Indicator or Monitoring Activity or Error Error Handling Procedure Expensive SQL statements High paging rate and CPU utilization that the data quality is sufficient, and that there is sufficient space available. Monitor the CPU and memory consumption. A hardware bottleneck can have a negative impact on the overall response time, as well as the response time of an individual business transaction. Especially monitor hardware load during high RFC transmission times. Software monitoring team Respon sibility
Operating system monitor
R/3 System ST02 buffer monitor
Monitor memory resource usage for Software specific R/3 application servers monitoring team To ensure optimal performance, check that 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 enters PRIV mode. Monitor current state of individual work processes. Ensure that enough work process capacity is available at peak times. Software monitoring team
Local work process overview
hourly tbd during peak hours and in case of performa nce problems or error message s hourly during peak hours tbd
WP status, WP utilization
System wide work process overview Database perform ance monitor
WP status, Similar to SM50 but for system long running wide statistics. jobs Table space sizes, table indexes for tRFC and aRFC
Software monitoring team
Daily and tbd in case of performa nce problems
Ensure that the data quality is Software sufficient, that there are no missing monitoring indexes, and that there is sufficient team space 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 qRFCtables (ARFCSSTATE ARFCSDATA ARFCRSTATE) Check short dumps; analyze Software aborted programs. monitoring Select a period and click on the List team button. Select an error, and then choose Display to see the short dump.
ABAP dump ST22 analysis
daily and tbd in case of an errors
© 2007 SAP AG
monitoring team Update records should be monitored regularly and the appropriate user should be contacted immediately to resolve any outstanding updates. System log SM21 daily and tbd in case of an errors Entries Check for general system program Software errors and table space errors or monitoring transactions that encounter errors. Monit or Time Indicator or Monitoring Activity or Error Error Handling Procedure For SAP developed programs that experience frequent terminations. Together with the user. determine whether the update request can be re started or has to be deleted. investigate SAPNet for a possible resolution and if necessary. Determine the performance of single statistical records Software monitoring team Respon sibility 76 Update tasks SM13 daily and tbd in case of an errors Display Statistical Record Transac In case tbd tion of bad STAD performa nce Status © 2007 SAP AG 76 . Position cursor on a time. Status Check for entries that have status Software ‘ERR’.Best Practice: ALE Monitoring Monitoring Monitor Monitor Object TA/Tool Freq. and then choose Display. open a customer message. team Maintain date/time and select Reread system log. For customer developed programs contact the appropriate member of the development team.
2006. SAP R/3 System Administration. see the book: Thomas Schneider. · · Search for related notes in the SAPNet. Literature · · For detailed information on how to administer an SAP R/3 system. SAP Performance Optimization Guide. see the book: Liane Will.Best Practice: ALE Monitoring 77 8 Further Information Troubleshooting If executing this Best Practice did not produce the desired results. Open an SAP Customer Message describing your problem (please see the respective component in section Error Handling. © 2007 SAP AG 77 . 2003 For information on how to monitor and tune the general system performance. Restartability and Escalation of every step).
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.