ALE Monitoring

Best Practice for Solution Management 
Version Date: 16.05.2007 

Contents 
1  Introduction .............................................................................................................................3  1.1  Applicability, Goals, and Requirements...............................................................................3  1.2  Best Practice Procedure.....................................................................................................5  1.2.1  Motivation for Interface Monitoring .............................................................................5  1.2.2  Preliminary Tasks.......................................................................................................5  1.2.3  Interface Monitoring concept ......................................................................................5  1.2.4  Legend ......................................................................................................................5  1.3  General Overview on ALE/EDI............................................................................................6  1.3.1  ALE (Application Link Enabling) .................................................................................6  1.3.2  EDI (Electronic Data Interchange) ..............................................................................6  1.3.3  IDocs .........................................................................................................................6  1.3.4  Change Pointers: .......................................................................................................7  1.3.5  ALE Processing Modes..............................................................................................7  1.4  Example Business Scenario with ALE...............................................................................15  1.4.1  Interface Monitoring in SAP CCMS and SAP Solution Manager................................15  2  Aspect: Error Monitoring........................................................................................................23  2.1  Manual Error Monitoring ...................................................................................................25  2.2  Automated Error Monitoring..............................................................................................28  2.3  Details on IDoc Batch Job Monitoring ...............................................................................29  2.4  Handling different error statuses ALE/EDI .........................................................................30  2.4.1  Status 02: Error passing data to port.........................................................................30  2.4.2  Status 03:.................................................................................................................30  2.4.3  Status 26: Error during syntax check of IDoc (outbound)...........................................30  2.4.4  Statuses 27, 29, 37: IDOC processing towards tRFC layer has problems .................31  2.4.5  Status 51: Application document not posted .............................................................31  2.4.6  Status 56: IDoc with errors added [anything missing?] ..............................................32  Status 63: Error passing IDoc to application...........................................................................32  2.4.7  Status 60: Error during syntax check of IDoc (inbound).............................................32  2.4.8  Status 65: Error in ALE service.................................................................................32  2.4.9  Reposting of IDocs in Status Error............................................................................33  3  Aspect: Backlog Monitoring ...................................................................................................36  3.1  Manual Backlog Monitoring ..............................................................................................36  3.2  Examples of Backlog Analysis techniques ........................................................................38

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 Introduction
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 ALE­based  interfaces manually as well as automated by using SAP Solution Manager. Both monitoring  approaches aim to detect any irregularities or deviations or to detect error situations at an early stage.  These procedures intend to ensure that the interface processing meets the requirements for stability,  performance and completeness as well as a smooth and reliable flow of the core business processes  so that your business requirements are met. 

Alternative Practices 
You can have SAP experts deliver this Best Practice on­site by ordering a Solution Management  Optimization (SMO) service for SAP Interface Management. This service is exclusively available within  an SAP Support Engagement (that is, SAP MaxAttention, SAP Safeguarding or SAP Premium  Support). 

Staff and Skills Requirements 
To implement this Best Practice, you require the following teams:  Application Management Team  This team provides the information on the business background of the interfaces used and knows the  needed business requirements for the interfaces: · · · Business department Solution support organization (for example the Basis Support or the Application Support) Implementation project team 

Business Process Operations Team  The Business Process Operations team will be responsible for applying the resulting procedures  derived from implementing this best practice. They include the following groups: · Persons designated to perform business process oriented monitoring and ensure that the  process runs smoothly (for example, the Business Process Champion for each business  process)

All parties in your Solution Support Organization and IT department involved in monitoring  focused on the application aspects (Application Support, Development Support, Job  Scheduling Management)  SAP Technology Operations Team · All parties in your Solution Support Organization and IT department involved in monitoring  focused on the system administration side (Program Scheduling Management, Software  Monitoring Team, System Administration Team including the System Administrator)  Business Process Champion · · The Business Process Champion is the person in the business department that is responsible  for the successful execution of the business process. He coordinates all activities necessary  for the business process. Therefore, he is usually responsible for the escalation paths in case  of problems. Often he is a second level in the escalation procedure, if the application  monitoring team needs to escalate an issue.

  Performance Monitoring and Data Management. the connected satellite  systems has to be at least of release 4. 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. © 2007 SAP AG  4  .  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. 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.  In the next step you can follow the setup procedure and implement the monitoring on your systems. We do not recommend setting up a full blown monitoring but recommend  concentrating on selective alert situations that will inform you in exceptional cases.  How to use this Best Practice  This document gives you an overview on interface monitoring tools and procedures for ALE/EDI  monitoring.  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. 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”.  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.  For a better understanding on what should be monitored it is essential to understand the ALE  processing mechanism.  Sections 2 to 6 list monitoring objects both for manual as well as automated monitoring procedure  concentrating on the six major areas: Resource Monitoring. add­ons ST­PI and ST­A/PI has to be installed on the SAP satellite  systems. for example  performance 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.  Timing  The best time to apply this Best Practice is during the planning phase or during the implementation  phase of your SAP solution. Backlog Monitoring. Error Monitoring. To have all described monitoring object available in  SAP Solution Manager.6C.

 backlog situations and performance.2.2 Preliminary Tasks  Before performing this Best Practice. Also detailed error handling and disaster  recovery procedures need to be defined.2. separate communication and escalation paths and procedures have to be defined. This  includes the final communication of open alerts to SAP.  Wherever communication connected with Interface Monitoring happens outside these support  processes. For early detection. A proactive interface monitoring helps to identify and avoid  inconsistencies. With an increased complexity of  system landscapes we face an increased risk of data inconsistency. These processes have to be adjusted so that communication and escalation procedures  contained within these processes are adequate to support the Interface Monitoring concept.  IT Operation relies completely on the fact of 100% data consistency.2. All those interfaces need to be monitored in terms of resource availability.  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. legacy environments and business entities are integrated using different interface  technologies.2 Best Practice Procedure  1.  An Interface Monitoring concept has to be tightly integrated with the support organization. specific data  consistency reports have to be executed on a regular basis. This  includes the integration with the Incident/Problem Management process and the Change Management  process. ensure that you perform the following preliminary tasks or checks  in the system: · · · · Complete all installation and post­installation actions and procedures including customizing Ensure that the initial download has been successfully executed Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations  resulting from customer problem messages Implement all current SAP Support Packages upon availability  1.1 Motivation for Interface Monitoring  Today’s system landscapes are often decentralized and can consist of various interfaces.  See the separate Best Practice for General Business Process Management for further details. © 2007 SAP AG  5  .4 Legend  This symbol indicates you a paragraph from where you can navigate to another section of this  document for more detailed information on a topic. This includes the definition of the roles and responsibilities  involved.3 Interface Monitoring concept  For a successful and efficient Interface Monitoring concept. Different  SAP systems. processing  errors. a process for the execution of the  monitoring concept has to be defined. 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.  1.  1.Best Practice: ALE Monitoring  5  1.2.

3 General Overview on ALE/EDI  1. the data is first packed into an IDoc and then sent to the receiving system. This enables the  recipient to automatically process the document by his business software. such as customer or material master data  • Customizing data used for an overall ALE view  Data can be exchanged between SAP Systems and external (non­SAP) systems. ALE uses the business scenarios and function modules that allow transfer data to or  from an SAP system without developing customer­specific programs. From the SAP viewpoint.  and from the EDI standard into the application data structure of the recipient. which  provides data to be exchanged.3.2 EDI (Electronic Data Interchange)  EDI is a standard format for exchanging business data. which is data from applications  • Master data.  EDI describes the mapping of the application data structure from the sender into the EDI standard.  1.  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  .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.Best Practice: ALE Monitoring  6  1.3.3. With EDI the technical structure of the document is retained.  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). the following data can  be exchanged via ALE:  • Transaction data. Each application has a special set of IDoc types. ALE is linked closely with  Workflow Management within SAP. and then converts it  to the IDoc format supported by SAP for further processing. ANSI X12 is either closely  coordinated with or is being merged with an international standard. where it is  analyzed and properly processed. It describes the document exchange with  business partners on a technical level. The standard is ANSI X12  and it was developed by the Data Interchange Standards Association. IDoc types form the  container for the data to be exchanged. EDIFACT. IDoc data exchange is always an asynchronous process. Instead of calling a program in the destination system  directly (RFC). IDocs can be used to exchange data between two R/3 systems or  between R/3 and an external system (non SAP). The following  functions and interfaces form the basis of communication:  • ALE with all its components such as monitoring.  • Usage of the data container called Intermediate Document (IDoc)  • Transactional RFC (tRFC)  1. The data is not only transferred between the systems; in addition it  can also trigger follow­up actions in the SAP system. archiving.3 IDocs  IDocs are predefined data structures of SAP applications at the interface level.

3.3. In ALE  Customizing. The port type is specified in transaction  WE20 (partner profiles) choose partner and select relevant outbound parameter.  Figure 1­2 Transaction WE20 ­ ALE processing mode © 2007 SAP AG  7  . changes to the  master data objects are flagged for distribution by change pointers ( ® Master Data Distribution).  Change pointers are basically the key fields of the table that contains the changed field.  1. The method of sending is  determined by the port type and depends on the technical configuration of the target system. The master IDoc is then passed to the ALE layer. reads the application data and  creates the master IDoc. the application writes a change document. The tool writes change pointers.5 ALE Processing Modes  There are two basic ways to send IDocs via tRFC (ALE) or via flat file (EDI). The contents of  this are passed to the SMD tool.Best Practice: ALE Monitoring  7  Figure 1­1 Application Link Enabling / IDoc flow  1.  The SMD tool is connected to the change document interface.4 Change Pointers:  If you want to distribute master data changes with the SMD tool (Shared Master Data). If the master data changes are to be  distributed (defined in ALE customizing). which sends it to all  interested systems. It is  configured using transaction WE21 (ports in IDoc processing). customers can specify the fields that need to be distributed.

  Ÿ  Each tRFC is sent exactly once.5.1 ALE ­ tRFC  Most common between R/3 systems is the (asynchronous) transactional RFC interface (standard ALE  scenario)  Ÿ  Integrated business processes across distributed systems within one company  Ÿ  Example: replication of master data between several SAP Systems  Ÿ  Distribution of master data.  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.  Ÿ  If an SAP system receives the data. even if the recipient partner is not active.  1.3.3.  Outbound and Inbound IDocs can either be processed individually (immediate transfer) or as a  collection/package using a background job.  1. the requests are handled as transactions.2 EDI ­ Flat File  Most common between R/3 system and EDI subsystem is the flat file interface  (standard EDI scenario).5.5.5.Best Practice: ALE Monitoring  8  1. a new attempt can be made to transfer the data.1 Outbound IDoc Processing   Transaction WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Outbound  Parameter. This setting is made in the partner profile using transaction  WE20. When the partner is  available again. 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. © 2007 SAP AG  8  .3.3. ANSI X. 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.3. so that there are no accidental double postings of  application data. transactional data.12  1.3 Processing Modes  Processing in the application layer and the ALE layer are completed on both the outbound and  inbound processing sides.  Ÿ  All erroneous attempts to post data are displayed in the tRFC monitor. This  means that all functions called in one tRFC are either processed together or not at all.

 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. There is a performance overhead associated to this  technique as a new connection is opened for each IDoc sent. you must choose a lower value.  Packet Size:  A general recommendation is between 50 and 100.Best Practice: ALE Monitoring  9  Figure 1­3 Transaction WE20 – Partner profile outbound  When the output mode “Tars Immediately” is activated. 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. the  sender also has to wait for an acknowledgement about the success of the processing from the  receiver.  user  contexts.sap. If immediate processing is implemented. IDocs are transferred immediately to the  receiver system as soon as IDocs are created. 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 this case.  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). avoids reading common database  tables from disk several times and so on. © 2007 SAP AG  9  . 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. in addition the same programs.  It is recommended where possible (business requirements may dictate that immediate  processing is required) to use the output mode “ Collect IDocs” .com/ifm ).  For more information visit: http://service. 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. and  database tables are read multiple times. it can lead to runtime  errors (for example Timeouts). However. If too high a number for “max number of IDocs” is selected.

