Stateless BSP-Applikationen
Stateless BSP-Applikation blockieren nur dann auf dem SAP Web Application Server Ressourcen, solange ein einzelner Request bearbeitet wird. Nach Abarbeitung des Requests werden alle Ressourcen, also insbesondere der Anwendungskontext, an das System zurückgegeben und für andere Requests eingesetzt.
Stateless Applikation erlauben somit – zumindest aus Sicht der Ressource "Speicher" – eine optimale Skalierung über eine große Anzahl unterschiedlicher Benutzer hinweg. Auf der anderen Seite kann es durch das Freigeben des Anwendungskontext nach jedem Request notwendig werden, Daten mehrfach identisch aus der Datenbank zu lesen und aufzubereiten. Somit wird die Einsparung an Speicher durch Laufzeit möglicherweise kompensiert. Dies ist von Fall zu Fall sehr genau zu analysieren und zu beurteilen.
Daumenregel: stateful oder stateless?
Als Daumenregel kann sicherlich die Empfehlung gelten, daß Internetszenarien, die von einer potenziell sehr großen Anzahl Benutzer gleichzeitig genutzt werden sollen, eher stateless arbeiten sollten. Komplexere Anwendungen, die von einer begrenzten Anzahl Benutzer parallel eingesetzt werden und die über einem teurer zu ermittelnden Datenbestand operieren, bieten sich eher für das stateful Programmieren an.
Informationen im stateless Modus über mehrere Requests retten
Auch - oder gerade - in stateless Applikationen stellt sich die Frage, wie trotz des Verlustes des Anwendungskontextes nach jedem Request, z.B. Benutzereingaben über mehrere Requests hinweg gerettet werden können. Hierzu ist von der Anwendung entsprechende Funktionalität zu programmieren. Als mögliche technische Realisierungen bieten sich an:
Dies kann mit Hilfe von sogenannten HTML hidden-Feldern erfolgen, z.B.:
Es bietet sich an, das Einmischen der Hidden-Felder durch ein Seitenfragment zu realisieren, das in jede Seite der Applikation eingebettet wird. An der Applikationsklasse selbst können die zu rettenden Attribute leicht definiert werden, aus dem Seitenfragment erfolgt dann das Einbetten in jede Website. Im Eventbehandler
OnRequest der Seite (oder besser in der ONREQUEST -Methode des IF_BSP_APPLICATION-Interfaces) erfolgt das Wiederherstellen der Anwendungsattribute aus dem Request (wir arbeiten stateless!). Auf Hyperlinks ist besonderes Augenmerk zu richten und die Einmischung der zu rettenden Parameter in z.B. den Query-String-Teil der URL von der Anwendung vorzunehmen.Hierbei ist zu beachten, dass Größe und Anzahl von Cookies, die in einem Web Client / Browser gespeichert werden können, stark begrenzt sind!
Die BSP-Laufzeit bietet einen generischen Mechanismus – sog. server-side Cookies – die zur effizienten Ablage beliebiger Datentypen und -mengen herangezogen werden können. Details finden Sie unter
Hierbei wird von der Anwendung eine jeweils für die spezifischen Anforderungen zugeschnittene Datenbanktabelle zum Retten der Anwendungsdaten vorgesehen. Im Gegensatz zu den Server-side Cookies können bei diesem Ansatz geeignete typisierte Tabellen zum Einsatz kommen, die Performanzvorteile gegenüber der generischen Lösung haben können. Allerdings ist diese Lösung mit erhöhtem Aufwand für die Anwendungsprogrammierung verbunden (insbesondere die Freigabe des Datenbankeintrages). Zur Identifikation eines Eintrages kann übrigens die Session-ID herangezogen werden, die über das Programmier-Interface
Siehe auch:
Stateful BSP-Applikationen Session-Cookie Mischformen Einstellung als stateful oder stateless Stateful oder stateless programmieren?