RAP - Gruppierung von Aktionen
Wie kannst du eigentlich deine verschiedenen Aktion in RAP unter einem Button gruppieren, vor allem wenn die Aktionen relativ ähnlich sind. In diesem Artikel schauen wir uns die Details zur Umsetzung mit ABAP an.
Inhaltsverzeichnis
In diesem Artikel werden wir die Factory Actions implementieren und im UI eine Gruppierung anwenden, um dem Anwender die Möglichkeiten besser zu visualisieren.
Einleitung
Aktuell haben wir verschiedene Optionen zur Anlage von neuen Datensätzen in unserer Sales App. Dabei haben wir in einem älteren Artikel zwei spezifische Factory Actions angelegt, um Datensätze mit einer Vorbefüllung und ersten Werten zu erstellen. Daneben steht weiterhin die Standard "Create" Aktion, über die wir einen neuen Datensatz anlegen können. Deshalb haben wir auch die Anforderung die Anlageoptionen zu reduzieren und für den Anwender einfacher darzustellen.
Factory Actions
Die Factory Action verwenden wir für die Anlage von neuen Datensätzen. Dabei verwenden wir nicht den Standard Create, da wir damit nur auf einer leeren Object Page landen, sondern zeigen dem Anwender Pflichtinformationen in einem neuen Popup die wir für die Neuanlage benötigen. Damit können wir den spezifischen Flow und die Ableitung von neuen Informationen im Prozess vereinheitlichen. In unserem Beispiel wollen wir, dass der Anwender nur Abweichungen als ganze Werte oder Prozent eingibt.
Aktueller Stand
Dazu hatten wir bereits im Verhalten die folgenden Actions definiert, aber noch nicht implementiert. Folgende Definitionen existieren aktuell und sind bereits im UI eingeblendet.
static factory action ( authorization : global ) createFixValue parameter ZBS_S_SAPopupFixValue [1];
static factory action ( authorization : global ) createPercent parameter ZBS_S_SAPopupPercent [1];
Die Aktionen sind STATIC, da noch keine Instanz besteht und die PARAMETER verwenden wir, damit ein Popup angezeigt wird, wo zusätzliche Informationen angezeigt werden. Da wir mit den Aktionen einen neuen Datensatz anlegen und der User später direkt damit arbeiten soll, gibt unsere Action genau einen Datensatz zurück.
Implementierung
Die eigentliche Implementierung ist relativ einfach gemacht, zumindest wenn du dich mit der Entity Manipulation Language (EML) auskennst. Dazu verarbeiten wir die übergebenen Schlüssel und legen pro Datensatz einen neuen Eintrag an. Das Ergebnis aus MAPPED übergeben wir dann an die Rückgabe unserer Implementierung. Wir verwenden hier einen LOOP, um später vielleicht noch entsprechende Ableitungen für andere Felder implementieren zu können, grundsätzlich könntest du auch mit einer FOR-Anweisung arbeiten. Welche EML Variante du nutzt, ist dir überlassen.
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.
Wichtig ist in der Implementierung, dass wir das Ergebnis an den Aufrufer zurückgeben, da sonst die Navigation auf die Object Page in Fiori nicht funktioniert. Ebenfalls müssen wir den Draft Status mit an den Create übergeben, da wir sonst eine Fehlermeldung erhalten und der Datensatz nicht korrekt angelegt wird.
Gruppierung
In diesem Abschnitt wollen wir die Gruppierung der beiden Factory Actions durchführen. Dabei soll der User unter einem Punkt die Möglichkeit der Anlage finden und nicht mehr verstreut über mehrere Buttons, wo vielleicht auch noch andere Aktionen sichtbar sind.
Gruppe bilden
Im Moment sind beide Aktionen einzeln im UI eingeblendet. Jede Aktion ist als FOR_ACTION eingebunden, hat eine Referenz zur RAP Aktion und ein Label für die Anzeige.
@UI.lineItem: [
{ position: 10, type: #FOR_ACTION, dataAction: 'createFixValue', label: 'Create Fix Value' },
{ position: 20, type: #FOR_ACTION, dataAction: 'createPercent', label: 'Create Percent' }
]
Dazu erstellen wir eine Gruppe mit dem Typ FOR_ACTION_GROUP. Dieser geben wir eine Beschreibung und eine "actionGroupId". Die Gruppe wird im UI dann alle zugeordneten Elemente als Dropdown bündeln. Als letzten Schritt müssen wir dann die "actionGroupId" den Buttons zuordnen. Damit haben wir insgesamt eine neue Zeile und zwei Attribute in den UI-Annotationen ergänzt.
@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' }
]
Schauen wir uns die Anwendung an, dann sind die beiden Aktionen nun unter einem neuen Punkt "Create" verfügbar und können per Dropdown ausgewählt werden.
Hinweis: In niedrigeren Fiori Releases kann es zu einem Fehler kommen, dass der neue Datensatz angelegt wird, aber keine Navigation auf die Object Page passiert. Dieser Fehler wurde für Factory Actions im Grouping Ende 2025 korrigiert.
Standard Create
Damit können wir nun den Standard Create entfernen, allerdings benötigen wir diesen weiterhin, da sonst die Anlage per EML nicht mehr funktioniert. Hier können wir den Create auf "Internal" umstellen, damit ist ein Create per EML im LOCAL MODE möglich, also innerhalb der Implementierung zum RAP Objekt. Dazu passen wir die Verhaltensdefinition ZBS_R_SASale an und setzen den Create der Entität SASale auf "internal".
internal create;
Allerdings haben wir nun ein Problem mit unserer Augmentation auf Ebene des Projection Layer, da diese über die Create Action unseres Objekts geht und damit einen Fehler verursacht, da die Standard Aktion nicht mehr zur Verfügung steht. In unserem Fall sollen die Factory Actions nur Shortcuts sein und eine korrekte Anlage von Entitäten weiterhin über CREATE möglich sein, zumindest mit EML. Die Stabilität solltest du vor allem mit den passenden Validierungen sicherstellen. In diesem Fall verwenden wir eine UI-Annotation auf Kopfebene der Metadata Extension. Damit können wir den CREATE Button auf UI-Ebene deaktivieren, damit der User vor allem mit unseren beiden Factory Actions arbeitet.
@UI.createHidden: true
Ergebnis
Schauen wir uns nun final noch einmal das Ergebnis der Anpassung an. Dabei haben wir unsere Create Action ausgeblendet und die beiden Factory Actions sind nun per Gruppe und Dropdown verfügbar. Wenn wir die Daten über das Popup eingegeben haben, landen wir direkt zur weiteren Bearbeitung im neuen Datensatz und die Informationen wurden übernommen.
Grundsätzlich fehlen zur vollständigen Implementierung noch Dinge wie die Validierungen oder das zum Beispiel die anderen Felder dann ausgeblendet werden, wenn entsprechend eine der beiden Varianten ausgewählt wurde.
Vollständiges Beispiel
Das vollständige Beispiel findest du in GitHub im entsprechenden Paket für die Sales App. Die Änderungen aus diesem Artikel findest du in diesem Commit und kannst damit die Änderungen, plus die Zusatzinformationen, nachvollziehen.
Fazit
Die Gruppierung von Aktionen räumt im ersten Schritt einmal das UI etwas auf und zeigt dem User, wie zum Beispiel neue Szenarien angelegt werden können. Dafür ist nun eine kleine Implementierung von UI-Annotationen nötig, um dann auch final das UI zu bereinigen.
