The ABAP Cloud Shift: A Technical Guide to Syntax and UI Changes

ABAP Cloud: Syntax Differences and Replacements

ABAP Cloud introduces a modernized and restricted development model compared to classic on-premise ABAP, leading to significant differences in syntax and available statements. The shift is driven by the need for cloud-ready, lifecycle-stable, and upgrade-safe applications, emphasizing a clean core strategy and service-oriented architecture.

Here are the key differences in syntax and the statements that are not available or are replaced in ABAP Cloud:

Core Principles Driving Syntax Changes

• Restricted ABAP Environment: ABAP Cloud enforces a restricted ABAP environment that mandates the use of public APIs and extension points, decoupling custom developments from the core system. This ensures system stability and upgradeability.

• Cloud-Optimized ABAP Language: The ABAP language versions “ABAP for Key Users” and “ABAP for Cloud Development” are cloud-optimized, defining specific syntax rules and a limited set of accessible repository objects.

• No Direct Database Access: Unlike classic ABAP, which relied on direct database access and monolithic architecture, ABAP Cloud promotes a service-oriented architecture using APIs for data access and integration. This means direct table reads and direct file system access are generally not permitted.

• No SAP GUI: The absence of SAP GUI in the cloud environment means all GUI-based programming is disallowed, solidifying Eclipse as the main ABAP IDE (ABAP Development Tools for Eclipse – ADT).

Statements and Functionalities Not Available or Replaced in ABAP Cloud:

Many traditional ABAP statements, function modules, and T-codes used for on-premise development have been replaced by cloud-compliant APIs, classes, or Fiori applications.

• Direct File System Access: Statements like OPEN DATASET, TRANSFER, and CLOSE DATASET that allowed direct access to the application server’s file system are not supported.

• SAP GUI Screen Programming: Features related to traditional SAP GUI screens, including DYNPRO events and classic report programs, are not supported. This includes:

◦ Event Blocks: LOAD-OF-PROGRAM, INITIALIZATION, AT SELECTION-SCREEN, START-OF-SELECTION, and similar event blocks are not allowed because program objects and dynpros are not permitted.

◦ UI Output: The WRITE statement and ALV (ABAP List Viewer) output are replaced by the ADT output console, Fiori apps generated by the ABAP UI service (using the ABAP RESTful Application Programming Model – RAP), or open-source solutions like ABAP2UI5.

• ABAP Memory (Shared Memory): EXPORT … TO MEMORY ID <ID name> and IMPORT … FROM MEMORY ID <ID name> are not supported. Alternatives for in-program memory exchange include EXPORT/IMPORT … TO INTERNAL TABLE / DATA BUFFER.

• Classic Batch Jobs: SM36 and SM37 transactions are deprecated. Application jobs are now managed using new ABAP artifacts like catalogs and templates. Programmatic scheduling is done via cl_apj_rt_api=>schedule_job().

• Application Log: Old T-codes SLG0, SLG1 and related function modules (BAL_LOG_CREATE, BAL_DB_SAVE) are replaced by classes like cl_bali_object_handler, cl_bali_log, cl_bali_log_db and the Fiori app “Application logs”.

• Change Document Logging: Direct table access to CDHDR and CDPOS is replaced by generated classes (e.g., <name space>CL_<change document object name>_CHDO) and cl_chdo_read_tools.

• Debugging: The jdbg command in classic SM37 for background job debugging is not available in the new framework. Similarly, LOG-POINT statements are not allowed in ABAP Cloud. Developers now use ABAP Development Tools (ADT) for debugging, and custom tools like variable-tracking tools have been developed to overcome limitations.

• Data Access and APIs:

◦ Direct access to tables like KNA1, LFA1, MARA, VBAK (Business Partner, Vendor, Material, Sales Order Header) is replaced by CDS views (e.g., i_customer, i_supplier, i_product, i_salesdocument).

