RAP - Grouping of Actions

Table of contents

• Introduction
• Factory Actions
• Current Status
• Implementation
• Grouping
• Create a group
• Standard Create
• Result
• Complete Example
• Conclusion

In this article, we will implement the Factory Actions and apply grouping in the UI to better visualize the options for the user.

 

Introduction

Currently, we have various options for creating new data records in our Sales App. In a previous article, we created two specific Factory Actions to create data records with pre-filled data and initial values. The standard "Create" action, which allows us to create a new data record, is still available. Therefore, we also have the requirement to reduce the number of creation options and present them more simply for the user.

 

Factory Actions

We use the Factory Action for creating new data records. We don't use the standard Create action, as this would only lead to an empty object page. Instead, we show the user mandatory information required for creating the new record in a new popup. This allows us to standardize the specific flow and the derivation of new information within the process. In our example, we want the user to only enter deviations as whole values or percentages.

 

Current Status

We had already defined the following actions in the behavior, but hadn't yet implemented them. The following definitions currently exist and are already displayed in the UI.

static factory action ( authorization : global ) createFixValue parameter ZBS_S_SAPopupFixValue [1];
static factory action ( authorization : global ) createPercent parameter ZBS_S_SAPopupPercent [1];

 

The actions are STATIC because no instance exists yet, and we use the PARAMETERS to display a popup with additional information. Since we create a new record with the actions, and the user should later work directly with it, our action returns exactly one record.

 

Implementation

The actual implementation is relatively simple, at least if you are familiar with the Entity Manipulation Language (EML). We process the passed keys and create a new entry for each record. We then pass the result from MAPPED to the return value of our implementation. We're using a LOOP here so that we can later implement corresponding derivations for other fields; you could also use a FOR statement. Which EML variant you use is entirely up to you.

LOOP AT keys INTO DATA(key).
  MODIFY ENTITIES OF zbs_r_sasale IN LOCAL MODE
         ENTITY SASale
         CREATE FROM VALUE #( ( %cid                        = key-%cid
                                %is_draft                   = key-%param-%is_draft
                                PartnerNumber               = key-%param-PartnerNumber
                                SalesDate                   = key-%param-SalesDate
                                DifferenceAmount            = key-%param-DifferenceAmount
                                DifferenceCurrency          = key-%param-DifferenceCurrency
                                %control-PartnerNumber      = if_abap_behv=>mk-on
                                %control-SalesDate          = if_abap_behv=>mk-on
                                %control-DifferenceAmount   = if_abap_behv=>mk-on
                                %control-DifferenceCurrency = if_abap_behv=>mk-on ) )
         MAPPED DATA(mapped_result).

  INSERT LINES OF mapped_result-sasale INTO TABLE mapped-sasale.
ENDLOOP.

 

It is important in the implementation that we return the result to the caller, otherwise navigation to the object page in Fiori will not work. We also have to pass the draft status to the create action, otherwise we will get an error message and the record will not be created correctly.

 

Grouping

In this section, we want to group the two factory actions. The user should then find the option to create a record under one item and no longer scattered across several buttons, where other actions might also be visible.

 

Create a group

Currently, both actions are displayed individually in the UI. Each action is included as a FOR_ACTION, has a reference to the RAP action, and a label for display.

@UI.lineItem: [
  { position: 10, type: #FOR_ACTION, dataAction: 'createFixValue', label: 'Create Fix Value' },
  { position: 20, type: #FOR_ACTION, dataAction: 'createPercent', label: 'Create Percent' }
]

 

To do this, we create a group of type FOR_ACTION_GROUP. We give it a description and an "actionGroupId". In the UI, the group will then bundle all assigned elements as a dropdown menu. As a final step, we need to assign the "actionGroupId" to the buttons. This adds a new line and two attributes to the UI annotations.

@UI.lineItem: [
  { position: 5, type: #FOR_ACTION_GROUP, label: 'Create', actionGroupId: 'idCreateGroup' },
  { position: 10, type: #FOR_ACTION, dataAction: 'createFixValue', label: 'Create Fix Value', actionGroupId: 'idCreateGroup' },
  { position: 20, type: #FOR_ACTION, dataAction: 'createPercent', label: 'Create Percent', actionGroupId: 'idCreateGroup' }
]

 

Looking at the application, the two actions are now available under a new "Create" item and can be selected via a dropdown menu.

 

Hint: In earlier Fiori releases, an error may occur where the new record is created, but no navigation to the object page takes place. This bug was fixed for Factory Actions in Grouping at the end of 2025.

 

Standard Create

We could now remove the Standard Create, however, we still need it, otherwise creation via EML would no longer work. Here we can change the Create to "Internal", which makes a Create via EML possible in LOCAL MODE, i.e., within the implementation of the RAP object. To do this, we adjust the behavior definition ZBS_R_SASale and set the Create of the entity SASale to "internal".

internal create;

 

However, we now have a problem with our augmentation at the Projection Layer level, as it goes beyond the Create action of our object and thus causes an error because the standard action is no longer available. In our case, the Factory Actions should only be shortcuts, and creating entities correctly should still be possible via CREATE, at least with EML. You should ensure stability primarily with appropriate validations. In this case, we use a UI annotation at the head level of the Metadata Extension. This allows us to disable the CREATE button at the UI level, so that the user primarily works with our two Factory Actions.

@UI.createHidden: true

 

Result

Let's take one last look at the result of the adjustment. We have hidden our Create Action, and the two Factory Actions are now available via group and dropdown menu. Once we've entered the data via the popup, we're taken directly to the new record for further editing, and the information has been transferred.

 

Basically, things like validations or hiding the other fields when one of the two variants is selected are still missing for complete implementation.

 

Complete Example

You can find the complete example in GitHub in the corresponding package for Sales. App. The changes from this article can be found in this Commit and you can follow the changes, plus the additional information.

 

Conclusion

Grouping actions initially tidies up the UI somewhat and shows the user how, for example, new scenarios can be created. A small implementation of UI annotations is now needed to finally clean up the UI.