SAP Gateway konfigurieren

Ein wichtiger Aspekt der Architektur des World Wide Web ist die Verwendung von abstrakten Schnittstellen für die Komponentenkommunikation. Diese abstrakten Schnittstellen werden als Konnektoren dargestellt. Ein Client und ein Server verwenden jeweils eine Konnektorkomponente. Es gibt einen Vertrag zwischen beiden Konnektoren, der das Anwendungsprotokoll definiert. Er definiert die Dokumente, deren Format und das Verhalten. Jedes Protokoll kann gewählt werden. Durch die Verwendung des Konnektorkonzepts sind sowohl der Client als auch der Server weitgehend unabhängig und austauschbar. Jeder Konnektor übersetzt die über den Kommunikationskanal ausgetauschten Dokumente sowohl auf der Server- als auch auf der Client-Seite in die internen Darstellungen und umgekehrt.

Das OData-Protokoll definiert einen solchen Vertrag, indem es ein einheitliches Protokoll vorgibt, das über die notwendigen Eigenschaften verfügt. Ein mit einem SAP-Backend-System verbundener Konnektor übersetzt zum Beispiel zwischen ABAP-APIs und OData-Entitäten. Das SAP Gateway ist ein solcher Konnektor.

Auf der anderen Seite übersetzt ein Clientkonnektor zwischen OData-Entitäten und den APIs der konsumierenden Plattform. Der Konnektor ist hier angegeben. Folglich kann jede Clientplattform mit Bibliotheken, die das im Vertrag festgelegte OData-Format unterstützen, mit jedem Server kommunizieren, der denselben Vertrag unterstützt.

OData folgt dem Architekturdesignparadigma Representational State Transfer (REST) in dem Sinne, dass das Protokoll Darstellungen des Ressourcenzustands überträgt. Der Begriff Ressource bezeichnet Daten, die adressierbar und zugänglich sind. Die Standardadressdarstellung oder -ressource ist der Uniform Resource Identifier (URI). Ein Client fordert eine Ressource von einem Server an, indem er einen Request an einen URI sendet. Der Server verarbeitet den Request, indem er den URI in interne Adressdaten übersetzt, um auf die Daten zuzugreifen oder die Daten zu bearbeiten und die Antwort dann zusammenzustellen.

ODataOData ist ein offener Standard, der ursprünglich von Microsoft entwickelt wurde, aber jetzt von der Oasis Organization verwaltet wird. Sie basiert auf den Standards Atom Publishing und Atom Syndication, die wiederum auf XML (Extensible Markup Language) und HTTP(S) (HyperText Transfer Protocol (Secure)) basieren. JSON (JavaScript Object Notation) ist eine Alternative zu XML, um Daten zu strukturieren.

Das Ziel des OData-Protokolls besteht darin, ein anbieterunabhängiges, webbasiertes API zu bieten, das die Designprinzipien von Representational State Transfer (REST) vollständig erfüllt. OData bietet datenbankähnlichen Zugriff auf serverseitige Ressourcen. OData wird in diesem Zusammenhang auch ODBC für das Web genannt.

Außerdem ist OData erweiterbar. Daher kann SAP die von OData verwendeten Datentypen durch zusätzliche Informationen aus dem ABAP Data Dictionary ergänzen. Ein weiteres Beispiel ist die metadatengesteuerte Entwicklung für Web und mobile Geräte wie SAP Fiori Elements.

V4OData ist in Version 2 (V2), Version 3 (V3) und Version 4 (V4) verfügbar. Die Versionen bauen aufeinander auf und erweitern die vorherige Version um neue Funktionen. Die meisten OData-Services basieren auf V2. SAP Gateway unterstützt OData V2 ab AS ABAP 7.00 und OData V4 ab AS ABAP 7.50. OData V3 wurde in SAP Gateway übersprungen und wird daher nicht unterstützt.

bietet verschiedene OData-Provider an. SAP Gateway (bis Ende 2014 als SAP NetWeaver Gateway bezeichnet) bietet einen zentralen Einstiegspunkt für den Zugriff auf Geschäftsdaten von ABAP-basierten Systemen wie der SAP Business Suite oder SAP S/4HANA. Die SAP HANA Extended Applications Services (XS) haben in SAP HANA dieselbe Rolle – nur um einen anderen wichtigen OData-Provider zu benennen.

