Implementing customer specific logic for Decoupled Infotype triggered through ESS/MSS

Implementing customer specific logic for Decoupled Infotype

triggered through ESS/MSS

Applies to: SAP HR ECC 6.0 onwards

Summary
This tutorial explains SAP introduced Concept of Decoupled framework Info types. In this concept for Info
types which are decouple and when they published on Portal (ESS/MSS) for End user then customer specific
validations are done in different way as compare to the Old Validation Method.

Customer Exit triggered from ESS/MSS

Page 1

Implementing Customer specific Logic for Decoupled Infotype triggered through ESS/MSS

Table of Contents
Summary........................................................................................................................................ 1
Implementing Enhancement Spot for Decoupled Info Types Checks.............................................3
Methods that should be implemented in BADI HRPAD00INFTYBL Definition:............................6
Methods that should be implemented in BADI HRPAD00INFTYDB Definition:...........................8
Related Content.............................................................................................................................. 9
Disclaimer and Liability Notice...................................................................................................... 10
Implementing Enhancement Spot for Decoupled Info Types Checks
For Implementing the Customer check when ESS/MSS is introduced for End User then for Decouple info
Types we have to implement the Enhancement Spot HRPAD00INFTYBL as shown in the screen shot below
through transaction SE18.

Once this has been selected then we will create an Enhancement Implementation for this Enhancement Spot
as shown in Screen shot below:

Once we have created and click on Ok, then we will get the below screen as shown in screen shot below
where we have to select for which BADI definition we have to Implement this.

Customer Exit triggered from ESS/MSS

Page 2

Implementing Customer specific Logic for Decoupled Infotype triggered through ESS/MSS

In Above screen shot we have 2 BADI Definition HRPAD00INFTYBL & HRPAD00INFTYDB. The above 2
BADI Definitions are for Customer Specific checks during run time (HRPAD00INFTYBL is used) and for
modifications in the Database (HRPAD00INFTYDB) after customer specific checks.
On selection of BADI Definition, a pop will appear as shown below:

In this we have to Select Empty Class and then Click on OK. We will get screen as shown below in screen
shot. In this we have to provide package.

Customer Exit triggered from ESS/MSS

Page 3

Implementing Customer specific Logic for Decoupled Infotype triggered through ESS/MSS

Once package is provide it will ask for Transport in which request should be saved. Once all this is done then
we will get the screen as shown below which will have both the BADI Implementation created above.

NOTE: In above screen shot we have selected BADI Definition Z_TEST_DECOUPLE_BL. Key point over
here is to make sure we have to maintain Single Implementation of BADI HRPAD00INFTYBL for all
different Developments as SAP has not provided multiple use Option of this. Refer below screen shot:

For HRPAD00INFTYDB we can have multiple Implementation of BADI. Refer below screen shot:

Best Practice for Implementing the above Enhancement Spot: During Project Implementation/support we
Customer Exit triggered from ESS/MSS

Page 4

Implementing Customer specific Logic for Decoupled Infotype triggered through ESS/MSS

will have multiple developments for incorporating the customer specific checks. In this way we will End up
creating One BADI definition for HRPAD00INFTYBL and multiple BADI Definition for HRPAD00INFTYDB.
Instead of this we Create a One-to-One BADI Definition for Both the BADI HRPAD00INFTYBL and
HRPAD00INFTYDB. And after that we create a Class for different-different developments and then call the
same in Z BADI Definition. Refer Below Screen shot:

From above screen shot we see that we have One Z BADI Definition for both the BADIs. In this Z definition
we will call the Created Classes for all different Technical development as shown in below screen shot.

Methods that can be implemented in BADI HRPAD00INFTYBL Definition:

In this we have methods as shown below in screen shot:
Customer Exit triggered from ESS/MSS

Page 5

Implementing Customer specific Logic for Decoupled Infotype triggered through ESS/MSS

Short Description of Methods of this class defines there usage. For ex:

INITIALIZE METHOD: To initialize the value on Portal before View is visible to user then this method
should be used to default the values.

