A guide to

SAP S/4HANA Technical Job Repository

© 2015 by SAP SE.

All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge,
ByDesign, SAP Business ByDesign, and other SAP products and services
mentioned herein as well as their respective logos are trademarks or
registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal

Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business
Objects products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of Business Objects S.A. in
the United States and in other countries. Business Objects is an SAP
company.

All other product and service names mentioned are the trademarks of their
respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
Version: 2016-11-08 These materials are subject to change without notice. These materials are
provided by SAP AG and its affiliated companies ("SAP Group") for
informational purposes only, without representation or warranty of any kind,
and SAP Group shall not be liable for errors or omissions with respect to
the materials. The only warranties for SAP Group products and services
are those that are set forth in the express
warranty statements accompanying such products and services, if any.
Nothing herein should be construed as constituting an additional warranty.
Table of Content

Table of Content
1. Purpose of Technical Job Repository .................................................................................................................. 3
2. Design-Time component of Technical Job Repository ...................................................................................... 4
3. Run-Time component of Technical Job Repository ........................................................................................... 7
4. A look behind the scenes: How does Technical Job Repository work? .......................................................... 9
5. Monitoring Technical Job Repository Operations with SLG1 ......................................................................... 12
6. Customizing Options for Technical Job Repository ........................................................................................ 16

2
 www.sap.com

1. Purpose of Technical Job Repository

The Technical Job Repository in SAP S/4HANA was initially developed to support automatic (technical) background job
scheduling in cloud-based SAP S/4HANA systems. SAP needed a mechanism to run certain recurring (=periodic)
background jobs automatically in every S/4HANA system, without the need for external intervention or monitoring.

Technical Job Repository is also available in the on-Premise Edition of SAP S/4HANA and serves the same purpose
there: to automatically schedule so-called technical background jobs which must be running in order to keep the
system “healthy”. Examples for such background jobs (from SAP NetWeaver software component) are
SAP_REORG_SPOOL, which deletes old spool requests, and SAP_REORG_JOBS, which deletes old background
jobs.

This paper intends to give a guideline to system administrators of SAP S/4HANA on-Premise Edition with respect to
automatic background job scheduling via Technical Job Repository. It introduces briefly the basic concepts of
Technical Job Repository, certain runtime aspects (job scheduling, un-scheduling, monitoring of operations) and finally
describes options an administrator has to modify/customize background job scheduling via Technical Job Repository.
 www.sap.com

2. Design-Time component of Technical Job Repository

Technical Job Repository has a design-time component (used by SAP development) which allows to create so-called
Technical Job Definitions (in short: Job Definition or Jobdef) which are basically templates for recurring background
jobs.

These Job Definitions are created by SAP developers, using transaction SE80, and are transported via a logcal
transport object (R3TR JOBD <name of job definition> ) to all target systems.

Here is how a job definition looks like in SE80:

The Overview tab defines the report and report variant name which will be executed by the background job.

Note: A job definition always carries the same name as the related background job which will eventually be created
from it in a target system, so the content of field background job name is identical to the name of the job definition.

Some special information is necessary for the contents of field User Name:

Almost every job definition you will find contains the value (DEFAULT) in field User Name. This is actually a
placeholder for the execution user that the run-time component will use when scheduling the background job.

As default behaviour, 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.

4
 www.sap.com

Note: If you want a different user name (i.e. not SAP_SYSTEM nor DDIC) to be employed for all Technical Jobs
scheduled by Technical Job Repository in SAP S/4HANA, this SAP user name needs to be entered into table
CLMS_TENANT, field JR_USER.

Starting with NetWeaver Release 7.51, SAP has updated report R_JR_UTIL_1 to allow maintenance of this table entry
in the current client. If you are running SAP S/4HANA based on NetWeaver Release 7.50 and require this functionality,
you can update report R_JR_UTIL_1 via SNOTE, the relevant SAP Note is
2339022 Maintain Default Step User for SAP S/4HANA Job Repository (On-Premise scenario)

You need to specify the user name in every client, since CLMS_TENANT is client-dependent (and so are SAP user
definitions).

Ensure that the background job step user you specify via report R_JR_UTIL_1 does indeed exist (and is unlocked) in
the current client, otherwise Technical Jobs will never be scheduled successfully!

Let us move to the execution terms tab of a job definition:

A job definition thus allows the author to define the following attributes of the background job:

Attribute: Possible Values: Comment:

Report Name <ABAP report>
Variant Name <existing system variant of the SAP-delivered job definitions can only use so-called
report> system report variants which are client-independent

5
 www.sap.com

