ABAP Cloud: RAP Full Model, Managed/Unmanaged, Draft & Side‑by‑Side Extensions – Final Developer Tutorial

 

ABAP in the Cloud – RAP Full Model, Draft & Side‑by‑Side Extensions: The 25,000+ Word Finale

Day 15 of the S/4HANA ABAP Development & Fiori Track – The Grand Finale

By @FreeLearning365 and Tech Partner @techbook24

Introduction: The Cloud Mandate and the ABAP Renaissance

TechBook24 is expanding. The procurement team wants a supplier scorecard that aggregates vendor performance from multiple sources, allows manual evaluations, and provides a collaborative draft process. However, the IT strategy is clear: keep the core clean. Modifying the S/4HANA system with custom tables and apps is discouraged. Instead, the new directive is “side‑by‑side extension” — build cloud‑native applications on SAP Business Technology Platform (BTP) that communicate with S/4HANA via APIs.

Arjun, having mastered CDS, OData, Fiori, and ABAP, is now tasked with learning and applying the ABAP RESTful Application Programming Model (RAP) in the SAP BTP, ABAP Environment. This is the modern, strategic way to develop ABAP‑based services and Fiori apps. In this final part of the Developer Track, you’ll join him in building a complete RAP application for vendor evaluation. You’ll create the business object using CDS views, define its behavior (managed with draft), expose it as an OData v4 service, and deploy it to the Fiori Launchpad. Furthermore, you’ll learn the key differences between managed and unmanaged scenarios, how draft works under the hood, and how to set up a side‑by‑side extension project on BTP. This is the capstone that ties together all the skills you’ve accumulated. Let’s take ABAP to the cloud.

1. The ABAP RESTful Application Programming Model (RAP) – A Paradigm Shift

1.1 From BOPF to RAP

Before RAP, building transactional apps required the Business Object Processing Framework (BOPF) or hand‑coded CRUD. RAP unifies the development experience using CDS views, behavior definitions, and OData v4. It provides a declarative approach: you define the data model and the intent, and the framework generates the runtime. RAP supports both managed and unmanaged modes, draft handling, and extensibility.

1.2 The Layers of a RAP Business Object

• CDS View (Data Model): The root entity and its children define the structure. They are annotated with @ObjectModel and @Semantics for RAP behavior.
• Behavior Definition: A separate artifact that specifies which operations are allowed (create, update, delete), which fields are read‑only, mandatory, or draft‑enabled, and whether the implementation is managed or unmanaged.
• Behavior Implementation: For unmanaged scenarios, an ABAP class that implements the actual CRUD logic. For managed, the framework handles it, but you can add custom validations and actions.
• Service Definition: Selects which entities and operations to expose as OData.
• Service Binding: Creates the actual OData v4 service with a protocol binding.

Arjun will build a vendor evaluation business object using the managed approach with draft, because the framework should handle standard CRUD and draft states automatically.

2. The TechBook24 Vendor Evaluation App – Requirements

The procurement team needs a simple app to track supplier performance. The data model:

• Vendor Evaluation (root): Vendor ID (LIFNR), evaluation date, overall score (1‑5), comment, status (Draft, Submitted, Approved).
• No child entities for simplicity, but Arjun will show how to add a child (evaluation items) later.

The app must support:

• Create, read, update, delete evaluations.
• Draft capability: users can start an evaluation, save as draft, come back later, and submit.
• Validation: score must be between 1 and 5; vendor must exist in the S/4HANA system (via an API call in the BTP side‑by‑side scenario).
• Side‑by‑side: the app runs on SAP BTP, ABAP Environment, not on the core S/4HANA. It fetches vendor master data via a remote OData call to the S/4HANA system (embedded scenario will also be shown but focus on side‑by‑side).

3. Setting Up the SAP BTP, ABAP Environment (For Side‑by‑Side)

3.1 Creating an ABAP Instance in SAP BTP

Arjun (or the Basis team) provisions an ABAP Environment service instance on BTP. He opens the SAP BTP cockpit, navigates to “Instances and Subscriptions”, creates an “ABAP System” instance (or uses a pre‑configured one). He gets the dashboard URL and creates a developer user with the role SAP_A4C_BC_DEV_USER. He then uses ADT (Eclipse) to connect to this ABAP system in the cloud.

Screenshot Description: ADT project wizard with connection to the ABAP environment on BTP.

3.2 Creating a Cloud Communication Setup

To call the S/4HANA system for vendor validation, Arjun sets up a communication arrangement. He defines a destination in the ABAP Environment dashboard (via SAP Fiori) pointing to the S/4HANA OData service (I_BusinessPartner). He creates an HTTP service and generates an inbound communication. Then in ADT, he references the destination in the behavior implementation.

For the side‑by‑side evaluation app, the business object is created in the BTP ABAP system, while the remote call fetches vendor details. This demonstrates the clean core principle.

4. Building the Vendor Evaluation RAP Business Object (Managed with Draft)

4.1 Creating the Root CDS View

