Explain Abap Code

Explain ABAP Code

Explain ABAP objects with full dependency context and optional ATC code quality analysis.

This skill replicates SAP Joule's "Explain Code" capability by combining ARC-1 (SAP system access) with mcp-sap-docs (documentation & best practices). It goes beyond J4D by providing compressed dependency graphs via SAPContext.

Smart Defaults (apply silently, do NOT ask)

Input

The user provides an ABAP object name (e.g., ZCL_TRAVEL_HANDLER, ZI_SALESORDER, Z_REPORT_POSTING).

Only the object name is required. If the user provides just an object name, auto-detect the type and proceed immediately with an overview explanation.

Optionally, the user may specify:

• Object type (default: auto-detect)
• Explain ATC findings? (default: no)
• Depth — "overview" or "detailed" (default: overview)

Step 1: Read the Object

1a. Resolve type (if not provided)

If the user didn't specify a type, search for the object:

SAPSearch(query="<object_name>")

Use the first result's type. If ambiguous (multiple matches), ask the user.

1b. Read the source code

SAPRead(type="<type>", name="<object_name>")

1c. For classes — also get the method listing

SAPRead(type="CLAS", name="<class_name>", method="*")

This returns all methods with their signatures, visibility (public/protected/private), and parameter types. Essential for understanding the class API.

1d. For CDS entities — also get the structured field list

SAPRead(type="DDLS", name="<entity_name>", include="elements")

Returns a formatted listing of all fields with key markers, aliases, associations, and expression types.

1e. (Optional) Read related artifacts

Depending on type, also read associated objects:

• CLAS: SAPRead(type="CLAS", name="<class>", include="testclasses") — check if tests exist
• DDLS: SAPRead(type="BDEF", name="<entity>") — check if behavior definition exists; SAPRead(type="DCLS", name="<entity>_DCL") — check CDS access control; SAPRead(type="DDLX", name="<entity>") — check for metadata extensions
• BDEF: SAPRead(type="DDLS", name="<entity>") — read the associated CDS view

These may fail if the related artifact doesn't exist — that's fine, skip them.

1f. For behavior definitions (BDEF) — walk the RAP graph

A behavior definition is only meaningful together with its bound CDS root entity and its behavior pool (handler) class. When the object is a BDEF, do this instead of (or in addition to) the steps above:

Read the BDEF source:

SAPRead(type="BDEF", name="<bdef_name>")

Identify the implementation type + bound pool class by reading the BDEF source:

• First non-comment token: managed / unmanaged / projection / abstract / interface — this is the implementation kind
• strict ( 2 ) → latest RAP syntax checks; with draft / with collaborative draft → draft-enabled
• The clause ... implementation in class <ZBP_NAME> unique; names the behavior pool class. Extract <ZBP_NAME> with a regex like implementation\s+in\s+class\s+(\S+). (A projection; BDEF may have no pool class — it reuses the base behavior via use ....)

Read the behavior pool class (the handler logic lives in its local includes — usually CCIMP):

SAPRead(type="CLAS", name="<ZBP_NAME>", include="implementations")

If that returns empty, also try include="definitions" (CCDEF) and the main include. The local handler classes are named lhc_<alias> and each FOR DETERMINE / FOR VALIDATE / FOR MODIFY method implements the corresponding BDEF declaration.

Read the bound CDS root entity to understand the data model the behavior governs:

SAPRead(type="DDLS", name="<root_cds>", include="elements")

The root CDS name appears in define behavior for <root_cds> alias <alias>.

For a projection BDEF, also read the underlying base BDEF (the one it projects) to see which operations are reused (use create; use update; use action ...).

These reads may fail if an artifact doesn't exist (e.g. a pure abstract BDEF) — skip gracefully.

1g. For function groups (FUGR) — read the full code tree

A function group's logic is spread across nested includes: the main program references the TOP (global data) and UXX (function-module dispatcher) includes, and the actual FUNCTION … ENDFUNCTION bodies live in further-nested LZ<grp>U01/U02… includes pulled in from UXX (PBO/PAI subroutines in …O…/…I… includes). Read the whole tree in one call with expand_includes:

SAPRead(type="FUGR", name="<group>", expand_includes=true)

This returns the main source plus every nested include (recursively, depth/count-capped), each prefixed with a === <name> === marker — so you get all the function module bodies and flow logic in one read. Without expand_includes, you only get the function-module list.

Screen flow is not available. Dynpros (screens) and GUI status (CUA) are not exposed by ADT over REST — they are SAPGUI-only (SE51/SE41), and the endpoints return 404. So for a FUGR you can explain the business purpose, function-module responsibilities, and flow logic from the code, but not the screen layout / PBO-PAI screen sequence beyond what the PBO/PAI module code reveals. State this limitation if the user asks about the screen flow specifically.

Step 2: Get Dependency Context

SAPContext(type="<type>", name="<object_name>")

This automatically extracts all dependencies and fetches compressed public API contracts for each. It provides:

• For classes: used interfaces, superclasses, injected dependencies, called methods on other classes
• For CDS views: data sources (FROM, JOIN), associations, compositions, projection bases
• For programs: called function modules, used classes, included programs

For complex objects with deep dependency chains, use depth=2:

SAPContext(type="<type>", name="<object_name>", depth=2)

If SAPContext fails (e.g., unsupported type), fall back to manual reads of key dependencies identified in the source code.

Supported types: SAPContext accepts CLAS, INTF, PROG, FUNC, DDLS (on-prem) / CLAS, INTF, DDLS (BTP). It does not accept BDEF. So when explaining a BDEF, run dependency/impact analysis on the bound CDS root entity instead:

SAPContext(action="impact", name="<root_cds>")