Best Practice: ALE Monitoring  10 Figure 1­4 Report RSEOUT00 © 2007 SAP AG  10  .

 If the input type value is set to ‘0’ the function module is enabled for mass  processing.  Inbound IDocs and IDoc packets are first saved in the database into single IDocs.  Trigger by Background Program   It is important to note that if the receiver system uses 'trigger immediately' option. If mass processing is not  supported.3. This type of package processing is valid for all IDoc  types as there are no special requirements for the inbound function module. It offers additional © 2007 SAP AG  11  . one commit is triggered for all IDocs belonging to a packet.5. and database  tables are read multiple times.Best Practice: ALE Monitoring  11 1. IDocs will be posted one by one.  This type of package processing can be used  depending on the configuration of the Inbound function module used for an IDoc. each IDoc would  be processed in a new dialog process meaning. Single IDocs can be  put into packets and then processed this functionality is provided by report RBDAPP01.3. and database tables are read multiple times.. user contexts. ALE inbound processing splits the  IDoc packets into individual IDocs; this results in an overhead such as. 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). the same programs. This does however reduce the  administrative load on the R/3 System because if packaging was not implemented. the same programs. this has a significant optimization  potential as overhead is reduced significantly.  If you use function modules that can process IDocs in mass.  Figure 1­5 Transaction WE20 – Partner Profile inbound  Trigger Immediately:  Upon receipt inbound IDocs are immediately released for posting. However there is limited  optimization potential here as a commit is triggered for every processed IDoc because the ALE layer  calls the function module several times in the same dialog process. This can be checked  via transaction BD51. In this case.2  Inbound IDoc Processing:   Transaction WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Inbound  Parameter. user  contexts. which allows  you to specify the package size for the RFC call.

  To do this carry out the steps below in ALE Customizing:  1. As a guide. Schedule posting and configure packaging:  Create variants of report RBDAPP01 and schedule as required using transaction SM36. you should use a packet size of between  20 and 100 IDocs. IDocs will not be processed unless  report RBDAPP01 is scheduled. (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. ensure that separate batch jobs for report RBDAPP01 are scheduled with variants that  include all IDocs that are set to immediate processing; not just those that are set to be ‘triggered by a  background program’. This leads to a tighter control on the handling of the incoming IDocs.  It is recommended where possible (business requirements may dictate that immediate  processing is required) to use the inbound processing mode “Trigger by background program”.Best Practice: ALE Monitoring  12 optimization potential apart from the loading of the programs and users contexts and avoids reading  the common database. 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. To  specify a package size use field pack size.  Figure 1­6 Report RBDAPP01  Additionally.) © 2007 SAP AG  12  .

 you can control which servers  can be used for parallel­processed jobs.  By default.  Figure 1­8­2 Transaction RZ12 – RFC Server Group Maintenance  Application servers in a server group can be used in parallel for updating IDocs in the background. by defining RFC groups. © 2007 SAP AG  13  . This could result in resource shortages in the application servers. This means that each packet will be passed to the application in turn.Best Practice: ALE Monitoring  13 Figure 1­7­1 Report RBDAPP01 – Parallel processing  As illustrated above report RBDAPP01 can be configured to facilitate parallel inbound processing. However. a parallel­processed job uses all qualified servers in an SAP System according to  automatic resource­allocation rules.  There might be only one application server in a server group.  Parallel processing can be used to improve performance and spread the load to a specific group of  application servers. all dialog processes in the SAP  system are used in parallel. This means that the packets can be processed in parallel.  The input field server group defines the RFC Server group which will be used by the report in parallel  processing. An RFC group specifies the set of allowed servers for a  particular parallel­processed job. then the IDoc processing can occupy all the dialog  processes on the application server. Only one work process  will be used for this action on the application server. If the indicator is not set then the IDocs will not be processed in  parallel. 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. If  several IDoc packets have been selected. If you do not specify a server group. Server groups are set up using transaction RZ12 below. 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).

 If however.. EDI). 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. MSGGUID or original application document number. using a unique number (for example. 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. and so on. © 2007 SAP AG  14  .).  Figure 1­9­3 Transaction RZ12 – Determination of resources  You can assign the above RFC resource parameters to these RFC server groups to limit the load  generated from RFCs within an SAP system as described in SAP Notes 74141 and 99284  Note:   To implement packaging of IDocs for a flat file (using file port such as.  IDoc number. resources are not  available.  (See figure 1­6­3 below). it must be verified in  advance that the middleware/target system can handle files that include multiple IDocs. 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. 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.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.

 dialog performance. It gives automated alerts including the possibility to notify these via various  communication means like email.  Business Process Monitoring (BPMon) within SAP Solution Manager is the proactive and process­  oriented monitoring of the core business processes of your company. It includes the observation of all  technical and business application­specific functions that are required for a smooth and reliable flow of  the business processes. throughput and backlog KPIs for  various applications. To monitor the IDoc flow from end­to­end the monitoring on the sending and the  receiving system needs to be set up for the IDoc processing – in this example of message type  ‘MATMAS’. update errors. other EU countries and non EU European Countries. 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. Such automated monitoring is optimally implemented using  Business Process Monitoring or System Monitoring in SAP Solution Manager.  1.1 Interface Monitoring in SAP CCMS and SAP Solution  Manager  For some monitoring activities it is possible to use a tool for automated monitoring. Its main business is buying PC components. The sales department is  divided between Great Britain.  composing them to pre­configured PCs and selling them within Europe. 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.  IDoc  message flow Figure 1­10 Business Process: Processing Purchase Orders  In the business process “Processing Purchase Orders” IDocs of message type ‘MATMAS’ (Material  Master) are sent from the SAP ECC sender system to the SAP MM receiver system via an ALE  distribution model.  © 2007 SAP AG  15  . application log and so on). Types of errors that can be monitored are for  example errors from logs (system log. This is also  possible with interface monitoring.  Business Process Monitoring (BPMon) reveals even slight deviations from a pre­defined ideal  business process state which would otherwise remain undetected until the flow of the process would  be seriously impacted. One of their core  business processes is named “Processing Purchase Orders” and is maintained within the SAP  Solution Manager. SMS and so on.Best Practice: ALE Monitoring  15 1.4.4 Example Business Scenario with ALE  For the different aspects of interface monitoring the SAP Solution Manager can be used.

sys ‘name of logical system’.4. This gives you the possibility to individually monitor IDocs which refer to certain business  processes.  The standard CCMS monitors on the satellite system show an ALE/EDI IDoc Monitoring for all  message types in inbound and in outbound direction.Best Practice: ALE Monitoring  16 For further details on Business Process Monitoring refer to http://service.  1.  Wherever monitoring via SAP Solution Manager is possible you will find a separate table.sap.1. 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.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. indicating  the relevant automatic monitoring functionalities. This © 2007 SAP AG  16  . if needed.1.com/bpm.  Figure 1­11 CCMS ALE/EDI Standard Monitoring Groups  1.2 Specific ALE/EDI Monitoring  Besides the standard monitoring objects available in SAP CCMS you can setup a specific ALE  monitoring. 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.4.

 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).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. In  the entry screen it is now possible to select the newly created monitoring object.  System wise.  The customizing of ALE/EDI monitoring objects can be done with transaction BDMO. It is also possible to © 2007 SAP AG  17  . these objects are considered as customizing. If one direction should not be monitored explicitly. This can be done either in inbound or in outbound direction or both.  Figure 1­13 BDMO – New Entry  In some cases it might be necessary to re­call transaction BDMO to have the new entry available.  To create a new monitoring object the button Create/activate monitoring objects in the entry screen of  transaction BDMO must be used.  Figure 1­12 BDMO – Create/Activate Monitoring Objects  In the following screen the new entry needs to be entered and set to active. The following screen  will pop up:  Figure 1­14 BDMO – Customize Monitoring Object  The specific message types for the inbound and/or outbound direction of an interface need to be  specified. Therefore. With transaction  BDMO it is possible to create new monitoring objects only for a specific message type and to activate  them accordingly. it can be left blank. they have to be set up in the  development system and from there transported via the quality assurance system to the productive  system.

 This will create new entries in the CCMS (transaction /NRZ20) and start  the data collection for the ALE/EDI alerts but just once. Therefore it makes sense to evaluate the  IDocs in status 03 if they have not been processed since longer than 60 minutes. Depending on your requirements you  can change the frequency to enable a more real­time alerting. then choose Monitoring Object / Start all in the entrance  screen of transaction BDMO. per default on an hourly basis.  Use cases might be the following:  a.  Monitoring on the number of IDocs.  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.  b. But if this is not the case after 30  minutes they are counted as IDocs in status 51. Those  IDocs are sometimes processed on an hourly basis. which are in status 51 for longer than 30 minutes.  The Monitoring Object is created in a development system and is then regularly transported into  the productive environment. To be able to assign both monitoring objects to the  same interface in the SAP Solution Manager they must have exactly the same names. that is specified in the development system  already has to be the connected productive system which should be monitored later on.  In field Days until now you can specify the age for IDocs in days which won’t be included into the  evaluation. 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. Hence the Partner no. which are in status 03 for longer than 60 minutes. 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. 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.Best Practice: ALE Monitoring  18 specify more than one message type if needed.  This way the program RBDMONI_CCMS_IDOC is scheduled in the background job  SAP_CCMS_MONI_BATCH_DP.  In section Period you can specify the number of days for the age of the IDocs that should be included  into the evaluation. If this time has not elapsed since the last status change.  If the same interface should be monitored on the sending system as well as on the receiving system.  To actually create the monitoring objects.  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  . The system type of the partner system needs to be  maintained as well as the system number from the partner (see transaction WE20). the  previous status is used and not the last one.  Monitoring on the number of IDocs.

 To check the processing mode navigate to transaction WE20. The selection works for the RFC destination specified for the involved partner in the  partner profile.  Ø  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.  © 2007 SAP AG  19  . select the message type and click on details. In the SAP CCMS the main  statuses are grouped together depending on the direction. select the partner  number.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 1­15 ALE/EDI Specific Monitoring Objects  Area 1: IDocs are generated via change pointers. Therefore the number of open change pointers is  relevant for monitoring.  Area 2: An IDoc changes its status during the message processing.

