ABAP RTTI and RTTS for Dynamic Programming
RTTI lets ABAP inspect the runtime type of existing data through CL_ABAP_TYPEDESCR and subclasses; RTTS extends the same type-description classes to create types dynamically, for example structures, tables, references or elementary descriptors. Use them for generic frameworks where the shape truly is runtime-driven. Prefer static DDIC/local typing when the structure is known, because dynamic components move errors from syntax time to runtime.
Practical reference for ABAP RTTI and RTTS for Dynamic Programming, including how the mechanism works, when it is appropriate, where it fits in SAP runtime/architecture, a realistic example, decision guidance, failure patterns, S/4HANA direction and operational ownership.
Reviewed by an ERPClimb SAP consultant on 20 Sept 2026· 749 words
What it is
The ABAP type-description hierarchy includes descriptors for elementary types, structures, tables, references, classes and interfaces. DESCRIBE_BY_DATA/DESCRIBE_BY_NAME style factory methods return RTTI metadata such as component lists, lengths, decimals, table keys or referenced types. RTTS uses create methods on structure/table/element descriptors to build a runtime type, after which CREATE DATA TYPE HANDLE can instantiate data and field symbols can access components dynamically. RTTI/RTTS are central to generic serializers, data browsers, ALV generators, mapping tools and frameworks that cannot know every line type at compile time.
When to use it
Use RTTI when code must inspect an arbitrary data reference, field symbol, DDIC name or generic parameter. Use RTTS when the target structure/table genuinely depends on runtime metadata, such as dynamically selected columns. Do not use dynamic typing to avoid declaring a known business structure or to bypass API contracts. If a report always reads the same sales-order fields, a static typed structure is safer, faster to understand and checked by the compiler.
How it fits the stack
RTTI/RTTS often appear with field symbols, data references, ASSIGN COMPONENT, dynamic Open SQL column lists, ALV field catalogs, generic JSON/XML mapping and testing tools. They replace older reliance on nametab function modules for many runtime-type questions. Clean-core rules still apply to any repository/DDIC object being described. Dynamic typing does not give permission to access unreleased tables or fields.
A worked example
A generic extract utility receives a DDIC structure name and a requested field list. It uses RTTI to validate that each field exists and to inspect types. RTTS builds a result structure containing only selected fields, then an internal table type around that structure. The extractor can now work generically without one custom type per object. A business posting program with a fixed payload, however, keeps a static released API structure because dynamic mapping would hide contract errors.
How to choose
- Use RTTI for inspection; use RTTS only when a new runtime type is actually required.
- Prefer static types for stable business interfaces and persistence models.
- Validate component names/types before dynamic ASSIGN or Open SQL use.
- Cache type descriptors within the request when repeated reflection becomes expensive.
- Wrap dynamic logic behind a small well-tested utility rather than spreading ASSIGN COMPONENT throughout business code.
Common pitfalls
- Assuming CAST/DOWNCAST of a type descriptor is safe without checking descriptor kind.
- Using generic TYPE ANY everywhere and losing compile-time protection.
- Building dynamic SQL field names from unchecked external input.
- Creating a new RTTS type inside a large loop instead of reusing descriptors.
- Using runtime reflection to work around an unstable or unreleased business interface.
ECC, S/4HANA and clean core
RTTI/RTTS remain standard ABAP capabilities in S/4HANA and are useful in ABAP Cloud within released language/API constraints. Modern ABAP favors these classes over internal DDIC function modules for runtime type inspection. Cloud restrictions affect which repository objects/data sources may be consumed, not the core reflection semantics.
Whose problem this is
ABAP framework developers own dynamic-type design and defensive validation. Business application teams should justify why runtime typing is necessary. Security reviewers should inspect any dynamic field/table names derived from user or external input because reflection combined with dynamic SQL can widen access unexpectedly.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-technical-topics/abap-rtti-rtts-dynamic-programmingERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.