Description

Defines a RAP behavior definition in the RAP BDL. A RAP behavior definition consists of a RAP behavior definition header and one or more entity behavior definitions EntityBehaviorDefinition1, EntityBehaviorDefinition2, ... Optionally, one or more RAP authorization contexts AuthorizationContext1, AuthorizationContext2, ... can be specified.

The header can define the following attributes for the entire business object. The implementation type is mandatory, all other attributes are optional.

• managed | unmanaged: Specifies the BDEF implementation type.
• SavingOptions:
• The default save sequence can either be enhanced or switched off and overwritten with a user-defined saving strategy.
• Can be defined either in the BDEF header and then applies to all entities of the business object. It is also possible to define saving options as an entity behavior characteristic.
• If specified, an implementation in the ABAP behavior pool is required.
• Only available for managed implementation scenarios. In unmanaged implementation scenarios, the save sequence is always user-implemented.
• implementation in class ClassName unique: Specifies  one or more classes which allow the behavior implementation of a business object. In a managed scenario, this is optional and required only if unmanaged components are added to the managed implementation.
• strict[(version)]: Switches on BDEF strict mode. Handled by the RAP framework.
• auxiliary class ClassName1[, ClassName2] [, ...]: Specifies one or more additional ABAP classes with enhanced access rights to the referenced RAP BO. The purpose of an ABP auxiliary class is to support the implementation in an ABAP behavior pool.
• extensible: Enables BDEF extensions. If this keyword is not specified, BDEF extensions are not allowed for the respective behavior definition.
• with draft: Enables RAP draft handling. This allows users to save their changes as draft and resume editing at a later point in time. Handled by the RAP framework.
• with privileged mode disabling ContextName: Enables BDEF privileged mode. The effect is that the authorization context ContextName is automatically disabled when a RAP BO consumer accesses the business object in question with a privileged EML call.
• foreign entity: Defines an entity  as RAP foreign entity. This means, an entity which is not part of the BO structure becomes a component for the response structures, thus enabling message mapping for other BOs.

The behavior definition header is followed by

• one or more entity behavior definitions that start with define behavior for
• or by the definition of one or more authorization contexts that start with define [own] authorization context.

Example

The following example shows a managed BDEF based on the CDS root view entity DEMO_RAP_FOREIGN_ENTITY. The BDEF header consists of the following components:

• the implementation type managed
• BDEF strict mode version 2, defined using strict(2)
• a RAP foreign entity, in this case DEMO_SALES_CDS_SO_1

managed implementation in class bp_demo_rap_foreign_entity unique;
strict(2);
//enables MAP_MESSAGES:
foreign entity DEMO_SALES_CDS_SO_1;

define behavior for DEMO_RAP_FOREIGN_ENTITY alias RootEntity
persistent table DEMO_DBTAB_ROOT
lock master
authorization master (global)
{
  create;
  update;
  delete;

  field(readonly:update) key_field;
}