SAP ALE performance optimization

Optimum ALE processing is synonymous with an optimum throughtput of IDocs

IDocs are processed during the ALE processing flow in the following places :

  • A: In the sending SAP system when IDocs are created
  • B: In the sending SAP system whe the IDocs are transferred to the communication layer
  • C: For communication between the sending system and receiving system
  • D: In the receiving system when IDocs are posted

Where can processing be optimized ?

Processing in these places can be optimized by one or more of the following measures :

  • Controlling IDoc events
  • Processing IDocs in parallel
  • Bundling of IDocs into packets (packet processing)
  • Administration of the IDoc communication

Creating and transferring IDocs to the communication layer in two separate steps improves the overall performance of the ALE process.


Creating IDocs in parallel

IDocs are created in parallel by several dialog processes that are used at once.

It can only be used if master datat is sent directly. In constrast, the program RBDMIDOC for analysing 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.

You must specify a server group for creating IDocs in parallel (RZ12).

The server group is a list of the application servers, whose available dialog processes are used to create IDocs. Two dialog processes remain unused on every application server in a server group.

To create IDocs in parallel on a particular application server, a server group must be created with this application server as the only entry.


Parallel transfert to the communication Layer

In collected mode, RSEOUT00 groups together IDocs for communication with the same logical receiving system, in accordance with specifications in the partner profiles. The packet size parameter determines how many IDocs are transferred with one tRFC call.

The selection screen for RSEOUT00 contains a field “Maximum number of IDocs”. Here you can specify the maximum number of IDocs that are to be transferred before a COMMIT WORK is transmitted and the IDocs are unlocked. For many selected IDocs, a value that is too large can lead to runtime errors (timeout, memory overflow). In this situation, choose a smaller value.

As a guide, the 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.

IDoc communication uses all available dialog processses of the application server that transfers the IDocs to the communication layer.
With IDoc parallel communication, it does not matter whether IDocs are first collected or transferred immediately.

Make sure you specify a sufficient number of dialog processes on the application server of the receiving system. The number of dialog processes should not be less than the number of sending application server.

Each individual dialog process creates a tRFC connection to the receiving system.


Processing IDocs in parallel

Immediate processing :

When IDoc packets are processed immediately, all dialog processes on the receiving application server are used.

The immediate mode could block the application server. You cannot distribute inbound IDoc packets among one server group

If the IDoc packet consists of several IDocs and if the posting function module is not capable of mass processing, the ALE layer calls up the function module several times within the same dialog process and transfers a single IDoc for posting each time.

When setting table TEDEF is filled, (entry TRFC-IDOC, BATCHJOB), receiving system could use batch processes to integrate IDocs if all dialog work processes are already used. In this case, program RBDAPP01 is scheduled in background for each IDoc. This could also use all aailable batch processses. (Note 555229)

Background processing:

Inbound IDoc packets are split into individual IDocs and stored in the database.

All application servers in a server group can be used in parallel for posting IDocs in the background.

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.

If one server group is used for parallel processing, two dialog processes remain unused on every application server in a server group. This prevents the application server becoming blocked.

Two groups of function modules are used to post IDocs :
– Function modules which process IDocs in mass. Thesse transfers packets of IDocs whose individual IDocs are posted in the same Logical Unit of Work (LUW).
– Function modules which process one IDoc per call.

If you post the IDocs immediately, the R/3 sending system determines the IDoc 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 you use function modules that can process IDocs in mass, the database load is reduced.

Packet Processing :

If you group IDocs into packets, this may also be practical for function modules that post inbound IDocs one at a time, because the ALE layer calls the function module several times in the same dialog process, thereby reducing the administrative load on the R/3 System.

If program RBDAPP01 carries out the background processing, as a guide, you should use a packet size of between 20 and 100 IDocs.

You can use packet processing in ALE for creating, transferring and posting IDocs.

Creation :

Cf § Creation of IDocs in the sending system.

Transfert :

Several IDocs can be grouped into a packet and sent in one transactional Remote Function Calll.

This has the following benefits :

  • The fewer administrative tasks reduce the load of the system.
  • tRFC uses less dialog processses in the sending system.
  • tRFC uses less dialog processses in the receiving system

IDoc posting :

Two groups of functions modules are used to post IDocs :

  • Function modules which process IDoc in mass.These transfert packets of IDocs whose individual IDocs are are posted on the same Logical Unit of Work (LuW).
  • Function modules which process one IDoc per call.

If you post IDoc immediately, the sending system determines the package size.
If IDocs are posted in the background, you can specify the size of packets to be generated by program RBDAPP01.

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 you use function modules that can process IDocs in mass, the database load is reduced.

If program RBDAPP01 carries out the background processing, as a guide, you should use a packet size of between 20 and 100 IDocs.

Source : BC619- ALE Technology

Abdel SIDHOM has written 38 articles

One thought on “SAP ALE performance optimization

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>