Back ground Jobs

What is a background job?

SAP background job allows the automation of routine tasks and the optimization of the use of SAP computing resources. It provides you with extensive functions for scheduling and administering background jobs.

What is the use of a background job?

SAP background processing automates routine tasks and helps you optimize your organization’s SAP computing resources. Using background processing, you tell the SAP System to run programs for you. Background processing lets you move long-running or resource-intensive program runs to times when the system load is low. It also lets you delegate to the system the task of running reports or programs. Your dialog sessions are not tied up, and reports that run in the background are not subject to the dialog-step run-time limit that applies to interactive sessions

the background processing system has an interface to external management tools so you can integrate your SAP background processing into an external tool. Certified implementations of this interface are available for several external system management tools.

How to create a Background Job?

 1.  Call Transaction SM36

  2.  Assign a job name. Decide on a name for the job you are defining and enter it in the Job Name field.

  3.  Set the job’s priority  or “Job Class”:

·          High priority:  Class A

·          Medium priority: Class B

·          Low priority: Class C

  4.  In the Taregt server field, indicate whether to use system load balancing.

For the system to use system load balancing to automatically select the most efficient           application server to use at the moment, leave this field empty.

       To use a particular application server to run the job, enter a specific target server.

  5.  If spool requests generated by this job are to be sent to someone as email, specify the email address. Choose the spool line receiptent button.

  6.  Define when the job is to start by choosing Start Condition and completing the appropriate selections. If the job is to repeat, or be periodic, check the box at the bottom of this screen.

  7.  Define the job’s steps by choosing step, then specify the ABAP program, external command, or external program to be used for each step.

  8.  Save the fully defined job to submit it to the background processing system.

  9.  When you need to modify, reschedule, or otherwise manipulate a job after you've scheduled it the first time, you'll manage jobs from the Job Overview.

How to monitor a background job?

Background jobs monitoring is one of the core responsibilities of the SAP Basis administrator. Basically, background jobs are scheduled to achieve specific tasks in the SAP system. There is more to simply monitoring the success or other wise of a background job. You should add value to the monitoring of your background in the SAP system. Depending on what you want to monitor/analyze, the SAP system provides the functionalities to simplify the exercise. Some information that you might want to investigate include…

Similar jobs: Transaction SM37 can also help you identify jobs that are similar or probably duplicated. The job name column can help in identifying such jobs. For these kinds of jobs, you might have to carry out housekeeping activities such as deleting the redundant jobs.  

Long running job – If you are interested in investigating long running jobs, you can do that via transaction SM37. The “Duration (sec.)” column of the report allows you to analyze this requirement properly. For these kinds of jobs, it will be nice to investigate the root cause via performance detection transactions such as STAD, ST03N and ST12.  

Regularly cancelled jobs – Transaction SM37 is also a veritable tool for investigating jobs that are cancelled regularly. This status check can be seen in the “status” column of the report. It will be nice for you to review why they are always cancelled.  

Obsolete jobs: Some jobs might not have been modified in a long time and as such they have become obsolete. You can see the jobs that falls to this category via transaction SE16 by specifying the table name, TBTCO and reviewing the “last job change” field accordingly. For the jobs in this category, you might consider modifying the jobs or deleting them where possible.

Trouble shooting of a background job?

1) First of all identify the job that is long running and identify details like job class, workprocess that is executing the job

How to identify long running background jobs

2) Click on the job to view the display job screen. In the screen, click on job log to understand what is being performed by the job currently. This may give details like job is currently extracting some data packages or processing data packages etc

3) Identify the executing server and process id of the job from the step 1 and goto transaction SM50 of the respective executing server to view more details about the background job running.

Figure out the status of the job like On Hold or running from the process overview. If the job is On Hold, find out the reason for On Hold by examing the "Reason" column of SM50 transaction. Reason for On Hold could be due to CPIC/RFC/DEBUG/ENQ/PRIV/UPD etc.

Double click on the reason column for detailed information on the same and troubleshoot accordingly. If reason is RFC, check out which RFC it is referring to and cross check whether destination system is up or not and any other problems with that system.

·         If it is ENQ, check out any lock issues like lock overflow etc

·         If it is PRIV, check out for memory bottlenecks

·         If it is UPD, check out whether any update issues

·         If it is CPIC, check out for any network , gateway, message server and other communication problems

4) After performing step3, if you figure out job is not on Hold and it is in running state, then examine report column to identify what report/program is being executed by the job. Once you got the report/program details, figure whether it sap program or custom program and take actions accordingly.

