Show TOC

 Enhancements for SAP E-Recruiting 6.0 SP8 (Support Package 8)

SAP delivers the following enhancements for SAP E-Recruiting within the framework of Support Package 8.

Web Dynpro ABAP as Interface Technology for Internal and External Candidate Scenarios

Once the Support Package has been installed, Web Dynpro ABAP is available as another interface technology for the internal and external candidate scenarios, in addition to the Business Server Pages (BSP). Using Web Dynpro ABAP enables you to separate front-end and backend for these scenarios, in other words to run the front-end and backend on different systems. In this way, you can place the front-end outside the company's firewall and the data in the backend system remains protected behind the firewall. The RFC connections between the front-end and the backend are secured through authorization objects, meaning that a user cannot call in the front-end an arbitrary RFC-capable module in the backend. These authorizations are already characterized in the standard roles, which means that the user has the minimum necessary access rights only. For more information, see the documentation for SAP E-Recruiting under Roles for Interfaces with Web Dynpro ABAP , the Security Guide for SAP E-Recruiting, and SAP Note 1017866 (Consulting note: Candidate scenarios using Web Dynpro). For the Security Guide, see SAP Library and choose mySAP ERP Security Guides → SAP ERP Central Component Security Guide → Human Resources → SAP E-Recruiting .

The following system constellations are possible:

  • Front-end and backend are on the same server, the scenarios of the internal and external candidate run on one server. SAP E-Recruiting uses Web Dynpro ABAP as the interface technology.

  • Front-end and backend are separated and run on different servers. External and internal candidates access the application via the front-end system. SAP E-Recruiting uses Web Dynpro ABAP as the interface technology.

  • Front-end and backend are separated and run on different servers. External candidates access the application via the front-end system and internal candidates access the application via the backend system. SAP E-Recruiting uses Web Dynpro ABAP as the interface technology.

Customizing

Within the new development, SAP delivers the following new roles relevant for Web Dynpro ABAP:

Roles for Interfaces with Web Dynpro ABAP

Technical Name

Name

SAP_RCF_UNREG_CANDIDATE_CLIENT

Unregistered Candidate (Client)

SAP_RCF_UNREG_CANDIDATE_SERVER

Unregistered Candidate (Server)

SAP_RCF_EXT_CANDIDATE_CLIENT

External Candidate (Client)

SAP_RCF_EXT_CANDIDATE_SERVER

External Candidate (Server)

SAP_RCF_INT_CANDIDATE_CLIENT

Internal Candidate (Client)

SAP_RCF_INT_CANDIDATE_SERVER

Internal Candidate (Server)

For information about the roles, see the documentation for SAP E-Recruiting under Roles for Interfaces with Web Dynpro ABAP .

Settings for User Interfaces with Web Dynpro ABAP

Within the new development, the following IMG activities are delivered to enable the use of Web Dynpro ABAP as the interface technology in SAP E-Recruiting. Note that if the front-end and backend run on separate systems, you must make some settings in the front-end system and other settings in the backend system.

Settings in the Front-End System

In your front-end system, you perform the following IMG activities that are new in Support Package 8:

  • Create Special Users for Front-End System (Web Dynpro ABAP)

    In this IMG activity, you create service users and reference users for the scenarios that are required when using Web Dynpro ABAP in a separated system.

  • Specify Role Assignment for Service Users and Reference Users

    In this IMG activity, you assign to service users and reference users the roles that are required when using Web Dynpro ABAP in a separated system.

    For this, SAP delivers the following roles in Support Package 8:

    • SAP_RCF_UNREG_CANDIDATE_CLIENT

    • SAP_RCF_EXT_CANDIDATE_CLIENT

    • SAP_RCF_INT_CANDIDATE_CLIENT

  • Create RFC Connection to Backend System

    In this IMG activity, you create an RFC connection from the front-end system to the backend system, whereby the Remote Function Call can be executed in the backend system without the user having to specify an explicit password ( SAP Trusted System (RFC Single Login) ).

  • Enter RFC Destination of Receiving Backend System

    In this IMG activity, you enter the RFC destination of the receiving backend system as a value of the new parameter RECFA UI2BL.

  • Specify E-Recruiting Services (Web Dynpro ABAP)

    In this IMG activity, you can activate the services that you want to use in SAP E-Recruiting when using Web Dynpro ABAP in a separated system (front-end and backend on different systems). You can also assign a service user to the services that are used by unregistered users.

    SAP delivers a range of new services for Web Dynpro ABAP. For more information, see the documentation for the IMG activity.

    Settings in the Backend System

