The XCO library
What you'll learn
XCO is a released, fluent library of xco_cp_* helpers for JSON, hashing, time, repository introspection, HTTP/OData, and strings — use xco_cp_json instead of the unreleased /ui2/cl_json.
- XCO is a released, fluent facade library (xco_cp_*) for cross-cutting concerns.
- Covers JSON, hashing/encoding, time/time-zone, repository introspection, HTTP/OData clients, string/file.
- Use xco_cp_json instead of the unreleased /ui2/cl_json for JSON.
XCO (the Extension Component library) is a released, fluent ABAP API for cross-cutting concerns that began in the ABAP Environment and is now broadly available in S/4HANA 758. Rather than hunting for a released class per task, you reach for the relevant `xco_cp_*` facade. It covers JSON (`xco_cp_json`), hashing and encoding (`xco_cp_hash`, `xco_cp_encoding`), date/time and time zones (`xco_cp_time`, `xco_cp_time_zone`), repository introspection (`xco_cp_abap_repository`), HTTP and OData clients (`xco_cp_http`, `xco_cp_odata`), and string and file helpers (`xco_cp_string`, `xco_cp_file_system`).
The fluent style reads as a chain of intent: you get a handle, then navigate to the member or operation you want. For JSON this replaces the old habit of calling `/ui2/cl_json` (not released for Cloud) with a released, explicit traversal. Because every facade is C1, code written against XCO survives upgrades, and because the API is uniform, a developer who learns one facade can read the others.
Repository introspection deserves a special mention: `xco_cp_abap_repository` lets your own code query packages, release states, and ATC findings. That turns XCO from a utility belt into a platform — for instance you can write a short program that asks the repository for every Z class consuming a C2 object and emit your own Clean Core compliance report, something SAP does not ship out of the box.
Key points
- XCO is a released, fluent facade library (xco_cp_*) for cross-cutting concerns.
- Covers JSON, hashing/encoding, time/time-zone, repository introspection, HTTP/OData clients, string/file.
- Use xco_cp_json instead of the unreleased /ui2/cl_json for JSON.
- Every facade is C1, so XCO-based code is upgrade-stable and uniform to read.
- xco_cp_abap_repository can introspect packages, releases, and ATC findings — build your own compliance tooling.
Examples
The familiar but unreleased path — /ui2/cl_json is not C1, so this is a Clean Core violation in a cloud package.
ABAPdata(json) = `{"matnr":"4711","mtart":"FERT"}`.
data ls_data type ty_material.
/ui2/cl_json=>deserialize( exporting json = json
changing data = ls_data ).The released, fluent XCO traversal: get a handle from the string, then navigate to the member and read its value.
ABAPdata(json) = `{"matnr":"4711","mtart":"FERT"}`.
data(handle) = xco_cp_json=>data->from_string( json ).
data(matnr) = handle->get_member( 'matnr' )->get_value( )->as_string( ).Source notes: clean-core-curriculum §5.3
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.