We are hiring and constantly growing! Have a look through our vacancies to find the right role for you!
... $[CREATE field_spec$]
$[CREATE BY \_assoc field_spec$]
$[UPDATE field_spec$]
$[DELETE field_spec$]
$[EXECUTE action field_spec $[REQUEST request$] $[
RESULT result_tab$]$] ...
1. ... CREATE field_spec
2. ... CREATE BY \_assoc field_spec
3. ... UPDATE field_spec
4. ... DELETE field_spec
5. ... EXECUTE action field_spec
The EML MODIFY statement supports the following operations:
In both, managed and unmanaged implementations, all modify operations must be specified in the CDS behavior definition. See more details in the BDL documentation: Define Behavior, Standard Operations. All nonstandard operations (actions) must be self-implemented in the ABP.
Each modify operation requires an internal table (field_spec) of instances as input parameters after the respective keyword to specify the fields that should be modified.
... CREATE field_spec
Used to create new node instances of a RAP BO entity.
For the keywords that must follow the keyword CREATE, see the documentation for field_spec.
The following source code section taken from DEMO_RAP_EML_MODIFY_OP_2 demonstrates a CREATE operation.
... CREATE BY \_assoc field_spec
Used to create new node instances for associated entities for which create must be enabled in the BDEF. The creation is not restricted to compositions. _assoc is the name of the association as it is specified in the underlying CDS view.
For the keywords that must follow the keyword CREATE, see the documentation for field_spec.
The following source code section taken from DEMO_RAP_EML_MODIFY_OP_2 demonstrates a create-by-association operation.
... UPDATE field_spec
Used to update node instances of a RAP BO. The UPDATE statement allows delta updates on RAP BO consumer side to be triggered where only key fields and the fields with new values must be provided. On RAP BO provider side, the fields to be overwritten and kept are identified.
For the keywords that must follow the keyword UPDATE, see the documentation for field_spec.
The following source code section taken from DEMO_RAP_EML_MODIFY_OP_2 demonstrates an UPDATE operation.
... DELETE field_spec
Used to delete instances of a RAP BO. Only key field values or %cid_ref are needed to identify which instances are to be deleted.
For the keywords that must follow the keyword DELETE, see the documentation for field_spec.
The following source code section taken from DEMO_RAP_EML_MODIFY_OP_2 demonstrates a DELETE operation.
... EXECUTE action field_spec $[REQUEST request$] $[RESULT result_tab$]
1. ... REQUEST request
2. ... RESULT result_tab
Used to trigger custom actions that are defined to modify data in a self-implemented way. The syntax for executing an action allows requested data (REQUEST request) to be specified and result data (RESULT result_tab) to be exported, each action specified in target variables.
For the keywords that must follow the keyword CREATE, see the documentation for field_spec.
The following source code section taken from DEMO_CDS_PURCHASE demonstrates a modify operation executing an action.
... REQUEST request
Used to specify whether the result should be returned completely or only parts of it (for example, only the keys) for the purpose of improving performance. request must be typed with the required BDEF derived type TYPE STRUCTURE FOR ACTION REQUEST. The components of the structure are all key and data fields of the RAP BO entity. They are of type ABP_BEHV_FLAG and can be flagged to specify whether the respective fields are included or not.
This is optional and can only be used for actions specified in the BDEF with the addition result selective.
... RESULT result_tab
Actions can optionally return a result. This can only be used for actions specified in the BDEF with
the addition result. The
internal table result_tab must be of type TABLE FOR ACTION RESULT bdef~action. See more details in RESULT result_tab.
Leave us your contact details and we will call you back. Fields marked with * are mandatory.
We offer holistic SAP solutions from a single source to shape digital change and develop new business areas.
Switzerland
Schaffhausen
Germany
Mannheim, Düsseldorf, Munich
USA
Haverhill
Greece
Thessaloniki