Monday 30 December 2013

Background Job/Background Workprocess


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