SAP Library / ABAP / Cheat sheet
SAP ABAP cheat sheet
38 objects in 4 groups. Each links to its full reviewed page.
T-Codes15
- SE38SE38 is used to create, display, change and execute classic ABAP reports and programs, depending on authorization. It is most useful for direct report execution, debugging and maintenance of classic ABAP program objects. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
- SE80SE80 Object Navigator provides one tree-based entry point to ABAP repository tools such as programs, classes, function groups, dictionary objects, screens, and packages. It does not own a separate business data model; it organizes underlying repository objects. For modern ABAP development, ADT may be preferred, but SE80 remains valuable for legacy and support work.
- SE24SE24 is the Class Builder, used to create and maintain global ABAP OO classes and interfaces: their attributes, methods, events, and inheritance relationships. It generates and stores method source code in system-managed includes rather than in a single flat program, which is the main source of confusion when developers try to edit or transport classes without understanding that structure.
- SE11SE11 is the ABAP Dictionary transaction used to create, display, and change tables, structures, views, data elements, domains, and search helps. It shows field definitions, technical settings, foreign keys, and where-used lists. It does not show table contents; that is SE16N. Changes require activation before they take effect at runtime or on the database.
- SE37SE37 is the Function Builder, used to create, change, test, and debug function modules and BAPIs. It is the standard way to run a function module in isolation with test data before or instead of triggering it through the actual calling program. Function modules live inside function groups, which own the shared global data and main program, and that grouping is the source of most confusion.
- SE16NSE16N is the general table browser: enter a table name, get a generated selection screen, and read the raw content. It bypasses application logic entirely on display, and it has a hidden edit mode (triggered via a command-field entry or specific authorization) that writes directly to the table with no business validation and, usually, no change document trail.
- SE18SE18 is the transaction for creating and maintaining a BAdI (Business Add-In) definition: the hook itself, its generated interface, its filter-dependent and multiple-use settings, and its enhancement spot assignment. It contains no executable logic. The actual code that runs lives in an implementation, maintained separately in SE19, which is where most BAdI troubleshooting should really begin.
- SE19SE19 is the transaction used to create, edit and activate implementations of Business Add-Ins, the customer-facing counterpart to BAdI definitions maintained in SE18. It handles two different generations of the same mechanism - classic filter-dependent BAdIs and enhancement-spot-based BAdIs - each with its own activation and conflict rules, which is the source of most confusion around it.
- ST05ST05 is the SQL/performance trace transaction. It records actual database calls, enqueue requests, RFC calls, and buffer activity for a chosen user during a defined recording window, then displays them as a sortable list. It is the tool used to see whether a slow transaction is spending its time in repeated or expensive SQL statements rather than in ABAP processing.
- SATSAT is the ABAP runtime analysis transaction that measures execution time, call counts, and aggregated database time for a program, transaction, function module, or RFC. It replaced the older SE30 transaction and gives a statement-level breakdown of where processing time is actually spent, distinguishing gross time (including called routines) from net time (own code only).
- SLINSLIN runs the extended (enhanced) syntax check on ABAP source, a static analysis deeper than the plain compiler check triggered from the editor. It flags unused variables, obsolete statements, unreachable code, and potential runtime risks like unassigned field symbols, tied to specific line numbers, without compiling or activating anything. The same check engine underlies Code Inspector and ABAP Test Cockpit.
- SCISCI opens the Code Inspector, which runs a named set of static ABAP checks against a defined object set (programs, classes, packages, or a transport request) using a check variant. The output is a saved snapshot of findings tied to that one run, not a live check, which is the main source of confusion when developers assume the list updates automatically after code changes.
- SE09SE09 is the Workbench Organizer, used to display, create, release and reassign transport requests and their tasks. It shares its underlying data and logic with SE10; the two transactions differ only in their default selection screen (workbench objects versus customizing entries), not in what they actually manage.
- SM30SM30 is the generic transaction for maintaining the contents of customizing tables and maintenance views. It does not maintain arbitrary tables directly; it hands control to a maintenance dialog that must already exist for that table or view. If no maintenance dialog has been generated, SM30 refuses the table outright, which is the single most common source of confusion for anyone new to it.
- SHDBSHDB is used to record SAP GUI screen flows to build or troubleshoot batch-input processing and legacy data-load logic. It is most useful when creating a BDC recording, reproducing a batch-input failure, or documenting exact dynpro field sequences. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
Language & Performance Concepts10
- ABAP Constructor Expressions: VALUE, CORRESPONDING, CONV, REDUCE and FILTERABAP constructor and table expressions let code build, convert, map, filter, and aggregate values declaratively: VALUE creates values, CORRESPONDING maps similarly named components, CONV performs typed conversion, FILTER selects table rows, and REDUCE folds a collection into a result. They can replace verbose helper loops, but dense nested expressions become harder to debug and should be split when business logic stops being obvious.
- ABAP JOIN vs FOR ALL ENTRIESA database JOIN combines related tables in one SQL statement, while FOR ALL ENTRIES (FAE) builds a database selection from values already held in an ABAP internal table. Prefer a JOIN when the relationship exists entirely in the database and can be expressed cleanly. Use FAE when the driving keys genuinely originate in ABAP memory or when a join is impractical, and always guard against an empty driver table.
- ABAP Internal Tables: Standard vs Sorted vs HashedABAP has three concrete internal-table categories: standard, sorted, and hashed. Standard tables favor index access and cheap appends, sorted tables maintain key order and support logarithmic key access, and hashed tables use a unique hash key for key-based access without a primary index. The right choice depends on how the table is filled, read, changed, and iterated.
- Secondary Keys on ABAP Internal TablesSecondary table keys give one ABAP internal table additional sorted or hashed access paths without changing its primary table category. They can make repeated alternative-key reads dramatically cheaper, especially on large tables, but they consume memory and add maintenance cost when rows are inserted, deleted, or changed. Use them only when a measured access pattern justifies the extra index or hash structure.
- SELECT SINGLE vs UP TO 1 ROWS in ABAPSELECT SINGLE is intended for fetching one row when the selection identifies a single result, typically through a full or semantically unique key. SELECT ... UP TO 1 ROWS is a result-set limitation and can be combined with ORDER BY when the business rule means 'choose the first row according to this order.' Without a deterministic order, either construct can return an arbitrary matching row when several rows qualify.
- Class-Based Exceptions in ABAP: TRY, CATCH, CLEANUP and RAISINGClass-based ABAP exceptions use subclasses of CX_ROOT to carry structured error information through RAISING declarations and TRY-CATCH blocks. CX_STATIC_CHECK requires callers to handle or propagate the exception, CX_DYNAMIC_CHECK is checked at runtime rather than syntax time, and CX_NO_CHECK needs no declaration. CLEANUP is reserved for cleanup during exception propagation, not a generic finally block for normal execution.
- Work Areas, Field Symbols and Data References in ABAPA work area holds its own row value, a field symbol acts like an alias to an already assigned memory area, and a data reference stores a reference to a data object. The three are not interchangeable performance tricks: they differ in ownership, lifetime, copying, null/unassigned states, and how safely they can be passed or retained beyond the current loop iteration.
- SAP LUW vs Database LUW and COMMIT WORKA database LUW is one database transaction between database commits or rollbacks; an SAP LUW can span multiple dialog steps and groups logically related application changes by using the update task and enqueue framework. COMMIT WORK ends the current SAP LUW, triggers registered update processing and database commits, and releases relevant locks according to scope. It is therefore a business-transaction boundary, not just a performance statement.
- BAdIs versus user exits versus enhancement pointsThree different mechanisms for injecting custom logic into standard SAP code, from three different eras. User exits are fixed, pre-defined subroutine slots (CMOD/SMOD) with no filtering and one implementation. BAdIs are interface-based, filterable, and support multiple parallel implementations (SE18/SE19). Enhancement points are raw source-code injection slots with no interface at all, riskiest on upgrade, last resort when nothing else exists.
- SAT vs ST05 vs ST12: Choosing the Right SAP Performance TraceSAT profiles ABAP runtime and call hierarchy, ST05 traces database SQL plus RFC/enqueue/buffer activity, and ST12 combines ABAP and SQL trace workflows for a focused transaction/user scenario. Choose based on the suspected layer: CPU/ABAP call cost -> SAT; expensive SQL/row transfer -> ST05; uncertain mixed application/database bottleneck -> ST12. Trace narrowly because production traces can generate significant volume.
Modern ABAP & Clean Core7
- ABAP Cloud and the released API modelABAP Cloud is the restricted programming model that only lets custom code call objects SAP has explicitly marked with a release contract, using a syntax subset enforced at compile time. It replaces the old approach of calling any table or function module directly, trading some short-term convenience for upgrade stability. It is mandatory on S/4HANA Cloud public edition and the BTP ABAP environment, and recommended elsewhere.
- ABAP SQL performance rules that still matter on HANAHANA does not remove the cost of database round trips or inefficient ABAP access patterns. Avoid SELECT inside loops, push filtering and aggregation to the database, select only required columns, and use JOIN, FOR ALL ENTRIES, CDS or suitable keys deliberately. Performance still depends on execution count, result-set size, predicates and data volume, so verify important paths with ST05, SQLM, SAT or ST12.
- Code pushdown from ABAP to HANACode pushdown means moving data-intensive logic out of the ABAP application layer and into the HANA database, using Open SQL that exploits HANA's engines, CDS views with calculation logic, or AMDP methods written in SQLScript. It cuts data transfer and loop-based processing in ABAP, but it also moves debugging, testing and portability out of familiar ABAP territory.
- Clean core explained for ABAP developersClean core is the practice of keeping the S/4HANA standard software layer unmodified and pushing all custom logic into defined extension points using released APIs, so upgrades and cloud moves do not break custom code. It is a governance discipline, not a tool, enforced through extensibility models, ATC checks, and released API lists rather than a single switch or setting.
- Custom code migration for S/4HANACustom code migration is the project activity that finds, classifies and fixes every Z and Y ABAP object that will break, misbehave, or become obsolete when a system moves to S/4HANA. It runs on ATC results plus usage data, and it is really three separate workstreams - simplification-driven fixes, HANA-specific fixes, and general hygiene - that get mistakenly treated as one backlog.
- ATC checks in an S/4HANA conversionATC checks in an S/4HANA conversion are ABAP Test Cockpit runs against a system's custom code base using SAP-delivered check variants that flag simplification-item breaks, deprecated objects, and HANA-unsafe SQL before or during a technical conversion. They produce a prioritized worklist of findings that must be remediated so custom code compiles and runs correctly after the target release goes live.
- Database Indexes on SAP HANA for ABAP DevelopersSAP HANA column-store tables already maintain column-oriented structures that make many filters efficient, so secondary indexes should not be added by reflex. An additional index can help highly selective access patterns—especially where a repeated predicate cannot be served efficiently otherwise—but every index costs memory and write/merge maintenance. Prove the need with SQL trace and HANA plan evidence, and never create indexes casually on SAP standard tables.
Common Dumps6
- CX_SY_ITAB_LINE_NOT_FOUNDCX_SY_ITAB_LINE_NOT_FOUND is an uncaught class-based exception raised when a table expression, such as itab[ key ], finds no matching row and the surrounding code has no TRY/CATCH or LINE_EXISTS guard. It almost always points to either a missing TRY/CATCH after a code refactor, or a genuine data gap in the lookup table the developer assumed was always populated.
- CX_SY_REF_IS_INITIALCX_SY_REF_IS_INITIAL is raised when ABAP code dereferences a data reference variable (declared TYPE REF TO ...) using the ->* operator while that reference is still initial, i.e. it has never been bound to a data object with CREATE DATA, GET REFERENCE, or a successful REFERENCE INTO read. The fix is almost always a missing bound-check in custom or BAdI code, not a Basis or infrastructure problem.
- CX_SY_ZERODIVIDECX_SY_ZERODIVIDE is the class-based exception the ABAP runtime raises when a division statement encounters a zero divisor in code that participates in the class-based exception model. If nothing catches it, the session terminates with an UNCAUGHT_EXCEPTION short dump naming CX_SY_ZERODIVIDE as the exception class, pointing at the exact ABAP statement that performed the division.
- CALL_FUNCTION_NOT_FOUNDCALL_FUNCTION_NOT_FOUND means the ABAP runtime tried to resolve a function module name in a CALL FUNCTION statement and found no active, generated function module of that name in the target system, whether local or across RFC. It almost always traces to a transport gap, a typo or renamed FM, a stale RFC destination, or a function group that failed generation.
- CALL_FUNCTION_REMOTE_ERRORCALL_FUNCTION_REMOTE_ERROR occurs when a CALL FUNCTION ... DESTINATION statement fails on the remote system and the calling program has no SYSTEM_FAILURE or COMMUNICATION_FAILURE exception declared to catch it. The real fault is almost always on the remote side — a remote dump, a rejected connection, or an authorization failure — surfacing locally as an uncaught runtime error.
- CX_SY_NO_HANDLERCX_SY_NO_HANDLER is the runtime system's own exception, raised when a class-based exception has unwound the entire call stack without meeting a matching CATCH statement. It signals a structural gap in exception routing, usually because the raise happened through a FORM, a dynamic call, an event handler, or a BAdI implementation that the compiler could not statically check for a handler.