Background jobs run in a special type of work process—the background work process—that 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 allocate memory differently than dialog work processes so that background work processes can become as large as they need to in allocated memory to allow for processing large volumes of data.
Having special work processes for background processing provides an additional dimension for separating background processing and interactive work. Typically, background processing and interactive work on the system is separated by time of day. For example, interactive users have the system during the day, large background jobs have the system by night. But the background work process also lets you separate interactive from background use by server, since background jobs can only run on those servers that offer background work processes.
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 that has been programmed for parallel processing runs in a background work process, but it can also dispatch work to available dialog processes. For more information, see Parallel Processing of Jobs with Asynchronous RFC.
To monitor background work processes, use the graphical job scheduling monitor or the server and work process overviews.
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 automatically mailed via SAPoffice to any user designated in the job definition, but because output can be rather large, this option should be used with care.
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 example, in synchronous execution, the background job waits until SAPXPG returns with the final status of the external program, while in asynchronous execution, the job proceeds immediately to the next job step once it has started SAPXPG. 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.