Fallback Class and Filter Design

Explanation

A fallback class runs when no active implementation matches the filter. It provides safe defaults so standard flow does not break. Filters should be based on stable business criteria (company code, sales org) — not on dynamic data that could change per transaction.

Code example

CLASS zcl_default DEFINITION.  PUBLIC SECTION.    INTERFACES if_ex_badi_zorder.ENDCLASS." Registered as fallback in SE18 for the BAdI

Real project scenario

During an org restructure new company codes had no BAdI implementation. The fallback class prevented the order-save process from failing.

Common mistakes

Overlapping filters causing multiple hits; no fallback so orders dumped for new orgs.

Best practices

Always ship a fallback for filter-dependent BAdIs; make filter values part of TR documentation.

Interview angle

When is a fallback class necessary?