Background Work Processes

Explained
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 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.

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 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, seeParallel Processing of Jobs with
Asynchronous RFC.
To monitor background work processes, use the graphical job scheduling monitor or 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 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.

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 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.