ABAP in Praxis - Fiori Daten fehlerhaft
In diesem kleinen Praxisbeispiel schauen wir uns einen Fehlerfall in Fiori an. Hier werden die Daten im UI falsch angezeigt, obwohl alles sonst richtig zu sein scheint. Die Spur führt uns durch den RAP Stack in eine andere Richtung.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns einen Fehlerfall in Fiori an, der uns etwas Arbeit in der Analyse kostet und schließlich auf ein ganz anderes Problem führt.
Einleitung
Die Analyse von RAP Anwendungen ist im Alltag nicht immer so einfach, vor allem wenn man das ABAP RESTful Application Programming Model noch nicht so gut kennt. Die vielen Objekte und der große Stack bereiten da manchmal das ein oder andere Problem. In diesem Beispiel bauen wir eine kleine Anwendung, die auf den ersten Blick in Ordnung aussieht, doch dann zu einer längeren Fehleranalyse führt.
Vorbereitung
Damit du das Beispiel bei dir nachvollziehen kannst, haben wir dir ein kleines Git-Repsitory auf GitHub angelegt, damit hast du eine Vorlage für alle Objekte bzw. kannst dir den kompletten Fall in dein System ziehen. Nachdem die Komponenten installiert wurden, musst du noch die ausführbare Klasse ZCL_BS_DEMO_EXAMPLE_FIORI_DATA starten, damit Daten in den Tabellen angelegt werden.
In dem Repository sind ein paar Tabellen für unser Datenmodell, hierbei verwenden wir einen Beleg, welcher Positionen hat und zu bestimmten Positionen können dann Notizen angelegt werden. Die Daten wollen wir kombinieren, da der Fachbereich sie gern nebeneinander sehen möchte, ähnlich wie mit im klassischen ALV.
Sonst findest du die modellierten Core Data Services, di dann den Report erzeugen. Wir verwenden wir kein Verhalten, da es sich rein um einen Anzeigereport handeln soll.
Aufgabe
Der Fachbereich hat nun unsere Anwendung getestet und wollte den Report ausführen, dabei kam es zu einem merkwürdigen Ergebnis in der Anzeige. Wir erhalten einen entsprechenden Screenshot der Daten, es wurden alle Daten der Datenbank ohne Selektion angezeigt. Scheinbar wiederholen sich einzelne Positionen immer wieder.
Wir führen eine erste Analyse durch und schauen uns als Entwickler direkt die Daten des Core Data Services "ZBS_C_DMOExFioReport" an. So weit sieht erst einmal alles in Ordnung aus, die Daten werden vollständig geladen und es sind keine Fehler zu erkennen. Es wird auch die gleiche Anzahl an Datensätzen gefunden und ans UI übergeben.
Nun zu deiner Aufgabe. Dir steht der Service und die Fiori Elements Anwendung zur Verfügung und du solltest nun mit der Analyse der Anwendung beginnen. Dabei sollst du den Fehler finden, der zum Schiefstand im UI führt und diesen beheben. Dazu stehen dir alle Werkzeuge, wie der Browser und die ABAP Development Tools, zur Verfügung.
Hinweis: Im nächsten Abschnitt werden wir auf die Lösung eingehen, wenn du die Aufgabe erst einmal selbstständig machen möchtest, solltest du hier pausieren.
Lösung
Schauen wir uns nun einmal verschiedene Punkte an und versuchen einen Weg zur Lösung zu finden. Dabei werden wir nicht immer den korrekten Weg gehen, sondern uns verschiedene Methoden anschauen, die vielleicht zu einer Lösung führen.
Request
Schauen wir uns dazu also erst einmal den Request an, der Richtung Backend geht und was wir als Ergebnis erhalten. Dazu kannst du im Browser die Konsole öffnen und im Netzwerk Tab schauen. Wenn du über den "Go" Button die Selektion startest, dann werden vom Browser verschiedene Anfragen geschickt, die hier auftauchen.
Für uns ist der $batch Request interessant, da damit die Anfragen in einem Batch ans Backend geschickt werden. Schauen wir uns dort den Reiter "Payload" an, finden wir die verschiedenen Anfragen. In diesem Fall wird ein GET gegen das Reporting durchgeführt und neben der Standard Pagination keine weiteren Daten eingeschränkt.
Im Repsonse finden wir die Antwort des Systems und können den JSON String mit der Struktur extrahieren, um uns diesen anzuschauen und die Daten zu prüfen.
Prüfen wir die Daten, dann ist alles in Ordnung. Es werden die unterschiedlichen Positionen geladen und miteinander verknüpft. So weit ist damit die Abfrage in Ordnung und wir erhalten das gleiche Ergebnis, wie wir auch schon im Core Data Service gesehen haben.
Da wir die Daten korrekt erhalten, wäre die nächste Schlussfolgerung eigentlich, dass die Aufbereitung im UI zu einem Fehler führt und wir deshalb nicht die korrekten Daten sehen. Grundsätzlich würde ich hier auch recht geben, allerdings handelt es sich hier um reinen Fiori Elements Standard und wir haben keinerlei Anpassungen gemacht. Nehmen wir eine zweite Anwendung zum Vergleich, werden dort die Daten korrekt angezeigt.
Filter
Probieren wir noch einmal mit dem Filter in der Anwendung. Wir erhalten alle Daten korrekt aus dem Backend geliefert, was ist, wenn wir einmal einen Beleg und eine Position sehen wollen, die nicht sichtbar ist? Tragen wir den Filter ein, dann wird die Position korrekt geladen. Allerdings ist die Notiz im hinteren Bereich immer noch nicht korrekt.
Langsam scheint sich ein Bild etwas klarer abzuzeichnen. Irgendwie hat das System Probleme, die richtigen Datensätze zuzuordnen. Für eine korrekte Zuordnung wäre daher wichtig, dass die Schlüssel sauber definiert sind.
Schlüssel
Bereits in der Aufgabenstellung haben wir uns den Core Data Service und das Ergebnis angeschaut, dort sieht alles korrekt aus. Prüfen wir also noch einmal die definierten Schlüssel in der Modellierung und schauen uns den Consumption View an.
Sieht erst einmal nicht so auffällig aus, keine Warnungen und keine Hinweise vom System. Gehen wir dann allerdings noch eine Ebene nach unten und führen auf den Views die Prüfung aus, dann werden wir mit einigen Warnungen überrascht.
Korrektur
Grundsätzlich könnte dir jemand so einen View zur Verfügung stellen und du würdest am Anfang nicht einmal das Problem merken. Was wir nun tun müssen, die i zusätzlichen Schlüssel zu definieren. Immer wenn wir Felder einer "One to Many" Assoziation übernehmen, sollten wir auch den Schlüssel anpassen. Daher überarbeiten wir die Felder für ZBS_I_DMOExFioReport.
define root view entity ZBS_I_DMOExFioReport
as select from ZBS_I_DMOExFioDocument
{
key DocumentId,
key _Position.PositionNumber,
key _Position._Notes.NoteId,
CreationDate,
_Country._Text[ Language = $session.system_language ].CountryName,
_Position.Customer,
_Position._Notes.Description
}
Und damit wir die beiden Views aktivieren können, müssen wir ebenfalls noch ZBS_C_DMOExFioReport mit der neuen Logik für die Schlüsselfelder nachziehen.
define root view entity ZBS_C_DMOExFioReport
provider contract transactional_query
as projection on ZBS_I_DMOExFioReport
{
key DocumentId,
key PositionNumber,
key NoteId,
CreationDate,
CountryName,
Customer,
Description
}
Nach der Aktivierung der beiden Views, können wir uns noch einmal den Preview anschauen. Die Daten werden nun korrekt in der Fiori Elements Applikation angezeigt.
Zusammenfassung
Das Problem war nicht sofort erkennbar und war eigentlich eine Folgeproblem aus der Modellierung der Datensätze am Anfang unserer Datenbeschaffung. Da wir mit dem Beleg eingestiegen sind, war dies von Anfang an der Primärschlüssel für uns. Allerdings mit jeder Ebene an Daten, die wir zusätzlich im View anzeigen, bringen wir weitere Zeilen in die Anzeige, unsere Daten vervielfachen sich. Hier ist es wichtig, ebenfalls den Schlüssel zu erweitern, um über diesen eine Eindeutigkeit herzustellen.
Im Data Preview werden alle Daten der Datenbank angezeigt, allerdings erfolgt hier kein Hinweis, ob der Schlüssel eindeutig ist. Hier müssen wir im Nachgang uns noch einmal die Definition anschauen und abgleichen. Ein Hinweis, eine Ausnahme oder ein Dump bei Schlüsselverletzung wäre wahrscheinlich sehr hilfreich bei der Fehleranalyse.
Fazit
An dem Beispiel wollten wir zeigen, dass das Problem vielleicht nicht immer aus der erwarteten Richtung kommt, sondern es manchmal andere Ursachen gibt. Weiterhin wollten wir dir verschiedene Methodiken zur Herangehensweise zeigen und wie du vielleicht noch in eine Datenanalyse einsteigen kannst.
