Ansicht
Dokumentation
ABENDERIVED_TYPES_REPORTED_ABEXA - DERIVED TYPES REPORTED ABEXA
Addresses (Business Address Services) ROGBILLS - Synchronize billing plansThis documentation is copyright by SAP AG.
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:
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:
Child entity:
Behavior definition
The CDS behavior definition DEMO_MANAGED_ROOT_REPORTED is defined in CDS BDL as follows:
Behavior implementation
For the above CDS 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.
Source Code
Description
Access with ABAP using EML
The program includes multiple requests:
- 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 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 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.
- 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 create-by-association request:
- A ROLLBACK ENTITIES statement before the create-by-association request rolls back all changes of the current RAP LUW. 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.
Vendor Master (General Section) BAL Application Log Documentation
This documentation is copyright by SAP AG.
Length: 9391 Date: 20240512 Time: 024221 sap01-206 ( 142 ms )
