RAP in SAP ABAP: Build a Modern Fiori App with CDS, Behavior Definitions and OData

Why this matters now

A RAP application needs a business model and enforceable rules before it needs a polished screen. This guide uses a fictional training-request application to connect CDS modelling, behaviour, service exposure and Fiori consumption. The aim is to understand which layer owns each responsibility and how to prove that the application behaves correctly, including when a user supplies invalid input.

Keep a simple drawing of the request’s data, allowed state changes and users. Revisit that drawing whenever you add a CDS entity, behaviour rule or exposed operation. It helps prevent a working screen from drifting away from the original business requirement.

Core concepts to learn

Build a practice scenario

1. Step 1: Name the request owner and the users who may change its status.
2. Step 2: Sketch the fields, identity and permitted state changes.
3. Step 3: Write one accepted and one rejected input before building the model.
4. Step 4: Confirm which RAP scenario the training backend supports.

Use sample, authorised or fictional data. Do not publish credentials, business data, account numbers or customer information in a portfolio. If a task has financial, security or production impact, include a review or approval step before any change.

What good work looks like

Choose one business object before generating an app

For a first RAP exercise, model a fictional training request. A requester enters a course code, requested date and number of seats. The request begins as open and can later be submitted according to a defined rule. Keep the first version small: one root entity, a few fields and one custom action. Do not start by reproducing an entire purchasing application.

Write the rules in plain language. The number of seats must be greater than zero. A course code must be supplied. A submitted request cannot be submitted again. Decide which user may edit or submit it, and what should happen if two users work on the same request. These decisions guide the data model and behaviour; a generated page cannot decide them for you.

Understand the layers from data to service

SAP’s RAP learning material describes a data model built with CDS, a business object with defined behaviour and a service-exposure layer. Each layer answers a different question. The data model describes the request and its relationships. The behaviour describes allowed operations and business rules. The service determines what an external consumer can access.

A service definition and service binding are not interchangeable. SAP describes the binding as the connection between the service definition and a communication protocol. Check the binding types supported by your backend. An OData service intended for a user interface and a service intended for an external API may have different consumption requirements.

Build a managed learning example in small stages

1. Prepare the environment. Confirm your authorised development package, backend release and supported RAP learning example. Use the naming convention required by your training system.
2. Create the data model. Define request identity and the small set of business fields. Add meaningful labels. Activate dependencies in a clear order and inspect errors at the object that causes them.
3. Define behaviour. For a supported managed scenario, let the framework handle its standard persistence responsibilities. Implement the business rules your scenario needs rather than assuming generated create and update operations are complete application logic.
4. Expose the projection. Include only the fields and operations needed by the request application. Check that an intended operation is exposed at the relevant projection layer.
5. Create the service and inspect the preview. Use the supported binding workflow. Verify the displayed fields and available actions, then test persistence and business behaviour separately.

The first milestone should be a valid request that can be created, read back and changed within the allowed rules. Only then add an action or another entity. This makes it easier to locate a defect than creating every repository object and troubleshooting the complete stack at once.

Separate validation, determination and action

A validation checks whether a business-object state is consistent. A determination changes values when its configured trigger occurs. An action represents an operation exposed by the business object. For the fictional request, rejecting zero seats is a validation concern; supplying an initial status may be a determination concern; submitting the request can be a custom action.

SAP documents validations as part of the behaviour definition and implementation, with support depending on the scenario. Follow the documentation for the release and implementation type you use. Return meaningful messages that identify the problem and, where appropriate, the affected field. A generic “save failed” message makes an otherwise correct rule difficult to use.

Do not use a hidden button as the only enforcement of a rule. The backend must protect the operation when called through the service or another permitted consumer. Similarly, changing a label in the preview does not implement an authorisation check.

Test beyond the first successful save

Keep a compact test log with the request data, user, action, expected outcome and actual result. Include a valid request, missing course code, zero seats, a repeated submission and an unauthorised operation. After a rejected save, read the object again to confirm that invalid values did not become active data.

Concurrency deserves its own exercise. Open the same request in two permitted sessions, change it in one, then attempt the second change. SAP’s RAP documentation covers locking and ETag-based concurrency mechanisms. Use the mechanism appropriate to the scenario and verify its behaviour instead of assuming the last save should silently win.

If you add draft handling, test saving unfinished work, resuming it, activating it and discarding it. Draft data and active business data represent different states. Record which state you inspected when investigating an apparent missing update.

Common RAP learning questions

Why is the Create button missing?

Check whether creation is defined and exposed for the relevant entity, then inspect the binding, service metadata and applicable feature or authorisation controls. Do not begin by changing unrelated UI annotations.

Does a working preview mean the app is ready?

No. A preview helps inspect consumption, but it does not prove role assignment, navigation, error handling, lifecycle delivery or business acceptance. Keep those checks in the project’s completion criteria.

Should beginners use managed or unmanaged RAP?

A small supported managed example is often easier for learning because standard responsibilities are supplied by the framework. Existing application logic may require another approach. Choose according to the requirement and supported backend, not because one tutorial labels an option more advanced.

Official SAP references

• Building an ABAP RESTful application
• Implementing input checks using validations
• Understanding RAP concurrency control
• Understanding the RAP draft concept

Frequently asked question

What should a beginner practise after learning ABAP RAP tutorial?

Build one small, documented exercise that uses the concepts safely, validate the result, and explain the decisions and limitations. Repeating this cycle makes learning more reliable than collecting disconnected tutorials.