RAP - Ermittlung
Wie werden Daten im ABAP RESTful Programming Model automatisch abgeleitet und angereichert? Dieser Frage gehen wir in diesem Artikel nach.
Inhaltsverzeichnis
Die letzte Woche hatten wir uns mit der Validierung auseinandergesetzt und wie du damit dein Business Objekt sauber hältst. Diese Woche werden wir einmal auf die automatischen Ableitungen eingehen und wie du nicht alle Felder vom User befüllen lassen musst.
Allgemein
Eine Ermittlung kann Arbeit abnehmen und Felder mit Informationen befüllen, die sich vielleicht aus anderen Datenquellen ergeben. Oder es werden Informationen abgeleitet, wenn der Anwender vergisst sie zu befüllen. Eine Ermittlung kann einfach oder komplex sein, am Ende sorgt sie ebenfalls für die Vollständigkeit der Daten im Business Objekt.
Anlage
Legen wir im ersten Schritt eine Ermittlung in unserem Business Objekt an, dazu definieren wir sie in der Verhaltensdefinition und geben die entsprechenden Eigenschaften:
determination fillCurrency on modify { create; update; }
Hierbei steht "on modify" und "on save" zur Verfügung, die die Ermittlung unterschiedlich auslösen. "On Modify" löst jedes Mal aus, wenn sich die Daten ändern und der User etwas Neues in ein Feld eingibt. Hier sollten vor allem schnelle Ermittlung durchgeführt werden, die nicht so viel Performance verbrauchen. "On Save" wird erst beim Sichern der Daten in der Speichersequenz ausgelöst und eignet sich vor allem für performance-intensive Aufgaben. In der geschweiften Klammer, stehen wie bei der Validierung, Felder und Events zur Verfügung. Hier kann man noch entsprechend granular die Ermittlung anpassen.
Im Anschluss kannst du die Methode in der Klasse wieder mit STRG + 1 generieren lassen und musst diese nicht per Hand anlegen. Die Methodendefinition sieht nun wie folgt aus:
METHODS fillcurrency FOR DETERMINE ON MODIFY
IMPORTING keys FOR partner~fillcurrency.
Hinweis: Eine Ermittlung muss nur auf Ebene des Interfaces definiert werden, da sie jederzeit gilt und nicht in der Projektionsschicht nach außen gegeben werden muss und auch nicht kann.
Implementierung
Die Methodenschnittstelle ist sehr überschaubar und enthält weniger Parameter als bei den Validierungen. Wie immer werden die betroffenen Schlüssel übergeben, als Rückgabe steht uns nur die Tabelle für Meldungen zur Verfügung, falls während der Ableitung etwas schieflaufen sollte.
Entsprechend einfach gestaltet sich unsere Ableitung, wir Lesen die übergebenen Schlüssel und prüfen, ob das Feld PaymentCurrency befüllt ist. Ist dies nicht der Fall, dann setzen wir einen Defaultwert, damit das Feld nicht leer bleibt. Die Implementierung sieht dann wie folgt aus:
READ ENTITIES OF ZBS_I_RAPPartner IN LOCAL MODE
ENTITY Partner
FIELDS ( PaymentCurrency )
WITH CORRESPONDING #( keys )
RESULT DATA(lt_partner_data).
LOOP AT lt_partner_data INTO DATA(ls_partner) WHERE PaymentCurrency IS INITIAL.
MODIFY ENTITIES OF ZBS_I_RAPPartner IN LOCAL MODE
ENTITY Partner
UPDATE FIELDS ( PaymentCurrency )
WITH VALUE #( ( %tky = ls_partner-%tky PaymentCurrency = 'EUR' %control-paymentcurrency = if_abap_behv=>mk-on ) ).
ENDLOOP.
Hinweis: Ein Commit darf in diesem Fall nicht gesetzt werden, da wir uns in der Bearbeitung des Business Objekts befinden. Versuchst du es dennoch, erhältst du vom Compiler eine Fehlermeldung und das Aktivieren ist nicht möglich.
Test
Im nächsten Schritt testen wir die Ermittlung einmal in der App. Dazu legen wir einen neuen Datensatz an und befüllen den Schlüssel, sowie das Pflichtfeld Land. Das Pflichtfeld hatten wir im letzten Artikel zum Thema Validierung angelegt:
Nach dem Speichern erhalten wir nun das folgende Bild, die Währung wurde auf Default gesetzt und muss nicht mehr befüllt werden.
Fazit
Die Ermittlung ist eine gute Möglichkeit fehlende Informationen anzureichern, dabei kannst du schnelle und langsame Ermittlungen gut teilen und entsprechend oft der Performance aufrufen. Langsame Ermittlungen machen vor allem beim Speichern Sinn, denn eine Änderung wird nach jedem Feld aufgerufen.