Execution Client ADMIN client, Programs which perform cross-client tasks usually
BUSINESS client, run only in ADMIN client, whereas programs which
or both work exlusively on (application or customizing) data
defined in the current client run only in BUSINESS
client

Note: ADMIN client is typically defined as client 000

Scope Dependency YES or NO A job for to a scope-dependent job definition will only
be scheduled if an entry in table
STJR_JOBD_SCOPE exists (containing the name of
the current job definition) in the current client.

It is the application’s responsibility to insert resp.

remove such table entries in STJR_JOBD_SCOPE.
Entries may be created via an API (class
CL_JR_JD_SETTINGS) or manually via table
maintenance in IMG.
Recurrence TIME-PERIODIC or
EVENT-PERIODIC
Time-based Specify the time interval after which
recurrence the job must run again.
For daily, weekly, monthly jobs it is
possible to also specify a start time
Event-based The name of the BATCH EVENT
recurrence which will trigger job execution

Our sample screenshots show job definition SAP_REORG_SPOOL: This job definition prompts Technical Job
Repository runtime to schedule a daily job with name SAP_REORG_SPOOL which runs report RSPO0041 using
report variant SAP&001 at 01:00 a.m. in the ADMIN client.

6
 www.sap.com

3. Run-Time component of Technical Job Repository

Technical Job Repository has a runtime component which is automatically active in every SAP S/4HANA system.

The run-time 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.

To verify that the runtime component of Job Repository is active in your system, run report R_JR_UTIL_1.
Executing report R_JR_UTIL_1 via transaction SE38 with default parameter settings should result in an output like the
following:

7
 www.sap.com

You may have noticed that the same report also has a CHANGE option on its parameter screen. Via this option, it is
possible for you (you need to have “batch administrator” role, this is basically the same authorization set you need to
fully operate transaction SM37) to deactivate the run-time component of Technical Job Repository.

When you run R_JR_UTIL_1 with CHANGE option, you get a warning popup:

The consequences of continuing with a “Yes” here are that the periodic (hourly) job generation action will not take
place any more. It will not affect the state of currently existing background jobs related to Job Repository, though:

Any technical background job already present in RELEASED state will not be affected. Neither are any Technical
Background Jobs in RUNNING state aborted or otherwise influenced.

Only deactivate Job Repository Automation in case you have an emergency situation that forces you to
deactivate the hourly job activation!

8
 www.sap.com

4. A look behind the scenes: How does Technical Job Repository work?

How does Technical Background Job Generation actually work in SAP S/4HANA systems?

First of all, the hourly action is triggered from the SAP kernel only in SAP S/4HANA systems! The profile parameter
responsible for this is rdisp/job_repo_activate_time

Here is a screenshot from RZ11 in an SAP S/4HANA system displaying the profile parameter details:

The value 60M is set by default in SAP S/4HANA systems and causes the Job Generation action to occur every 60
minutes.

9
 www.sap.com

The hourly Job Generation action stores its last execution time in table BTCCTL. So it is possible to learn the last Job
Repository Job Generation time by displaying table BTCCTL with SE16 and selecting the entry with key value
CTLOBJ = JOBDSDL.

For example:

The table entry reveals that the last Job Generation action took place at 08:41:46 (system time) on server
ldcietx_ETX_10.

What happens during the hourly Job Generation action is that an ABAP session is started which executes a program
that creates a background job named R_JR_BTCJOBS_GENERATOR in every relevant client. These background jobs are
responsible for the actual Job Generation action of Technical Background Jobs.

You can view those created jobs in transaction SM37, for example:

10
 www.sap.com

These jobs monitor Technical Job Definitions and schedule (or un-schedule) Technical Jobs in the current client as
necessary.

Here is what job R_JR_BTCJOB_GENERATOR performs in detail (in the current client):

Step 1 Collect all existing active Technical Job Definitions

Step 2 For each Job Definition: Check whether Job is relevant in current client
Relevance check includes:
- Should job run in BUSINESS and/or ADMIN client?
- Scope-dependent Job Definitions: Is scoping table entry present for Job Definition?
Step 3 For each Job Definition: If not relevant in current client, unschedule any existing Technical Job
Step 4 For each Job Definition: If relevant in current client, calculate start condition for Technical Job
Step 5 For each Job Definition: Check if a Technical Job already exists with correct start condition.
If Yes: No action
If No: Unschedule any existing Technical Job and schedule new Technical Job with correct start
condition

11
 www.sap.com

5. Monitoring Technical Job Repository Operations with SLG1

The task of Technical Job Repository is to ensure that relevant Technical Background Jobs are getting scheduled (and
not-relevant ones do not get scheduled).

