User Exits, Customer Exits & BAdIs

Enhancement techniques are the supported places to add your logic. There are four generations, and knowing which to use is the point.

Why not just modify the code. A modified SAP object is flagged during every upgrade, and somebody has to compare your version against SAP's new one by hand, in SPAU or SPDD. Do that in a hundred places and upgrades become projects nobody wants to start.

Everything below lives in the customer namespace, so upgrades leave it alone.

1. User exits — empty subroutines. The oldest form: SAP left FORM routines named USEREXIT_* inside standard programs, which you fill in through a customer include.

Mostly in SD, MM and PP. They are tightly coupled to one specific program and there is no interface — you read and write the program's global variables. Encountered in old systems rather than chosen today.

2. Customer exits — SMOD and CMOD. A formalised version: SAP defines an enhancement containing function module slots, and you implement the include inside one.

These have a proper interface — importing, exporting and tables parameters — so you know exactly what you receive and what you may change. The limitation is that one enhancement can be used by only one project.

3. BAdIs — the object-oriented replacement. SAP defines an interface; you write a class that implements it.

Classic BAdIs allow one active implementation per filter value. The newer kind, defined inside an enhancement spot, allows several implementations active at once, each with its own filter, plus a fallback class used when no filter matches.

That difference matters when two projects need to enhance the same point. With a classic BAdI they collide; with the new framework both can be active.

4. Enhancement points and sections. SAP marks specific lines inside standard code as enhanceable:

Implicit enhancement points exist automatically at the start and end of nearly every form, method and program, even where SAP placed nothing. They are the last resort when no BAdI exists — they work, and because SAP never declared that spot an interface, a restructuring of the method in a later release can leave your code attached somewhere that no longer makes sense.

How to choose today. Look for a BAdI first, then a customer exit, then an explicit enhancement point, then an implicit one. Modify standard code only when nothing else is possible, and record why.

In S/4HANA the same question is answered differently again: key user extensibility through Fiori apps, and developer extensibility through released APIs and RAP, both designed to survive cloud upgrades that nobody gets to adjust by hand.

What the interviewer is probing.1. "Which enhancement would you use and why?" Probing: whether you know the hierarchy. Stalls: "A user exit." Moves up: the newest available — BAdI or enhancement spot first, customer exit if that is all there is, and a modification only as a last resort.

2. "Why is a BAdI better than a customer exit?" Probing: the technical difference. Stalls: "It is newer." Moves up: it is object-oriented, supports multiple independent implementations and filters, where a customer exit allows only one include.

3. "What is the problem with modifying standard code?" Probing: the upgrade cost. Stalls: "It works." Moves up: every upgrade hits it in SPAU and it has to be re-adjusted manually forever — and support may decline to help.

4. "How do you find the right exit for a transaction?" Probing: the method. Stalls: "Search notes." Moves up: the enhancement spot in the code via the debugger or SE18, or a trace looking for calls to BADI handlers — not guesswork.