RAP - Action

Table of contents

• Introduction
• Deployment
• Actions
• Messages
• Conclusion

In the last RAP articles we dealt with the topic of validations and determinations, we now want to complete this with the actions. In this article you will learn how to define actions and implement them.

 

Introduction

The easiest way to think of actions is as buttons on an interface, you can trigger them externally and they perform different steps. In most cases, data of the RAP business object is also affected. Similar to validations and determinations, they must be created in the object's behavior definition.

 

Deployment

In the first step we define two simple actions in the behavior definition, you only have to specify the "action" and a name. In this case we define two actions, one normal and one static. The two actions and their methods can be generated via CTRL + 1 in order to implement the coding later.

action fillEmptyStreets;
static action clearAllEmptyStreets;

 

So that the actions can also be used in the app or interface, they must be announced in the projection. It can only be used when it is made available to the outside world.

use action fillEmptyStreets;
use action clearAllEmptyStreets;

 

In order for the actions to now appear on the UI, the Metadata Extension must be extended. For this purpose, any field can be extended with further annotations. By expanding LineItem, the buttons appear above the list. The most important thing is the definition of the "type" and the "dataAction" so that the button is displayed and triggers the correct action.

@UI.selectionField : [ { position: 10 } ]
@UI.lineItem: [
  { position: 20, importance: #MEDIUM },
  { position: 10, type: #FOR_ACTION, label: 'Fill', dataAction: 'fillEmptyStreets' },
  { position: 20, type: #FOR_ACTION, label: 'Clear All', dataAction: 'clearAllEmptyStreets' }
]
@UI.identification: [{ position: 10, qualifier: 'PARTNER_INFO' }]
@EndUserText.label: 'Partner'
@EndUserText.quickInfo: 'Identifier of the partner'
PartnerNumber;

 

The buttons are now also displayed on the UI and can be used:

 

Finally, let's implement the two actions. The "fillEmptyStreets" action fills a data set with an empty street with a value. The "clearAllEmptyStreets" action now clears the values again, but no other streets. The implementation looks like this:

METHOD clearAllEmptyStreets.
  SELECT FROM zbs_dmo_partner
    FIELDS partner, street
    WHERE street = 'EMPTY'
    INTO TABLE @DATA(lt_partner_data).

  LOOP AT lt_partner_data INTO DATA(ls_partner).
    MODIFY ENTITIES OF ZBS_I_RAPPartner IN LOCAL MODE
      ENTITY Partner
      UPDATE FIELDS ( Street )
      WITH VALUE #( ( PartnerNumber = ls_partner-partner Street = '' %control-Street = if_abap_behv=>mk-on ) ).
  ENDLOOP.

  INSERT VALUE #(
    %msg = new_message_with_text( text = |{ lines( lt_partner_data ) } records changed|
    severity = if_abap_behv_message=>severity-success )
  ) INTO TABLE reported-partner.
ENDMETHOD.


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

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

 

Actions

In the example above we used two actions, a normal "Action" and a "Static Action". The normal action is initially inactive and can only be used once one or more records in the list have been selected. The action is only performed on this record.

The second action is always active because it affects the entire object and is not dependent on a selected data record. The action is correspondingly different, because here we have to read all the keys ourselves from the database and are not handed them over.

 

Messages

Actions bring with them the possibility of returning corresponding messages to the user. In our example implementation, we printed a simple success message that generated a message toast that disappeared after a few seconds.

 

However, there is also the possibility of generating more messages here. If more messages are generated, then the form changes to a popup, if other types are used, the message is displayed differently or perhaps it has to be confirmed first.

 

Conclusion

Actions give the RAP object further possibilities to act on the data without making changes directly. The actions can be simple and change data or trigger complex actions such as reading data via an interface.