This is a test message to test the length of the message box.
Login
ABAP RAP Action
Created by Software-Heroes

RAP - Action

1387

In this article, we'll take a look at actions, how they are structured, and what they actually do with the RAP Business Object.

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.


Included topics:
RAPBTPAction
Comments (0)



And further ...

Are you satisfied with the content of the article? We post new content in the ABAP area every Friday and irregularly in all other areas. Take a look at our tools and apps, we provide them free of charge.


RAP - Deep Action in OData v4

Category - ABAP

In this article we will look at actions with deep structures, how we can create them and pass data to an API endpoint.

05/24/2024

BTP - Connect On-Premise (Consumption Model v2)

Category - ABAP

In this article we want to provide another update on the connection of on-premise systems and how this is done with a communication arrangement.

12/15/2023

RAP - Show app count (Tile)

Category - ABAP

This example is about displaying a counter on the tile of a Fiori Elements application and how such a thing can be implemented.

10/06/2023

RAP - Generator (Fiori)

Category - ABAP

In this article we will look at the more complex RAP generator as a Fiori Elements application and what advantages you have with it.

09/15/2023

RAP - Generator (ADT)

Category - ABAP

Today, let's take a look at the RAP Generator, which is already integrated into ABAP Development Tools, and how you can use it to easily build new RAP apps.

09/08/2023