RAP - Augmentation
In diesem Artikel stellen wir unser Datenmodell der RAP Anwendung um und ändern die Form wie wir mit den Texten umgehen. Dabei verwenden wir Augmentation, um unser Datenmodell trotzdem vollständig zu halten.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns das Handling der Sprachen an und verwenden Augmentation, um weitere Sprachen per API anzureichern.
Einleitung
Dabei verwenden wir die erstellte Sales App, um eine weitere Anforderung zur Verfügung zu stellen. Aktuell haben wir eine Entität mit einer Information an unserem RAP Objekt. Dabei handelt es sich um ein Feld, welches eigentlich nur in die verschiedenen unterstützten Sprachen übersetzt wird. Aktuell soll der Anwender das aktuelle Feld befüllen und sich nicht auch um die anderen Sprachen kümmern.
Umbau
Um die Anforderung umsetzen zu können, müssen wir die Anwendung etwas umbauen. Dazu muss der Sprachschlüssel mit in den Schlüssel des Datenmodells.
Tabelle
Da nun der Sprachschlüssel ebenfalls Schlüsselfeld ist und eine Sprache nur einmal vorhanden sein soll, können wir die PARENT_UUID und den Sprachschlüssel als eindeutigen Schlüssel definieren. Die eigene UUID benötigen wir damit nicht mehr, da diese sonst die Möglichkeit eröffnet mehrere Einträge in Deutsch zu erzeugen. Die Tabelle würde damit wie folgt aussehen.
define table zbs_sainfo {
key client : abap.clnt not null;
key parent_uuid : sysuuid_x16 not null;
key language : spras not null;
text000 : zbs_demo_sa_text;
}
Möchtest du nun die Tabelle aktivieren, dann erhältst du mit großer Wahrscheinlichkeit eine DDIC Meldung. Da wir den Schlüssel geändert haben und bereits Einträge in der Tabelle sind, müssen wir eine Tabellenumsetzung anstoßen.
Über STRG + 1 rufen wir den Quick Fix auf und erhalten die entsprechenden Optionen, um die Tabelle anzupassen. Da wir später noch einmal die Einträge aus unseren Testdaten übernehmen können, löschen wir erst einmal die vorhandenen Daten mit der Option "Adjust and activate database table, delete data".
Core Data Service
Da wir die Tabelle angepasst haben, können wir sie aber noch nicht komplett aktivieren, da nun auch das Datenmodell über die Core Data Services gerade gezogen werden muss. Sonst erhalten wir beim Aktivieren immer noch entsprechende Fehlermeldungen. Dazu ändern wir den Interface View ZBS_R_SAINFO, entfernen das alte Schlüsselfeld und ergänzen die KEY Informationen. Zusätzlich müssen wir noch die Assoziation anpassen, da sich der Schlüssel geändert hat.
define view entity ZBS_R_SAINFO
as select from zbs_sainfo as SAInfo
association to parent ZBS_R_SASALE as _SASale on $projection.ParentUUID = _SASale.UUID
{
key parent_uuid as ParentUUID,
key language as Language,
text000 as TextInformation,
_SASale
}
Zum Abschluss passen wir noch im Datenmodell den Consumption View ZBS_C_SAINFO an, wie bereits zuvor die Schlüsselfelder und die Assoziation.
define view entity ZBS_C_SAINFO
as projection on ZBS_R_SAINFO
association of exact one to one ZBS_R_SAINFO as _BaseEntity on $projection.ParentUUID = _BaseEntity.ParentUUID
{
key ParentUUID,
key Language,
TextInformation,
_SASale : redirected to parent ZBS_C_SASALE,
_BaseEntity
}
Zum Abschluss können wir nun alle drei Objekte gleichzeitig aktivieren und haben erst einmal wieder ein konsistentes Datenmodell.
Verhalten
Damit wir wieder unser RAP Objekt und die Fiori Elements Anwendung nutzen können, müssen wir noch einen Schiefstand im Verhalten geradeziehen. In der Verhaltesdefinition von ZBS_R_SASale gibt es nun einige Fehler, die wir korrigieren müssen:
- Schlüssel - Der Schlüssel hat sich geändert und ein Feld wurde entfernt. Daher entfernen wir alle Aufrufe von UUID, sowie das Mapping.
- Darfttabelle - Per Quick Fix lassen wir dann noch einmal die Drafttabelle neu generieren, um so die letzten Fehler zu beseitigen.
- Sprache - Die Sprache setzen wir dann noch auf "readonly : update", da wir den Schlüssel beim Update nicht mehr ändern können.
Damit können wir wieder die Verhaltensdefinition aktivieren und du kannst die Anwendung wieder normal benutzen. Zusätzlich solltest du noch einmal die Klasse ZCL_BS_DEMO_RAP_SALES_DATA ausführen, damit wir wieder Texte in unserer Tabelle haben. Die Ausführung funktioniert ohne weitere Änderung der Daten oder Logik.
Localized
Mit den Änderungen können wir nun den sprachabhängigen Text in unser UI übernehmen. Dazu erweitern wir den Core Data Service ZBS_C_SASale. Die Änderung ist nicht möglich, wenn "Language" kein Schlüsselfeld ist.
_SAInfo.TextInformation : localized,
Damit wir nun gleich das Feld im UI haben, passen wir noch die gleichnamige Metadata Extension an, nehmen das Feld auf und setzen einige UI Annotationen. Das Feld ordnen wir der Gruppe "GENERAL" zu.
@UI.identification: [ { position: 160 , qualifier: 'GENERAL' } ]
@EndUserText.label: 'Text Information'
TextInformation;
Laden wir dann das UI neu und gehen in den Änderungsmodus, dann ist zum einen das Feld nun in der aktuellen Anmeldesprache vorhanden und zum anderen im Moment nicht eingabebereit. Damit können wir zumindest die sprachabhänge Information einfach in der aktuellen Sprache einbetten.
Augmentation
Damit wir nun aber auch den Text ändern können, haben wir die Möglichkeit mit Augmentation zu arbeiten. Damit können wir Felder im Consumption View änderbar machen, die nicht im Datenmodell sind oder Einfluss auf andere Felder und Entitäten haben.
Verhaltensdefinition
Dazu müssen wir das Verhalten anpassen und dieses Mal in der Projektion ZBS_C_SASale. Hier ergänzen wir jeweils an der Create und Update Methode das AUGMENT Schlüsselwort.
use create (augment);
use update (augment);
Dann öffnen wir das Feld für die Anpassung der Daten. Beide Änderungen passieren auf der ROOT Entität, da wir das Feld auf diese Ebene gehoben haben und dort editieren.
field (modify) TextInformation;
Verhaltensimplementierung
Bist du auch jemand, der sich gefragt hat, wiese es eine Verhaltensimplementierung auf Consumption bzw. Projectionebene gibt? Genau für solche Fälle ist die Implementierung gedacht. Hast du die Definition gespeichert, legst du per STRG + 1 (Quick Fix) die beiden Methoden an.
CLASS lhc_sasale DEFINITION INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
METHODS augment_create FOR MODIFY
IMPORTING entities FOR CREATE SASale.
METHODS augment_update FOR MODIFY
IMPORTING entities FOR UPDATE SASale.
ENDCLASS.
CLASS lhc_sasale IMPLEMENTATION.
METHOD augment_create.
ENDMETHOD.
METHOD augment_update.
ENDMETHOD.
ENDCLASS.
Die speziellen Methoden werden aufgerufen, bevor die eigentliche Implementierung des RAP BOs durchlaufen wird. Damit können wir Operationen durchführen, die den Puffer des RAP Objekts verändern. Die CREATE Methode wird aufgerufen, wenn wir in der Anwendung einen neuen Datensatz anlegen. Speichern wir dann einen Datensatz, egal ob neu oder alt, dann wird unsere UPDATE Methode aufgerufen.
Create
Wenn wir einen neuen Datensatz anlegen, dann wollen wir alle unterstützten Sprachen einfügen, auch wenn der Text erst einmal leer ist. Das Statement ist erst einmal etwas komplexer aufgebaut. Wir verwenden dabei den Zusatz MODIFY AUGMENTING ENTITIES um den Modify aufzurufen. Hier gehen wir zur Anlage direkt über den Root Knoten auf die Info Entität. Dort befüllen wir die Referenz und den Draft Status. An das %TARGET werden die eigentlichen Daten gehangen. Hier ist es wichtig, dass wir ebenfalls den richtigen Draft Status übergeben, da es sonst zu einem Abbruch in der Verarbeitung kommt.
LOOP AT entities INTO DATA(entity).
DATA(texts) = get_supported_languages( ).
MODIFY AUGMENTING ENTITIES OF zbs_r_sasale
ENTITY SASale
CREATE BY \_SAInfo AUTO FILL CID FIELDS ( Language )
WITH VALUE #( ( %cid_ref = entity-%cid
%is_draft = entity-%is_draft
%target = VALUE #( FOR translated_text IN texts
( %is_draft = entity-%is_draft
Language = translated_text-language ) ) ) ).
ENDLOOP.
Update
Beim Update wollen wir dann den neuen Text in die Tabelle übernehmen. Hier haben wir aktuell zwei Szenarien, wir haben alte Datensätze, wo noch keine Spracheinträge sind und neue Datensätze, die ihn haben. Daher müssen wir zuerst per EML den aktuellen Puffer lesen.
READ ENTITIES OF zbs_r_sasale
ENTITY SASale BY \_SAInfo
FROM CORRESPONDING #( entities )
RESULT DATA(found_languages).
Dann verarbeiten wir die eigentlichen Datensätze. Dazu holen wir uns erst die Sprachen und deren Übersetzung. Zur Übersetzung erfährst du im nächsten Abschnitt mehr. Dann nehmen wir jeden Satz aus der Übersetzung und prüfen, ob die Sprache bereits als Zeile vorhanden ist. Ist das der Fall, dann machen wir einen UPDATE, sonst legen wir per CREATE den Datensatz neu an.
LOOP AT entities INTO DATA(entity).
LOOP AT translate_text( entity-TextInformation ) INTO DATA(text).
IF line_exists( found_languages[ ParentUUID = entity-uuid
Language = text-language ] ).
MODIFY AUGMENTING ENTITIES OF zbs_r_sasale
ENTITY SAInfo
UPDATE FIELDS ( TextInformation )
WITH VALUE #( ( %tky-%is_draft = entity-%tky-%is_draft
%tky-parentuuid = entity-%tky-uuid
%tky-Language = text-language
TextInformation = text-textinformation ) ).
ELSE.
MODIFY AUGMENTING ENTITIES OF zbs_r_sasale
ENTITY SASale
CREATE BY \_SAInfo AUTO FILL CID FIELDS ( Language TextInformation )
WITH VALUE #( ( %tky = CORRESPONDING #( entity-%tky )
%target = VALUE #( ( %is_draft = entity-%is_draft
Language = text-language
TextInformation = text-textinformation ) ) ) ).
ENDIF.
ENDLOOP.
ENDLOOP.
Übersetzung
Oben nutzen wir bereits eine Übersetzung, die automatisch zur eingegebenen Sprache die entsprechenden Übersetzungen in der anderen Sprache ergänzt. Dafür nutzen wir die Google Translate API, die wir bereits in einem älteren Projekt angebunden haben. Dazu lassen wir uns die unterstützen Sprache zurückgeben und bereiten die Übersetzung vor.
result = get_supported_languages( ).
DATA(translate) = NEW zcl_bs_demo_google_integration( ).
Dann befüllen wir die eigentliche Übersetzung. Handelt es sich um die aktuelle Sprache, übernehmen wir den Text einfach in die Tabelle, ansonsten rufen wir die API auf. Da wir intern mit SPRAS arbeiten, also dem einstelligen Sprachcode, müssen wir diesen zuerst ins ISO Format konvertieren. Dazu verwenden wir die XCO Bibliothek, um an den passenden ISO Code zu kommen. Die API übersetzt dann den Text und wir hängen das Ergebnis an die Tabelle.
LOOP AT result REFERENCE INTO DATA(line).
IF line->language = sy-langu.
line->textinformation = text.
ELSE.
DATA(iso_language) = xco_cp=>language( line->language )->as( xco_cp_language=>format->iso_639 ).
line->textinformation = translate->translate_text( id_text = CONV #( text )
id_target_language = to_lower( iso_language ) ).
ENDIF.
ENDLOOP.
Test
Testen wir nun einmal die Oberfläche und die Funktion. Dazu legen wir einen neuen Datensatz über Create an. Schauen wir uns die Entität für die Informationen an, dann wurden bereits die Sprachen angelegt. Der Text ist noch leer, da wir keine Eingaben gemacht haben.
Das Feld ist editierbar und wir können einen Text in Englisch eintragen, da wir in dieser Sprache am System angemeldet sind.
Speichern wir nun den Datensatz und schauen in den unteren Bereich auf unsere Entität, dann wurden nun auch alle Übersetzungen zu unserem Text angelegt. Die Augmentation funktioniert so weit.
Vollständiges Beispiel
In unserem GitHub Repository findest du das vollständige Beispiel und auch den Umbau der Anwendung. Dazu am besten in diesem Commit nachschauen, wo alle Änderungen dokumentiert sind.
Fazit
Mit dem LOCALIZED kannst du übersetzbare Elemente nach oben holen und bekommst den Text in der aktuellen Sprache angezeigt. Die Augmentation ist eine sinnvolle Ergänzung, wenn du nicht editierbare Felder hast, die aber zum Beispiel auch Auswirkungen auf andere Entitäten oder Inhalte haben. So können wir nach Eingabe eines Textes per API auch direkt die Übersetzung in die verschiedenen Sprachen machen.
Quelle:
SAP Help - RAP augment
SAP Help - Operation Augmentation
