RAP - Determination

Table of contents

• General
• Creation
• Implementation
• Test
• Conclusion

Last week we dealt with validation and how you can use it to keep your business object clean. This week we will go into the automatic derivations and how you don't have to let the user fill in all fields.

 

General

A determination can take the work out of filling in fields with information that might come from other data sources. Or information is derived if the user forgets to fill it in. A determination can be simple or complex, but in the end it also ensures that the data in the business object is complete.

 

Creation

In the first step, let's create a determination in our business object, for this we define it in the behavior definition and give the appropriate properties:

determination fillCurrency on modify { create; update; }

 

Here "on modify" and "on save" are available, which trigger the determination differently. "On Modify" triggers every time the data changes and the user enters something new in a field. Above all, quick determinations that do not consume so much performance should be carried out here. "On Save" is only triggered when the data is saved in the save sequence and is particularly suitable for performance-intensive tasks. As with validation, fields and events are available in the curly brackets. Here you can adjust the determination accordingly granular.

You can then generate the method in the class again with CTRL + 1 and do not have to create it manually. The method definition now looks like this:

METHODS fillcurrency FOR DETERMINE ON MODIFY
  IMPORTING keys FOR partner~fillcurrency.

 

Hint: A determination only has to be defined at the level of the interface, since it applies at all times and does not have to and cannot be given to the outside in the projection layer.

 

Implementation

The method interface is very straightforward and contains fewer parameters than with the validations. As always, the affected keys are passed, the only return we have is the table for messages in case something goes wrong during the derivation.

 

Our derivation is correspondingly simple, we read the transferred key and check whether the PaymentCurrency field is filled. If this is not the case, then we set a default value so that the field does not remain empty. The implementation then looks like this:

READ ENTITIES OF ZBS_I_RAPPartner IN LOCAL MODE
  ENTITY Partner
  FIELDS ( PaymentCurrency )
  WITH CORRESPONDING #( keys )
  RESULT DATA(lt_partner_data).

LOOP AT lt_partner_data INTO DATA(ls_partner) WHERE PaymentCurrency IS INITIAL.
  MODIFY ENTITIES OF ZBS_I_RAPPartner IN LOCAL MODE
    ENTITY Partner
    UPDATE FIELDS ( PaymentCurrency )
    WITH VALUE #( ( %tky = ls_partner-%tky PaymentCurrency = 'EUR' %control-paymentcurrency = if_abap_behv=>mk-on ) ).
ENDLOOP.

 

Hint: In this case, a commit must not be set because we are currently processing the business object. If you try anyway, you will receive an error message from the compiler and activation is not possible.

 

Test

In the next step, we test the determination once in the app. To do this, we create a new data record and fill in the key and the mandatory country field. We created the mandatory field in the last article on validation:

 

After saving, we now get the following image, the currency has been set to default and no longer needs to be filled.

 

Conclusion

The determination is a good way to enrich missing information, you can share fast and slow determinations well and call them up according to the performance. Slow determinations make sense especially when saving, because a change is called up after each field.