High-yield legacy → released replacements
What you'll learn
Swap legacy calls for released ones: BAPI_USER_GET_DETAIL→XCO_CP_USER, CONVERSION_EXIT_ALPHA_INPUT→`|{ value ALPHA = IN }|`, NUMBER_GET_NEXT→CL_NUMBERRANGE_RUNTIME, READ_TEXT→XCO_CP_LONG_TEXT, CL_BCS→CL_BCS_MAIL_MESSAGE; RFC_READ_TABLE has no API replacement — read a CDS view.
- BAPI_USER_GET_DETAIL → XCO_CP_USER / XCO_CP factory.
- CONVERSION_EXIT_ALPHA_INPUT → string template `|{ value ALPHA = IN }|` (C1, type-safe).
- NUMBER_GET_NEXT → CL_NUMBERRANGE_RUNTIME; READ_TEXT → XCO_CP_LONG_TEXT; CL_BCS → CL_BCS_MAIL_MESSAGE.
A handful of legacy calls account for most of the migration work, and each has a known released replacement. User detail: `bapi_user_get_detail` gives way to the `xco_cp_user` / `xco_cp` factory. Alpha conversion: the function module `conversion_exit_alpha_input` (C2 from Cloud) is replaced by the string-template form `|{ value alpha = in }|`, which is C1 and type-safe. Number ranges: `number_get_next` becomes the released `cl_numberrange_runtime`. Long text: `read_text` moves to `xco_cp_long_text` where available per release. Outbound mail: the legacy `cl_bcs` is replaced by the released `cl_bcs_mail_message` for in-stack sending.
The case that trips people up is `rfc_read_table`: it is not released for cloud consumption, and there is no drop-in API replacement. The correct move is architectural — expose the data you need through a released CDS view and read that view instead. There is no 'read any table generically' API in Clean Core by design, because that capability is exactly what breaks upgrade stability.
The discipline is to treat the legacy call as a smell and look up its row in this table before reaching for an exemption. Most replacements are not just compliant but better: the alpha template is inlineable and avoids a function-call round-trip; `cl_numberrange_runtime` is a clean object API; the XCO helpers are fluent and testable. Migration here usually improves the code rather than merely satisfying ATC.
Key points
- BAPI_USER_GET_DETAIL → XCO_CP_USER / XCO_CP factory.
- CONVERSION_EXIT_ALPHA_INPUT → string template `|{ value ALPHA = IN }|` (C1, type-safe).
- NUMBER_GET_NEXT → CL_NUMBERRANGE_RUNTIME; READ_TEXT → XCO_CP_LONG_TEXT; CL_BCS → CL_BCS_MAIL_MESSAGE.
- RFC_READ_TABLE is NOT released — read a released CDS view instead; there is no generic table-read API by design.
- Replacements are usually better code, not just ATC-compliant.
Examples
The classic CONVERSION_EXIT_ALPHA_INPUT call — a C2 function module from a Cloud package, and a round-trip for a pure string operation.
ABAPcall function 'conversion_exit_alpha_input'
exporting
input = lv_matnr
importing
output = lv_matnr.The released, type-safe, inline form — no function call, C1, and clearer at the call site.
ABAPdata(lv_matnr) = |{ lv_matnr alpha = in }|.RFC_READ_TABLE is not released for cloud consumption — there is no compliant way to keep this call.
ABAPcall function 'rfc_read_table'
exporting
query_table = 'MARA'
tables
data = lt_data.Replace the generic read with a typed SELECT from the released interface view — the contract you are allowed to depend on.
ABAPselect from i_material
fields material, materialtype
into table @data(lt_material).Source notes: clean-core-curriculum §5.2
Ask Claude
Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.