© 2007 SAP AG  20  . all pairs of consecutive business process steps on different  systems. At  least one business process with steps on different systems and defined interfaces must be available  before it is possible to configure interface monitoring. the required interface must be selected for Monitoring.  In node Interface Monitoring all existing interfaces for the corresponding business process and the  selected steps are displayed. Initial Step (usually the business process step that  sends information). To  differentiate between the interfaces.1. such as. Sender  and Receiver (SID respectively) are displayed.Best Practice: ALE Monitoring  20 Figure 1­16 tRFC settings for ALE processing   Per default the threshold values for the SAP CCMS MTEs are usually set too high and need to be  adjusted either directly within SAP CCMS or within the SAP Solution Manager. The Interface Name and the Interface Technique can  be changed manually. ALE/EDI.  1. To customize the interface.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). Interface Name (per default “<Sender SID>><Receiver SID>”. the  Interface Technique (for example. qRFC).4.

  Figure 1­18 Use Value Help for ALE/EDI monitoring objects © 2007 SAP AG  21  .4. It is now necessary to assign the previously  created monitoring objects from the satellite system to the respective interface.  21 Figure 1­17 Setup Interface Monitoring in SAP Solution Manager  This sub­node is either used for loading Monitoring Objects from the connected local CCMS (for  ALE/EDI. Outbound­  objects on Sender side and Inbound­objects on Receiver side) are loaded into the session. This happens with the push­button: Reload CCMS: ALE  Mon Objects. This is not  visible at first.3.1.Best Practice: ALE Monitoring  After saving the entries for every interface that is selected for monitoring a respective sub­node  Interface “<Name of the Interface>“ (<Interface Technique>) will be created. Copy the selected objects  and save. but when the F4 value help is used for either SID or ALE Monitoring Object.  1. This means that the  objects must be loaded into the session. qRFC and tRFC this is described in the following sub­sections) or the sub­node is empty for  all other Interface Techniques.1  Implement ALE/EDI Interface Monitoring  If an interface is selected for monitoring with the Interface Technique ALE or EDI.  then all  reloaded Monitoring Objects appear and can be selected for monitoring. a sub­node appears:  Interface “<Name of the Interface>“(<ALE or EDI>). All ALE/EDI monitoring objects available on the satellite systems (that is.

 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. To  transfer all the threshold values at once.Best Practice: ALE Monitoring  22 A new sub node. select "Copy All". double­click the copy icon between them. To transfer the  threshold values for a single line from right to left. It is also possible to change the threshold  values for the alerts manually. Additionally. relating to the Monitoring Objects selected in the node above.  Figure 1­19 Selection of ALE/EDI related alerts © 2007 SAP AG  22  . the new values are transferred to the local CCMS of the  monitored system. When saved. are  loaded into the session. Alert Monitors. appears. The next step is to decide what kind of alert should be selected for 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. their  identification can be extremely important and time critical. The next sections will deal with individual aspects of interface monitoring. Error  situations can be identified by the occurrence of error messages or error statuses. Monitoring procedures should. All IDocs start with status 01 (IDoc generated) in  Outbound. and the numbers from 01 to 49 are reserved for Outbound status (50­99 are Inbound  status).  ensure a clear visualization and prioritization of incidents to support their fast and effective resolution.Best Practice: ALE Monitoring  23 2 Aspect: Error Monitoring  From the previous sections. As these incidents can endanger the entire data flow between the involved systems. 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  . therefore. The various error statuses which can occur for outbound and inbound IDocs and which  should be monitored on a daily basis. Each step in the  processing of the IDoc has a different status number.  Error monitoring is intended to detect critical situations and exceptional cases during interface  processing.  Error Monitoring includes the monitoring of all error situations documented within the system.

 multiple systems and different interface technology are utilized. Errors can occur at any of the 5 steps. 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  . The figure below shows the various  technologies and the SAP tools we can use to monitor ALE/EDI scenarios in a solution landscape  manually:  Figure 2­1 Standard ALE processing error monitors  Monitoring Objects:  The figure below shows how data is distributed using ALE.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. There  are various tools for monitoring and problem analysis. so  these steps represent our monitoring objects.

 If IDoc is  found in failed status.  For IDocs in status 51  BD87 will state whether  an application log exists  for the IDoc. if so.1 Manual Error Monitoring  As in the above description.  Call transaction  BD87on receiving  system.Best Practice: ALE Monitoring  25 Figure 2­2 ALE layers  2.  57.  Monitoring Objects w/o SAP Solution Manager  Monitoring  Monitor  Monit. 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  .  check if interface is  configured to collect  and. check if  background job is  running. It is  possible to drill down to  display the IDoc and its  status records (by  double clicking). Choose  timeframe and various  selection criteria. 52. A list  of IDocs will be  displayed for various  message types. If  IDoc is not found.  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.  Indicator  Object  TA/Tool  Freq.  Monitoring Activity or  Error Handling  Procedure  Use BD87: enter  correct date/time frame  and logical message  type. Double click on  various statuses to get  a list of IDocs. 54.  review status text for  reason for failure. the following table documents the handling of errors at the five processing  statuses.

 29. choose  timeframe and check  for IDocs in status 03.Best Practice: ALE Monitoring  IDoc. an application  log pushbutton  becomes available in  the status record  display. 63 . choose  timeframe to see a list  of tRFCs with errors.  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. If no button is  available. to  get some information  using transaction  SLG1. A list  of IDocs will be  displayed for various  message types. 26. It may be  possible. If report is  tRFCs in  running check  error status  transaction SM58 as  below. If  there are IDocs in  status 03. 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). 34.  Analyze reason  accordingly. 21. Choose  timeframe and various  selection criteria.  Double­click to get  more details for each  tRFC.  27. ensure report  SM58  RBDMOIND  shows  Is running. 60.  Call transaction  BD87on receiver  system.  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.  Business  Process  Operations  Team /  SAP  Technology  Operations  Team  Application  Management  Team /  Business  Process  Champion © 2007 SAP AG  26  .  IDocs in status  BD87  “Error in ALE  layer ” (sender  system)  As  required  by business  Existence  of the  following  statuses:  02. If you double­click  on the IDoc status  record.  37  Call transaction  BD87on sender  system. however. You can specify  <*IDOC NUMBER*> in  field “External ID”. It is  possible to drill down to  display the IDoc and its  status records (by  double clicking).  In SM58.  65. A list of IDocs  will be displayed for  various message types.

  Double click on  individual work items to  find out why they failed  Call transaction WE07. If  SAP  correspond  IDoc was not  Technology  ing to  processed recently.  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.  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).  36. A list  of workflows will be  displayed in error  status.  Choose timeframe and  various selection  criteria to display a list  of IDocs with errors. there  transaction WE21 ­>  is a  choose file port and  problem. test  Operations  active EDI  access to specified  Team  scenario? If  directory using  not.  In addition check for  errors in BD87.  15.Best Practice: ALE Monitoring  27 Error in  external  system  BD87  As  required  by business  Existence  of following  statuses  04. 07.  08. Choose  timeframe and various  selection criteria. 23. 11.  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  .  Double click to drill  down to display IDoc  and status records.  perform an access test. 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. 05. 17. 09.  Choose timeframe and  various selection  criteria on the sender  system and analyze the  reasons in BD87.

 57)  Inbound  IDocs in  status “Error  in IDoc  Interface”  (statuses: 56. 11.Best Practice: ALE Monitoring  28 2. 08. 21. 15.  20. 34.  54.  60. 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.  17.  27. 29.  05.  Automated Monitoring Objects with SAP Solution Manager  Monitoring  Monitor  Monit  Indicator or  Monitoring  Object  TA/Tool  Freq.  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. 07. refer to the section Interface Monitoring in  SAP CCMS and SAP Solution Manager.2 Automated Error Monitoring  For details on how to setup the automated error monitoring.  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. 36.  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  . 63.  09. 26.  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. 23.

 you can check via partner profile  WE20). investigate using the job log. Job runtime: This depends on many factors (Functionality/activity of the job. Also. If a  background job is deemed to be running long.  · Typical Inbound jobs run programs:  1.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. we cannot give exact statements about performance indicators. hardware.  RBDMIDOC (Change Pointers. system  resources etc). It is also possible  to perform an ABAP or SQL trace using transaction ST12 see  Section 7 of this document.3 Details on IDoc Batch Job Monitoring  Confirm that the below background jobs are scheduled and are running successfully.  RSARFCEX (clears IDocs out of ALE/RFC layer)  6. using transaction  SM37. can check via BD50) © 2007 SAP AG  29  .  RSNAST00 – WE15 (If using message control.  RBDMOIND (changes IDoc from status 03 to 12)  7. Further information about the cause of the failure may be available in the  system log transaction SM21.  RSEOUT00 (sends IDocs – we14)  5.  RBDAPP01 (posts IDocs)  2.  RBDMANI2 (posts status 51 IDocs)  Typical Outbound jobs run programs  3. validate message control is set up properly via NACE. Therefore. Monitoring should include an assessment of: · Occurrence of failed/cancelled jobs: The job logs should be investigated to determine what  caused the error. (Creates IDocs)  4.

 Maybe the  network is down. To do so.  2.  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. or the receiving system does not have any dialog work processes available or there  are other resource issues. the Gateway developer trace needs to be reviewed and/or a RFC trace needs to be  created and analyzed.  If this does not solve the problem.  2.Best Practice: ALE Monitoring  30 2. debug the application program that creates the IDoc.  If necessary.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. 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.1 Status 02: Error passing data to port  Common causes of error: · Access to the file system does not work. use the transaction SM59. but it has not yet  been input in the receiving system. then the connection from this server to the outbound  directory should be checked. but has not yet been transferred to the receiving system.  2.4. 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  .  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). · Directory might not exist · File System full. Processing  discontinued only if  “Cancel Processing After Syntax Error‘ is flagged in WE20 (Partner Profiles).  If the report is running.  Ensure that the user has at least assigned authorization object S_DATASET. If there is a  problem with a specific application server. (See the note 532918 for more details).2 Status 03:  Status 03 signifies that an IDoc in the sending system has been passed to tRFC. You should test the RFC connection. see also SAP notes  334097 and 90111.4 Handling different error statuses ALE/EDI  There are instructions below on issue resolution for the most important error statuses. this means that the tRFC call has not yet been executed.4. because a user has insufficient authorization to  relevant directory to write a file.  Check if the directory exists and there is enough space left in the file system.  Analysis steps/Solution:  Start by checking access to the outbound directory from each application server (WE21).4.

 When this is done.  31 2. however. an “application log pushbutton” becomes  available in the status record display. by setting a breakpoint in the relevant IDoc inbound function module  (WE20) If IDocs are in status 51. 37: IDOC processing towards tRFC layer  has problems  IDOC processing towards tRFC layer has problems.  Common causes of error: · No relevant entry in partner profile · Receiver fields in IDoc header are not filled correctly  Analysis steps/Solution: · Check IDoc error status using transaction WE02/WE05 · Review Partner Profile (WE20) and distribution model (BD64) · Check content of IDoc receiver fields in IDoc header · Debug the application program  2. This does not relieve you of  monitoring the IDocs to make sure that no other errors are present.4.  When you double­click on the IDoc status record. The program can also be scheduled as a periodic job.4 Statuses 27. to get some information using  transaction SLG1 you can specify <*IDOC NUMBER*> in field “External ID”. 29. · Debug the application. to collect IDocs that  could not be posted because of a lock problem. It may be possible.5 Status 51: Application document not posted  IDoc could not be posted. If no button is available it means that a detailed  log is not available. transaction BD87 will state whether an  application log exists for the IDoc. you can © 2007 SAP AG  31  · .Best Practice: ALE Monitoring  Analysis steps/solution: · Check IDoc error status using transaction WE02/WE05 · Review IDoc structure using transaction ‘WE30’ · If necessary.  o  Manually edit IDoc: Check if you can manually correct the IDoc.4. If this is the case. 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  Resending IDoc: Check if the error can be resolved by changing the business­related  objects. you can reprocess the IDoc. you can try to reprocess the IDocs:  o  Automatic re­processing RBDMANI2: You can use the report RBDMANI2 to resubmit  the IDoc. If this is possible.  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. you can drill down to display the IDoc. Keep in mind that  some IDocs must not be changed according to local laws. If the error cannot be  corrected. then a new IDoc has to be created and the “old” IDoc has to marked for  deletion.

