Neben den allgemeinen Limitierungen bei den Namen der RFC-Destinationen (siehe Allgemeine Limitierungen bei den Namen der RFC-Destinationen), gibt es bei der Nutzung der Multi-Back-End-Funktionalität weitere Limitierungen.

Folgende Zeichen und Zeichenketten dürfen nicht im Namen der RFC-Destination enthalten sein:

Das Customizing der Multi-Back-End-Funktionalität muss wie bisher im Back-End vorgenommen werden. Die xSuite Apps für Fiori verwenden dieses Customizing.

Im Front-End muss in der Datei settings.json der Basisfunktionalität der neue Parameter m‍u‍l‍t‍i‍b‍a‍c‍k‍e‍n‍d auf true gesetzt werden.

Eine xSuite App verwendet die Multi-Back-End-Funktionalität nur, wenn alle folgenden Bedingungen zutreffen:

Wenn eine dieser Bedingungen nicht zutrifft, wird wie bisher nur ein Back-End (RFC-D‍e‍s‍t‍i‍n‍a‍t‍i‍o‍n) von der App angesprochen.

Das bedeutet, dass z. B. der xSuite Invoice Monitor sowohl mit als auch ohne Multi-Back-End verwendet werden kann.

Die Verwendung mit und ohne Multi-Back-End wäre unter anderem unter folgender Konstellation möglich:

Es gibt zwei Back-Ends (RFC-Destinations): "RFC_1" und "RFC_2"

Im Back-End "RFC_1" ist das Master-System, d. h. dort erfolgt im Back-End das Multi-Back-End-Customizing.

"RFC_2" ist das Slave-System.

Im Front-End wird der Parameter m‍u‍l‍t‍i‍b‍a‍c‍k‍e‍n‍d auf true gesetzt und die RFC-Destination "RFC_1" wird als Default-RFC-Destination hinterlegt.

Im Fiori Launchpad werden 2 Kacheln für den xSuite Invoice Monitor angelegt: Eine Kachel ohne RFC-Parameter, d. h. die Default-RFC-Destination wird verwendet, und eine Kachel mit dem RFC-Parameter "RFC_2".

Der Invoice Monitor mit dem Back-End "RFC_1" erfüllt alle Bedingungen der Multi-Back-End-Funktionalität und verwendet diese. Es kann somit auf die Back-Ends "RFC_1" und "RFC_2" zugegriffen werden.

Der Invoice Monitor mit dem Back-End "RFC_2" erfüllt die Bedingungen der Multi-Back-End-Funktionalität nicht – das Back-End-Customizing fehlt. Über diese Kachel kann somit nur auf das Back-End "RFC_2" zugegriffen werden.

Benutzereinstellungen werden im Multi-Back-End immer vom Master-System geladen und auch dort gespeichert. TCURX-Daten werden ebenfalls nur vom Master-System geladen.

F4-Wertehilfen, das Speichern, Löschen und Laden von Vorlagen und die Toolbar-Buttons sprechen immer das jeweilige Back-End des Dokuments oder der Suche etc. an, nicht zwingend das Master-System.

Mit Single-Back-End werden die Benutzereinstellungen im jeweiligen Back-End gespeichert.

Nachfolgend sind die Unterschiede zwischen Single- und Multi-Back-End in der xSuite Invoice Monitor App für SAP Fiori aufgeführt.

In der Inbox kann mit Multi-Back-End nur ein Workitem ausgewählt und bearbeitet werden. Mit Single-Back-End können mehrere Workitems ausgewählt werden.

Die Tabelle der Workitems enthält mit Multi-Back-End zusätzlich die Spalte System. Dort ist das Back-End benannt, von dem das jeweilige Workitem stammt.

In den App-spezifischen Einstellungen kann der Benutzer mit Multi-Back-End die Position der Spalte System innerhalb der Tabelle festlegen. Zudem kann die Breite der Spalte definiert werden.