Durch die Verwendung von OData können Geschäftsdaten von mehreren Umgebungen und Plattformen gemeinsam genutzt werden. Für die Nutzung der Daten sind keine SAP-Kenntnisse erforderlich. In der Regel konsumieren Client-basierte Anwendungen SAP-Gateway-Services und interagieren direkt mit dem Benutzer. Anwendungen in einem Web-Browser sind ein gängiges Beispiel.

Es ist jedoch auch möglich, dass ein SAP-Gateway-Service von einer serverbasierten Anwendung als API (Application Programming Interface) verwendet wird. Zum Kommunikationspfad können weitere Server hinzugefügt werden, um die Möglichkeiten für Client und Server zu erweitern. Für mobile Geräte bieten die SAP Mobile Services zusätzlichen Mehrwert für die Anwendungen.

Für AS ABAP 7.00 bis 7.31 besteht SAP Gateway aus einzelnen Add-Ons, die die OData-Funktion bereitstellen. Diese lassen sich in zwei Bereiche unterteilen:

Laufzeit

Stellt den OData-Service und damit den SAP-Gateway-Service extern über den URI bereit.

Designzeit

Beinhaltet die Entwicklungsumgebung wie auch die Programme zum Verarbeiten der Anfragen an den Service.

Zuerst in AS ABAP 7.40 eingeführt und in AS ABAP 7.51 finalisiert, werden alle Add-Ons in der Softwarekomponente SAP_GWFND (SAP Gateway Foundation) zusammengeführt. Dies bietet alles, was für die OData-Laufzeit und die Design-Zeit erforderlich ist.

Es gibt drei mögliche Deployment-Optionen für SAP Gateway (Hub ist ein Synonym für Frontend-Server (FES)):

Hub-Deployment mit Entwicklung im Backend-Server (BES)

Ein Hub-Deployment bietet die Möglichkeit, mehrere Backend-Systeme weiterzuleiten und zusammenzustellen. Es ist der zentrale Zugriffspunkt auf Backend-Systeme bei Verwendung von OData. Dies erhöht die Sicherheit und Flexibilität im Betrieb.

Dies ist die empfohlene Einrichtung für SAP Business Suite.

Hub-Deployment mit Entwicklung im Frontend-Server (FES)

Bei der Entwicklung im FES werden Daten nur über RFC-fähige Funktionsbausteine aus dem BES gelesen, was den Zugriff auf Daten eines BES ermöglicht, der keinen OData-Service alleine bereitstellen kann. Dadurch erhalten Sie mehr Freiheit bei der Auswahl eines Systems als Datenquelle.

Dies ist die empfohlene Einrichtung für die Integration mehrerer BES mit verschiedenen Releases.

Integriertes Deployment

Bei der Entwicklung im BES hat der Anwendungsquelltext direkten Zugriff auf die Definition der Daten und anderer Repository-Objekte. Dies erhöht die Performance und Effizienz bei der Entwicklung.

Dies ist die empfohlene Einrichtung für SAP S/4HANA.

Für AS ABAP 7.00 bis 7.31 besteht SAP Gateway aus einzelnen Add-Ons, die die OData-Funktion bereitstellen. Die OData-Laufzeit besteht aus dem Gateway Core (GW_CORE) und der Information Worker Foundation (IW_FND) und beinhaltet damit neben der Laufzeit auch die Serviceregistrierung. Das zentrale Add-On Business Enablement Provisioning (IW_BEP) der Design- und Serviceanbieter-Laufzeit beinhaltet die Werkzeuge für die Serviceimplementierung. Zusätzlich können weitere Add-ons installiert werden, zum Beispiel:

• Prozess-Gateway-Workflow (IW_PGW)

• Generischer Interaction Layer (IW_GIL)

• Service Provider Infrastructure (IW_SPI)

Seit AS ABAP 7.40 sind GW_CORE, IW_FND, IW_BEP und IW_HDB (SAP-HANA-Datenbank) zusammengefasst in der Softwarekomponente SAP_GWFND (Gateway Foundation). Diese bietet alles, was für die OData-Laufzeit und -Implementierung benötigt wird. Die weiterhin möglichen zusätzlichen Add-ons werden unter Datenmodell-Nutzung und Generatoren zusammengefasst.