5) Also examine Action and table columns in SM50 transaction of respective executing server to identify what is the action( roll in/roll out /Sequential read/Physical read/insert/update/delete etc)  being carried out by the job currently and what is the table on which action is being carried out.

If it is sequential read, figure out the cost of that sequential etc and consider for indexing etc. If it is physical read, check out whether there are too many swaps and consider resizing buffers accordingly. If you observed delay is due to high roll in/roll out, identify reasons for the same and tune buffer/memory parameters accordingly.

6) Once you get the table details on which action is being carried out, figure out        

·         How many records are existing in the table ?

·         Is this taking long time due to volume of records ?

·         Are there proper indexes on the table ?(If no proper index, consider index creation  by taking help of DBA )

·         Is the table having upto date statistics ? (If statistics are out of date,

 consider updating statistics of that table)

7) Consider debugging the process in SM50 ( Program/Session -> Program ->   Debugging ) to figureout the issue

8) Using ST05 or ST12, a trace can be taken for background job to figure out where exactly time is being consumed and to identify various cpu/memory bottlenecks or any buffer issues.

9) STAT/STAD transcation can be used to figure out what is the reason for high response time and actions can be taken accordingly

10) By taking help of ABAP er, even ABAP run time analysis can be done using SE30 transaction

By following the above steps, you can pin point the issue and take actions accordingly to minimize runtime of long running background jobs.

Spool Administration

Spool administration:

Unlike the Output Controller (transaction SP01), in which both users and administrators can work, Spool Administration (transaction SPAD

All devices, servers, and so on that are involved in printing are defined and managed in spool administration (transaction SPAD).

In the spool administration, you can perform the following tasks:

·        Setting Up Output Devices and Managing Output Devices

·        Setting Up and Managing Spool Servers

·        Setting Up and Managing Device Types sets

·        Setting Other general administration work, such as

·         Deleting Old Spool Requests

·         Checking the Consistency of the Spool Database

SAP provides its own spool service and a spool database so that users do not have to deal with operating system-specific issues.

The platform-independent SAP spool system is responsible for the output of forms and documents. The data to be printed is first temporarily stored (“spooled”), then formatted, and finally transferred to a host spool system to be output. You can control all of your output from the SAP system and do not need to arrange further processing in the host spool system.

The following are among the main tasks of the SAP spool system:

·        Processing and managing print requests

·        Administering output devices

·        Technical mapping of the output devices in the SAP system

Print Process in General:

An introduction for users and administrators, in which the print process from document to printout is explained in general. The focus of the introductory sections is the Output Controller (transaction SP01), which can be used by both administrators and users to manage print requests.

·        Spool Access Authorizations

·        This section and its subsections describe the access authorizations required specifically for the spool system.

·        Possible Print Architectures and Print Methods

·        The various print architectures are described in this section and its subsections, that is, the different constellations of hardware and software components with the corresponding access methods: Each architecture also requires a specific print method, such as:

·        Local printing: The spool server (application server with a spool work process) and host spool system (operating system spooler) are on the same host.

·        Remote printing: The spool server and the host spool system are on different hosts.

·        Frontend printing: Print data are to be printed on the default printer of the user’s PC.

·        Printing using SAP GUI for HTML

·        Output Devices in the SAP Spool System

·        Output devices must be defined in the SAP system so that they can be addressed from the SAP system.

·        You do these using device definitions with which the devices are managed in the SAP system.

·        This link takes you to a description of these device definitions and their printer settings.

Spool Server:

The spool server is an SAP application server that provides spool processing. It therefore requires at least one spool work process.

You can enter additional attributes and administration information for spool servers.

To do this, call transaction SPAD and, on the Devices/Severs tab page, choose the Spool Servers pushbutton. The list of defined spool servers appears. If you double click the relevant spool server, a window showing the attributes of the spool server appears.

You can enter or change the following attributes in this window:

·        Server Name: You can enter a description of the spool server in the long field of the Server Name area.

·        Server Class: Choose a suitable entry, depending on the intended use of the server, from the input options for the server class field, such as production printing, mass printing, and so on. The classification of the spool server helps you to realize your planned printing architecture, that is, to assign newly defined output devices to the corresponding spool server. If you specify the spool server in a device definition, the spool system compares the classification of the output device to the classification of the server. If they do not match, then the spool system warns you.

·        Alternative server: You can specify a “replacement printer”, the alternative server, for a spool server. The alternate server takes over the processing of output requests if the original server is down or unavailable. For more information, see Alternative Server.

·        Allow Load Balancing: You can define whether the output processing workload of a server may be distributed among its alternate servers. By default, load balancing is deactivated. Instead, the spool system ensures that output requests are printed in the order that they are generated.

·        Logical server: You can define spool servers as logical servers. A logical server is a name that can, in turn, stand for one or more logical or real servers (a real spool server is a server that actually has spool work processes and can run in the SAP System).

·        Using logical servers, you can transport a complete printing architecture to another system with only minimal changes. To activate printing in the target system, you only need to edit the assignment of the logical server. You can do this using the Mapping field. For more information.

Device Types for SAP Output Devices

Device types are explained in this section. A device type in the SAP system is the category of printer to be addressed. The information in the device type, such as font selection, page size, and character set selection is used to convert a document from the internal SAP format to a device-specific, printable data stream.

A device type is distinguished by the attributes listed below. If you change an existing device type or create a new device type, you must change at least some of these attributes.

·        Character set: A character set specifies the codes with which characters must be represented in the print-ready output stream (output request). This code replaces the generic SAP characters set that are used internally by the SAP spool system (spool request).

·        Printer driver: You can specify different printer drivers for printing SAPscript documents and ABAP lists.

·        Print controls: Print controls represent printer operations, such as boldface or changing the font size. These print controls are replaced by printer-specific commands during the creation of the output request from a spool request.

·        Formats: Formats specify the format supported by the SAP system. The system differentiates between SAP Script formats (DINA4 and LETTER) and ABAP list formats (X_65_132 = 65 rows/132 columns).

·        Page format: A page format is the interface between a format and SAPscript. It specifies the paper dimensions with which SAPScript can calculate the row and column lengths.

·        Actions: Actions are output device-specific commands that are required for the implementation of a format. The action printer initialization, for example, can contain a printer command with which the number of rows on a page is defined. There is a set of actions for every format supported by a device type.

Maintaining the Spool Database

Maintain the spool database regularly to ensure optimal performance and size. You should perform the following tasks to maintain the spool database regularly:

·        Check the consistency of the spool database

·        Delete old spool requests

 Process Flow

The figure below shows the most important methods of maintaining the spool database:

Scheduling both deletion and the consistency check in the background is preferable to performing these tasks in dialog. Scheduling these tasks in the background ensures the regularity of deletion and of consistency checks. It also eases the workload both of the administrator and of the systems.

TemSe Database Storage

Every TemSe object consists of a header entry in table TST01 and the actual object. This can be stored in the file system (for example, job logs) or in table TST03 (for example, HR data).

There are the following TemSe objects, among others:

·        Spool requests (TemSe Name: Spool....)

·        Job logs (TemSe Name: JOBLG...)

·        Objects from other applications, such as Human Resources (TemSe Name: HR)

·        An object whose name begins with KONS; this is object is constantly used by report RSPO1043 and should never be deleted (SAP Note 98065)

Analyzing Printing Problems:

Was the output request printed?

 1. Call transaction SP01.

2.  Enter all available information that you have on the spool request in the selection screen.

  3.  The most important status information about the spool requests means the following:

-- (no status): The spool request has not yet been sent to the output device. Print the spool request to see if it is output normally.

Being processed: The job is currently being formatted and/or transmitted to the host system spooler. You can wait to see if processing finishes normally. Or you can go to analysis procedure determining Why Output Request Was Not Processed to check whether processing is proceeding normally. Waiting or Complete and still has not appeared at the printer, you can go directly to the analysis procedure Determining Why Output Request Was Not Processed. If the status is Complete, also check the request information. To do this, select the spool request and choose. The Output Attributes tab page shows the status of completed output requests. If Processed… without printing is selected, the output request has not yet been printed. Go to the error analysis procedure shown above.

If Printed with Errors:

It is important to distinguish between minor and major problems with the appearance of output that has actually been printed.

A minor problem has occurred when the print out is legible and generally correct. However, there are problems with individual characters, with alignment of text and graphic elements, and the like. In this case, see Correcting Minor Output Errors.

A severe problem has occurred when a print request has been printed but is not readable. For example: the output is in the incorrect character set (such as Dingbats), or lines breaks and formatting are severely incorrect. In this case, see Correcting Sever Output Errors.

To check weather spool request generated or not:

  1.  Enter all available information that you have on the spool request in the selection screen, in particular the name of the user who generated the spool request and the printer name (Output device).

  2.  If you find the spool request, then go to the analysis procedure Determining Why an Output Request Has Not Been Processed.

  3.  If you do not find a spool request, see No Spool Request Generated: Analyzing a Spool Dump.