Title
Workload Distribution and External Parallel Processing

Purpose
Many reports cannot be parallel processed. They only process theirworklist sequentially. The time available for processing the data in acritical time frame can often only be adhered to by parallel processingthe report.
It is possible to parallel process reports that are not considered tobe "parallel processing-compliant" and this is done by manuallymaintaining a large number of variants for a parallel process. But thisstatistical division of the worklist can lead eventually to paralleljobs with an uneven workload. The individual variants therefore oftenhave very varied runtimes. The shorter runtime, which is the aim ofdividing up the workload manually, may therefore approach the same sortof runtime as is required for sequential processing. Therefore,statistical division of the workload is not always the solution toparallel processing criteria (for example, increasing number ranges inpurchase orders, deliveries).
By choosing the transaction WLCPAR, you are able toautomatically parallel process reports that cannot be parallelprocessed with the report RWLC_PROCESS_IN_PARALLEL. This is done byembedding the report that is to be parallel processed in a report thathas been generated by the report RWLC_PROCESS_IN_PARALLEL, and thensaving it as a separate report. This separate report, which providesthe functionality for external parallel processing and for reports thatare to be parallel processed, can be planned like any standard job aslong as a variant is maintained for this report.
A worklist is created in a preprocessing run and then distributed amongthe parallel jobs. Selection variants are created for these jobs withwhich the report can be started automatically. The workload isdistributed every time the report is called so that all the paralleljobs take more or less the same amount of time and therefore have amuch shorter runtime than sequential processing or manual distribution.
You must also create a variant Vr in the report R
that is to be parallel processed. This is necessary for definingthe worklist that is to be processed.
Using the report RWLC_PROCESS_IN_PARALLEL, generate a separate reportRp in the development system (transaction WLCPAR) for every report R that hasto be parallel processed. Rp preselects the worklist,distributes the workload among the parallel jobs, creates selectionvariants Vrp (which are derived from the variant
Vr) for the parallel jobs and to start the parallel jobs forreport R.
The generated report Rp is automatically entered into achange and transport request with which the report can be transferredto the production system. You do not need to make any more Customizingsettings in the production system.
This means that you must maintain the Mandatory Optionsand the Additional Selection Options views in Customizingin the development system. You can maintain the view DefaultValues for Selection Screen in Customizing; you can/must definethe current values in the variant Vp.
You must plan the generated report Rp, rather than thereport R, in the production system with one of thevariants Vp that was defined for this report.
Ensure when you are planning follow-on jobs that once the generatedreport Rp has been processed, all the reports
R have been processed. Therefore, a planned follow-on job canstart immediately after.

Prerequisites
Reports that are to be parallel processed externally have to fulfillthe following prerequisites:

• The selection screen must contain at least one selection option.


• You must be able to define the worklist in advance: a maximum of 4
tables can be read generically whose keys match at least the fieldnumber and the data type. Dependent tables must copy and, if necessary,enhance the key from the higher level table.
INCLUDE WLC_REP_CUST OBJECT DOKU ID TX