Stateful und Stateless BSP-Anwendungen HTTP ist stateless!

Transkript

1 Stateful und Stateless BSP-Anwendungen HTTP ist stateless! (1) Stateful BSP-Programmierung : NWAS: stateful Anwendungskontext über Response hinaus gehalten Bei Weiterführung zvfg. User 1 Session 1 session NWAS "merkt" sich Daten, die zu Anwendung gehören (Rollbereich) + greift bei Fortsetzung darauf zu User 2 Session 2 session Daten auch nach Senden der Response-Seite an Browser für weitere Requests derselben BSP- Anwendung zur Vfg Session Stickness! User 3 Session 3 session Zeit Nachteil : Ressource Laufzeit vs. Ressource Speicher - Hohe Last auf dem Server - Kontextdaten vieler User im Speicher halten - Ressourcen unnötig lange gehalten, wenn User BSP-Anwendung abbricht (Timeout) Vorteil : - Einfachere Programmierung - Daten bleiben zvfg. ( keine Cookies etc nötig ) - Keine erneute Datenbeschaffung + keine wiederholten DB-Zugriffe! HTTP ist ein zustandsloses Protokoll: Nach Antwort eines Servers auf die Anfrage eines Clients hält der Server keine Zustandsinformationen über den Client - jede neue Anfrage des Clients erfordert einen neuen Verbindungsaufbau und erneute Datenbeschaffung. Jedoch wird in einer stateful BSP-Anwendung der Anwendungskontext über die Response (Serverroundtrip) und alle Benutzerinteraktionen hinweg gehalten, bis die BSP-Anwendung beendet ist. Der Anwendungs- / Benutzerkontext wird wie bei einer klassischen R/3-Transaktion im Rollbereich zwischengespeichert und wieder in den zuständigen WAS-Workprozess hineingerollt, wenn die Bearbeitung fortgesetzt wird. Der Anwendungskontext wird über alle Request-Response- Zyklen einer BSP-Anwendung gehalten - die Daten stehen auf jeder Seite über die gesamte Session zur Vfg. Konsequenzen: Auf dem Server wird eine große Last erzeugt: Web-Anwendungen werden meist von vielen Benutzern eingesetzt. Für jeden Benutzer wird Kontext auf dem Netweaver Application Server gehalten und belastet somit dessen Speicherkapazität. Ressourcen werden unnötig lange auf dem Server gehalten: Webbrowser melden sich nicht beim Server ab, wenn ein "flüchtiger" Benutzer zu einer anderen Seite navigiert. Eine offene Sitzung kann somit nicht beendet werden - und verbleibt im Speicher des WAS bis der Timeout- Mechanismus den Kontext freigibt. Da dies einige Zeit dauern kann, werden begrenzte Server- Speicherressourcen unnötig lange blockiert. Ist der Server nicht mehr in der Lage, weitere Daten zu speichern, verweigert er die Erstellung zusätzlicher Sessions, so dass kein weiterer Anwender die Applikation nutzen kann. Die Programmierung ist jedoch leichter zu realisieren: Die Daten stehen beim erneuten Zugriff ohne erneute DB-Abfragen für die komplette BSP-Session zur Vfg. Die Zahl der Datenbankzugriffe ist minimal. Es kann auf Cookies oder Hidden Fields verzichtet werden. Man sollte sich jedoch stets fragen, ob es wirklich nötig ist, die komplette Benutzersitzung permanent aufzubewahren.

2 Session- Handling : SAP-Session- ID (2) HTTP arbeitet stateless Kennt nur unabhängige Requests Nach Response wird Verbindung geschlossen Kein Mechanismus zur Sessionkennzeichnung : Zuordnung mehrerer Request zu einer gemeinsamen Sitzung BSP-LZ generiert Session-ID in Session-Cookie: - Im stateful-fall verschickt sap-contextid - Identifikation mehrerer Requests als Teil einer logischen Session / Anwendung - Gültig bis Sitzungs-Ende - Abfrage über autom. instantiiertes Objekt runtime In allen Eventhandlern + Layout Attribut session_id abgreifbar Explizites Beenden einer Session : navigation exit( 'extit.htm' ). Funktioniert nicht, wenn in Browser- Einstellungen Sitzungs-Cookies nicht zugelassen sind! Data: s_id TYPE string. s_id = runtime session_id. Bewirkt im stateful-fall Abbau des Session-Kontextes + Freigabe aller Ressourcen! Zum Session-Handling dient das globale, automatisch instantiierte Objekt runtime vom Typ IF_BSP_RUNTIME. Über runtime hat man Zugriff auf das Attribut session_id. Dieses enthält einen eindeutigen Sitzungsschlüssel zur Sitzungsidentifikation. (Eine weitere nützliche Methode des runtime-objekts ist get_url(). Diese liefert die URL der aktuellen BSP-Seite zurück.) Allerdings wird nur im stateful-fall dieser Sitzungsschlüssel in Form eines Sitzungs-Cookies an den Client-Browser geschickt (und von diesem mit dem nächsten Request der gleichen Session wieder an den Server). Eine BSP-Session ist der Zeitraum zwischen Start der Applikation durch Aufruf der entsprechenden URL, und Beenden der Applikation. Die Zuordnung von Requests zu einer stateful-bsp-session erfolgt mit Hilfe von Session-Cookies, die von der BSP-Laufzeit erzeugt werden. Sie werden clientseitig als "sap-contextid" im Speicher abgelegt und bestehen auf dem Client nur für den Zeitraum der BSP-Session. Damit ist es der BSP-Laufzeit möglich, den Client-Requests eine eindeutige Session-Nummer anzufügen, um den Request im stateful-fall einer bestimmten Session und dem Applikationskontext zuzuordnen. Bei jedem erstmaligem Aufruf einer neuen BSP-Anwendung wird eine neue session_id vergeben. Eine stateful-bsp-anwendung hält Daten, die der Anwender eingegeben oder angefragt hat (Applikations- / Benutzerkontext), über die komplette BSP-Session hinweg. Der benutzer-spezifische Applikationskontext steht über die einzelnen Request-Response-Zyklen hinaus zur Vfg und wird von Seitenaufruf zu Seitenaufruf aktualisiert. Leider wird die Synchronität zwischen Client und Server durch das Stateful-Zustandsmodell gefährdet und muss vom Entwickler sichergestellt werden: Der Zustand der Anwendung kann sich von der Anzeige im Browser unterscheiden, zb durch Navigieren in der Browser-Historie oder mittels Browser-Back-Button. Ein User kann zu einer Webseite zurück navigieren und diese erneut senden, obwohl die Anwendung mit anderen Anfragen rechnet:

3 Stateless BSP-Anwendungen Nach Absenden jeder Response wird aktueller Benutzerkontext abgebaut und alle Ressourcen freigegeben - Alle Instanzen gelöscht User 1 WAS : stateless request response (3) - Alle Seitenattribut-Werte gelöscht - Alle Anwendungsklassen-Attributwerte gelöscht. User 2 request response Werte bei nächstem Request nicht mehr Vfg. Server ohne "Gedächtnis" - bedient isolierte Requests. User 1 request response Zeit Kompletter Kontextneuaufbau bei jedem Seitenwechsel erforderlich. 1. Seitenattribute In OnInitialization oder Layout wird Wert zugewiesen. In OnInputProcessing verwendbar, Wert dort aber wieder initial 2. Attribute des Applikationsklassen-Objekts Attribute (Einzelwerte und ganze interne Tabellen) nach Response in OnInputProcessing wieder initial Das Stateless-Zustandsmodell hält den benutzerspezifischen Applikationskontext nur für die Dauer eines Request-Response-Zyklus. Eine BSP-Anwendung stateless auszuführen bedeutet, daß für jeden Request ein neuer Applikationskontext erzeugt wird und einschließlich sämtlicher Instanzen nach jeder Response wieder verworfen wird (zustandslos = "gedächtnis-frei"). Ist der Request bearbeitet und die Response an der Browser gesendet, werden alle Ressourcen freigegeben. Der WAS verhält sich somit so, als würde sich jeder Benutzer einer BSP-Anwendung bei jedem Seitenwechsel abmelden und anschließend erneut anmelden. Der Kontext (Inhalt Seitenattributen und die Instanz der Anwendungsklasse mit ihren Attribut-Werten) bleibt nicht über einen Request- / Response-Zyklus hinaus auf dem WAS erhalten - und muss somit bei jedem folgenden Request komplett neu aufgebaut werden. Beispiel: Man weist in einer stateless-bsp einem Seitenattribut im Layout einen Wert zu. Dann kann zwar das Seitenattribut im Eventhandler OnInputProcessing verwendet werden, sein Wert ist dort aber wieder initial! Das gleiche gilt für die Attribute der Applikationsklasse. Anmerkung: Mit Ablauf des Benutzerkontextes wird auch das ABAP-Memory abgebaut, so dass die entsprechenden ABAP-Anweisungen: IMPORT... FROM MEMORY ID... und EXPORT... TO MEMORY ID... nicht sinnvoll einsetzbar sind. Das Verwerfen des Kontextes lässt sich auch in der SAP-Benutzerliste SM04 erkennen: Während des Aufrufs einer BSP-Anwendung erscheint kein Eintrag in der Benutzerliste. Erst wenn man zb in einem Eventhandler einen Beakpoint setzt, erscheint die Sitzung in der Benutzliste! Wird die gleiche Anwendung stateful geschaltet, so wird der Benutzkontext gehalten und führt zu einen Eintrag in der Benutzerliste.

4 Stateless BSP-Anwendungen (4) Nachteil : - Daten neu zu beschaffen, wenn mehrfach benötigt - Erneute Datenbeschaffung + DB-Anfragen - oder: Cookies Vorteil : - Server Ressourcen nur während Request-Bearbeitung beansprucht. Kein Blockieren unnötiger Ressourcen - Bessere Skalierung des Servers - gut für viele Anwender - Browser-Back/Forward-Navigation unproblematisch - Direkter Sprung in beliebige Anwendungsseite unproblematisch Requests Keine "Session Stickness" bei verteiltem SAP-System aus mehreren NWAS Jeder einzelnen Request kann von vorgelagerten WebDispatcher einem anderen NWAS des Systems zugeteilt werden! Web Disp. NWAS 1 NWAS 2 NWAS 3 Verteiltes System Einstellen Zustandsverhalten : In Eigenschaften der BSP-Anwendnung kann stateful oder stateless selektiert werden! Selektives Umschalten zur LZ möglich - gemischte BSP-Anwendung : Setzen des Attributs keep_context des Objekts runtime : Umschalten auf stateful : runtime keep_context = 1. Umschalten auf stateless : runtime keep_context = 0. im Eventhandlercode Vorteil ist die Ressourcennutzung: Auf dem NWAS werden nur während der Bearbeitung eines Requests Ressourcen beansprucht. Sofortiges Verwerfen des Applikationskontext nach Absenden der Response vermeidet unnötige Speicherbelegung durch zahlreiche "flüchtige" Internetuser. Stateless Programmierung führt somit zu einer guten Skalierung des Servers und ist für Web-Anwendungen (viele "flüchtige" Anwender) gut geeignet. Nachteilig ist die hohe Zahl von Datenbankzugriffen. Daten müssen ständig neu beschafft werden: Daten, die mehrere BSPs innerhalb einer BSP-Anwendung benötigen, müssen mehrfach von der DB gelesen werden. Dies führt zu einer höheren Last auf der DB und zu Laufzeitverlängerungen gegenüber dem Stateful-Zustandsmodell. Es gibtlösungen diesen Nachteil zu umgehen (s.u.) Für Applikationen, die keine Statusdaten brauchen, ist stateless (Default) sinnvoller, da nicht unnötig Ressourcen im SAP-System belegt werden. In den Eigenschaften einer BSP-Anwendung läßt sich festlegen, ob die gesamte Anwendung stateful oder stateless gehandhabt wird. Aber es ist auch möglich, zwischen stateful und stateless zur Laufzeit umzuschalten (gemischte BSP-Applikation). Dies wird zur LZ erreicht durch das Setzen des Attributs keep_context des Objekts runtime (Typ if_bsp_runtime). Das Umschalten ist in den Eventhandlern möglich. Typischerweise würde die Anwendung stateful geschaltet, wenn der Anwender Daten eingibt, die im weiteren Verlauf der Anwendung weiterhin benötigt werden. Da stateless BSP-Anwedungen keinen Kontext auf dem NWAS für den User speichern, kann jeder Teilschritt einer Webanwendung von einem anderen NWAS eines verteilten SAP-Systems bearbeitet werden im Gegensatz zu einer klassischen SAP-Anwendung, bei der der User nach seiner Anmeldung (via Message Server) einem bestimmten NWAS fest zugeteilt wird und im Rollbereich dieses NWAS ein entsprechender Userkontext gehalten wird. In einer stateless BSP-Anwendung wird somit Session-Stickness vermieden und die Skalierbarkeit des Systems verbessert! Dagegen erzwingen statefull BSP-Anwendungen Session-Stickness durch das Halten von User-Kontext auf einem der NWAS. Aufeinander folgende Request der gleichen Session können nicht auf verschiedene NWAS verteilt werden, da der Userkontext nur auf einem NWAS gehalten wird.

