Get Example source ABAP code based on a different SAP table
Using %tky This example demonstrates the use of %tky in two scenarios: a managed RAP BO in a non-draft scenario a managed RAP BO in a draft scenario Data models Non-draft scenario: The CDS data model consists of the root entity DEMO_MANAGED_ROOT_4 and its child entity DEMO_MANAGED_CHILD_4. The child entity is not used in the example. Root entity: DDLS DEMO_MANAGED_ROOT_4 Draft scenario: The CDS data model consists of the root entity DEMO_MANAGED_DRAFT_ROOT and its child entity DEMO_MANAGED_DRAFT_CHILD. The child entity is not used in the example. Root entity: DDLS DEMO_MANAGED_DRAFT_ROOT Behavior definition Non-draft scenario: The RAP behavior definition DEMO_MANAGED_ROOT_4 is defined in RAP BDL as follows: BDEF DEMO_MANAGED_ROOT_4 Draft scenario: The BDEF is DEMO_MANAGED_DRAFT_ROOT. It is defined as follows: BDEF DEMO_MANAGED_DRAFT_ROOT Behavior implementation
Non-draft scenario: For the above RAP behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_MANAGED_ROOT_4. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_MANAGED_ROOT_4========CCIMP of the behavior pool. In this case, the behavior pool does not include any implementations that are relevant for the example.
Draft scenario: The global class of the behavior pool is BP_DEMO_MANAGED_DRAFT_ROOT. The actual implementation is here: BP_DEMO_MANAGED_DRAFT_ROOT====CCIMP. In this case, the behavior pool does not include any implementations that are relevant for the example.
ABAP_SOURCE_CODE DEMO CL_DEMO_RAP_DRVD_TYPES_TKY
ABAP_DESCRIPTION Access with ABAP using EML There are two scenarios covered to demonstrate the use of %tky: Non-draft scenario
An ABAP_EML modify request covers a create operation to create new RAP BO instances and an update operation on those newly created instances. In the RAP create operation, the key is specified with different options. The update operation on the newly created instances updates a specific field. The instances are referred to using %tky and others to demonstrate that %tky can also be used to refer to the keys in non-draft scenarios. See the topic Using Keys and Identifying RAP BO Instances in a Nutshell for more information. With a COMMIT ENTITIES statement, the instances are saved to the database. The output shows the database table entries as well as the failed messages that are returned for those instances for which an update operation cannot be executed. Draft scenario ABAP_EML modify requests are covered to execute RAP operations on active and draft instances
RAP operations on active instances: An ABAP_EML modify request covers a create operation to create new, active RAP BO instances and an update operation on those newly created instances. The update operation on the newly created instances update a specific field. The instances are referred to using %tky to demonstrate that %tky can also be used to refer to the keys in draft scenarios while disabling the included %is_draft component to execute RAP operations on active instances. A COMMIT ENTITIES statement saves the instances to the database. The output shows those entries.
RAP operations on draft instances: The previously created active instances are put to the draft table using the draft action edit and the COMMIT ENTITIES statement that follows. Then, an update operation on those draft instances is carried out by referring to the keys with %tky . The draft indicator is enabled. The following COMMIT ENTITIES statement save the updated values in the draft table. With the draft action activate and a COMMIT ENTITIES statement, the updates done on the draft table get saved to the database. The output shows different tables to demonstrate the effect on the draft and database tables. The first two tables show the state of the draft and database table before the activation, i. e. the update on the draft instances is shown. At this stage, there have not been any changes to the database table. The next two tables show the state of the draft and database tables after the activation. The database table now includes the former draft instances that have been persisted to the database. The draft table is empty.