4. 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.7 Status 60: Error during syntax check of IDoc (inbound)  Processing is discontinued.4. · IDoc contains characters that are not compatible with internal character set · Error in ALE service  Analysis steps/Solution: · Check status error message in transaction BD87 or WE02/WE05 · Add or change Inbound Partner profile · Create conversion rule · Automatic re­processing using report RBDAGAI2  2.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.  32 2. analyze the structure of the IDoc file and check how the sender system fills  the parameters IDOC_CONTROL_REC_40 and IDOC_DATA_REC_40 of function module  ‘IDOC_INBOUND_ASYNCHRONOUS’ · Automatic re­processing using RBDSYNEI  2.Best Practice: ALE Monitoring  reprocess the IDoc.4.8 Status 65: Error in ALE service  Common causes of error:  Filtering does not work  Analysis steps/Solution: · Check IDoc error status using transaction BD87 or WE02/WE05 · Review ALE customizing using transaction ‘SALE’ · Automatic re­processing using RBDAGAI2 © 2007 SAP AG  32  . only if “Cancel Processing After Syntax Error” is flagged in partner profile  (transaction WE20).

 Use the execute button at the top  to begin processing. This choice  gives you more options to process the IDoc. © 2007 SAP AG  33  .Best Practice: ALE Monitoring  33 2.4. you restart the  processing of the IDoc(s). but can be archived or deleted. If you right­click. If Bkgd processing is unchecked.  as shown in the figure below. you have to make a few more choices. IDoc display shows you the payload of the IDoc. you can see the window below. meaning that the IDoc has an error and does not need to be  processed again.  you can choose between Process or Restrict and process.9 Reposting of IDocs in Status  Error   Figure 2­3 Transaction BD87  In the status monitor (BD87). Process starts the processing of the selected IDoc(s). If you choose process.  Figure 2­4 BD87 ­ Manual IDoc processing  You can further restrict the IDocs you wish to process in this screen. you can choose a particular IDoc to try to reprocess it. Restrict and process.  ALE/EDI Interface Management.  Delete flag sets the IDoc status to 68. If you choose.

  Figure 2­6 BD87 – Display Status Records  Figure 2­7 BD87 – Display Data Records  Analyze the error situation. Check if the error can be resolved by changes in the business­related  objects so that the IDoc can be reprocessed correctly. 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  . To display the errors in the  IDoc. click the Segments with errors button. The next figure shows you a sample error. If this is not possible.Best Practice: ALE Monitoring  34 Figure 2­5 BD87 ­ Display Status Records  If you click IDoc display. you will see the current information on the IDoc.

