AVE — ABAP Versions Explorer & Code Reviewer
SAP ABAP version explorer and code review tool for SAP GUI.
Tested on dozens of transport requests and on real projects — the largest one so far: 4 developers, several months of work, ~25 000 lines of code, reviewed with AVE from end to end.
Also outside SAP GUI. The version history, the diff between two versions and the saved code
review — including approving, declining and commenting on a block — are available in Eclipse ADT
and in VS Code through VERTEX · Marketplace.
It reads AVE over an ADT resource that lives in
Simple-Data-Explorer, so both repositories
have to be on the system. A review is prepared in AVE; VERTEX reads it and writes verdicts into
it.
In the construction phase. No blame yet, and a dictionary object's review is still SAP GUI.
What AVE gives you
- A whole transport at once — open a request, task, package, class or function group and review everything in it in one screen, instead of opening object after object in SE80 or Eclipse.
- Objects that do not exist are red — a request listing something nobody can find shows it before it is released.
- Any two versions compared — side by side or inline, the full source or only the changed blocks.
- No noise — reformatting and case, generator timestamps, generated
*_MPC / *_DPC classes, SAP framework includes, empty class sections, blank blocks, repeated and Transport-of-Copies versions, and lines that merely moved are all left out. What remains is what a person wrote.
- Class sections read as they were written — declarations are paired by signature, so a method that only moved is not shown as deleted here and added there.
- The real author — resolved through Transports of Copies, together with the request and task that actually carry the change.
- Blame — who wrote each line, and when.
- Code review with a memory — approve or decline each block (never your own), leave comments and decline notes, see totals per developer and per reviewer, close the session and reopen the review later.
- Moving Violations — what your request will overwrite, or bring back, in another development system once it is moved there.
- AI, if you want it — send a block or a whole object to an LLM from inside SAP GUI, or copy out a ready-made prompt.
- Straight into Eclipse — every object, and every changed block, opens in the ADT editor on its own line; one Recalc afterwards and the review is on the new code.
- Fast navigation — every method of a class, every object of a package or request, one click away.
Table of Contents
- Why AVE
- Installation
- Selection screen
- Versions Explorer
1. Why AVE
First of all — the Eclipse version is the best.
But I want a very fast interface for some cases:
- I don't want to see the list of all the same versions because of using TOC (Transport of Copies)
- I do want to see the real object owner, especially when a Transport of Copies is used
- fast navigation within Transport Requests / Tasks
- fast navigation within methods inside a class
- fast navigation within objects inside a package
- detecting non-existent objects in Transport Requests / Tasks
And the longer answer to the list above: what the standard tools make you do by hand, and what AVE does instead.
1.1 A change is a transport, not an object
SE80 version management and Eclipse compare one object with one of its versions. A transport request is not one object — it is dozens of programs, classes, methods, function modules, CDS views and table definitions. Reviewing it in the standard tools means opening every object by hand, remembering which ones are already done, and starting over tomorrow.
AVE takes the whole scope as the unit of work: enter a request (or a task, a package, a class, a function group) and you get one list of everything in it, the versions of each part, and the diffs — with the objects that do not exist in the system marked red, so a request listing something nobody can find shows it before the request is released.
1.2 The noise problem
A raw line comparison shows everything that differs, and most of it is not a change anybody made. Reviewers learn to scroll past it, and that is exactly how a real change slips through. AVE removes the noise before it reaches the screen:
| Ignored | Why it is not a change |
|---|
| Indentation and case | The pretty-printer reformats a whole block nobody touched. One switch, because the comparison folds whitespace and case together. |
| Generator timestamps | The SEGW header (has been generated on … in client …), the function group regeneration stamp (* regenerated at …) and the table maintenance generator header (generation date:, view maintenance generator version:) are rewritten by every regeneration — in every system independently. |
| Generated Gateway/SEGW classes | *_MPC, *_MPC_EXT, *_DPC are generated from the model. *_DPC_EXT holds hand-written code and stays in the review. |
| SAP-authored includes | Function group framework includes (version author SAP*) are written by the system, not by a developer. |
| Empty class sections | A new class always gets all three section includes; the unused ones contain nothing but their own protected section. header. |
| New objects that are only comments | A generated stub of comment lines is not something to review. |
| Blank-only blocks | A block whose changed lines are all empty is nothing to look at. |
| Repeated versions | Versions whose source is identical to the previous one, and the Transport-of-Copies versions that create them. |
| Lines that only moved | A block moved elsewhere in the file is not two changes (a deletion and an insertion). |
What is left is what a person wrote.
1.3 Class sections come back in random order
The public, protected and private part of a class is stored as a generated include, and SAP regenerates it with the declarations in an arbitrary order. Compare two versions line by line and you get a method that merely moved reported as deleted in one place and added in another — and, worse, the importing and parameter lines of one method matched against another method's, which reads as if signatures had changed.
AVE pairs declarations by their signature and aligns the parameters inside a matched declaration by name. Moved declarations disappear from the diff; a changed one shows exactly the parameter that changed.
1.4 Who really made the change
With a Transport of Copies in the landscape, the version list names the copy, not the author. AVE resolves a T-copy back to its parent request and looks up the responsible task, so every version shows the developer and the request that actually carries the change.
1.5 The other development system
If your landscape has more than one development system — a main one and a project one, say — the retrofit between them is never quite up to date. A request released from one of them can silently overwrite work done in the other, or bring back lines somebody had already deleted, and nobody sees it because everyone is looking at the changed lines, not at the code around them.
Point AVE at the other system and it compares the reviewed source against what is active there, listing everything that will be overwritten or re-inserted when the request is moved. See Moving Violations.
1.6 A review, not just a view
AVE is also a code review workflow: approve or decline every block (never your own), leave comments and decline notes, see totals per developer and per reviewer, and reopen the review later — it lives in one Z table, saved automatically after each action. An LLM can be plugged in, or the prompt copied out to any chat.
2. Installation
a) abapGit — clone https://github.com/ysichov/AVE into a package. You get the report Z_AVE, the observer report Z_AVE_OBSERVER and all ZCL_AVE_* classes.
b) Standalone report — copy src/z_ave_standalone.prog.abap into one new report; it is a generated single-file merge of the whole tool, nothing else is needed. The observer has its own standalone file, src/z_ave_observer_sa.prog.abap.
Only the Code Reviewer needs one extra object — the table ZAVE_REVIEW, see section 7. Everything else runs as is.
3. Selection screen
The whole selection screen of Z_AVE with contains six blocks: Main features, object type block, Layout/UI preferences, Data filter options, AI API config, Diagnostic/Debug.
3.1 Main features
The first block chooses the mode and the review scope.
| Field | Parameter | Meaning |
|---|
| Code Reviewer | P_CR | Review mode: AVE prepares the diffs of a transport scope and opens the review report. |
| Versions Explorer | P_VE | Classic mode: browse and compare versions of one object. |
| TRs for Re-View | S_TASK | One or more requests / tasks — the review scope, and also the object when TR/Task is chosen below. |
| Include Tasks | P_ITASK | Read the objects of the S-tasks belonging to the entered requests too. A request header only carries what was recorded directly on it, so an unreleased K is usually empty while its tasks hold everything. |
| Remote system Id version check | P_SYS | TMS system id — adds a remote baseline version and switches on the Moving Violations check (5.6). |
| Who is Blame :) | P_BLAME | Compute blame — who wrote each line. Costly on long histories, see 4.9. |
| Comment check (request no.) | P_CMTCHK | Mark changed blocks that name no transport request, and objects whose first block is not the change description — see 5.9. Off by default. |
3.2 Object types
Choose one object type, enter its name and press Enter.
| Radio button | Parameter | Object |
|---|
| TR/Task | S_TASK | Transport request or task (entered in the block above) |
| Program/Include | P_PROG | Report, include |
| Class | P_CLAS | Class |
| Function Module | P_FUNC | Single function module |
| Package | P_PACK | Development package |
| CDS View | P_DDLS | DDL source |
| Function Group | P_FUGR | Whole function group |
| Table (TABD) | P_TABD | DDIC table |
| Domain (DOMA) | P_DOMA | DDIC domain |
| Data element (DTEL) | P_DTEL | DDIC data element |
Interfaces have their own handler too — they are opened from a transport request or a package, not from the Class field.
3.3 Layout / UI preferences
| Field | Parameter | Meaning |
|---|
| Compact/Full Text | P_CMPCT | Only the changed fragments, or the full source with the changes highlighted. |
| 2-Pane/Single Pane | P_PANE | Old and new side by side, or one inline pane. |
| Side-bar/Top-down layout | P_LAYOUT | Where the parts and versions tables sit relative to the viewer. |
To keep this page readable, only the first part of the README is shown. Open the original README for the full document.