Maintaining Job Users and their Authorizations

After exploring the subjects of template creation, job management, and monitoring jobs, Adam’s interest extends to the fundamental principles of the authorization concept, particularly within the Application Jobs apps.

Carl therefore explains that in the public edition of SAP S/4HANA Cloud, user access to objects and data is managed via a multi-layered process. Let us walk through this to understand how they work together to control user access.

If we look at the big picture, at the beginning there are the Business Users. They are assigned specific Business Roles, which include Business Catalogs and Restriction Types. While Business Catalogs control access to apps, Restriction Types manage access to customer data within apps and group multiple restriction fields. At the end are Restriction Fields, populated with permission values.

The Business Catalogs within a Business Role dictate the available restriction types. A restriction type is a unit that groups available restriction fields into a logical definition, such as a company code. These restriction fields can be employed to limit access to a specific business object, like an organizational area. Thus, the Business Catalogs within a Business Role outline what a Business User can access. This access can be further refined by limiting the access category for the fields and objects a user can access. An access category specifies the type of access granted to a user assigned to a Business Role, such as read, write, or value help access. These access restrictions can be modified in the Business Role using the Maintain Business Roles app.

Understanding the interplay between Restriction Types and Business Catalogs under the users Business Role layer is vital. A single Restriction Type can govern access across various Business Catalogs, thereby influencing the users Business Roles. At the same time, a single Business Catalog can be associated with numerous Restriction Types.

When managing a business role, the Access Categories section plays an important role in determining access restrictions.

This section comprises three categories:

Write, Read, Value Help: Supersedes all others, providing Write, Read and Value Help controls on all Restriction Fields.

Read, Value Help: Only has Read and Value Help controls on all Restriction Fields but lacks Write control.

Value Help: Only provides the Value Help controls on all Restriction Field and is essentially a list of pre-defined values for selection.

Each category offers three possible access options:

• Unrestricted
• Restricted
• No Access

In most restrictions considerations, the Restricted option is typically chosen to assign the appropriate permission values to the restriction fields.

The Maintain Restrictions window is split into two sections, left and right. The top left corner provides a summary of Access Categories. If you wish to modify Access Categories, you'll need to expand the Access Categories section in the middle. All the Restrictions can be accessed by expanding the Assigned Restriction Types.

The panel on the right displays all the details of each Restriction Type:

Values: Assign authorization values to the Restriction Fields.

Description: Provides an explanation of the Restriction Type, including its purpose, and sometimes, the explanations of these restriction fields.

Business Catalogs: Lists business catalogs this Restriction Type is relevant to.

Restriction Types that contain general organizational Restriction Fields are grouped together into a section called General. As a result, there are many more Restriction Fields than individual Restriction Types.

It is important to be aware of the potential to override restrictions. Consider a scenario where we have two business roles, AdminRole_1 and AdminRole_2. A user may often be assigned multiple business roles. If a certain restriction "A", is present in both roles, but it is applied differently in each - for instance, it’s enforced in AdminRole_1 but not in AdminRole_2 - then the restriction "A" from AdminRole_1 will be overridden for that user. This results in the restriction being lifted entirely.

If the desire is for this restriction to be applied to all business catalogs that this user possesses, the Leading Restriction flag in the Maintain Business Roles app can be selected.

To use the Application Job Templates app, create a business role and assign the SAP_CORE_BC_APJ_TPL catalog to it. This allows access to templates with Write, Read, or No Access permissions. While your own and SAP-provided templates are accessible at all times, other users' private templates do not appear in the Application Jobs app, but can be viewed in the Application Job Templates app.

To change access to the Application Jobs app, create a business role with the SAP_CORE_BC_APJ_JCE catalog. This allows you to modify restriction types and provide necessary permissions, for example, for actions on other users' jobs.

You can also create a display-only role using this restriction type. Define your business role with the Application Job Catalog Entry and Application Job Part fields. If the job owner and the user require different users, the owner must have the Create application jobs for other users permission.

Carl then also describes to Adam the restriction type Create Application Jobs for Other Users. He can, for example, authorize Kelly Keyuser to schedule an application job on behalf of another user, such as Betty Business. This implies that Kelly is responsible for setting up the job, but while the job is in progress, the authorizations of Betty apply. In particular, Betty must have the necessary authorization to start the job. Accordingly, Kelly does not need that start authorization. Adam can also use this restriction type to define which jobs Kelly is allowed to schedule for other users. Actions on other users' jobs could involve deleting a future job, aborting a running job, restarting a job, or viewing a job log, result list, or details. These authorizations are provided through restriction types in suitable business roles.

Carl continues explaining to Adam that this type of restriction allows him to populate the Application Job Catalog Entry and Application Job Part fields when the Restricted mode is activated. The Application Job Catalog Entry field holds the title of a specific application job catalog entry. The Application Job Part field, on the other hand, contains a segment of an application job. This could be the entire job (JOB), the result list of an application job (SPOOL), or the log of an application job (APPLOG).

Carl further clarifies that this restriction type enables Adam to assign permissions to users for specific actions on other users' application jobs, which are based on a particular job catalog entry.

For this he mentions four examples:

To permit a user to view jobs of other users, including job details, select Restricted in the Read section. Then, choose the appropriate Application Job Catalog Entry and then JOB as the value for the Application Job Part.

To allow a user to view the result lists of other users' jobs, select Restricted in the Read section. Then, choose the appropriate Application Job Catalog Entry and both JOB and SPOOL as the Application Job Part.

To authorize a user to delete or cancel other users' jobs, in the Write section, select Restricted. Then, choose the appropriate Application Job Catalog Entry and JOB as the Application Job Part.

To provide a user with full display authorization for all application jobs without any change authorization, in the Write section, select No access. In the Read section, select Unrestricted.

Carl also reminds Adam that the application jobs that a user can display also depend on the job scheduling tile. The SAP_CORE_BC_APJ_JCE business catalog contains the general Application Jobs tile, showing all catalogs. However, many business applications have their own restricted job scheduling tile, which is limited to one or a few job catalog entries. If a user operates with such a tile, its restrictions apply in all cases - in addition to any restrictions from examples provided.

Adam explores how to modify the owner and user of application jobs that have been established from a job template. This is a crucial skill, especially in dynamic business environments.

For instance, consider a scenario where an employee gets promoted or transferred to a different department. In such cases, their previous responsibilities, including managing certain application jobs, may need to be reassigned to another individual. Similarly, if an employee leaves the organization, their associated business user account may need to be removed, and the jobs they were handling reassigned.

This ensures a smooth transition of responsibilities and maintains the continuity of important tasks within your organization.

Participate in the following practice simulation with Carl and Adam. This will help you understand how Carl takes over the administrative application job previously scheduled by Adam and sets himself as the new job owner.

At the end of this lesson, Carl shows Adam what activities he has performed so that Kelly could access the general Application Jobs app.

As Adam has learned, creating a new Business Role is a process that involves choosing the appropriate Business Catalogs. These roles are crucial in managing access to your applications. When you create a Business Role, you are essentially integrating one or more Business Catalogs. These ready-made catalogs contain the permissions that allow users to use apps and, if needed, set up instance-specific restrictions. Each business catalog brings together authorizations for a specific business area. Once a Business Role is created, it can be assigned to multiple Business Users who perform similar business activities.

On Adam's request, Carl lists all the actions as an overall picture, since Kelly, as a non-administrator, would not have had access to the app.

Join Carl and Adam in a step-by-step practice simulation on the process of creating a Business Role to access the Application Jobs app.