Setting Up the Background Processing Environment

In normal operation, every background work process processes jobs of every priority.

You can, however, reserve some of the configured background work processes as desired for high priority jobs; that is, class A jobs. The reservation of work processes for class A jobs does not reserve any particular work processes. Rather, it ensures that a particular number of background work processes are kept free for class A jobs whenever possible.

Jobs of classes B and C can only be started if the defined number of work processes remains free for possible class A jobs, as shown in the figure below.

This option allows a choice between two prioritization strategies for your background jobs:

• Critical track (class A) and two-level priority (classes B and C): If you have mission-critical jobs whose immediate execution must always be ensured, you can set up class A as your "critical jobs" category. In this case, reserve a work process for class A jobs and assign class A only to these mission-critical jobs. In this scenario, class B and C jobs are very unlikely to block a class A job.

• Three-level priority for allocation of free work processes: You can also decide to run with a straight three-level priority scheme for allocating free work processes. In this case, reserve no work processes for class A. If the class A workload is small, or bottlenecks rarely occur in background processing, that is, at least one background work process is usually free, the reservation of a work process for class A jobs probably provides no advantages. In this case, reservation will simply mean that a work process is seldom used.

To set the number of reserved background work processes for class A, you can define an operation mode in transaction RZ04 (CCMS: Edit Operation Modes and Instances) and maintain the work process distribution for this operation mode. When doing so, you have the option of reserving work processes.

Only instances with background work processes or a job server group can be used for the targeted scheduling of a background task.

A job server group contains one or more instances with available background work processes. You can use groups of this type in the same way as logon groups for dialog users. You can also process background tasks from different applications on selected instances.

Job server groups can be used to separate jobs from application servers being used by dialog users. In this case, the job server group used by a job would contain application servers other than those contained in the logon groups (transaction SMLG) for dialog users.

To set up a job server group, start transaction SM61(Display control object list) and then choose Job Server Groups. You can then define your job server group and assign your instances (see the figure above).

For more information, see SAP Note 612838 – Administration of job server groups.

For some long running SAP reports, the nights are just getting too short. Especially at customers with large volumes of data, some reports that customarily run in the background processing system (such as material planning runs) may have run times of many hours. These jobs can exceed the "night-time" that is available, particularly if the dialog users are distributed across multiple time zones.

SAP offers a solution to the "short nights" problem: parallel-processed background jobs. Long-running reports can now implement parallel processing where the work to be done can be distributed into smaller packages for the available work processes. The results can then be collected and synchronized.

In parallel processing, a job step is started as usual in a background processing work process. With the help of the ABAP command CALL FUNCTION <Function Module> STARTING NEW TASK <Task> DESTINATION IN GROUP <Group>, a program that runs in a job step can be programmed to have portions of the data to be processed run in parallel in other work processes (see the figure above). The calling program is continued as soon as the remotely called function has been started in the target system, without waiting for its processing to be finished.

An RFC group specifies the set of allowed servers for a particular parallel-processed job.

To define an RFC server group, use transaction RZ12. For RFC server groups, the descriptions of the individual parameters for resource allocation of the can be found in the F1 help in the system. Limitations concerning the SAP system parameters are explained in SAP Note 99284 – RFC exception: RESOURCE_FAILURE. Also, see SAP Note 2001276 – Changed configuration as of 7.40 SP2 for changes as of AS ABAP 7.40. It is recommended to deviate from the predefined SAP standard values for the parameter in very exceptional situations only (and must be tested with the relevant load on the system).

As a system administrator, you are going to work with a lot of batch jobs in your business, and want to know what you have to keep the batch functionality in an optimal state.

Standard jobs are background jobs that should run regularly in a production SAP system. These jobs mainly perform certain clean-up tasks in the system, such as the deletion of obsolete spool requests.

In AS ABAP-based SAP systems that are not SAP S/4HANA Server systems, you can access a selection of important standard jobs that you can schedule, monitor, and edit in the transaction SM36. To do so, you should choose Standard jobs in the application function bar. As the figure Scheduling Standard Jobs displays, you will see the table with all standard jobs (table REORGJOBS). If there are no standard jobs scheduled, the table will appear empty.