Ab AS ABAP 7.51 wurde IW_PGW zusätzlich zur Softwarekomponente SAP_GWFND zusammengeführt. Dies bietet allgemeine SAP-Workflow-Funktionen über SAP Gateway, die insbesondere im Bereich von SAP Fiori verwendet werden. Alle anderen SAP-Gateway-Add-ons sind veraltet und sollten deinstalliert werden. Die entsprechenden Funktionen sind jetzt entweder Teil der Softwarekomponente SAP_GWFND oder werden nicht mehr unterstützt.

Ab SAP NetWeaver 7.50 SP03 wurden Neuentwicklungen in SAP Gateway nur für die Softwarekomponente SAP Gateway Foundation (SAP_GWFND) im höchsten SAP-NetWeaver-Release durchgeführt.

Ab SAP NetWeaver 7.52 SP01 bis zur ABAP-Plattform 2022 wurde entschieden, einen Downport der folgenden Strukturpakete und ihrer Unterpakete des SAP-Gateway-Foundation-Frameworks auf SAP NetWeaver 7.51 durchzuführen:

• /IWFND/FRAMEWORK
• /IWBEP/FRAMEWORK
• /IWCOR/TD_CSI

Dies umfasst die neueste Entwicklung für das SAP-Gateway-Foundation-Framework für OData V4 sowie für OData V2. Sie enthält jedoch nicht die Komponenten des Benachrichtigungskanals.

Beachten Sie, dass

1. In bestimmten Anwendungsfällen kann es leichte Abweichungen in der Funktion geben.
2. nicht für alle Funktionen ein Downport durchgeführt wurde (siehe vorstehende Liste der Softwarepakete).

Infolgedessen entsprechen die oben genannten Unterpakete des SAP-Gateway-Frameworks in SAP NetWeaver 7.52 SP01 ihren Gegenteilen im SAP-Gateway-Framework in SAP NetWeaver 7.51 SP05 und SAP NetWeaver 7.50 SP11.

Dasselbe gilt für höhere Releases, deren Gegenstücke in der Tabelle sichtbar sind. Der letzte verfügbare Downport für SAP_GWFND 7.50 ist in SP12 enthalten. Der letzte verfügbare Downport für SAP_GWFND 7.51 ist in SP09 enthalten. Für diese Releases sind keine weiteren Downports geplant.

Weitere Informationen finden Sie im SAP-Hinweis 2512479 – SAP Gateway Foundation Support Package Stack Definition.

Ein Technologie-Framework, das die Bereitstellung und den vereinfachten Zugriff auf SAP-Software von jedem Gerät oder jeder Umgebung aus mithilfe von offenen Standardprotokollen ermöglicht. Es öffnet Daten und Prozesse, die auf SAP-Anwendungen ausgeführt werden, für Softwareentwickler, um Apps in verschiedenen Umgebungen und Geräten zu erstellen, um viele weitere Geschäftskunden anzusprechen. Vormals unter dem Namen SAP NetWeaver Gateway bekannt.

Standard, der eine Reihe von Best Practices für die Erstellung und Nutzung von RESTful-APIs definiert.

sind vier Schritte als Basiskonfiguration in SAP Gateway erforderlich, um die Kommunikation über OData zu ermöglichen:

1. RFC-Destination zu BES im FES anlegen (für eingebettetes Deployment nicht erforderlich)
2. SAP Gateway im FES aktivieren (in BES für eingebettetes Deployment)
3. Systemalias in FES anlegen (optional für integriertes Deployment)
4. ICF-Knoten unter /sap/opu im FES aktivieren (in BES für eingebettetes Deployment)

Abhängig von der Deployment-Option von SAP Gateway benötigt der Systemalias bestimmte Einstellungen:

• In einem Hub-Deployment mit Entwicklung in BES darf weder das Kennzeichen Lokales GW noch Lokale App gesetzt sein.

• In einem Hub-Deployment mit Entwicklung im FES darf nur das Kennzeichen Lokale App gesetzt sein.

• In einem integrierten Deployment muss nur das Kennzeichen Lokales GW gesetzt sein.

Die letzte Kombination mit beiden gesetzten Kennzeichen wird nur in einem integrierten Deployment für Services verwendet, die ursprünglich für das Hub-Deployment mit Entwicklung im FES entwickelt wurden.

