Ansicht
Dokumentation
ABENBDL_AUGMENT_PROJECTION - BDL AUGMENT PROJECTION
ABAP Short Reference Addresses (Business Address Services)This documentation is copyright by SAP AG.
- augment, Projection BDEF
Augmenting operations
... augment ...
Augmenting fields
... modify ... ...
Alternatives:
1. ... augment ...
2. ... modify ... ...
Effect
With the operation augmentation, it is possible to add data or modify incoming requests on the projection layer before data reaches the transactional buffer. This is described under Alternative 1, augmenting operations.
Moreover, the operation augmentation can include virtual element that are defined in the projection view layer, in the derived types of the projection BDEF and work with them. This is described under Alternative 2, augmenting fields.
- Development guide for the ABAP RESTful Application Programming Model, section Operation Augmentation.
Alternative 1
... augment ...
Effect
With an augmentation implementation, you can add data requests reaching the projection BO before the request is passed to the handler of the base BO. Modify operations can be augmented in the projection BDEF. They are implemented in the RAP handler method FOR MODIFY in the ABAP behavior pool of the projection layer.
The following operations can be augmented:
An augmenting operation can refer to original base instances and add field values. It can also create new base instances. In the former case, if an instance from the original request is augmented, it is subject to the following regulations:
- To augment an original update, issue an augmenting operation update on the same instance.
- To augment an original create, issue an augmenting operation create on the same instance.
- Do not issue an augmenting update, as the base BO would then see the un-augmented create operation, which it may refuse (for example because of a missing mandatory field) or handle in an unwanted manner.
- To augment an original create by association, issue an augmenting operation create by association on the same instance.
It is not possible to set a field in augment which was already set for the original instance. The RAP runtime discards such augment fields. For example, values set in the original request cannot be changed. Only fields which are unset in the original request can be added.
It is not possible to set fields in augment that are defined as readonly. Augment is handled like an external access and therefore, any attempt to access a readonly field leads to a runtime error.
When the augmentation operation is executed, the original base instances have already been locked by the framework. If the augment contains new instances, then the runtime attempts to lock them. Instances for which locking fails are included in the FAILED response of the projection request, and are removed from the base request.
Note
It is possible to combine augment and precheck. If both the base BO and the projection BO define a precheck method, the execution order is as follows:
- precheck on projection
- augment on projection
- precheck on base
This way, the request including the augmentation can be checked by the base precheck.
Example
The following example shows a projection BDEF that demonstrates how to define and implement the operation augmentation for modify operations.
The base BDEF is DEMO_RAP_MANAGED_ASSOC_ROOT.
For the implementation in the ABAP behavior pool, see BP_DEMO_RAP_PROJ_AUGMENT======CCIMP.
The ABAP program DEMO_RAP_PROJ_AUGMENT uses
EML to access the
RAP business object. It performs a create, an update, and a
create-by-association
operation. The augmentations are automatically performed, they add field values and / or add new entity instances.
The example listed above is displayed an explained in detail in topic CDS BDL - operation augmentation.
Alternative 2
... modify ...
Effect
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 by default excluded from the BDEF derived types for the projection BDEF, because they are non-transactional in character. Augmentation provides a means to include such fields in transactional handling. As a prerequisite, they must be marked in the projection BDEF as follows:
field (modify) VirtualField;
This causes VirtualField to appear in types like table for create ProjectionEntity.
Then, by augment-enabling the required modify operations and implementing the augment exit, the field can be part of a projection modify request, and translated to the necessary augment operations on the base BO (where the field has no direct counterpart). For example, a localized field can be translated into a create or update of the associated text entity, using the current language as additional key. (The text entity may not even be exposed as a projection entity; it only occurs in the projection BO by means of virtual field[s].)
Currently, the operation augmentation is not available for the RAP read operation and therefore, virtual fields can't be read enabled.
Note
For an augmented virtual field, field characteristics, such as features:instance, can be defined. For further details, see topic CDS BDL - field characteristics, projection BDEF.
Example
The following example shows a projection BDEF that augments a virtual element. The base BDEF is DEMO_RAP_MANAGED_ASSOC_ROOT.
As a result, the field is part of the BDEF derived types:
IMAGE @@ABDOC_VIRTUAL.jpg@@422@@251@@For a complete end-to-end example, see the Development guide for the ABAP RESTful Application Programming Model, section Editing Language-Dependent Fields.
CPI1466 during Backup General Data in Customer Master
This documentation is copyright by SAP AG.
Length: 10895 Date: 20240426 Time: 125234 sap01-206 ( 160 ms )