5 Weitergabe von Seitenattribut-Werten innerhalb BSP 1 Wertübergabe bei impliziter + expliziter Navigation : OnInputProcessing Navigation OnInitialization Bereits behandelt (5) Identisch für stateless / stateful Unterschiedlich für AUTO und Nicht-AUTO-Seitenattribute 2 Seitenattribut : test type string Seitenattribut test füllbar in : 1. OnInitialization 2. Layout On Initialization Layout On InputProcessing Form req. res. req. Wert in OnInputProcessing noch gefüllt und abgreifbar? Browser Browser Formular Request-Response-Zyklus = Kontextlebensdauer BSP 1... Identisch für AUTO / Nicht- AUTO-Seitenattribute Unterschiedlich für stateless und stateful Anwendungen Bereits behandelt wurde die Übergabe von Seitenattribut-Werten aus dem Zeitpunkt OnInputProcessing an OnInitialization. Hier wurden verschiedene Arten der Navigation auf die gleiche oder eine andere BSP unterschieden. Es ging um die Wertübergabe: OnInputProcessing ( Navigation ) OnInitialization Das Verhalten hing nicht davon ab, ob die BSP-Anwendung stateful oder stateless lief. Dagegen war entscheidend, ob es sich um ein Auto-Seitenattribut oder Nicht-Auto-Seitenattribut handelte. Nun betrachten wir die Übergabe von Seitenattribut-Werten aus den Zeitpunkt OnInitialization, Layout und Formbearbeitung an OnInputProcessing. Es geht um die Wertübergabe: OnInitialization / Layout / Formular OnInputProcessing Das Verhalten hängt nicht davon ab, ob es sich um ein Auto-Seitenattribut oder Nicht-Auto- Seitenattribut handelt. Dagegen ist es entscheidend, ob die BSP-Anwendung stateful oder stateless läuft.

6 Weitergabe von Seitenattribut-Werten innerhalb BSP (6) Seitenattribut test gefüllt in: 1. OnInitialization 2. Layout 3. Form Zugriff in: OnInputProcessing Identisch für AUTO / Nicht- AUTO-Seitenattribute Unterschiedlich für stateless und stateful Anwendungen Noch gefüllt + abgreifbar in OnInputProcessing : Seitenattribut stateless stateful gefüllt in : OnInitialization nein ja Layout nein ja Form (Benutzereingabe) ja ja request get_form_field( ) Man bewegt sich in ein und derselben BSP-Seite Dennoch Seitenattribut-Werte nicht ständig verfügbar! BSP-Seitengrenzen nicht identisch mit Umfang eines Request-Response-Zyklus! In der Tabelle ist das Verhalten einer stateful- und stateless-bsp-anwendung gegenübergestellt. Wenngleich man sich ständig innerhalb einer BSP-Seite bewegt, stehen die einmal gefüllten Seitenattribut-Werte nicht ständig zur Verfügung - was eventuell der Intuition widerspricht.

7 Halten von Kontextdaten in stateless BSP- Anwendungen : Hidden Fields + Clientseitige Cookies + Serverseitige Cookies (7) HTTP ist stateless, aber : Betriebswirtschaftliche Transaktionen benötigen internen Zustand = Userkontext Dieser ist der Inhalt der laufenden Session + einem Client = User zugeordnet Abhilfe / Workaround : Zustand als Datenpaket zwischengespeichert - durch Serverprogramm auswertet : Korrekte Fortsetzung der Transaktion Generieren der korrekten Response 1. Unsichtbare Eingabeelemente <input type=hidden > 2. Clientseitige Cookies 3. Serverseitige SAP-"Cookies" auf DB 4. HTML5 : Web Storage ( sessionstorage + localstorage ) Typischer Anwendungsfall : Warenkorb-Zuordnung Ein gutes Beispiel für die Notwendigkeit, den Benutzerkontext (Zustand) aufzubewahren ist der Warenkorb eines OnlineShops: Die Auswahl des Besuchers muss im Warenkorb gespeichert bleiben, selbst wenn zwischendurch die Verbindung unterbrochen wird. Wenn der Kunde, nachdem er einige Waren aufgenommen hat, eine andere Webseite aufsucht und dann zum Onlineshop zurückkehrt, sollen alle Inhalte und Details des Warenkorbes noch vorhanden sein. Dazu müssen diese Informationen als Kontext gespeichert werden. Die Gedächtnisfreiheit von HTTP (und somit das wiederholte Einlesen von Daten) läßt sich auch in einer stateless BSP-Anwendung durch verschiedene Techniken umgehen: a) Unsichtbares Eingabeelement: Ablegen von Daten in einem HTML-Formular durch hidden fields. Diese werden über mehrere Seiten hinweg innerhalb von Forms übertragen. b) Cookies (client- und serverseitig): Das ICF bietet Methoden zum Senden und Empfangen von Cookies. Die Lebensdauer von Cookies kann bestimmt werden.

8 Hidden Fields Für Benutzer unsichtbares Weiterreichen von Formulardaten = Name-Wert-Paare über mehrere Seiten Behandlung analog zu sichtbaren Formularfeldern In BSP mit navigation set_parameter( ) an Folgeseite first.htm <form > Layout <input type = "TEXT" name = "NAME" > <input type = "HIDDEN" name = "user" value = "13" > <input type = "SUBMIT" name = "OnInputProcessing(Opt)" value = "Ab!" > </form > Form 13 Form 13 Form Hidden field (8) Web Server CASE event_id. OnInputProcessing WHEN 'Opt'. navigation set_parameter( 'user' ). navigation goto_page( 'next.htm' ). ENDCASE. next.htm Seitenattribut Auto user X In einem HTML-Formular sind für den Anwender nicht sichtbare, versteckte HTML-Input-Felder vom Typ hidden mit zugewiesenen Werten abgelegt. Nach Versand des Formulars mittels Submit kann das versteckte Textfeld auf dem Server ausgelesen und die Information weiterverarbeitet werden. Der Inhalt versteckter Textfelder (hidden fields) wird innerhalb eines HTML-Formulars versteckt mitgesendet. Diese Informationen sind - analog zu sichtbaren INPUT-Feldern - in Name-Wert-Paaren zusammengefasst. Man nutzt dieses Verfahren, um Variablen, die auf mehreren oder allen Seiten der Anwendung benötigt werden, durchzuschleifen, dh von Seite zu Seite zu übergeben. Für eine BSP ist es irrelevant, ob Werte aus einer Form als Typ = "hidden" oder Typ = "text" beim Request mitgesendet werden. Damit die eingegebenen Daten auch in der Folgeseite verarbeitet werden können, muss in allen Fällen mit navigation set_parameter() der Wert weitergeleitet werden. Die Folgeseite muss ein gleichnamiges Auto-Seitenattribut besitzen, um den Wert entgegennehmen zu können. Mit der Technik der versteckten Felder lassen sich somit Informationen über mehrere Seiten in HTML-Formularen übertragen. Dazu muss das Name-Wert-Paar auch in den Folgeseiten wiederum als hidden field an deren Folgeseiten übertragen werden. Eine typische Anwendung ist die Weitergabe von User- bzw. Rolleninformationen innerhalb einer stateless BSP-Anwendung. Dies kann alternativ natürlich auch mit Cookies geschehen. Es ist nicht möglich, die Werte interner Tabellen auf diese Weise zu übertragen! Zum Weiterreichen derselben hidden fields über mehrere Seiten einer BSP-Anwendung sind Seitenfragmente gut geeignet. Nachteile: Es ist umständlich, die hidden fields in allen relevanten Seiten zu deklarieren. Ferner gibt es browserabhängige Größenbegrenzungen für Formularfelder. Somit eignen sich hidden fields nur für kleine Steuerungs-Kontexte.