◦ Many classic Function Modules (BAPI_MATERIAL_SAVEREPLICA, BAPI_SALESORDER_CREATEFROMDAT2) are deprecated or replaced by Behavior Definitions of RAP Business Objects (e.g., i_producttp_2, i_salesordertp).

◦ Remote Function Calls (RFC) and SOAP services now rely on specific ABAP objects, communication scenarios, and classes for inbound/outbound communication, rather than direct SE37 or SOAMANAGER usage.

• System Fields (sy-): While some sy- fields (like sy-subrc, sy-uname) are still available, others like sy-datum, sy-uzeit, sy-zonlo are replaced by methods from cl_abap_context_info (e.g., get_system_date(), get_system_time(), get_user_time_zone()).

• Syntax for Calculations and Internal Tables:

◦ Arithmetic operations like ADD, SUBTRACT, MULTIPLY, DIVIDE are replaced by modern inline operators (+, –, *, /) and assignment operators (+=, -=, *=, /=).

◦ Counting internal table rows using DESCRIBE TABLE … LINES … is replaced by lines( itab_name ).

◦ Looping with group levels using LOOP AT … AT NEW … ENDAT is replaced by LOOP AT … GROUP BY ….

• Other Replaced Functionalities:

◦ Calendar (Factory/Public holidays): Replaced by CL_FHC_CALENDAR_RUNTIME class and relevant CDS views.

◦ Concurrency Control (Locks): Function modules like ENQUEUE_E_TABLE are replaced by cl_abap_lock_object_factory.

◦ Number Range: SNRO T-code and NUMBER_GET_NEXT function module are replaced by classes cl_numberrange_objects, cl_numberrange_runtime and the “Manage number range intervals” Fiori app.

◦ Parallel Processing: CALL FUNCTION … STARTING NEW TASK is replaced by the cl_abap_parallel class.

◦ Regular Expressions (Regex): Old REPLACE ALL OCCURRENCES OF REGEX syntax is replaced by object-oriented classes like cl_abap_matcher or xco_cp_regular_expression.

◦ Translation: GUI-based translation is replaced by xco_cp_i18n class and the “Maintain translations” Fiori app.

◦ Transport Request Information: Direct table access to E070, E071 is replaced by classes xco_cp_cts, xco_cp_transport.

ABAP Cloud: UI and Development Paradigm Shift

In SAP ABAP Cloud, user interface development has been completely modernized. Traditional technologies like Dynpro and the SAP GUI are no longer supported, making classic reports and selection screens obsolete.

Development is now standardized on Eclipse (using ABAP Development Tools – ADT), and ABAP Cloud leverages modern, web-based solutions for creating user interfaces. ABAP Cloud primarily relies on:

• Fiori applications generated by the ABAP UI service through the ABAP RESTful Application Programming Model (RAP). This approach is metadata-driven, using UI annotations directly in the data model to define the layout, data binding, and behavior of the UI, often without needing additional front-end code unless custom additions are required.

• For more flexible UI development, ABAP2UI5 (an open-source project) allows developers to create Fiori UI5 applications purely with ABAP. This offers capabilities similar to traditional UI development, including selection screens, tables, popups, and support for all Fiori Elements floorplans.

• For simple string output, particularly for developers, the ADT output console replaces the classic WRITE statement and ALV (ABAP List Viewer) output.

In ABAP Cloud, classic event blocks like INITIALIZATION and START-OF-SELECTION are no longer permitted because they are tied to the unsupported Dynpro technology.

This change is part of a broader shift to a restricted ABAP environment. Now, developers must use public APIs and extension points, which decouples custom code from the core system. This modern approach ensures greater stability and makes future upgrades much simpler.

Sources

Smooth transition to ABAP for Cloud Development(Cheat sheet)
ABAP Cloud: Background Concepts and Overview
ABAP Cloud Concepts
ABAP in Cloud-Based SAP Systems

ABAP ABAPCLOUD BTP