Ab AS ABAP 7.50 SP04 ist es möglich, die gesamte Verarbeitung des OData-Requests an den BES weiterzuleiten. Die Funktion hieß in AS ABAP 7.50 Micro Hub, wurde in AS ABAP 7.51 jedoch in OData im Backend umbenannt. Dies kann die Performance der Serviceaufrufe je nach Szenario bezüglich der Arbeitslast im FES und BES oder des Netzwerks erhöhen. Die folgenden Schritte sind erforderlich, um OData im Backend für einen SAP-Gateway-Service zu aktivieren:

1. Definieren Sie einen Systemalias im FES mit aktiviertem Kennzeichen OData im Backend.
2. Registrieren Sie einen Service im FES mit diesem Systemalias im Verarbeitungsmodus Routing-basiert.
3. Registrieren Sie denselben Service in BES ohne Systemalias im Verarbeitungsmodus Nur integriertes Deployment.

Zusätzlich zur Funktion OData im Backend in einem Hub-Deployment wird heute empfohlen, SAP-Gateway-Services in einem eingebetteten Deployment im Verarbeitungsmodus Nur integriertes Deployment zu registrieren. Dies erhöht die allgemeine Performance von OData-Requests, indem ein Kommunikationsteil in einem AS ABAP übersprungen wird, der normalerweise beim Verbinden von FES mit BES beteiligt ist.

Neben dem Systemalias, der FES mit BES verbindet, ermöglicht der SAP-Gateway-Alias die Verbindung von BES zu FES. Dies ist für den Aufruf eines SAP-Gateway-Service nicht erforderlich, wird jedoch bei der Entwicklung eines SAP-Gateway-Service nützlich. Es sind zwei Schritte erforderlich, damit Entwickler ihre OData-Services über den SAP Gateway Service Builder (Transaktion SEGW) registrieren, verwalten und testen können:

1. RFC-Destination für FES in BES anlegen (für eingebettetes Deployment nicht erforderlich)
2. SAP-Gateway-Alias in BES anlegen

Im Task-Manager für die technische Konfiguration (Transaktion STC01) sind mehrere Aufgabenlisten vorhanden, um die Initialisierung und Handhabung von SAP Gateway zu vereinfachen:

SAP_GATEWAY_BASIC_CONFIG (ab AS ABAP 7.40)

Führt die Basiskonfiguration wie die Aktivierung von SAP Gateway, zentralen ICF-Knoten und Metadaten-Cache durch.

SAP_SAP2GATEWAY_TRUSTED_CONFIG (ab AS ABAP 7.40)

Legt eine vertrauenswürdige RFC-Verbindung zwischen BES und FES einschließlich Single Sign-On an und konfiguriert sie.

SAP_GATEWAY_ACTIVATE_ODATA_SERV (ab AS ABAP 7.40)

Registriert eine Liste der SAP-Gateway-Services auf Routing-Basis oder integriertem Deployment.

/IWFND/TL_SERVICE_MAINTENANCE (ab AS ABAP 7.54)

Aktivieren Sie die Massenpflege von SAP-Gateway-Services, z.B. Handhabung der Systemaliaszuordnung, Festlegen des Verarbeitungsmodus, Löschen oder Transportieren von Services.

SAP-Gateway-Service-Verwaltung (Transaktion /IWFND/MAINT_SERVICE) stellt eine Liste aller im System registrierten OData-V2-Services bereit. Hier wird die vollständige Verwaltung der SAP-Gateway-Services durchgeführt. Die Transaktion unterteilt sich in drei Bereiche:

• Servicekatalog (Servicename, Beschreibung und viele weitere Einstellungen)
• ICF-Knoten (Pflege der ICF-Services und Testen des Services)

  Hinweis

  Ab SAP_GWFND 7.58 ist ein ICF-Knoten für den Aufruf eines SAP-Gateway-Service optional. Die OData-V2-Services sind dann direkt mit dem Knoten /sap/opu/odata verknüpft.
• Systemaliasse (Pflege der Verbindung zum Backend)

  Hinweis

  Für Services, die sich nicht mit anderen Systemen verbinden, wird der Modus auf Nur integriertes Deployment gesetzt, und es wird kein Systemalias zugeordnet.

OData-V4OData-V4-Services werden nicht als Einzelinstanzen registriert. Stattdessen wird eine aus mehreren Services bestehende Service-Gruppe publiziert. Diese Service-Gruppen werden über die SAP-Backend-Service-Administration (Transaktion /IWBEP/V4_ADMIN) angelegt und von SAP ausgeliefert oder von Entwicklern angelegt.

