🔬 Clean Core — Evolution Project
The current AI@CustomCode scope is reactive — ATC makes a finding, AI fixes it. The Clean Core workstream extends this with a proactive approach that goes significantly further. It is the same technical engine applied to a broader and more strategic problem.
How Clean Core Extends the Custom Code Adaptation Framework​
| AI@CustomCode (existing) | Clean Core extension (planned) | |
|---|---|---|
| Trigger | ATC finding | Proactive inventory scan |
| Scope | Custom code syntax/API adaptation | Custom code + DDIC objects + enhancement patterns |
| Output | Corrected ABAP in a transport | Corrected ABAP + retired objects + new BAdI implementations |
| SAP goal | Compile-clean for S/4HANA | Clean Core compliant (extensibility model) |
| Complexity | Medium | High — requires semantic understanding of business logic |
Use Case 1 — Clean Core Compliance Scoring & Roadmap​
Before fixing anything, clients need to know where they stand. This use case offers an inventory scan that produces a Clean Core compliance score per object and a prioritised remediation roadmap:
| Object type | Count | CC-compliant | To fix | Effort | No CC possible |
|---|---|---|---|---|---|
| Classic user exits | 47 | 0 | 47 | High | 12 |
| Custom BAPIs | 23 | 0 | 23 | High | 9 |
| BOPF extensions | 12 | 12 | 0 | ✅ | |
| RAP extensions | 8 | 8 | 0 | ✅ | |
| Unreleased FM calls | 156 | 0 | 156 | Med | |
| Direct table reads | 89 | 0 | 89 | Med | |
| Dead custom programs | 312 | N/A | 312 | Low (retire) |
The ABAP Experts / Tech Lead of the client company reviews and approves or rejects the proposed corrections. AI@CustomCode implements only the released (approved) modifications.
Use Case 2 — Dead Code & DDIC Cleanup​
Using SCMON data (already available in AI@CustomCode) the system can identify:
- Custom programs, function modules, and classes with zero usage → candidate for retirement
- Custom DDIC objects (tables, data elements, domains, structures) that are only referenced by dead code → candidate for deletion
- Orphaned Customising tables with no active reads
The AI solution generates a cleanup transport that marks objects for deletion, with a simulation report first (same pattern as the existing Step 4 in AI@CustomCode). The client developer validates, approves, and the objects are retired.
This use case alone can reduce the custom code footprint by 20–40% on a typical legacy ECC system.
Use Case 3 — BAdI / Enhancement Framework Modernisation​
This is the most technically complex use case. The goal is to replace custom BAPIs and classic user exits with SAP-released BAdI / RAP extension points.
Scan targets:
- Custom BAPIs (
Z_BAPI_*) - Function modules in custom FM groups used as hooks
- Classic user exits (
EXIT_*,SAPLXXXX) - Old-style customer exits (CMOD / SMOD)
- Screen exits, menu exits
For each object found, the AI:
- Identifies the SAP-released equivalent (Business Event, released BAdI, RAP extension point, Key User Extensibility field, OData extension)
- Generates the new BAdI implementation class
- Produces a simulation report showing: old code | new equivalent | mapping
- Waits for developer validation of functional equivalence
- Writes the new
ZCL_BADI_IMPL_xxxclass - Flags the old BAPI / exit for retirement
The BAPI → BAdI replacement case requires semantic reasoning about business logic, not just syntax adaptation. The AI must understand what the old BAPI does and confirm the new BAdI covers the same use case. This requires reading both the custom code and the SAP documentation for the released extension point — and always needs a human validation gate before any change is applied.
What AI@CustomCode Specifically Brings to Clean Core​
- It can read the custom BAPI source code and understand the business intent, not just the syntax
- It can search SAP documentation (via AI@KB or OSS notes) for the released equivalent extension point
- It can write the complete new BAdI class — not just flag the issue, but generate the replacement
- It can handle the transport lifecycle — same as the existing Step 6
- It operates in a simulation → validate → execute pattern that keeps the ABAP developer in control
Market Context​
| Product | Pain point | Target market |
|---|---|---|
| AI@CustomCode (existing) | Thousands of ATC findings, not enough ABAP developers | S/4HANA migration projects |
| AI@CustomCode + Clean Core (planned) | Clients on S/4HANA who want to move to cloud but have messy extensions | S/4HANA customers looking at RISE or SAP BTP adoption |
Clean Core modernisation requires semantic reasoning about SAP's extensibility API landscape, which changes rapidly (RAP, Key User Extensibility, BTP extensions). Clients will need a solid, regularly updated knowledge base of SAP's released extension points — the AI@KB tool is a natural candidate to feed this.