With a determination, you can modify an entry via the Entity Manipulation Language to fill out automatically the necessary fields needed. For example, when you type a username inside a field, you may want to extend that in the database as well as in the view with the full name, so that it can be displayed in the same screen.
To start, as like the validation methods, we need a definition in the behavior definition file. We want to extend our Connections service, which contains origin and destination airports. From this we want to show the user from the IATA code the correct city and country code in the view.
First of all, we register this determination in the file as follow:
managed implementation in class ZBP_CONNECTIONS unique;
strict ( 2 );
with draft;
define behavior for ZR_CONNECTIONS
persistent table zconnections
draft table ZCONNECTIONS_D
etag master LocalLastChangedAt
lock master total etag LastChangedAt
authorization master( global )
{
// ...
// Custom determination logic
determination GetCities on save { field AirportCityFromId, AirportCityToId; }
// ...
}After that we can do an implementation, the same way as a validation method. The determination as in this case, gets executed every time, when we save and modify an Airport City Id in the “From” and “To” variant.
In our local behavior implementation class, we get now a new definition GetCities:
CLASS lhc_zr_connections DEFINITION INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
METHODS:
get_global_authorizations FOR GLOBAL AUTHORIZATION
IMPORTING
REQUEST requested_authorizations FOR zr_connections
RESULT result,
" Validation definition methods
" ...
GetCities FOR DETERMINE ON SAVE
IMPORTING keys FOR ZR_CONNECTIONS~GetCities
" ...
ENDCLASS.Now we are able to implement this method:
" Updating fields depending on the entered airport codes.
METHOD GetCities.
" Reading the current data from the business object.
READ ENTITIES OF zr_connections IN LOCAL MODE
ENTITY zr_connections FIELDS
(
AirportCityFromId
AirportCityToId
)
WITH CORRESPONDING #( keys )
RESULT DATA(lt_connections).
" Loop through every business object (since it could be a mass transaction).
LOOP AT lt_connections ASSIGNING FIELD-SYMBOL(<fs_connection>).
" Fetching the airport from data from our value help CDS view.
SELECT SINGLE FROM zvaluehelp_airports
FIELDS City, CountryCode
WHERE AirportId EQ @<fs_connection>-AirportCityFromId
INTO (
@<fs_connection>-AirportCityFrom,
@<fs_connection>-AirportCountryCodeFrom
).
" Fetching the airport to data from our value help CDS view.
SELECT SINGLE FROM zvaluehelp_airports
FIELDS City, CountryCode
WHERE AirportId EQ @<fs_connection>-AirportCityToId
INTO (
@<fs_connection>-AirportCityTo,
@<fs_connection>-AirportCountryCodeTo
).
ENDLOOP.
" Defining a new internal table to update our business object later.
" This table contains addtionally flags in the structure for the RAP framework.
DATA lt_connections_upd TYPE TABLE FOR UPDATE zr_connections.
" Move our updated data to the new table.
lt_connections_upd = CORRESPONDING #( lt_connections ).
" Now with EML, we can update the corresponding fields with our update table.
" We receive then a reported records variable which contains
" the successful saved records.
MODIFY ENTITIES OF zr_connections IN LOCAL MODE
ENTITY zr_connections
UPDATE FIELDS (
AirportCityFrom
AirportCountryCodeFrom
AirportCityTo
AirportCountryCodeTo
)
WITH lt_connections_upd
REPORTED DATA(reported_records).
" These records must be returned to the reported variable
" to notify the user that data has been changed.
reported-zr_connections = CORRESPONDING #( reported_records-zr_connections ).
ENDMETHOD.This is how you can update existing fields. If you want to validate your data input, please refer to this post, which describe the different possibilities to check the data as well with the Entity Manipulation Language.
Leave a Reply