INSERT COMPUTATION: This method is used to check if Insert is allowed as well as compute
derived values during insert. Customer specific checks will be performed after SAP specific checks.
If SAP specific checks fail then customer exit will not be called.

MODIFY COMPUTATION: This method is used to check if Modify is allowed as well as compute
derived values during Modify. Customer specific checks will be performed after SAP specific checks.
If SAP specific checks fail then customer exit will not be called.

DELETE COMPUTATION: This method is used to check if Delete is allowed. Customer specific
checks will be performed after SAP specific checks. If SAP specific checks fail then customer exit will
not be called.

INITIAL COMPUTATION: This method is used to default values if record is newly created
(insert/copy). Customer specific defaulting will be performed after SAP specific defaulting. If SAP
specific defaulting logic fails then customer exit will not be called.

READ COMPUTATION: This method may be used to add or compute derived values into the
records after reading them from the database. Customer specific post read will be performed after
SAP specific post read. If SAP specific post read methods fail then customer exit will not be called.

METADATA COMPUTATIONS: This method is used to compute Metadata values during

Insert/Modify/Delete. Based on the metadata values (field attributes: READ ONLY, MANDATORY,
UNUSED) of the fields in the structure further validations and computations are performed.
Customers can modify metadata computed by SAP. This method needs to be implemented only if
the metadata defined using customizing t588mfprops/t588mfpropc is not sufficient.
Above methods define what the purpose of them is. For more information about the way they should
be implemented, refer below screen shot which shows how to read the Importing Parameters of each
method and so on.
NOTE: When End User access Portal there could be a possibility that some users do have the
access to do the same thing from Portal and from ECC as well. In this case the best way to
handle both the requirements is to Implement the EXIT_SAPFP50M_002 and then call the
same from HRPAD00INFTYBL. In this case from where ever the Info type is called (i.e. from
ECC or Portal) the Logic written in EXIT_SAPFP50M_002 is called as this exit is called from
BADI. For both the cases please refer below attached screen shots.

Customer Exit triggered from ESS/MSS

Page 6

Implementing Customer specific Logic for Decoupled Infotype triggered through ESS/MSS

Method to be implemented in BADI HRPAD00INFTYDB Definition:

In this we have methods as shown below in screen shot:

As method name itself suggest, Update/Modify the database the data which is already stored in SAP
database Tables. The BAdI is called, after the decoupled info type framework writes the info type data to the
database. This is done during method FLUSH. BAdI provides information about operations performed on info
type records when written to the database. Implementing the BAdI, the customer can do any additional
database updates or write any customer specific logs. However COMMIT/ROLLBACK must not be
performed within the BADI implementation itself. This BAdI is only called when using the decoupled info type
framework. It corresponds to BAdI HRPAD00INFTY (method IN_UPDATE) that is called by the old info type
framework (PA30, SAP50UPR). As long as both frameworks are used, both BADIs need to be implemented.
The coding provided is no comprehensive implementation of the BAdI. It only illustrates how to access the
data passed in parameter OPERATION_TAB using reference variables and field symbols.

Customer Exit triggered from ESS/MSS

Page 7

Implementing Customer specific Logic for Decoupled Infotype triggered through ESS/MSS

Customer Exit triggered from ESS/MSS

Page 8

Implementing Customer specific Logic for Decoupled Infotype triggered through ESS/MSS

Related Content
www.sap-img.com
www.sdn.sap.com

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces
and therefore is not supported by SAP. Changes made based on this information are not supported and can
be overwritten during an upgrade.
SAP will not be held liable for any damages caused by using or misusing the information, code or methods
suggested in this document, and anyone using these methods does so at his/her own risk.
SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of
this technical article or code sample, including any liability resulting from incompatibility between the content
within this document and the materials and services offered by SAP. You agree that you will not hold, or seek
to hold, SAP responsible or liable with respect to the content of this document.

Customer Exit triggered from ESS/MSS

Page 9