The SAP ABAP package no one understands: AI-generated living docs for legacy SAP ABAP on AWS
Use a foundation model on Amazon Bedrock to document an SAP ABAP package with a call graph, class summaries, an onboarding README, and plain-English method explanations, all with read-only SAP access.
Series: AI Assisted SAP ABAP workflows using Kiro Agents (3 articles)
- 3The SAP ABAP package no one understands: AI-generated living docs for legacy SAP ABAP on AWS This article
A new developer joins on Monday and is expected to be productive by Friday in a custom ABAP package whose code-focused subset contains 118 objects: classes, interfaces, programs, and function groups. The broader all-object package inventory used for decommissioning contains 143 objects. Only four people have touched the package in a decade, and it has no
README. The developer opens a class, follows a call into another class, follows that call into a third, loses the thread, and starts again. Three weeks later, they can change something. A clear understanding of the package may take much longer.Teams lose weeks while capable developers build a mental model of code that already works. This post shows how to reduce that onboarding time with AI-generated living documentation. A foundation model on Amazon Bedrock, used through Kiro CLI, reads the package, maps the relationships, and creates the documentation that the original authors never wrote. Every SAP operation is read-only. A hands-on workshop at the end lets you run the same process.
This workflow uses
abapctl to connect Kiro CLI to SAP through ADT APIs and run its SAP operations. To learn how abapctl works and how to get started, visit the official abapctl documentation .The problem: the knowledge is in the code, and only in the code
Meet Marco, a tech lead at a logistics company running SAP on AWS. He has inherited
ZSFLIGHT, a package built over several years by developers who have moved on. It works and runs in production every night. Nobody on the current team can explain the complete flow.The problem is not a defect. The team has no reliable map:
- Every new developer repeats the same investigation. They spend days following where-used lists in ADT. Existing comments often describe code that changed several refactors ago.
- Changes feel risky because the impact is unclear. If Marco changes a DAO method, he cannot quickly tell which callers may break. He must inspect the where-used results by hand.
- The layers are not documented.
ZSFLIGHTfollows a useful DAO, manager, and service design, but that design exists only in the memories of former developers. A new team member cannot open a current diagram and see it.
Tools such as SE80, ADT, and where-used show structure, but they do not explain purpose. They can show that
ZCL_SFLIGHT_BOOKING_DAO runs a SELECT on SBOOK. They do not explain that the class is the booking persistence layer or identify the method a developer should read first. A language model can turn those technical relationships into a useful explanation.The capability: read the code, map it, and explain it without changing it
The agent uses
abapctl to retrieve source, where-used relationships, and call hierarchies through ADT's REST APIs. All calls are display-only. It sends that context to a model on Amazon Bedrock to create four artifacts that developers can use:- Navigation, where-used results, and a call graph. The agent follows the dependency graph to show which classes call each other, which methods are entry points, and what belongs in each layer. A developer can then read from the top down instead of working backward through a long where-used list.
- Behavior summaries. Each object gets a plain-English purpose statement that explains what the class does and which objects it works with. This is the context that useful comments should provide but often do not.
- Living documentation. The summaries and call graph become an onboarding README with an architecture overview, a guide to each layer, entry points, and a suggested reading order. The team can regenerate it from the current source whenever needed.
- "Explain this method." A developer can select one difficult routine and get an explanation of its inputs, outputs, branches, and edge cases. It provides the kind of context they would ask the original author to explain.
Because every SAP request is read-only, there is no transport, no activation, and nothing to roll back. The worst result is a document that a reviewer corrects, not a change to the SAP system.
How to run it
The process has four main steps. The workshop provides the detailed instructions:
- Prerequisites: install Kiro CLI on an automation host and use an AWS account with Amazon Bedrock access plus a DEV or sandbox SAP connection.
- Connect: configure a read-only profile for the DEV ADT endpoint. Retrieve the SAP password from AWS Secrets Manager at runtime instead of storing it on disk.
- Run: point the agent at a package. It lists the objects, builds the call graph, summarizes each object, and creates the README.
- Output: save the Markdown documentation and call graph in a local repository or an S3 bucket that you choose. Do not write them back to SAP.
Comprehension in action: making sense of ZSFLIGHT
The example below runs against a live S/4HANA development system (SID
S4H, client 100). Its ZSFLIGHT package contains 118 code objects, including classes, interfaces, programs, and function groups, with limited documentation. Every command is read-only. The object count and names are real; the generated prose is representative.The call graph. One read-only pass shows the layers clearly:
1
2
3
4
5
ZSFLIGHT (118 objects): layered DAO / manager / service
service layer → orchestrates a booking request end to end
└─ manager → applies pricing + discount rules
├─ ZCL_SFLIGHT_CALCULATOR (pure logic: fees, multipliers, discounts)
└─ ZCL_SFLIGHT_BOOKING_DAO (persistence: reads/writes SBOOK)A new developer sees the stack instead of a flat where-used list. Building the same picture by hand can take a week.
Per-class purpose. For
ZCL_SFLIGHT_BOOKING_DAO:Booking persistence (DAO layer). Encapsulates all reads and writes against theSBOOKtable so the rest of the package never touches SQL directly. Key methods:read_booking, plus create, cancel, update. Called by the booking manager. Start here if you're changing how bookings are stored or read.
The onboarding README. The agent combines these summaries with the call graph in a package
README.md. It explains what the package does, shows the layers and entry points, and recommends this reading order: service, manager, calculator, and DAO. A new developer gets one Markdown file instead of opening 118 objects without a guide."Explain this method." When asked about
calc_group_discount, a compact tiered IF with hard-coded numbers, the agent returns:calc_group_discount( iv_count )→ discount rate. Returns a group-size discount: 20+ → 0.20, 10–19 → 0.15, 5–9 → 0.10, fewer than 5 → none. Tiers are checked largest-first, so the highest qualifying discount wins. Watch out: thresholds and rates are hard-coded literals.
A new developer can understand the rule and its main maintenance concern without tracing every branch first.
Outcome: less time spent getting up to speed
| Metric | Manual onboarding | With AI-generated living docs |
|---|---|---|
| Understand layering | days of where-used review | one call graph, read-only (real structure) |
| Per-class purpose | worked out one object at a time | plain-English summary per object |
| Onboarding guide | missing / stale | generated README + reading order, regenerable |
| A difficult routine | trace the logic and infer intent | explained with tiers + caveat |
| New-joiner time-to-context | illustrative: ~2-3 weeks | illustrative: hours to a day |
The 118 objects, the layers, and the class names are real. The onboarding time figures are illustrative. AI does not remove the need to read code. It gives a new developer a starting map instead of a blank page, and the team can regenerate that map from the current source.
You just saw the agent turn a package with limited documentation into a call graph, per-class summaries, an onboarding README, and a method explanation. Every SAP step was read-only. You can run the same flow in the workshop below.
Performance at scale
These figures come from the same development system, with read-only access throughout. Setup: SID
S4H, client 100, ZSFLIGHT with 118 objects, and one automation host.| Metric | Value | Source |
|---|---|---|
| Objects in package | 118 | measured |
| Structure + call-graph extraction | ADT reads, seconds per object | measured |
| Objects summarized per hour | illustrative: ~150-300, limited by model latency + concurrency | illustrative |
| Re-run cost | read-only and idempotent; safe to run every sprint | measured |
| Human approval before SAP changes | n/a; the output is documentation and is never committed to SAP | design |
Because the process is read-only and idempotent, you can run it as a scheduled job. A nightly run keeps the documentation no more than a day behind the source. Use objects summarized per hour to estimate model cost and the time needed to document a package.
Build it in your landscape
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
flowchart TB
subgraph SAP["SAP DEV · read-only"]
direction TB
subgraph CONTEXT["ABAP context"]
direction LR
SRC["Source"]
USE["Where-used"]
CALL["Call data"]
end
ADT["ADT REST API<br/>read-only"]
SRC --> ADT
USE --> ADT
CALL --> ADT
end
subgraph AWS["Customer AWS account / VPC"]
direction TB
HOST["Automation host<br/>Kiro CLI + abapctl"]
BR["Amazon Bedrock<br/>Claude Opus 5"]
HOST -->|Summarize| BR
end
subgraph DOCS["Generated documentation"]
direction LR
GRAPH["Call graph"]
README["README"]
SUMMARY["Summaries"]
end
ADT -->|Retrieve| HOST
BR --> GRAPH
BR --> README
BR --> SUMMARY
classDef aws fill:#FFF3E0,stroke:#FF9900,stroke-width:2px,color:#1F2937;
classDef sap fill:#EAF3F8,stroke:#0A6ED1,stroke-width:2px,color:#1F2937;
classDef process fill:#F3F4F6,stroke:#6B7280,stroke-width:2px,color:#1F2937;
classDef gate fill:#ECFDF3,stroke:#1F8A4C,stroke-width:2px,color:#1F2937;
classDef output fill:#F3E8FF,stroke:#7E22CE,stroke-width:2px,color:#1F2937;
class HOST,BR aws;
class SRC,USE,CALL,ADT sap;
class GRAPH,README,SUMMARY output;In both designs, Kiro CLI and
abapctl run on a small automation host. You can use a laptop, an EC2 instance, or a CI runner for scheduled updates. The host invokes the model through Amazon Bedrock. All SAP requests use HTTPS to ADT endpoints on a DEV or sandbox system and are display-only.- AWS-native: the host connects directly from your VPC to the DEV ADT endpoint. It retrieves the SAP password from AWS Secrets Manager and reaches Bedrock through a VPC endpoint (PrivateLink). The source does not cross the public internet. The generated documentation goes to your S3 bucket or Git repository.
- SAP RISE on AWS: the DEV system runs in the SAP-managed environment. The automation host runs in your account and connects to ADT through the RISE-provided connectivity path. No direct database or operating system access is required because
abapctluses the same ADT REST APIs as Eclipse. Bedrock remains in your account.
What differs: With RISE, ABAP source moves from the SAP-managed environment to your account so the model can read it. Nothing is written back, but the read still crosses an account boundary. Document which source leaves, where it is processed, and which Region is used. Obtain the required data-transfer approval. Amazon Bedrock does not use prompts or completions to train base models, and the data remains in your Region.
Which model, and what it costs
This example uses Anthropic Claude Opus 5 on Amazon Bedrock as the series default. Code summarization, however, can work well with a smaller model. Nothing is committed to SAP, and a person reviews the documentation. A less detailed summary may need editing, but it cannot change the running system. This makes code comprehension a good use case for a lower-cost model.
| Model on Bedrock | Cost/token | Fit here | Impact |
|---|---|---|---|
| Claude Opus 5 (default) | $$$ | Highest | Most detailed summaries and method explanations |
| Claude Sonnet-class | $$ | High | Strong documentation at lower cost; a practical default for many objects |
| Amazon Nova / Haiku-class | $ | Good for structure + short summaries | Lowest cost and fastest for a first-pass README |
A person reviews the output before using it. A smaller model therefore trades some detail and writing quality for lower cost, not SAP system safety. For a one-time run across many packages, Sonnet-class or Nova-class may be the better choice.
Cost. Illustrative; confirm current rates on the Amazon Bedrock pricing page and with the AWS Pricing Calculator . One object of about 100-150 lines plus its prompt uses roughly ~3-8k input tokens and ~0.3-1k output tokens. This task is mostly reading and summarization. It does not need multi-step reasoning, successor lookups, or an approval gate. Documenting a 118-object package usually costs cents to a low-single-digit dollar amount. A new run costs about the same, which is small compared with the developer time needed to document the package by hand.
Alternatives, and when to choose them
- SAP's built-in tooling: ADT/SE80 where-used, ABAP Doc, and Joule for Developers. These are first-party tools integrated with SAP. Choose the Kiro + Bedrock approach when you want current prose documentation and call graphs in a repository you control, a choice of models, and a process that can run in CI.
- Hand-written documentation. People can provide the most precise explanation when the document is new, but manual documentation often becomes outdated. Choose generated living documentation when the team has not been able to keep manual documents current.
- Static call-graph or diagram tools. These tools show structure but do not explain purpose. Use them with a model that adds the missing context.
Security and SAP authorizations
Every SAP step is a display-only ADT read against a DEV or sandbox system. There is nothing to write back and nothing to roll back. The tooling retrieves the SAP password from AWS Secrets Manager at runtime and does not store it on disk or in logs. It reaches Bedrock through VPC endpoints and, for RISE, uses the agreed private connectivity path. The model does read ABAP source. Classify that source and obtain data-transfer approval, especially for RISE.
Adoption is simpler because the process is entirely read-only. There is no mutating tier. Confirm the exact authorization objects and values for your SAP release.
| Action | SAP authorization (typical) | Tier |
|---|---|---|
| Reach the ADT REST endpoint | active /sap/bc/adt ICF services (SICF) + developer access | read |
| Read source, where-used, call graph | S_DEVELOP with ACTVT 03 (display only) | read |
| Read metadata via OData (if used) | S_SERVICE for the relevant services | read |
Grant a display-only developer user. Do not grant
S_TRANSPRT, create/change/activate rights, or write access to application tables. The user cannot change the SAP system even if the tooling attempts a write. This limited access can make the security review more direct.Try it yourself
You have seen the agent turn a 118-object package with limited documentation into a call graph, per-class purpose statements, an onboarding README, and a plain-English method explanation. Every SAP step used read-only access. Now run it against a sandbox:
AI Assisted SAP ABAP workflows using Kiro Agents , starting with Use Case 4: Legacy Code Comprehension.
- You'll build: a read-only process that generates a call graph, per-object summaries, and an onboarding README for a sample package.
- You'll leave with: a repeatable documentation process that can run against your own DEV system and as a nightly job.
- What you need: an AWS account with Amazon Bedrock access and a DEV or sandbox SAP connection. You do not need prior agent experience or SAP write authorizations.
- RISE customer? Use the same process over your RISE-provided connectivity path.
Wrap-up
A legacy ABAP package may contain years of useful knowledge that exists only in the source. Each new developer spends time rebuilding the same understanding. A read-only process on AWS can use a model on Amazon Bedrock to read that code through ADT and create documentation your team controls. The call graph and README can be regenerated whenever the source changes. The process has no SAP write risk and is inexpensive enough to run nightly.
- 🔎 Run it: AI Assisted SAP ABAP workflows using Kiro Agents (start with Use Case 4).
- 💬 Which package is hardest for your team to understand? Share what you would document first.
If you inherited a package that nobody can explain, start with this read-only approach. It requires no SAP write approval and cannot change the running system.
Series: AI Assisted SAP ABAP workflows using Kiro Agents (3 articles)
- 3The SAP ABAP package no one understands: AI-generated living docs for legacy SAP ABAP on AWS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article