Get Example source ABAP code based on a different SAP table
• READONLY ABAP_BDL_BODY , FIELD • FIELD FEATURES INSTANCE ABAP_BDL_BODY , FIELD • MANDATORY CREATE ABAP_BDL_BODY , FIELD • READONLY UPDATE ABAP_BDL_BODY , FIELD • MANDATORY ABAP_BDL_BODY , FIELD • FIELD ABAP_BDL_BODY , CHARACTERISTICS • SUPPRESS ABAP_BDL_BODY , FIELD BEGIN_SECTION VERSION 5 OUT • NOTRIGGER WARN ABAP_BDL_BODY , FIELD END_SECTION VERSION 5 OUT
What does it do? This topic lists RAP field characteristics for the fields of a RAP BO entity. Commas can be used to classify multiple fields in the same way. Example: field(readonly) Field1, Field2, Field3; A field can have multiple characteristics, divided by commas within the brackets. Example: field(mandatory:create, readonly:update) Field1, Field2, Field3; . Certain restrictions apply on the combination of field characteristics. They are indicated by a syntax check warning.
ABAP_AVAILABILITY
Managed RAP BOs
Unmanaged RAP BOs
In case of projection BOs, automatic inheritance takes place. To newly define field characteristics in a projection BO, special rules apply. See topic TITLE .
For abstract BDEFs , special rules apply. See topic TITLE .
For interface BDEFs, automatic inheritance takes place. The interface can add further field characteristics, as long as they do not contradict the field characteristics from the base layer. This is described in topic Field Characteristics, Interface BDEF. ABAP_AVAILABILITY_END
ABAP_FURTHER_INFO
Development guide for the ABAP RESTful Application Programming Model, section Feature Control Definition: Fields
Latest notes:
In UI scenarios, field characteristics are displayed as a RAP consumer hint.
All primary key fields must be defined as readonly or as readonly:update. Otherwise, a syntax check warning occurs. NON_V5_HINTS ABAP_HINT_END
Defines that it is mandatory to enter values into the specified fields before persisting them on the database. These fields are marked as mandatory on the user interface in an OData scenario. However, there is no runtime check for mandatory fields and no runtime error occurs if a mandatory field is not filled. If a runtime check is required, the application developer should implement it using a validation on save.
Static field attribute.
No implementation in the ABAP behavior pool required.
ABAP_EXAMPLE_VX5 The following example shows a managed BDEF that defines the field char_field1 as mandatory. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. It does not fully meet the requirements of the RAP BO contract. See more information on the RAP BO contract in the Development guide for the ABAP RESTful Application Programming Model. BDEF DEMO_RAP_FIELD_MANDATORY The ABAP class CL_DEMO_RAP_MANAGED_MANDATORY uses EML to access to RAP business object. It creates three entity instances by specifying a value for the primary key field key_field. No value is entered for the mandatory field char_field1. It commits the three new entity instances to the database. Using the AB_SQL SELECT statement, it displays the content of the underlying database table. Code Snippet: ABEXA 01529 Result: The mandatory field char_field1 contains the initial value, no syntax check warning or syntax check error occurs. IMAGE ABDOC_MANDATORY.png 353 104 ABAP_EXAMPLE_END
Field(suppress) can be used to remove a field from the BDEF derived types, OData, and all RAP APIs. This is possible for all fields except for key fields, foreign key fields, and fields used by the current BDEF, such as ETag fields.
Currency key fields of data type CUKY can be suppressed only if all amount fields that make a reference to this particular CUKY field are also suppressed.
Static field attribute.
No implementation in the ABAP behavior pool required.
If a RAP BO consumer tries to modify a suppressed field, an error message occurs that tells the consumer that no field of this name exists.
ABAP_EXAMPLE_VX5 The following example shows an interface BDEF that suppresses the field DataFieldRoot. BDEF DEMO_RAP_INTERFACE_DRAFT The ABAP class CL_DEMO_RAP_INTERFACE_DRAFT creates a variable typed with the BDEF derived type of the RAP BO DEMO_RAP_INTERFACE_DRAFT and displays the structure of this variable. Code Snippet: ABEXA 01654 Result: The suppressed field DataFieldRoot is not part of structure. IMAGE field_suppress.png 375 268 ABAP_EXAMPLE_END
Dynamic field attribute that defines access restrictions for fields depending on the state of the BO entity instance.
Must be implemented in the ABAP behavior pool in the RAP handler method FOR INSTANCE FEATURES. In the ABAP behavior pool, it can be specified that a field is dynamically mandatory, read-only, has no restrictions, or that it is mandatory and read-only.
If a RAP BO consumer tries to breach the dynamic access restrictions, it is ignored. There is no error or warning message. In a managed RAP BO, there is also no entry in the response structures. In an unmanaged RAP BO, the reported structure can be filled, depending on the BO implementation.
ABAP_EXAMPLE_VX5 The following example shows a managed BDEF that defines dynamic feature control for field int_field2. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. It does not fully meet the requirements of the RAP BO contract. See more information on the RAP BO contract in the Development guide for the ABAP RESTful Application Programming Model. BDEF DEMO_RAP_INSTANCE_FEATURES In the ABAP behavior pool, it specifies the following condition: if field int_field1 contains the value '1', then int_field2 is read-only. Code snippet: ... %field-int_field2 = COND #( WHEN ls_variable-int_field1 = '1' THEN if_abap_behv=>fc-f-read_only ELSE if_abap_behv=>fc-f-unrestricted ) ) ). The ABAP class CL_DEMO_RAP_INSTANCE_FEATURES uses EML to access to RAP business object.
First, it inserts an entity instance directly onto the database using AB_SQL INSERT. This entity instance has the value '1' for field int_field1. Therefore, it fulfills the condition that triggers feature control: if this instance is updated, field int_field2 should be read-only.
An EML UPDATE operation is executed on the same instance. This update operation tries to enter a value into field int_field2.
The updated entity instance is committed to the database. Using the AB_SQL SELECT statement, the content of the underlying database table is displayed. Result: The update operation is prevented by the dynamic feature control. Field int_field2 contains the initial value. No syntax check warning or syntax check error occurs. IMAGE ABDOC_INSTANCE_FEATURES.png 415 64 ABAP_EXAMPLE_END
Dynamic field attribute that defines that it is mandatory to enter a value when an instance is created.
No implementation in the ABAP behavior pool required.
If a RAP BO consumer tries to create a new entity instance without entering a value into the field defined as mandatory:create, a runtime error occurs.
Latest notes: A typical use case is to combine mandatory:create with readonly:update for key fields (external numbering by RAP BO consumer). NON_V5_HINTS ABAP_HINT_END
Dynamic field attribute that defines a field as read-only during update operations, that means, the field in question cannot be changed anymore after the create operation.
No implementation in the ABAP behavior pool required.
If a RAP BO consumer tries to update a field defined as readonly:update, a syntax check error occurs. BEGIN_SECTION VERSION 5 OUT
Defines that the field in question must not be used as the trigger condition of a RAP determination or a RAP validation.
Available in RAP behavior definitions of type managed and unmanaged.
If a field defined as field(notrigger) is used in a trigger condition, a syntax check error occurs.
If the optional addition warn is used, a syntax check warning occurs. This addition can be used, for example, if the field restriction is added at a later point in time when the field in question has potentially already been used in a trigger condition. In this scenario, the addition warn prevents an incompatible change.
This field characteristic can be useful, for example, in RAP extensibility scenarios. The original RAP BO can exclude certain fields from usage in trigger conditions and this applies to all RAP BO extensions.
Static field attribute.
No implementation in the ABAP behavior pool required.
Example ABAP Coding
The following managed BDEF excludes two fields from being used as a trigger condition in a RAP determination or a RAP validation. The fields are administrative fields that are updated automatically by the RAP transactional engine and therefore, they are not suitable as trigger conditions. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. The RAP handler methods in the ABAP behavior pool are not implemented here. BDEF DEMO_RAP_NOTRIGGER ABAP_EXAMPLE_END END_SECTION VERSION 5 OUT
