Background
Work process:
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 600 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 either 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.
The
background processing system runs the external program by starting the sap
server program SAPXPG on the target host and then uses on the target host
system and then uses RFC to communicate with SAPXPG.
The
three phases of the background processing are
1)
Job
scheduling
2)
Job
processing
3)
Job
overview
Background
processing enables you to plan the start of ABAP/4 programs then at the given
time; they are started by special work processes called background work
processes.
In
the background we can run ABAP programs, external commands and external
programs.
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 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.
SAP
runs background jobs by using background work process but SAP schedules the
background job by using dialogue work process. From SM36 we can schedule a
background job.
Scheduling
a standard housekeeping jobs:
There
are several background jobs that should run periodically in a production SAP
System. These jobs perform housekeeping chores such as deleting outdated spool
requests of background jobs. You should schedule each of these jobs for periodic
execution
Some
of the predefined background jobs are:
Job name
|
ABAP Program
|
Required Variant
|
Often
|
SAP_REORG_JOBS
(Delete old background
jobs)
|
RSBTCDEL
|
You must create a variant
|
Daily
|
SAP_REORG_SPOOL
(deletes old spool
request)
|
RSPO0041
|
You must create a variant
|
Daily
|
SAP_REORG_BATCHINPUT
(Deletes old batch input
files. This job may not run at the same time as normal batch input activity.
Schedule this job for periods during which no batch input sessions are run.)
|
RSBDCREO
|
You must create a variant
|
Daily
|
SAP_REORG_ABAPDUMPS
(Deletes old dumps
produced by ABAP abnormal terminations)
|
RSSNAPDL
|
You must create a variant
|
Daily
|
SAP_REORG_UPDATERECORDS
(Delete old update
records)
|
RSM13002
|
You must create a variant
|
Daily
|
SAP_COLLECTOR_FOR_PERFMONITOR
(Collects system
performance statistics)
|
RSCOLL00
|
None
|
Hourly
|
SAP_COLLECTOR_FOR_JOBSTATISTIC
(Generates run time
statistics for background jobs)
|
RSBPCOLL
|
None
|
Hourly
|
SLCA_LCK_SYNCHOWNERS
(Synchronizing enque
server)
|
SLCA_LCK_SYNCHOWNERS
|
None
|
Hourly
|
Defining a house keeping
job:
1) Go
to SM36 and define a job name:
2) From
the above screen we will define background jobs.
3) While
scheduling a background job we have different kind of priorities based on the
priority background jobs will be executed.
Class
A: high priority jobs
Class
B: Medium priority
Class
C: Low Priority
Class
A job will be taken care by the class A work process present in the background
work process.
4) If
you want to run your background job in other server than select respective
server in the execution server. The spool list recipient will be used to send
mails about the background job status.
5) Select
Job step in the above screen, another window will popup select the program that
you want to run. Here we are selecting ABAP program.
6) As
I am running a standard housekeeping job here I am running rspo0041 (deletion
of old spool requests) and I am selecting a standard variant.
7) Click
on check and save overview window will appear.
8) For
scheduling the job go back and save it.
9) Now
we need to run the background for that go to start condition.
10) Here we are running the job immediately with
periodically so select periodic check box as well.
11) Check and save and select periodic values
option.
12) Here we can define the periodic values. I
would like to run this job for every three minutes so I am selecting other
period option and I will specify as 3minutes.
13) Check and save in all the windows and save it
in sm36 main screen the job will be in the released stage.
14) Sm37 is the transaction code to check the
status of the background jobs.
15) Execute the above screen to know the status of
the jobs that you released.
16) The job we released has finished successfully.
To check the job log double click on the that job.
No comments:
Post a Comment