** Credit SAP web
Background Processing in Overview
Here’s a brief overview of how background processing works in the R/3 System. This diagram shows the components that are involved in processing various types of R/3 background jobs.
- Job scheduling: Before the background processing system can do anything, background jobs have to be scheduled. This can occur in transaction SM36 (job scheduling), in the ABAP editor (transactions SA38 and SE38, the "start program in the background" execution option), or through the programming interface or external interface of the background processing system. Many R/3 applications use the internal programming interface to schedule long-running reports for background processing.
- Job storage management: Jobs are stored in the R/3 database. Principal tables in the background processing system include the following:
- TBTCP: The job step table (individual processing steps in jobs)
- TBTCS: The control table for the time-driven job scheduler
- BTCEVTJOB: Jobs scheduled to wait for an event
Job logs are held in the R/3 "TemSe" (Temporary-Sequential Objects) database. The TemSe is set always to hold job logs as files in your host systems.
Accessing job logs for display and managing job log storage is transparent for you. You can display or delete job logs by way of the job overview (transaction SM37) or the graphical background monitor. Old job logs are removed automatically together with the jobs to which they belong by the ABAP program RSBTCDEL, which should always be scheduled to run periodically (see Required Basis Background Jobs).
- Job start management:
- The time-driven job scheduler runs periodically to check for jobs that were scheduled to run according to some kind of time criterion (start date or calendar date, for example). By default, the scheduler runs every 60 seconds in each R/3 server that has at least one work process for background processing. The start interval is controlled by the system profile parameter rdisp/btctime .
The time-driven job scheduler takes over the starting of event-based jobs if these jobs cannot be started when the corresponding event is triggered (for example, no free background work processes are available). Such jobs are managed as jobs whose start time and date has already arrived and start running as soon as possible.
Immediate-start jobs are normally started directly by the R/3 dispatcher (without the involvement of the time-driven scheduler). But these jobs are also taken over by the scheduler if they cannot be started when they are scheduled. Like event-triggered jobs, they are managed by the scheduler as jobs whose start time and date has already arrived and which therefore are immediately eligible to run.
- The event-driven scheduler is started whenever an event is triggered in the background processing system. Events are objects in the background processing system. They do not have anything to do with workflow events, nor do they have any system-wide meaning. A typical event is, for example, the system event "Job completed."
The scheduler checks for and starts any jobs that were scheduled to wait for the event and (optionally) for the event argument. Jobs that were scheduled with the start-time options After event, At operation mode or After job are event-driven.
There are two possible origins for a events: those created within R/3 and those generated at the operating system level, or external events. Events are automatically passed by the message server to an active background processing server. The R/3 System must be active to respond to external events. An event triggered by an external program when the R/3 System is not running is lost.
Both schedulers run in dialog work processes. If they find an eligible job, then they trigger the execution of the job in a background work process.
Start eligibility: A job becomes eligible when both of the following are true:
- The start specification of the job is fulfilled. Start specifications can be time based (including immediate start), calendar based, or event driven.
- The job has been released to run.
The release requirement can be turned off on a per-user basis. Trusted users can be given a special authorization (authorization object S_BTCH_JOB (Batch Processing: Operations on Batch Jobs) value RELE). When such a user schedules a job, the job is also automatically released.
- Job processing: Jobs run in a special type of R/3 work process, the background work process. Background work processes are different from dialog work processes in that:
- Background work processes allocate memory differently than dialog work processes. The purpose is to let background work processes grow as large in allocated memory as they need to be to process the large volumes of data associated with background processing.
The segregation of background processing to special work processes gives you an additional dimension for separating background processing and interactive work on the system. It’s customary of course to separate background processing and interactive work on the system temporally (for example, interactive users have the system during the day, large background jobs have the system by night). But R/3’s 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.
The use of background work processes also lets you use operation modes to change the configuration of your R/3 System to optimize background or dialog processing. In a "night" mode, more servers can offer more background work processes to take care of background processing jobs that are scheduled to run when interactive users are not present. In "day" operation, you could restrict background processing to fewer servers and/or fewer background work processes.
Jobs can specify a particular background server (an R/3 application server that has at least one background work process) for their execution. However, it’s best to leave the choice of background server to the background system. The system then uses a load-balancing mechanism to distribute the background processing workload among the available servers.
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 in that server starts the remaining jobs for which it has capacity, and so on.
Parallel processing (asynchronous RFC) 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 dispatch work to available dialog processes. For more information, please see Parallel Processing of Jobs with Asynchronous RFC.
You can monitor background work processes with the graphical job scheduling monitor and with the server and work process overviews (transactions SM50 and SM51).
Processing of ABAP Programs: To run an ABAP program in the background, you must provide it with a variant (for reports with selection screens) or it must supply its own runtime parameters. You can specify the R/3 user under whose authorizations the program should run, and you can also specify how list or other output from the program should be handled by the R/3 spool system.
If an ABAP program generates output, then this output is held in the R/3 spool system as a spool request. The job step printing and archiving specifications (Print specifications function) allow users to specify how such output is to be handled. It is also possible to have spool requests automatically mailed by way of the SAPoffice to a user designated in the job definition. Because output can be rather large, this option should be used with care.
Processing of external commands and external programs: To run an external, non-R/3 program, you must identify the host on which the program is to run and also specify the path name of the program and any arguments that the program requires. The background processing system starts the external program by starting an SAP server program (SAPXPG) on the target host system. R/3 uses R/3 RFC (Remote Function Calls) to communicate with SAPXPG.
The background processing system lets you specify how the execution of the external program should be managed. For example, in synchronous execution, the background job waits until SAPXPG returns with the final status of the external program. In asynchronous execution, the job proceeds immediately to the next job step once it has started SAPXPG. In synchronous execution, you can 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 (SM36), where separate fields for external commands and external programs are offered.
Briefly, external commands are pre-defined commands for end users. They are operating-system independent, because there is a different variant of each command for each operating system that R/3 supports. They are protected by authorizations, so that normal end users can schedule only the commands that the system administator permits them to.
External programs are unrestricted commands that a user with administrator authorization can enter in a job step. There is no restriction on the command that that the administrator can type in; the command is neither pre-defined nor is it protected by R/3 authority checks.
The purpose of this distinction is to let system administrators execute any required external program while restricting normal users to authorizations-tested external commands. For more information, please see External Commands and External Programs.
- Managing background processing: The background processing system lets you track background processing activity in your R/3 System with list-oriented and graphical monitors.
- The list-oriented monitor (transaction SM37) offers an administrator full control over background processing. From the main status display, you, as an administrator, can display job details, change or withdraw scheduling and release, display job logs, and use debugging and error analysis tools. If you have the required authorization, you can also display the spool requests generated by ABAP job steps.
More information: Managing Jobs with the Job Overview
- The graphical monitor (transaction RZ01) is specialized for system operators. It offers a Gantt-chart view of background processing, showing all completed, active, and released jobs on a time-line across all available background servers and work processes. The system tracks previous job performance, so that repeated jobs are always shown with Gantt chart lengths that reflect previous run times.
More information: Using the Graphical Job Scheduling Monitor.
Problem analysis support includes the background job logs, which record all messages issued by programs run in the background.
The only exception: batch-input messages are recorded in the batch input log (transaction SM35) rather than in the background processing log. Further, whether output from external programs is logged depends on whether the external command or program is started synchronously or asynchronously and how the job step control flags for program output are set. In asynchronous mode, the background processing system does not wait for completion of an external command or program before starting the next job step or completing the job. In this case, output from the external command or program is not captured in the job log.
Background job logs also contain job progress and status messages from the background processing system itself. (For more information, please see Displaying a Job Log.)
You can also use a variety of tools for analyzing and checking the background processing environment, and you can use standard ABAP debugging to "capture" a job while it is running. The best places to start looking for information are the job log and the R/3 system log. You will find a problem-solving guide and help in using these tools in Troubleshooting the Background Processing System.
0 comments:
Post a Comment