HANDS-ON EXERCISE FOR WEEK 3 UNIT 5: ENHANCING THE BUSINESS OBJECT BEHAVIOR WITH APP-SPECIFIC LOGIC

Previous exercise:

Week 3 Unit 4: Understanding Entity Manipulation Language (EML)

Introduction

In the present hands-on exercise, you will enhance the standard transactional behavior of your managed business object by defining determinations, validations and actions. You will also add static and dynamic feature control.

You can watch week 3 unit 5: Enhancing the Business Object Behavior with App-Specific Logic on the openSAP platform.

Hints and Tips
Speed up the typing by making use of the Code Completion feature (shortcut Ctrl+Space) and the prepared code snippets provided. You can easily open an object with the shortcut Ctrl+Shift+A, format your source code using the Pretty Printer feature Shift+F1 and toggle the fullscreen of the editor using the shortcut Ctrl+M.

A great overview of ADT shortcuts can be found here: Useful ADT Shortcuts

Please note that the placeholder #### used in object names in the exercise description must be replaced with the suffix of your choice during the exercises. The suffix can contain a maximum of 4 characters (numbers and letters). The screenshots in this document have been taken with the suffix 1234 and system D20. Your system id will be TRL.

Please note that the ADT dialogs and views may change in the future due to software updates.

Follow the instructions below.

Step 1. Enhance the behavior definition of the Travel entity

Begin with enhancing the behavior definition of the Travel entity.

Open the base behavior definition ZI_RAP_Travel_#### - where #### is your chosen suffix – of your business object by either double-clicking on it in the Project Explorer or using the shortcut Ctrl+Shift+A (Open ABAP Development Object).
Provide the behavior implementation for each entity in a separate ABAP class.
For that, specify a behavior implementation class (aka behavior pool) using the statement implementation in class… for each entity.

Move the generated, commented out statement implementation in class… specified after the managed keyword from the header section to the travel entity after the define behavior for… statement as shown on the screenshot below. Remove the semi-colon at the end of the statement.

You can use the code snippet provided below for that.
Do not forget to replace the placeholder #### with your chosen suffix.
```
 implementation in class zbp_i_rap_travel_#### unique
```
The source code should look as follows:
Add static field-control by setting the fields TravelID, TotalPrice and TravelStatus to readonly.
Do the same for the administrative fields LastChangedAt, LastChangedBy, CreatedAt, CreatedBy and LocalLastChangedAt.

For that, copy and insert the code snippet provided below in the Travel behavior definition as shown on the screenshot.
```
  field ( readonly  ) TravelID, TotalPrice, TravelStatus;
  field ( readonly  ) LastChangedAt, LastChangedBy, CreatedAt, CreatedBy, LocalLastChangedAt;
```
The source code should look as follows:
Set the fields AgencyID and CustomerID to mandatory.
A little red star symbol will then be shown in the SAP Fiori elements UI.

Please note: The implementation of a corresponding validation is still required.

For that, copy and insert the code snippet provided below in the Travel behavior definition as shown on the screenshot.
```
  field ( mandatory ) AgencyID, CustomerID;
```
The source code should look as follows:
Add the following 3 actions:
- Define the two actions acceptTravel and rejectTravel with dynamic feature control for approving and rejecting travels. Both return $self with cardinality 1 as the result. $self means that the instance of the same type is returned on which the operation is performed.
- Define the internal action recalcTotalPrice for the re-calculation of the total price.
For that, copy and insert the code snippet provided below in the Travel behavior definition as shown on the screenshot.
```
  action ( features : instance ) acceptTravel result [1] $self;
  action ( features : instance ) rejectTravel result [1] $self;
  internal action recalcTotalPrice;
```
The source code should look as follows:
Add the following 3 determinations:
- The setInitialStatus determination is used to default the status to N whenever a new instance is created. It uses the create trigger on Modify.
- The calculateTotalPrice determination is used to update the total price whenever the BookingFee or CurrencyCode is changed.
- The calculateTravelID is used to determine the TravelID when a new instance is created. It is executed on save.
  Please note that the calculation of the TravelID is only used for demonstration purposes. The primary key of the Travel business object is still the TravelUUID.
For that, copy and insert the code snippet provided below in the Travel behavior definition as shown on the screenshot.
```
determination setInitialStatus    on modify { create; }
determination calculateTotalPrice on modify { field BookingFee, CurrencyCode; }
determination calculateTravelID   on save   { create; }
```
The source code should look as follows:
Define 3 validations to validate the input of the fields AgencyID, CustomerID, BeginDate and EndDate. They shall be all triggered on save.
For that, copy and insert the code snippet provided below in the Travel behavior definition as shown on the screenshot.
```
  validation validateAgency   on save { field AgencyID; create; }
  validation validateCustomer on save { field CustomerID; create; }
  validation validateDates    on save { field BeginDate, EndDate; create; }
```
You can make use of the shortcut Ctrl+F1 to format the source code.

