CUA: Tips for optimizing ALE distribution performance

How can I optimize the ALE distribution of the Central User Administration (CUA)


I. Outbound processing

When you process outbound IDOCs, two variants are available: 'Transfer IDocs Immediately' and 'Collect IDocs'.

1. 'Transfer IDocs Immediately':
If changes to the user masters are to take effect immediately, then select this variant. (The package size mentioned in the paragraph on 'Collect IDocs' is irrelevant for this variant.)

2. 'Collect IDocs':
'Collect IDocs' means that a batch job to be scheduled regularly for the RSEOUT00 report, which sends out the IDocs collected so far.

Use this outbound processing variant if the central system of your CUA has a restricted number of work processes available, which is smaller than the number of child systems. In this case, it may happen that when sending the IDocs to all systems in parallel, all work processes of the central system are blocked by ALE processing. For more information, see Notes 527481 and 400330.

To prevent these bottlenecks, collect the outbound Idocs and process them as follows using report RSEOUT00:

Determine the maximum number of target systems to be supplied in parallel based on the work processes available and the 'max-conn' parameter (see Note 527481, Point 3 of the solution).
Example:

A maximum of 15 work processes are available. You want to keep five free for dialog activities. 20 child systems are connected to your CUA and the 'max-conn' indicator is set to five.

To avoid blocking more than 10 processes in parallel by the ALE processing in the CUA environment, IDocs may only be distributed over a maximum of two systems simultaneously.

Create the variants for report RSEOUT00.
For each variant, you need to specify two target systems for the case described above. To do this, enter two logical system names for each variant in the multiple selection of the 'Partner number of Recipient' input field.

To be prepared for the addition of further target systems to the existing CUA, create a final variant containing all the current systems of the CUA on the 'Single Values' tab page ('Exclude values'). This variant is then used to send all IDocs whose target systems have not already been supplied with the other variants.

Now schedule a batch job that processes all variants one by one. Schedule the special variant described above as the last step.
Depending on the number of IDocs to be sent and the runtime of the background job, select the length of the period in which it is scheduled.
Other Settings and Explanations for Outbound Processing:


Use the package size (*) in the partner profile (transaction WE20) to determine how many IDocs are collected in a package and therefore how many of them should be sent with a tRFC call.

When transferring several IDocs to a port using report RSEOUT00, you can determine the maximum number of IDocs that can be transferred before a COMMIT WORK using the 'Maximum Number of IDocs (**)' option. Report RSEOUT00 executes a tRFC-call for each package, which means that the number of IDocs in a tRFC-call is the same as the 'Package Size' value. Even if the last package does not contain the full number of IDocs, it is still sent:

Formula:
max. number of IDocs(**)/IDocs per package(*) = number of packages
= tRFC calls


After the COMMIT WORK, the tRFC calls collected in accordance with the formula mentioned above are processed by the RFC.

If transfer errors occur during certain tRFC calls, the IDocs concerned remain in the sending system with status 30 and the system tries to send them again during the next RSEOUT00 call.
The tRFC status messages are updated by a job for the RBDMOIND report.
Transaction SCUL also displays the open tRFC calls that affect the CUA (see also transaction SM58).
tRFC calls that have not been sent but are now obsolete can be deleted using report RSARFC01 (see Note 371068).


II. Inbound processing

Every IDoc that is sent needs at least one work process in the receiving system. If a large number of IDocs are sent simultaneously, you need to set the inbound processing to 'Trigger by Background Program' in transaction WE20 in the partner profiles in the receiving system and process these IDocs using report RBDAPP01 in the background. (Alternatively, IDocs can also be processed using RBDSER04.)

This report forwards all inbound IDOC that meet the selection criteria and have the status specified below to the application for processing:

64 "IDoc ready to be transferred to application"
66 "IDoc is waiting for predecessor IDoc (serialization)",



There are essentially two groups of IDocs:

IDocs to be serialized according to the relevant object
All other IDocs,

There are also two types of processing:

Serial processing
(all IDocs are processed in sequence in one process)
Parallel processing
(All IDocs are transferred in packages to other processes for processing. If no other processes can be occupied, a termination message occurs after a timeout (300 seconds).)

Parallel processing of user administration IDocs (Message type USERCLONE ) may result in locking problems in two instances:

1. If several IDocs are to be processed in parallel for the same user, the system only waits for a maximum of one minute for the lock to be released. After this, an error status is set.
2. If several IDocs are to be processed in parallel for different users and these contain user assignments for the same roles (direct assignments or indirect single role assignments because of assigned composite roles), a warning message is issued in transaction SCUL, indicating that the IDoc has still been posted correctly.

For the IDoc inbound processing during normal daily use of the CUA, the RBDAPP01 report should be scheduled as a periodic job with a high repetition rate (for example, every 5 minutes) and the following selection:

Message type: USERCLONE
CCLONE

Process in parallel: no

Parallel processing of IDocs does not occur, and the packages are transferred to the application in sequence. In total, only a single work process of the running background job is occupied on the application server.

Caution:
If the total delay plus runtime of a background job is to be longer than the repetition rate of the periodic job, the IDocs are processed in parallel, and the lock problems described above may occur.
A solution to this problem is available in Note 557610.

If, on the other hand, a very large volume of user data is processed (for example, transferring users with transaction SCUG or comparing the role assigners of HR-Org with transaction PFUD), it may be useful to schedule the job with following selection:

Message type: USERCLONE
CCLONE

Package size: 3

Process in parallel: yes

In this case, a free dialog process on the application server of the specified server group is used for each IDOC package for inbound processing of the application (an 'asynchronous RFC' is used for this purpose). This means that the packages are processed in parallel. If several IDOC packages were selected, almost all dialog processes of the application server are occupied by IDoc processing (two processes remain empty; see Note 84716). Therefore, the server group should only contain servers that are not used by dialog users.
In the case of a termination (Dump/A-Message), no message is issued by RBDAPP01. To recognize such problems, it is useful to enter a job step for RBDAPP01 WITHOUT a parallel mode, after you have entered one WITH a parallel mode. A logged termination (either a dialog message or a message in the job log) then occurs with the IDocs that were not processed during the first job step.


Effect of the 'Package Size' Parameter

This parameter determines the size of the packages that are to be processed in a particular task when parallel processing is active and IDocs are serialized by object. Therefore, independent objects may be processed in a single task, in the same way as serial processing. (A large package size lowers the level of parallel processing.)
For all other IDocs, the system tries to transfer a package of a corresponding size to the application. On the one hand, this means that some application inbound modules are capable of supporting large packages. On the other hand, however, the number of parallel packages is still lowered when parallel processing is active (reduced system load, longer runtimes).