Ansicht
Dokumentation

HRSFI_BADI_AUTHORITY - BAdI: Authorization Check for SFSF Integration

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   ROGBILLS - Synchronize billing plans  
This documentation is copyright by SAP AG.

This Business Add-In (BAdI) is used for the integration add-on for SAP ERP HCM and SuccessFactors BizX.

You can use this BAdI to perform authorization checks for data that is transferred from SuccessFactors BizX to the SAP ERP system. The implementations that you create for this BAdI run when you call the list of data transferred from SuccessFactors BizX. The SAP ERP system thereby checks whether the user has the required authorizations for the data (for example, the applications imported from SuccessFactors BizX). If this is the case, the system displays the relevant data records.

You can also use this BAdI to assign super user authorization to users.

Note

Users with this authorization can, for example, delete entries from the list of imported applications in the application for the further processing of imported applications (transaction HRSFI_RCT_HIRE). For all other users, the Delete function is deactivated.

The BAdI is also run to check whether a user in the Organization and Staffing applications (transactions PPOCE, PPOME, PPOSE) has authorization for a job requisition to display the data that was transferred to SuccessFactors BizX the last time the data transfer report was run. If the user has this authorization, the Display Fields pushbutton is active on the SFSF Job Requisition tab. The Fields column is displayed for closed job requisitions. If the user does not have this authorization, the pushbutton is inactive and the column is not displayed.

The BAdI uses the following methods:

• CHECK_AUTHORITY with the following parameters:

Import parameters

• IT_SFSF_DATA_FIELDS

Table with all fields and field values transferred from SuccessFactors BizX

IT_MAPPED_DATA

Table with the mapping result (all infotype fields and field values that have been mapped to the fields transferred from SuccessFactors BizX in the SAP ERP system)

Return parameter

• RV_HAS_AUTHORITY

States whether the user has the required authorizations for the imported data

You can use this method to implement authorization checks for data that is transferred from SuccessFactors BizX to the SAP ERP system.

• CHECK_SUPER_USER with the following parameters:

Return parameter

• RV_IS_SUPER_USER

States whether the user has super user authorization

You can use this method to assign super user authorization.

• CHECK_AUTHORITY_REQ_FIELDS with the following parameters:

Import parameter

• IS_POSITION

Return parameter

• RV_HAS_AUTHORITY

States whether the user has authorization to display the transferred fields and field contents

You can use this method to implement authorization checks for the Display Fields pushbutton.

• HRSFI_SCENARIO

States for which integration scenario (for example, integration scenario for recruiting data or integration scenario for compensation data) the authorization check is to be used. You can use this filter value to implement the BAdI more than once to perform different authorization checks for different data.

• CL_HRSFI_IM_AUTHORITY_CHECK

This fallback class uses the method CHECK_AUTHORITY to perform an authorization check for the integration scenario for recruiting data. It first checks whether the data imported from SuccessFactors BizX includes the personnel area, employee group, and employee subgroup. If this is not the case, it issues corresponding error messages. If the data is available, it uses the authorization object P_ORGIN to perform an authorization check. In doing so, it uses the following information for the authorization fields of this authorization object:

• Infotype (INFTY): Infotype as stored in the table with the mapping result

• Subtype (SUBTY): Subtype as stored in the table with the mapping result

• Authorization Level (AUTHC): Write access (W)

• Personnel Area (PERSA): Personnel area as stored in the table with the mapping result

• Employee Group (PERSG): Employee group as stored in the table with the mapping result

• Employee Subgroup (PERSK): Employee subgroup as stored in the table with the mapping result

• Organizational Key (VDSK1): Is not checked

If the authorization profile of the user logged on contains the relevant values for all authorization fields, the user may edit the relevant data record. If not, the relevant data record is not displayed in the application for the further processing of the imported applications (transaction HRSFI_RCT_HIRE).

In addition, the fallback class uses the method CHECK_SUPER_USER to define that no user has super user authorization.

The class uses the method CHECK_AUTHORITY_REQ_FIELDS to specify that all users have authorization for all job requisitions to display the data that was transferred to SuccessFactors BizX the last time that the data transfer report was run.

If you perform authorization checks different from those implemented as standard, and if you want to assign super user authorization, create customer-specific implementations of this BAdI for the integration scenarios of your choice. In doing so, ensure that the data that you want to use for the authorization checks is also transferred from SuccessFactors BizX.

• CL_HRSFI_IM_AUTHORITY_CHECK_PL

This sample implementation uses the method CHECK_AUTHORITY to perform an authorization check for the integration scenario for recruiting data. It first checks whether the data imported from SuccessFactors BizX includes the position. If this is not the case, it issues a corresponding error message. If the position is available, it uses the authorization object PLOG to perform an authorization check. In doing so, it uses the following information for the authorization fields of this authorization object:

• Plan Version (PLVAR): Active plan version

• Object Type (OTYPE): Position (S)

• Infotype (INFOTYP): Relationships (1001)

• Subtype (SUBTYP): Holder (A008)

• Planning Status (ISTAT): Active planning status (1)

• Function Code (PPFCODE): Change (AEND) / create (INSE) / delete (DEL) / delimit (CUTI)

This means that for all positions contained in his or her structural authorization profile, the user logged on can create, change, and delete position holders, as well as delimit the corresponding infotype records.

In addition, the sample implementation uses the method CHECK_SUPER_USER to define that no user has super user authorization.

The class uses the method CHECK_AUTHORITY_REQ_FIELDS to specify that all users have authorization for all job requisitions to display the data that was transferred to SuccessFactors BizX the last time that the data transfer report was run.

ROGBILLS - Synchronize billing plans   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 9283 Date: 20240523 Time: 200022     sap01-206 ( 179 ms )