In ADT (connected to BTP ABAP), Arjun creates a new ABAP package ZVENDEVAL. He creates the root CDS view ZR_VENDOR_EVAL:

@AbapCatalog.sqlViewName: 'ZRVENDEVAL'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Vendor Evaluation Root'
@ObjectModel: {
  representativeKey: 'VendorEvalUUID',
  transactionalProcessingEnabled: true,
  draftEnabled: true,
  compositionRoot: true
}
define root view entity ZR_VENDOR_EVAL
  as select from zvend_eval_draft "will be generated, but initial creation uses a special syntax or we define the table in the behavior
{
  key vendor_eval_uuid : raw(16),
      lifnr            : lifnr,
      eval_date        : datum,
      overall_score    : abap.int1,
      comment          : string(256),
      status           : abap.char(2), " 01=Draft, 02=Submitted, 03=Approved
      created_by       : syuname,
      created_at       : timestampl,
      last_changed_by  : syuname,
      last_changed_at  : timestampl,
      draft_entity_creation : abap_boolean,
      is_draft             : abap_boolean
}

The annotations are critical: @ObjectModel.draftEnabled: true, compositionRoot, and representativeKey. For managed, the framework expects certain draft fields (like draftentitycreation, is_draft) but they are automatically managed. He uses raw(16) as the UUID key, a common pattern.

He activates the CDS view. The system might request a draft table; he follows the quick fix to generate the draft table.

4.2 Creating the Behavior Definition

Right‑click the root CDS view → New → Behavior Definition. He chooses “Managed” scenario and “Draft enabled”. The wizard generates:

managed implementation in class zcl_vendor_eval unique;
strict ( 2 );

define behavior for ZR_VENDOR_EVAL alias VendorEval
persistent table zvend_eval
draft table zvend_eval_d
with draft;

field ( mandatory ) lifnr, overall_score;
field ( read only ) vendor_eval_uuid, created_by, created_at, last_changed_by, last_changed_at;
field ( readonly : update ) vendor_eval_uuid; // key cannot be changed

determination setStatus on modify { create; }
validation validateScore on save { create; update; }

action submit external name 'Submit';
action approve external name 'Approve';

He then creates a class ZCL_VENDOR_EVAL and adds methods for determination and validation. For the managed scenario, he only needs to implement the custom logic; the framework handles CRUD operations on the persistent table ZVENDEVAL.

Determination setStatus: sets the status to ’01’ (Draft) on create. He writes:

MODIFY ENTITIES OF ZR_VENDOR_EVAL IN LOCAL MODE
  ENTITY VendorEval
  UPDATE FIELDS ( status )
  WITH VALUE #( FOR key IN keys ( %tky = key-%tky status = '01' ) )
  REPORTED DATA(reported).

Validation validateScore: reads the entity’s overall_score and checks it is between 1 and 5. If not, he adds a message to the reported structure.

4.3 Implementing the Submit and Approve Actions

For submit, he changes status from ’01’ to ’02’. For approve, from ’02’ to ’03’. He implements the action methods. He also adds an authorization check or remote validation call to S/4HANA to verify the vendor exists. In the validateScore method, he can call a remote service using a client proxy generated from the S/4HANA OData service, but that’s advanced. He shows how to import the service consumption model in ADT and call it inside the validation. We’ll detail that in the side‑by‑side section.

4.4 Enabling Draft – The Underlying Mechanics

When draft is enabled, the framework creates an additional table (draft table) that holds temporary data until the user saves or submits. The draft table has the same structure plus draft‑specific administrative fields. The end user sees a “Save as Draft” button; the data stays in the draft table. Upon explicit “Submit”, the draft is converted to an active record. Arjun explains the draft lifecycle and how to handle draft‑specific logic (using %is_draft indicator). He also demonstrates how the OData service automatically provides the draft actions.

5. Creating the Service Definition and Binding

5.1 Service Definition

Right‑click the root CDS view → New → Service Definition. He selects the entity ZR_VENDOR_EVAL and the actions he wants to expose. The definition:

define service Z_SRV_VENDOR_EVAL {
  expose ZR_VENDOR_EVAL as VendorEvaluation;
}

5.2 Service Binding

Right‑click the service definition → New → Service Binding. He chooses “OData V4 – UI” as the binding type. He activates the binding. The system generates the OData v4 service URL. He opens the service in the “Service Binding” editor, clicks “Preview” to see the OData metadata and test CRUD. He creates a new evaluation via the test UI; the draft is automatically handled. He sees the status ’01’ and can submit.

Screenshot Description: Service binding editor with the generated OData URL and the entity list.

6. Publishing to the Fiori Launchpad (Cloud)

In the BTP ABAP Environment, a Fiori Launchpad is available. Arjun uses the “Maintain Business Catalogs” and “Maintain Business Roles” apps (via the Fiori Launchpad designer) to add his service as a tile. He creates a catalog, assigns the service (using the service binding name), and creates a role that includes the catalog. He then assigns the role to his user. The Fiori Launchpad now shows the “Vendor Evaluation” app. He opens it, creates a draft, submits, and views the list. This is the same experience as Part 39 but with a cloud‑native RAP app.