Die SAP-Gateway-Service-Administration (Transaktion /IWFND/V4_ADMIN) wird verwendet, um Service-Gruppen zu veröffentlichen, damit die darin enthaltenen Services in Anwendungen verwendet werden können.

dem SAP Gateway Client (Transaktion /IWFND/GW_CLIENT) können alle Funktionen eines OData-Services getestet werden. Bei einem Lese-Request genügt es, den Request-URI einzugeben und auszuführen. Für einen Create-, Update- und Delete-Request müssen weitere Anpassungen vorgenommen werden, z.B. muss ein mit Daten gefüllter Request-Body angelegt werden. Alle Anpassungen können als Testfälle für die spätere Verwendung gespeichert werden.

Der SAP Gateway Client kann Datenformate wie XML (Atom) und JSON sowohl für OData-V2- als auch für -V4-Services verarbeiten.

Neben diesen beiden Transaktionen gibt es noch viele weitere rund um das SAP Gateway. Alle Transaktionen sind über Drucktasten und Menüeinträge miteinander verknüpft. Daher können Sie aus der Servicepflege in den Mandanten und zurück springen.

SAP Gateway ist in zwei Branches (Laufzeit und Design-Zeit) im SAP-Referenz-Einführungsleitfaden (Transaktion SPRO) verfügbar, bietet jedoch auch viele Transaktionen. Neben dem SAP Gateway Service Builder (Transaktion SEGW) für Entwickler können die Transaktionen in Administration, Verwaltung und Monitoring kategorisiert werden. Wenn eine Transaktion mit IWFND beginnt, wird sie mit der OData-Laufzeit verbunden (für das Hub-Deployment im FES). Wenn sie mit IWBEP beginnt, wird sie mit der Design-Zeit verbunden (für Hub-Deployment in BES).

/IWFND/IWF_ACTIVATE

SAP Gateway für das gesamte System (de-)aktivieren.

/IWFND/ROUTING

Definieren Sie Systemaliasse für den Zugriff auf ABAP-Systeme über RFC.

/IWFND/SOFTSTATE

Aktivieren Sie den Soft-State-Modus für alle SAP-Gateway-Services im System (de-)aktivieren.

Achtung

Lesen Sie den SAP-Hinweis 1986626 – Request konnte vor der Aktivierung nicht im Soft-State-Modus verarbeitet werden.

/IWBEP/GLOBAL_CONFIG

Einstellungen für Protokolle, Traces und Caching.

/IWFND(IWBEP)/CACHE_CLEANUP

Bereinigen Sie den Modell-Cache zur Laufzeit und Design-Zeit.

/IWFND/NOTIF_CLEANUP

Bereinigung von Benachrichtigungen zur Laufzeit und Design-Zeit.

/IWFND/MED_ACTIVATE

Metadaten-Cache für das gesamte System (de-)aktivieren.

/IWFND/APPS_LOG

Zeigen Sie allgemeine Meldungen von Services an.

/IWFND(IWBEP)/ERROR_LOG

Zeigen Sie Fehlermeldungen von Services für Laufzeit und Design-Zeit an.

/IWFND(IWBEP)/NOTIF_MONITOR

Status der Benachrichtigungswarteschlange für Laufzeit und Design-Zeit anzeigen.

/IWFND(IWBEP)/TRACES

Performance- und Payload-Traces für Laufzeit und Design-Zeit ausführen und anzeigen.

/IWFND/STATS

Zeigen Sie die Anforderungsstatistik der Dienste an.

SAP Gateway bietet einige Bereinigungsjobs an, um sicherzustellen, dass die Software mit optimaler Performance ausgeführt wird. Die angegebene Häufigkeit hängt von der Last in Ihrem System ab, um eine Verschwendung von Festplatten- und Speicherplatz zu vermeiden. Der SAP-Referenz-Einführungsleitfaden (Transaktion SPRO) bietet Abschnitte für Bereinigungsaufgaben für FES und BES. Die folgenden Jobs können direkt in SPRO eingeplant werden, die täglich um 3:00 Uhr ausgeführt werden:

SAP_IWFND_SUP_UTIL_CLN

Dieser Job löscht Protokolle von Support-Hilfsprogrammen, z.B. Fehlerprotokolle, Traces und Performance-Protokolle.