9 Client- Cookies HTTP- Cookie : (9) Bis zu 4 KB pro Cookie, nur Strings Request Response Maximal 300 pro Client Maximal 20 pro Server oder Domäne Von Server mit HTTP-Response gesendet HTTP-Client (Browser) Request HTTP-Server Vom Client mit nächsten Request automatisch zur selben Server-URL zurückgeschickt. Lebendauer : - temporär - persisitent (mit Verfallsdatum) Data: booklist type string. OnInputProcessing request get_cookie( exporting name = 'basket' importing value = booklist ). * Cookie-Datenstring booklist in interne Tabelle überführen * Interne Tabelle = Einkaufskorb verwalten * Interne Tabelle wieder in Cookie-Datenstring booklist überführen * response set_cookie( exporting name = 'basket' value = booklist expires = 'TUE, 30-MARCH-13 23:59:59 GMT ' ). BSP-Objekte und Methoden zum Auslesen und Übergeben von Cookies an HTTP Keine internen Tabellen - müssten serialisiert werden SS0-Tickets + SessionIDs werden als nichtpersistente Cookies geführt Lebensdauer + Gültigkeit für eine Session SSO-Cookie = MYSAPSSO2 Eigenschaften eines HTTP-Client-Cookies: Bis zu 4 KByte Textdaten werden vom Server in der angeforderten HTTP-Response eingebettet und mitgesendet. Den Inhalt des Cookies legt der Server fest. Cookies können serverseitig gesetzt und bereits im HTTP-Protokollkopf mitgeschickt werden - oder mittels des JS-Objekts document.cookie clientseitig erst beim Aufbau der HTML-Seite im Browser gesetzt werden. Die Wirkung ist dieselbe: Bei jedem folgenden Request werden die Cookie- Daten im HTTP-Protokollkopf zurück an den Server gesendet. Das Cookie enthält : 1. Die zu sichernde Information - benutzerbezogene Zustandsinformationen, z.b. fortlaufende Nummern für den Zustand einer Transaktion, oder der aktuelle Inhalt eines Warenkorbs. (Name- Wert-Paare). 2. Die Gültigkeitsdauer. 3. Die URL des Ursprungsservers (Domain). Nachteil von Client-Cookies: Da sie Teil des HTTP-Protokolls sind, können sie nur Felder vom Typ String enthalten keine internen Tabellen. Da sie bei jedem Request mitgesendet werden erzeugen Cookies auch Netzlast. Ein Cookie kann von einem Server nicht aktiv angefordert werden. Der Server sendet Cookies zum Browser. Der Client-Browser schickt den Inhalt des Cookies beim nächsten HTTP-Request zum gleichen Server automatisch wieder mit. Die Lebensdauer ist entweder a) temporär - der Browser hält den Cookie nur im Speicher, mit Ende der Browser-Session geht der Cookie verloren. Oder b) persistent - der Browser speichert das Cookie lokal in einem festgelegten Verzeichnis, so dass es in der nächsten Browser-Session wieder ausgelesen werden kann. Der Server gibt dazu dem Cookie ein Verfallsdatum (expiration date) mit, nach dessen Ablauf der Browser den Cookie nicht mehr sendet. Browsereinstellungen legen fest, ob Cookies überhaupt oder erst nach Nachfrage angenommen werden sollen. Sie lassen sich durch den Browseruser abschalten. Somit sind clientseitige Cookies kein sicheres Mittel. Clienseitige Cookies sollten also nicht als "Basisfunktionalität" einer Anwendung eingesetzt werden, sondern allenfalls als Ergänzung. Sicherlich ist es nicht sinnvoll, sensible Daten als Browser-Cookie abzulegen.

10 Client- Cookies Zahlreiche(!) weitere Methoden zur Cookie-Manipulation im Interface IF_HTTP_ENTITY (10) Importparameter von set_cookie( ) Name Typ Bedeutung name String Name des Cookies value String Wert des Cookies domain String Domäne der aufgerufenen Seite. Wenn nicht gesetzt, dann Hostname des sendenden Servers path String Gültiges Verzeichnis auf Server; Default = Pfad der aktuellen Seite expires String Zeitstempel, legt Ende der Lebensdauer fest. Format: Wdy, DD-Mon-YY HH:MM:SS GMT zb Tue, 30-March-12 23:59:59 GMT secure i Wert : 1 Cookie nur über HTTPS-Verbindung sendbar Wert : 0 Cookie auch über ungesicherte Verbindung sendbar Mögliche Aufrufzeitpunkte von : get_cookie: OnRequest, OnInitialization, OnInputProcessing, OnManipulation set_cookie: OnInitialization, OnManipulation Das ICF bietet in IF_HTTP_ENTITY Methoden zum Versenden und Empfangen clientseitiger Cookies. Diese Methoden stehen über die automatisch instantiierten Objekte request und response zur Vfg. Man kann einen beliebigen String im Cookie ablegen. Die Lebensdauer des Cookies ist durch einen Zeitstempel steuerbar: Wenn man kein Verfallsdatum angibt, wird das Cookie beim Schließen des Browsers (Sessionende) gelöscht. Soll das Cookie auf dem Client abgelegt werden, dann muss dem Cookie in der Methode set_cookie() ein Verfallsdatum mitgegeben werden. Cookies mit abgelaufenem Verfallsdatum werden nicht mehr an den Server gesendet. Vom WAS aus können clientseitige Cookies gelöscht werden. Dazu sendet man das Cookie erneut an den Client, datiert das Verfallsdatum jedoch in die Vergangenheit. Das Pfad-Attribut beschränkt das Cookie auf bestimmte Server-URLs. Der Wert '/' drückt aus, das das Cookie für alle URLs auf dem Server gültig ist. Weitere mögliche Werte sind z.b. runtime- >runtime_url oder runtime->page_url. Die Klasse CL_BSP_UTILITY verfügt über die statsiche Methode data_to_string_http, mit der sich ein Zeitstempel im gewünschten Format erzeugen lässt: Data: ts TYPE bsptimestamp, tss(14) TYPE c. ts-date = sy-datum. ts-time = sy-uzeit. tss = ts. Cl_BSP_UTILITY date_to_string_http( timestamp = tss ). Die Objekte request und response stehen mit ihren Methoden nur zu den angegebenen Zeitpunkten zur Vfg. Zu anderen Zeitpunkten kann man sich die aktuellen Instanz-Referenzen über die Referenz page der aktuellen BSP-Seitenklasse beschaffen: Data: response TYPE REF TO if_http_resonse, request TYPE REF TO if_http_request. response = page get_response( ). request = page get_request( ).

