Purpose
Application Link Enabling provides a range of administration tools:
- Monitoring of IDoc processing and tRFC communication
- Transport of Customizing data from maintenance systems to receiving systems
- Optimization of ALE performance
- Serialization of messages
You can find the administration functions under ALE Administration. Information about optimizing the performance of ALE often refers to settings in R/3 Customizing. You can find ALE Customizing under Basis ? Distribution (ALE)
Monitoring Message Exchange
The ALE layer processes the outbound IDoc and controls its dispatch. Depending on the partner profile settings in Customizing for ALE, IDocs can be transferred in the following ways:
IDocs assigned to the same partner and message type are collected and the RSEOUT00 program later forwards them to the communication layer.
To do this, in ALE Customizing (Transaction SALE) choose:
Set-Up System Monitoring
IDoc Processing
Schedule Collected IDoc Transmission (SM36)
You can also send the collected IDocs to the communication level manually, in the ALE Administration under Monitoring ®IDoc Display ® Status Monitor. The IDoc is forwarded to the communication layer immediately.
Central Monitoring Using the ALE CCMS Monitor
The alert monitor gives you an overview of the following R/3 System performance attributes which are important for ALE: ? IDoc change pointers
1. Processing of outbound IDocs
2. tRFC queue
3. Processing of inbound IDocs
You can monitor any number of R/3 Systems from any one system. The number of systems that can be monitored is, however, restricted by technical factors, such as the speed of the network and the level of traffic in the network. In ALE Administration choose: Monitoring ? ALE Monitor in CCMS.
Status Monitor for ALE Messages
With the status monitor you can monitor the processing status of IDocs in ALE inbound and outbound processing and you can process IDocs manually. Choose Tools ? ALE ? Administration ? Monitoring ? Status Monitor for ALE Messages.
Displaying the IDoc List
Choose Display IDocs to display a list of the associated IDocs for each main entry or sub-entry . You can use WE02/WE05 to display the IDOCs.
Determining Status in Receiving System
You can determine the status of the IDocs in the receiving system (inbound processing) using ALE Audit and IDoc Tracing . You can use the transaction BDM7/BDM8. Programs RBDAUD01 and RBDAUD02 can also be used for Statistical analyses for the ALE Audit. Confirmations can only be dispatched, if you have defined a message flow for message type ALEAUD in the distribution model. Basis ? Application Link Enabling (ALE) ? System Monitoring ? IDoc Confirmation in Receiver System (ALE Audit) ? Distribution Model for ALE Audit. In the receiver system you have to make the settings for periodic confirmations. You can also send confirmations directly.
When confirmations are sent (program RBDSTATE), IDocs of message type ALEAUD are generated containing information about the processing state of inbound IDocs. An audit IDoc contains confirmations for up to 500 IDocs. If there are more IDocs to be confirmed, several audit IDocs are generated. A list of the generated IDocs is displayed. If an IDoc cannot be generated or an error occurs, a message is displayed.
IDocs whose statuses have recently changed are selected. Because almost every IDoc activity (e.g. creation, successful posting/ unsuccessful posting in an application) alters the status of the IDoc, it is precisely these IDocs which have in some way or other been processed.
Tracing IDocs System-Wide
In the status monitor you can trace IDocs system-wide to determine the processing status in the receiving system of IDocs with status 3 and 12. Select a status text or a message type / object method and select Trace IDocs. A status overview of IDoc pairs in the sending and receiving systems appears.
Synchronizing Customizing Data Between Systems
In ALE Administration you can synchronize Customizing data of Customizing objects between systems. Customizing objects are assigned to distribution groups and transported to the participating systems in transport requests. You have to define distribution groups in Customizing for ALE. To synchronize Customizing data you have to execute the functions below in both the sending and the receiving systems: Choose Tools ? ALE ? Services ? Customizing Data ? ALE Requests:
In the sending system:
- Display outbound ALE Requests :Under Display outbound requests you can display the status details of ALE transport requests for a specified time period for each distribution group and target system. - Generate ALE requests :Under Generate using the selection options and parameters you can generate ALE transport requests and IDocs that notify the receiving systems.
Note on field CTS dummy system The CTS requires information on the target system, even though in this ALE case, this information is not used because ALE controls the distribution through the info-IDoc itself. Enter an "empty pseudo system" to which usually no transports are made.
In the receiving system:
-Display inbound ALE requests *:*In Display inbound requests you can display the ALE requests and their import status for a specified time period for each distribution group and source system. -Import ALE requests :Under Import you can transport source requests for a specified time period for each distribution group.
-- Consolidate and forward ALE requests :Under Consolidate you can create a consolidation request from several ALE requests. The consolidation request is used to transport Customizing data imported by ALE requests into quality and production systems.
You can only execute this function in Customizing Systems in which Customizing data has been imported by ALE transports. The function generates a standard Customizing request that has not been released. The user of the function is also the owner of the consolidation request.
Optimizing ALE Performance
IDocs are fundamental to Application Link Enabling. Optimal system performance in ALE processing is synonymous with optimal performance of IDocs.
In ALE processing IDocs are:
1.Created in the R/3 sending system
2.Transferred to the communication layer in the R/3 sending system
3.Used when R/3 sending and receiving systems communicate
4.Processed in the receiver system
You can optimize IDoc processing in one or more of the following ways:
Controlling IDoc Events
BD21 and BD22 are used to select and delete the change pointers. BD50 is used to activate the change pointers for a message type. BD61 is used to activate the general change pointers.Program RBDMIDOC is used to generate the IDOCs based on the change pointers.
Background posting of IDOC posting can be set up by the program RBDAPP01 later releases the saved IDocs for processing. Single IDocs can be put into packets and then processed.
Processing IDocs in Parallel:
Several IDocs can be processed at the same time in different dialog processes. This is particularly advantageous for sending mass data. IDocs can only be created in parallel in different dialog processes, if master data is sent directly. In contrast, the program RBDMIDOC to process change pointers uses only one dialog process. There are no benefits of creating IDocs in parallel for distributing transaction data in ALE, because this mainly involves single events which cannot be accelerated by running dialog processes at the same time. IDoc communication with transactional RFC (tRFC) uses all available dialog processes on the application server that transfers the IDocs to the communication layer. With tRFC parallel communication, it does not matter whether IDocs are first collected or transferred immediately.
Posting IDocs in Parallel ::This is used for:
1. Immediate processing : When IDocs are processed immediately, all dialog processes on the receiving application system are used for posting. This could block the application server. You cannot distribute inbound IDoc packets among one server group. An IDoc packet may consist of one or more IDocs. A dialog process to execute the posting function module is started on the application server for every IDoc packet. If the IDoc packet consists of several IDocs, and if the posting function module is not capable of mass processing, the ALE layer calls the function module several times in the same dialog process and each time transfers a single IDoc for processing.
2. Background processing :Inbound IDoc packets are split into individual IDocs and are stored in the database. You can process IDocs that are ready for transfer (status 64) manually in ALE Administration (IDocs ? Monitoring ? Process IDocs manually). Alternatively, IDocs can be processed in the background. To do this, in ALE Customizing choose: Modeling and Implementing Business Processes Partner Profiles and Time of Processing Scheduling IDoc Processing in Receiving System All 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. If you do not specify a server group, all dialog processes in the local server are used in parallel. This could block the application server. IMPORTANT : For mass data it is better to process IDocs in parallel. You must select the option Parallel posting on the screen Inbound processing of IDocs ready for transfer in the program RBDAPP01. Specify a server group for parallel updating on several applications. Because two dialog processes remain unused on every application server in a server group, make sure there are enough dialog processes available on the application servers.
Processing IDocs in Packets
Packet processing enables one program or one function module to process batches of data of the same type. This reduces the number of dialog processes called and improves system performance.
You can use packet processing in ALE for:
Creating IDoc Packets:
If you send master data directly, a function module creates an IDoc for each master data object, for example, material. In most cases more than one master data object can be passed to the function modules for IDoc creation.
If you send master data directly, you can send more master data objects in each process. As a guide you can send between 20 and 100 objects.
This reduces the number of dialog processes used and the administrative load on the R/3 System.
Packet processing and parallelism complement each other, although in some situations they may compete with each other. If there are too many master data objects in each process, possibly not all available dialog processes will be used.
Sending IDoc Packets:
Several IDocs can be grouped into a packet and sent in one transactional Remote Function Call (tRFC). This has the following benefits:
1.The fewer administrative tasks reduce the load on the system
2.tRFC uses less dialog processes in the sending R/3 System
3.tRFC uses less dialog processes in the receiving R/3 System
You can specify the packet size of message types in Customizing for ALE. Modeling and Implementing Business Processes Partner Profiles and Time of Processing Generate Partner Profiles
As a guide, packet size should be between 10 and 200 IDocs. The smaller the IDocs are, the larger the packet size can be. For message types which contain large volumes of data, for example, GLROLL or ALEAUD, the packet size should be between 1 and 10 IDocs.
If the IDocs are not going to be posted immediately in the receiving R/3 System, an IDoc packet can contain up to about 10000 data records. For example, if each IDoc contains 10 data records, a packet can contain up to 1000 IDocs.
Posting IDoc Packets :
Two groups of function modules are used to post IDocs:
1.Function modules which process IDocs in mass. These transfer packets of IDocs whose individual IDocs are updated in the same Logical Unit of Work (LUW).
2. Function modules which process one IDoc per call.
3.INPUTTYP contains the code for posting function modules.
To display the function module's INPUTTYP, on the ALE Development screen, choose IDoc ? Inbound ? Function module attributes.
INPUTTYP can contain the following values:
1. "0", for function modules which process IDocs in packets.
"1" and "2" for function modules which process one IDoc per call.
If you post the IDocs immediately, the R/3 sending system determines the packet size. ALE inbound processing can recognize if the posting function module allows packet processing and if so, passes the IDoc packet to it. If not, the IDoc packet is split into individual IDocs.
If IDocs are posted in the background, you can specify the size of the IDocs to be generated in the program RBDAPP01.
Administration of IDoc Communication
IDoc communication is based on transactional Remote Function Call (tRFC).
You can optimize the performance of ALE processing by using the following settings and procedures.
1. Suppressing Background Processing
2. Setting Dispatch Status to OK
3. Checking the tRFC Status
Suppressing Background Processing
In the standard R/3 System, if tRFC errors occur, a background job is generated to re-establish the connection. In certain circumstances this could result in a large number of background jobs being started that completely block background processing.
To cancel a background job if tRFC errors occur use program RSARFCEX to restart tRFC.
In ALE Customizing select a connection to change: Sending and Receiving Systems Systems in Network Define Target Systems for RFC Calls
Then choose Destination ? tRFC options and select Suppress background job if connection error. Alternatively from the R/3 initial screen by choosing Tools ? Administration, then Administration? Network ? RFC Destinations.
Setting Dispatch Status to Dispatch OK
When an IDoc is passed to the communication layer, it is assigned a globally unique transaction identifier (TID). If the IDoc has been successfully dispatched, this information is not automatically passed to the ALE communication layer. So that ALE processing sets the IDoc status to Dispatch OK, you should compare the TID numbers in the communication layer and the ALE layer.
The program RBDMOIND checks that the IDocs passed to the transactional RFC have already been sent to the receiving R/3 System. If they have been sent, the IDoc status is changed to "12" - Dispatch OK.
To set the IDoc dispatch status, run the program RBDOIND after the IDocs have been passed to the communication layer.
Check the tRFC Status
To check the status of tRFC calls select Tools ? ALE ? Administration ? Services ? Communication ? Transactional RFC ? Display incorrect calls. tRFC calls that connect IDocs use the function module INBOUND_IDOC_PROCESS in the receiving system. INBOUND_IDOC_PROCESS).
If an IDoc in the sending system has been passed to tRFC (IDoc status "03"), but has not yet been input in the receiving system, this means that the tRFC call has not yet been executed.
The program RSARFCEX restarts unsuccessful tRFC calls.
You cannot choose the option is being executed in background processing.
Serialization of Messages
Use
Serialization plays an important role in distributing interdependent objects, especially when master data is being distributed.
IDocs can be created, sent and posted in a specified order by distributing message types serially.
Errors can then be avoided when processing inbound IDocs.
Features
Interdependent messages can be serially distributed in the following ways:
1. Serialization by Object Type
2. Serialization by Message Type
3.Serialization at IDoc Level (not for IDocs from generated BAPI-ALE interfaces)
Serialization by Object Type
Use
Serialized messages can be of different types (for example, create, change or cancel messages). All messages here relate to one special application object.
The messages can contain both master data and transaction data.
With object serialization the messages a given object are always processed in the correct order on the receiver system. The order messages are posted in on the receiver system is the same as they were created on the sender system.
Prerequisites
You have to activate serialized distribution in both systems in ALE Customizing:
Tools >AcceleratedSAP > Customizing > Project ManagementSAP Reference IMG>Basis Components> Distribution (ALE) >Modeling and Implementing Business Processes> Master Data Distribution> Serialization for Sending and Receiving Data >Serialization by Object Type
Features
Object type serialization is carried out using object channels.
All messages are processed in an object channel in the target system in the same order they were sent from the source system. An object channel contains a number of ordered IDocs and is defined by an object type (BOR) and precisely one channel number. A channel number is a message attribute. It is generated by the function module ALE_SERIAL_KEY2CHANNEL.
All messages with the same channel number and object type are serialized when the messages are processed.
The current number of each object channel is recorded. This process is takes place in what is known as the registry. There is an outbound registry and an inbound registry. Serialization must be activated in both registries (see prerequisites).
Outbound Processing (Source System)
When outbound IDocs are processed, for each object channel (field CHNUM) a unique serial number is assigned to each IDoc created (field CHCOU). This number and the object channel are transferred with the IDoc in the SERIAL field.
An unique serial number is assigned to each message for the application object in question.
Inbound Processing (Target System)
When inbound IDocs are processed, a unique serial number is generated for each object channel (field CHNUM) and communication link. The ALE layer determines whether a given IDoc can now be posted or whether other IDocs have to be posted first. The serial number for each received IDoc is exactly one whole number lower. Any gaps in the sequence will mean that IDocs are missing, either because the transfer did not work, or because earlier IDocs were not posted successfully.
In this case the IDoc is assigned status 66 and must be posted again with the program RBDAPP01.
Objects are assigned to messages and channels by the application.
Transfer errors (IDoc sequence mixed up) and inbound posting errors (IDoc cannot be posted due to Customizing errors) no longer affect the sequential order, because serialization corrects these errors.
Serialization By Message Type
Use
IDocs can be created, sent and posted in a specified order by distributing message types serially.
Object interdependency is important at the message type level.
Consider a purchasing info record with a vendor and a material. To avoid any processing errors, the vendor and material must be created in the receiving system before the purchasing info record.
Prerequisites
You have to activate serialized distribution of message types in both systems in ALE Customizing (Transaction SALE).
Basis Components >Distribution (ALE) >Modeling and Implementing Business Processes >Master Data Distribution> Serialization for Sending and Receiving Data> Serialization by Message Type
Features
Serialized distribution is only used to transfer changes to master data. IDoc message types are assigned to serialization groups according to the order specified for their transfer. Master data is distributed in exactly the same order. If all the IDocs belonging to the same serialization group are dispatched successfully, the sending system sends a special control message to the receiving system. This control message contains the order IDocs are to be processed in and starts inbound processing in the receiving systems.
Serialized distribution of message types is not a completely new way of distributing master data; it uses existing ALE distribution mechanisms whilst adhering to a specified order of message type. This distribution could also be carried out manually using existing ALE programs. However, serialized distribution automates the single steps and can schedule them in a batch job.
In the serialization menu selection criteria determine how certain parts of the serialized distribution will be processed, for example, control message dispatch and inbound processing.
Serialization at IDoc Level
Use
Delays in transferring IDocs may result in an IDoc containing data belonging to a specific object arriving at its destination before an "older" IDoc that contains different data belonging to the same object. Applications can use the ALE Serialization API to specify the order IDocs of the same message type are processed in and to prevent old IDocs from being posted if processing is repeated.
SAP recommends that you regularly schedule program RBDSRCLR to clean up table BDSER (old time stamp).
Prerequisites
IDocs generated by BAPI interfaces cannot be serialized at IDoc level because the function module for inbound processing does not use the ALE Serialization API.
Features
ALE provides two function modules to serialize IDocs which the posting function module has to invoke:
1.IDOC_SERIALIZATION_CHECK to check the time stamps in the serialization field of the IDoc header.
2.IDOC_SERIAL_POST updates the serialization table.
ALE Recovery for Data Consistency
Use
In distributed environments you can also recover an R/3 System following a system failure caused by a database error. Using backup and point-in-time recovery, you can reset the database to the status at the time the system failed and continue working with it.
In this case, transactions may still have taken place after the time the system is reset to, which are subsequently lost and have to be carried out again. External interactions (for example, ALE, EDI, mail, fax, telex), possibly carried out under a different key, are duplicated and require special processing.
For example, if, a process sent a message to another system and started another process here during the time between when the error occurred and when it was discovered on the recovered system, the data related to this process will no longer exist on the recovered system. The results of the second process carried out on the receiving system still exist in this system. The inconsistent data in the two systems can be put right by canceling the data resulting from the communication in the receiving system.
In the case of such point-in-time recoveries, certain documents must be canceled in the communication partners' systems and messages sent earlier from the receiving system must be sent again. You have to determine all the actions that need to be carried out in the recovery process.
You can use ALE recovery tools for this.
ALE recovery tools can also be used for data exchanged with non-SAP systems.
Prerequisites
To recover a system, the following is required:
? Database that allows a point-in-time recovery
? Continuous database backup
? The database of the recovered system has already been restarted at the status before the error occurred
Features
ALE Recovery tools perform the required analyses and help you carry out the necessary tasks.
1. The recovered system prompts its communication partners to provide details of the IDocs exchanged between the systems during the time affected.
2. The communication partners of the recovered system report back this information.
3. The information reported back is compared to the information in the recovered system. This process determines what further activities are required to recover a consistent status in the entire distributed environment. The status of IDocs is updated in the recovered system.
4. A list of documents to be canceled in the communication partner systems is created. If necessary, IDocs are sent again automatically.
Not all inconsistencies can be automatically put right by the recovery tools. You may have to remove some of the inconsistencies manually. This especially applies to canceling application documents.
Activities
To remove inconsistencies, you have to carry out the following R/3 transactions:
1.Determine recovery objects: Transaction code BDRC
2. Process recovery objects: Transaction code BDRL
For more information, see the program documentation.
The following functions are also available:
3. Application log for ALE recovery procedure: Transaction code BDR1
The relevant parameters specified in the transactions Determine recovery objects and Process recovery objects, are recorded in a log. You can display the log in Transaction BDR1.
4. Reorganization of the data for recovery objects: Transaction code BDR2
The data generated in the transactions Determine recovery objects and Process recovery objects, is used to identify the status of the recovered objects.
This data is deleted when it is reorganized if the following conditions apply:
5. The recovered objects do not need to be processed further.
6. The recovered objects have already been processed.
Report IDocs in Error - Code Snippet
ABAP Code Sample to Report Error IDocs