Ale monitoring

5,039 views

Published on

3 Comments
4 Likes
Statistics
Notes
No Downloads
Views
Total views
5,039
On SlideShare
0
From Embeds
0
Number of Embeds
103
Actions
Shares
0
Downloads
132
Comments
3
Likes
4
Embeds 0
No embeds

No notes for slide

Ale monitoring

  1. 1. ALE Monitoring Best Practice for Solution Management  Version Date: 16.05.2007 Contents 1  Introduction .............................................................................................................................3  1.1  Applicability, Goals, and Requirements...............................................................................3  1.2  Best Practice Procedure.....................................................................................................5  1.2.1  Motivation for Interface Monitoring .............................................................................5  1.2.2  Preliminary Tasks.......................................................................................................5  1.2.3  Interface Monitoring concept ......................................................................................5  1.2.4  Legend ......................................................................................................................5  1.3  General Overview on ALE/EDI............................................................................................6  1.3.1  ALE (Application Link Enabling) .................................................................................6  1.3.2  EDI (Electronic Data Interchange) ..............................................................................6  1.3.3  IDocs .........................................................................................................................6  1.3.4  Change Pointers: .......................................................................................................7  1.3.5  ALE Processing Modes..............................................................................................7  1.4  Example Business Scenario with ALE...............................................................................15  1.4.1  Interface Monitoring in SAP CCMS and SAP Solution Manager................................15 2  Aspect: Error Monitoring........................................................................................................23  2.1  Manual Error Monitoring ...................................................................................................25  2.2  Automated Error Monitoring..............................................................................................28  2.3  Details on IDoc Batch Job Monitoring ...............................................................................29  2.4  Handling different error statuses ALE/EDI .........................................................................30  2.4.1  Status 02: Error passing data to port.........................................................................30  2.4.2  Status 03:.................................................................................................................30  2.4.3  Status 26: Error during syntax check of IDoc (outbound)...........................................30  2.4.4  Statuses 27, 29, 37: IDOC processing towards tRFC layer has problems .................31  2.4.5  Status 51: Application document not posted .............................................................31  2.4.6  Status 56: IDoc with errors added [anything missing?] ..............................................32  Status 63: Error passing IDoc to application...........................................................................32  2.4.7  Status 60: Error during syntax check of IDoc (inbound).............................................32  2.4.8  Status 65: Error in ALE service.................................................................................32  2.4.9  Reposting of IDocs in Status Error............................................................................33 3  Aspect: Backlog Monitoring ...................................................................................................36  3.1  Manual Backlog Monitoring ..............................................................................................36  3.2  Examples of Backlog Analysis techniques ........................................................................38
  2. 2. Best Practice: ALE Monitoring  2  3.2.1  Single IDoc time stamp analysis...............................................................................38  3.3  Automated Backlog Monitoring .........................................................................................39 4  Aspect: Performance Monitoring............................................................................................41  4.1  Manual Performance Monitoring.......................................................................................41  4.1.1  Overview of Available Tools for ALE/EDI Performance Analysis ................................44  4.1.2  Activation of Performance Monitoring With Transaction ST03N ................................48  4.2  Automated Performance Monitoring .................................................................................56 5  Aspect: Resource Monitoring.................................................................................................57  5.1  Manual Resource Monitoring............................................................................................58  5.2  Automated Resource Monitoring.......................................................................................61 6  Aspect: Data Management ....................................................................................................62  6.1  Manual Data Volume Monitoring.......................................................................................64  6.2  Automated Data Volume Monitoring..................................................................................64 7  Generic Part on System Monitoring .......................................................................................65  7.1  Performance Monitoring ...................................................................................................65  7.1.1  General information .................................................................................................65  7.1.2  Procedure ................................................................................................................66  7.1.3  Transaction ST03N ..................................................................................................67  7.1.4  Transaction STAD....................................................................................................68  7.1.5  Transaction ST05.....................................................................................................72  7.1.6  Transaction SE30 ....................................................................................................72  7.1.7  Transaction ST12.....................................................................................................73  7.2  General Monitoring Guidelines for a SAP System .............................................................74 8  Further Information................................................................................................................77© 2007 SAP AG  2 
  3. 3. 1 Introduction1.1 Applicability, Goals, and Requirements To ensure that this Best Practice is the one you need, consider the following goals and requirements. Goal of Using this Service This Best Practice helps you set up an Interface Monitoring concept with the focus on ALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitor ALE­based interfaces manually as well as automated by using SAP Solution Manager. Both monitoring approaches aim to detect any irregularities or deviations or to detect error situations at an early stage. These procedures intend to ensure that the interface processing meets the requirements for stability, performance and completeness as well as a smooth and reliable flow of the core business processes so that your business requirements are met. Alternative Practices You can have SAP experts deliver this Best Practice on­site by ordering a Solution Management Optimization (SMO) service for SAP Interface Management. This service is exclusively available within an SAP Support Engagement (that is, SAP MaxAttention, SAP Safeguarding or SAP Premium Support). Staff and Skills Requirements To implement this Best Practice, you require the following teams: Application Management Team This team provides the information on the business background of the interfaces used and knows the needed business requirements for the interfaces: · Business department · Solution support organization (for example the Basis Support or the Application Support) · Implementation project team Business Process Operations Team The Business Process Operations team will be responsible for applying the resulting procedures derived from implementing this best practice. They include the following groups: · Persons designated to perform business process oriented monitoring and ensure that the  process runs smoothly (for example, the Business Process Champion for each business  process) · All parties in your Solution Support Organization and IT department involved in monitoring  focused on the application aspects (Application Support, Development Support, Job  Scheduling Management) SAP Technology Operations Team · All parties in your Solution Support Organization and IT department involved in monitoring  focused on the system administration side (Program Scheduling Management, Software  Monitoring Team, System Administration Team including the System Administrator) Business Process Champion · The Business Process Champion is the person in the business department that is responsible  for the successful execution of the business process. He coordinates all activities necessary  for the business process. Therefore, he is usually responsible for the escalation paths in case  of problems. Often he is a second level in the escalation procedure, if the application  monitoring team needs to escalate an issue.
  4. 4. Best Practice: ALE Monitoring  4 Necessary or Useful Trainings  q  BIT300 ­ Interface Technology Overview  q  BIT350 ­ ALE Enhancements  q  SMO610 ­ BPM training course  q  ADM105 ­ Advanced R/3 System Administration  q  ADM315 ­ Workload Analysis System Requirements  To setup an automated IDoc monitoring on the SAP Solution Manager, the connected satellite  systems has to be at least of release 4.6C. To have all described monitoring object available in  SAP Solution Manager, add­ons ST­PI and ST­A/PI has to be installed on the SAP satellite  systems. Duration and Timing  Duration  Creating an Interface Monitoring concept depends very much on the complexity of your interface  landscape and could take around one week for about 10 ALE/IDoc interfaces.  Timing  The best time to apply this Best Practice is during the planning phase or during the implementation  phase of your SAP solution. How to use this Best Practice This document gives you an overview on interface monitoring tools and procedures for ALE/EDI monitoring. The aim is not to name all available monitors and tools but to focus on the more suitable monitors and tools for each of the aspects discussed. After having got a general idea on monitoring possibilities you should evaluate which are the critical error situations in your system landscape and individually decide which monitoring procedure is suitable in your case. We do not recommend setting up a full blown monitoring but recommend concentrating on selective alert situations that will inform you in exceptional cases. In the next step you can follow the setup procedure and implement the monitoring on your systems. In case of business process related monitoring objects you have the possibility to setup a business process monitoring focused monitoring concept and involve your application teams in monitoring and error resolution activities. For a better understanding on what should be monitored it is essential to understand the ALE processing mechanism. The first section is supposed to give you a general overview on ALE/EDI and introduces to you the automated ALE monitoring functionality within SAP Solution Manager using the example business process “Processing Purchase Orders”. Sections 2 to 6 list monitoring objects both for manual as well as automated monitoring procedure concentrating on the six major areas: Resource Monitoring, Error Monitoring, Backlog Monitoring, Performance Monitoring and Data Management. The monitoring object tables list the following information:  o  Monitoring object  o  Monitoring transaction or tool  o  Monitoring frequency  o  Indicator for an issue or error  o  Monitoring activity or error handling procedure  o  Responsibility  o  Escalation Procedure The last section Generic Part includes information on scenario independent tools, for example performance monitoring.© 2007 SAP AG  4 
  5. 5. Best Practice: ALE Monitoring  5 1.2 Best Practice Procedure 1.2.1 Motivation for Interface Monitoring Today’s system landscapes are often decentralized and can consist of various interfaces. Different SAP systems, legacy environments and business entities are integrated using different interface technologies. All those interfaces need to be monitored in terms of resource availability, processing errors, backlog situations and performance. IT Operation relies completely on the fact of 100% data consistency. With an increased complexity of system landscapes we face an increased risk of data inconsistency. For early detection, specific data consistency reports have to be executed on a regular basis. Also detailed error handling and disaster recovery procedures need to be defined. A proactive interface monitoring helps to identify and avoid inconsistencies. 1.2.2 Preliminary Tasks Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in the system:· Complete all installation and post­installation actions and procedures including customizing· Ensure that the initial download has been successfully executed· Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations  resulting from customer problem messages· Implement all current SAP Support Packages upon availability 1.2.3 Interface Monitoring concept For a successful and efficient Interface Monitoring concept, a process for the execution of the monitoring concept has to be defined. This includes the definition of the roles and responsibilities involved. It has to be defined who is supposed to carry out which activity and how is the communication between the different roles within the support organization supposed to take place. An Interface Monitoring concept has to be tightly integrated with the support organization. This includes the integration with the Incident/Problem Management process and the Change Management process. These processes have to be adjusted so that communication and escalation procedures contained within these processes are adequate to support the Interface Monitoring concept. This includes the final communication of open alerts to SAP. Wherever communication connected with Interface Monitoring happens outside these support processes, separate communication and escalation paths and procedures have to be defined. See the separate Best Practice for General Business Process Management for further details. 1.2.4 Legend  This symbol indicates you a paragraph from where you can navigate to another section of this  document for more detailed information on a topic.  This symbol indicates you a paragraph from where you can navigate to another document  within the SAP Service Marketplace for more detailed information on a topic.© 2007 SAP AG  5 
  6. 6. Best Practice: ALE Monitoring  6 1.3 General Overview on ALE/EDI 1.3.1 ALE (Application Link Enabling) Application Link Enabling (ALE) is the technology used by SAP within one company to support distributed business processes across separate application components within the company’s landscape. ALE uses the business scenarios and function modules that allow transfer data to or from an SAP system without developing customer­specific programs. ALE is linked closely with Workflow Management within SAP. The data is not only transferred between the systems; in addition it can also trigger follow­up actions in the SAP system. From the SAP viewpoint, the following data can be exchanged via ALE: • Transaction data, which is data from applications • Master data, such as customer or material master data • Customizing data used for an overall ALE view Data can be exchanged between SAP Systems and external (non­SAP) systems. The following functions and interfaces form the basis of communication: • ALE with all its components such as monitoring, archiving, • Usage of the data container called Intermediate Document (IDoc) • Transactional RFC (tRFC) 1.3.2 EDI (Electronic Data Interchange) EDI is a standard format for exchanging business data. It describes the document exchange with business partners on a technical level. With EDI the technical structure of the document is retained. EDI describes the mapping of the application data structure from the sender into the EDI standard, and from the EDI standard into the application data structure of the recipient. This enables the recipient to automatically process the document by his business software. The standard is ANSI X12 and it was developed by the Data Interchange Standards Association. ANSI X12 is either closely coordinated with or is being merged with an international standard, EDIFACT. 1.3.3 IDocs IDocs are predefined data structures of SAP applications at the interface level. IDoc types form the container for the data to be exchanged. Each application has a special set of IDoc types, which provides data to be exchanged. IDocs can be used to exchange data between two R/3 systems or between R/3 and an external system (non SAP). Instead of calling a program in the destination system directly (RFC), the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. IDoc data exchange is always an asynchronous process. When communicating with an external system (non SAP) an EDI converter or subsystem such as Gentran receives the EDI messages in standardized format (such as EDIFACT), and then converts it to the IDoc format supported by SAP for further processing. ALE enables a controlled exchange of Intermediate Documents (IDocs) between application systems and is used for: · Separation and integration of operational units · Master and transactional data · Exchange with Business Partners via EDI© 2007 SAP AG  6 
  7. 7. Best Practice: ALE Monitoring  7 Figure 1­1 Application Link Enabling / IDoc flow 1.3.4 Change Pointers: If you want to distribute master data changes with the SMD tool (Shared Master Data), changes to the master data objects are flagged for distribution by change pointers ( ® Master Data Distribution). Change pointers are basically the key fields of the table that contains the changed field. In ALE Customizing, customers can specify the fields that need to be distributed. The SMD tool is connected to the change document interface. If the master data changes are to be distributed (defined in ALE customizing), the application writes a change document. The contents of this are passed to the SMD tool. The tool writes change pointers, reads the application data and creates the master IDoc. The master IDoc is then passed to the ALE layer, which sends it to all interested systems. 1.3.5 ALE Processing Modes There are two basic ways to send IDocs via tRFC (ALE) or via flat file (EDI). The method of sending is determined by the port type and depends on the technical configuration of the target system. It is configured using transaction WE21 (ports in IDoc processing). The port type is specified in transaction WE20 (partner profiles) choose partner and select relevant outbound parameter. Figure 1­2 Transaction WE20 ­ ALE processing mode© 2007 SAP AG  7 
  8. 8. Best Practice: ALE Monitoring  8 1.3.5.1 ALE ­ tRFC Most common between R/3 systems is the (asynchronous) transactional RFC interface (standard ALE scenario)  Ÿ  Integrated business processes across distributed systems within one company  Ÿ  Example: replication of master data between several SAP Systems  Ÿ  Distribution of master data, transactional data, and control data  Ÿ  This occurs during application Customizing The advantages of transactional Remote Function Calls (tRFC) over synchronous and asynchronous RFCs are:  Ÿ  The calls are buffered, even if the recipient partner is not active. When the partner is  available again, a new attempt can be made to transfer the data.  Ÿ  If an SAP system receives the data, the requests are handled as transactions. This  means that all functions called in one tRFC are either processed together or not at all.  Ÿ  Each tRFC is sent exactly once, so that there are no accidental double postings of  application data.  Ÿ  All erroneous attempts to post data are displayed in the tRFC monitor. 1.3.5.2 EDI ­ Flat File Most common between R/3 system and EDI subsystem is the flat file interface (standard EDI scenario). An EDI subsystem/converter maps IDocs to international standard formats  Ÿ  SAP systems use Intermediate Document (IDoc) format to store application  documents for transfer  Ÿ  Examples of standard formats: UN/EDIFACT, ANSI X.12 1.3.5.3 Processing Modes Processing in the application layer and the ALE layer are completed on both the outbound and inbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface to the receiving system where it can be posted. Outbound and Inbound IDocs can either be processed individually (immediate transfer) or as a collection/package using a background job. This setting is made in the partner profile using transaction WE20. 1.3.5.3.1 Outbound IDoc Processing  Transaction WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Outbound Parameter.© 2007 SAP AG  8 
  9. 9. Best Practice: ALE Monitoring  9 Figure 1­3 Transaction WE20 – Partner profile outbound When the output mode “Tars Immediately” is activated, IDocs are transferred immediately to the receiver system as soon as IDocs are created. There is a performance overhead associated to this technique as a new connection is opened for each IDoc sent, in addition the same programs,  user contexts, and  database tables are read multiple times. If immediate processing is implemented, the sender also has to wait for an acknowledgement about the success of the processing from the receiver. This could cause performance problems especially if runtime is quite long in the receiving system and could lead to backlogs if the sender is restricted in his parallel processing capabilities. It is recommended where possible (business requirements may dictate that immediate processing is required) to use the output mode “ Collect IDocs” . With the output mode “Collect IDocs” IDocs are collected and set as a package to the receiving system; this can save processing time because it usually avoids the overhead of opening multiple connections (only one connection opened per package) and loading the programs and user contexts, avoids reading common database tables from disk several times and so on. In addition to setting the collect flag “ collect IDocs”  the report RSEOUT00 needs to be scheduled on a regular basis as a background job (TA SM36). Using this report you can enter the maximum number of IDocs that should be transferred before a COMMIT WORK is set and the IDocs become blocked. If too high a number for “max number of IDocs” is selected, it can lead to runtime errors (for example Timeouts). In this case, you must choose a lower value. Packet Size: A general recommendation is between 50 and 100. However, it depends on a number of factors like size of the IDocs (in case of large IDocs a small package size is better) or network bandwidth. The packet size that suits best for a given interface should be carefully investigated using test runs or alternatively as part of an SAP Interface Management Optimization service.  For more information visit: http://service.sap.com/ifm ).© 2007 SAP AG  9 
  10. 10. Best Practice: ALE Monitoring  10Figure 1­4 Report RSEOUT00© 2007 SAP AG  10 
  11. 11. Best Practice: ALE Monitoring  111.3.5.3.2  Inbound IDoc Processing:  Transaction WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Inbound Parameter. Figure 1­5 Transaction WE20 – Partner Profile inbound Trigger Immediately: Upon receipt inbound IDocs are immediately released for posting. ALE inbound processing splits the IDoc packets into individual IDocs; this results in an overhead such as,. the same programs, user contexts, and database tables are read multiple times. Trigger by Background Program  It is important to note that if the receiver system uses trigger immediately option, whether IDocs are processed in the package or not depends on the character of the Inbound function module (if function module supports mass processing or not is defined in transaction BD51). If mass processing is not supported, IDocs will be posted one by one. Inbound IDocs and IDoc packets are first saved in the database into single IDocs. Single IDocs can be put into packets and then processed this functionality is provided by report RBDAPP01, which allows you to specify the package size for the RFC call. This type of package processing is valid for all IDoc types as there are no special requirements for the inbound function module. However there is limited optimization potential here as a commit is triggered for every processed IDoc because the ALE layer calls the function module several times in the same dialog process. This does however reduce the administrative load on the R/3 System because if packaging was not implemented, each IDoc would be processed in a new dialog process meaning, the same programs, user contexts, and database tables are read multiple times. If you use function modules that can process IDocs in mass, this has a significant optimization potential as overhead is reduced significantly.  This type of package processing can be used depending on the configuration of the Inbound function module used for an IDoc. This can be checked via transaction BD51. If the input type value is set to ‘0’ the function module is enabled for mass processing. In this case, one commit is triggered for all IDocs belonging to a packet. It offers additional© 2007 SAP AG  11 
  12. 12. Best Practice: ALE Monitoring  12optimization potential apart from the loading of the programs and users contexts and avoids reading the common database.  It is recommended where possible (business requirements may dictate that immediate  processing is required) to use the inbound processing mode “Trigger by background program”. To do this carry out the steps below in ALE Customizing:  1. Set up background processing:  TA WE20 ® Partner Profiles ® Select the relevant Partner ® Select the relevant Inbound Parameter  Inbound processing mode should be set to: “Trigger by background program”  2. Schedule posting and configure packaging:  Create variants of report RBDAPP01 and schedule as required using transaction SM36. To  specify a package size use field pack size. As a guide, you should use a packet size of between  20 and 100 IDocs. Figure 1­6 Report RBDAPP01 Additionally, ensure that separate batch jobs for report RBDAPP01 are scheduled with variants that include all IDocs that are set to immediate processing; not just those that are set to be ‘triggered by a background program’. This leads to a tighter control on the handling of the incoming IDocs. (IDocs are configured to be posted immediately but if no free dialog work processes are available when Inbound IDocs are created they will remain unprocessed with status 64. IDocs will not be processed unless report RBDAPP01 is scheduled.)© 2007 SAP AG  12 
  13. 13. Best Practice: ALE Monitoring  13Figure 1­7­1 Report RBDAPP01 – Parallel processing As illustrated above report RBDAPP01 can be configured to facilitate parallel inbound processing. Parallel processing can be used to improve performance and spread the load to a specific group of application servers. If the indicator “Parallel Processing Active” is set then the inbound processing of the application uses one free dialog process for each IDoc packet on the application server (asynchronous RFC is used for this). This means that the packets can be processed in parallel. If several IDoc packets have been selected, then the IDoc processing can occupy all the dialog processes on the application server. If the indicator is not set then the IDocs will not be processed in parallel. This means that each packet will be passed to the application in turn. Only one work process will be used for this action on the application server. The input field server group defines the RFC Server group which will be used by the report in parallel processing. Server groups are set up using transaction RZ12 below. Figure 1­8­2 Transaction RZ12 – RFC Server Group Maintenance Application servers in a server group can be used in parallel for updating IDocs in the background. There might be only one application server in a server group, however we recommend that you have multiple application servers configured for a server group so that the load can be balanced between the servers of a server group and also it improves availability. By default, a parallel­processed job uses all qualified servers in an SAP System according to automatic resource­allocation rules. However, by defining RFC groups, you can control which servers can be used for parallel­processed jobs. An RFC group specifies the set of allowed servers for a particular parallel­processed job. If you do not specify a server group, all dialog processes in the SAP system are used in parallel. This could result in resource shortages in the application servers.© 2007 SAP AG  13 
  14. 14. Best Practice: ALE Monitoring  14Generally, SAP recommends (if resources allow) to have a dedicated group of servers to handle RFC communication and to have separate servers for DIALOG end users. If however, resources are not available, it is also possible to limit the amount of resources used by RFC by limiting the resources of the RFC server group – current resource configuration can be checked by double clicking the Group. (See figure 1­6­3 below). Figure 1­9­3 Transaction RZ12 – Determination of resources You can assign the above RFC resource parameters to these RFC server groups to limit the load generated from RFCs within an SAP system as described in SAP Notes 74141 and 99284  Note:  To implement packaging of IDocs for a flat file (using file port such as,. EDI), it must be verified in advance that the middleware/target system can handle files that include multiple IDocs. In addition a fixed file name should not be used as there is the risk that a file that has not yet been processed will be overwritten in the target system. Therefore the file port (WE21) should be configured to use a function module which generates dynamic file names such as, using a unique number (for example, IDoc number, MSGGUID or original application document number, and so on.). A timestamp would not suffice because if parallel processing was activated there is a possibility of the same timestamp being generated for two different files thus one will overwrite the other.© 2007 SAP AG  14 
  15. 15. Best Practice: ALE Monitoring  151.4 Example Business Scenario with ALE For the different aspects of interface monitoring the SAP Solution Manager can be used. In this section we provide you an overview on its functionality with reference to the following example business scenario: PC Express is a midsize company. Its main business is buying PC components, composing them to pre­configured PCs and selling them within Europe. The sales department is divided between Great Britain, other EU countries and non EU European Countries. One of their core business processes is named “Processing Purchase Orders” and is maintained within the SAP Solution Manager.  IDoc  message flowFigure 1­10 Business Process: Processing Purchase Orders In the business process “Processing Purchase Orders” IDocs of message type ‘MATMAS’ (Material Master) are sent from the SAP ECC sender system to the SAP MM receiver system via an ALE distribution model. To monitor the IDoc flow from end­to­end the monitoring on the sending and the receiving system needs to be set up for the IDoc processing – in this example of message type ‘MATMAS’. 1.4.1 Interface Monitoring in SAP CCMS and SAP Solution  Manager For some monitoring activities it is possible to use a tool for automated monitoring. This is also possible with interface monitoring. Such automated monitoring is optimally implemented using Business Process Monitoring or System Monitoring in SAP Solution Manager. Business Process Monitoring (BPMon) within SAP Solution Manager is the proactive and process­ oriented monitoring of the core business processes of your company. It includes the observation of all technical and business application­specific functions that are required for a smooth and reliable flow of the business processes. Business Process Monitoring (BPMon) reveals even slight deviations from a pre­defined ideal business process state which would otherwise remain undetected until the flow of the process would be seriously impacted. It gives automated alerts including the possibility to notify these via various communication means like email, SMS and so on. Types of errors that can be monitored are for example errors from logs (system log, application log and so on), throughput and backlog KPIs for various applications, dialog performance, update errors, and so on The possibility to keep the alerts for a defined time allows to evaluate a kind of history and to identify trends in the alert occurrence at an early state. © 2007 SAP AG  15 
  16. 16. Best Practice: ALE Monitoring  16For further details on Business Process Monitoring refer to http://service.sap.com/bpm. Wherever monitoring via SAP Solution Manager is possible you will find a separate table, indicating the relevant automatic monitoring functionalities. The approach of this section is to outline the setup procedure for a selective interface monitoring for messages involved in your core business processes. 1.4.1.1 Standard ALE/EDI Monitoring The Interface Monitoring functionalities are based on the SAP Computing Center Management System or CCMS Alert Monitor (transaction /NRZ20) and could be used independently of the SAP Solution Manager, if needed. The standard CCMS monitors on the satellite system show an ALE/EDI IDoc Monitoring for all message types in inbound and in outbound direction. The standard monitoring group can be found in transaction /NRZ20 ® SAP CCMS Technical Expert Monitors ® System / All Monitoring Segments / All Monitoring Context ® ALE/EDI <SID>(CLIENT) Log.sys ‘name of logical system’. Figure 1­11 CCMS ALE/EDI Standard Monitoring Groups 1.4.1.2 Specific ALE/EDI Monitoring Besides the standard monitoring objects available in SAP CCMS you can setup a specific ALE monitoring. This gives you the possibility to individually monitor IDocs which refer to certain business processes. In our example IDocs of type ‘MATMAS’ are exchanged between two SAP systems. This© 2007 SAP AG  16 
  17. 17. Best Practice: ALE Monitoring  17interface is part of the core business process “Processing Purchase Orders” and is a critical interface which needs to be monitored on a regular basis. The customizing of ALE/EDI monitoring objects can be done with transaction BDMO. With transaction BDMO it is possible to create new monitoring objects only for a specific message type and to activate them accordingly. This can be done either in inbound or in outbound direction or both. If two SAP systems are involved you need to do the customizing on both the sending system (outbound direction) as well as the receiving system (inbound direction). System wise, these objects are considered as customizing. Therefore, they have to be set up in the development system and from there transported via the quality assurance system to the productive system. To create a new monitoring object the button Create/activate monitoring objects in the entry screen of transaction BDMO must be used. Figure 1­12 BDMO – Create/Activate Monitoring Objects In the following screen the new entry needs to be entered and set to active. Figure 1­13 BDMO – New Entry In some cases it might be necessary to re­call transaction BDMO to have the new entry available. In the entry screen it is now possible to select the newly created monitoring object. The following screen will pop up: Figure 1­14 BDMO – Customize Monitoring Object The specific message types for the inbound and/or outbound direction of an interface need to be specified. If one direction should not be monitored explicitly, it can be left blank. It is also possible to© 2007 SAP AG  17 
  18. 18. Best Practice: ALE Monitoring  18specify more than one message type if needed. The system type of the partner system needs to be maintained as well as the system number from the partner (see transaction WE20). In section Period you can specify the number of days for the age of the IDocs that should be included into the evaluation. In field Wait time status changes OUT or field Wait time status changes IN you can specify a waiting time in minutes to change a status. If this time has not elapsed since the last status change, the previous status is used and not the last one. Use cases might be the following:  a.  Monitoring on the number of IDocs, which are in status 03 for longer than 60 minutes. Those  IDocs are sometimes processed on an hourly basis. Therefore it makes sense to evaluate the  IDocs in status 03 if they have not been processed since longer than 60 minutes.  b.  Monitoring on the number of IDocs, which are in status 51 for longer than 30 minutes. This  way the alerts are suppressed for IDocs which are “temporarily” in error status 51 because  their status might be changed by the next processing retry. But if this is not the case after 30  minutes they are counted as IDocs in status 51. In field Days until now you can specify the age for IDocs in days which won’t be included into the evaluation.  The Monitoring Object is created in a development system and is then regularly transported into  the productive environment. Hence the Partner no. that is specified in the development system  already has to be the connected productive system which should be monitored later on. If the same interface should be monitored on the sending system as well as on the receiving system, it is necessary to create the respective monitoring objects on both these systems; one for the outbound direction and the other for the inbound direction. To be able to assign both monitoring objects to the same interface in the SAP Solution Manager they must have exactly the same names. To actually create the monitoring objects, then choose Monitoring Object / Start all in the entrance screen of transaction BDMO. This will create new entries in the CCMS (transaction /NRZ20) and start the data collection for the ALE/EDI alerts but just once. The scheduling of a periodic background job needs to be done on every satellite system in transaction /NRZ21 ® Technical infrastructure ®method execution ® activate background dispatching. This way the program RBDMONI_CCMS_IDOC is scheduled in the background job SAP_CCMS_MONI_BATCH_DP, per default on an hourly basis. Depending on your requirements you can change the frequency to enable a more real­time alerting.  Test the runtime of this program during peak time and evaluate the additional system load  generated before transporting to your productive system!© 2007 SAP AG  18 
  19. 19. Best Practice: ALE Monitoring  19After the program execution the created monitoring objects are generated in SAP CCMS:  Ar ea1  Ar ea 2  Ar ea 3Figure 1­15 ALE/EDI Specific Monitoring Objects Area 1: IDocs are generated via change pointers. Therefore the number of open change pointers is relevant for monitoring. Area 2: An IDoc changes its status during the message processing. In the SAP CCMS the main statuses are grouped together depending on the direction.  Ø  For outbound direction the following groups are available containing the listed statuses:  Ø  For inbound direction the following groups are available containing the listed statuses: Area 3: If the IDoc processing is done via tRFC you can monitor the number of remote calls waiting to be processed. The selection works for the RFC destination specified for the involved partner in the partner profile. To check the processing mode navigate to transaction WE20, select the partner number, select the message type and click on details. © 2007 SAP AG  19 
  20. 20. Best Practice: ALE Monitoring  20Figure 1­16 tRFC settings for ALE processing  Per default the threshold values for the SAP CCMS MTEs are usually set too high and need to be adjusted either directly within SAP CCMS or within the SAP Solution Manager. 1.4.1.3 Implement Specific ALE/EDI Monitoring in SAP Solution Manager The setup of interface monitoring will be done in the Setup Business Process Monitoring session. At least one business process with steps on different systems and defined interfaces must be available before it is possible to configure interface monitoring. In node Interface Monitoring all existing interfaces for the corresponding business process and the selected steps are displayed, such as, all pairs of consecutive business process steps on different systems. To customize the interface, the required interface must be selected for Monitoring. To differentiate between the interfaces, Interface Name (per default “<Sender SID>><Receiver SID>”, the Interface Technique (for example, ALE/EDI, qRFC), Initial Step (usually the business process step that sends information), Final Step (usually the business process step that receives information), Sender and Receiver (SID respectively) are displayed. The Interface Name and the Interface Technique can be changed manually.© 2007 SAP AG  20 
  21. 21. Best Practice: ALE Monitoring  21After saving the entries for every interface that is selected for monitoring a respective sub­node Interface “<Name of the Interface>“ (<Interface Technique>) will be created. Figure 1­17 Setup Interface Monitoring in SAP Solution Manager This sub­node is either used for loading Monitoring Objects from the connected local CCMS (for ALE/EDI, qRFC and tRFC this is described in the following sub­sections) or the sub­node is empty for all other Interface Techniques. 1.4.1.3.1  Implement ALE/EDI Interface Monitoring If an interface is selected for monitoring with the Interface Technique ALE or EDI, a sub­node appears: Interface “<Name of the Interface>“(<ALE or EDI>). It is now necessary to assign the previously created monitoring objects from the satellite system to the respective interface. This means that the objects must be loaded into the session. This happens with the push­button: Reload CCMS: ALE Mon Objects. All ALE/EDI monitoring objects available on the satellite systems (that is, Outbound­ objects on Sender side and Inbound­objects on Receiver side) are loaded into the session. This is not visible at first, but when the F4 value help is used for either SID or ALE Monitoring Object,  then all reloaded Monitoring Objects appear and can be selected for monitoring. Copy the selected objects and save. Figure 1­18 Use Value Help for ALE/EDI monitoring objects© 2007 SAP AG  21 
  22. 22. Best Practice: ALE Monitoring  22A new sub node, Alert Monitors, appears. All Outbound alerts for the Sender system and all Inbound alerts for the Receiver system, relating to the Monitoring Objects selected in the node above, are loaded into the session. Additionally, all the corresponding threshold values are loaded from the local CCMS. The next step is to decide what kind of alert should be selected for monitoring. To transfer the threshold values for a single line from right to left, double­click the copy icon between them. To transfer all the threshold values at once, select "Copy All". It is also possible to change the threshold values for the alerts manually. When saved, the new values are transferred to the local CCMS of the monitored system. Figure 1­19 Selection of ALE/EDI related alerts© 2007 SAP AG  22 
  23. 23. Best Practice: ALE Monitoring  232 Aspect: Error Monitoring From the previous sections, you know the general ALE processing mechanism and how to setup selective and automated IDoc monitoring within Business Process Monitoring in the SAP Solution Manager. The next sections will deal with individual aspects of interface monitoring. Error monitoring is intended to detect critical situations and exceptional cases during interface processing. As these incidents can endanger the entire data flow between the involved systems, their identification can be extremely important and time critical. Monitoring procedures should, therefore, ensure a clear visualization and prioritization of incidents to support their fast and effective resolution. Error Monitoring includes the monitoring of all error situations documented within the system. Error situations can be identified by the occurrence of error messages or error statuses. Each step in the processing of the IDoc has a different status number. All IDocs start with status 01 (IDoc generated) in Outbound, and the numbers from 01 to 49 are reserved for Outbound status (50­99 are Inbound status). The various error statuses which can occur for outbound and inbound IDocs and which should be monitored on a daily basis, are detailed below: Possible error statuses for Outbound IDocs  Code  Description  02  Error passing data to port  04  Error within control information of EDI subsystem  05  Error during translation  07  Error during syntax check  09  Error during interchange handling  11  Error during Dispatch  15  Interchange Acknowledgement negative  20  Error triggering EDI subsystem  21  Error passing data for test  23  Error during retransmission  25  Processing despite syntax error (outbound)  26  Error during syntax check of IDoc (outbound)  27  Error in dispatch level (ALE service)  29  Error in ALE Service  30  IDoc ready for dispatch (ALE service)  31  Error ­ no further processing  34  Error in control record of IDoc  36  Electronic signature not performed (timeout)  37  IDoc added incorrectly  40  Application Document not created in receiving system Possible error statuses for Inbound IDocs  Code  Description  51  Error: Application document not posted  52  Application document not fully posted  54  Error during formal application check  56  IDoc with errors added  57  Test IDoc: Error during application check  60  Error during syntax check of IDoc (inbound)© 2007 SAP AG  23 
  24. 24. Best Practice: ALE Monitoring  24 61  Processing despite syntax error (inbound)  63  Error passing IDoc to application  65  Error in ALE service  68  Error ­ no further processing Monitoring Requirements: In a typical solution landscape, multiple systems and different interface technology are utilized. There are various tools for monitoring and problem analysis. The figure below shows the various technologies and the SAP tools we can use to monitor ALE/EDI scenarios in a solution landscape manually: Figure 2­1 Standard ALE processing error monitors Monitoring Objects: The figure below shows how data is distributed using ALE. Errors can occur at any of the 5 steps, so these steps represent our monitoring objects, that is: · Application creates IDoc + passes it to the ALE layer (Application layer (sender system)) · Outbound processing in the ALE layer (ALE layer (Sender system)) · IDoc sent to the receiving system in the communication layer (Communication layer)) · Inbound processing in the ALE layer (ALE layer (receiver system)) · IDoc passed to the Application (Application layer (receiver system))© 2007 SAP AG  24 
  25. 25. Best Practice: ALE Monitoring  25Figure 2­2 ALE layers 2.1 Manual Error Monitoring As in the above description, the following table documents the handling of errors at the five processing statuses. Monitoring Objects w/o SAP Solution Manager Monitoring  Monitor  Monit.  Indicator  Monitoring Activity or  Respon­  Escalation Object  TA/Tool  Freq.  or Error  Error Handling  sibility  Procedure  Procedure Check if IDocs  BD87  As  IDoc in  Use BD87: enter  Business  Application were created  required  error or no  correct date/time frame  Process  Management successfully  by IDoc  and logical message  Operations  Team / by ‘Application  business  created  type. Double click on  Team /  Business Layer’ (sender  various statuses to get  SAP  Process system)  a list of IDocs. If IDoc is  Technology  Champion  found in failed status,  Operations  review status text for  Team  reason for failure. If  IDoc is not found,  check if interface is  configured to collect  and, if so, check if  background job is  running. IDocs in status  BD87  As  Existence  Call transaction  Business  Application “Error in  required  of the  BD87on receiving  Process  Management Application  by following  system. Choose  Operations  Team / Layer”  business  statuses:  timeframe and various  Team /  Business (receiver  51, 52, 54,  selection criteria. A list  SAP  Process system)  57,  of IDocs will be  Technology  Champion displayed for various  Operations  message types. It is  Team  possible to drill down to  display the IDoc and its  status records (by  double clicking).  For IDocs in status 51  BD87 will state whether  an application log exists  for the IDoc. If this is  the case you can drill  down to display the © 2007 SAP AG  25 
  26. 26. Best Practice: ALE Monitoring  26 IDoc. If you double­click  on the IDoc status  record, an application  log pushbutton  becomes available in  the status record  display. If no button is  available, it means that  a detailed log is not  available. It may be  possible, however, to  get some information  using transaction  SLG1. You can specify  <*IDOC NUMBER*> in  field “External ID”. IDocs in status  BD87  As  Existence  Call transaction  Business  Application “Error in ALE  required  of the  BD87on sender  Process  Management layer ” (sender  by following  system. Choose  Operations  Team / system)  business  statuses:  timeframe and various  Team /  Business  02, 21, 26,  selection criteria. A list  SAP  Process  27, 29, 34,  of IDocs will be  Technology  Champion  37  displayed for various  Operations  message types. It is  Team  possible to drill down to  display the IDoc and its  status records (by  double clicking).  Analyze reason  accordingly. IDocs in status  BD87  As  Existence  Call transaction  Business  Application “Error in ALE  required  of the  BD87on receiver  Process  Management layer ”  by following  system. A list of IDocs  Operations  Team / (receiver  business  statuses:  will be displayed for  Team /  Business system)  56, 60, 63 ,  various message types.  SAP  Process  65,  It is possible to drill  Technology  Champion  down to display the  Operations  IDoc and its status  Team  records (by double  clicking).  Analyze  reason accordingly IDocs stuck in  SM58/BD  As  BD87  In BD87, choose  Business  Application commun­  87  required  shows  timeframe and check  Process  Management ication layer ”  by IDocs in  for IDocs in status 03. If  Operations  Team /  business  status 03  there are IDocs in  Team /  Business  status 03, ensure report  SAP  Process  SM58  RBDMOIND  Technology  Champion shows  Is running. If report is  Operations  tRFCs in  running check  Team  error status  transaction SM58 as  below.  In SM58, choose  timeframe to see a list  of tRFCs with errors.  Double­click to get  more details for each  tRFC. © 2007 SAP AG  26 
  27. 27. Best Practice: ALE Monitoring  27Error in  BD87  As  Existence  Choose timeframe and  Business  Application external  required  of following  various selection  Process  Management system  by statuses  criteria on the sender  Operations  Team /  business  04, 05, 07,  system and analyze the  Team /  Business  08, 09, 11,  reasons in BD87.  SAP  Process  15, 17, 23,  Technology  Champion  36, 40  Operations  Team Inbound IDocs  WE08  As  Was the  Transaction WE08 ­>  Business  Application from flat file  required  file  double click on  Process  Management  by processed  directory check date of  Operations  Team /  business  recently for  last processing and last  Team /  Business  directory  IDoc/record number. If  SAP  Process  correspond  IDoc was not  Technology  Champion  ing to  processed recently, test  Operations  active EDI  access to specified  Team  scenario? If  directory using  not, there  transaction WE21 ­>  is a  choose file port and  problem.  perform an access test.  In addition check for  errors in BD87. Workflow  SWI2_DI  As  If listed  Call Transaction  Business  Application triggered by  AG  required  workitem it  SWI2_DIAG. Choose  Process  Management Inbound IDocs  by is in error  timeframe and various  Operations  Team /  business  selection criteria. A list  Team /  Business  of workflows will be  SAP  Process  displayed in error  Technology  Champion  status.  Operations  Double click on  Team  individual work items to  find out why they failed IDocs with  WE07  As  IDocs with  Call transaction WE07.  Business  Application errors  required  errors  Choose timeframe and  Process  Management  by various selection  Operations  Team /  business  criteria to display a list  Team /  Business  of IDocs with errors.  SAP  Process  Double click to drill  Technology  Champion  down to display IDoc  Operations  and status records.  Team IDoc  SM37  Once  Jobs with  Validate using  Business  Application background  daily  errors  transaction SM37 that  Process  Management jobs  the various ALE/EDI  Operations  Team /  background jobs are  Team /  Business  scheduled and are  SAP  Process  running successfully as  Technology  Champion listed below (this should  Operations  be done at least once a  Team  day). © 2007 SAP AG  27 
  28. 28. Best Practice: ALE Monitoring  282.2 Automated Error Monitoring For details on how to setup the automated error monitoring, refer to the section Interface Monitoring in SAP CCMS and SAP Solution Manager. Automated Monitoring Objects with SAP Solution Manager Monitoring  Monitor  Monit  Indicator or  Monitoring  Respon­  Escalation Object  TA/Tool  Freq.  Error  Activity or  sibility  Procedure  Error  Handling  Procedure Outbound  SAP CCMS  Hourly  IDocs in this  Analyze the  Business  Application IDocs in  / SAP  status  reasons in  Process  Management status “Error  Solution  BD87  Operations  Team / in IDoc  Manager  Team /  Business interface”  SAP  Process (statuses: 02,  Technology  Champion 20, 21, 26,  Operations 27, 29, 34,  Team 37) Outbound  SAP CCMS  Hourly  IDocs in this  Analyze the  Business  Application IDocs in  / SAP  status  reasons in  Process  Management status “Error  Solution  BD87  Operations  Team / in external  Manager  Team /  Business system”  SAP  Process (statuses: 04,  Technology  Champion 05, 07, 08,  Operations 09, 11, 15,  Team 17, 23, 36, 40) Inbound  SAP CCMS  Hourly  IDocs in this  Analyze the  Business  Application IDocs in  / SAP  status  reasons in  Process  Management status “Error  Solution  BD87  Operations  Team / in  Manager  Team /  Business application”  SAP  Process (statuses: 51,  Technology  Champion 54, 57)  Operations  Team Inbound  SAP CCMS  Hourly  IDocs in this  Analyze the  Business  Application IDocs in  / SAP  status  reasons in  Process  Management status “Error  Solution  BD87  Operations  Team / in IDoc  Manager  Team /  Business Interface”  SAP  Process (statuses: 56,  Technology  Champion 60, 63, 65)  Operations  Team Background  SAP  As  Cancellations,  Analyze the  Business  Application jobs for IDoc  Solution  needed  Maximum  reason in  Process  Management processing  Manager  duration  SM37  Operations  Team / listed above  Team /  Business  SAP  Process  Technology  Champion  Operations  Team IDoc  SAP  As  Error  Analyze the  Business  Application processing  Workflow  needed  situations (by  reasons in  Process  Management monitoring  status)  BD87  Operations  Team / using SAP  Team /  Business workflow  SAP  Process© 2007 SAP AG  28 
  29. 29. Best Practice: ALE Monitoring  29(refer to SAP  Technology  Champion note 116610)  Operations  Team Update  SAP  Hourly  Update errors  Analyze the  Business  Application errors for  Solution  V1 / V2  reasons in  Process  Management transactions  Manager  SM13  Operations  Team / or programs  Team  Business  Process  Champion tRFC errors  SAP CCMS /  Hourly  Too many  SM58  Business  Application (refer to  SAP  remote calls  Process  Management figure  Solution  waiting  Operations  Team / ALE/EDI  Manager  Team /  Business Specific  SAP  Process Monitoring  Technology  Champion Objects)  Operations  Team 2.3 Details on IDoc Batch Job Monitoring Confirm that the below background jobs are scheduled and are running successfully, using transaction SM37. Monitoring should include an assessment of: · Occurrence of failed/cancelled jobs: The job logs should be investigated to determine what  caused the error. Further information about the cause of the failure may be available in the  system log transaction SM21. · Job runtime: This depends on many factors (Functionality/activity of the job, hardware, system  resources etc). Therefore, we cannot give exact statements about performance indicators. If a  background job is deemed to be running long, investigate using the job log. It is also possible  to perform an ABAP or SQL trace using transaction ST12 see  Section 7 of this document. Typical Inbound jobs run programs:  1.  RBDAPP01 (posts IDocs)  2.  RBDMANI2 (posts status 51 IDocs) Typical Outbound jobs run programs  3.  RSNAST00 – WE15 (If using message control, you can check via partner profile  WE20). Also, validate message control is set up properly via NACE. (Creates IDocs)  4.  RSEOUT00 (sends IDocs – we14)  5.  RSARFCEX (clears IDocs out of ALE/RFC layer)  6.  RBDMOIND (changes IDoc from status 03 to 12)  7.  RBDMIDOC (Change Pointers, can check via BD50)© 2007 SAP AG  29 
  30. 30. Best Practice: ALE Monitoring  302.4 Handling different error statuses ALE/EDI There are instructions below on issue resolution for the most important error statuses. 2.4.1 Status 02: Error passing data to port Common causes of error: · Access to the file system does not work, because a user has insufficient authorization to  relevant directory to write a file. · Directory might not exist · File System full. Analysis steps/Solution: Start by checking access to the outbound directory from each application server (WE21). If there is a problem with a specific application server, then the connection from this server to the outbound directory should be checked. Check if the directory exists and there is enough space left in the file system. Ensure that the user has at least assigned authorization object S_DATASET, see also SAP notes 334097 and 90111. 2.4.2 Status 03: Status 03 signifies that an IDoc in the sending system has been passed to tRFC, but it has not yet been input in the receiving system, this means that the tRFC call has not yet been executed. Common causes of error: · Report RBDMOIND not scheduled · tRFC call has failed · No ‘Commit Work’ statement has been issued in the application program which creates the  IDoc. Analysis steps/solution: The report RBDMOIND is responsible for the status change from 03 to 12: If an IDoc has been passed to tRFC (IDoc status 03), but has not yet been transferred to the receiving system.  If the report is running, but you still see a large number of IDocs in status 03 then proceed as follows: Call SM58 to analyze the problem in more detail. You should test the RFC connection. Maybe the network is down, or the receiving system does not have any dialog work processes available or there are other resource issues. If necessary, the Gateway developer trace needs to be reviewed and/or a RFC trace needs to be created and analyzed. To do so, use the transaction SM59, (See the note 532918 for more details). If this does not solve the problem, debug the application program that creates the IDoc. 2.4.3 Status 26: Error during syntax check of IDoc (outbound) Common causes of error: IDOC configuration is not correct; this should not happen in a productive system. Processing discontinued only if  “Cancel Processing After Syntax Error‘ is flagged in WE20 (Partner Profiles). The following checks are performed: · Mandatory segment is missing · Sequence of segments in a group in which the segment appears is incorrect · More segments exist in a segment group for the IDoc as defined for the basic IDoc type© 2007 SAP AG  30 
  31. 31. Best Practice: ALE Monitoring  31Analysis steps/solution: · Check IDoc error status using transaction WE02/WE05 · Review IDoc structure using transaction ‘WE30’ · If necessary, debug the application transaction to the function IDOC_OUTPUT_<message  type> (in case of MC) or MASTERIDOC_CREATE_<message type>) (in case of direct  outbound processing). 2.4.4 Statuses 27, 29, 37: IDOC processing towards tRFC layer  has problems IDOC processing towards tRFC layer has problems. Common causes of error: · No relevant entry in partner profile · Receiver fields in IDoc header are not filled correctly Analysis steps/Solution: · Check IDoc error status using transaction WE02/WE05 · Review Partner Profile (WE20) and distribution model (BD64) · Check content of IDoc receiver fields in IDoc header · Debug the application program 2.4.5 Status 51: Application document not posted IDoc could not be posted. Common causes of error: · Problems within Application Customizing · Incorrect IDoc data · Programming errors Analysis steps/Solution: · Check IDoc error status using transaction BD87/WE02/ WE05 · Check Application log: For IDocs in status 51, transaction BD87 will state whether an  application log exists for the IDoc. If this is the case, you can drill down to display the IDoc.  When you double­click on the IDoc status record, an “application log pushbutton” becomes  available in the status record display. If no button is available it means that a detailed  log is not available. It may be possible, however, to get some information using  transaction SLG1 you can specify <*IDOC NUMBER*> in field “External ID”. · Debug the application, by setting a breakpoint in the relevant IDoc inbound function module  (WE20) · If IDocs are in status 51, you can try to reprocess the IDocs:  o  Automatic re­processing RBDMANI2: You can use the report RBDMANI2 to resubmit  the IDoc. The program can also be scheduled as a periodic job, to collect IDocs that  could not be posted because of a lock problem. This does not relieve you of  monitoring the IDocs to make sure that no other errors are present.  o  Resending IDoc: Check if the error can be resolved by changing the business­related  objects. If this is possible, you can reprocess the IDoc. If the error cannot be  corrected, then a new IDoc has to be created and the “old” IDoc has to marked for  deletion.  o  Manually edit IDoc: Check if you can manually correct the IDoc. Keep in mind that  some IDocs must not be changed according to local laws. When this is done, you can© 2007 SAP AG  31 
  32. 32. Best Practice: ALE Monitoring  32 reprocess the IDoc. You will find more information below on reprocessing IDocs in  status 51. 2.4.6 Status 56: IDoc with errors added [anything missing?]  Status 63: Error passing IDoc to application Common causes of error: · Missing Inbound Partner Profile or inbound parameters are not defined in the inbound partner  profile. · IDoc contains characters that are not compatible with internal character set · Error in ALE service Analysis steps/Solution: · Check status error message in transaction BD87 or WE02/WE05 · Add or change Inbound Partner profile · Create conversion rule · Automatic re­processing using report RBDAGAI2 2.4.7 Status 60: Error during syntax check of IDoc (inbound) Processing is discontinued, only if “Cancel Processing After Syntax Error” is flagged in partner profile (transaction WE20). Common causes of error: · Mandatory segment is missing · Sequence of segments in a group in which the segment appears is incorrect · More segments exist in a segment group for the IDoc as defined for the basic IDoc type Analysis steps/Solution: · Check IDoc error status using transaction BD87 or WE02/WE05 · Review IDoc structure using transaction ‘WE30’ · In the case of EDI, analyze the structure of the IDoc file and check how the sender system fills  the parameters IDOC_CONTROL_REC_40 and IDOC_DATA_REC_40 of function module  ‘IDOC_INBOUND_ASYNCHRONOUS’ · Automatic re­processing using RBDSYNEI 2.4.8 Status 65: Error in ALE service Common causes of error: Filtering does not work Analysis steps/Solution: · Check IDoc error status using transaction BD87 or WE02/WE05 · Review ALE customizing using transaction ‘SALE’ · Automatic re­processing using RBDAGAI2© 2007 SAP AG  32 
  33. 33. Best Practice: ALE Monitoring  332.4.9 Reposting of IDocs in Status  Error  Figure 2­3 Transaction BD87 In the status monitor (BD87), you can choose a particular IDoc to try to reprocess it. If you right­click, you can choose between Process or Restrict and process. If you choose process, you restart the processing of the IDoc(s). If you choose, Restrict and process, you have to make a few more choices, as shown in the figure below. Figure 2­4 BD87 ­ Manual IDoc processing You can further restrict the IDocs you wish to process in this screen. Use the execute button at the top to begin processing. If Bkgd processing is unchecked, you can see the window below. This choice gives you more options to process the IDoc. Process starts the processing of the selected IDoc(s). Delete flag sets the IDoc status to 68, meaning that the IDoc has an error and does not need to be processed again, but can be archived or deleted. IDoc display shows you the payload of the IDoc. ALE/EDI Interface Management.© 2007 SAP AG  33 
  34. 34. Best Practice: ALE Monitoring  34Figure 2­5 BD87 ­ Display Status Records If you click IDoc display, you will see the current information on the IDoc. To display the errors in the IDoc, click the Segments with errors button. The next figure shows you a sample error. Figure 2­6 BD87 – Display Status Records Figure 2­7 BD87 – Display Data Records Analyze the error situation. Check if the error can be resolved by changes in the business­related objects so that the IDoc can be reprocessed correctly. If this is not possible, you need to decide what the next steps are: • Either resend corrected data from the sending system and then mark the IDoc for deletion or© 2007 SAP AG  34 

×