C1 Contract Rules for Providing RAP Behavior Definitions

ABAP - Keyword Documentation → ABAP - Rules for ABAP Cloud → Contract Rules for ABAP Released APIs → C1 Contract Rules → C1 Contract Rules for API Providers →

Mail Feedback

RAP projection behavior definitions, RAP interface behavior definitions, and RAP abstract behavior definitions can be classified with the C1 contract. No other BDEF implementation type can be classified with the C1 contract. The following sections list the most important C1 contract rules.

Prerequisites for a C1 Release
Stability Rules After Release

Prerequisites for a C1 Release

A provider of RAP behavior definitions must obey the following rules:

The BDEF to be released must not have any syntax errors.
A projection behavior definition must have the ABAP language version Standard ABAP as a prerequisite for C1 release. Projection behavior definitions with the ABAP language version ABAP for Cloud Development cannot be C1 released.
The most recent version of BDEF strict mode must be used.
Abstract behavior definitions must specify with hierarchy in the behavior definition header and with control in the entity behavior definition.
For projection behavior definitions and interface behavior definitions, all authorization objects that are listed in the full authorization context must be classified with the C1 contract as a prerequisite for C1 release of the BDEF. For interface BDEFs, the authorization objects from the underlying base BDEF are considered.
All underlying CDS entities, RAP foreign entities, and entities used as association targets must be C1 released.
The underlying CDS entity must not contain any CDS virtual elements, path expressions, or CDS localized fields specified using the addition LOCALIZED.
RAP create operations are allowed for the root node only.
All key fields must be defined as readonly or readonly:update.
Projection BDEFs must not contain any RAP type mapping.
Input parameters and output parameters of actions and functions must be CDS entities or BDEFs that are C1 released. The output parameter of an action or a function must not be a CDS custom entity.
In interface BDEFs, RAP business events are allowed for the root node only. The CDS abstract entity or abstract behavior definition specified as output parameter must be C1 released.

Stability Rules After Release

The BDEF must not be removed and the release contract must not be removed.
The alias name and the external name, if specified, must not be changed.
The RAP draft handling must remain stable. This means that RAP draft handling must not be added or removed after C1 release.
use side effects must not be removed.
use etag must not be removed.
with hierarchy must not be removed.
with privileged mode must not be removed.
RAP late numbering must not be added or removed.
RAP BO standard operations must not be removed or defined as internal.
The addition with control must not be removed.
Scalar entities must not be added or removed.
RAP field characteristics must not be added, removed, or changed with the following exception: changing the field attribute readonly to readonly:update is allowed.
Associations must remain stable in the following ways:
- They must not be removed.
- If the create-by-association operation is enabled, it must not be removed.
- If an abbreviation is specified, it must not be changed or removed.
- If an association is draft-enabled, the addition with draft must not be removed.
- If the addition with hierarchy is specified, it must not be removed.
- mandatory:execute must not be added or removed.
RAP actions, RAP functions, RAP BO determine actions, and RAP BO draft actions must remain stable. In particular, their names, external names, input and output parameters, and additions must not be changed or removed. They must not be declared as internal.
RAP business events must remain stable. In particular, a RAP business event must not be removed, its name must not be changed, and the output parameter must not be changed.
In abstract BDEFs, RAP type mappings must not be removed.
RAP foreign entities must not be removed and their alias name must not be changed.