Show TOC

 HRPAD00AUTH_CHECK (BAdI: Customer-Specific Authorization Checks)

Definition

Business Add-In (BAdI) that you can use to replace the SAP standard authorization check with a customer-specific authorization check for HR master data and infotypes.

Use

If your requirements of the authorization check for HR Master Data infotypes cannot be met by either the standard system or by a customer-specific authorization object, you can replace the authorization checks completely without modification (as of Release 4.6C). For this, you use Business Add-Ins (BAdI). The BAdI for the master data authorization check is called HRPAD00AUTH_CHECK.

Note Note

You can find the Business Add-In (BAdI) in the IMG for Personnel Management under Start of the navigation path Personnel Administration Next navigation step Tools Next navigation step Authorization Management Next navigation step BAdI: Set Up Customer-Specific Authorization Check End of the navigation path . You can find information on implementing a BAdI in the documentation of the corresponding IMG activity.

As soon as an implementation for this BAdI is active,allHR master data authorization checks are stopped and instead only the activated implementation is performed.

You can implement this BAdI using the SE19 transaction.

In this context, note that access to documentation in this transaction does not work properly sometimes. If this is the case, you can access the documentation using the SE18 transaction and the corresponding BAdI (here: HRPAD00AUTH_CHECK) or using the SE24 transaction and the corresponding interface (here: IF_EX_HRPAD00AUTH_CHECK): Double-click an interface name to leave transaction SE18 or SE19 and go to transaction SE24 where you can access the documentation of each method.

End of the note.

In order to accommodate the numerous requirements of the authorization check, the IF_EX_HRPAD00AUTH_CHECK is kept relatively open. The following methods are available and mustallbe implemented:

CHECK_MAX_INFTY_AUTHORIZATION

CHECK_MAX_LEVEL_AUTHORIZATION

CHECK_MAX_SUBTY_AUTHORIZATION

CHECK_MIN_INFTY_AUTHORIZATION

CHECK_MIN_LEVEL_AUTHORIZATION

CHECK_MIN_SUBTY_AUTHORIZATION

SET_ORG_ASSIGNMENT

SET_PARTIAL_ORG_ASSIGNMENT

CHECK_AUTHORIZATION

CHECK_MAX_PERNR_AUTHORIZATION

CHECK_MIN_PERNR_AUTHORIZATION

CHECK_PERNR_AUTHORIZATION

DELAYED_CONSTRUCTOR

If you want to make only one change to a specific subfunction of the standard authorization check (for example, a change to the time logic), simply copy the CL_HRPAD00AUTH_CHECK_STD class used in the standard system, adjust the (customer-specific) copy to your requirements, and then activate the copy as a BAdI (see also example ). It is not advisable to adjust only the CHECK_AUTHORIZATION method for this. This may be sufficient in certain cases but often this kind of adjustment automatically requires changes to be made to the other methods.

Structure

This section explains the role played by the various methods of the IF_EX_HRPAD00AUTH_CHECK interface during the authorization check. The method interfaces are stored in the system as documentation of the corresponding methods. Review the method documentation of the corresponding method if you are implementing a new method or changing method.

  • CHECK_AUTHORIZATION

This method is the central method of the authorization check on HR Master Data infotypes. The CHECK_AUTHORIZATION method is processed during each authorization check at single record level.

During implementation, ensure that this method is also processed when you perform hiring actions. In particular cases, there are no data records available in the database for the Actions (0000) and Organizational Assignment (0001) infotypes at the point when the method is processed.

Also ensure that the correct interaction with the ..._ORG_ASSIGNMENT methods is achieved during implementation.

  • SET_ORG_ASSIGNMENT

This method is called by applications that have already read all the data records of the Organizational Assignment (0001) infotype and want to prevent this data from being read again in the authorization check. This method should be used for performance tuning only.

  • SET_PARTIAL_ORG_ASSIGNMENT

Since the organizational assignment is only partly known during hiring actions, a normal authorization check is not possible as the data required for this check is not yet available in the system. To enable at least a rough check to be carried out, the application transfers the currently known fields of the Organizational Assignment infotype (0001) to the authorization check using this method.

  • CHECK_MAX_LEVEL_AUTHORIZATION

This method is called by applications that want to know if a user has maximum authorization for an authorization level. In other words, if the user can access all infotypes and all personnel numbers for the authorization level specified.

If this method returns the result IS_AUTHORIZED = TRUE , the calling applications do not normally perform any more authorization checks. If this method returns the result IS_AUTHORIZED = FALSE , the calling applications normally perform more specific authorization checks.