11 Cookies auf Server : Serverseitige SAP- Cookies (11) HTTP-Client (Browser) Request Response Request WAS DB Serverseitiges Cookie : Speichern von Kontext in stateless- Anwendungen Server-Cookie : - Speichern von Zustandsdaten, Kontext in DB-Tabelle sscookie - Beliebige Typen und Mengen Einzelwerte, Strukturen, ganze Tabellen - Lebensdauerkonzept - Zugriff durch statische Methoden der Klasse CL_BSP_SERVER_SIDE_COOKIE Vorteil : Ergebnisse komplexer Selects für direkten Wiederzugriff abgelegt Standardprogramme : BSP_SHOW_SERVER_COOKIES : zeigt alle Server-Cookies an BSP_CLEAN_UP_SERVER_COOKIES : löscht alle abgelaufenen Server-Cookies Serverseitigen SAP-Cookies: Serverseitige Cookies sind persistente Daten (Felder, Strukturen, ganze Tabellen) und werden in der DB des Systems abgelegt. Somit ist das Setzen und Lesen eines Server-Cookies ein DB-Zugriff. Sie werden nicht zwischen Client und Server hin und her transferiert. Es existiert ein Verfallszeitmechanismus. Ihr Vorteil: Man kann beliebig viele anlegen und sie haben unbegrenzte Größe. Anwendungsdaten werden in oft komplexen select-anweisungen aus mehreren DB-Tabellen zusammengestellt. Indem man die einmal in einer internen Tabelle gesammelten Daten in Form eines serverseitigen Cookies auf der DB ablegt... vermeidet man wiederholte komplexe Select-Anweisungen, und greift stattdessen die gewünschten Daten in einem einfacheren Zugriff ab. beschränkt man den DB-Zugriff auf die gewünschte Menge. Somit kann der Einsatz von Server-Cookies die Performanz steigern. Die Klasse CL_BSP_SERVER_SIDE_COOKIE stellt Methoden zum Arbeiten mit serverseitigen Cookies zur Vfg. Folgende Standardprogramme sind hilfreich: BSP_SHOW_SERVER_COOKIES : zeigt alle Server-Cookies an BSP_CLEAN_UP_SERVER_COOKIES : löscht alle abgelaufenen Server-Cookies Sollte als periodischer Batch-Job vom WAS-Admin eingeplant werden, da Server-Cookies, deren Verfallszeit abgelaufen ist, nicht automatisch gelöscht werden. Das Programm besteht nur aus einer Zeile: delete from sscookie where expiryd lt sy-datum. Jedoch wird beim Auslesen ein serverseitiges Cookie automatisch aus DB gelöscht. Soll es erhalten bleiben, muss es sofort im Anschluss an den Lesevorgang wieder auf die DB geschrieben werden. Die Verfallszeit kann in Sekunden oder Tagen angegeben werden.

12 SAP-Server-Cookies : CL_BSP_SERVER_SIDE_COOKIE * Server-Cookie Schreiben : Cl_BSP_SERVER_SIDE_COOKIEset_server_cookie ( exporting name = 'booklist' application_namespace = runtime application_namespace application_name = runtime application_name username = sy-uname session_id = runtime session_id data_name = 'it_book_data' data_value = it_book_data expiry_time_rel = 3600 ). Server-Cookie hier angelegt für : - aktuellen User (12) - aktuelle Anwendung - aktuelle Session Nur für diese später auch zugreifbar Server-Cookie auch unabhängig von bestimmter Anwendung, Session, User speicherbar In diesem Fall: application_namespace = 'NONE' application_name username session_id = 'NONE' = 'NONE' = 'NONE' Anwendungsname und Session-ID als Attribute des globalem Objekt runtime in allen Eventhandlern und Layout zur Vfg. Die Methodenparameter von set_server_cookie() und ihre Bedeutung: name username übereinstimmen data_name data_value expiry_time_rel expiry_date_rel expiry_time_abs expiry_date_abs Beliebiger Name des Cookies als String Beleibiger Benutzername als String, muss nicht mit sy-uname Datenname als String muss identisch mit 'data_value' sein Dateninhalte beliebigen Typs, auch interne Tabellen Relative Lebensdauer in Sekunden als Integer Relative Lebensdauer in Tagen als Integer Absolute Lebensdauer als Zeitfeld vom Typ T Absolute Lebensdauer als Datumsfeld vom Typ D Mit den Parametern data_value und data_name werden zu sichernder Datenobjektinhalt und Datenobjektname festgelegt. Dies ist notwending, wel die Cookie-Daten in einer generischen Clustertabelle auf der DB gespeichert werden. Zur endeutigen Identifizierung eines Server-Cookies sind die Session-ID sowie Benutzer- und Anwendungsname geeignet. Diese Werte stehen als Attribute des automatisch instantiierten Objekts runtime zur Vfg. Man kann ein Server-Cookie auch Anwendungs-, Session- und Benutzer-unabhängig ablegen! In diesem Fall würde man den Parametern: application_namespace application_name username session_id einfach zb als Default den String-Wert 'NONE' zuweisen. Auf Server-Cookies deren Vefallszeit abgelaufen ist, kann nicht mehr zugegriffen werden. Sie werden jedoch nicht automatisch aus der DB gelöscht.