SAP_IWFND_APPS_LOG_CLN

Dieser Job löscht SAP-Gateway-Einträge aus dem Anwendungsprotokoll.

SAP_IWFND_NOTIF_CLN

Dieser Job löscht die SAP-Gateway-Benachrichtigungen.

SAP_IWBEP_SUP_UTIL_CLN

Dieser Job löscht Protokolle von Support-Dienstprogrammen, z.B. Fehlerprotokolle, Traces und Performance-Protokolle.

SAP_IWBEP_QRL_CLN

Dieser Job löscht die Einträge des Abfrageergebnisprotokolls.

Zusätzlich zu diesen automatisch eingeplanten Jobs bietet der Report /IWFND/R_SM_CLEANUP mehrere Bereinigungsszenarios. In SPRO kann sie direkt ausgeführt oder als Job mithilfe von Reportvarianten für mehrere Szenarios wie die Bereinigung des Anwendungsprotokoll-Viewers (Szenario /IWFND/CLEANUP_APPSLOG) oder das Fehlerprotokoll (Szenario /IWFND/SUPPORT_UTILITIES) eingeplant werden.

Standardmäßig ist die OData-Kommunikation zustandslos. Es gibt jedoch bestimmte Geschäftsszenarien, die das Caching von Daten benötigen, um die Performance zu verbessern.

Seit SAP Gateway 2.0 SP09 (SAP_GWFND 7.40 SP08) ermöglicht der Soft-State der SAP-Gateway-Laufzeit, mehrere Requests in einer ABAP-Application-Server-Sitzung ähnlich dem zustandsbehafteten Verhalten zu verarbeiten. Der einzige Unterschied besteht im Verhalten des Anwendungsservers nach dem Sitzungs-Timeout: Anstatt die Request-Verarbeitung mit einer Timeout-Ausnahme zu unterbrechen, legt der Server eine neue Session an und verarbeitet den Request wie gewohnt. Der Consumer wird nur beobachten, dass die Antwortzeit länger ist, da Daten, die zuvor im Cache abgelegt wurden, erneut gelesen oder berechnet werden müssen.

Die Session, die vom Internet Communication Framework (ICF) gehalten wird, führt zu einer Session, die im Backend-System über RFC gehalten wird. Dort werden die in der SAP-Gateway-Design-Zeit verarbeiteten Daten (Variablen) im Cache des Datenproviders zwischengespeichert.

Darüber hinaus befindet sich der Cache für Abfrageergebnisse auf Basis des Soft-State (SQRC) im FES. Wenn der Client nur durch eine Ergebnismenge navigieren möchte, kann er als Cache dienen und unnötige Aufrufe an den BES vermeiden.

Über die SAP-Gateway-Serviceverwaltung (Transaktion /IWFND/MAINT_SERVICE) wird der Soft-State für einzelne Services aktiviert, die Soft-State unterstützen. Voraussetzung ist, dass der Session-Timeout für den ICF-Knoten auf einen Wert größer 0 gesetzt wird. Dies kann auch in der SAP-Gateway-Service-Verwaltung über die Drucktaste ICF-Knoten erfolgen.

Die erste Serviceanforderung, die SQRC verwendet, ist deutlich höher als eine ähnliche Anforderung ohne. Die gesamten Daten werden auf einmal aus der Datenbank gelesen und zwischengespeichert. Alle folgenden Requests vor dem Timeout lesen den nächsten Teil der Daten aus dem Cache. Dadurch wird die Anwendungszeit auf 0 reduziert, wodurch auch keine RFC-Kommunikation mit dem BES stattfindet.

SQRC sollte nur verwendet werden, wenn alle der folgenden Bedingungen zutreffen:

• Der Datenabruf ist sehr aufwendig (langsam).
• Das Caching großer Datenmengen muss vermieden werden.
• Im Cache abgelegte Daten werden nicht oft geändert.
• Speicher ist ausreichend verfügbar.

SAP-Systemressourcen sind belegt, solange die Sitzung aktiv ist. Je mehr Services parallel im Soft-State-Modus laufen, desto mehr Ressourcen sind dauerhaft belegt. Daher sollte der Timeout sehr kurz sein. Weitere Informationen finden Sie im SAP-Hinweis 1986626 – Request konnte im Soft-State-Modus nicht verarbeitet werden.