In your backend system, you perform the following IMG activities that are new in Support Package 8:

  • Create Special Users for Backend System (Web Dynpro ABAP)

    In this IMG activity, you create service users and reference users for the scenarios that are required when using Web Dynpro ABAP in a separated system.

  • Specify Role Assignment for Service Users and Reference Users

    In this IMG activity, you assign to service users and reference users the roles that are required when using Web Dynpro ABAP in a separated system.

    For this, SAP delivers the following roles in Support Package 8:

    • SAP_RCF_UNREG_CANDIDATE_SERVER

    • SAP_RCF_EXT_CANDIDATE_SERVER

    • SAP_RCF_INT_CANDIDATE_SERVER

  • Create RFC Connection to Front-End System

    In this IMG activity, you create an RFC connection from the backend system to the front-end system.

  • Specify System Parameters for Web Dynpro

    In this IMG activity, you specify the system parameters that you require for displaying user interfaces using Web Dynpro ABAP.

    SAP delivers the following new parameters in Support Package 8:

    • RECFA WEBUI

      Specifies whether the candidate scenarios use Web Dynpro ABAP or BSP technology.

    • RECFA BL2UI

      Contains the name of the receiving front-end system.

    • RECFA SYEMP

      Specifies whether the scenarios of the internal candidate run on the front-end system like those of the external candidate or in the backend system.

    • RECFA LOCFI

      Specifies whether a candidate can enter all possible entries when entering the desired work location or only entries for existing branches of the company.

  • Assign Values to Interface Parameters (Web Dynpro ABAP)

    In this IMG activity, you can overwrite the values of the interface parameters delivered in the standard system for user interfaces using Web Dynpro ABAP.

  • Specify URL Parameter for Applications with Web Dynpro ABAP

    In this IMG activity, you can redefine the parameter values delivered in the standard system with values of your own choosing for a range of URL parameters for SAP E-Recruiting.

    SAP delivers the following new parameters in Support Package 8:

    • THEME_URL

      You can use this parameter to influence the layout of Web Dynpro applications by entering the path to a third-party theme.

    • RIGHT_TO_LEFT

      You can use this parameter to specify how the objects (texts, input fields, and so on) are aligned on the user interfaces of Web Dynpro applications.

    • ACCESSIBILITY_MODE

      You can use this parameter to specify that the Web Dynpro applications are accessible within SAP E-Recruiting.

  • Store URLs for Language-Dependent Data Privacy Statements

    In this IMG activity, you can enter a link to a data privacy statement for each of the possible logon languages.

Flexibilization of Web Dynpro Applications

Within the new development, the following IMG activities are delivered to enable customizing of the interfaces of Web Dynpro applications in SAP E-Recruiting to suit the customer's requirements. Note that if the front-end and backend run on separate systems, you must make some settings in the front-end system and other settings in the backend system.

Settings in the Front-End System

BAdI: Specify Application Configuration for Application Wizard

You can use this BAdI to set a Web Dynpro application configuration for the application wizard and thus to hide or show, for example, certain fields on the interface as required.

Settings in the Backend System

Start Pages

  • In the IMG activities Create Structuring Elements for First Level and Create Structuring Elements for Second Level , you can create user-defined structuring elements for start pages.

  • Define Start Pages

    In this IMG activity, you can change the start pages delivered in the standard system for Web Dynpro ABAP to suit your own requirements. You can also use user-defined structuring elements here. In addition, you can define different variants for the same start page.

Roadmap Pattern

  • Create Roadmap Steps

    In this IMG activity, you create user-defined roadmap steps.

  • Create Roadmap Pattern

    In this IMG activity, you can change the roadmap patterns delivered in the standard system to suit your own requirements. You can also use user-defined roadmap steps here. In addition, you can define different variants for the same roadmap pattern.

After the installation, note the following:

In the standard system, the system behavior is identical to the behavior before the Support Package was installed. If you want to use Web Dynpro ABAP for the candidate scenarios, you must perform the IMG activities listed above.

Dashboard

Worklist as Target Worklist

Once the Support Package is installed, the new function WLNAV is available in the Confirmations application area. You can use this function to refer from a worklist in the Confirmations application area to another worklist. To do this, you store in the worklist's function profile the WLNAV function and the technical name of the worklist that serves as a target worklist. You also enter the name of the reference field whose value is used to filter the entries in the target worklist.

Once a user executes the function, the worklist that was stored as the target worklist is called.

Note Note

Worklists that you specify as target worklists in the function profile are not displayed by the system in the navigation tree.

End of the note.

In the standard system, SAP delivers the Confirmations (Works Council Hearing) worklist for which the Alternative Candidates worklist is stored as the target worklist. For more information about this, see the following sections.

New Worklist: Confirmations (Works Council Hearing)

The dashboard delivered in the standard system for recruiters was enhanced in the Confirmation Activities work area with the Confirmations (Works Council Hearing) worklist.

The output profile of the worklist is set up such that the user sees the Individual Confirmations of the Confirmation of Works Council Hearing activity type (9001) that have the status Planned ; in other words, the confirmations that the user has received from other users that still need processing.

It makes sense to use the new Confirmations (Works Council Hearing) worklist in a dashboard for works council members, for example. If a works council is included in the recruitment process, it must view potential candidates for the vacant job and appraise them from a works council perspective. This occurs using the Confirmations of Works Council Hearing .

In addition, the user can use the Alternative Candidates function to call a list of candidates who are assigned to the relevant requisition too and were previously proposed as alternative candidates. The new Alternative Candidates worklist is used to display the list of alternative candidates.

The Confirmations (Works Council Hearing) worklist is a selection-based worklist, this means that the system uses selection criteria to read the values from application tables.

New Worklist: Alternative Candidates

The dashboard delivered in the standard system for recruiters was enhanced with the Simple Activities work area with the Alternative Candidates worklist.

Note Note

This worklist is called as a target worklist using the Alternative Candidates function in the Confirmations (Works Council Hearing) worklist. Therefore, the worklist is not displayed in the dashboard's navigation tree in the standard system. The Simple Activities work area is not visible in the navigation tree since the Alternative Candidates worklist is the only worklist for this work area in the standard system.

End of the note.

The output profile of the worklist is set up such that the user sees a list of candidates who - in addition to the current candidate - were assigned to the relevant requisition and were also proposed as alternative candidates.

Note Note

Alternative candidates are candidates who have an activity of the Propose as Alternative Candidate activity type (1901) assigned to their assignment to the requisition.

End of the note.
Customizing

The new Simple Activities work area is provided within the framework of the Customizing for the dashboard. The settings are stored for the Alternative Candidates worklist and the Confirmations (Works Council Hearing) worklist.

More Information

For more information, see SAP Library in the documentation for SAP E-Recruiting under Dashboard and Dashboard for the Recruiter (Standard System) .