13 SAP-Server-Cookies : CL_BSP_SERVER_SIDE_COOKIE (13) * Server-Cookie Lesen Data: ex_d type SYDATE. Data: ex_t type SYTIME. Cl_BSP_SERVER_SIDE_COOKIEget_server_cookie ( exporting name = 'booklist' application_namespace = runtime application_namespace application_name = runtime application_name username = sy-uname session_id = runtime session_id data_name = 'bookshop_data' importing expiry_date = ex_d expiry_time = ex_t changing data_value = it_book_data ). Alle Parameter außer Lebensdauer sind auch beim Auslesen mitzugeben * Server-Cookie Löschen - unahängig von Lebensdauer Cl_BSP_SERVER_SIDE_COOKIEdelete_server_cookie ( ). Alle Parameter (außer der Lebensdauer) müssen auch beim Lesen wieder mitgegeben werden, damit das richtige Cookie gefunden wird. Die Methode get_server_cookie() liefert auserdem die Lebensdauer des Server-Cookies zurück, und zwar als Datums- oder Zeitfeld in Form der SAP-Dictionary-Datentypen SYDATE und SYTIME. Es existiert eine eigene Methode delete_server_cookie(), um das Cookie manuell (unabhängig von seiner Lebensdauer) aus der DB zu löschen: Cl_BSP_SERVER_SIDE_COOKIE delete_server_cookie ( exporting name application_namespace application_name username = 'booklist" = runtime application_namespace = runtime application_name = sy-uname session_id = runtime session_id ). Anmerkung: Der Hauptspeicher des NWAS scheidet zum Zwischenspeichern von Sitzungs-daten aus, da die Session bei jedem Request auf einer anderen Maschine bearbeitet werden kann, falls es sich um ein SAP-System aus mehreren WAS handelt. Die Verteilung des Speicherinhalts auf alle Applikationsserver wäre zu aufwendig.

14 Datenhaltung bei Stateless-Anwendungen Quelle: [WOLF03] (14) via Netzwerk via Datenbank Hidden Field, set_parameter() - Begrenzte Datenmenge - Benötigt keine DB-Zugriffe - Belastet das Netzwerk Client-Cookie - Begrenzte Zahl und Datenmenge - Vom Browser-User abschaltbar - Benötigt keine DB-Zugriffe - Belastet das Netzwerk Server-Cookie + DB-Ablage - Unbegrenzte Datenmenge - Schont das Netzwerk - Belastet die DB-Performanz - Belegt DB-Speicher - Regelmäßiges "Säubern" nötig Stateful oder Stateless : Sehr grosse Zahl gleichzeitiger User Komplexere Anwendung, wenige User, aufwendige DB-Zugriffe stateless stateful Auch - oder gerade - in stateless Applikationen stellt sich die Frage, wie trotz Verlustes des Anwendungskontextes nach jedem Request, z.b. Benutzereingaben über mehrere Requests hinweg gerettet werden können. Hierzu ist entsprechende Funktionalität zu programmieren. Es gibt zwei Verfahrensgruppen - Verwendung des Netzwerks bzw der Datenbank. Je kleiner die zu haltende Datenmenge (bis zu wenigen kb), desto effizienter ist die Netzwerk- Lösung. Wird die bei jeder Benutzeraktion über das Netz zu übertragende Datenmenge größer, resultieren jedoch schnell nicht mehr akzeptable Antwortzeiten. Die Datenbank hat den Vorteil, dass in ihr auch grosse Datenmengen verarbeitet werden können. Allerdings ist die Datenbank der "bottleneck" des SAP-Systems. Daumenregel: stateful oder stateless? Als Daumenregel gilt, daß Internetszenarien, die von einer potenziell sehr großen Anzahl Benutzer gleichzeitig genutzt werden, 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. Stateless BSP-Applikation blockieren nur dann Server-Ressourcen, solange ein einzelner Request bearbeitet wird. Nach Abarbeitung des Requests werden alle Ressourcen an das System zurückgegeben und für andere Requests eingesetzt. Stateless Applikation erlauben somit aus Sicht der Ressource "Speicher" eine optimale Skalierung. Andererseits kann das Freigeben des Anwendungskontext nach jedem Request erfordern, dieselben Daten mehrfach aus der Datenbank zu lesen und aufzubereiten. Somit wird die Einsparung an Speicher durch Laufzeit-Einbußen möglicherweise kompensiert. Dies ist von Fall zu Fall genau zu analysieren und zu beurteilen.

15 Zustände BSP-Anwendung (15) Quelle: Heinemann, Rau 2005 Stateful : Seiten-Objekt bleibt erhalten OnCreate nur einmal durchlaufen! OnDestroy gar nicht! Die Aufrufabfolge der Event-Handler ist abhängig vom Zustandmodell der BSP-Applikation bzw. - Seite, da sich der Aufruf der Events nach der Lebenszeit des BSP-Seitenobjekts richtet. Stateless-Modell: Bei der Bearbeitung eines Request überprüft die BSP-Laufzeit, ob für die angeforderte Seite bereits ein Seitenobjekt existiert. Falls kein Seitenobjekt existiert, wird der OnCreate-Handler aufgerufen und durchlaufen und für die Seite ein Seitenobjekt erzeugt. Auto- Seitenattribute werden übernommen, so dass sie der Seite zur Vfg stehen. Es folgt OnRequest. Falls eine Benutzeraktion voranging, wird OnInputProcessing angestoßen. Dessen Programmcode kann auf eine andere Seite navigieren oder auf der Seite verbleiben. Im ersten Fall wird der OnDestroy-Handler aufgerufen und das Seitenobjekt zerstört. Daraufhin beginnt der Zyklus für die annavigierte Seite von Neuem. Im zweiten Fall würde OnInitialization derselben Seite aufgerufen. Im Anschluss erfolgt das Zusammenführen statischen Layout-HTMLs und dynamischen ABAP-Layout-Codes und die Einbettung in einen HTTP-Datenstrom im OnLayout-Handler. Danach wird OnManipulation aufgerufen; hierin kann der Datenstrom noch verändert werden. Daraufhin wird OnDestroy angestoßen und das Seitenobjekt gelöscht. In OnDestroy bietet es sich im stateless-fall an, Zustandsdaten zu sichern. Abschließend wird der HTTP-Datenstrom an den Client geschickt. Das Stateful-Modell unterscheidet sich im Ablauf der Handler vom Stateless-Modell nur bezüglich des OnCreate- und OnDestroy-Events. Im Statefull-Modell bleiben die Seitenobjekte einer BSP- Applikation für die gesamte Dauer der BSP-Session erhalten. Daher wird OnCreate für jede BSP-Seite nur einmal ausgeführt. Das Event OnDestroy wird im Stateful-Fall überhaupt nicht prozessiert, da während einer Stateful- Session keine Seitenobjekte zerstört werden.

16 Online Text Repository OTR : Internationalisierung (16) Ziel: OTR: Anwendung in mehreren Sprachen (sprachunabhängig) Zentrale paketspezifische Textablage + Dienste zur Texterfassung und Übersetzung OTR-Tags im BSP-Layout verwendbar Textarten : 1. Kurztexte (Aliastexte): Unter Aliasnamen paketweit ansprechbar <%=OTR( Aliasname )%> 2. Langtexte: Direkt in OTR-Tags eingeschlossen <%@page language = "abap" %> <html> <head> <title> OTR-Texte </title> </head> <body> <otr> Dieser Text ist lang und kommt nur einmal vor. Deshalb im OTR als Langtext abgelegt </otr> <center> <%=otr( zbsptest/gruss ) %> </center> </body> </html> Paketname immer Teil des Aliasnamens! <OTR>... </OTR> Alle BSP-Seiten und Seitenfragmente können auf alle OTR-Texte des Pakets zugreifen Pflege der OTR-Texte : a) Kurztexte aus Layout durch Doppelklick auf OTR-Referenz (Vorwärtsnavigation ins Pflegebild für OTR-Texte) b) durch Menü Springen OTR Browser c) durch Direkteinstieg in TA SOTR_EDIT Übersetzung der OTR-Texte : Springen Übersetzung OTR Kurztexte / Langtexte Weitere Infos in [WOLF03] Das OTR ist die zentrale Textablage. Im BSP-Layout können OTR-Direktiven eingesetzt werden. OTR-Objekte sind einem Paket zugeordnet und werden in Transportaufträge aufgenommen. Damit eine BSP-Anwendung in mehreren Sprachen zur Vfg steht, sollte man im Layout alle übersetzungsrelevanten Teile als OTR-Texte angeben. (Übersetzung in TA SE63). Es werden Langtexte und Kurztexte unterschieden, wobei die absolute Länge des abgelegten Textes nicht wesentliches Untescheidungsmerkmal ist. Wichtiger ist die Häufigkeit des Vorkommens: Kommt ein Text nur einmal in einer BSP-Anwendung vor, dann wird der Text als Langtext im OTR abgelegt. Man legt einen Langtext an, indem man im Layout der BSP den Text selbst zwischen die Tags <OTR>... </OTR> schreibt und die Seite aktiviert. Dadurch wird der Text automatisch ins OTR eingetragen. Langtexte stehen für sich selbst, dh sind nicht über einen Aliasnamen oder Schlüssel erreichbar. Wird dagegen ein Text häufig gebraucht, wird der Text unter einem Aliasnamen als Kurztext im OTR abgelegt. Über diesen Aliasnamen ist dieser Text paketweit ansprechbar und somit wiederverwendbar. Die Übersetzung muss nur einmal erfolgen. Das Anlegen von Kurztexten erfolgt durch Schreiben des Tags <%=OTR(Aliasname)%> und Doppelklick auf den Aliasnamen. Auf einem Bildschirmbild kann man den Aliasnamen, die maximale Textlänge und den Text pflegen. Der Aliasname beginnt immer mit dem Namen des zugeordneten Pakets. Um Texte zu übersetzen, muss durch das Menü Springen Übersetzung OTR Langtext in die Übersetzung verzweigt werden. Man erhält einen Überblick über alle dem Paket zugeordneten OTR-Texte im OTR-Browser, erreichbar durch das BSP-Layout-Menü Springen OTR Browser. Im OTR wird auch ein Kontext zu jedem OTR-Objekt (Ersteller, Datum,...) gespeichert.

