To optimize the ALE distribution of Central User Administration, you can execute the outbound processing and inbound processing of IDocs in the background (see Background Processing: Concepts and Functions).
Optimizing IDoc Outbound Processing
When testing, it may be useful to temporarily set Pass IDocs Immediately. If, however, you have a large number of parallel dialog processes for IDocs in the central system and in the child system for mass processing in transactions SU10, PFCG, and PFUD, use the following settings in transaction WE20 for the outbound processing:
Transactional RFC (tRFC)
Packet Size 60
Set the packet size so that a packet consists of as many segments as possible, up to a limit of 4000 segments (total size below 4 MB).
Collect IDocs
Collect IDOCs means that a regularly-scheduled background job for report RSEOUT00 packs the IDocs into tRFC calls with the maximum packet size. The last packet is usually not full, but is sent anyway.
The tRFC status messages are updated using a job for report RBDMOIND. Transaction SCUL also displays the open tRFC calls for CUA (see also transaction SM58).
You can use report RSARFCER to delete unsent, obsolete tRFC calls.
Optimizing IDoc Inbound Processing
Since every sent IDoc requires at least one work process in the receiving system, inbound processing in the background is advantageous, if you:
Are sending a large number of IDocs simultaneously and want to optimize performance
Want to execute the processing serially
Want to restrict the processing to a particular application server
To do this, follow the procedure below:
In the receiving system, use transaction WE20 to set inbound processing to Processing in background in the partner profiles.
Schedule report RBDAPP01 as a background job, to process the IDocs (see also SAP Note 399271).
The report forwards all inbound IDocs to the application for processing, if they fulfill the selection criteria and have one of the following statuses:
Status 64, IDoc ready to be transferred to application
Status 66, IDoc is waiting for predecessor IDoc (serialization)
Serial IDoc Inbound Processing in the Background
For IDoc inbound processing with normal CUA operation, schedule report RBDAPP01 with dialog users as a periodic job with a high repetition frequency (for example, every five minutes) and the following selections:
Message Type: USERCLONE and CCLONE
Parallel Processing: No
The IDoc packets are serially passed to the application. In total, only one work process on the application server is occupied by the running background job.
Parallel IDoc Inbound Processing in the Background
If you are processing a very large quantity of user data by mass processing (for example, when transferring users with transaction SCUG or comparing organizational management role assignments with transaction PFUD), it can be useful to schedule the job with the following selection:
Message Type: USERCLONE and CCLONE
Packet Size: 3
Parallel Processing: Yes
On the application servers of the specified server group, a free dialog work process is occupied for each IDoc packet for the application's inbound processing (asynchronous RFC), that is, the packets are processed in parallel. If you have selected a large number of IDoc packets, almost all dialog work processes of the application servers are occupied by the IDoc processing (two processes remain free; see SAP Note 84716). The server group should therefore contain only servers that are not used by dialog users.
Since report RBDAPP01 does not output a message if it terminates, we recommend that, after a job step for report RBDAPP01 with parallel mode, you schedule a job step for report RBDAPP01 without parallel mode. This means that the IDocs that were not processed by the first job step terminate in a way that is logged (dialog message or a message in the job log).