ESS Personal information scenario is one of the most commonly and heavily customized scenario. With Enhancement package 5 a newly architected ESS Personal profile was released based on WD ABAP and FPM. The backend parts remained mostly same as JAVA scenarios but some new layers and customizing options are introduced. This blog gives “Architectural Deep-Dive” to understand what are extension possibilities and in which layers.
This blog assumes that you are familiar with basic infotype concept, with using customizing tables, BAdIs and FPM configurations.
See diagram below to understand layers of coding and configurations
Layer 1: PA Infotype framework
IMG: Personnel Management -> Personnel Administration -> Customizing Procedures -> Infotypes
ESS personal information scenario uses “Decoupled Infotype framework” . In this layer the actual business logic is implemented. This logic is independent of ESS and is reused in other layers as well. The logic is implemented by means of a business logic check class. If you decide to implement a change in logic of existing infotype or decided to create a new infotype then you start at this layer.
Customizing options
Transaction PM01 – Enhance or create new infotypes
Business logic check classes: V_T582ITVCLAS, V_T582ITVCHCK
BAdIs:
HRPAD_SUBTY_CHECK – Validation of permissible subtypes (normally not needed due to standard customizing tables)
HRPAD00INFTYBL – To create customer specific validations and update logic
HRPAD00INFTYDB – To write DB update logic (e.g. to write additional customer tables or log tables)
Customizing field attributes: V_T588MFRPOPS (SAP standard), V_T588MFPROC (customer specific)
Test Transaction: PUIT_UI can be used to validate the changes made
Layer 2: PA UI Conversion Layer
IMG: Personnel Management -> Personnel Administration -> Customizing Procedures -> Infotypes
In this layer the infotype structures are adapted so that they can be easily consumed in UI consumption layers built above. Screen structures are created so that they have fields required for UI layers like description and text fields, fields from infotype views ..etc. For infotypes which have repeat fields (like wagetypes in 0008) line structures are created. For each UI structure a conversion class (defined in T588UICONVCLAS) is used which performs input/output conversion from infotype stuctures to screen structures. In this layer the screen structures are created such that each country version has its own structure.
This layer needs to be considered if you have created a custom infotype or extended standard infotype structures with custom fields which require some explicit input/output conversion.
You can use this layer if you need to change some metadata of UI fields (like mandatory, hidden)
Customizing options
Transaction PM01 – Enhance or create new infotype UI parts
UI Logic Conversion classes: V_T588UICONVCLAS
BAdI: HRPAD00INFTYUI – To write UI conversion logic, mapping of fields and field attribute determination
Test Transaction: PUIT_UI can be used to validate the changes made
:!: NOTE: Enhancements done in Layer1 and Layer2 are independent of ESS and are also applicable for other scenarios like HCM Processes and Forms and in future releases for HR Administration UI. If you write any logic or change any attributes then they will be also applied in other UI screens
IMG: Personnel Management -> Employee Self-Service (Webdynpro ABAP) -> Service-Specific settings -> Personal Information
On top of UI conversion layer ESS Adapter CL_HRPA_PERNR_INFTY_XSS is developed. This layer performs ESS specific operations like Create,Read,Update,Delete. This layer performs some specific extensions to business logic by providing specific customizing options.
Examples of customizing options: ESS specific timeconstraint handling also known as ESS use cases which control visibility of Create, Delete, Update buttons and display of validity fields. This layer also restricts which subtypes are allowed for ESS. In this layer also specific logic of reuse of country version structures for other countries are allowed.
Customizing options
V_T7XSSPERSUBTY – Assign permissible infotypes and Use cases (time constraints and validity periods)
BAdI HRXSS_PER_SUBTYPE – Programmatically control visibility of subtypes and use cases that can not be statically defined via V_T7XSSPERSUBTY
V_T7XSSPERFORADD & BAdI: HRXSS_PER_FOREIGN_ADDRESS – Define permissible Foreign Address handling
V_T7XSSREUSEUISN – Allow reuse of country versions screens in other country versions
BAdI: HRXSS_PER_BEGDA – Control visibility of records and set default begin dates[GK1] . For e.g., to enable past data editing. Or, restrict editing to starting from future date – for e.g., begin of next month.
IMG: Personnel Management -> Employee Self-Service (Webdynpro ABAP) -> Service-Specific settings -> Personal Information
The Business Object Layer (BOL) model is a programming concept that allows for uniform application development, decoupled from interface changes in the underlying business-object-specific Application Programming Interfaces (APIs).
This layer initially built for CRM UI is now used in many business suite applications.
For HCM the model name is HRPAD. As of now this model is used for ESS but in future releases this model is used for even HR Administration scenarios. The model is implemented by a Generic Interaction Layer class CL_HRPAD_IL.
This layer needs to be considered only when a new custom infotype needs to added.
Customizing options
Transaction: HRPAD_EDIT_MODEL – To introduce new infotypes
Transaction: GENIL_MODEL_EDITOR – To check and transport models
Test Transaction: GENIL_BOL_BROWSER can be used to validate the changes made and data is visible in BOL (This transaction needs some knowledge and not very easy to test)
Layer 5: ESS UI Layer using FPM
FPM Layer offers countless number of possibilities to enhance the standard applications so you need to decide what really needs to be changed and for which portions you want to copy standard configurations or feeder classes.
http://scn.sap.com/community/erp/hcm/employee-self-service/blog/2012/06/07/enhancing-essmss-wd-abap-...
Personal information Overview and detail screens are built using FPM GUIBB. The metadata, actions and events are processed using FPM feeder classes CL_HRESS_PER_OVERVIEW and CL_HRESS_PER_DETAIL. In some cases there may be infotype specific feeder classes. In case if you are not able to achieve logic enhancements using any layers below then this is your last fallback option.
Personal information scenario uses FPM Overview floorplan (OVP). HRESS_CC_PER_OVP is the component configuration that can be enhanced to add/enhance the UI blocks
For every infotype screen a list and detail configuration is created. Example HRESS_CC_PER_OVR_BANK_XX and HRESS_CC_PER_DTL_BANK_XX. You need to enhance these to create customer specific configurations
Layer 5.3: UI Composition Configuration
Personal information profile uses various country specific configurations dynamically. This is achieved by Application controller component HRESS_C_PERSINFO_CONFIG. You can configure HRESS_CC_PER_CONFIG to dynamically replace the UIBBs.
In standard implementation the dynamic assembly is done based country/molga of employee but you can use BAdI HRESS_PER_CONFIG_KEY so that other parameters like Employee group, Subgroup can also be used.
WD ABAP Application
WD Application HRESS_A_PERSINFO is used with application configuration HRESS_AC_PERSINFO. You can also pass some application parameters to influence the UI behavior (e.g. starting from enhancement pack 6 you can make profile read only)
Some typical scenarios to enhance ESS Personal profile
Note: You have many alternative ideas to implement every scenario but this table just gives a guidance
Layer 1-4 requires backend customizing and development knowledge to implement BAdI
Layer 5 requires FPM knowledge
Apart from this you may go for implicit coding enhancement options at various layers but it is not recommended since SAP may change internal processing logic in future releases.
Scenarios | Possible Layer affected (customizing required using customizing tables or BAdIs) |
Changing field attributes - making field mandatory, read-only, hidden | Layer 1 & 2 if this is not specific to ESS E.g. V_T588MFPROC or BAdI HRPAD00INFTYBL or HRPAD00INFTYUI Layer 5.1 and 5.2 if this attribute change is specific to ESS using configuration or feeder classes |
Adding or removing existing fields from SAP standard Infotype in ESS UI which are not shipped in default configuration | Layer 5.2 |
Adding or removing customer specific fields in SAP Standard infotype & include them in ESS UI | Layer 1 and 2 – structure changes in customer include and if required UI conversion logic or Business logic validations Layer 5.2 – Add new fields |
Filtering subtypes for ESS only, Changing the timeconstraint for ESS (controlling actions like new, edit, delete button), configuring foreign address scenario | Layer 3 |
ESS subtype usecases are not sufficient and need more dynamic control to decide if certain action buttons like add, delete should be visible | Layer 5.1 |
Adding completely new customer infotype | Layer 1,2 - decouple new infotype using PM01 Layer 3 – optional (only if ESS logic is required) Layer 4 – Add new infotype in BOL Layer 5.2 (5.1 and 5.3 optional) |
Missing country version for standard infotype or reuse another country version | Layer 3 (if reuse is required from different country) Layer 5.2 and Layer 5.3 |
Adding new business logic checks & validations | Layer 1 (assumption is that business logic checks are independent of ESS) |
Updating other infotypes from ESS infotypes | Layer 1 using BAdI HRPA00INFTYBL |
Updating customer specific tables or log files | Layer 1 using BAdI HRPA00INFTYDB |
Post processing like triggering some mails/notifications | Use standard processing as far as possible using SWEHR* transactions and standard event processing. If this is not sufficient then use BAdI HRPA00INFTYDB in Layer 1 |
If you have more scenarios which you have customized using different technique then do let me know and I can try to include them in the blog!
- SAP Managed Tags:
30 Comments
