Kontakt

Ansicht
Dokumentation

ABENBDL_FIELD - BDL FIELD

ABENBDL_FIELD - BDL FIELD

CPI1466 during Backup   General Data in Customer Master  
This documentation is copyright by SAP AG.
SAP E-Book

- field characteristics

... field(readonly) Field1, Field2, ...;
       $| (mandatory) Field1, Field2, ...;
       $| (features:instance) Field1, Field2, ...;
       $| (mandatory:create) Field1, Field2, ...;
       $| (readonly:update) Field1, Field2, ...;
       $| (numbering:managed) Field1, Field2, ...;

Variants:

1. ... field(readonly) Field1, Field2, ...

2. ... field(mandatory) Field1, Field2, ...

3. ... field(features:instance) Field1, Field2, ...

4. ... field(mandatory:create) Field1, Field2, ...

5. ... field(readonly:update) Field1, Field2, ...

6. ... field(numbering:managed) Field1, Field2, ...

Effect

This topic lists field attributes 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.

Availability: these field characteristics are available for RAP BOs of type managed, unmanaged, or abstract. In case of a projection BDEF, automatic inheritance takes place. To newly define field characteristics in a projection BDEF, special rules apply. See topic CDS BDL - field characteristics, projection BDEF.

  • Variants 1 to 5: Development guide for the ABAP RESTful Application Programming Model, section Feature Control Definition: Fields
  • Variant 6: Development guide for the ABAP RESTful Application Programming Model, section Automatically Drawing Primary Key Values in Managed BOs.

Variant 1

... field(readonly) Field1, Field2, ...


Effect

  • Defines that the values of the specified fields must not be created or updated by the RAP BO consumer.
  • Static field attribute.

Variant 2

... field(mandatory) Field1, Field2, ...


Effect

  • 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's 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.

Example

The following example shows a managed BDEF that defines the field char_field1 as mandatory.

The ABAP program 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 SELECT statement, it displays the content of the underlying database table.

Code Snippet:

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@@

Variant 3

... field(features:instance) Field1, Field2,...


Effect

  • 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 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's no error or warning message. In a managed implementation scenario, there's also no entry in the response structures. In an unmanaged implementation scenario, the reported structure can be filled, depending on the BO implementation.

Example

The following example shows a managed BDEF that defines dynamic feature control for field int_field2.

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 program DEMO_RAP_INSTANCE_FEATURES uses EML to access to RAP business object.

  • First, it inserts an entity instance directly onto the database using 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 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 EML - RAP Calculator



Variant 4

... field(mandatory:create) Field1, Field2, ...


Effect

  • 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.

Note

A typical use case is to combine mandatory:create with readonly:update for key fields (external numbering by RAP BO consumer).

Variant 5

... field(readonly:update) Field1, Field2, ...


Effect

  • 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 runtime error occurs.

Variant 6

... field(numbering:managed) Field1, Field2,...


  • Automatic assignment of values for the field in question.
  • Can be applied only to primary key fields with ABAP type raw(16) (UUID).
  • This so-called managed internal numbering is managed by the RAP framework, no implementation in the ABAP behavior pool is required.

Note

For self-defined numbering, the keyword early numbering is available, see topic CDS BDL - early numbering.

Example

The following example shows a managed BDEF that defines internal numbering for the key field key_field.

The ABAP program DEMO_RAP_MANAGED_FIELDS 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 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:

Result: values for the primary key field are generated automatically.

IMAGE @@ABDOC_INTERNAL_NUMB.png@@358@@106@@




CPI1466 during Backup   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

Length: 15472 Date: 20240425 Time: 070603     sap01-206 ( 221 ms )