Fiori für ABAP - Navigation Parameters
Was ist eigentlich, wenn zu viele Parameter bei der Navigation übergeben werden und die Ziel-App nicht mehr das korrekte Ergebnis anzeigt? Eine mögliche Lösung können Navigation Parameters sein, die wir uns einmal im Detail anschauen.
Inhaltsverzeichnis
In diesem Artikel gehen wir im Detail auf die App zu App Navigation ein und schauen uns die Wirkung der Parameter in der Ziel App an.
Einleitung
Bei der App-zu-App-Navigation ist eine besondere Herausforderung, die richtigen Parameter zu übergeben und damit in der Ziel-App das richtige Ergebnis zu erzeugen. Dies kann von der Filterung einzelner Einträge bis zur Navigation auf die Object Page reichen. Hierbei gibt es viele Faktoren, die einen Einfluss darauf haben, wie zum Beispiel die Quellparameter in unserer aufrufenden App und das Mapping in der Ziel-App. Das sind die verschiedenen Bestandteile, die wir uns einmal im Detail anschauen sollten, um in Zukunft immer die richtige Navigation zu erhalten.
Vorbereitung
Bevor wir in das Beispiel eintauchen, sollten wir eine kleine Ziel-App vorbereiten, die wir ansteuern können, um dort zu testen, wie die verschiedenen Parameter auf die App wirken. Ebenso brauchen wir die aufrufende Konfiguration, die wir in einer anderen App definieren.
Navigationsziel
Deshalb brauchen wir zuerst einmal eine Ziel-App, die für unsere Navigation dient. Hierzu definieren wir uns eine kleine Anwendung bzw. eine Projection auf unserer Sales App. Dabei benennen wir einige wichtige Felder um, um dann auch das Thema Parameter-Mapping und Ziel-Mapping aussteuern zu können, in diesem Fall die UUID, die Partnernummer und die Währung. Darauf generieren wir dann einen Service und führen ein Deployment der Anwendung durch, da wir dies zum Testen der Navigation benötigen.
define root view entity ZBS_C_NavigationTarget
provider contract transactional_query
as projection on ZBS_R_SASALE
{
key UUID as UniqueKey,
PartnerNumber as Partner,
SalesDate,
SalesVolume,
SalesCurrency as Currency,
DifferenceAmount,
DifferenceCurrency,
DifferenceQuantity,
DifferenceUnit,
SaleComment,
LoggingId,
LocalCreatedBy,
LocalCreatedAt,
LocalLastChangedBy,
LocalLastChangedAt,
LastChangedAt
}
Weiterhin legen wir ein Launchpad App Descriptor Item an und lassen den Navigationsteil erst einmal im Default. Hier legen wir uns zusätzlich eine Kachel an, die wir dann auch ins Launchpad einbinden und einer Rolle zuweisen, damit wir die App auch im Launchpad sehen. Weitere Details zu dieser kleinen Anwendung findest du im GitHub Repository unten verlinkt.
Navigation
In unserer Sales App passen wir dann die Navigation auf der Partnernummer an und definieren hier das neue Navigationsziel, unsere gerade erstellte App. Diese arbeitet als Display-App, das heißt, für sie ist auch die Action als "display" definiert. Wenn wir also das nächste Mal die App aufrufen und über die Partnernummer navigieren, landen wir auf unserer neuen Navigations-App und können damit die Navigation zwischen den beiden Anwendungen im Detial testen.
@UI.lineItem: [
{ position: 20,
type: #WITH_INTENT_BASED_NAVIGATION,
semanticObject: 'ZBS_NAV_TARGET',
semanticObjectAction: 'display'
}
]
PartnerNumber;
Problem
Wo liegt nun das eigentliche Problem bei der Navigation? Schauen wir uns das einmal in einer Probe-Navigation an: Wir gehen in unsere App und klicken auf einen Partner. Dabei erfolgt die Navigation auf die neue App als Ziel-App, und es sind bereits Filter für die Selektion vorselektiert. Allerdings fehlen hier Informationen wie der Partner oder die Währung. Da wir diese in der Ziel-App in neue Felder gepackt haben, werden diese nicht automatisch gemappt und befüllt. Allerdings sind weitere Informationen befüllt, die wir so nicht erwartet hätten, wie das Datum oder das Verkaufsvolumen.
Passen wir nun einmal die URL an, finden wir hinter der eigentlichen Navigation die verschiedenen Parameter, die übergeben werden, um die Navigation durchzuführen. Dabei werden nicht nur die Schlüssel übergeben, sondern alle Parameter, die auf dieser Zeile definiert wurden, wie zum Beispiel auch das Icon. Die Partnernummer ist vorhanden, nur unter dem anderen Namen, und weitere Informationen wie die Criticality, die dort definiert wurde. All diese Informationen werden nun genommen und in der Ziel-App auf die Felder der Selektion gemappt. Dadurch entsteht dieses Bild in der Anzeige und die gesetzte Filter (Werte wurden in neue Zeilen getrennt).
Allerdings führt nun dieses Verhalten zu Problemen bei der Navigation. So werden zum Beispiel auch Datumsfelder gefüllt, die wir übergeben, die aber in unserer Ziel-App komplett unterschiedlich sein können. Ebenso werden Schlüsselfelder nicht gemappt, wie wir sie benötigen. Hierbei kommen nun die Navigation Parameters zum Einsatz, die wir benötigen, um die richtigen Zielparameter für uns zu definieren.
Additional Handling
Im ersten Schritt schauen wir uns die Einstellung "Additional Parameter Handling" an. Dieser wird über den Navigation Parameters gesetzt und hat drei Einstellungen zur Verfügung.
Damit der Parameter greift, sollten wir ein erstes Paar Navigation Parameters definieren. Dazu tragen wir den Parameternamen "PartnerNumber" ein, das ist der Parameter, den wir aus unserer Quell-App erhalten. Und den Zielparameter in unserer aktuellen Anwendung, also den "Partner". Weitere Einstellungen sind hier nicht nötig.
Ignored
Setzen wir die Einstellung auf IGNORED, werden alle eingehenden Parameter außer unserem definierten Mapping ignoriert. Im Ergebnis erhalten wir den gefilterten Partner, den wir übergeben bekommen haben. Alle anderen Filter sind dahingehend aber leer.
Allowed
Bei ALLOWED werden erst unsere eingestellten Mappings vorgenommen, sodass der Partner zum Beispiel befüllt ist, und dann werden alle zusätzlichen Parameter, die übergeben werden, auch noch gemappt. In diesem Fall sind auch noch weitere Kriterien befüllt, sodass die Selektion weitere Einträge einschränkt und wir nur noch einen Eintrag erhalten.
Not Allowed
Bei der dritten Einstellung NOT ALLOWED bekommen wir direkt eine Fehlermeldung, wenn wir aus der Quell-App die Navigation versuchen. Da wir hier automatisch Parameter mitgeben, diese aber nicht erlaubt sind, wird unsere Anfrage komplett blockiert, die Navigation funktioniert hier nicht mehr.
Navigation Parameters
Schauen wir uns einmal die Funktionsweise und das Mapping der einzelnen Parameter an und sehen anhand von zwei Beispielen, wie das funktioniert. Die Einstellung steht dabei auf IGNORED, um nur das Mapping zu verwenden.
Mapping
Im ersten Beispiel legen wir zwei Parameter an, die vom Parameternamen her unterschiedlich heißen. Das ist der eingehende Parameter, und diesen mappen wir auf unsere internen Felder "Partner" und "Currency". Alle anderen Eingaben belassen wir auf Standard.
Mit einem Klick auf eine Zeile wird die Navigation durchgeführt und die beiden Informationen werden in die Filter übertragen. Somit erhalten wir im Ergebnis mehrere Datensätze, da wir nicht über den Schlüssel filtern.
Weitere Parameter
Als zweites Beispiel definieren wir noch einen zusätzlichen Parameter: das Verkaufsdatum, welches denselben Namen wie in unserer Quell-App hat. Allerdings werden alle Parameter wegen des Zusatzes IGNORED nicht berücksichtigt. Deshalb müssen wir diesen Mapping-Eintrag zusätzlich angeben, damit der Parameter auch in unserem Filter ankommt.
Führen wir nun die Navigation durch, sind alle drei Filter vorbelegt und wir erhalten nur die eine Zeile, die wir auch in der Original-App angeklickt haben.
Object Page
Bisher sind wir eigentlich immer auf den List Report navigiert. Nun stellt sich die Frage: Können wir eigentlich auch direkt auf einen Object-Page-Eintrag springen? Dazu schauen wir uns zwei Beispiele in diesem Kapitel an.
Schlüssel
Verwenden wir dazu im ersten Schritt genau den Schlüssel, der eine Instanz ausmacht, in diesem Fall die UUID. Diese wird aus dem Original-View mitübertragen, wie wir bereits oben in den Daten der URL gesehen haben. Führen wir nun ein Mapping der ID durch, das einziege Feld welches wir zulassen.
Führen wir nun die Navigation auf unserem Partner durch, landen wir über genau diesen Schlüssel auf der Object Page in unserer Ziel-App. Grundsätzlich hätten wir hier die Möglichkeit zu editieren, wenn diese aktiv wäre, und sehen sofort alle Daten genau dieses Verkaufs auf einen Blick.
Semantischer Schlüssel
Grundsätzlich sind wir nicht auf die Variante über den eindeutigen Schlüssel angewiesen, sondern können auch den semantischen Schlüssel verwenden, um eine Navigation durchzuführen. Wichtig ist hier allerdings, dass wir dann als Ergebnis auch genau einen Eintrag zurückbekommen. Dazu definieren wir einen semantischen Schlüssel im Consumption View der Ziel-App und definieren Partner und Verkaufsdatum als semantischen Schlüssel.
@ObjectModel.semanticKey: [ 'Partner', 'SalesDate' ]
define root view entity ZBS_C_NavigationTarget
Dieses Mapping übernehmen wir nun in die Navigationsparameter, um genau diese beiden Informationen anzusprechen. Gehen wir nun in die Sales App und führen die Navigation durch, landen wir ebenfalls auf der Object Page unserer Zielanwendung. Die Navigation über den semantischen Schlüssel funktioniert also genauso, um auf die Object Page zu gelangen und bindet uns nicht an den echten Schlüssel der Instanz.
Manifest
Möchtest du die Konfiguration bereits vor dem Deployment durchführen oder hast kein App Descriptor Item in deinem System zur Verfügung, dann kannst du bereits in der manifest.json die Konfiguration vornehmen. Wenn du im Generierungsprozess die Fiori Launchpad Konfiguration erzeugst, steht dir der Knoten zur Verfügung. Im Bereich SIGNATURE findest du die Parameter und die Konfiguration, um Anpassungen vorzunehemen. Allerdings muss bei dieser Variante immer das Artefakt angepasst werden und ein neues Deployment durchgeführt werden. Deshalb hatten wir in diesem Artikel die Variante nicht weiter im Detail beleuchtet.
Vollständiges Beispiel
Das komplette Beispiel findest du im Paket ZBS_DEMO_RAP_NAVIGATION, dort wurde die App als Projection auf der Sales App aus REX7 erstellt, um ein einfaches Beispiel zu haben. Im GitHub Repository findest du alle Sourcen und Beispiele. In diesem Commit findest du die angepassten und erzeugten Ressourcen.
Fazit
Funktioniert die Navigation nicht so, wie du dir das vorstellst? Landest du nicht auf der Object Page oder werden die falschen Filter übergeben? Dann solltest du einmal darüber nachdenken, die Navigation Parameters zu verwenden, um Anpassungen im App-Handling vornehmen zu können. Über die verschiedenen Einstellungen kannst du dann definieren, welche Parameter entgegengenommen werden, welche ignoriert werden und welche neu gemappt werden.