if  the IDoc contains transactional data. you mark the IDoc for archiving or deletion. In this case. (This is done for  documentation purposes). it is quite easy to resend a new master data IDoc. © 2007 SAP AG  35  .  the copy can not be processed! The original copy gets status 32 (sender) or 69 (receiver). you have the option to change the data so that it will be processed the next  time. To give you a little more understanding on the  procedure. we can set the deletion flag and send a new IDoc.  Then you switch to change mode by clicking Data record ­> Display ­> Change. data that must not be changed according to  the local countries law. the IDoc should be reprocessed and should not be deleted. the following things happen in the system: A copy is created of the org. customizing error or missing data). This copy has either status 33 (sender) or 70 (receiver). The status for this is 68. A status  record is also created with 32 (sender) or 69 (receiver) and its long text contains the IDoc number of  the IDoc copy.  The other option is to modify the IDoc:  Figure 2­9 BD87 – Status change after deletion  If the IDoc does not contain legally binding data; that is. it may not be so easy to resend the IDoc.  35 Figure 2­8 BD87 – Delete Flag  By clicking the Delete flag button. it is  recommended to correct the errors first (that is. After the IDoc is  corrected. IDoc. If the IDoc is of type Master data. you can reprocess the IDoc again. It is  defined in a central system; therefore. you can’t do both!  The appropriate agent also probably needs to decide what steps need to be taken. mark the IDoc for deletion.  Please keep in mind that this is an either or activity. we would like to explain a little about what happens in SAP ERP. When you reprocess an  IDoc.  This denotes the fact that the document had an error. However. was deleted and does not need any further  processing.Best Practice: ALE Monitoring  • Manually process the IDoc by entering the corrected IDoc data directly into the appropriate SAP  application transaction. Once the changes  have been made. Then. You can edit the IDoc content manually by clicking on the ‘notepad’ icon in front of the segment. In addition to this.

  Specifically look out for  function module  IDOC_INBOUND  ASYNCHRONOUS  which is used to  transfer the IDoc to the  target system.1 Manual Backlog Monitoring  Monitoring Objects w/o SAP Solution Manager  Monitoring  Monitor  Monit  Indicator  Object  TA/Tool  Freq. Based on this information. look  at number of entries in  table. 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. This might serve as an indicator of delays in business critical data flows. Choose  various selection  criteria and execute. as  well as an indicator for interacting applications.  Backlog situations for IDocs in non­erroneous statuses can also indicate severe error situations in the  ALE processing. analyze why  tRFC has not been  processed. reporting on the interface  throughput can be set up. Call  transaction  WE02/WE05.  3. or have not  been processed in a defined time window. which  utilize this function  module.  Choose execute. in case the data volume processed exceeds or falls  below defined threshold values. If you  see many entries in the  tRFC queue. 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 Error  tRFC Queue  SM58  As  required  by business  Slow  processing  Monitoring Activity or  Error Handling  Procedure  Call transaction SM58  and specify timeframe.  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  . This gives the corresponding organizational units the time necessary  to adapt their operations to the upcoming increase or decrease of unfilled work items.

Best Practice: ALE Monitoring  records of IDoc for  technical information. with the report  RBDAPP01. In  case Parallel  processing is in use  SAP Note 547253 must  be implemented.  Specify the selection  criteria and execute.  RSNAST00 and  RBDMIDOC but  outbound processing is  normally quite fast). From the  number of posted  IDocs and the job  duration.e. (This  strategy can also work  with outbound jobs  such as RSEOUT00.  © 2007 SAP AG  37  .1  below for example.  37 See section 3.  If processing is found to  be slow. 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. If  processing is found to  be slow. you can figure  out the throughput.2. use  techniques detailed in  Section 7 of this  document to investigate  reason for slow  processing.  the Job log will show  how many IDocs where  posted.  When IDocs are posted  by a background job  i.  On tab “Technical info”  compare timestamps  for various statuses. you can  check the processing  time from the job  duration using  transaction SM37.

2 Examples of Backlog Analysis techniques  3.  Fig 3­1 Single IDoc time stamp analysis © 2007 SAP AG  38  .2. IDOC_INBOUND_ASYNCHRONOUS.1 Single IDoc time stamp analysis  In cases were IDocs are configured to be sent/posted immediately.Best Practice: ALE Monitoring  38 3. 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. Subtracting the difference  between the timestamps gives the processing duration.e. The status 50 shows that the IDoc has been  added to the application and status 53 is when the IDoc has been posted. Use transaction WE02/WE05 to  select an IDoc and display its status records as below.

com/~sapidb/011000358700006137532006E  Automated Monitoring Objects with SAP Solution Manager:  Monitoring  Monitor  Monit  Indicator or  Monitoring  Object  TA/Tool  Freq.sap. For details refer to section Specific ALE/EDI  Monitoring. 30 and 64. if their processing doesn’t start in time.  66.  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. 64. different IDoc statuses can be  considered responsible for backlog situations. Therefore. 61.  For details on Business Process Monitoring within SAP Solution Manager refer to the setup guides at “  http://service. 32.  If the IDocs are processed by background jobs. 69.Best Practice: ALE Monitoring  39 3.com/~sapidb/011000358700006137522006E  ­  http://service. The most  common statuses therefore. 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. 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.  25.com/bpm ­> Media Library ­> Technical Information“ or follow those links:  ­  http://service. background job monitoring can be a better  option for monitoring upcoming backlogs. are 03. 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  .sap.  A large number of IDocs does not necessarily indicate a backlog situation in the IDoc processing.  58.  Therefore. their cancellation or long runtimes can be the reason  for backlog situations in the IDoc processing.sap.3 Automated Backlog Monitoring  Depending on your ALE customizing and the IDoc processing. the length of time that the IDoc has been in a certain status needs be considered.

  Parallel  Processing  SAP  Technology  Operations  Team  SAP  Technology  Operations  Team /  Application  Management  Team © 2007 SAP AG  40  .  Analyze the  Maximum  reason in  duration. Out of  time window.  Job Logs.Best Practice: ALE Monitoring  40 Background  jobs for IDoc  processing  listed above  SAP  Solution  Manager  As  needed  Cancellations. Start  SM37  delay.

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. Proactively applied performance monitoring notifies you in  situations of reduced interface throughput. Look  at task type ALE  and RFC for an  overview of  performance of  ALE/EDI to see  where time is  being spent. which. Reactive performance monitoring allows for the documentation of the service level  delivered. so you need to be able to process one IDoc per second.  4. There are different  ways of using IDocs ­ there is really no simple way to define what is a good performance or bad  performance.  activities running on the distributed systems. For example. One way to find these KPIs is to use your QA ­system (or the future productive system) and  measure it. depending on the  landscape and solution.  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.  All parties in the process need to adhere to these KPIs and the actions to be taken if these limits are  exceeded.1.1. 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.  The performance of ALE depends on many factors (type of business process. By doing so. Therefore. the first step is defining KPIs (Key performance indicators) for the ALE/EDI  interfaces.1 of this  SAP  Technology  Operations  Team  SAP  Technology  Operations  Team © 2007 SAP AG  41  . This depends on a  number of factors and is based on your business needs. Another method is to analyze your  business process.  The first step is to understand that we actually need to look at least two systems. Optimization steps may need to be done in two systems. in turn. you define what minimum performance you require.  See section  4. These numbers might be useful in defining the KPIs. and so on). hardware. There is also a SAP course called  “ADM315 Workload Analysis” which covers this and many more performance monitoring topics in  greater detail.  Performance monitoring enables you to monitor for the interface performance and compare it with  predefined key performance indicators. if you need to send 3600 IDocs per hour (each containing the  business data for one sales order). number of messages.  Monitoring Requirements:  The first step in measuring Performance is to have a baseline to measure against. can avoid backlog situations for performance  critical interfaces.1 Manual Performance Monitoring  Monitoring Objects w/o SAP Solution Manager  Monitoring  Monitor  Monit  Indicator  Object  TA/Tool  Freq.

  STAD  As  High  Business  SAP 42  © 2007 SAP AG  .  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.  Review section  7 of this  document on  how to further  investigate any  observed  bottlenecks.2  and 4.Best Practice: ALE Monitoring  document for  details.e.  See section  4.  aRFC_DEST_C  ONFIRM.  Function  Modules.1. See  Sections 4.3  below for  details.1.  INBOUND_IDO  C_PROCESS.1.  EDI_DATA_INC  OMING.  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.1.  aRFC_DEST_E  XECUTE.  Call transaction  SAP  Technology  Operations  Team  RFC.  Business  Process  Operations  Team /  SAP  Technology  Operations  Team  SAP  Technology  Operations  Team  RFC.  aRFC_DEST_S  HIP.  IDOC_INBOUN  D_ASYNCHRO  NOUS.1.  IDOC_START_I  NBOUND.  Review section  7 of this  document on  how to further  investigate any  observed  bottlenecks.4 of this  document for  details.1.

  Reports/Jobs  required  by business  processing  times  STAD. Choose  a time frame for  the analysis and  the ALE/EDI  user.  Double click for  detailed  analysis.  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. Sort  by “Task Type”  Background.  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.Best Practice: ALE Monitoring  Function  Modules.  Function  Modules.  Select a record  which utilizes  ALE/RFC and is  showing bad  performance. On the  next screen you  see a list of all  the statistical  records for the  chosen  timeframe.  Call transaction  ST12 and  specify various  selection  criteria. For  further  information on  how to use  ST12 see  43 Process  Technology  Operations  Operations  Team /  Team  SAP  Technology  Operations  Team  RFC.  Call transaction  ST03N. Switch  to “Expert  Mode” and  choose server  and from lower  window choose  Transaction  Profile ­>  Standard.  Further  information is  © 2007 SAP AG  43  .

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. © 2007 SAP AG  44  . day.1. and then go to ‘Analysis Views’ >> Workload  Overview.1.1.  Also see  section  Backlog  monitoring. week. month.  4. Look at task type ALE for an overview of performance. select a specific server of  interest/or select all servers (Total – as below) and choose a time period i.1 Overview of Available Tools for ALE/EDI Performance  Analysis  4.Best Practice: ALE Monitoring  available below  44 in section 7. time period.  Figur e 4­1 – Wor kload over view with ST03N  For a more detailed analysis of ALE/EDI performance use the RFC profiles. For a general overview of how a specific server is performing choose the  relevant server that you want to analyze.

2 ST03n ­ RFC Client Profile  Using the RFC Client profile (choose: Analysis views ­> RFC profiles ­> Choose RFC profile: “RFC  Client Profile. RFC trace) should be performed on the function modules where as a rule­of­  thumb the following is true: call time – execution time > 20% (i.e. 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. Choosing the tab ‘Function Module’ displays a list of the called RFC  function modules for the selected server/servers over the selected time period. 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.1. target RFC destination. >20% processing time is spent on  establishing a connection). RFC server is overloaded or insufficient  number of registrations by the RFC Server programs Data transfer takes too long e.  Double click  for further   details Figur e 4­3 – RFC Client Pr ofile  © 2007 SAP AG  45  .g. user  who called function module.Best Practice: ALE Monitoring  45 Choose particul profile i Client o Server   Figur e 4­2– RFC pr ofiles – list of called function modules  4.e.1.”) as illustrated below allows analysis of ALE/EDI communication when this particular  server acted as the RFC client.  Detailed analysis (i. 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. Possible reasons for long connection times include: · · Establishment of the connection takes long e. bytes sent. bytes received see figure below.g.

 aRFC_DEST_SHIP.  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. As this is the RFC server you  should be looking out for high load function modules i. Similar to above  double clicking on the transaction provides further information.  4.Best Practice: ALE Monitoring  46 Choosing tab ‘Transaction’ allows you to view a list of all RFC spawning transactions.  In the RFC Server Profile it is also possible to double click on each function module to access greater  detail about the called function module – information available includes local RFC destination. remote  RFC destination. (Maybe IDoc collection can be  implemented so that function modules are not called so often.  IDOC_INBOUND_ASYNCHRONOUS.1.3 ST03n ­ RFC Server Profile  Using the RFC Server profile (Analysis views ­> RFC profiles ­> Choose RFC profile: “RFC Server  Profile. Choosing the tab ‘Function Module’ displays a list of the called function  modules for the selected server/servers over the selected time period. bytes received (see figure below). IDOC_START_INBOUND  © 2007 SAP AG  46  . executed frequently and long running function  modules.  Double c for furth details Figur e 4­4 –RFC Ser ver  Pr ofile  **The Function modules which you should pay particular attention to when analyzing  performance of ALE/EDI include: aRFC_DEST_EXECUTE.1.  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.). EDI_DATA_INCOMING.e.g. user who called function module. 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. 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. INBOUND_IDOC_PROCESS.  aRFC_DEST_CONFIRM. bytes sent.”) as illustrated below allows analysis of ALE/EDI communication when this particular server  acted as the RFC server.

  When you choose the sever another window will appear in the lower right hand side and then you  choose the application statistics.1. Then you see following figure  Figure 4­5 ST03n displaying Application statistics  Upon double clicking a row further details can be displayed including user who executed the  report/transaction see figure below:  Fig 4­6 ST03n displaying Application statistics (additional details)  With the information above you can detect if there are performance problems database. you need to go to the appropriate application server.1. 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  .4 ST03n – ALE/IDOC Application Statistics  To see the ALE/IDOC application statistics.Best Practice: ALE Monitoring  47 4.

 the kernel writes subrecords with additional information about the  processing time. While the workload statistics always analyze a complete dialog step.1. The following two sections describe how to enable the  monitoring and how to use the tool to monitor ALE/EDI. NW2004.  4.1 Activating the Statistical Collectors – RFC  It is possible that no RFC­statistics are stored. The RFC client and RFC server records contain data such as execution time  and called function for individual RFCs. RFC server.  In addition to RFC profiles it is also possible to activate ALE/IDOC application statistics. Using special calls within the ABAP coding. The RFC destination records contain the total of all RFC calls  per destination and therefore no additional information about the called function modules. which function module.2. function modules.  a)  For SAP 4. Here we  will describe the different methods of activation. The  steps to reactivate the monitoring are different for 4.1. you need to go into the collector branch ­> workload collector ­> Collector and reorg. the system collects statistics for individual parts  of an application. you can answer the following questions: · Which transaction. and which user caused what workload through  RFC calls as an RFC client or an RFC server? What workload do the transactions.2 Activation of Performance Monitoring With Transaction  ST03N  ST03n can be used to investigate ALE/EDI performance issues within the SAP system but you have to  do some configuration to enable this. the destination.  In the workload monitor ST03N. For each system version you need to enter  transaction ST03N >> Expert Mode. NW2004s versions of SAP. 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.x. The parameter stat/rfcrec (default:  stat/rfcrec = 5) specifies the maximum number of subrecords of each type (RFC client. which is sufficient for performance analyses.Best Practice: ALE Monitoring  48 4. and the function module used. A larger value for stat/rfcrec can lead to performance  problems in the collector. only the five calls with the longest execution time are therefore  logged. The  application statistics allow you to analyze resource consumption in detail from an application  viewpoint. or users cause in which local or remote  RFC destinations?  · For transaction steps with RFC. and RFC server destination) that the kernel writes. you can use  the application statistics to analyze the resources used by an individual function within a dialog step  (such as price determination).  RFC client destination. © 2007 SAP AG  48  . as it is possible to turn them off in the system. If more RFCs are  performed during a transaction step. you can analyze the workload caused by Function Modules relating to  ALE/EDI by displaying the RFC profiles.x:   In ST03N.

  Figur e 4­8 – activation of RFC Statistics with ST03N  In this screen SAP suggests that you activate all the check boxes and options. © 2007 SAP AG  49  .Best Practice: ALE Monitoring  49 Figur e 4­7 – activation of RFC Statistics with ST03N  Push button: Modify parameters. At least the "Cumulate  RFC profiles"­entry under "Statistical data to be cumulate & Controls for the collector" has to active. In addition it is highlighted above how you can modify the residence times for  statistical data.  Then save the choices.