• If you want to schedule all standard jobs, choose Default Scheduling and provide a system user under which the jobs should be executed. All standard jobs will be scheduled with the specified variant and period. If other jobs exist that execute one of the programs of the standard jobs, you will see an information message.

• To schedule individual jobs, choose the selected job with the input help and specify an execution period.

• To define an additional standard job that is not yet available in the selection (table REORGJOBS), choose Predefine new job.

Due to changes to standard jobs over time, schedule the standard jobs manually according to the SAP Notes listed below which also provide more information on standard jobs:

• SAP Note 16083: Standard jobs, reorganization jobs
• SAP Note 1034532: Changes for standard jobs
• SAP Note 1411877: New Standard Jobs
• SAP Note 1440439: New Standard Jobs (2)

In SAP S/4HANA Server systems, the Technical Job Repository serves the purpose to automatically schedule so-called technical background jobs (both in the "ADMIN" and "BUSINESS" clients) which must be running in order to keep the system "healthy". It replaces the "Standard Job" functions in transaction SM36 and consists of a design-time component and a runtime component.

• The designtime component allows SAP to create Technical Job Definitions (in short: Job Definitions) which are basically templates for recurring background jobs.

• The runtime component is automatically active in every SAP S/4HANA Server system. This can be checked with the help of program R_JR_UTIL_1 with default parameter settings.

  The runtime component is responsible for actual scheduling (or unscheduling) of background jobs as mandated by the set of delivered Technical Job Definitions. The run-time component is triggered by an hourly action which occurs automatically in an SAP S/4HANA system.

  Hint

  The profile parameter responsible for this is rdisp/job_repo_activate_time with default value 60M. The hourly Job Generation action stores its last execution time in table BTCCTL. So it is possible to receive the last Job Repository job generation time by displaying table BTCCTL with transaction SE16 and selecting the entry with key value CTLOBJ = JOBDSDL.

Almost every job definition contains the value "(DEFAULT)" in field User Name. This is actually a placeholder for the execution user that the runtime component will use when scheduling the background job. As default behaviour, the Technical Job Repository will use SAP_SYSTEM as batch job step user if this user is available in the current client. If no such user exists, user DDIC will be used as batch job step user as a fallback solution.

The job definition status (see figure above) differs from the background job status. A job definition can be consistent, but nevertheless the job is not scheduled, for example because it should not run in the current client.

The job definition status reason explains why no job is scheduled for a job definition, for example

• if the user of the job definition does not exist in the current client (status reason "BTC User Error") or

  Note

  As of release SAP_BASIS 7.56, if you select one job definition from the list and choose button All clients in the application toolbar, you will get an overview of the selected job definition details in all clients.

• if the job will not run in the current client (status reason "Not Relevant") or
• if the job definition is scope dependent (see column Scope Dependent) but the scope conditions are not fulfilled (status reason "Not In Scope") .

Transaction SJOBREPO_STEPUSER allows you both to create a suitable technical user for Job Repository for the current client and to assign a technical user to the current client that is to be used by Job Repository. With the help of this transaction you can also display currently assigned Job Repository technical users for all existing clients.

For more information about the Technical Job Repository, see SAP Notes 2190119: Background information about S/4HANA technical job repository and 3236399 – FAQ - Technical Job Repository (SJOBREPO).

Certain requirements have to be met before the background processing can work. For example, profile parameters and authorizations must be set. A simple function is available for checking the consistency of the background processing environment: the analysis tool for background processing (transaction SM65). This tool is displayed in the figure below.

There are two test types available:

• Basic tests (initial screen): Here you can check whether the profile parameters are correctly set and whether the user ID SAPCPIC exists (required for starting external programs). You can perform this check both for a particular background server and for all servers. It is required for starting external programs.

• Expert tests (from the start screen, choose Goto → Additional Tests): In addition to the basic tests described above, you can us this option to also check the

  • user authorization for background processing

  • name of all job servers

  • function and status of the TemSe subsystem, which is required for writing the job logs

  • consistency of the database tables.

The background processing stores job data in multiple database tables. These tables can be checked for consistency. This test is especially important if problems occur with the database and you need to determine whether all job data is still available.