The aim of this method call is performance tuning, that is the method should return a rough result as quickly as possible. Apart from the performance point of view, it is unproblematic from an authorization perspective if the method always returns IS_AUTHORIZED = FALSE because the relevant applicants then perform additional checks. It can become critical, in comparison, if the method delivers IS_AUTHORIZED = TRUE for users with insufficient authorization because the system grants access without any additional authorization checks. It is therefore particularly important that this method either is implemented in accordance with the CHECK_AUTHORIZATION method or always returns IS_AUTHORIZED = FALSE .

What is more, the applications that call these methods assume that the response time is well under a second. Implementations that check the authorizations of all personnel numbers in the system are therefore especially inappropriate at this point.

  • CHECK_MAX_INFTY_AUTHORIZATION

This method is similar to the CHECK_MAX_LEVEL_AUTHORIZATION method. The only difference is that it determines whether a user has maximum authorization for a given infotype and a given authorization level. The remarks on the CHECK_MAX_LEVEL_AUTHORIZATION are also valid here.

  • CHECK_MAX_SUBTY_AUTHORIZATION

The same applies for this method as for the CHECK_MAX_INFTY_AUTHORIZATION method except that this method determines whether a user has maximum authorization for the subtype of a given infotype and a given authorization level.

  • CHECK_MIN_LEVEL_AUTHORIZATION

This method is called by applications that want to determine whether a user has minimum authorization for an authorization level. In other words, if the user can access at least one (not necessarily existing) data record of an infotype for a personnel number for the authorization level specified.

If this method returns the result IS_AUTHORIZED = FALSE , the calling applications do not normally perform any more authorization checks.

The aim of this method call is to prevent users from accessing data as early as possible. In other words, instead of being denied access to every function he or she performs, a user should not be able to start the relevant transaction in the first place. As with checks for maximum authorization, the check only needs to return a rough system response as quickly as possible. Apart from performance and accessibility points of view, it is unproblematic from an authorization perspective if the method always returns IS_AUTHORIZED = TRUE because the relevant applicants then perform additional checks anyway. It is problematic if the method returns IS_AUTHORIZED = FALSE for users who have appropriate authorizations because the system denies access in the foreground. It is therefore particularly important that you implement this method in accordance with the CHECK_AUTHORIZATION method or that it always returns IS_AUTHORIZED = TRUE .

What is more, the applications that call these methods assume that the response time is well under a second. Implementations that search this long for a data record of a personnel number for which authorization exists are, therefore, particularly inappropriate at this point.

  • CHECK_MIN_INFTY_AUTHORIZATION

This method is similar to the CHECK_MIN_LEVEL_AUTHORIZATION method. The only difference is that it determines whether a user has minimum authorization for a given infotype and a given authorization level. The remarks on the CHECK_MIN_LEVEL_AUTHORIZATION method are also valid here.

  • CHECK_MIN_SUBTY_AUTHORIZATION

The same applies for this method as for the CHECK_MIN_INFTY_AUTHORIZATION method except that this method determines whether a user has minimum authorization for the subtype of a given infotype and a given authorization level.

  • CHECK_PERNR_AUTHORIZATION

This method is called by applications outside HR master data that want to check if a user should be granted access to a specific personnel number. This is problematic from a master data point of view because the personnel number as such is not stored in HR master data as an object. Master data management recognizes only infotypes. For this reason, the logic of a check on the access authorization for a personnel number is unclear from a master data perspective. Therefore, the standard system checks the authorization for the dummy infotype < BLANK > if you use this method.

Instead of this method, some applications call one of the following methods:

  • CHECK_MAX_PERNR_AUTHORIZATION

This method is called by applications that want to determine whether access authorization exists for all the infotypes/subtypes of a specified personnel number, that is whether a full authorization for access to all data of a personnel number exists. The standard system implements the check by specifying * in the INFTY and SUBTY fields for the AUTHORITY-CHECK statement. The system does not check if users can access each existing infotype but if users could access all conceivable infotypes (even if these infotypes do not exist in the system).

  • CHECK_MIN_PERNR_AUTHORIZATION

This method is called by applications that want to determine whether access authorization exists for one data record of the specified personnel number, that is whether a minimum authorization for access to at least one data record of the personnel number exists. The standard system implements the check by specifying DUMMY in the INFTY and SUBTY fields for the AUTHORITY-CHECK statement. The system does not check if users can access an existing infotype but if users could access any conceivable infotype (even if this infotype does not exist in the system).

  • DELAYED_CONSTRUCTOR

The BAdI function does not allow the Constructor to be specified in the interface. The DELAYED_CONSTRUCTOR method is used in the interface for this reason. The method is always processed directly after the constructor. The method interface enables you to obtain information about the environment of instance creation.

The parameters of this method are the result of very specific customer requirements that were taken into account when the interface was developed. It is only meaningful in certain special cases to evaluate these parameters. It is therefore advisable not to implement this method in most cases and instead to use the normal constructor.

See also:

Examples of the HRPAD00AUTH_CHECK BAdI

Example of the Implementation of HRPAD00AUTH_CHECK