Diese Einstellungen werden in den Benutzereinstellungen des Master-Systems gespeichert und sind somit persistent gesichert.

Einige der Elemente, die zur Verbesserung der Barrierefreiheit eingefügt wurden, setzen mindestens die SAPUI5-Version 1.61 voraus, z. B. einige Landmarks.

Diese Änderungen sind automatisch aktiv, wenn die notwendige SAPUI5-Framework-Version verwendet wird. Ein gesondertes Customizing ist nicht erforderlich.

Zudem hat SAP die Barrierefreiheit des SAPUI5-Frameworks mit Version 1.78 deutlich verbessert. Wenn das Thema Barrierefreiheit relevant ist, dann sollte mindestens diese SAP UI5-Version verwendet werden.

Pflichtfelder sind durch einen Stern (*) gekennzeichnet. In den Tooltips dieser Felder ist zudem der Vermerk (Pflichtfeld) vorhanden.

Mit diesem Release gibt es zu Beginn von Seiten, die Pflichtfelder enthalten, einen entsprechenden Infotext. Zudem kommen noch weitere Infotexte zum Einsatz, wo dies erforderlich ist.

Der Benutzer kann diese Infotexte in den Einstellungen über die Checkbox K‍e‍i‍n‍e Z‍e‍i‍c‍h‍e‍nl‍e‍g‍e‍n‍d‍e anzeigen deaktivieren. Standardmäßig werden die Infotexte angezeigt.

Tabellen, die nicht die gesamte Seite umfassen, z. B. die Tabelle Positionsdaten in einem Workitem, haben meistens eine Standardanzahl von Zeilen, die angezeigt werden.

Durch Verschieben des Tabellenendes kann die Höhe bei diesen Tabellen geändert werden. Diese Änderung war bisher immer temporär. Mit Verlassen der Seite wurde die Änderung der Tabellengröße rückgängig gemacht.

Ab diesem Release kann der Benutzer die Standard-Anzahl der angezeigten Tabellenzeilen in den Benutzereinstellungen individuell festlegen. Der Standardwert ist 5.

Der Benutzer kann den erweiterten Zugänglichkeitsmodus in den Benutzereinstellungen der xSuite Apps im Tab Barrierefreiheit de- oder aktivieren. Standardmäßig ist dieser Modus deaktiviert.

Wenn der erweiterte Zugänglichkeitsmodus aktiv ist, können folgende Optionen individuell de- oder aktiviert werden:

Wenn das Fiori Launchpad oder die App im Standalone-Modus mit dem URL-Parameter sap-accessibility bzw. sap-ui-accessibility gleich true, X oder 1 aufgerufen wird, ist der erweiterte Zugänglichkeitsmodus mit allen Optionen, unabhängig von den Benutzereinstellungen, immer aktiv.

Der erweiterte Zugänglichkeitsmodus kann dann auch über die Benutzereinstellungen nicht deaktiviert werden.

In der Detailansicht der xSuite Cockpit App ist nun die Laufwegvorschau verfügbar. Die Laufwegvorschau zeigt den Weg, den ein Workitem im Workflow nehmen wird.

Um die Laufwegvorschau zu öffnen, muss der Benutzer ein Workitem auswählen und anschließend auf den Button Laufwegvorschau klicken.

Die Laufwegvorschau wird als Baumstruktur ausgegeben. Die oberste Ebene der Baumstruktur zeigt die einzelnen Workflowaufgaben und das Workflow-Ende.

Darunter folgen jeweils als eigene Ebene die Stufen, die Benutzer und die Positionen. Das Symbol hinter einer Position zeigt an, dass das Ende-Kennzeichen vorhanden ist.

Über den Button Alles expandieren kann die komplette Baumstruktur ausgeklappt werden. Über den Button Alles komprimieren kann die komplette Baumstruktur eingeklappt werden.

