Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  ABAP RESTful Programming Model →  Behavior Definitions →  ABAP BDL 

ABAP BDL - IMPLEMENTATION

Other versions: 7.31 | 7.40 | 7.54

Syntax


implementation unmanaged|managed|abstract [in class class_name unique];

Effect

The implementation type of the business object behavior is introduced in the behavior definition using the keyword implementation.

Implementation types can be split into the following categories:

  • unmanaged
    In the case of the implementation type unmanaged, all important components of the REST contract must be implemented first. All required operations (the standard operations create, update, and delete plus any application-specific actions) must be defined in the relevant behavior definition before being implemented in ABAP. This implementation type is best used when using existing legacy business logic for behavior implementation.
  • managed
    The implementation type managed is best used when implementing completely new business logic. In this case, a behavior definition is sufficient to obtain a ready-to-run business object.
  • abstract
    A behavior definition with the implementation type abstract cannot be implemented using behavior pools and is used as a metadata-only artifact in the representation of external services instead.

A behavior definition can specify one or more classes which allow the behavior implementation of a business object. This can be done by using the addition in class ... unique in the behavior definition of the business object.

Effect of in class ... unique:

  • A behavior for the entity in question can only be implemented in a behavior pool with the specified name. Any other class that attempts this raises an ABAP Compiler error.
  • If the addition in class ... unique is specified, an operation must not be implemented multiple times in different handler classes.


Example

In the following example, the data from the ABAP flight data reference scenario (or flight data scenario for short) is used. It represents a legacy business logic that can be used to create and edit flight bookings. The CDS view /DMO/I_Travel represents the root node of the business object for managing flight trips. The underlying business model is described in ABAP BDL - Example.

The following example shows the behavior definition for the root entity Travel. In the example, the implementation type is set to unmanaged because the existing legacy business logic needs to be integrated into the new application for managing flight trips.

implementation unmanaged;
define behavior for /DMO/I_Travel alias Travel
{
  create;
  update;
  delete;
}