Performance considerations

Limits to the number of parallel processes that can be used

The limitation of MDR is purely based upon the available hardware within the SAP landscape. We have seen, on larger SAP customers, 20+ application servers with over 700 background processes. In this configuration, it has been possible to run an MDR program with as much as 300 parallel processes without causing contention upon the database and seeing an effect on scalability.

Contention with other batch jobs and dialog processes

It is important to know what other jobs are running in the batch schedule so that the SAP system is not overloaded. This goes for both MDR programs and their child processes as well as other batch jobs or user / dialog activity. This is the key benefit of a batch scheduler to ensure that jobs are orchestrated together. MDR arms you with the necessary control to run an ABAP program in a short burst of activity, so you can get it out of the way by maximizing the available hardware and system configuration.

MDR and your SAP batch scheduler

MDR integrates seamlessly with any job scheduler e.g. Automic / UC4, Tivoli / Maestro, Redwood. The scheduler itself triggers the same MDR ABAP program with the same variant. Within this variant, we set a parameter flag (see Wait for run to complete in section 1.2) that ensures that the “parent” job (triggered by the job scheduler) waits while the child parallel jobs finish. This means there are no changes from a batch scheduler perspective, as it completes the job as per normal but just N times faster. One of the key strengths of an MDR report / program is that it looks like any other ABAP report / program. The number of “intervals” and the number of “parallel jobs” to be started must be specified, however, these can be defaulted into the program itself or into the variant. The batch scheduler will still continue scheduling the program to run with the ABAP program name and the variant name, but the parameters within that variant will be enhanced only.