BAdIs in ABAP Cloud

BAdIs remain the sanctioned way to inject custom logic into SAP standard from a cloud-clean package — but only through released enhancement spots. In ABAP Cloud, the enhancement-spot picker shows you only released spots (for example `badi_sd_sls_quotation`); unreleased spots simply are not visible, so you cannot accidentally hook into an internal extension point. Implementing one is ordinary work: you create an implementing class in your own package, and it activates fine as long as the BAdI's supertype interface is released.

The subtle trap is filters. A released BAdI can still define filter values that are themselves unreleased — typed against a C2 constant from SAP standard. Writing your implementation's filter to match that SAP constant means your code references a C2 object, and that reference is a Clean Core violation even though the BAdI itself is released. ATC catches it under the cloud variant.

The remediation is to declare your own constant in your package holding the literal filter value, use that, and document in a comment that it binds to the SAP value. You lose nothing functionally — the filter still matches at runtime — but your code no longer has a compile-time dependency on an unreleased SAP object, so an upgrade that re-types or renames the SAP constant cannot break you.

ABAPmethod if_badi_sd_sls_quotation~modify.
  " filter bound to an unreleased C2 constant from SAP standard
  if i_doc_category = if_sd_doc_categ_c=>quotation.
    " ... custom logic
  endif.
endmethod.

ABAPconstants c_doc_quotation type c length 1 value 'B'.
" binds to SAP doc category Quotation (see released doc)
method if_badi_sd_sls_quotation~modify.
  if i_doc_category = c_doc_quotation.
    " ... custom logic
  endif.
endmethod.

Source notes: clean-core-curriculum §4.4