Twelve SAP GUI transactions, three per master object, written in the late nineties. One agent, two MCP servers, no line of code written by hand. What came out is not the same application in a new frame. It is a better one, because the decisions were taken from the whole picture of the system, not from one program at a time. This is the walk-through, with the evidence.
The starting point
The legacy application manages flights, bookings, customers and travel agencies. Twelve module pools carry it: for every master object one transaction to display, one to change, one to create. Each of them has its own screens, its own field checks and its own copy of the rules. A nightly check run repairs what the dialogs failed to validate during the day.
A migration that reads these programs one by one and rebuilds them one by one ends with twelve Fiori apps that repeat the same mistakes in a new framework. The interesting part happens before anything is built.
What the whole picture showed
Before the agent wrote anything, it read the knowledge graph of the system through Sysparency MCP: which programs exist, which tables they write, who calls whom, how often each transaction runs, and what the business rules are. Three findings changed the design.
The dialogs are not the only writers to the booking table. The graph lists eleven applications that access SBOOK. Besides the three dialog programs, the function group SAPBC_GLOBAL_FIS inserts and updates, the BAPI group SAPBC_BAPI_SBOOK updates, and the ALE generator SAPBC_DATA_GENERATOR_ALE deletes. Thirty-five RFC-enabled function modules sit on the same tables. A new app that only replaces the dialogs would be one more writer among many.
A nightly check run repairs what the entry point fails to validate. The graph holds a check program with usage 0 that reads the three master tables, and an ATC finding of priority 1, a missing authority check, on the edit dialog. The rules themselves live in the function module SAPBC_GLOBAL_BOOK: invalid customer, invalid travel agency, invalid class, flight booked out.
73 percent of all calls are display only. The usage counters per transaction show 4,870 display calls against 158 edits by travel agencies. The application is read far more than it is written.
How the agent worked
The agent had two tools. Sysparency MCP answers questions about the existing system with cited facts: graph queries, semantic search over the business descriptions, the source of a program, the fields of a screen. SAP ADT MCP creates, changes and activates objects in the target system. The loop is always the same: ask the graph, decide, build, check.
For the new system it created four RAP business objects with CDS views, behaviour definitions and behaviour implementations, one OData V4 service, three Fiori Elements apps for flights and bookings, customers and travel agencies, an analytics dashboard and the launchpad that holds them. Every object was generated and activated through ADT. The people involved reviewed and decided; nobody typed ABAP.
What was built differently
Rules once, in the data model. The seven checks that used to be scattered across twelve programs and a nightly run now fire on save, inside the business objects: connection exists, flight date is valid, capacity is not exceeded, customer exists, travel agency exists, class is valid, seats are available. The check run is retired.
One click path instead of three transactions. A booking is created, changed and displayed on one object page. Read mode is the default, because that is what 73 percent of the calls do; editing is a deliberate step.
One field less. The obsolete smoker flag, still carried by the old screens, is gone from the new interface. The database column stays until the next step.
Four analytics that never existed. Flights, seats and revenue per airline, bookings by class and cancellation, a ranking of travel agencies, and a booking trend, all as CDS analytics on the same tables.
The numbers
- 12 to 4: twelve programs became four business objects behind one OData service.
- 3 to 1: three transactions per booking became one click path.
- 0 to 7: seven rules on save, instead of a nightly check run.
- 0 to 4: four analytics: KPIs, charts, ranking, trend.
What it is not
The application runs on SAP reference data on a trial system, not on a customer system. RFC, ALE and IDoc still write to the tables directly; routing them through the business objects is the documented next step, and the list of what to route already exists, because the graph produced it. The rebuild took an afternoon of agent time and a few hours of human review.
What this means for your system
The lesson is not that an agent can generate ABAP. It can, and so can several tools. The lesson is where the design decisions came from: from the whole picture of the system, with every dependency, every writer, every usage counter and every rule cited to its source line. Without that picture the agent would have rebuilt twelve programs. With it, it built one application and improved the system in the same move.
Every custom system carries the same questions. Who else writes this table? What does the nightly job repair? Which of these transactions does anyone still use? Sysparency answers them from the code, for people and for agents, before the first line of the new system is generated.