Performance discussions take one of two roads. Intuition: someone says a program is heavy, opens it, fixes a query, and the topic closes. Or measurement: a trace is collected, everyone stares at numbers, and nobody knows which line to start from.
Neither road is wrong. Both leave the same gap: is there a repeating pattern inside the code, and if so, where?
That is an inventory question, not a measurement question. The useful part is that you do not have to run the code to answer it.
A rule engine, not a runtime measurement
CPA scans ABAP source read from SAP against defined static rules. Objects are discovered with package, program, class, function and change date filters. From a selected starting object it follows include, function and class or method calls to a set depth and builds a relationship tree. Source lines and those relationships are stored as a scan snapshot.
The boundary is worth stating up front: this is not a compiler or a runtime profiler. It is a static engine built on regular expressions and limited scope resolution. It does no AI-based code analysis and is not a vulnerability scanner; dynamic calls and SQL generated at runtime fall outside its reach.
What you get in return is specific: a repeatable finding list produced without running the code or touching production.
The patterns the rules look for
SELECTinside a loop. Directly in the loop body, or inside a FORM, function or method called from it.- Wide reads.
SELECT *usage and loop-styleSELECT ... ENDSELECTreads. - Internal table access. Key reads without
BINARY SEARCH, andWHERElookups on a standard table inside a nested loop. - Join candidates. Two
SELECTstatements in the same scope flagged from their shared conditions.
The rules are narrow and readable. A finding does not say the code is bad; it says this pattern sits on this line. False positives are possible too — the key read finding is raised regardless of table type, and a join candidate does not prove two queries can safely be merged.
Where the remediation draft stops
Findings arrive with object, rule, severity, line range and source context. For supported cases a draft shows the lines to remove, add or change, drawing on the table field catalog where that is needed.
The marker beside the draft is what matters. Some results are applicable candidates; others are review guidance only. The generated code is not written back to SAP, and no draft can be assumed behaviourally safe in every program. The decision and the testing stay with the developer.
How to present the health percentage
A health percentage is derived from finding scores and query counts. Taking that to management as “our system health is 82 percent” would be wrong; calling it a static finding indicator against defined patterns is accurate. The scores are fixed in code and cannot be claimed to map onto a measured runtime cost.
Change between snapshots says far more than one percentage. A rescan preserves the previous scan and attaches the new one to the same chain, and the comparison is where changed objects and findings show up.
One more hook exists for teams that want the control to engage earlier: the event raised from released transport requests can trigger CPA analysis for changed objects. Do not design it as a mandatory quality gate; treat it as a prompt to look once more before code reaches production.
A proposal. Pick the Z package you get the most complaints about, let us run one scan, and sort the list into three groups — fix this week, queue it, leave it alone. Teams that can make that split stop being intimidated by a finding list.