Best Practice: ALE Monitoring  50 b)  For SAP NW2004:   Call transaction ST03N >> then Collector and Performance DB  Figur e 4­9 – Activation of RFC Statistics with ST03N  In all the mentioned sub screens you have the choice to use the SAP Defaults button. © 2007 SAP AG  50  .  Figur e 4­10 – 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. In this screen you can choose how much data is  stored on the local file system. Be aware that there is no exact information on how large the files can  get. Make sure to note which parameters you  modified in the system. As everything you have set manually will be erased by the defaults. so please make sure that you have enough disk space available for these logs.  Choose Performance Database ­> Reorganization here you can modify all the settings relating to the  retention times of performance data.

 but the RFC statistics is the minimum  which should be activated.  Figur e 4­12  ST03N – Selection of data to cumulate © 2007 SAP AG  51  . SAP suggests activating all the checks.Best Practice: ALE Monitoring  51 Figur e 4­11 – ST03n Retention of statistic files  Next choose Workload Collector Database>> Statistics to Be Created. here you can choose what data  is stored in the system.

 As everything you have set manually will be erased by the defaults. © 2007 SAP AG  52  .  Figur e 4­14 – ST03n Retention time for per for mance data  Choose Workload Collector Database >> Reorganization ­> Control here you can modify all the  settings relating to the retention times of aggregated performance data.  Choose Performance Database ­> Reorganization here you can modify all the settings relating to the  retention times of performance data.Best Practice: ALE Monitoring  52 c)  For SAP NW2004s:   Call transaction ST03N >> then Collector and Performance DB  Figur e 4­13 – Activation of RFC Statistics with ST03N  In all the mentioned sub screens you have the choice to use the SAP Defaults button. Make sure to note which parameters you  modified in the system. This option will  set the parameters to values which are suggested by SAP.

 (This is the same procedure for all versions of SAP). © 2007 SAP AG  53  .  Figur e 4­17 – ST03N maintenance of collector  par ameters (Total statistics aggregation)  The parameter stat/rfcrec which controls the number of RFC subrecords to be generated is configured  using ST03n (Expert mode) >> Collector and Performance DB >> Statistics Records and File >>  Online Parameters >> Dialog Step Statistics.  Figur e 4­16 – ST03n maintenance of collector  parameter s (Instance statistics aggr egation)  Choose Workload Collector >> Total Collector ­> Control here you activate collection of aggregated  performance data at overall system level.Best Practice: ALE Monitoring  53 Figur e 4­15 – ST03n maintenance of collector  parameter s (retention periods aggregated data)  Choose Workload Collector >> Instance Collector ­> Control here you activate collection of  aggregated performance data at instance level.

 This activates the monitoring for the ALE/EDI RFC functions: IDOC_INBOUND*. © 2007 SAP AG  54  . When these particular calls are made their statistics  are summed up and recorded in ST03n.1. 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.2 Activating the Statistical Collectors – ALE/IDOC Application  Statistics  The steps to activate collection of the Application Statistics are described in this section.2.  INBOUND_IDOC* and EDI_DATA_INCOMING.  Figure 4­19  Then the window below is opened where you can select ALE/IDoc statistics and save the  setting.Best Practice: ALE Monitoring  54 Figur e 4­18 – Configur ing the number  of RFC subr ecor ds  4.

 In addition the Job RSSTAT87 is activated.Best Practice: ALE Monitoring  55 Figure 4­20 – Activation of application statistics  In addition to the above you need to make sure that in the corresponding instance profile the profile  parameter stat/as_level is set to 1(meaning the application tracing is active.  Goto AL11 . If there is no traffic then the file remains  small. From which the ST03N can display the data. It  will grow according to how much data is processed. you will notice that the file called astat will grow. The application  statistics are written into the file called astat.  Figure 4­21 – Transaction AL11 (Checking if application statistics are generated)  If the application statistics collection works properly. © 2007 SAP AG  55  . and it writes  the application statistics in the table MONI. choose the directory data as illustrated below. is that the Kernel writes the statistics into a file called STAT. If there is  ALE activity you can see if application statistics are being measured by checking the file called astat. 0=not active).What happens.

sap.com/bpm ­> Media Library ­> Technical Information“ or follow those links:  ­  http://service. you can monitor  background jobs for their runtime.2 Automated Performance Monitoring  Using the SAP Solution Manager and its Business Process Monitoring functionality. end delay. refer to the setup guides at  “http://service.  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.  Operations  Operations  STAD.com/~sapidb/011000358700006137522006E  ­  http://service.Best Practice: ALE Monitoring  56 4. where you can monitor for the average response times for specified function modules  and/or programs. out of time window etc.  Team  Team /  ST12  Application  Management  Team SAP  Technology  Operations  Team  © 2007 SAP AG  56  .sap. use the “Dialog Performance Monitor” in the SAP Business Process Monitoring  functionality.  Error  Activity or  Error  Handling  Procedure  Background jobs  SAP  As  Maximum  Analyze the  for IDoc  Solution  needed  duration.  For details on Business Process Monitoring within SAP Solution Manager. start delay. module or program involved in the  IDoc processing.com/~sapidb/011000358700006137532006E  Automated Monitoring Objects with SAP Solution Manager  Monitoring  Monitor  Monit  Indicator or  Monitoring  Object  TA/Tool  Freq.  If you need to monitor the total response time of a specific function.sap.

  Monitoring Requirements:  To enable the successful execution of interfaces. In the first subsection you find possibilities on how  to do a manual monitoring and error handling. This chapter will show you how a resource monitoring for interface  monitoring with ALE/IDoc scenarios could be done. as well as  their resource consumption.  It is important that the following resources are monitored for availability to ensure optimal interface  performance  Monitoring Objects: · Work processes · Queues · CPU · Memory · Buffers · Database  Figure 5­1 Resource overview in ALE processing © 2007 SAP AG  57  .Best Practice: ALE Monitoring  57 5 Aspect: Resource Monitoring  Resource monitoring includes the monitoring of the availability of involved components. it is important that sufficient resources are available. The second subsection outlines possibilities for an  automated monitoring.

1 Manual Resource Monitoring  Monitoring Objects w/o SAP Solution Manager  Monitoring  Monitor  Monitor  Object  TA/Tool  Freq. WP  during  utilization  peak  hours and  in case of  performan  ce problems  or error  messages  Monitor current state of  individual work  processes. 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.  Ensure that enough  work process capacity is  available at peak times.  Ensure that enough  work process capacity is  available at peak times.  If an application uses a  lot of transactional or  asynchronous RFC. long  Similar to SM50 but for  during  running jobs  system­wide statistics.  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  .Best Practice: ALE Monitoring  58 5.  Resource usage by RFC  can be controlled using  various profile  parameters. this  can overload the  participating application  servers.  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.  SAP  Technology  Operations  Team  SAP  Technology  Operations  Team  SM66  System­  wide work  process  Hourly  WP status.