17 OTR Notation <%=otr( aliasname )%> nur im Layout-Bereich anwendbar. Jedoch auch in Eventhandlern und Anwendungsklasse Zugriff auf Kurztexte mittels runtime-objekt oder Klasse CL_BSP_GET_TEXT_BY_ALIAS : (17) DATA: alias TYPE STRING, text TYPE STRING. alias = ' zbsptest/gruss '. text = runtime get_otr_text( alias ). CL_BSP_GET_TEXT_BY_ALIAS get_text ( exporting language = 'EN' alias = alias importing alias_text = text ). OTR-Texte können in Übersetzungsvarianten unterschiedliche Länge aufweisen Abschneiden überschüssiger Leerzeichen im Layout durch BSP-Seitendirektive : <%@page language="abap" otrtrim="true" %> Die OTR-Referenz <%=otr( aliasname )%> wird intern in einen Methoden-aufruf der runtime-instanz aufgelöst. Der Methodenaufruf cl_bsp-runtime=>get_otr_text() kann auch in den Eventhandlern und der Anwendungsklasse erfolgen - aber auch in Reports und konventionellen ABAP-Programmen außerhalb der BSP-Programmierung. Vertiefung siehe [WOLF03]. Eine Anwendungsmöglichkeit ist die sprachunabhängige Hinterlegung von Fehlermeldungen, die beim Prozessieren der Eventhandler erzeugt werden - oder die Wiederverwendung von Texten auch innerhalb derselben Sprache. OTR-Texte werden auf dem WAS gepuffert - dies macht den Zugriff schnell. Durch das Systemkommando /$otr kann der OTR-Puffer manuelle zurückgesetzt werden, wenn Textänderungen vorgenommen worden sind. Auch mittels der Klasse CL_BSP_GET_TEXT_BY_ALIAS kann auf OTR-Texte zugegriffen werden. Die Klasse hat nur eine statische Methode get_text(). Hier kann auch die gewünschte Sprache als Parameter übergeben werden. Somit können auch Texte in Sprachen verwendet werden, die nicht der Anmeldesprache des Benutzers entsprechen. Damit eine BSP in der gewünschten Sprache angezeigt wird, muss diese Sprache im benutzten Service hinterlegt sein. Dazu werden in der TA SICF Alias-Services eingerichtet. OTR-Texte können Parameter beinhalten. Hierzu wird der Platzhalter für den Parameter durch das & eingeschlossen. Nur Buchstaben, Ziffern und Unterstrich sind erlaubt. Zur Laufzeit wird dann der benannte Platzhalter durch einen Wert (zb Seitenattribut) ersetzt. Wenn man einen OTR-String anlegt und in verschiedene Sprachen übersetzt, so wird die Länge der übersetzten Strings in der Regel in den verschiedenen Sprachen unterschiedlich sein. Ein langer OTR-String könnte sehr kurze Übersetzungen besitzen. Allerdings wird mit dem String in allen seinen Übersetzungen durch das OTR-System stets nur die Länge des Orginal-Strings gespeichert - und liefert somit eventuell OTR-Strings mit überschüssigen Spaces zurück, so dass HTML-Darstellungen unschön verbreitert sind. Die o.a. BSP-Seitendirektive sorgt dafür, dass aus jedem in die Seite eingefügten OTR-Strings überflüssige Spaces entfernt werden.

18 Timeout-Situationen : 1. Session-Timeout Session-Timeout und Processing-Timeout (18) HTTP Server kann nur passiv auf eingehende Client-Requests reagieren. Server merkt nicht, wenn Client abspringt (Browser schliesst, wegnavigiert, untätig ist) Bindet Ressourcen (=Status) auf dem Server Inaktive Sessions nach vorkonfigurierter idle time vom ICM abgeräumt! Ressourcen freigeben, Session gelöscht Maximum idle time : Konfiguriert in Systemprofil-Parameter rdisp/plugin_auto_logout Default : 30 Minuten Gilt für gesamten WAS und alle BSP-Anwendungen. Nicht für einzelne BSP- Anwendungen verlängerbar, Jedoch in SICF verkürzbar Client bekommt timeout allerdings nicht mit, nicht vom Server darüber informierbar. Erst bei nächsten Roundtrip tritt bei User Fehler wegen inaktiver Session auf. Benutzer-Info mittels Workaround : Nach idle time Browser-Fenster via Skript löschen : <script> var T = 31 /*min*/ * 60 * 1000; /*ms*/ window.settimeout( "document.url = 'about:blank' ;", T ) ; </script> Der Session-Timeout bezieht sich auf das Browser-Verhalten: Wenn sich Browser nach Ablauf dieser Zeit nicht mehr meldet wird der Kontext verworfen HTTP ist ein striktes Request/Response-Protokoll; der Server kann nur auf einen Browser-Request hin tätig werden. Der Server kann nicht beim Browser "nachfragen": "Bist du noch da". Er kann höchstens für sich einen internen Timeout setzen und nach dessen Ablauf die Verbindung schliessen. Der Server kann dem Browser zu keinen Zeiten "zwischendurch" Informationen zukommen lassen. Somit kann der Browser auch nicht über eingetretene Session-Timeouts informiert werden. Die Session wird einfach beendet, ohne dass im Browser-Fenster etwas darauf hindeutet. Wenn der User später an seinen Arbeitsplatz zurückkehrt, so sieht er im Browser weiterhin die offene scheinbar noch laufende BSP-Anwendung. Erst bei der nächsten Interaktion tritt ein Fehler auf und der User bemerkt die verlorene Session. Als Hilfe für den User dient das clientseitige JavaScript, das in jede Seite der BSP-Anwendung einzubauen wäre. Solange der User mit der BSP-Anwendung interagiert setzt sich jede neu geladene Seite einen neu initialisiereten Timer. Im Skript gehen wir von einer Server-idle time von 30 Minuten aus. Sollte der User den Browser länger als 31 Minuten nicht bedienen (keine neuen Seiten anfordern) so wird der Brower-Screen gelöscht - und der User bemerkt auf diese Weise, dass die Session serverseitig beendet wurde. Es ist möglich, den Server darüber zu informieren, dass der Browser die BSP-Anwendung verlässt (wegnavigiert oder geschlossen wird), indem das onunload-javascript-event der Seiten verwendet wird und eine JavaScript-Funktion appunload() implementiert wird. Diese wird beim Eintreten von onunload augerufen. Für Details der Lösung (Verwendung von Framesets) verweisen wir auf [MCKE06], S.125ff.

