Cloud vs. On-Premise ABAP: Programming Techniques Compared

A technical comparison of the ABAP Cloud development model and classic ABAP development, covering language scope, data access, extensibility, and lifecycle management.

1. Language Scope

ABAP Cloud enforces a restricted syntax subset checked statically by the ABAP compiler and ATC (ABAP Test Cockpit) cloud-readiness checks. Disallowed or restricted constructs include:

• Native SQL (EXEC SQL) and ADBC direct database access
• CLIENT SPECIFIED and explicit client handling in Open SQL
• Direct INSERT/UPDATE/MODIFY/DELETE on database tables outside a RAP transactional buffer
• Classic dynpro statements (CALL SCREEN, MODULE, screen painter artifacts)
• Calls to any class, function module, or table not explicitly released for cloud development
• EXPORT/IMPORT to database (cluster tables), BREAK-POINT, kernel-level statements

Classic ABAP on-premise imposes none of these restrictions. Any released or unreleased SAP object, native SQL, direct table access, and full dynpro/screen programming remain available, subject only to modification-access rules (developer key, SSCR where still applicable).

2. Object Release Contract

Every SAP-delivered API in an ABAP Cloud system carries a release state: Released, Deprecated (with successor), or unreleased/internal. Only released objects are visible and callable from ABAP Cloud code. SAP guarantees backward compatibility for released APIs across upgrades and gives advance notice before deprecation.

On-premise development has no such enforcement layer. Custom code frequently calls internal SAP classes and function modules directly. This is more flexible but carries upgrade risk — SAP makes no compatibility guarantee for non-released objects, and upgrade-time adjustments (SPDD/SPAU-style conflicts, or ATC-flagged breaking changes) are a known cost of this approach.

3. Data Access Layer

Both models use CDS views as the primary data modeling layer, but usage diverges:

4. Business Logic: RAP vs. Classic Frameworks

The RESTful ABAP Programming Model (RAP) is the mandatory business-object framework in ABAP Cloud. A managed RAP business object is defined through:

define behavior for ZI_Order alias Order
persistent table zorder
lock master
authorization master ( instance )
{
  create;
  update;
  delete;
  field ( readonly ) OrderId;
  mapping for zorder corresponding;
}

RAP handles locking, buffering, draft handling, and number ranges through framework-provided determinations, validations, and actions — custom logic hooks into these events rather than owning the persistence lifecycle directly.

On-premise development still commonly uses BOPF, classic function-module-based business logic, or direct dynpro transaction coding with manual COMMIT WORK/ENQUEUE/DEQUEUE handling. RAP is available on-premise too (as of S/4HANA on-premise releases supporting it) but is not mandatory, so codebases mixing RAP, BOPF, and classic Open SQL logic are common.

5. UI Technology

• Cloud ABAP: Fiori Elements generated from RAP-exposed OData V2/V4 services, or freestyle SAPUI5 consuming those services. SAP GUI dynpro UI is not part of the model.
• On-Premise ABAP: SAP GUI Dynpro, Web Dynpro ABAP, classic Fiori (OData V2 without RAP), and RAP-based Fiori all coexist depending on system age and modernization level.

6. Extensibility Model

7. Transport and Lifecycle

Cloud ABAP environments enforce software/application component boundaries — a component can only reference released objects of another component, checked at activation time, not just at transport time. abapGit-based, Git-centric development (gCTS) is the default workflow for BTP ABAP Environment and increasingly for S/4HANA Cloud, enabling CI/CD pipelines built on released ADT/CI APIs.

On-premise systems typically use classic CTS/CTS+ with request-based transport across a landscape (DEV → QAS → PRD). gCTS is available but optional. Cross-client and cross-component coupling is technically unrestricted, which is more flexible but places the burden of dependency discipline on the development team rather than the platform.

8. Testing

ABAP Unit is the standard framework in both models. The practical difference is enforcement: because ABAP Cloud disallows direct database access outside RAP, business logic is naturally isolated behind interfaces, making test doubles (CL_ABAP_TESTDOUBLE, RAP's local test doubles for CDS) close to mandatory for meaningful unit coverage. ATC cloud-readiness checks also gate what can be released for transport.

On-premise code frequently couples business logic directly to database access, so unit tests are more often integration-style (against a real or test database) or skipped entirely for legacy code, since retrofitting test doubles onto tightly coupled logic is more expensive.

9. Background Processing and Output

• Cloud ABAP: Job scheduling through released Job Scheduling APIs; output/forms handled via the cloud Output Management framework and Adobe Forms Cloud service. Direct JOB_OPEN/JOB_SUBMIT/JOB_CLOSE and SAPscript/SmartForms are not available.
• On-Premise ABAP: Full access to classic job control (SUBMIT, background job function modules, SM36/SM37), SAPscript, SmartForms, and Adobe Forms via classic form processing.

10. Summary