RAP is a model, behavior, and service—not one code file

A purchase-request API needs a data shape, business operations, and a way for clients to reach them. RAP organizes those responsibilities into repository artifacts that work together.

Follow the request

  1. A persistence table (or supported persistence model) stores active business data.
  2. CDS entities describe the business object and its relationships.
  3. A behavior definition declares transactional operations and rules; behavior implementation adds custom logic where needed.
  4. An optional projection tailors the BO for one consumer.
  5. A service definition exposes selected entities; a service binding chooses a protocol and publishes the service.

Managed RAP provides much of the standard CRUD transaction handling. Unmanaged RAP requires developers to supply more of that behavior. EML, covered in the previous unit, is the ABAP interface for a consumer inside AS ABAP; an OData service has its own runtime entry point.

These are architectural roles, not a mandatory artifact list for every BO. Keep the model small and use only layers needed by the consumer. SAP’s syntax samples are intentionally simplified, not complete application designs.

Sources

Developer practice · ABAP

Practice: order RAP artifacts in a data flow

Put the fictional artifacts in the order data is modeled, behavior is defined, and an API is exposed.

Choose your ABAP environment

This choice changes the output pattern checked here: WRITE belongs in a classic executable report, while out->write( ) uses the supplied output reference in an ABAP Cloud class-run method. It does not switch the language version of the other code; check release and API availability in your target system.

Complete the task and include the output statement shown for your selected environment. Variable names can differ if you use them consistently. This browser checker checks structure only; it does not compile or run ABAP.

0 required structures detected · 0 checks