The source code should look as follows:
Save the behavior definition.
We will address the appearing warnings in the next unit (i.e. week 3 unit 6) when we provide the behavior implementation.

Step 2. Enhance the behavior definition of the Booking entity

Now go ahead and enhance the behavior definition of the Booking entity.

Specify the behavior implementation class (aka behavior pool) of the Booking entity.

For that, copy and insert the code snippet provided below in the Booking behavior definition as shown on the screenshot.
Do not forget to replace the placeholder #### with your chosen suffix.
```
implementation in class zbp_i_rap_booking_#### unique
```
The source code should look as follows:
For the Booking entity, also add static field-control to the field BookingID by setting it to readonly.

Do the same for the administrative fields CreatedBy, LastchangedBy and LocalLastChangedBy.

For that, copy the code snippet provided below and replace the existing statement field ( readonly ) TravelUUID; with it in the Booking behavior definition as shown on the screenshot.
```
  field ( readonly ) TravelUUID, BookingID;
  field ( readonly ) CreatedBy, LastChangedBy, LocalLastChangedAt;
```
The source code should look as follows:
Add the following 2 determinations:
- The calculateBookingID determination for determining the BookingID.
- For updating the TotalPrice we add the calculateTotalPrice that is triggered whenever the FlightPrice or CurrencyCode is changed.
For that, copy and insert the code snippet provided below in the Booking behavior definition as shown on the screenshot.
```
  determination calculateBookingID  on modify { create; }
  determination calculateTotalPrice on modify { field FlightPrice, CurrencyCode; }
```
You can make use of the shortcut Ctrl+F1 to format the source code.

The source code should look as follows:
Save and activate the behavior definition.

Step 3. Enhance the projected behavior definition

Determinations and validations are automatically triggered by the RAP application infrastructure at runtime. Therefore, there is no need to project them. But this is not the case for actions. Therefore, they always need to be explicitly exposed in the business object behavior projection if they are required in the given scenario.
In order to later access the new defined actions acceptTravel and rejectTravel in your Travel app, you will now expose them in the business object behavior projection.

Open the behavior definition of your business object ZC_RAP_Travel_####, where #### is your chosen suffix by either double-clicking on it in the Project Explorer or using the shortcut Ctrl+Shift+A (Open ABAP Development Object).

Project the two new actions acceptTravel and rejectTravel by adding the use statements provided below in the travel behavior projection as shown on the screenshot below.

For that, copy and insert the code snippet provided below in the Travel behavior definition as shown on the screenshot.
```
   use action acceptTravel;
   use action rejectTravel;
 
```
You can make use of the shortcut Ctrl+F1 to format the source code. The source code should look as follows:
Save and activate the behavior definition.

You have now enhanced the behavior of your composition model by declaring new, business object specific logic and behavior, but no implementation is provided at this stage. You will implement the logic in the hands-on exercise of the next unit – i.e. week 3 unit 6.

Step 4. Enhance the CDS metadata extension of the Travel entity

You will now add appropriate UI annotations in the CDS metadata extension for the Travel entity to add the newly defined actions acceptTravel and rejectTravel to the SAP Fiori elements-based UI of your Travel app.

Open the CDS Metadata Extension ZC_RAP_TRAVEL_#### of the travel entity, where #### is your chosen suffix.

You can either double-click on it in the Project Explorer or use the shortcut Ctrl+Shift+A (Open ABAP Development Object).

Scroll down to the element TravelStatus and replace the existing @UI annotation block with the code snippet provided below as shown on the screenshot.

The lineitem and identification annotations have been enhanced with information about the action from type #FOR_ACTION, the name of the back-end action is specified in the attribute dataAction and a label is also provided.

  @UI: {  lineItem:       [ { position: 90 },
                            { type: #FOR_ACTION, dataAction: 'acceptTravel', label: 'Accept Travel' },
                            { type: #FOR_ACTION, dataAction: 'rejectTravel', label: 'Reject Travel' }
                          ],
          identification: [ { position: 90 },
                            { type: #FOR_ACTION, dataAction: 'acceptTravel', label: 'Accept Travel' },
                            { type: #FOR_ACTION, dataAction: 'rejectTravel', label: 'Reject Travel' }
                          ] }

The source code should look as follows:

Save and activate the metadata extension.

Summary

You have completed the exercise!
In this unit, you have learned

How to enhance the standard transactional behavior (CUD) of a business object using determinations, validations and actions.
How to define static and dynamic feature control.
How to add the enhanced behavior to the projected behavior definition
Finally, how to enhance CDS metadata extensions to add buttons on the UI for defined actions.

Solution

Find the source code of the CDS behavior definitions (base and projection), and the enhanced CDS metadata extension for the Travel entity in the sources folder:

Do not forget to replace all the occurrences of #### in the copied source code with your chosen suffix.

Next exercise

Week 3 Unit 6: Implementing the Business Object Behavior

FilesExpand file tree

unit5.md

Latest commit

History