e.  No free block  found in the WP  Communication  Area.  performan  SAP­RC=672.  Check the configured  number of resources  dedicated to RFC  against the number of  available work  processes on sender  system by using  transactions SARFC  and SM50.  Decide if enough work  processes are  configured for  destination  Outbound/i  SMQ1/  Hourly In  nbound  SMQ2  case of  Queues  performan  ce problems  or error  messages  Status of  queues.  SAP  Technology  Operations  Team  SAP  Technology  Operations  Team © 2007 SAP AG  59  .  CONN_EXCEE  DED.Best Practice: ALE Monitoring  Monitoring  Monitor  Monitor  Object  TA/Tool  Freq.  MAX_CPIC_CLI  ENTS.  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. 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. No wp_ca  block received.  ce R3_LOGIN_FAI  problems  LED.

  reorganize the table and  decrease its size.e.  g on the  utilization  A hardware bottleneck  business  can have a negative  process)  impact on the overall  and in  response time.  Monitor the growth of  tables and indexes.  Ensure that the data  quality is sufficient. if table sizes  are larger than 500MB.  table indexes for  tRFC and aRFC  i.  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. check that  the R/3 parameters are  set correctly with  transaction ST02.  To ensure optimal  performance. as well  case of  as the response time of  performan  an individual business  ce transaction.  See SAP Note 375566.  In general. and that there  is sufficient space  available.Best Practice: ALE Monitoring  Monitoring  Monitor  Monitor  Object  TA/Tool  Freq.  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. One  such example would be  when a work process  enter PRIV mode. that  there are no missing  indexes.  Hourly In  Swaps  case of  performan  ce problems  or error  messages  Monitor memory  resource usage for  specific R/3 application  servers.  SAP  Technology  Operations  Team  SAP  Technology  Operations  Team © 2007 SAP AG  60  .  problems  Monitor hardware load  during high RFC  transmission times  especially.  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.  especially on tRFC­ and  qRFC­tables  (ARFCSSTATE  ARFCSDATA  ARFCRSTATE) Since  the tRFC and qRFC  tables shrink and  expand constantly.

  For further information consult the following guide:  http://service. within the System Monitoring part of SAP Solution Manager.2 Automated Resource Monitoring  Many of the manual monitoring objects for the general system availability.com/~sapidb/011000358700001872602002E  Automated Monitoring Objects with SAP Solution Manager  Monitoring  Monitor  Monit  Indicator or  Monitoring  Object  TA/Tool  Freq.  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.Best Practice: ALE Monitoring  Monitoring  Monitor  Monitor  Object  TA/Tool  Freq.  Solution  performance  ­ dialog steps  Manager’s  per minute  System  ­ CPU utilization  Monitoring  ­ Memory usage  part  ­ DB key figures  etc.)  Respon­  sibility  Escalation  Procedure  SAP  technology  operations  team  SAP  Technology  Operations  Team © 2007 SAP AG  61  .  Completely automated technical resource monitoring can be performed individually. per system and  instance.  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.sap.  Indicator or  Error  Monitoring Activity or  Error Handling  Procedure  61 Responsibility  Escalation  Procedure  impact on the  performance  5.

 These tables grow  very quickly. Otherwise.  Monitoring Objects:  A data management strategy should be set up for the following interface­relevant tables. like most other SAP objects.0C  IDoc data records for 4. they will use up  disk space unnecessarily. © 2007 SAP AG  62  . need to be archived regularly. they can cause interface(s) to execute slowly. Setting up an archiving plan early in the implantation phase.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.Best Practice: ALE Monitoring  62 6 Aspect: Data Management  Monitoring Requirements:  The Interface relevant tables listed below have a direct impact on performance. and if they are not managed correctly.  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.

  RSARFC01:  tRFC Reorganization.sap.  Also.  b)  RFC related tables  For RFC tables. TRFCQOUT entried.  Recommendation:  If you find that the tables are large or have poor storage quality. ARFCRSTATE.Best Practice: ALE Monitoring  63 assures you of a well running system. and frequent changes.com/saphelp_erp2005vp/helpdata/en/12/83e03c19758e71e100  00000a114084/content. TRFCQDATA. can grow quite large and a data management strategy should also monitor and  manage these tables. due to the  high volume of data.htm  Regarding reorganizing IDoc Change pointer tables run the report RBDCPCLR periodically –  review the below URL for further information:  http://help.  Time stamps for Serialization at IDoc level are stored in table BDSER. This table can grow  quite large. Unlike the IDocs tables. ARFCSDATA. This will reduce the size of the database considerably  once the archived objects are removed.htm  The tables IDOCREL and SRRELROLES.  Further information available at:  http://help. 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. ARFCRDATA. link tables are not required to be archived before they are  deleted. for  example.sap. and statistics should not be collected.com/saphelp_erp2005vp/helpdata/en/dc/6b81ed43d711d1893e  0000e8323c4f/content. © 2007 SAP AG  63  . the indexes for these tables should be  reorganized on a regular basis.  RSARFCER:  Deletes tRFC in reference to the status  Refer to SAP Note 324545 and 375566 for additional details. TRFCQSTATE and TRFCQIN.  See SAP Note 752194 for further information.  TRFCQOUT.  These tables are considered volatile. outdated statistics and  poor storage quality. such as ARFCSSTATE. See SAP Note 505608 for further information. you can improve performance  by reorganizing these tables.  RSTRFCES:  Deletes ARFCSSTATE.  Once that is complete.  Recommendation:  Define an archiving strategy for your IDoc tables and implement using transaction SARA. which contain links to application documents. performance problems often  occur as a result of a large number of blocks allocated for these tables. Report RSRLDREL can be used to remove obsolete entries from these  two tables.  Report RBDSRCLR should be scheduled to keep this table at a manageable size. ARFCSDATA.  This report deletes the error log of the  ARFC in the background.

 ALE/EDI can create work items. The archiving object is WORKITEM.  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  . SWW*). Even if  you are not explicitly using workflow for the IDocs.sap.  6.com/ilm. SWWW* schedule relevant house keeping jobs or set up archiving  using transaction SARA (SAP Note 49545 explains how to delete unnecessary work items). you will find standard recommendations on the topic data  management and specific recommendations for different DB tables including interface­related DB  tables: http://service.  Recommendation:  Reorganize the work items.com/saphelp_nw04s/helpdata/en/8d/3e704c462a11d18900000  0e8323d3a/frameset.  Specifically look  out for interface  tables listed  above.sap.  In the following best­practice document.  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.e.htm  For workflow tables i.2 Automated Data Volume Monitoring  Automated Monitoring Objects with SAP Solution Manager  Monitoring  Monitor  Monit  Indicator  Monitoring  Respon­  Object  TA/Tool  Freq.  Respon­  sibility  Escalation  Procedure  Table Growth  DB02. See SAPHELP for further  information on archiving work items:  http://help.  DB15  Daily  SAP  Technology  Operations  Team  SAP  Technology  Operations  Team  6.1 Manual Data Volume Monitoring  Monitoring Objects without SAP Solution Manager  Monitoring  Monitor  Monit  Indicator  Object  TA/Tool  Freq.sap.com/~sapidb/011000358700005044382000E or visit quicklink  http://service.Best Practice: ALE Monitoring  64 c)  Workflow related tables  The work item tables can grow quickly (tables included are SWWWIHEAD.

 The  accuracy of the reported value depends on the timer of the operating system (under UNIX. 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. system resource consumption and middleware queues (among others). and therefore for  the underlying database  Load/Generating time  Time for loading/generating screens. background jobs running too long. ABAP programs. 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). other times. expensive SQL statements. This may be related to  long lasting transactions steps (dialog steps). memory management. In addition  to this measurement of time.1 General information  As part of the daily monitoring activities of your SAP system. you will find the description of a general procedure for monitoring the performance of  your SAP system. Poor  performance of a system is generally equal to extremely high response times.  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). There are several transactions available with which you can monitor  the average performance of the system and analyze the causes of poor performance.1 Performance Monitoring  In this section.Best Practice: ALE Monitoring  administration ­>  Data archiving)  System  Monitoring  growth in  transaction  DB15.  Please also consider the training BC315 Workload Analysis. consisting of parts of  the times listed above that cannot be calculated. statistical records. you should not only watch system  availability. and CUA elements (not  for presentation). database monitor and  buffer analysis among others.  DB01  Team  65 Team /  Application  Management  Team  7 Generic Part on System Monitoring  In this part of the ALE Monitoring Best Practice. etc. The different transactions that are mentioned in the procedure are described in  detail below.  Roll­in time  Time for rolling in the roll area context of a dialog step  Enqueue time  Time for setting a logical SAP enqueue  Processing time  This time is calculated as follows:  Processing time = Response time ­ Wait time ­ Load/Generating time ­ DB  time ­ Roll­in time ­ Enqueue time  Important: the CPU time should not be added to the above times as it is a total. Due to © 2007 SAP AG  65  . you will find information about common monitoring  activities that are not specific to special business process steps.  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. If you subtract these components from the response time.1. Please keep in mind that this is general information. such as waiting times or database times. are still measured  in SAP.  7.  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. for  example.  7. This course covers topics like workload  monitor. this leaves the processing time  which cannot be measured directly. but also the  performance of your SAP system. ABAP programming code is processed during the processing  time.

 performance monitoring should not only refer generally to a  task type. CPU. 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. whereas the user context is in the roll area. that is. The Roll wait time  is processed on a client. They also occur when the R/3 System communicates with the front­end  controls.  The Roll­Out time is not part of the response time. the R/3 context is rolled out. thus  releasing the work process.Best Practice: ALE Monitoring  66 this rough resolution of the CPU time. a single user or  a specific transaction or program  SQL trace of a specific step.  7. monitor on transaction or  even on dialog step level.g.  It is also important to use the right granularity for KPIs.  Generally speaking. less than 2 sec for each dialog step) as this might be too tight or  too  wide for specific needs. While the data on the front­end is being processed.)  Use when?  Daily (e.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. from individual statements  up to complete transactions  Get an overview on the time  distribution (DB. The transaction step  is only exited at this point.  The Roll wait time is the time a work process is waiting for the response of a RFC. Key Performance Indicators are quantifiable measurements. as it only occurs after the data is transferred to the  presentation server.  The application of the RFC is started here.  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. instead. neither resource is  used up nor does a bottleneck occur here for high Roll wait time.  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). it is not recommended that company ABC just monitors  the average response time for dialog transactions. If front­end Office  applications such as Microsoft Word are started and closed. High Roll wait times occur frequently. but should rather go one or to steps further into single transactions or even steps. This can occur several times during a transaction step. There is no need to  define a KPI for the response time of each and every step in the process.  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). This monitor provides an © 2007 SAP AG  66  . This is because no resource use occurs for the application server. As the call center agents need  very good response times for business partner searches in order to answer a call. 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. agreed beforehand. Roll wait is not part of the response time for transaction  steps of task type RFC.  that reflect the critical success factors of an organization.1. for transactions or background jobs. it is possible that a slightly longer CPU time is displayed for a  dialog step than for the response time. but it important that they are  not defined in a too general way (e.g.  Transaction  Workload  monitor  Workload /  statistical  records  Trans. the RFC connection is cancelled. which  Function Module or SQL statement  etc. short  sequence of steps or part of a long  running job  Getting an overview of the duration  and performance of the source  code.  This may be caused by calls of Windows or other external applications from within the R/3 System. Furthermore. a  very long Roll wait time occurs here also. In this case.  They should. The user context enters the roll areas and roll wait time is  processed until the application is exited. only after a long time (several minutes). Therefore. we refer to the system response  time for single dialog steps of your core business process(es). and the queries for  large target groups may take several seconds.

 you can display the totals  for all instances and then compare the performances of individual instances over specific periods of  time. with or without the GUI time · Workload and transactions used listed by users. 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 should normally start by analyzing the workload overview. If you are interested in a particular © 2007 SAP AG  67  . if you follow a useful naming convention. transactions. Therefore. and client · Workload generated by requests from external systems  For all of this data.  You can use the workload monitor to display the: · Number of configured instances for each SAP R/3 System · Number of users working on the different instances · Distribution of response times · Distribution of workload by transaction steps. 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. based on what is important for performance monitoring. · If a single dialog step (one step within a transaction) has a bad performance. DB time. In case of  performance problems.  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. listed by transactions. use transaction STAD to find what part of the response time  is particularly high in his case. Depending on your user mode.1.3 Transaction ST03N  Transaction ST03N is a very powerful transaction with lots of functions. · In case you can not find the cause of the performance problem or need further assistance for  the analysis contact the next support level or open an OSS message on component XX­SER­  TCC.  The system then displays the result on the right of the screen in a standardized ALV Grid Control. For most analysis views. sub­applications. Use the user profile for a comparison among  different users and user groups. The workload monitor is  used to analyze statistical data from the SAP kernel. the last weeks and the last months is possible. Wait time. Use the time profile of transaction ST03N to check if performance has been  decreasing over time or if there are peaks.  7. use transaction  STAD to find what part of the response time is particularly high in this case. week and month (or determine the length of  time yourself using the Last Minutes’ Load function). · If you have a general performance problem. function modules and destinations · Number and volume of spool requests · Statistics about response time distribution. packages. Continue the  analysis depending on the result. you can choose the  time period for which you want to display the data; day.Best Practice: ALE Monitoring  67 overview of the response times and the components (CPU time. Get an ABAP runtime analysis (transaction SE30) if you find that the  performance is related to high CPU or high processing times. You can quickly determine the source of possible performance problems using the large number  of analysis views and the determined data.  The workload monitor has an interface that is divided into two parts. When analyzing the performance of a system. For example. · Get a performance trace (transaction ST05) if you find that the performance problems are  related to high DB times.  Continue the analysis depending on the result. you can display it for a particular instance (not only the one to which you are  logged on) or optionally totaled for all instances. we can only  mention a few here. use the system monitors to check resource  consumptions. etc). Selection between the  last days. payroll number. 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. Compare it with other users to see if it is an isolated problem.

  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. The selection criteria include user. Dialog. it is not always possible to perform a  complete analysis for long­running transactions. 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. transaction. time frame from 03. However. In the first workload overview. choose Detailed Analysis. standard transaction profile. Here.  The analyzed time period can be larger than the interval defined by Read Time.  Figure 7­1 Transaction ST03N  7.  CPU time.1. you should use as short an interval as possible (around 10 minutes).2005 – 09.  If you want to use this transaction to analyze the performance of the steps done by a particular user. selecting for  instance the task type dialog and the aggregation per transaction.01. Update. than Last Minute’s Load and than the  required time frame on the appropriate instance.2005. and start time. workload for  server us0306_Q4C_02.  The following screen shot shows transaction ST03N using the options: Expert mode. You can now go to Analysis Views  à Transaction Profiles à Standard. RFC. as the system  analyzes complete transactions as far as possible. task type. etc). you can get a more detailed view. you find the response times and its components for the different  task types (Background.  program.01. etc) have been. slowly one after the other and write down the exact  time at which he executed them.  showing dialog transactions sorted by average response time. GUI time. As the business transaction analysis is time­  consuming.  proceed as follows: · Tell the user to execute the steps once. start date. every step on SAP Application Server is recorded. The records for all  instances of a SAP system are displayed. HTTP.Best Practice: ALE Monitoring  68 · time within the last 24 hours.4 Transaction STAD  In the transaction STAD. © 2007 SAP AG  68  . Wait time.

 CPU. program buffers) are filled. transaction SE30 (for long CPU times) or a  network analysis (not described in this document) in case of high GUI times. The last two fields can help you to identify the single  steps executed. Depending on what you are analyzing. © 2007 SAP AG  69 . GUI. 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. 69 Format the output list (button “Sel. …). for  example. ‘CUA reference  program’ and ‘CUA internal command’. 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. you ensure that all buffers (for  example. This way. With this analysis.  · · · · You can also use this transaction to see what was going on in the system during specific periods of  poor performance in detail. Fields”). transaction ST05 (for long DB times).  The following screen shots show the initial screen of STAD with the options: Show all statistic records. 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. 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. Depending on the result. proceed with a deeper analysis of the worst steps using. including the fields ‘GUI time’. Check which steps are actually having a bad response time and what part is contributing most  to it (DB. it might be wise to let the user execute all steps twice  and use the second execution for the analysis.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). for all users (*)  that executed dialog transactions lasting longer than 1000 ms. reading of the records for 10 minutes starting from 16:50 hours.  sorted by start time.  Call transaction STAD with the following selection criteria: · · · · · Show all statistic records.

 DB time. © 2007 SAP AG  70  . you see  which program was executed. time in work process. They where  adjusted using the “Select output fields” button (F9). the user. For each. Program and CUA internal  command are displayed. response  time. CPU time. within which transaction. For each time stamp.Best Practice: ALE Monitoring  70 Figure 7­2 Transaction STAD  Below. These columns are not all part of the first standard output. on which server. there are two screen shots showing the result of this query. CUA ref. GUI time.

 The steps should  be performed by a key user. the program. GUI time) given in the list. If you cannot identify the cause. if the did some unusual steps or if he  noticed a bad response time. please proceed as described below. Use also the information on the distribution of the response time (DB time. · Execute the typical steps of your core business processes once.  CPU time. However. these commands can be different  in your system depending on customizing settings. · · · Use this information to identify which dialog steps are having extremely high response times  during you peak load time. transaction SE30 (for long CPU times) or a network analysis (not described in this document)  in case of high GUI times. Contact the  responsible user to find out what he was doing at that time. Execute the steps slowly one  after the other and write down the exact time at which you executed them. Fields”). in detail. for example. Depending on the result  proceed with a deeper analysis of the worst steps using.1. transaction ST05 (for long DB  times). more than 10 seconds). the CUA reference program and the CUA internal command.  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). particular system usage.  · For details on the Performance monitoring on Function Code level and the monitoring setup  procedures use the following link  http://service.Best Practice: ALE Monitoring  71 To make the following steps easier. also. Format the output list (button “Sel. or if you are not sure on the  assignment. ‘CUA reference  program’ and ‘CUA internal command’. and so on.sap. © 2007 SAP AG  71  . to identify the cause of the problem. what is harming the performance of the corresponding  transaction or dialog step. 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. You may identify which steps belong together by  comparing the transaction. you may use the procedure described  for transaction ST05 for a deeper analysis. Make  sure you have displayed all the columns you need before downloading.  Use this information to analyse.  If you can’t find a CUA ref program or a CUA internal command in this list. Be aware. Please beware that the table beneath only shows  typical CUA internal commands for some common steps.com/~sapidb/011000358700003081072005E and navigate to section 2. 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). you may want to download the list with spreadsheet format. including the fields ‘GUI time’. that the STAD  records are only kept in the system for a limited period (normally 24 or 48 hours). user exits.  In addition. search for those taking particularly long (for example.

 You can use these results to identify runtime­intensive statements. · 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. to combine  table accesses. a detailed description of the performed steps and the related STAD records to the message. Write down the displayed time stamps  (trace period) to be able to find the same trace in the system later on. you make sure that all buffers (for  example. contact the next support level or open an SAP message on component SV­BO. 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. function modules or classes. which  you can display as lists. or need further assistance for the  analysis. From the results of the runtime analysis. and remote calls of reports  and transactions in a trace file and to display the performance log as a list. such as. you  can identify: · · · · Excessive or unnecessary use of modularization units CPU­intensive program functions User­specific functions that could be replaced with ABAP statements Inefficient or redundant database access. Attach the  trace. If you identified a transaction or a process step that is taking too  long. program buffers) are filled. locking activities. Make sure the user name is correct.1. Use the extended trace  list to display the time stamps for each SQL statement. · Enqueue Trace: This allows you to monitor the locking system.  In case you cannot find the cause of the performance problem. also for authorization object S_ADMI_FCD). © 2007 SAP AG  72  . to find out if one or more SQL statements are causing the  performance problem. It allows you to record database access.  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.Best Practice: ALE Monitoring  72 7. it might be wise to let the user execute all steps twice  and use the second execution for the analysis.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.1.  · Go trough the trace and search for the statements with a high duration (marked red). This way.6 Transaction SE30  The runtime analysis tool allows you to examine the performance of any ABAP programs. Depending on what you are analyzing. Use the ‘explain’  function to see if the correct index is being used for that statement.  reports.  7.  To use the performance trace.  The aim of the procedure described below is to find the SQL statements that are causing high  response times in the SAP system. subroutines. locking. and remote calls of reports and  transactions. It saves its results in performance data files. and show the hierarchy of program calls. It also provides extensive  support for analyzing individual trace records. you may use transaction ST05.

