SAP Performance Optimization often comes down to three coding patterns, not a hundred bad habits. They are a database call buried inside a loop, a full-table scan on a large table, and aggregation done in ABAP when the database could do it in a blink. Teams that fix these three usually see their worst reports drop from minutes to seconds. This post explains each pattern with simple before and after logic, then shows how AI scans a whole custom code estate to find them faster than any manual review.
What Makes a Custom SAP Report Slow?
A custom SAP report slows down when ABAP code moves too much data, too many times, between the application server and the database. The cause is rarely the hardware. Almost always, it is the way the code asks for data.
Think of a report that runs fine in a test system with 5,000 sales orders. Then production holds several years of orders, and the same report takes 40 minutes. Nothing changed in the code. The data volume exposed the pattern.
SAP Performance Optimization starts with that insight. You do not tune servers first. You find the specific statements that waste the most runtime, and you fix those.
The three anti-patterns share one trait. Each one works correctly and passes testing, so nobody flags it. The report returns the right numbers. It just returns them slowly, and the delay grows as the business grows.
Why These Patterns Survive for Years
Developers wrote much of this code a decade ago, often under deadline pressure. The original author may have left the company. Also, the code rarely breaks, so no one has a reason to open it.
Here is the typical life of a slow report:
- A developer builds it quickly for a small business need.
- Data volume grows and users start waiting.
- Users schedule it as an overnight job to hide the delay.
- The job starts overlapping with other batch work, and the pain spreads.
By step four, the report is a risk to the whole batch window, and nobody remembers why it is slow.
How Do Database Calls Inside Loops Hurt Runtime?
A database call inside a loop means the program queries the database once for every row it processes, instead of fetching all the data it needs in one request. Each call carries fixed overhead, so thousands of small calls cost far more than one large call.
Here is the before logic. The report reads 50,000 sales order items into an internal table. Then, for each item, it runs a SELECT SINGLE against the material master table to fetch the description. That is 50,000 separate database round trips.
The after logic is simple. Collect the distinct material numbers first. Run one SELECT with a FOR ALL ENTRIES clause or a join. Read the results into a sorted or hashed internal table. Then look up each description in memory.
The result is one database call instead of 50,000. The business output is identical. The runtime is not.
What This Looks Like in Practice
For example, imagine a Toronto distributor running a stock aging report. The original code loops over plant and storage location combinations and queries stock quantities inside the loop. Planners wait 25 minutes each morning.
After the rewrite, the report reads all stock rows in one statement and builds the aging buckets in memory. Planners get the same figures before their first coffee finishes brewing.
Watch for these warning signs in your own code:
- SELECT or SELECT SINGLE statements sitting inside LOOP, DO, or WHILE blocks
- Calls to function modules inside loops that run their own database reads
- Nested loops where the inner loop reads a standard internal table without a key
That last item matters. A nested loop over a standard table forces a linear search for every outer row. Switching to a sorted or hashed table fixes it, and the change is often only a few lines.
Why Do Full-Table Scans Slow Down Reports?
A full-table scan happens when the database reads every row in a table because no index supports the query conditions. On a small table, the scan is invisible. On a large transactional table, it becomes the single biggest cost in the report.
The before logic is common. A report selects from a large document table using a field that is not part of any index, such as a custom status field or a text-based filter. The database has no shortcut, so it reads everything and discards most of it.
The after logic has several options. Add the key fields the table already indexes to the WHERE clause, such as company code, document date, or plant. Rewrite the filter so it uses indexed fields first. In some cases, a secondary index makes sense, but only after an architect confirms the write cost is acceptable.
Many developers also write SELECT * out of habit. That pulls every column across the network when the report needs four. Naming the required fields cuts data transfer sharply, which helps even when the scan itself stays.
The Selection Screen Problem
Selection screens create their own trap. When users leave date ranges blank, the report scans all history. A simple rule fixes this: force a sensible default range, or validate that at least one indexed field carries a value.
Here is a quick test. Ask whether the report would still behave if a user cleared every filter. If the answer is no, the code needs guardrails.
What Goes Wrong When ABAP Does the Aggregation?
Aggregation in ABAP means the program pulls detailed rows into memory and then sums, counts, or groups them in a loop, instead of asking the database to do it. Databases are built for this work, and SAP HANA does it extremely fast.
The before logic looks like this. A report selects 2 million billing line items. A loop then adds up revenue by customer and product group using COLLECT or manual internal table updates. The application server holds millions of rows just to produce a few hundred totals.
The after logic pushes the work down. A single SELECT with SUM and GROUP BY returns only the few hundred result rows. Alternatively, a Core Data Services view defines the aggregation once, and many reports reuse it.
This is the idea behind HANA pushdown. Code pushdown means moving calculation logic from the ABAP layer into the database layer, so only finished results travel across the network.
Why This Matters for Migration
The pattern matters even more during an SAP ECC to S4HANA Migration. Code written for older databases often pulls raw data and calculates in ABAP, because that was once the sensible choice. On HANA, the same code wastes the platform’s strengths.
Teams that migrate without addressing this carry old habits onto a new database. The system runs, but the reports never benefit from the investment. Clean-up work belongs inside the migration plan, not after it.
How Does AI Find These Anti-Patterns Across the Estate?
AI finds ABAP anti-patterns by reading custom code at scale, matching it against known problem structures, and ranking each finding by its likely runtime cost. A human reviewer might check 20 programs a week. An automated scan covers thousands of objects in hours.
Manual review has a second weakness. People notice what they already know to look for, and they tire. A scanner applies the same logic to object 4,000 as it did to object one. Reliable AI results also depend on clean inputs, which is why SAP’s guidance on data quality and AI governance is worth reading before you automate any code analysis.
The approach used in our five-step method works like this:
- Measure: Collect real runtime data from production traces and statistics.
- Analyse: Scan the code for loop database calls, full-table scans, and ABAP-side aggregation.
- Rank: Sort findings by runtime multiplied by execution frequency.
- Rewrite: Apply HANA pushdown and set-based database logic.
- Prove: Compare old and new output row by row, and record before and after runtimes.
Step three deserves attention. A report that runs 30 minutes once a month matters less than a 20-second report that runs 10,000 times a day. Ranking by runtime times frequency sends effort where it pays back first.
Why Human Review Still Matters
AI finds candidates. It does not approve changes. An architect reviews every rewrite before it moves to transport, because business logic carries context that a scanner cannot see.
The proof step protects you here. Row-by-row parity checks show that the rewritten report returns exactly the same data as the original. If one row differs, the change does not ship.
This AI ABAP remediation workflow keeps speed and control together. The scanner supplies breadth, and the architect supplies judgment.
How Should You Plan an ABAP Clean-Up Project?
Plan an ABAP clean-up by starting with measurement, fixing the highest-impact reports first, and proving each change before release. Skip the temptation to rewrite everything. A focused effort on the worst offenders delivers most of the gain.
For IT directors, the business case is simple. Slow reports consume batch windows, delay decisions, and push teams toward expensive hardware upgrades that do not fix the cause. Fixing code is cheaper than adding capacity.
For SAP developers, this work builds valuable skills. Understanding HANA pushdown, CDS views, and runtime analysis makes you far more useful in modernization projects. Employers look for exactly this experience.
A sensible starting checklist looks like this:
- Pull a list of the longest-running custom reports from your system statistics
- Note how often each one runs
- Identify which of the three anti-patterns each report contains
- Estimate the effort of each rewrite against the time it saves
- Agree a transport and regression test plan before touching code
Where Custom Code Strategy Fits
Many companies treat custom code as a liability to shrink. Others treat it as a competitive asset to keep sharp. Both views need a clear picture of what exists. SAP Custom Development works best when someone has already cleaned the foundations, because new programs inherit the habits of the old ones.
Good SAP ABAP modernization also sets coding standards so the same anti-patterns do not return. A short review checklist at the code review stage prevents most of them. For deeper SAP report optimization, teams often add automated checks into the transport pipeline.
You can read more about SAP’s platform direction on the SAP S/4HANA product page.
Frequently Asked Questions
Q. What is the most common cause of slow custom SAP reports?
A. Database calls inside loops cause more slowdowns than any other single pattern. Each iteration adds a round trip to the database, so runtime grows with data volume. Moving to one set-based query usually fixes it.
Q. Can AI really fix ABAP code, or does it only find problems?
A. AI is strongest at finding and ranking problems across thousands of objects. Rewrites still pass through an architect review and a row-by-row parity check before transport. 2iSolutions uses that combination so speed never costs accuracy.
Q. Do I need SAP HANA to benefit from these fixes?
A. Fixing loop queries and full-table scans helps on any database. Aggregation pushdown delivers its biggest gains on HANA, because the platform calculates in memory at high speed. Companies planning a move to HANA should fix these patterns first.
Q. How do I know which reports to fix first?
A. Rank reports by runtime multiplied by how often they run. A short report that runs constantly can cost more than a long report that runs monthly. System statistics and production traces give you the data.
Q. Where can I find SAP Consulting Services Canada for ABAP work?
A. Look for a partner with HANA pushdown experience and a proof process that compares old and new results. 2iSolutions is a Toronto-based SAP partner serving Canadian clients with performance and modernization work.
Turning Three Patterns Into a Faster SAP System
Slow reports rarely need new hardware. They need a short list of coding habits corrected: queries moved out of loops, scans narrowed with indexed filters, and aggregation pushed down to the database. AI makes finding those habits across a large estate practical, and architect review keeps every change safe.
The strongest results come from following the sequence: measure, analyse, rank, rewrite, and prove. Teams that skip the ranking or the proof step either waste effort or risk wrong numbers. Teams that follow all five steps get faster reports and the evidence to show it.
Email us at info@2isolutions.com to request a performance review.
