RAP - Navigation (App to App)
Wie kannst du eigentlich innerhalb deiner Fiori Anwendung auf eine andere Anwendung navigieren, ohne das der User die App manuell wechseln muss? Schauen wir uns die Navigation zwischen Fiori Apps an.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns die App-to-App-Navigation an und blicken vor allem auf zwei Varianten, wie du diese umsetzen kannst sowie welche Vor- und Nachteile diese haben.
Einleitung
Aktuell enthält unsere Sales App auch Partner-Informationen, zumindest die Nummer des Partners. Hier würde es sich anbieten, eine Navigation auf die Partner App zu haben, sodass du direkt aus unserer Anwendung auf den Partner springen kannst, um weitere Informationen zu sehen oder direkt Anpassungen vorzunehmen. Das spart dem Fachanwender am Ende die Zeit, sich die passende App herauszusuchen, und er kann direkt aus dem Kontext heraus in die passende Anwendung abspringen.
Voraussetzung
Damit wir im nächsten Schritt die Navigation zwischen den Anwendungen testen können, müssen beide Anwendungen auf dem System deployed sein. Über die Preview funktioniert die Navigation nicht und die Links werden auch nicht aufgebaut. Hintergrund ist, dass das semantische Objekt erst im Launchpad greift und dort die Konfiguration abgelegt ist, wodurch das System auch weiß, ob die Ziel-App und die Navigation dorhin verfügbar ist oder nicht.
In unserem Beispiel verwenden wir unsere Sales App als Quelle und wollen auf den Partner navigieren, da wir Partnerdaten innerhalb unserer Sales App verwenden. Ebenso haben wir im vergangenen Tutorial die Partner App ins System deployed und verschiedene Launchpad Configurations angelegt, um diese zu testen.
Wir werden bei unserem Test dabei drei Spalten anpassen: den Partner als das eigentliche Schlüsselfeld und semantischer Key, das Sales Date als normales Feld den Sales Month als ein Feld mit Kritikalität, um die verschiedenen Effekte auf den Feldern zu beobachten.
Variante - Consumption
Die Variante mit Consumption basiert vor allem auf der Annotation "Consumption.semanticObject". Daran erkennst du, dass diese Variante ausgewählt wurde. Diese hat zum Beispiel aber auch den Nachteil, dass nur eine Navigation auf ein Ziel möglich ist, da das semantische Objekt die Einstellungen im Core Data Service für andere Navigationen überschreibt. In diesem Beispielen erweitern wir die Metadata Extension für ZBS_C_SASALE.
Link (Object)
Definieren wir also im ersten Schritt das semantische Objekt an der Partnernummer und am Verkaufsjahr. Hierbei geben wir nicht die Aktion an und auch keine weiteren Informationen.
@Consumption: {
semanticObject: 'ZBS_DEMO_PMANUAL'
}
PartnerNumber;
@Consumption: {
semanticObject: 'ZBS_DEMO_PMANUAL'
}
SalesYear;
Prüfen wir dann das Ergebnis in unserer Anwendung, finden wir bereits auf der Partnernummer und dem Einkaufsjahr einen Link, der blau hervorgehoben ist. Damit funktioniert die Navigation bereits.
Führen wir nun die Navigation auf dem ersten Eintrag aus und klicken auf die Partnernummer. Dabei navigiert unsere App in die Partner-App, allerdings sehen wir hier die komplette Liste an Partnern, die geladen wird, es ist kein Filter gesetzt. Schaust du dir die URL an, dann wurden alle Informationen des Datensatzes als Kriterien in diese übernommen, außer die Partner-ID, also das Feld, das wir angeklickt haben.
Das Gleiche wiederholen wir nun auf dem Verkaufsjahr. Die Navigation funktioniert, dieses Mal ist die Partnernummer im Filter befüllt. Prüfen wir die URL, werden wir feststellen, dass dieses Mal das Verkaufsjahr fehlt. Das heißt, das aktuelle Feld, das angeklickt wird, wird nicht mit in den Filter übergeben.
Link (mit Element)
Im zweiten Beispiel erweitern wir nun das Ganze um das Object-Mapping "Element". Dabei wissen wir ja, dass wir die Partnernummer zum Filtern benötigen, deshalb ergänzen wir die Partnernummer als Element. Hierbei handelt es sich um den Namen des Zielelements, welches in der Ziel-App angesteuert wird.
@Consumption: {
semanticObject: 'ZBS_DEMO_PMANUAL',
semanticObjectMapping.element: 'PartnerNumber'
}
PartnerNumber;
@Consumption: {
semanticObject: 'ZBS_DEMO_PMANUAL',
semanticObjectMapping.element: 'PartnerNumber'
}
SalesYear;
Führen wir nun wieder die Navigation über die Partnernummer aus, dann wird die Partnernummer in der Ziel-App befüllt und der Filter wird angewandt. Wir sehen nur einen Datensatz.
Klicken wir auf das Verkaufsjahr, dann landen wir ebenso in der Partner-App. Dieses Mal wird das Partnerfeld mit dem aktuellen Jahr befüllt, welches wir angeklickt haben. Das heißt, am Ende wird das aktuelle Element, an dem wir das semantische Mapping-Objekt definiert haben, verwendet, um das Zielelement zu befüllen.
Link (mit Binding)
Im dritten Beispiel verwenden wir nun das Additional Binding an den Feldern. Hierbei mappen wir das lokale Feld und das Remote-Feld zueinander. Diese Variante verwenden wir jeweils bei beiden Feldern, der Partnernummer und dem Verkaufsjahr.
@Consumption: {
semanticObject: 'ZBS_DEMO_PMANUAL',
semanticObjectMapping.additionalBinding: [
{ localElement: 'PartnerNumber', element: 'PartnerNumber' }]
}
PartnerNumber;
@Consumption: {
semanticObject: 'ZBS_DEMO_PMANUAL',
semanticObjectMapping.additionalBinding: [
{ localElement: 'PartnerNumber', element: 'PartnerNumber' }]
}
SalesYear;
Bei der Navigation über die Partnernummer landen wir nun wieder in der Ziel-App, die Partnernummer ist sauber befüllt.
Ebenso beim Verkaufsjahr landen wir in der Partner-Applikation. Die Partnernummer ist sauber befüllt und der Filter funktioniert.
Variante - Inline
Schauen wir uns nun ein Beispiel an, wo die Navigation sich im Item befindet. Dabei ist es aber wichtig, dass du die Annotation "Consumption.semanticObject" aus dem vorhergehenden Beispiel nicht in deinem Core Data Service hast.
Link (WITH)
In diesem Beispiel verwenden wir den Zusatz WITH_INTENT_BASED_NAVIGATION, um eine Navigation am Feld zu definieren. Dabei setzen wir das semantische Objekt und die Action, um direkt die Navigation anzusteuern. In diesem Fall verzichten wir auf ein Mapping bei beiden Feldern. Alle Informationen befinden sich im gleichen Eintrag und nicht als zusätzlichen Eintrag.
@UI.lineItem: [
{ position: 20,
type: #WITH_INTENT_BASED_NAVIGATION,
semanticObject: 'ZBS_DEMO_PMANUAL',
semanticObjectAction: 'manage'
}
]
PartnerNumber;
@UI.lineItem: [
{ position: 32,
importance: #LOW,
type: #WITH_INTENT_BASED_NAVIGATION,
semanticObject: 'ZBS_DEMO_PMANUAL',
semanticObjectAction: 'manage'
}
]
SalesYear;
Klicken wir nun auf die Elemente, wird die Navigation durchgeführt und wir landen in der Ziel-App. Bei beiden Feldern wird der Filter sauber angewandt, obwohl wir kein Mapping definiert haben. Hier werden die Elemente anhand der Namensgleichheit im Filter der URL sichergestellt.
Additional Binding
Das zusätzliche Binding (semanticObjectBinding) benötigst du vor allem, wenn du abweichende Namen innerhalb deines Core Data Services verwendest. Um das Mapping mit der Ziel-App herzustellen, musst du dazu dieses zusätzliche Mapping definieren.
Buttons
Die Navigation muss nicht immer über einen Link erfolgen, sondern es gibt auch die Möglichkeit, an verschiedenen Stellen Buttons zu implementieren, die für die Navigation vorgesehen sind. Dies machen wir in diesem Kapitel.
Button (List Report)
In diesem Fall wollen wir einen Button in der Liste anzeigen, direkt mit den anderen Optionen. Dazu definieren wir ein eigenes Element in den LineItems. Diesem können wir auch eine Reihenfolge geben und aktivieren es für Intent-based Navigation. Neben dem semantischen Objekt und der Aktion müssen wir auch wieder ein Binding angeben. Über das Label definieren wir dann den Text, der auf dem Button zu sehen ist.
@UI.lineItem: [
{ position: 33, criticality: 'DataCriticality', criticalityRepresentation: #WITH_ICON, importance: #LOW },
{ type: #FOR_INTENT_BASED_NAVIGATION,
semanticObject: 'ZBS_DEMO_PMANUAL',
semanticObjectAction: 'manage',
semanticObjectBinding: [{ localElement: 'PartnerNumber', element: 'PartnerNumber' }],
label: 'To Partner' }
]
@EndUserText.label: 'Sales Month'
SalesMonth;
Im UI wird dann ein neuer Button (To Partner) sichtbar, der das folgende Verhalten aufweist:
- Haben wir keinen Datensatz in der Liste markiert und klicken auf den Button, dann wird die Navigation durchgeführt, es wird aber kein Filter befüllt.
- Markieren wir einen Datensatz und klicken dann auf den Button, wird dieser Datensatz genommen und das Mapping hergestellt. Wir sehen dann in der Ziel-App einen Datensatz.
- Markieren wir mehrere Datensätze, werden mehrere Partnernummern in die Ziel-App übernommen und als Filter eingetragen, wir erhalten dann mehrere Datensätze, entsprechend des Filters.
Button (Object Page)
Wollen wir einen zusätzlichen Button für die Navigation einbauen, können wir dies über ein zusätzliches Item im Bereich der Identification tun. Dafür definieren wir dieses vom Typ FOR_INTENT_BASED_NAVIGATION, definieren eine Action passend dazu und optional ein Binding und geben dem Button über den Zusatz LABEL einen Text.
@UI.identification: [
{ position: 33 , qualifier: 'GENERAL', criticality: 'DataCriticality', criticalityRepresentation: #WITH_ICON },
{ type: #FOR_INTENT_BASED_NAVIGATION,
semanticObject: 'ZBS_DEMO_PMANUAL',
semanticObjectAction: 'manage',
semanticObjectBinding: [{ localElement: 'PartnerNumber', element: 'PartnerNumber' }],
label: 'Open Partner' }
]
SalesMonth;
Schauen wir uns dann unsere Anwendung an, wird ein zusätzlicher Button auf der Object Page generiert, der neben den anderen Buttons im oberen Bereich des Headers steht. Über einen Klick auf den Button navigieren wir dann in die Partner App mit dem gesetzten Filter.
Unterschiede
Gibt es eigentlich nun einen Unterschied bei der Verwendung der beiden Varianten? Im ersten Fall verwenden wir die Variante mit der "Consumption" Annotation, um uns die Links auf den drei Feldern generieren zu lassen. Wie du siehst, ist die Partnernummer fett hervorgehoben und das Verkaufsdatum zum Beispiel hat immer noch den Criticality Indicator.
Bei der Variante, wo wir unsere semantische Navigation innerhalb des Objektes definieren (Variante Inline), sind alle Formatierungsoptionen verschwunden. Der Partner und das Verkaufsdatum werden normal dargestellt und unser Criticality Indicator wurde entfernt. Dafür wird der Link immer blau und normal dargestellt.
Hinweis: Eine Vermischung beider Varianten im gleichen Core Data Service sollte vermieden werden. Hier solltest du entscheiden, wie die Felder aufbereitet werden sollen und ob bestimmte Formatierungen für dich wichtig sind.
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 Navigation über semantische Objekte und Informationen unserer App erleichtert die Bedienung durch Links und Buttons, die zur entsprechenden Ziel-App führen, um eine Pflege schneller durchführen zu können. Hierbei handelt es sich um eine Komfortfunktion für unsere Endanwender. Diese funktioniert aber nur im deployten Zustand.