7. Side‑by‑Side Integration – Calling the S/4HANA API from the BTP RAP App

7.1 The Remote Validation Requirement

In the evaluation creation, the vendor number must be validated against the S/4HANA business partner master data. Arjun creates a “Service Consumption Model” (SRVC) in ADT by importing the EDMX of the S/4HANA OData service I_BusinessPartner. He then generates a client proxy class.

In the validation method validateScore, he calls:

DATA(lo_client) = cl_web_odata_client_factory=>create_by_http_destination( iv_http_destination = 'Z_S4H_DEST' ).
lo_client->set_entity_set( 'A_BusinessPartner' )->get_entity( ... )...

He checks if the vendor exists; if not, he reports an error. This is a true side‑by‑side extension: clean core, cloud logic.

7.2 Handling Errors and Asynchrony

He ensures the remote call is wrapped in a try/catch; network issues are reported as messages. He also suggests using a background job for eventual consistency if the remote call is not critical.

8. Managed vs Unmanaged – A Realistic Comparison

Arjun explains that the vendor evaluation app is perfect for managed with draft because the framework handles persistence. But suppose TechBook24 wants to store evaluations in a custom legacy database table with complex logic. Then they would use unmanaged: they must implement the full CRUD in the behavior class (methods like create, update, delete). He shows a quick unmanaged behavior definition:

unmanaged;
define behavior for ZR_VENDOR_EVAL alias VendorEval
implementation in class zcl_vendor_eval_unm unique
persistent table zveneval_legacy
{
  create;
  update;
  delete;
  field ( mandatory ) lifnr;
}

He contrasts the effort: unmanaged gives full control but requires writing all CRUD, which is more work. Draft is not automatically handled in unmanaged unless you implement the draft interface.

Scenario	Managed	Unmanaged
CRUD logic	Framework generates	Developer writes all
Draft support	Declarative	Manual implementation
Complex validations / actions	Custom methods	Custom methods
Use when	Standard data storage, clean business objects	Legacy tables, complex non‑standard logic, migration projects

9. The Complete Hands‑On Lab – Building the Vendor Evaluation RAP App

1. Prerequisites: Access to SAP BTP, ABAP Environment or an S/4HANA system with embedded RAP (for practice). Arjun uses the BTP system.
2. Create ABAP package ZVENDEVAL in ADT.
3. Create root CDS view ZR_VENDOR_EVAL with the structure and annotations above. Activate; let the system generate the draft table.
4. Create behavior definition (managed, draft enabled). Implement the class ZCL_VENDOR_EVAL with determination and validation methods as described.
5. Create service definition Z_SRV_VENDOR_EVAL exposing the entity.
6. Create service binding (OData v4 UI). Test with preview.
7. Create a Fiori Launchpad tile using the “Maintain Business Catalogs” app (or within ADT using the Fiori elements wizard to generate a UI – but for RAP, the service binding preview already provides a generic Fiori elements app).
8. Integrate remote validation: create communication scenario and destination, implement the client proxy call in the validation method.
9. Test the full flow: create draft, validate score, submit, approve. Verify that invalid vendor triggers error.
10. Demonstrate unmanaged variant (optional quick lab).

10. Testing and Debugging RAP – ADT Tools

• Behavior Debugging: Set breakpoints in the behavior implementation class methods. Use the OData preview to trigger operations. The debugger stops within the managed runtime.
• Draft Analysis: Use CL_RAP_DRAFT_ADMIN APIs or the draft administration Fiori app to view draft states.
• OData Trace: In the service binding, enable trace and examine the request/response.

11. Best Practices and Pitfalls in RAP Development

• Always define a representative key for the business object; it improves API consumption.
• Use managed whenever possible – it reduces boilerplate and ensures standard patterns.
• Draft adds complexity; if the business process does not require draft (e.g., simple master data), skip it.
• Be careful with the draft table name – it’s automatically generated; don’t modify it manually.
• In side‑by‑side, mind latency – remote calls inside validations can slow down the UI. Use asynchronous if needed.
• Transport managed RAP objects together – CDS, behavior definition, class, service definition, and binding must be in the same transport.

12. The Future of ABAP – Your Cloud‑Native Journey

With this final part, Arjun has completed his transformation from a traditional ABAP programmer to a full‑stack cloud developer. The RAP model, combined with CDS, OData, and Fiori Elements, empowers you to build enterprise‑grade, transactional applications that run on any ABAP platform — on‑premise, private cloud, or BTP. SAP’s clean core strategy relies on developers like you to create extensions that don’t disrupt the standard. The skills you’ve built across these 45 parts are exactly what the market demands.

Thank you for completing the S/4HANA Deep Dive: ABAP Development & Fiori Track. The functional track, the technical architecture, and now the cloud track — you’re ready to design, develop, and integrate SAP solutions end‑to‑end. Keep learning, keep building, and never stop pushing the boundaries of what ABAP can do.

End of Part 45 – ABAP Cloud & RAP Finale. Brought to you by @FreeLearning365 and tech partner @techbook24.