Unexpected Behavior in BAdI HRPAD00INFTY Implementations: What You Should Know

Everyone is familiar with the indispensable BAdI HRPAD00INFTY, a loyal helper when it comes to implementing various business requirements related to personnel administration infotypes. Everything would be fine if it weren’t for one nuance that functional consultants should be aware of. In this note, I’ll try to draw your attention to specific behavioral features of BAdI HRPAD00INFTY implementations.

See the note: How to define additional logic for a PA infotype?

The key feature of BAdI HRPAD00INFTY is that every time a record for any personnel administration infotype is created or viewed, all implementations of this BAdI are called (the method depends on the operation performed on the infotype). This is all orchestrated by class CL_EX_HRPAD00INFTY.

You can confirm this by debugging one of the methods used in this class. For demonstration purposes, I’ll use the BEFORE_OUTPUT method of this class. First, make sure the BAdI has multiple implementations. This can be checked using transaction SE18.

Then, set a breakpoint in the BEFORE_OUTPUT method of class CL_EX_HRPAD00INFTY and try opening any infotype.

The following sequence of actions is hopefully clear from the video snippet:

At the beginning of the BEFORE_OUTPUT method execution in CL_EX_HRPAD00INFTY, the system collects information about all active implementations and their implementing classes (into internal table EXIT_OBJ_TAB).

Then, the system calls the BEFORE_OUTPUT method of each implementing class individually.

You might not give much thought to how your new implementation works—until something goes wrong while using transactions that handle core employee master data like PA20/PA30/PA40. And by “something,” I don’t mean a minor issue, but dumps. But let’s not get ahead of ourselves—let’s go step by step.

Suppose you’ve created a new BAdI HRPAD00INFTY implementation that performs an important check. You carefully added an ABAP condition to restrict its execution to your specific infotype, thinking this will prevent it from running on others. For example:

During testing, everything looks fine, since you’re working with the exact infotype for which the implementation was created. No complaints from colleagues either. For example:

Let’s say your development is transported to production. But for some reason, one of the objects used in your implementation doesn’t make it to the production system. You might say this is unlikely—but I would disagree. It can happen. The reasons why an object might fail to reach the target system aren’t discussed here.

So, one of the objects doesn’t make it to production, and a business user starts performing their regular tasks with personnel master data. The key point here is that the user works with infotypes that have nothing to do with your implementation. You assume nothing bad can happen. For example, the user creates a record for Infotype 0006 – "Addresses". In the video snippet:

When creating a record for infotype 0006 via transaction PA30, a dump occurs, indicating that an object required by the new BAdI implementation is missing in the system.

Yes, this is the moment I referred to earlier. Regardless of how good your ABAP code is, or how many checks you implement to restrict it to a specific infotype, if any implementation contains a critical error, it will disrupt the operation of essential personnel master data transactions. Forgot about PA40? Let's fix that.

That’s all from me. As always, hugs. Yours, ignatov.