Best Practice: ALE Monitoring 

73

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 SV­BO. Attach the  runtime analyses, a detailed description of the performed steps and the related STAD records to the  message.  For more information on automated performance monitoring via CCMS and SAP Solution  Manager, also read section 2.1 of the document Application Monitoring with SAP Solution  Manager. 

7.1.7 Transaction ST12 
The Single Transaction Analysis tool allows you to examine the performance of transactions or ABAP  programs, such as reports, subroutines, function modules or classes. You can trace the ABAP coding  as well as the database activities (SQL trace / performance trace) in one run. It saves its results in  performance data files, which you can display as lists.  You can use these results to identify runtime­intensive statements, to combine table accesses, and  show the hierarchy of program calls. From the results of the runtime analysis, you can identify: · · · · Excessive or unnecessary use of modularization units CPU­intensive program functions User­specific functions that could be replaced with ABAP statements Inefficient or redundant database access. 

ST12 allows you to aggregate the ABAP trace data per modularization unit (subroutine, loop, function  call …) and gives the possibility to analyze the ABAP trace in different ways with a graphical help for  easier identifying the call tree structure from different perspectives. The performance trace and the  ABAP trace, if done from within one ST12 trace execution are kept in one named version and can be  analyzed together.  ST12 comes with the support tools add­on ST­A/PI à see note 69455 for details.

© 2007 SAP AG 

73 

Best Practice: ALE Monitoring 

74

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).  ST­A/PI is small and does not interfere with productive coding. It can be implemented anytime and  there is no need to logoff users.  For details about the use of transaction ST12, see note 755977.  Depending on the size of the program, considerable volumes of data can be generated during the  runtime analysis. For this reason, this tool is defaulted to aggregation per calling position. This  reduces the volume of records for a loop to the number occurrences in the coding of a loop – instead  of separate records for each loop cycle. Note 755977 gives you more details.  The runtime analysis consists of two parts: · · Recording performance data Analyzing the performance data 

In the first part, the system measures the transaction, program, or procedure, and writes the result to a  performance data file. You can restrict the measurement to certain objects. You can also measure up  to ten external processes.  In the second part, the performance data is analyzed, and the system displays the results in list form.  For more information on this transaction and its usage please see the application help.  For more information on automated performance monitoring via CCMS and SAP Solution  Manager please also read the chapter 2.1 of the document Application Monitoring with SAP  Solution Manager. 

7.2 General Monitoring Guidelines for a SAP System 
For the administration of an SAP R/3 system, there are a number of monitoring activities we strongly  recommend scheduling and supervising on a regular basis. The following list is not complete,  especially jobs and tasks for the database administration (such as backups, archiving transaction logs,  update statistics for cost base optimizer and so on) are not mentioned, however it gives you an  impression of what you have to do in order to keep a system running. If you have further questions on  these subjects, please refer to the Solution Management Optimization Service System  Administration.  The table below lists transactions used for General System Checks: 
Monitoring  Monitor  Monitor  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 

ST04 

Weekly  tbd  and in  case of  performa 

Increased  database  response  time / 

© 2007 SAP AG 

74 

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 

75

Operating  system  monitor 

R/3 System  ST02  buffer  monitor 

Swaps 

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 

SM50 

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 

SM66 

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 

DB02 

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  qRFC­tables (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 

Dumps 

© 2007 SAP AG 

75 

 determine whether  the update request can be re­  started or has to be deleted.  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  .  team  Maintain date/time and select  Reread system log.  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.  monitoring  team  Update records should be  monitored regularly and the  appropriate user should be  contacted immediately to resolve  any outstanding updates.  investigate SAPNet for a possible  resolution and if necessary. Together  with the user.  Status  Check for entries that have status  Software  ‘ERR’.Best Practice: ALE Monitoring  Monitoring  Monitor  Monitor  Object  TA/Tool  Freq. and then choose  Display. For customer  developed programs contact the  appropriate member of the  development team. open a  customer message. Position cursor  on a time.

 Restartability and Escalation of every step). 2006.  Literature · · For detailed information on how to administer an SAP R/3 system. see the book:  Thomas Schneider. · · Search for related notes in the SAPNet. Open an SAP Customer Message describing your problem (please see the respective  component in section Error Handling. 2003 For information on how to monitor and tune the general system performance. SAP Performance Optimization Guide. see the book:  Liane Will. © 2007 SAP AG  77  . SAP R/3 System Administration.Best Practice: ALE Monitoring  77 8 Further Information  Troubleshooting   If executing this Best Practice did not produce the desired results.

 or non­infringement. OS/390  .. text. BAPI. XML. PowerPoint  and SQL Server  are registered trademarks of  Microsoft Corporation. special.  ®  HTML.  Some software products marketed by SAP AG and its distributors contain proprietary software components of other software  vendors.  SAP. SAP does not warrant the accuracy or completeness of the  information.  ®  ®  ®  ®  UNIX  . EXCEL  .  SAP shall not be liable for damages of any kind including without limitation direct. RIVA.  Disclaimer : SAP AG assumes no responsibility for errors or omissions in these materials. SAP EarlyWatch. WebFlow. DHTML. ABAP. the implied warranties of  merchantability.  SAPPHIRE.  ®  ®  JAVA  is a registered trademark of Sun Microsystems. These materials are provided “as  is” without a warranty of any kind.  TM  ®  ®  INFORMIX  ­OnLine for SAP and Informix  Dynamic Server  are registered trademarks of Informix Software  Incorporated. either express or implied. Management Cockpit. AIX  . S/390  .com Logo and mySAP.  Inc. XHTML are trademarks or registered trademarks of W3C  . mySAP. All other products mentioned are trademarks or registered  trademarks of their respective companies. SAP Business Workflow.com are trademarks or registered trademarks of SAP AG  in Germany and in several other countries all over the world. AS/400  . including but not limited to. R/3. Word  . R/2. and Motif  are registered trademarks of the Open Group. used under license for technology invented and implemented by Netscape. or consequential  damages that may result from the use of these materials. All rights reserved. indirect. OSF/1  . DB2  . MVS/ESA  . The information contained herein may be changed without prior notice.Best Practice: ALE Monitoring  © Copyright 2007 SAP AG. JAVASCRIPT  is a registered trademark of Sun Microsystems. links or other items contained within these materials.  ®  ®  ®  ®  ®  ®  ®  Microsoft  . X/Open  .  Massachusetts Institute of Technology. SAP ArchiveLink. Inc.  78 No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission  of SAP AG. OS/2  . graphics.  ®  ®  ®  ®  ®  ®  ®  ®  ®  ®  ®  IBM  .  ®  ORACLE  is a registered trademark of ORACLE Corporation. SAP has no control over the information  that you may access through the use of hot links contained in these materials and does not endorse your use of third party  Web pages nor provide any warranty whatsoever relating to third party Web pages. World Wide Web Consortium. and  ®  OS/400  are registered trademarks of IBM Corporation. Parallel Sysplex  . SAP Logo. RS/6000  . DB2/6000  . WINDOWS  . fitness for a particular purpose. © 2007 SAP AG  78  . NT  .

Sign up to vote on this title
UsefulNot useful