Sap Unused Code

SAP Unused Code Discovery

Find Z/Y custom objects that are never called at runtime — the prerequisite for any credible custom-code retirement project. Combines runtime usage data from SAP's call monitor (SCMON) with static where-used analysis to classify each object as UNUSED / LIKELY_UNUSED / USED / INDETERMINATE.

⚠ Required: scope and intent

This skill refuses to run without a filter. A "list all unused code" report across an ECC system returns tens of thousands of rows and is useless. The user must provide at least one of:

• Package (e.g., Z_FI_CUSTOM) — analyze only objects in this package
• Namespace prefix (e.g., Z_SALES_*, /ACME/*) — only objects matching the pattern
• Object list — comma-separated names to check
• Intent statement — e.g., "find Z reports in FI-GL that haven't run in 90 days" — narrow by purpose

If none is given, ask. Example clarifying questions:

Which package or namespace do you want to audit? E.g., "the Z_REPORTING package", "all Z* starting with Z_FI_", or "these 15 reports I'm planning to delete".

Why this is harder than it looks (read before proposing a plan)

SAP has two relevant monitoring systems. Understand which you're working with:

Key constraint: SCMON auto-deactivates when record threshold is hit (SCMON_CONF_SET_MAX_NUM_SLICES). SUSG refuses to aggregate if SCMON was inactive during the window. On dev/test systems this breaks the pipeline constantly.

Three Options (pick based on system state)

Option A (preferred) — Direct SCMON table join via ARC-1

Works immediately on any system where SCMON has ever been active, regardless of whether SUSG aggregation ran.

-- "Which programs actually ran?"
SELECT p~PROGNAME, p~OBJECT, p~OBJ_NAME, SUM( d~COUNTER ) AS EXECS
FROM SCMON_DATA AS d INNER JOIN SCMON_PROG AS p ON d~TRIGID = p~PROGID
WHERE <filter>
GROUP BY p~PROGNAME, p~OBJECT, p~OBJ_NAME
ORDER BY EXECS DESCENDING

-- "Which transactions/reports triggered anything?"
SELECT s~ROOTNAME, s~ROOTTYPE, SUM( d~COUNTER ) AS EXECS
FROM SCMON_DATA AS d INNER JOIN SCMON_SUB AS s ON d~SUBID = s~SUBID
GROUP BY s~ROOTNAME, s~ROOTTYPE

Column caveat (SAP naming is inverted):

• SCMON_DATA.TRIGID → SCMON_PROG.PROGID (the executed program, despite the name)
• SCMON_DATA.SUBID → SCMON_SUB.SUBID (the trigger root, transaction/report that initiated)

Pros: No batch wait, no slice rotation dance, runs today. Cons: Limited retention window (~7 days); useless for "has this run in the last 6 months" questions.

Option B — Aggregated SUSG via CDS views

Use when the customer has SUSG properly scheduled (production systems usually do).

-- Same question, longer window
SELECT PROGNAME, OBJ_TYPE, OBJ_NAME, SUM( COUNTER ) AS EXECS, MAX( LAST_USED ) AS LAST_SEEN
FROM SUSG_I_DATA
WHERE <filter>
GROUP BY PROGNAME, OBJ_TYPE, OBJ_NAME

Pre-joined CDS view: SUSG_I_DATA, SUSG_I_RDATA, SUSG_I_ODATA. All have @AccessControl.authorizationCheck: #NOT_REQUIRED.

Pros: Longer history (months), pre-joined (simpler SQL), officially supported data. Cons: Requires SUSG batch to have run (0 rows in SUSG until it does); nothing works if SCMON was deactivated during the window.

Option C — Manual SUSG XML export (fallback only)

If the customer has already run transaction SUSG and exported the 5 XML files (ADMIN0001.xml, PROG0001.xml, DATA*.xml, RDATA*.xml, SUB0001.xml), the skill can parse those locally. This is the Kiro path and should be the last resort — it requires human action in SAP GUI and offline file handoff.

This skill does not bundle an XML parser. If the user insists on Option C, tell them to use Kiro's parse-susg.py or write a local Python script; ARC-1 won't do it.

Smart Defaults (apply silently, do NOT ask)

Prerequisites

Check these up front. If missing, stop and tell the user.

1. SAP_ALLOW_FREE_SQL=true on the ARC-1 server (otherwise SAPQuery is blocked — it runs FreeSQL). Ask admin if needed.
2. User has S_TABU_NAM authorization on SCMON_DATA, SCMON_PROG, SCMON_SUB, SCMON_RDATA (or the SUSG equivalents for Option B).
3. SCMON has been active at some point (Option A) OR SUSG aggregation has run (Option B). Probe with:

SAPQuery(sql="SELECT COUNT(*) AS CNT FROM SCMON_DATA")
SAPQuery(sql="SELECT COUNT(*) AS CNT FROM SUSG_I_DATA")

Zero rows in both → data collection hasn't happened. Point the user to the next section and stop.

If the customer has no SCMON/SUSG data yet

Tell them:

1. SAP GUI: transaction SCMON → activate the monitor → let it run for N days (7 is a common minimum)
2. Transaction SCMONL shows slice state; SCMOND shows raw data
3. For permanent data: schedule SCMON_COLLECT as a daily job, then SUSG_COLLECT_FROM_SCMON after it
4. Re-run this skill once data is flowing

Step 1: Probe which option to use

Run the two COUNT queries above. Decision table:

Step 2: Enumerate the scope

Based on user's filter input:

2a. Package

SAPRead(type="DEVC", name="<package>")

Keep only objects of runtime types (PROG, CLAS, FUGR, FUNC) with Z/Y prefix. (Tables, CDS views, interfaces aren't "called at runtime" in a way SCMON/SUSG captures directly.)

2b. Namespace / prefix

SAPSearch takes a single objectType filter — call it once per runtime type and union the results:

SAPSearch(query="<prefix>*", objectType="PROG")
SAPSearch(query="<prefix>*", objectType="CLAS")
SAPSearch(query="<prefix>*", objectType="FUGR")

2c. Object list

Use names as given.

Call this set S (the candidate list).

Step 3: Query runtime usage

Option A (SCMON direct join)

Build a WHERE clause from set S. SAP FreeSQL has query length limits, so chunk if |S| > 100.

SELECT p~PROGNAME, p~OBJECT, p~OBJ_NAME, SUM( d~COUNTER ) AS EXECS
FROM SCMON_DATA AS d INNER JOIN SCMON_PROG AS p ON d~TRIGID = p~PROGID
WHERE p~OBJ_NAME IN ( 'ZCL_FOO', 'ZR_BAR', ... )   -- or  p~OBJ_NAME LIKE 'Z_FI_%'
GROUP BY p~PROGNAME, p~OBJECT, p~OBJ_NAME

Also check trigger-side (some Z-objects run only as transactions/RFCs, never as inner callees):

SELECT s~ROOTNAME, s~ROOTTYPE, SUM( d~COUNTER ) AS EXECS
FROM SCMON_DATA AS d INNER JOIN SCMON_SUB AS s ON d~SUBID = s~SUBID
WHERE s~ROOTNAME IN ( ... )

Union the results. Build set U (runtime-used objects with counts).

Option B (SUSG)

SELECT PROGNAME, OBJ_TYPE, OBJ_NAME, SUM( COUNTER ) AS EXECS, MAX( LAST_USED ) AS LAST_SEEN
FROM SUSG_I_DATA
WHERE <scope filter>
GROUP BY PROGNAME, OBJ_TYPE, OBJ_NAME

Build set U with additional LAST_SEEN timestamp.

Step 4: Static where-used for objects not in U

For each object in S but not in U:

SAPNavigate(action="references", type="<type>", name="<name>")

(references is ARC-1's where-used action — it calls SAP's where-used scope API under the hood.)

Build set W (statically referenced objects — someone calls them in source, even if no one ran them in the observed window).

Step 5: Classify

Apply first-match-wins:

Step 6: Emit the report

6a. Headline

Unused Code Audit — <scope>
Data source: SCMON (2,843 rows, window: 2026-04-12 → 2026-04-19)   ← Option A
  — or —
Data source: SUSG (Aggregated 2026-01-01 → 2026-04-19, 128 days)    ← Option B

Scope:         42 objects
  USED:          18  (43%)  — safe to keep
  LIKELY_UNUSED: 12  (29%)  — still has static callers; investigate
  UNUSED:        10  (24%)  — deletion candidates
  INDETERMINATE:  2   (5%)  — manual review

6b. UNUSED table (the deletion candidates)

Object                  Type  Package           Last change (TR)
ZR_OLD_FI_POSTING       PROG  Z_FI_CUSTOM       2024-02-15 (MARIAN / A4HK900042)
ZCL_LEGACY_HELPER       CLAS  Z_FI_CUSTOM       2023-11-03 (MARIAN / A4HK900031)
...

"Last change" comes from SAPRead(type="VERSIONS"). Old + unused = safest to delete.

6c. LIKELY_UNUSED table with caller hints

For each LIKELY_UNUSED object, show who references it:

ZCL_OLD_SALES_UTILS  (CLAS)
  Called by:  ZR_SALES_JOB (PROG — also UNUSED — cascade delete)
              ZCL_ACTIVE_HANDLER (CLAS — USED at runtime) ← blocks deletion

A LIKELY_UNUSED object whose callers are all UNUSED is transitively deletable. One active caller blocks deletion.

6d. Follow-up options

• "Want to see the static reference graph as a tree?" (→ chained SAPNavigate where-used)
• "Want to clean-core-check the USED objects before worrying about unused ones?" (→ sap-clean-core-atc)
• "Want documentation for the USED objects?" (→ sap-object-documenter)
• "Want to turn this into a reviewed S/4HANA migration dossier with HTML/CSV/graph outputs?" (→ sap-migration-dossier)
• "Want to start deleting UNUSED objects?" → Manual: this skill does not delete anything; the user does it via SAPWrite or a transport

Error Handling

Caveats

What runtime data does NOT tell you

• Coverage gap: a report that runs every year-end won't appear in a week's worth of SCMON data. Always consider the observation window vs. the object's expected frequency.
• Dead-code-detection ≠ code elimination: an UNUSED object may be emergency/DR code, exam-period-only, or called by a scheduled job not active during the window. Cross-check with business owners before deletion.
• Dynamic calls: CALL FUNCTION IN BACKGROUND, SUBMIT with dynamic program names, or CALL METHOD via RTTI may not attribute to the right PROGNAME in SCMON. Some false UNUSEDs are unavoidable.

What this skill does NOT do

• No deletion. Report only. Deletion must be a human decision, ideally via transport and CTS.
• No cross-system consolidation (DEV + QAS + PRD usage). That requires exports from each system; this skill reads one system at a time.
• No replacement suggestions for deprecated-but-used code. For that, use sap-clean-core-atc.
• No XML import (Option C). If the customer has SUSG XML dumps and nothing else, they need an offline parser.

When to Use This Skill

• Scoping a custom-code retirement project
• Before a migration — don't migrate what you don't use
• Post-project cleanup — removing code written for a feature that was rolled back
• License/compliance reviews requiring a dead-code inventory
• Combine with sap-clean-core-atc: migrate USED Level-A code, audit USED Level-C/D code, delete UNUSED code entirely