action="impact" (DDLS only) returns the downstream blast radius — projection views, consumption views, and services that build on the behavior. This is the "dependencies / who consumes this" answer for a behavior definition. For the handler class internals, run SAPContext(type="CLAS", name="<ZBP_NAME>").

Step 3: (Optional) Run ATC Check

If the user asked to explain code quality or ATC findings:

SAPDiagnose(action="atc", type="<type>", name="<object_name>")

If a specific ATC variant is needed (e.g., S/4HANA readiness):

SAPDiagnose(action="atc", type="<type>", name="<object_name>", variant="<variant>")

Group findings by priority:

• Priority 1 (Errors): Must-fix issues — deprecated APIs, syntax problems
• Priority 2 (Warnings): Should-fix — performance, maintainability
• Priority 3 (Info): Nice-to-fix — style, conventions
• Check each finding's hasQuickfix flag. If true, mention that SAP provides a machine-applicable quickfix proposal for that location.

Step 4: (Optional) Research with mcp-sap-docs

For unfamiliar SAP APIs found in the source code:

search("<class_or_function_name> ABAP documentation")

For ATC findings that need explanation:

search("<checkTitle> simplification item S/4HANA")

For SAP Notes if available:

sap_notes_search(q="<finding_or_api_name>")

Use documentation results to enrich the explanation with official SAP context.

Step 5: Explain

Present a structured explanation with the following sections. Adapt depth based on user preference (overview vs detailed).

Summary

• Purpose: What the object does in one sentence
• Type: Object type and classification (e.g., "RAP behavior pool", "interface CDS view", "ALV report")
• Scope: How many methods/fields/lines, complexity assessment

Public API

For classes:

• Key public methods with their signatures and purpose
• Implemented interfaces
• Constructor parameters (especially injected dependencies)
• Events raised

For CDS views:

• Exposed fields with business meaning
• Parameters (if any)
• Associations available for navigation

Business Logic

• Core processing flow (what happens when key methods are called)
• Important business rules and conditions
• Data transformations and calculations
• Error handling approach

Behavior Definition (if the object is a BDEF)

Structure the explanation around the RAP behavior graph you read in Step 1f:

• Implementation kind: managed / unmanaged / projection / abstract / interface — and what that implies (framework-provided CRUD vs custom handlers vs reuse/typing layer). Note strict(2) and with draft if present.
• Business purpose: derived from the bound CDS root entity + the BDEF header comments.
• Per-entity model: for each define behavior for <CDS> alias <alias> — persistent table, lock master/lock dependent, authorization master/authorization dependent, etag.
• Operations (the CRUD graph): create / update / delete, create-by-association (association _X { create; }), and whether draft actions (Edit, Activate, Discard, Resume, Prepare) are present.
• Determinations: determination <name> on save|on modify — what each derives, read from the matching FOR DETERMINE method in the pool class.
• Validations: validation <name> on save — what each enforces, from the FOR VALIDATE method.
• Actions / functions: action <name> (+ static/factory/parameter/result), from the FOR MODIFY / FOR READ methods.
• Side effects: side effects { ... } declarations (what UI refresh / recompute they trigger).
• Field controls: field ( readonly | mandatory | numbering : managed ), mapping for <table>.
• For a projection BDEF: which base operations/actions are reused via use ....

Dependencies

From SAPContext results:

• Direct dependencies with their roles (data source, helper, framework)
• Key interfaces/classes used and why
• External system calls (RFC, HTTP, etc.) if any
• Database tables accessed

Security / Authorization

• CDS access control (DCLS) rules if present (row-level restrictions, role mapping)
• Behavior-level authorization hints (authorization master, authorization dependent by) when present in BDEF
• Practical impact: what data/operations may be restricted at runtime

Code Quality (if ATC was run)

From ATC results:

• Summary: total findings by priority
• Top findings with explanation of impact
• Recommendations for improvement

Follow-up Options

Offer the user next steps:

• "Want me to explain a specific method in detail?"
• "Want me to get SAP quickfix proposals for the ATC findings?" (→ SAPDiagnose(action="quickfix"))
• "Want me to apply SAP's quickfix for ?" (uses SAP-verified fix proposals + apply_quickfix)
• "Want me to analyze the ATC findings and suggest fixes?" (→ migrate-custom-code skill)
• "Want me to generate unit tests for this class?" (→ generate-abap-unit-test skill)
• "Want me to show the full dependency graph?" (→ SAPContext with depth=2)
• For a BDEF: "Want me to implement a missing determination/validation/action body?" (→ generate-rap-logic skill) or "Want me to scaffold the behavior pool handlers?" (→ SAPWrite(action="scaffold_rap_handlers"))

Error Handling

Common Issues and Fixes

Notes

BTP vs On-Premise Differences

• BTP: Fewer object types available — no PROG, INCL, FUGR. Focus on released APIs and ABAP Cloud objects. DDLS, DCLS, CLAS, INTF, BDEF, DDLX, SRVD are the primary types. ATC variants are limited to cloud readiness checks.
• On-Premise: Full range of object types. All ATC variants available. Can explain legacy objects (FORM routines, function modules, classic reports).

What This Skill Does NOT Do

• No code modification: This skill only reads and explains — it never writes or changes code
• No refactoring suggestions: For improvement suggestions, use ATC analysis or migration skill
• No test generation: For generating tests, use generate-abap-unit-test or generate-cds-unit-test skills
• No cross-system comparison: Explains objects on one system at a time

When to Use This Skill

• When onboarding to an unfamiliar codebase
• When investigating a bug or understanding existing behavior
• When reviewing code quality before a migration
• When documenting an undocumented object
• When understanding the impact of changing a shared class or CDS view