Background Work Processes

Definition

Background jobs run in a special type of work processthe background work processthat is different from dialog work processes in two ways:

  1. A dialog work process has a run-time limit that prevents users from interactively running especially long reports. By default, the system terminates any dialog work process in a transaction that exceeds 300 seconds. Although the value of the limit can be changed (in the system profile parameter rdisp/max_wprun_time), that limit is always in effect for dialog work processes. No such limit applies to background work processes.

  2. Background work processes assign memory differently to dialog work processes. In this way background work processes can be use as much allocated memory as necessary to process the often large amounts of data in the background processing.

Use

Using background work processes also lets you optimize both background or dialog processing. In "night" mode, more servers can offer more work processes to accommodate background processing jobs that are scheduled to run when there are lower numbers of interactive users. In "day" mode, you could limit background processing to fewer servers and/or fewer background work processes.

When a time-driven scheduler is activated, it starts the jobs for which it has free work processes. If there is another background processing server, then the scheduler on that server starts the remaining jobs for which it has capacity, and so on.

Although a job can specify to use a particular background server (an application server that has at least one background work process), it is best to allow the background processing system to use load balancing to distribute the workload among the available servers.

Parallel processing, or asynchronous RFC (remote function call), is the only exception to the rule that job processing only occurs in background jobs. A report programmed for parallel processing runs in a background work process. However, it can pass on work to the available dialog work processes. For more information, see Parallel processing, or asynchronous RFC.

To monitor background work processes, use the server and work process overviews.

ABAP Programs

To run an ABAP program in the background, you must provide a variant for reports with selection screens or the ABAP program must supply its own runtime parameters. You can specify the SAP user under whose authorizations the program should run, as well as how the spool system should handle output from the program.

Output generated by an ABAP program is held in the SAP spool system as a spool request. The job step printing and archiving specifications specify how to handle this output. Spool requests can also be sent automatically using SAPoffice to a user defined in the job definition. As the output can be quite high, you should be careful when using this option.

External Commands and External Programs

To run an external, non-SAP program, you must identify the host to run the program on and the path to the program as well as any arguments the program needs. The background processing system runs the external program by starting the SAP server program SAPXPG on the target host system and then uses RFCs to communicate with SAPXPG.

You can also specify how to manage the execution of the external program. For synchronous execution, the background job waits until SAPXPG displays the last status of the external program, for example. In contrast, the job continues for asynchronous execution after starting SAPXPG directly with the next job step. Synchronous execution also allows you to retrieve error output and a return code from the external program.

The background processing system makes a distinction between external commands for normal users and external programs for system administrators. You can see this distinction in the job scheduling transaction, with its separate fields for external commands and external programs.

External commands are pre-defined commands for end users and can run on any operating system. They are protected by system administrator-defined authorizations, so end users are restricted to scheduling only the commands they've been authorized to run.

External programs are unrestricted commands that can be entered into a job step by any user with administrator authorizations. Administrator authorization allows a user to run any program. For more information, see External Commands and External Programs.