19 Timeout-Situationen : Session-Timeout und Processing-Timeout 2. Processing-Timeout Maximale Prozessdauer für Bearbeitung HTTP-Request durch ABAP-Stack auf Server Bei Überschreiten wird ABAP-Session + BSP-Anwendung abgebrochen (19) Fehlermeldung 500 Connection timed out an Browser In ICM-Verwaltung SMICM eingesehbar : Wird pro offenem HTTP-Port eingestellt Konfigurierbar in Systemprofil-Parameter: icm/server_port Ermöglichen längerer Prozessdauern : Neuen HTTP- Port in SMICM definieren mit längerer maximaler Prozessdauer : Springen Services Service Anlegen und dort Verfügbar nach Neustart NWAS Der "Connection Timeout" ist die Folge eines Überschreitens der maximalen Prozessdauer. Er drückt aus, dass die Verbindung zwischen ICM und ABAP-Stack eine Zeitüberschreitung erfahren hat. Die Fehlermeldung hat nichts zu tun mit einem Session-Timeout (idle timeout). Länger als dieses Zeitintervall darf die Request-Bearbeitung durch die WAS-Workprozesse nicht dauern, sonst wird die Bearbeitung abgebrochen und der User erhält eine Fehlerseite. Wenn dieses Zeit zu knapp eingestellt ist, dann kann nicht mehr richtig debuggt werden, da die Dauer des Debugs einfliesst. In Produktivsystemen ist die maximale Prozessdauer meist auf relativ kleine Werte gesetzt, so dass Workprozesse nicht lange blockiert werden können. Nachteilig kann sein, dass Debuggen von BSP- Anwendungen nicht mehr funktioniert, da der Debug-Vorgang in die Prozessdauer eingeht. Abhilfe schafft das Anlegen eines weiteren HTTP-Ports mit längerer maximaler Prozessdauer. Die URL (Port-Nummer) der BSP-Anwendung muss im Browser entsprechend geändert werden, damit sie beim Aufruf über den neuen Port läuft. Anmerkung: Die keep-alive Zeit (sichtbar in TA SMICM) legt gemäß HTTP1.1 die Zeit in Sekunden fest, die der ICM eine untätige TCP-Verbindung offen hält (und auf einen Browser-Request) wartet, ehe er sie schliesst. Die Wiederverwendung von TCP-Verbindungen verbessert das Antwortverhalten bei HTTP-Requests, da keine erneuten Roundtrips zwischen Browser und Server nötig sind, um eine neue TCP-Verbindung aufzusetzen. Allerdings ist die maximale Zahl gleichzeitig offener TCP- Verbindungen des Servers begrenzt. Deshalb werden nicht verwendete TCP-Verbindungen nach einigen Sekunden idle time geschlossen. Die Profil-Parameter des ICM können in der TA SICM eingesehen werden durch Aufruf des Memüpunkts Springen Parameter Anzeigen. Hier finden sich auch die Einstellungen für maximale Zeitdauern

20 LZ- Fehler-Behandlung (20) Historische BSP Error Pages seit 6.40 inaktiv! BSP Runtime setzt TRY / CATCH um jeden Seitenaufruf. Wenn beim Prozessieren der BSP LZ-Exception auftritt wird Kontrolle an Fehlerseite übergeben Problem : Auch die Fehlerseite ist eine BSP! Nicht sinnvoll bei Schiefstand im BSP-Framework! Neues Konzept ab 6.40 : Wenn Exception auftritt, wird BSP-Framework sofort verlassen + ICF übernimmt Kontrolle ICF-Klasse CL_HTTP_EXT_BSP fängt Fehler aus BSP-Anwendungen + erzeugt generische HTML-Fehlerseite mittels Methode REPORT_ERROR_HTML. Ausprobieren in BSP z.b. mit : <% data: result type i. result = 1 / 0. % > Durch das Konzept der BSP Fehlerseiten konnten in jeder BSP-Anwendung eine oder mehrere BSP-Seiten als Fehlerseiten ausgewiesen werden. Dies geschah einfach durch Setzen eines Eintrags auf der Eigenschaftenseite. Problematisch daran ist, dass es sich bei der Fehlerseite selbst auch um eine BSP handelt. Tritt ein Fehler auf, so startet die Fehlerseite in der fehlerbehafteten Umgebung der Orginal-BSP. Die Fehlerseite hat keine Information darüber, was von der Orginal-BSP bereits in das HTTP response-objekt geschrieben wurde und somit Teil der erzeugten Antwort ist, die an den Client geht. Zudem könnte auch der gesamte BSP-Stack selbst in einem fragwürdigen Zustand sein. Schlimmstenfalls könnte die Fehlerseite selbst einen Fehler auslösen, während sie auf den Fehler der Original-BSP eingeht. Aufgrund dieser Problematik hat SAP ab NWAS 6.40 den Support für das Fehlerseiten-Konzept eingestellt: Alle Fehlerseiten-Einträge auf BSP-Eigenschaftsseiten werden seitdem einfach von der BSP-Laufzeit ignoriert. Allerdings wurde sofort ein neues Konzept ausgeliefert, das BSP-Anwender auch customizen können: Wenn eine LZ-Exception auftritt, so wird das BSP-Framework komplett verlassen und das ICF übernimmt die Kontrolle mit eingestellten Fehlerklassen. Die automatisch erzeugten generischen Fehlerseiten decken die meisten LZ-Fehler-Situationen ab und liefern viele Diagnose-Informationen. Konfigurations-Möglichkeiten: In DB-Tabelle BSPERRHANDLER kann eine andere Fehler-Klasse und ihre Methode hinterlegt werden, die im LZ-Fehlerfall gerufen wird. Mittels Wildcards (*) in der angegebenen URL kann eine Fehlerklasse für eine Gesamtheit von BSP-Anwendungen vorgesehen werden. Die Klasse CL_BSP_ERRHANDLER_SAMPLE enthält ein SAP-Beispiel für eine selbstgeschriebene Fehlerklasse und ihre Methode REPORT_ERROR_HTML. Die Klassen CL_BSP_ERRHANDLER und CL_HTTP_EXT_BSP können als Kopiervorlagen für eigene Fehlerklassen dienen. Man befindet sich dabei jedoch nicht mehr innerhalb des BSP-Frameworks. Somit können BSP Extensions und HTMLB nicht eingesetzt werden! Es ist ein HTML-String zusammenzustellen und dem ICF-response-Objekt zu übergeben: response append_cdata( html ).