Über die Felder Aufgabe-Filter, Stufen-Filter und Nutzer-Filter kann die Laufwegvorschau nach den Aufgaben, Stufen und Benutzern gefiltert werden.

Die xSuite Cockpit App unterstützt nun den Expertenmodus. Benutzer mit dem xSuite-Benutzerattribut XF_ADMIN_EXT gleich X führen die xSuite Cockpit App im Expertenmodus aus.

Im Expertenmodus wird bei Klick auf den Button Workflow Neustart (nicht zu verwechseln mit dem Button Neustart Workflowschritt) nicht direkt der Workflow neu gestartet.

Stattdessen kann der Benutzer den Workflowschritt auswählen, in dem der Workflow neu gestartet werden soll.

Die Datei settings.json beinhaltet nun den Parameter cloud, über den definiert wird, ob die Apps in der Cloud-Foundry- oder in der Neo-Umgebung verwendet werden.

Innerhalb der Subaccounts wird standardmäßig vorausgesetzt, dass für das verwendete Gateway eine Destination mit dem Namen xSuiteCube-gateway vorhanden ist.

Wenn ein anderer Destinationsname verwendet wird, sind Code-Anpassungen erforderlich.

Für das Deployment in eine Cloud-Foundry-Umgebung wird eine separate mtar-Archivdatei bereitgestellt. Diese Datei enthält den Programmcode sämtlicher Anwendungen sowie weitere Konfigurationsdateien für die Cloud Foundry.

Für das Deployment in die SAP-Neo-Umgebung werden für die einzelne xSuite Apps sowie für die xSuite-Basisfunktionalität einzelne ZIP-Archivdateien bereitgestellt. Diese Dateien müssen einzeln in der Web IDE importiert werden.

Die xSuite Apps für SAP Fiori erkennen jetzt automatisch, ob sie innerhalb oder außerhalb des Fiori Launchpads laufen. Somit ist der Parameter fiori in der Datei settings.json obsolet und wurde entfernt.

Zudem bestimmt die Umgebung, ob ein Gateway verwendet wird oder verwendet werden muss.

Nur im Fall von On-premises (nicht Cloud) im Standalone-Modus mit SSO-Login ist dies nicht eindeutig festgelegt. Daher wird der settings.json-Parameter use_nwgw nur noch im Fall von On-premises im Standalone-Modus mit SSO-Login von den xSuite Apps ausgewertet und muss dann auch korrekt gesetzt werden.

In allen anderen Fällen wird dieser Parameter ignoriert.

Fehler und Warnungen werden von den xSuite Apps nun nicht mehr direkt über das console-Objekt in der Browser-Konsole ausgeben.

Stattdessen wird die Logging API des SAPUI5-Frameworks genutzt. Die Meldungen stehen somit in der Logging API zur Verfügung.

Die API gibt, abhängig von den Einstellungen, die Meldungen aber auch weiterhin in der Browser-Konsole aus.

Die ID des Process Analyzers wurde von xSuiteProcessAnalyzer geändert zu x‍S‍u‍i‍t‍e‍A‍p‍pP‍r‍o‍c‍e‍s‍s‍A‍n‍a‍l‍y‍z‍e‍r. Damit entspricht die ID dem Schema der übrigen xSuite-Anwendungen.

Durch die Änderung der ID funktionieren alte Kacheln für diese Anwendung nicht mehr. In der Transaktion /UI2/FLPD_CUST muss daher das Mapping für das semantische Objekt xsfpaonl angepasst werden.

Der (primäre) Kalendertyp innerhalb der xSuite Apps ist nun immer "Gregorian". Alle anderen Kalender-Typen (z. B. "Persian" oder "Japanese") werden nur als sekundäre Kalender-Typen unterstützt.

Der sekundäre Kalendertyp kann wie bisher in der Datei settings.json im Parameter secondaryCalendarType festgelegt werden, sofern ein sekundärer Kalendertyp angezeigt werden soll.