# graphiffy-abap

Knowledge-graph builder for ABAP / SAP codebases. Hard fork of
[`safishamsi/graphify`](https://github.com/safishamsi/graphify) with
first-class ABAP support backed by [abaplint](https://github.com/abaplint/abaplint).

> Point it at a folder of `.abap` files (raw dumps, abapGit-exported repos, or
> a cloned ABAP GitHub repo) and it produces a queryable knowledge graph of
> classes, interfaces, methods, function modules, forms, includes, table
> accesses, exception flow, and rationale comments — all with cross-file
> resolution.

## What it does

Three-pass pipeline inherited from upstream graphify:

1. **AST extraction (per file, deterministic, no LLM).**
   For ABAP, this calls abaplint via a Node subprocess and walks its parsed
   statement tree to emit graph nodes/edges. Other languages still go through
   tree-sitter (Python, JS, Go, Java, etc.).
2. **Cross-file resolution.** Definition-site nodes and reference-site nodes
   share canonical IDs (`clas:zcl_foo`, `fm:z_post_invoice`,
   `method:zcl_foo::process`, `ddic:vbak`), so calls/inheritance/interface
   implementations stitch automatically across files.
3. **LLM semantic pass (optional, `--mode deep`).** Claude reads docs, PDFs,
   images, and rationale comments to add INFERRED edges and design rationale.

Output:

```
graphiffy-abap-out/
├── graph.json       canonical knowledge graph
├── graph.html       interactive graph (vis.js, open in any browser)
├── GRAPH_REPORT.md  god nodes, communities, surprising connections, suggested questions
└── cache/           SHA256-keyed per-file cache; re-runs only re-process changed files
```

## What ABAP support extracts

For every `.abap` file, the pipeline captures:

| ABAP construct | Graph node | Edges out |
|---|---|---|
| `REPORT zfoo` / `PROGRAM zfoo` | `prog:zfoo` | `defines` → forms, `includes` |
| `CLASS zcl_foo DEFINITION` | `clas:zcl_foo` | `inherits_from`, `implements_interface`, `defines` |
| `INTERFACE zif_foo` | `intf:zif_foo` | `defines` → methods |
| `METHODS process` | `method:zcl_foo::process` | (caller side) |
| `FORM x` (subroutine) | `form:zfoo::x` (program-scoped) | (caller side) |
| `FUNCTION z_foo` (function module) | `fm:z_foo` | (caller side) |
| `INCLUDE zinc_x` | `include:zinc_x` | `includes` |
| `SELECT … FROM <table>` and INSERT/UPDATE/MODIFY/DELETE | `ddic:<table>` | `accesses_table` |
| `RAISING zcx_foo` | `exc:zcx_foo` | `raises_exception` |
| Comment block above a definition | `rationale:<file>:<row>` | `rationale_for` |

Edge types:

* `inherits_from`, `implements_interface`, `defines`, `includes`
* `calls_form` (PERFORM)
* `calls_function_module` (CALL FUNCTION 'Z_FOO')
* `calls_method` (`obj->meth`, `cls=>meth`, legacy CALL METHOD)
* `instantiates` (`NEW zcl_foo( )` / `CREATE OBJECT`)
* `accesses_table` (Open SQL)
* `raises_exception`, `rationale_for`
* `*_dynamic` (PERFORM (lv_x), CALL FUNCTION (lv_x)) — flagged AMBIGUOUS

Every edge carries `confidence` ∈ {`EXTRACTED`, `INFERRED`, `AMBIGUOUS`} and a
`confidence_score` so the downstream report can be honest about what's solid
vs. guessed.

## Quick start

**Prerequisites:** Python 3.10+, Node.js 18+, an ABAP corpus.

```bash
# Install graphiffy-abap from a local clone (PyPI publication TBD)
git clone https://github.com/NabheetCloud/graphiffy-abap.git
cd graphiffy-abap
pip install -e .

# In the project you want to analyse, install abaplint
cd /path/to/your/abap-project
npm install @abaplint/core

# Run
graphiffy-abap .
```

Output lands in `graphiffy-abap-out/` next to your source.

## Worked example: abap2UI5

A real run on the public [`abap2UI5/abap2UI5`](https://github.com/abap2UI5/abap2UI5)
codebase produced a 2,700-node / 2,870-edge graph with 1,338 cross-file edges.
Top god nodes (degree-ranked) were exactly what an SAP engineer would
predict: `CX_STATIC_CHECK`, `Z2UI5_CL_UTIL_EXT`, `LTCL_UNIT_TEST`,
`CL_ABAP_UNIT_ASSERT::ASSERT_EQUALS`, `Z2UI5_IF_AJSON`.

Full validation report: [`worked/abap2ui5/review.md`](worked/abap2ui5/review.md)

## File detection

graphiffy-abap recognises:

* Plain `.abap` files
* abapGit conventions: `*.clas.abap`, `*.prog.abap`, `*.intf.abap`,
  `*.fugr/*.abap` (function-group includes)
* Object type detected from filename (so a `*.clas.abap` is correctly typed
  as a class even before the source is parsed)

Other graphify file types (`.md`, `.pdf`, images, code in 25 other languages)
are still supported — drop ABAP, design docs, and screenshots into one
folder and graphiffy-abap will produce one unified graph.

## Roadmap

**Phase 1 (done).** ABAP language plugin via abaplint.
Programs, classes, interfaces, methods, function modules, forms, includes,
calls, table references, exceptions, rationale.

**Phase 2 (done).** DDIC XML parsing (tables, structures, data elements,
domains, search helps), CDS view DDL, AMDP method bodies, BAdI / enhancement
framework awareness, SAP-aware Pass-3 LLM prompts.

**Phase 3 (WIP).** Live SAP system extraction via ADT REST / RFC,
transport-aware incremental updates, on-prem LLM option, SAP-specific MCP
server.

## Relationship to upstream graphify

graphiffy-abap is a **hard fork** of `safishamsi/graphify` v5
(commit `770d7f5`). The MIT license is preserved. ABAP support adds an
external Node.js dependency (abaplint) and SAP-specific extraction logic
that aren't generally useful to upstream's audience, hence the fork.
See [`NOTICE`](NOTICE) for full attribution.

All non-ABAP languages still work exactly as upstream — graphiffy-abap is a
strict superset of graphify's language support.

## License

MIT — see [`LICENSE`](LICENSE).