Get Example source ABAP code based on a different SAP table
Example for Message-Related BDEF Derived Type Components This example demonstrates the use of the following message-related BDEF derived type components with a managed RAP BO :
%element
%global
%msg
%other
%own
%path
%state_area
ABAP_FURTHER_INFO See more details on message handling in the Development Guide for the ABAP RESTful Application Programming Model, section Messages. Data model The CDS data model consists of the root entity DEMO_MANAGED_ROOT_REPORTED and its child entity DEMO_MANAGED_CHILD_REPORTED. Root entity: DDLS DEMO_MANAGED_ROOT_REPORTED Child entity: DDLS DEMO_MANAGED_CHILD_REPORTED Behavior definition The RAP behavior definition DEMO_MANAGED_ROOT_REPORTED is defined in RAP BDL as follows: BDEF DEMO_MANAGED_ROOT_REPORTED Behavior implementation For the above RAP behavior definition, one ABP is created. The global class of the behavior pool is BP_DEMO_MANAGED_ROOT_REPORTED. The actual behavior implementation takes place in local classes that are defined and implemented in the BP_DEMO_MANAGED_ROOT_REPORTED=CCIMP of the behavior pool. The following methods are relevant for the example:
get_global_authorizations The method is implemented in a way that RAP create, update and delete operations are only enabled for users with the appropriate authorizations. In the interest of having a simple demo, the example goes without an authorization object which is, for example, a way to handle the authorization granting in production applications. The variable auth_flag represents the authorization that is granted or not. In this case, the permission for the operations is granted and the reported response parameter is filled by adding a message to the %msg component. Furthermore, the components %create, %update and %delete are filled in case the respective requested_authorizations parameter is marked as enabled. The %global component is marked as enabled, too, because the message is a RAP transition message and, thus, related to a specific entity of the business object. For demonstration purposes, a RAP unbound message is added to the %other component in the context of this method.
validatenum: It contains the method implementation for a validation. The validation checks whether the value of a number of a RAP BO instance field in the child entity is between the values of two numbers of two fields in the root entity. If this is not the case, the validation fails and the failed and reported response parameters are filled. Since reported is of type TYPE RESPONSE FOR REPORTED LATE , the %own component is available and used in the example, although it is optional here, to refer to the child entity. The %path, %element and %state_area components are also filled. Before looping at the RAP BO instances, the state area is invalidated. For demonstration purposes, a RAP unbound message is added to the %other component in the context of this method.
ABAP_SOURCE_CODE DEMO CL_DEMO_RAP_DRVD_TYPES_REPO
ABAP_DESCRIPTION Access with ABAP using EML The class includes multiple ABAP_EML requests: ABAP_EML create request: Multiple RAP BO instances are created for the root entity. A COMMIT ENTITIES triggers the saving of the instances to the database. Apart from an internal table showing the database table entries, the output shows the REPORTED EARLY response that, among other things, includes the %global component that is marked as enabled, and the content of the %other component. First ABAP_EML create-by-association request: Multiple RAP BO instances are created for the child entity. All are purposely specified in a way so that the validation does not fail. Hence, all entries are saved to the database table following a COMMIT ENTITIES statement. The entries are shown in an internal table in the output. Besides this, REPORTED LATE responses are displayed. Since the validation is successful, there are no entries in the reported parameter for the RAP BO entities. For demo purposes, another RAP unbound message that has been added to %other when calling the validatenum method is displayed. Second ABAP_EML create-by-association request: Two RAP BO instances are created for the child entity. All are purposely specified in a way so that the validation fails. Hence, the entries are not saved to the database table following a COMMIT ENTITIES statement. The entries of the database table are shown in an internal table in the output and do not show any changes. Also here, REPORTED LATE responses are displayed in a table. Since the validation fails, the reported parameter shows entries. Among them, there are entries to visualize the content of the %path and %element components. The %state_area component is initial in this context. A read operation that follows this create-by-association operation is required to visualize an entry. The RAP unbound message in %other is displayed, too. ABAP_EML read-by-association request: A read-by-association operation is executed on the previously failed instances. The entries of the REPORTED EARLY response is displayed in an internal table. The sole purpose of this operation is to visualize the %state_area component that shows an entry. Third ABAP_EML create-by-association request: A ROLLBACK ENTITIES statement before the create-by-association request rolls back all changes of the current RAP transaction. Then, two RAP BO instances are created for the child entity using the same keys as previously. All are purposely specified in a way so that the validation does not fail. Hence, the entries are saved to the database table following a COMMIT ENTITIES statement. The entries of the database table are shown in an internal table. Both REPORTED EARLY and REPORTED LATE responses are displayed in an internal table, too, however, they do not show any entries for the child entity. The RAP unbound messages in %other contained in REPORTED EARLY and REPORTED LATE are displayed.