This is achieved (as outlined in chapter 4) by an hourly ABAP session which spawns so-called activator jobs (named
R_JR_BTCJOBS_GENERATOR) in every relevant client which perform the actual scheduling resp. unscheduling of
Technical Background Jobs.

You can monitor the actions of these activation jobs in transaction SLG1 (application log). In SLG1, enter
JOB_ACTIVATION as value for selection field “Object” as shown:

SLG1 then displays job activation logs for the hourly Job Activation actions, plus any additional manual actions related
to Job Repository that may have taken place.

12
 www.sap.com

An example:

Double-clicking a single log line renders detailed information what happened during job activation, for example:

13
 www.sap.com

Information you find in SLG1 concerning Job Activation action includes:

 Notification that a job was scheduled because no current matching Technical Job was found

 Notification that a job was rescheduled (i.e. unscheduled and newly created) due to a discrepancy in job
attributes:
14
 www.sap.com

For example, the execution frequency of a time-based Technical Job Definition may have changed (i.e. an
updated Job Definition was imported) and this needs to be adapted for the actual periodic Background Job.

 Notification that a job was unscheduled because the job is not relevant (any longer) in current client.

For example, a Technical Job which belongs to a scope-dependent Job Definition was unscheduled because
the “Job Definition is in Scope” flag (that is, an entry in table STJR_JOBD_SCOPE) was deleted by an
application in the current client

 Any errors related to Background Job management that occur during job scheduling or unscheduling.

15
 www.sap.com

6. Customizing Options for Technical Job Repository

The task of Technical Job Repository is to ensure that certain background jobs are getting scheduled in a regular
fashion. To this end, Technical Job Definitions have been defined that control various parameters of executed jobs,
e.g. Report Name (plus Variant Name, if applicable), Frequency, Start Time, and the like.

All Job Definitions in Technical Job Repository have been defined and shipped by SAP (Basis and Application)
Development. Now your specific SAP S/4HANA system may have requirements that differ from what SAP assumed as
typical usage patterns of SAP S/4HANA systems.

If, for whatever reason, you have the need to modify the behaviour of a Technical Job scheduled via a Technical Job
Definition in Job Repository, the explanation in this section will guide you through the options you have for modification.

Step 1: Identify the Job Definition in question

Job Definitions always carry the same name as the created background job. This makes it easy to look up the job
definition starting from a job encountered in transaction SM37.

Step 2: Identify the client in which the Job needs to be modified

Background Jobs always execute programs in a defined client. Modification of a Job Definition is a client-specific
action. You need to identify in which client you want to make a change.

Step 3: Look up the job definition details via transaction SJOBREPO

Log into the system using the client identified in step 2. Run transaction SJOBREPO. It will present a list of all existing
Job Definitions in the system, together with relevance and job status information for the current client.

16
 www.sap.com

An example:

Double-click on a Job Definition name, the system will navigate to the Job Definition details which are
viewed/maintained in transaction SE80:

17
 www.sap.com

With tab Execution Terms you can view for example the Job Frequency (for time-based Job Definitions), the Event
name (for event-based Job Definitions), plus all relevant attributes like scope-dependency, execution in ADMIN or
BUSINESS client, etc.

18
 www.sap.com

Step 4: Decide whether you want to completely deactivate the job in current client or only alter the scheduling pattern
(i.e. scheduling frequency and/or start time)

19
 www.sap.com

Step 5A: If you decide to deactivate the job, go back to the overview list of SJOBREPO. Position the cursor on the Job
Definition in question and use F7 (“Deactivate Standard Technical Job Definition locally”). You will be prompted
with a popup which you need to confirm:

When you select “Yes”, you will receive a transport system popup requesting you to log your configuration change in a
customizing transport request:

Once you save the customizing transport request, you are done – the Job definition has been deactivated in the
current client, this is also indicated in the overview list of SJOBREPO:

20
 www.sap.com

Step 5B: If you want to retain the Job from the Job Definition, but change its frequency and/or start time, again run
transaction SJOBREPO, position cursor on the Job Definition in question and use function F9 (“Local change of a
Technical Job Definition”): You will be prompted with a popup screen which displays the current frequency and start
time and where you can enter the desired new Job Frequency and/or Start Time:

21
 www.sap.com

Make your changes here and push the “Save” icon (or F5): Again, you will be prompted with a transport system popup
screen where you save your configuration change in a customizing transport request in order to transport it to
subsequent systems.

Once you save the transport request, you are done – the Job definition has been customized in the current client, this
is also indicated in the overview list of SJOBREPO:

22
www.sap.com

23