Get Example source ABAP code based on a different SAP table
• FIELD ABAP_BDL_PROJECTION • READONLY ABAP_BDL_PROJECTION , FIELD • FEATURES INSTANCE ABAP_BDL_PROJECTION , FIELD • MANDATORY CREATE ABAP_BDL_PROJECTION , FIELD • READONLY UPDATE ABAP_BDL_PROJECTION , FIELD • SUPPRESS ABAP_BDL_PROJECTION , FIELD
ABAP_RAP - Field Characteristics, Projection BDEF
ABAP_SYNTAX_FORMS
Field Characteristics That Can Be Added for Regular Fields ... field(readonly) Field1, Field2, ...; $| field(mandatory:create) Field1, Field2, ...; $| field(readonly:update) Field1, Field2, ...; $| field(suppress) Field1, Field2, ...;>
Field Characteristics That Can Be Added for Virtual Fields ... field(modify$[,FieldChar$])VirtualField1, VirtualField2, ...; >
What does it do? A projection BDEF> automatically and implicitly inherits all field characteristics> of its underlying projected BDEF. Field characteristics that do not require an implementation in the ABAP behavior pool> can be added in the projection layer under the condition that the base BDEF hasn't already specified any field characteristics for the respective field. Field characteristics that require an implementation (currently, this is the case only for features:instance>) cannot be added for regular fields in the projection layer, but for augmented virtual elements>. Read the sections below for further details.
Latest notes:
Managed internal numbering, specified using the keyword numbering:managed>>, is inherited and it cannot be newly defined in a projection BDEF.
In UI scenarios, field characteristics are displayed as RAP consumer hint>. NON_V5_HINTS ABAP_HINT_END
ABAP Alternative 1 field(FieldChar) Field1, Field2, ...>
What does it do? The following field characteristics can be newly added in a projection BDEF:
readonly>
mandatory:create>
readonly:update>
suppress> Topic RAP BDL - field characteristics> describes how they work. If there is already field control defined in the underlying base BDEF, the projection BDEF cannot define other field characteristics for the same field(s). Any such attempt leads to a syntax check error. In a managed or unmanaged RAP BO, multiple field characteristics can be combined. In a projection BDEF, there is only one valid combination: mandatory:create, readonly:update>. Commas can be used to classify multiple fields in the same way. Example: field(readonly) Field1, Field2, Field3;>.
ABAP_EXAMPLE_VX5 The following example demonstrates inheritance. The projection BDEF inherits managed internal numbering from its projected BDEF and therefore, the primary key field KEY_FIELD> is automatically assigned a value. ABAP_NOTE This example does not fully meet the requirements of the RAP BO contract>. It is intentionally kept short and simple and serves demonstration purposes only. See more information on the RAP BO contract in the Development guide for the ABAP RESTful Application Programming Model>. BDEF DEMO_RAP_PROJECTION_NUMBERING The ABAP class CL_DEMO_RAP_PROJECTION_NMBRNG>> uses EML > to access to RAP business object> and performs the following steps:
It creates three entity instances by specifying a value for the 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. It can be seen that the primary key field KEY_FIELD > of each entity instance contains a value, which was generated by means of managed early numbering>. Code Snippet: ABEXA 01552 Result: values for the primary key field are generated automatically. IMAGE ABDOC_INTERNAL_NUMB.png 358 106 ABAP_EXAMPLE_END
ABAP Alternative 2 field(modify$[,FieldChar$]) Virt1, ...>
What does it do? CDS projection views> may contain CDS virtual elements> (defined using the keyword VIRTUAL> >) , fields defined by association traversal > (path expressions), or localized fields> (defined using the keyword LOCALIZED>). Such fields are automatically and implicitly set to read-only. They are excluded from the BDEF derived types> and a RAP BO consumer cannot update those fields. A way to enable those field for transactional processing is by using the operation augment>. The following syntax can be used to augment a field and thus include it in transactional handling: field(modify$[, FieldChar$]) VirtualField;> An augment-enabled virtual field can be controlled with the following field characteristics FieldChar>:
mandatory>
readonly>
mandatory:create>
readonly:update>
features:instance>
A prerequisite for using features:instance> on a virtual field is that BDEF strict mode> is enabled.
An implementation in the RAP handler method> FOR INSTANCE FEATURES>> in the ABAP behavior pool of the projection layer is required. For further details on the operation augment, see topic RAP BDL - augment, projection BDEF>.