b.santos/abap-cheat-sheets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update

Browse Source
This commit is contained in:
danrega
2024-01-05 15:24:25 +01:00
parent 6f8a9af27d
commit 3da26b1510
1 changed files with 243 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

248
08_EML_ABAP_for_RAP.md
View File

@@ -4,6 +4,7 @@
- [ABAP for RAP: Entity Manipulation Language (ABAP EML)](#abap-for-rap-entity-manipulation-language-abap-eml)
- [RAP Terms](#rap-terms)
- [Excursion: RAP Behavior Definition (BDEF)](#excursion-rap-behavior-definition-bdef)
- [ABAP Behavior Pools (ABP)](#abap-behavior-pools-abp)
- [RAP Handler Classes and Methods](#rap-handler-classes-and-methods)
- [RAP Saver Class and Saver Methods](#rap-saver-class-and-saver-methods)
@@ -45,15 +46,13 @@ The following points cover RAP-related terms such as *RAP business objects* and
is the root entity that represents the business object. With a
large composition tree, RAP BOs can be fairly complex. Or they
can be very simple by just consisting of one root entity alone.
- Note: There is a special syntax for the CDS root view
entity of a RAP BO: [`define root view
entity`](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abencds_define_root_view_v2.htm)
- [CDS behavior
- Note: There is a special syntax for the [CDS root entity](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abenroot_entity_glosry.htm) of a RAP BO: [`define root view entity`](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abencds_define_root_view_v2.htm)
- [RAP behavior
definition](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abencds_behavior_definition_glosry.htm "Glossary Entry")
(BDEF)
- RAP BOs are described by the definitions specified in a special
[DDIC](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abenddic_glosry.htm "Glossary Entry")
artifact: CDS behavior definition (BDEF)
artifact: RAP behavior definition (BDEF)
- A BDEF defines the [RAP business object
behavior](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abenrap_bo_behavior_glosry.htm "Glossary Entry")
(i. e. the transactional behavior of a RAP BO)
@@ -197,6 +196,245 @@ focus on).
<p align="right"><a href="#top">⬆️ back to top</a></p>
## Excursion: RAP Behavior Definition (BDEF)
- As mentioned in the RAP terms and as the name implies, a RAP behavior definition describes a RAP business object (RAP BO) by defining its behavior for all of its RAP BO entities.
- BDL source code is used in a BDEF.
- Once you have created ...
- the CDS root view entity of a RAP BO, ADT helps you create the skeleton of a BDEF (e.g., right-click on the CDS root view entity and choose *New Behavior Definition* from the pop-up).
- the BDEF, ADT helps you create the skeleton of an ABAP behavior pool, as well as RAP handler and saver method declarations and the skeleton of implementations via ADT quick fixes.
- More information (see also the subtopics there):
- [Structure of a RAP behavior definition](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abencds_bdef.htm)
- [Infos about BDL syntax](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abenbdl_syntax.htm)
- [Infos about behavior definitions](https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abenbdl.htm)
The following example shows a commented BDEF.
Note that there is a wide variety of possible specifications and options. The example shows only a selection. For full details, refer to the ABAP Keyword Documentation.
```abap
//Possible implementation types: managed, unmanaged, abstract, projection, interface
//(with restrict/enable further specifications)
//You can specifiy one or more implementation classes (behavior pools/ABPs -> bp...)
//for the RAP BO (in some contexts, specifying no ABP is possible).
//Specifying unique is mandatory (each operation can only implemented once).
managed implementation in class bp_some_demo unique;
//For managed RAP BOs, you can enable user-defined saving options (optional additions
//are available).
//Purpose: Enhancing or replacing the default save sequence (Note: Only in this case,
//the ABP has a local saver class/save_modified saver method)
//managed with additional save with full data implementation in class bp_some_demo unique;
//full data: Full instance data is passed for saving
//managed with unmanaged save implementation in class bp_some_demo unique;
//Enabling the strict mode (and version) to apply additional syntax checks; handled by
//the RAP framework; it is recommended that you use the most recent version
strict ( 2 );
//Enabling RAP draft handling
//with draft;
//It is mandatory to specify an entity behavior definition for the RAP BO root entity.
//Here, some_demo represents a CDS view entity.
define behavior for some_demo
//Specifying an alias name (e.g. to have a more telling name than the technical name of
//the entity). When specifying an alias name, you should address the entity with the alias
//name instead of the full name (e.g. in the signature of handler methods).
//define behavior for some_demo alias root
//Specifying the database table a RAP BO is based on (only available/mandatory in managed
//BOs); note further requirements for diverse scenarios in the documentation
persistent table some_dbtab
//Mandatory specification of a draft table when a RAP BO is draft-enabled
//draft table drafttab
//Specifying the locking mechanism for entities, e.g. to prevent a simultaneous
//modification. In unmanaged RAP BOs, this must be self-implemented in a dedicated handler
//method
lock master
//Controlling authorization that is to be implemented in an ABP (also for managed)
//You can specify variants: global (e.g. for restricting certain operations) and/or
//instance (restrictions based on entity instances) or both of them (dedicated handler
//methods must be implemented)
//More variants are available that can be specified in the { ... } block below for
//excluding and delegating authorization checks (e.g. authorization:update)
authorization master ( instance )
//authorization master ( global )
//authorization master ( instance, global )
//Defining late numbering for primary key fields (see the adjust_numbers handler method)
//More numbering options are available such as early numbering, or, in the { ... } block below,
//the 'numbering : managed' specification for particular fields.
//late numbering
//Defining a field as entity tag (ETag) field for optimistic concurrency control (i.e.
//enabling transactional access to data by multiple users to avoid inconsistencies when
//unintentionally changing already modified data). More options available, e.g. for
//draft-enabled RAP BOs (total etag).
//etag master some_field
{
//RAP BO operations
//Standard operations (Note: Read is implicitly enabled, no specification available)
create;
update;
//More additions are available dealing with authorization, feature control, precheck etc.
//The example shows precheck. In doing so, you can implement a precheck (e.g. to prevent
//unwanted changes) before instances are deleted in a dedicated handler method. A precheck
//implementation is also available for other operations (e.g. actions).
//As is true for various specifications, a comma-separated list of specifications is possible.
delete( precheck );
//Applying feature control
//delete( features: global );
//Applying authorization control
//delete( authorization : update );
//Operations for associations (many specification options are possible)
//The following example means enabling create-by-association operations for associations
//Assumption: _child is specified in the the underlying CDS data model.
association _child { create; }
//Non-standard operations (check the specification options in the documentation, e.g. feature
//control and others are possible) such as actions (modify RAP BO instance) and functions (return
//information). There are different flavors of actions such as non-factory and factory actions,
//which themselves have different variations. Other flavors of actions are save actions (only to
//be executed during save sequence), determine actions (allow RAP BO consumers to execute
//determinations and validations on request), and draft actions.
//Non-factory actions (modify existing instances)
//Instance action, relates to instances, modify instances
action act1;
//Static action, not bound to instances, relates to the entrie entity
static action act2;
//Internal action, accessible only from within the ABP (internal can also be specified in other
//contexts, e.g. operations)
internal action act3;
//You can optionally specify input or output parameters or both (not always possible for all
//action types). The following example shows an output parameter, defined with the result
//addition. It stores the result of an action in an internal table. Variants are possible for
//the return type. Here, it is $self (result type is the same type as entity) It can, for
//example, also be an abstract BDEF or a different entity.
action act4 result [1] $self;
//Input parameter specified following 'parameter' (in this case, a CDS abstract entity)
action act5 parameter some_cds_abstract;
//Factory action (to create instances, can be instance-bound or static)
//Specifying the cardinality is mandatory
factory action act6 [1];
//Draft actions
//Available for draft-enabled RAP BOs, allow data modification on the draft table; are
//implicitly available; it is recommended for the draft actions to be specified explicitly;
//for some of the methods the 'with additional implementation' is available
//Copies active instances to the draft table
//draft action Edit;
//Sets a lock for entity instances on the persistent database table
//draft action Resume;
//Copies draft table content to the persitent database table; recommendation: use the
//optimized addition
//draft action Activate optimized;
//Clears entries from the draft database table
//draft action Discard;
//Corresponds to the determine actions for active instances;
//used to validate draft data before transitioning to active data
//draft determine action Prepare
// {
//You can assign validations and determinations defined with 'on save'
// validation val;
// }
//Functions (similar to actions, there are optional additions, such as static)
//Since they return information, specifying an output parameter is required.
//Instance function
function func1 result [0..*] $self;
//Static function
static function func2 result [1] some_cds_abstract;
//Instance function with optional input parameter
function func3 parameter some_cds_abstract result [1] $self;
//Field characteristics
//Field values cannot be created/updated
field ( readonly ) field1;
//Read-only during update (especially key fields created during create operations)
field ( readonly : update ) key_field;
//It is mandatory to specify values for the fields before persisting them to the database
//Comma-separated list possible for the field characteristics in general;
//mutliple characteristics can also be specified in a comma-separated list in the parentheses
field ( mandatory ) field2, field3;
//Defining access restrictions for fields
field ( features : instance ) field4;
//Validations
//Checking the consitency of instances; validations are triggered based on conditions
//Conditions (one or more are possible) can be specified for create, update, delete operations
//and modified fields; note: not available for unmanaged, non-draft RAP BOs.
validation val1 on save { create; field field1; }
//Determinations
//Modifying instances based on trigger conditions;
//As above, conditions (one or more are possible) can be specified for create, update, delete
//operations and modified fields. The triggering is possible for 'on modify' and 'on save'.
determination det1 on modify { update; delete; field field1, field2; }
determination det2 on save { create; field field3, field4; }
//RAP business event (derived events with the specification 'managed evt ...' is also possible)
event evt;
//RAP side effects, to trigger a reload of affected properties on the UI
//Trigger properties: Field changes, action executions
//Multiple side effects can be specified within a { ... } block, separated by a colon
//There are multiple options to specify the target following 'affect'; the example uses fields
//to be reloaded
side effects { field field1 affects field field4;
field field2 affects field field4;
field field3 affects field field4;
action act1 affects field field4; }
}
//It is optional to specify an entity behavior definition for child entities
define behavior for some_child_entity alias child
//Applying locks dependent on the specified association (locks are delegated to
//the specified association). In this case, it's the parent entity. Assumption:
//_parent is specified in the the underlying CDS data model.
lock dependent by _parent
//Applying authorization checks dependent on the specified association
//As above, the assumption is that _parent is specified in the underlying CDS
//data model.
authorization dependent by _parent
{
update;
delete;
field ( readonly ) key_field;
field ( readonly : update ) key_field_child;
association _parent;
}
```
<p align="right"><a href="#top">⬆️ back to top</a></p>
## ABAP Behavior Pools (ABP)
As mentioned above, you can access RAP BO data from inside AS ABAP using