WebAppServer_1B.pdf - DHBW Mosbach

Stateful und Stateless BSP-Anwendungen: HTTP ist stateless ! 

Stateful BSP-Programmierung : 

Anwendungskontext über Response hinaus 

gehalten ⇒ Bei Weiterführung zur Vfg. 

NWAS "merkt" sich Daten, die zu Anwendung 

gehören (Rollbereich), greift bei Fortsetzung 

wieder darauf zu: 

Klassisches R/3: Bei jedem SAPGUI-Bildwechsel 

NWAS: Daten auch nach Senden der Response- 

Seite an Browser für weitere Requests derselben 

BSP-Anwendung zur Vfg ⇒ Session Stickness ! 

Nachteil : 

- Hohe Last auf dem Server - Kontextdaten vieler User im Speicher halten 

- Ressourcen unnötig lange gehalten, wenn User BSP-Anwendung abbricht (Timeout) 

Vorteil : 

User 1 

Session 1 

User 2 

Session 2 

User 3 

Session 3 

NWAS: stateful 

session 

session 

- Einfachere Programmierung - Daten bleiben zur Vfg (keine Cookies etc nötig!) 

- Keine erneute Datenbeschaffung + wiederholte DB-Zugriffe ! (Performanz !!) 

session 

Ressource Laufzeit vs. Ressource Speicher 

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. 

(1) 

Zeit

Session- Handling: SAP-Session- ID 

HTTP arbeitet stateless ⇒ Kennt nur unabhängige Requests 

BSP-LZ generiert Session-ID 

in Session-Cookie: sap-contextid 

-Imstateful-Fall verschickt 

Nach Response wird Verbindung geschlossen 

⇒ Kein Mechanismus zur Sessionkennzeichnung : 

Zuordnung mehrerer Request zu einer gemeinsamen Sitzung 

- Identifikation mehrerer Requests als Teil einer logischen Session (Anwendung) 

- Gültig bis zum Sitzungs-Ende 

- Abfrage über autom. instantiiertes Objekt runtime 

In allen Eventhandlern + Layout 

Attribut session_id abgreifbar 

Explizites Beenden einer Session : 

Data: s_id TYPE string . 

s_id = runtime→session_id . 

navigation→exit( 'http://www.sap.com' ) . 

Bewirkt im stateful-Fall den Abbau des Session-Kontextes + Freigabe aller Ressourcen 

(2) 

Funktioniert nicht, wenn in Browser- 

Einstellungen Sitzungs-Cookies nicht 

zugelassen sind !! 

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:

Stateless BSP-Anwendungen 

Nach Absenden jeder Response wird aktueller 

Benutzerkontext abgebaut und alle Ressourcen 

freigegeben ⇒ 

- Alle Instanzen gelöscht 

- Alle Seitenattribut-Werte gelöscht 

- Alle Anwendungsklassen-Attributwerte 

gelöscht. 

Werte bei nächstem Request nicht mehr zur Vfg. 

Server ohne "Gedächtnis" - bedient isolierte 

Requests. 

Kompletter Kontextneuaufbau bei jedem 

Seitenwechsel erforderlich. 

1. Seitenattribute 

User 1 

User 2 

User 1 

In OnInitialization oder Layout wird Wert zugewiesen. 

In OnInputProcessing verwendbar, Wert dort aber wieder initial 

2. Attribute des Applikationsklassen-Objekts 

WAS : stateless 

response 

request 

response 

request 

request 

response 

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. 

(3) 

Zeit

Stateless BSP-Anwendungen 

Nachteil : 

- Daten neu beschaffen, wenn in mehreren BSPs einer Anwendung benötigt 

- Erneute Datenbeschaffung und 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 

Einstellen des Zustandsverhaltens : 

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 ... 

Requests 

(4) 

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 

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 deutlich 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 somit nicht 

auf verschiedene NWAS verteilt werden, da der Userkontext nur auf einem der NWAS gehalten wird. 

Verteiltes System

Weitergabe von Seitenattribut-Werten innerhalb BSP 

1 

2 

Browser 

Wertübergabe bei impliziter + expliziter Navigation : 

OnInputProcessing 

Navigation 

OnInitialization 

On 

Initialization 

req. 

Seitenattribut : 

test type string 

Layout 

Request-Response-Zyklus 

= Kontextlebensdauer 

res. 

BSP 1 

Browser 

req. 

Formular 

On 

InputProcessing 

..... 

..... 

Bereits behandelt .... 

(5) 

Identisch für stateless und stateful 

Unterschiedlich für AUTO und 

Nicht-AUTO-Seitenattribute 

Seitenattribut test füllbar in : 

1. OnInitialization 

2. Layout 

3. Form 

Wert in OnInputProcessing 

noch gefüllt und abgreifbar? 

Identisch für AUTO und 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.

Weitergabe von Seitenattribut-Werten innerhalb BSP 

Seitenattribut test gefüllt in: Zugriff in: 

1. OnInitialization 

2. Layout 


3. Form 

Noch gefüllt + abgreifbar in OnInputProcessing : 

Seitenattribut stateless stateful 

gefüllt in : 

OnInitialization nein ja 

Layout nein ja 

Form (Benutzereingabe) ja request→get_form_field( ) ja 

(6) 

Identisch für AUTO und Nicht- 

AUTO-Seitenattribute 

Unterschiedlich für stateless 

und stateful Anwendungen 

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.

Halten von Kontextdaten in stateless BSP- Anwendungen : 

Hidden Fields + Clientseitige Cookies + Serverseitige Cookies 

HTTP ist stateless, aber : 

Betriebswirtschaftliche Transaktionen benötigen internen Zustand = Userkontext 

Dieser ist der Inhalt der laufenden Session und einem Client zugeordnet 

Abhilfe : 

Zustand als Parameter versteckt / gespeichert, den Serverprogramm auswertet : 

→ Korrekte Fortsetzung der Transaktion 

→ Generieren der korrekten Response 

1. Unsichtbare Eingabeelemente 

2. Clientseitige Cookies 

3. Serverseitige SAP-"Cookies" auf DB 

Anwendungsfall : 

Weitergabe von User- bzw. Rollen- 

Informationen für angemeldete User 

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. 

(7)

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 

CASE event_id. OnInputProcessing 

WHEN 'Opt'. 

navigation→set_parameter( 'user' ). 

navigation→goto_page( 'next.htm' ). 

ENDCASE. 

first.htm 

 

Layout 

 

 

 

 

Form 

13 

Form 

13 

Form 

Hidden field 

13 

13 

(8) 

Web 

Server 

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.

Client- Cookies 

HTTP-Client (Browser) 

Request 

Response 

Request 

HTTP-Server 

(9) 

HTTP- Cookie : 

Bis zu 4 KB pro Cookie, nur Strings 

Maximal 300 pro Client 

Maximal 20 pro Server oder Domäne 

Von Server mit HTTP-Response gesendet 

Vom Client mit nächsten Request automatisch 

zur selben Server-URL zurückgeschickt. 

Lebendauer : 

- temporär - persisitent (mit Verfallsdatum) 

Data: booklist type string. 

OnInputProcessing BSP-Objekte und 

request→get_cookie( 

Methoden zum Aus- 

exporting name = 'basket' 

lesen und Übergeben 

importing value = booklist ). 

von Cookies an HTTP- 

* Cookie-Datenstring booklist in interne Tabelle überführen 

Strom ...... 

* Interne Tabelle = Einkaufskorb verwalten 

Keine internen Tabellen - 

* Interne Tabelle wieder in Cookie-Datenstring booklist überführen 

müssten erst serialisiert 

* ....................................................... 

werden ............ 

response→set_cookie( 

SS0-Tickets + SessionIDs 

exporting name = 'basket' 

werden als nichtpersistente 

Cookies geführt ⇒ 

value = booklist 

Lebensdauer + Gültigkeit für 

expires = 'TUE, 30-MARCH-13 23:59:59 GMT ' ). 

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.

Client- Cookies 

Zahlreiche(!) weitere Methoden zur Cookie-Manipulation 

im Interface IF_HTTP_ENTITY 

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( ) . 

(10)

Cookies auf Server : Serverseitige SAP-Cookies 

HTTP-Client (Browser) 

Request 

Response 

Request 

WAS 

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 

DB 

Serverseitiges 

Cookie : 

Speichern von 

Kontext in 

stateless- 

Anwendungen 

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. 

(11)

SAP-Server-Cookies : CL_BSP_SERVER_SIDE_COOKIE 

* Server-Cookie Schreiben : 

Cl_BSP_SERVER_SIDE_COOKIE ⇒set_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 auch unabhängig von bestimmter Anwendung, 

Session, User speicherbar 

In diesem Fall: application_namespace = 'NONE' 

application_name = 'NONE' 

username = 'NONE' 

session_id = 'NONE' 

(12) 

Server-Cookie hier 

angelegt für : 

- aktuellen User, 

- aktuelle Anwendung 

- aktuelle Session 

Nur für diese später 

auch zugreifbar .... 

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 Beliebiger Name des Cookies als String 

username Beleibiger Benutzername als String, muss nicht mit sy-uname 

übereinstimmen 

data_name Datenname als String – muss identisch mit 'data_value' sein 

data_value Dateninhalte beliebigen Typs, auch interne Tabellen 

expiry_time_rel Relative Lebensdauer in Sekunden als Integer 

expiry_date_rel Relative Lebensdauer in Tagen als Integer 

expiry_time_abs Absolute Lebensdauer als Zeitfeld vom Typ T 

expiry_date_abs 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.

SAP-Server-Cookies : CL_BSP_SERVER_SIDE_COOKIE 

* Server-Cookie Lesen 

Data: ex_d type SYDATE . 

Data: ex_t type SYTIME . 

Cl_BSP_SERVER_SIDE_COOKIE ⇒get_server_cookie ( 

exporting 

name = 'booklist' 




session_id = runtime→session_id 

data_name 

importing 

= 'bookshop_data' 

expiry_date = ex_d 

expiry_time 

changing 

= ex_t 

data_value = it_book_data ) . 

* Server-Cookie Löschen - unahängig von Lebensdauer 

Cl_BSP_SERVER_SIDE_COOKIE ⇒ delete_server_cookie ( .... ) . 

(13) 

Alle Parameter außer 

Lebensdauer sind auch 

beim Auslesen 

mitzugeben ... 

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 = 'booklist" 




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.

Datenhaltung bei Stateless-Anwendungen 

via Netzwerk 

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 

via Datenbank 

Quelle: [WOLF03] 

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 ⇒ stateless 

Komplexere Anwendung, wenige User, aufwendige DB-Zugriffe ⇒ 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. 

(14)

Zustände BSP-Anwendung 

Webbrowser 1 

Webbrowser 2 

Internet 

WAS 

1 

1 

1 

1 

2 

2 

2 

2 

Zeit 

(15) 

stateful stateless 

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 Statefull-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. 

1 

2 

2 

1 

2

Online Text Repository OTR : Internationalisierung 

Ziel: Anwendung in mehreren Sprachen (sprachunabhängig) 

OTR: Zentrale paketspezifische Textablage + Dienste zur Texterfassung und Übersetzung 

OTR-Tags im BSP-Layout verwendbar – Textarten : 

1. Kurztexte (Aliastexte): Unter Aliasnamen paketweit ansprechbar 

2. Langtexte: Direkt in OTR-Tags eingeschlossen 

 

 

 

OTR-Texte 

 

 

 

Dieser Text ist lang und kommt nur einmal vor. 

Deshalb im OTR als Langtext abgelegt 

 

 

 

 

 

 

Paketname immer Teil des 

Aliasnamens ! 

(16) 

 

..... 

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 ..... 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 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.

OTR 

Notation 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 : 

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 : 

 

Die OTR-Referenz 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. 

(17)

Timeout-Situationen : Session-Timeout und Processing-Timeout 

1. Session-Timeout 

HTTP → Server kann nur passiv auf eingehende Client-Requests reagieren. 

⇒ Server merkt nicht, wenn Client abspringt (Browser schliesst, wegnavigiert, untätig ist) 

⇒ Bindet kritische Ressourcen (Status) auf dem Server 

⇒ Inaktive Sessions nach vorkonfigurierter idle time vom ICM abgeräumt ! 

Rollback, Sperren(!) + Ressourcen freigeben, Session gelöscht 

Maximum idle time : 

Konfiguriert in Systemprofil-Parameter rdisp/plugin_auto_logout 

Default : 30 Minuten 

Client-Browser bekommt timeout allerdings nicht mit, nicht vom Server darüber informierbar. 

Erst bei nächsten Roundtrip tritt Fehler wegen inaktiver Session auf. 

Benutzer-Info mittels Workaround : Nach idle time → Browser-Fenster via Skript löschen: 

 

var T = 31 /*min*/ * 60 * 1000; /*ms*/ 

window.setTimeout( "document.URL = 'about:blank' ;" , T ) ; 

 

Gilt stets für gesamten WAS 

und alle BSP-Anwendungen, 

nicht für einzelne BSP- 

Anwendungen verlängerbar, 

jedoch in SICF verkürzbar 

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. 

(18)

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 

⇒ 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 

(19) 

Ermöglichen längerer Prozessdauern : 

Neuen HTTP- Port in SMICM 

definieren mit längerer maximaler 

Prozessdauer : 

Springen → Services und dort 

Service→ Anlegen 

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

LZ- Fehler-Behandlung 

Historische BSP Error Pages → seit 6.40 inaktiv ! 

Neues Konzept ab 6.40 : 

(20) 

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 ! 

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 : 

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 ).

Fehler-Behandlung – Fehlermeldungen erzeugen + verwalten 

ICF-Klasse CL_BSP_MESSAGES erlaubt Speichern + Abfragen von Meldungen 

Referenz darauf durch message-Attribut des page-Objekts: page→messages 

Methoden zum Verwalten selbstverfasster Meldungen aufgrund eigener Prüfungen : 

page→messages→add_message( condition = ' feldname' 

message = ' Hier der erläuternde Text ' 

severity = 1 ). 

if page→messages→num_messages( ) is not initial. 

data: feldname type string. 

data: text type string. 

data: sev type i. 

page→messages→get_message ( 

exporting index = 1 

importing condition = feldname 

mesagge = text 

severity = sev ) . 

endif. 

page→messages→delete_message( condition = 'feldname' ). 

page→messages→reset( ). 

(21) 

Bedeutung der Parameter 

condition : 

Feldname, dem der Fehler 

zuzuordnen ist 

message : 

Beschreibender Meldungstext 

severity (optional) : 

Fehlerschwere (default = Error) 

Durch eigene Prüfungen innerhalb der Anwendung können Fehlersituationen unterschied-licher 

Schwere bemerkt werden. Die zugehörige Information kann mit einem Fehlertext, einer Fehlerstufe 

und der Nennung eines zugehörigen Feldnamens (dessen Werte für den Fehler verantwortlich sind) 

übersichtlich verwaltet werden. Dazu werden einem message-Objekt Informationen übergeben. Ein 

message-Objekt der Klasse CL_BSP_MESSAGES steht als Attribut messages des automatisch 

erzeugten page-Objekts zur Verfügung. 

Es ist möglich, dass mehrere Formularfelder auf einer BSP fehlerhaft sind. In diesem Fall sollte 

(ähnlich wie bei der Dynpro-Verarbeitung) immer nur die erste Fehlermeldung ausgegeben werden. 

Durch den Aufruf der Methode num_messages() kann überprüft werden, ob überhaupt ein Fehler 

aufgetreten ist. 

Eventuell ist es sinnvoll, entsprechende Methoden in der Applikationsklasse zu kapseln. 

Die Klasse CL_BSP_MESSAGES enthält konstante Attribute, durch die die Fehlerschwere 

(Fehlersufen / severity) als Integer codiert werden kann. Die Fehlerschwere ist ein Kennzeichen, durch 

das entschieden werden kann, ob nur eine Warnung ausgegeben werden oder aber die vielleicht die 

gesamte BSP-Anwendung abgebrochen werden soll: 

CO_SEVERITY_ERROR Fehlerstufe: Fehler 

CO_SEVERITY_FATAL_ERROR Fehlerstufe: Fataler Fehler 

CO_SEVERITY_INFO Fehlerstufe: Nur eine Information 

CO_SEVERITY_SUCCESS Fehlerstufe: Erfolgsmeldung 

CO_SEVERITY_WARNING Fehlerstufe: Nur eine Warnung

Einstellung Anmeldedialog 

(22) 

In SICF ist für einen Service das 

Anmeldeverhalten der Anwendung 

einstellbar über: 

Fehlerseiten • Anmeldefehler 

Systemanmeldung • Konfiguration 

Definition service-spezifischer 

Einstellungen möglich, die von globalen 

Einstellungen abweichen 

Mittels Aliases kann sogar für eine Anwendung eine Vielzahl unterschiedlicher Anmeldes-creens 

hinterlegt werden – dies ist insbesondere dann nützlich, wenn man verschiedene interne und externe 

Zugänge zu einer Anwendung unterstützen möchte. Insbesondere können Mandant und 

Anmeldesprache bereits hinterlegt werden. 

Das Look & Feel der Anmeldeseite kann eingestellt werden, indem man auf SAP-Vorlagen 

zurückgreift. Es ist jedoch sogar möglich, ein benutzerspezifisches Layout und Ablauf der Anmeldung 

zu hinterlegen, indem man eine ABAP-OO-Klasse hinterlegt, die von der Klasse 

CL_ICF_SYSTEM_LOGIN erbt. Als Kopiervorlage oder anpassbares Beispiel liefert SAP dazu die 

Klasse CL_ICF_EXAMPLE01_LOGIN aus.

Performance-Analyse 

Anteile im Zeitverbrauch für BSP-Anwendungen : 

1. Reine Netzwerk-Übertragungszeit: Tool ping mit Option -l für variable Datenpaketgröße 

C:\> ping -l 32950 m65z05.hcc.uni-magdeburg.de 

2. BSP-Laufzeit auf NWAS + im Netz für Request-Response-Zyklus 

SAP-BSP-Testprogramm IT03 → Testseiten zwischen 1 und 64 KB 

3. Reine Server-Prozessdauer mittels ABAP-Stopuhr-Funktion GET RUN TIME FIELD 

4. Browser Rendering : Seitenaubau-Zeit mittels JavaScript-Stoppuhr Date() 

 

var renderStart = new Date() ; 

ABAP- und Browser-Stoppuhr- 

....................... 

Funktionen klammern das 

Seitencoding 

 

var renderEnd = new Date() ; 

var renderTime = renderEnd.getTime() - renderStart.getTime(); 

window.status = "Server=" + "" + " Render-Time=" + renderTime ; 

 

Verschiedene Anteile der Ausführungsdauer einer BSP-Anwendung sowie Analyse-Tools: 

Durch das ping-Tool wird die reine Netzwerk-Übertragungszeit gemessen. Das Tool sendet einen 

kleinen Test-Request an den Server (Datengröße einstellbar, default 32 Bytes) und der Server liefert 

einfach die gleichen Daten zurück. Alles passiert auf OS-Ebene und enthält kaum Server-Overhead. 

Die ermitelte Zeit ist die Summe aus Request + Response Zeit. 

Die SAP Demoanwendung IT03 liefert einfach nur Testseiten unterschiedlicher Grösse und 

Zusammensetzung (Text oder Bilder). Dabei sind alle Schichten des WAS beteiligt. Die benötigte Zeit 

ist die Zeit zum Füllen des ABAP-Buffers, übertragen zum ICM Erzeugen von HTTP, Übergabe ans 

Netzwerk und Übermittlung zum Browser. 

Die reine Server-Prozessdauer kann mittels ABAP-Stoppuhr-Funktion gemessen werden, deren 

paarweise Aufrufe die gesamte BSP-Seite einklammern. Das o.a. JavaScript gibt die Zeitdauer in der 

Statusleiste des Browsers aus. Gemessen wird die Zeit, die im Applikationscoding verbraucht wird; sie 

enthält keinen BSP-LZ-Overhead. 

Die Browser-Rendering-Zeit (Aufbau + Darstellung der HTML-Seite) muss im Browser mit JavaScript 

ermittelt werden. Die Differenz zwischen Start- und Endzeit der Seitenbearbeitung wird gemessen. Die 

JavaScript-Aufrufe stehen außerhalb des gesamten HTML-Codes der Seite. 

(23)

Performance-Analyse 

Workbench-Performance-Tools 

Statistical Records : ABAP-Laufzeit ohne ICM-Zeiten 

1. Aktivieren mit ABAP-Programm RSSTATISTIC 

2. BSP-Anwendungen ausführen 

3. TA STAD aufrufen, um die Statistik-Files auszulesen 

Filtern nach Ausführungszeit, User und Programm SAPMHTTP 

(24) 

Doppelklick auf Eintrag 

liefert detaillierte Daten 

zu Zeiten und 

Speicherverbrauch 

Um die aktuelle Server-Prozesszeit zu messen können Statistical-Records verwendet werden. Diese 

schreiben durch das ICF sehr kleine Zeitstempel in die BSP-Anwendung. Die gemessenen Zeiten 

geben die komplette ABAP-Laufzeit wieder. Die Statistik-Optionen sind per Default nicht für HTTP 

aktiviert und müssen gesondert aktiviert werden. 

Zum Auswerten dient die TA STAD. Der Zeitfilter ist entsprechend der Zeit des Tests zu stetzen und 

die Ausgabe auf das Programm SAPMHTTP zu begrenzen. (Dieses Programm ist der allererste 

Aktivierungsschritt, wenn HTTP-Calls auf den ABAP-Stack plaziert werden.) 

Typischerweise dauert der erste Seitenzugriff deutlich länger als nachfolgende Zugriffe auf die 

gleiche Seite. Beim ersten Zugriff muss die ABAP-Load der BSP-Seite aus der Datenbank beschafft 

und in den Programmpuffer geladen werden, so dass ein großer DB-Overhead resultiert, der bei 

folgenden Zugriffen nicht mehr auftritt. 

Laufzeitanalyse: Sehr detaillierte Informationen liefert die Laufzeit-Analyse, deren Daten für eine 

Anwendung in der TA SE30 angezeigt werden. 

1. Die Laufzeitanalyse für BSP-Anwendungen wird aktiviert in der Serviceverwaltung TA SICF. Dort 

den Menüpfad Bearbeiten→Laufzeitanalyse →Aktivieren wählen. 

2. Die zu analysierende BSP-Anwendung ist auszuführen. 

3. In der TA SE30 können die gesammelten Daten analysiert werden. 

Die erfassten Informationen betreffen DB-Zugriffe, Funktions- und Methoden-Aufrufe, Aufruf- 

Hierachien - und ermöglichen auch Sprünge an Sourcecode-Stellen, deren Laufzeitverhalten 

ermittelt wurde ..... und vieles mehr .... 

Die Besprechung dieses reichhaltigen Tools übersteigt jedoch deutlich den Fokus unserer 

Vorlesung. Weitere Informationen finden sich in: Thomas Schneider "SAP-Performanceoptimierung. 

Analyse und Tuning von SAP-Systemen."

BSP-Caching : ICM Server Cache 

Erhöhung Performanz + Skalierbarkeit von BSP-Anwendungen (bis zu Faktor 20) 

→ Für BSP-Erstellung notwendige Server-Ressourcen werden reduziert. 

→ Wiederholte Ausführung häufig angeforderter BSPs entfällt. 

Steuerung des BSP-Caching-Verhaltens 

1. SE80 → BSP-Eigenschaften → Caching 

- Verfallsdauer für Caching im Internet Server-Cache 

- Verfallsdauer für Caching im Browser-Client 

- Browserabhängiges Seiten-Caching 

2. Im Coding der BSP-Applikation durch Methoden von ICF-Klassen 

Kein Eintrag ⇒ Caching 

kommt für Seite nicht zum 

Einsatz ...... 

... aber natürlich doch für Inhalte des 

MIME-Repositories der Anwendung ! 

Seite nur aus Server-Cache 

liefern wenn Request vom 

gleichen Browsertyp kommt 

Mit Objekt response der Klasse CL_HTTP_RSPONSE Verfallszeit des ICM Server-Caches steuern : 

- Relative Verfallszeit festlegen: response→server_cache_expire_rel( ) 

- Absolute Verfallszeit festlegen: response→server_cache_expire_abs( ) 

Durch statische Methoden von CL_HTTP_SERVER Invalidieren + Auffrischen des ICM Server-Cache: 

- Cache-Einträge für Seite : CL_HTTP_SERVER ⇒ server_cache_invalidate( ) 

- Alle Objekte im Server Cache : CL_HTTP_SERVER ⇒ server_cache_invalidate_all( ) 

Quelle: SAP-Bibliothek (Online-Docu) Benchmark Tests für Cache-Treffer im Hauptspeicher haben 

Antwortzeiten von unter einer Millisekunde pro Request und einen Gesamtdurchlauf von über 3000 

Requests pro Sekunde auf einer 4-CPU Hardware ergeben. MIME-Objekte werden nach dem ersten 

Laden automatisch im Server-Cache eingetragen. Bei Änderungen wird der Puffer invalidiert, was 

auch programmgesteuert erfolgen kann. 

Man kann sowohl für den Browser Cache als auch für den ICM Server-Cache bestimmen, wie lange 

die Seite im Cache gehalten werden soll. Wenn nichts angegeben wird, wird der entsprechende 

Cache für die Seite nicht verwendet. Das Kennzeichen Browser abhängig bedeutet, dass der Server 

die Seite nur aus dem Cache holt, wenn der Request vom gleichen Browser-Typ kommt. Wenn das 

Kennzeichen nicht gesetzt ist müssen alle von der Seite verwendeten Elemente browserunabhängig 

sein. Browser-Cache: Der Client kann nicht merken, wenn sich eine Seite geändert hat; er liefert bei 

der gleichern URL immer dieselbe Seite aus dem Cache, bis die Verfallsdauer abgelaufen ist - somit 

ist der Browser-Cache weniger gut kontrollierbar wie der Server-Cache. 

Steuerung des ICM-Server_Caches: Halten von BSPs im Server-Cache 

Man kann die relative Verfallszeit oder eine absolute Verfallszeit angeben sowie auch spezielle 

Cache-Einträge (nicht nur ganze BSP-Seiten) invalidieren - auch in Abhängigkeit von 

Benutzereingaben. 

Durch die Invalidierungs-Methoden kann man stets die Aktualität der gecachten Seite gewährleisten. 

Die Angaben werden vom System automatisch an andere Applikationsserver weitergeleitet, damit 

die Cache-Integrität gewährleistet ist. Man vermeide allzu häufige Invalidierungen, um systemweite 

Übertragungen an andere App-Server zu minimieren. 

Beispiel: response->server_cache_expire_abs( expires_abs_time = '180000 ) . 

Jeden Abend um 18 Uhr wird der Cache-Eintrag invalidiert. Dies kann für Dinge, die einmal täglich 

neu berechnet werden (z.B. aktuelle Preise), sinnvoll sein. 

(26)

NWAS als HTTP-Client 

REPORT ZCLIENTDEMO. 

DATA: myurl TYPE STRING, 

myclient TYPE REF TO IF_HTTP_CLIENT, 

rc TYPE I, 

content TYPE STRING. 

Auf Fehlerhandling 

myurl = 'http://www.sap.de'. 

wurde verzichet ...... 

* Erstellen HTTP-Client : 

cl_http_client=>create_by_URL( 

exporting url = myurl 

importing client = myclient ). 

* Senden Request und Empfangen der Response : 

myclient→send( ). 

myclient→receive( ). 

myclient→response->get_status( importing code = rc ). 

* Abholen Response-Daten im Character-Format: get_cdata() 

* Abholen Response-Daten im Binär-Format: get_data() 

content = myclient→response→get_cdata( ). 

* Schliessen Request und Freigeben der Ressourcen : 

myclient→close( ). 

NWAS kann als Web-Client 

Requests an andere WebServer 

(auch: NWAS) absetzen und 

Response entgegennehmen. 

Zentral ist die Klasse : 

CL_HTTP_CLIENT 

Der NWAS kann auch als Client fungieren: Es kann ein Request an einen HTTP-Server gesendet 

und die Response empfangen werden. Der Request wird mit Methoden des Interfaces 

IF_HTTP_CLIENT aufgebaut, gesendet und die Response empfangen. Als HTTP-Server kann ein 

weiterer SAP NWAS oder auch ein beliebiger anderer Server fungieren. 

Um einen HTTP-Client aufzubauen muss eine gültige URL angegeben werden. Durch Methoden der 

Klasse CL_HTTP_CLIENT kann der Request abgesetzt und und die Response entgegengenommen 

werden. Es ist wichtig, mit der Methode close() die HTTP-Verbindung zu schliesen, damit die 

gehaltenen Systemressourcen wieder freigegeben werden. 

Der Returncode rc enthält den HTTP-Statuscode des Requests und müsste ausgewertet werden. 

"Typische" Werte sind zB : 

rc = 200 (OK) rc = 302 (Redirect) rc = 401 (Authentication Required) 

rc = 500 (Server Error) 

Da der NWAS auch als Web-Client fungieren kann, läßt sich durch BSP-Anwendungen auch eine 

Verknüpfung zwischen verschiedenen Websites herstellen. Auf dieser Basis lassen sich mit dem 

NWAS auch Internetportale zur kollaborativen, unternehmensübergreifenden Geschäftsprozessierung 

realisieren – Stichwort SOA !! 

(28)

Profilpflege NWAS 

Relevante Einstellungen des 

NWAS in Profildateien.pfl im 

NWAS-Filessystem 

Zur Profilpflege RZ10 : 

Werkzeuge → CCMS → 

Konfiguration → Systemprofile 

Infos durch Anzeige von : 

→ Verwaltungsdaten 

→ Grundpflege 

→ Erweiterte Pflege 

Hier auch festgelegt, ob ICM beim 

Starten der Instanz aktiviert wird + 

ob HTTP- und SMTP-PlugIn 

eingebunden und Port zugeordnet 

ist 

(30) 

Auf Fehlerhandling 

wurde verzichet ...... 

Der NWAS wird mit einem Standard-Systemprofil ausgeliefert, dessen einzelne Parameter die 

Performanz des NWAS stark beeinflussen. Dort ist u.a. gepflegt, welche PlugIns des ICMs aktiviert 

und welche Ports ihnen zugeordnet sind. Zu erkennen in der Erweiterten Pflege ist zB der HTTP- 

Server-Port mit dem Wert 8065. 

Alle Profildateien befinden sich im Filesystem des NWAS und werden beim Starten des Systems 

(bzw der Instanz) ausgelesen.

Übersicht BSP-Seiten-Direktiven 

BSP-Direktive Beispiel Bedeutung 

Festlegen Server-Skriptsprache 

Einbinden von Seitenfragmenten 

Skript-Tag 

BSP-Kommentar 

Ausgabe-Tag 

OTR-Kurztext 

Text OTR-Langtext 

 

Wir listen die verschiedenen BSP-Seiten-Direktiven auf, die bei der Entwicklung von BSP-Seiten 

eingesetzt werden können. 

Bis auf das Einbinden von BSP-Extensions haben wir alle Direktiven kennengelernt 

(31)

Bewertung + Einordnung BSP-Technologie 

Nutzung bestehender 

SAP-Anwendungen 

ohne Anpassung 

Neue Anwendungen 

mittleren Umfangs 

Komplette 

Beeinflussung + 

Ausprogrammierung 

von Look & Feel 

Zustandslose Appl. 

Neue Anwendungen 

großen Umfangs 

Übernahme von SAP- 

Oberflächenelementen 

Konventioneller Browser Interner ITS 

Konventioneller Browser 

Mobile Devices mit 

individueller CSS- 

Anpassung 

Ausnutzen HTML5 + JS + CSS 

Alle Plattformen 

Browser 

BSP 

Konventionelle 

Einbettung in ABAP- 

Workbench und 

vertraute ABAP-Welt 

Relativ offenes 

Framework 

(32) 

Web Dynpro 

Durchgängig MVC 

Eigene Begrifflichkeit 

Vorgegebene 

Oberflächenelemente 

Geschlossenes 

Framework 

BSP ist sicherlich nicht die aktuelleste und mächtigste SAP-Web-Technologie. BSP bietet sich jedoch 

an, wenn kleinere und mittlere Web-Projekte mit geringem Aufwand schnell zu erstellen sind. Vorteile 

sind : 

1. Einfache Umsetzung des konventionellen ServerPage-Paradigmas 

2. Aufbau der Oberflächen liegt komplett in der Hand des Entwicklers 

3. Firmenspezifisches Look &Feel und Corporate Identity-Vorgaben lassen sich umsetzen 

4. Wie stark die Komplexität des zugrundeliegenden ICF-Frameworks genutzt wird, liegt in der 

Hand des Entwicklers

Anhang : Fortgeschrittene Techniken 

1. Mails aus BSP 

2. Programmieren eigener ICF-Services + HTTP-Handler 

3. Programmierung eigener BSP-Extensions (Tag Libraries) 

4. MVC mit BSP 

Im Folgenden werden fortgeschrittene Möglichkeiten im BSP-Umfeld besprochen. Zur weiteren 

Vertiefung verweisen wir jedoch auch auf die zur Vorlesung angegebene Literatur ! 

(33)

Mails aus BSPs mittels BCS 

Verwendung Business Communication 

Service 

Voraussetzungen : 

1. SMTP-Plugin im ICM-Profil konfiguriert, zB : 

icm/server_port_1 = PROT=SMTP, PORT=25 

2. In TA SCOT Mailing via SMTP eingeschaltet:: 

Grün hinterlegter Eintrag SMTP 

3. Zuweisung Mail-Domäne an SAP-System 

Beispielcoding im Report ZMAILDEMO 

in Paket ZBSPTEST ....... 

(34) 

Erzeugte Mail und deren Zustand in 

SAPconnect-Administration TA SCOT 

überprüfbar durch Auswahl der 

Sendeübersicht : 

Hilfsmittel → Übersicht Sendeaufträge 

Mit Klick auf Brille email prüfen 

In Empfängerliste stehen Adressaten. 

Der NWAS verfügt über ein SMTP-Plugin, das emails direkt aus BSP-Anwendungen versenden kann, 

sofern der WAS an einen Mailserver gekoppelt ist. Um Mails zu senden müssen einige Objekte 

verschiedener Klassen durch statische Methodenaufrufe erzeugt werden: 

1.Mail-Auftrag erzeugen mittels Klasse CL_BCS und statischer Methode create_persistent(). 

2.Mail-Dokument erzeugen mittels Klasse CL_DOCUMENT_BCS und statischer Methode 

create_document(). Mail-Text wird in interner Tabelle vom Typ character(255) verwaltet. Zu 

sendender Text muss in dieser Tabelle stehen. 

3.Erzeugtes Dokument dem Mail-Auftrag zuordnen durch Instanz-Methode set_document() der 

Klasse CL_BCS. 

4. Festlegen des Senders durch Klasse CL_SAPUSER_BCS und statischer Methode create(). 

5.Erzeugten Sender dem Mail-Auftrag zuordnen durch Instanz-Methode set_sender() der Klasse 

CL_BCS. 

6. Festlegen des Empfängers mittels Klasse CL_CAM_ADRESS_BCS und statischer Methode 

create_internet_adress(), sowie Interface IF_RECIPIENT_BCS. 

7. Empfänger an Mailaufrag übergeben durch Instanz-Methode add_recipient() der Klasse 

CL_BCS. 

8. Mail-Auftrag freigeben durch Instanz-Methode send() der Klasse CL_BCS. Das Senden der Mail 

erfolgt asynchron. 

9. COMMIT WORK. 

In der SAPconnect-Administration (TA SCOT) kann der Erfolg des Mailversands überprüft werden.

Eigene HTTP- Handler 

Vordefinierter BSP- Handler = Klasse CL_HTTP_EXT_BSP 

Eigener HTTP- Handler = Jede ABAP-Klasse die if_http_extension implementiert 

Einziger Methode : handle_request() Zur Requestbearbeitung 

Eingabeparameter : Objekt server Zugriff HTTP-request/ -response 

Methodenaufruf : response→set_cdata() HTTP-Antwort 

METHOD if_http_extension~handle_request. 

data: text type string, info type string. 

info = server→request→get_header_field( '~path' ). 

text = ' Service erreicht! ' 

server→response→set_status( code = 200 reason = 'OK' ). 

server→response→set_cdata( text ). 

if_http_extension~flow_rc = if_http_extension~co_flow_ok. 

ENDMETHOD. 

Attribut if_http_extension~flow_rc steuert Aufruf weiterer Behandler 

Request vollständig behandelt, keine weiteren Handler : 

if_http_extension~flow_rc = if_http_extension~co_flow_ok. 

Nach Ausführung Behandler weitere Behandler : 

if_http_extension~flow_rc = if_http_extension~co_flow_ok_others_opt. 

(35) 

Vorteil 

Totale Kontrolle 

der Request- 

Bearbeitung ohne 

BSP-LZ-Zugriffe 

⇓ 

Leichtgewichtige 

schlanke Services 

Servlet-artige 

Programmierung 

BSPs sind aus Sicht des ICM ledglich eine besondere Art von HTTP-Services, die alle durch den 

speziellen, von SAP ausgelieferten Requestbehandler CL_HTTP_EXT_BSP bedient werden. Dieser 

ist dem SICF-Knoten /sap/bc/bsp zugeordnet. Wird eine BSP-Anwendung über die Workbench 

angelegt, so wird automatisch ein Unterknoten dazu angelegt. Dadurch ist auch automatisch 

sichergestellt, dass die Anwendung vom SAP-BSP-Framework, also dem Behandler 

CL_HTTP_EXT_BSP aufgerufen wird. 

Ein eigener HTTP-Handler ist einfach eine normale ABAP-Klasse die das Interface 

if_http_extension mit seiner einzigen Methode handle_request() implementiert. Deren 

Eingabeparameter ist ein server-Objekt, das HTTP-request und -response-Objekte enthält. Durch 

handle_request() wird ein Request bearbeitet und darin durch Aufruf der Methode 

response→set_cdata() eine HTTP-Antwort erzeugt. Wenn der ICM einen zugehörigen Knoten in der 

Service-Verwaltung gefunden hat, dann wird ein Objekt der Behandler-Klasse instantiiert und deren 

Methode handle_request() aufgerufen. 

Durch wenige Codezeilen kann ein neuer HTTP-Behandler in das ICF eingefügt werden. Vorteil 

selbstgeschriebener Handler ist, dass man totale Kontrolle über die HTTP-request-Auswertung und 

HTTP-response-Erstellung hat. Wenn die Leistungen der BSP-LZ gar nicht benötigt werden, so lassen 

sich auf diese Weise sehr schlanke und performante Lösungen realisieren.

Eigener HTTP- Handler in SICF 

ZCL_HTTP_HANDLER 

Beispiel für resultierende URL : 

Service HandlerTest angelegt in SICF direkt unter default_host : 

http://m65z.hcc.uni-magdeburg.de:8065/handlertest 

(36) 

In SICF muss neuer Service 

angelegt werden 

Pfad im SICF-Baum bestimmt 

URL des Service 

Eigene HTTP-Behandlerklasse 

ist in Handlerliste einzutragen 

Sollen weitere Handler im 

Anschluss aufgerufen werden, 

sind auch sie in gewünschter 

Reihenfolge in Handlerliste 

aufzunehmen 

Das Interface if_http_extension hat ein Attribut namens flow_rc. Dessen Wert steuert, ob nach 

Ausführung des Requests noch weitere Behandler aufgerufen werden sollen oder die Behandlung 

beendet ist. Es stehen in dem Interface dazu vordefinierte Konstanten zur Verfügung: 

Request ist vollständig behandelt, die response wurde komplett erstellt, es sind keine weiteren 

Handler (also auch nicht das BSP-Framework) aufzurufen: if_http_extension~flow_rc = 

if_http_extension~co_flow_ok 

Nach Ausführung des Behandlers sind weitere Behandler aufzurufen. Diese sind in ihrer Aufruf- 

Reihenfolge in der Handler-Liste des Services innerhalb der Service-Verwaltung aufgeführt: 

if_http_extension~flow_rc = if_http_extension~co_flow_ok_others_opt 

Eigene Handler sind als eigener Service in den SICF-Baum aufzunehmen und in die Handlerliste 

aufzunehmen. Da eigene Handler nicht zum BSP-Framework gehören, sollten sie im SICF-Baum nicht 

unterhalb von /sap/bc/bsp eingetragen werden, sondern unter einem separaten Pfad. 

Der Aufruf selbstgeschriebener Handler erfolgt mit einer URL, die neben dem Namen des Servers 

auch den SICF-Pfad enthält. 

Trägt man in der Handler-Liste auch die Klasse CL_HTTP_EXT_BSP ein, so würde im Anschluss 

auch das BSP-Framework aufgerufen werden.

Eigene Tag-Library = BSP-Extension 

* Redefinition Methode in generierter Behandler-Klasse : 

METHOD IF_BSP_ELEMENT~DO_AT_END. 

data: grussformel type string value ' Hallo, & ! ', 

out type ref to if_bsp_writer. 

out = get_previous_out( ). 

replace '&' in grussformel with name. 

out→print_string( grussformel ). 

ENDMETHOD. 

 

 

 

Test eigene Extension 

 

 

 

 

 

 

Tag-Libraries : 

Einheitliche Darstellung von Oberflächenelementen 

+ Präsentationslogik 

Zusammenfassung + Auslagerung 

aufwendiger statischer + dynamischer 

Elemente in Tag-Bibliothek 

⇒ Wiederverwendung + Lesbarkeit ! 

⇒ Einheitliches Layout ! 

⇒ Einbinden als selbstdefinierte 

parametrisierte Tags 

Beispiele: 

Tabellen + Suchen/Sortieren, Trees, Kalender, …. 

Workbench : 

(37) 

1. Anlegen → BSP-Extension 

2. Anlegen → BSP-Element 

3. Attribute für BSP-Element anlegen 

⇒ Behandlerklassen automatisch generiert 

4. Methode(n) der generierten Klasse durch 

eigenes Behandlercoding redefinieren 

⇒ Funktionalität + Attributbelegung 

5. Neue Tag-Library in BSP-Seiten 

anmelden + Tags aufrufen 

Tag Libraries sind ein wichtiges Hilfsmittel bei der Gestaltung der Benutzerschnittstelle. Sie bieten die 

Möglichkeit, wiederkehrende grafische Elemente einheitlich darzustellen. Auch immer gleiche Logik 

zur Präsentation von Daten kann in Tags ausgelagert werden. Der Name Extension bedeutet: Man 

kann den Grundwortschatz der Präsentierungssprache HTML um eigene Tags erweitern. BSP- 

Extensions kommen somit als Erweiterung der HTML-Tags daher und fügen sich besser in das 

Design einer HTML-Seite ein als zahlreiche Scripting-Anweisungen. 

Der Hauptgrund für den Einsatz von Tag Libraries ist die Wiederverwendbarkeit. Immer gleicher 

HTML-Code wird nicht in die Webseiten eingestreut, da man diesen auch als parametrisiertes Tag 

aufrufen kann. Das Layout bleibt lesbar, einheitlich und übersichtlich. Man erreicht mit Tag Libraries, 

gleichbleibenden Code nur einmal implementieren zu müssen. 

Das BSP-Element ähnelt technisch einem Funktionsbausteinaufruf. Die Schnittstelle sind die 

Element-Attribute. So lassen sich variable Teile des zu generierenden Codes durch entsprechende 

Attributwerte steuern. Auf Serverebene stellt sich eine Seite als eine Mischung von HTML- und BSP- 

Elementen dar. Der Server transformiert die BSPElemente in die Zielsprache HTML, die an den Client 

gesendet wird. Die Regeln der Transformation sind in der Implementierung der BSP-Elemente 

verborgen. Der für die Präsentationslogik notwendige Code wird verborgen. In der Seite wird nur das 

gewünschte Layoutelement, geeignet parametrisiert, angesprochen. Die Erzeugung des Codes wird 

an die Elementbehandlerklasse delegiert und gehört somit nicht mehr zur Präsentationsinformation 

der jeweiligen Seite. 

Dadurch, dass die Elementbehandlerklasse von einer automatisch generierten Basisklasse erbt, 

enthält sie automatisch Implementierungen des Interfaces IF_BSP_ELEMENT. Diese sind jedoch alle 

leer. Damit ein BSP-Element etwas Sinnvolles tut, muss man mindestens eine Methode dieses 

Interface redefinieren und mit eigenem Code versehen - wie es oben mit der Methode do_at_end( ) 

geschieht.

Model View Controller Paradigma MVC-Design Pattern 

Konsequente Entkopplung von 

Ablaufsteuerung, Präsentation 

(Layout) und Geschäftslogik in 

separaten Objekten 

Request 

Response 

Methodenaufrufe 

Datenfluss 

Ereignisse 

Kontrollfluss 

Daten- 

Weitergabe 

View-Auswahl 

View-Aufruf 

Controller 

View 

Zustandsabfragen 

 

 

Steuerung 

Steuerung 

Kontrollfluss 

Kontrollfluss 

der 

der 

Anwendung 

Anwendung 

 

 

Events 

Events 

behandeln 

behandeln 

 

 

Daten 

Daten 

an 

an 

View 

View 

geben 

geben 

/ 

/ 

von 

von 

View 

View 

holen 

holen 

 

 

Übersetzen 

Übersetzen 

Benutzereingaben 


für 

für 

Model 

Model 

 

 

Auswahl 

Auswahl 

passende 

passende 

View 

View 

für 

für 

Response 

Response 

Aufruf 

Model 

Zustandsänderungen 

Quelle: OIO, Kursmaterial 

 

 

Visualisieren 

Visualisieren 

der 

der 

Anwendungsdaten 

Anwendungsdaten 

 

 

Darstellung 

Darstellung 

+ 

+ 

Benutzerinteraktion 

Benutzerinteraktion 

 

 

Senden 

Senden 

von 

von 



an 

an 

Controller 

Controller 

(38) 

 

 

Container 

Container 

für 

für 

Geschäftsdaten 

Geschäftsdaten 

und 

und 

Geschäftslogik 


 

 

Kapselung 

Kapselung 

Anwendungszustand 

Anwendungszustand 

 

 

Eigentliche 

Eigentliche 

Datenverarbeitung 

Datenverarbeitung 

durch 

durch 



 

 

Information 

Information 

View 

View 

bei 

bei 

Änderung 

Änderung 

Server 

Architektur entsteht immer durch Zerlegung eines Ganzen in einzelne Komponenten und Definition 

von deren strukturierten Zusammenwirken. Dabei orientiert man sich an typischen Mustern, 

sogenannten Design Patterns. 

MVC führt zu einer besseren organisatorischen und logischen Strukturierung der Anwendung. Es wird 

das Prinzip "Separation of Concerns" umgesetzt, wodurch auch die Wartbarkeit deutlich zunimmt. 

Ohne andere Komponenten zu beeinflussen, können zB die Views oder Teile des Models 

ausgetauscht werden.

MVC mit BSP 

Einbettung in Workbench + 

Forward-Navigation 

Controller 

View 

Model 

BSP-Anwendung zugeordnet Anlegen→ Controller 

BSP-Anwendung zugeordnet Anlegen→ Controller 

 

 

Ablaufsteuerung 

Ablaufsteuerung 

(Flow 

(Flow 

Logic) 

Logic) 

der 

der 

Anwendung 

Anwendung 

durch 

durch 

entsprechende 

entsprechende 

Methoden 

Methoden 

– 

– 

analog 

analog 

BSP-Eventhandlern 

BSP-Eventhandlern 

 

 

Klassen 

Klassen 

erben 

erben 

von 

von 

ICF-Basisklasse 

ICF-Basisklasse 

CL_BSP_CONTROLLER2 

CL_BSP_CONTROLLER2 

 

 

Können 

Können 

Views 

Views 

aufrufen 

aufrufen 

sowie 

sowie 

Model-Objekt 

Model-Objekt 

erzeugen 

erzeugen 

+ 

+ 

ansprechen 

ansprechen 

 

 

Aufrufbar 

Aufrufbar 

mit 

mit 

eigener 

eigener 

URL 

URL 

Endung 

Endung 

.do 

.do 

 

 

Coding 

Coding 

hinterlegen 

hinterlegen 

durch 

durch 

Überschreiben 

Überschreiben 

geerbter 

geerbter 

Methoden 

Methoden 

 

 

Normale 

Normale 

ABAP-OO-Klassen 

ABAP-OO-Klassen 

 

 

Erben 

Erben 

von 

von 

CL_BSP_MODEL 

CL_BSP_MODEL 

 

 

Zahlreiche 

Zahlreiche 

geerbte 

geerbte 

Methoden 

Methoden 

 

 

Frei 

Frei 

definierbare 

definierbare 

eigene 

eigene 

Methoden 

Methoden 

+ 

+ 

Attribute 

Attribute 

zur 

zur 

Darstellung 

Darstellung 

der 

der 

Logik 

Logik 

 

 

Direkt 

Direkt 

via 

via 

ClassBuilder 

ClassBuilder 

angelegt 

angelegt 

 

 

Aufrufe 

Aufrufe 

erfolgen 

erfolgen 

aus 

aus 

Methoden 

Methoden 

der 

der 

Controller-Klasse 

Controller-Klasse 

 

 

BSP-Anwendung 

BSP-Anwendung 

zugeordnet Anlegen → Seite → View 

zugeordnet Anlegen → Seite → View 

 

 

Haben 

Haben 

keine 

keine 

eigene 

eigene 

URL 

URL 

– 

– 

nicht 

nicht 

direkt 

direkt 

aufrufbar 

aufrufbar 

 

 

Vom 

Vom 

Controller 

Controller 

aufgerufen 

aufgerufen 

+ 

+ 

mit 

mit 

Daten 

Daten 

versorgt 

versorgt 

 

 

Haben 

Haben 

Eigenschaften, 

Eigenschaften, 

Layout, 

Layout, 

Seitenattribute 

Seitenattribute 

 

 

Keine 

Keine 

Eventhandler, 

Eventhandler, 

keine 

keine 

Auto-Seitenattribute 

Auto-Seitenattribute 

Der Controller beinhaltet die Steuerungslogik der Anwendung. Er reagiert auf User-Input und 

Ereignisse und verteilt Aufgaben an die View und das Model. Innerhalb BSP besteht der Controller 

aus zwei separaten Teilen: 1. Das Controller-Eigenschaften-Objekt mit den Attributen des 

Controllers (Verwaltungsinformationen, URL, Zustandsverhalten) 2.Eine zugeordnete ABAP-OO- 

Klasse, die von der BSP-Systemklasse CL_BSP_CONTROLLER2 erbt. Diese Klasse enthält die 

eigentliche Controller-Logik; in ihr wird der ABAP-Code hinterlegt, der die Aufgaben des Controllers 

umsetzt. 

Im Gegensatz zu BSP-Seiten können Views nicht direkt von Außen aufgerufen werden. 

In einer BSP-Anwendung können sowohl Seiten mit Ablauf-Logik als auch Controller und Views sowie 

Model-Klassen vorhanden sein. Je komplexer eine BSP-Anwendung ist, desto eher lohnt sich der 

zusätzliche Aufwand des MVC-Patterns. 

Zur Umsetzung von MVC in einer BSP-Anwendung sind ABAP-OO-Kenntnisse erforderlich, 

insbesondere auch Vererbung, Überschreiben von Methoden und das Prinzip der Polymorphie. Da 

separate ABAP-OO-Klassen angelegt werden, bekommt man in der Workbench alle Elemente der 

entsprechenden BSP-Anwendung (inklusive der Klassen) nur in der Paket-Sicht zu Gesicht. 

Auf die sehr mächtigen Möglichkeiten des DataBindings zwischen Views und Models können wir hier 

nicht eingehen. Wir verweisen dafür auf die Literatur, insbesondere auf : 

B. McKellar T.Jung : Advanced BSP Programming, Kapitel 13 

(39)

MVC mit BSP 

Controller-Eigenschaften 

View-Seiten haben keine eigene URL, keine 

Eventhandler, keine Auto-Seitenattribute …. 

Controller-Bestandteile = (40) 

1. Controller-Eigenschaften + 

2. Controller-Klasse / -Objekt 

Bei Anlegen von Controllern in 

Workbench wird Name der 

Controller-Klasse genannt 

Durch Vorwärtsnavigation kann 

man im ClassBuilder Methoden 

überschreiben 

CL_BSP_CONTROLLER2 dabei 

automatisch als Superklasse 

gesetzt 

View-Eigenschaften 

Im Gegensatz zu BSP-Seiten können Views nicht direkt von Außen aufgerufen werden. Sie verfügen 

auch nicht über Eventhandler – denn die Geschäftslogik liegt im Model und die Kontrollflusssteuerung 

im Controller.

Verarbeitungs-Ablauf im Controller 

Controller repräsentiert Ablaufsteuerung einer BSP-Seite (Flow Logic) 

Durch Methoden und deren definierten Aufruf realisiert - BSP-Runtime besorgt Aufrufe 

Analog : Eventhandler einer konventionellen BSP-Seite mit Ablauflogik 

Konventionelle BSP-Seite 

OnCreate 

OnInitialization 

OnRequest 

Layout 


OnManipulation 

Hier nur Grundlagen. Mächtige Möglichkeiten für Data- 

Bindung und automatischer Datenübertragung : 

B. McKellar T.Jung : Advanced BSP Programming 

Kapitel 13 

Controller-Methoden und ihre Bedeutung : 

MVC-Controller-Klasse 

DO_INIT 

DO_INITATTRIBUTES 

DO_REQUEST 

DO_HANDLE_DATA 

DO_HANDLE_EVENT 

DO_FINISH_OUTPUT 

CALL_VIEW , Dispatch_Input 

Festlegen der Ablauflogik durch Überschreiben 

(Redfinieren) dieser von CL_BSP_CONTROLLER2 

geerbten Methoden in der eigenen Controller-Klasse 

ClassBuilder : Redine-Button im Methoden-Tab für selektierte Methode 

DO_INIT : Diese Methode wird bei der Erzeugung der Controller-Instanz aufgerufen. Hier kann z. B. ein Objekt 

einer Model-Klasse erzeugt werden. Wird bei stateful-Anwendungen nur einmal gerufen. 

DO_INITATTRIBUTES : Ist mit dem BSP-Eventhandler Onlnititialization vergleichbar. 

DO_REQUEST : Zentrale Methode für Eingabe-/Ausgabe-Steuerung. Steuert die folgenden spezialisierten 

Methoden für Input-Verarbeitung: 

DO_HANDLE_DATA sorgt dafür, dass die Model-Klasse mit Daten gefüllt wird. Daten der Formfelder und 

Nachrichten werden übergeben. DO_HANDLE_EVENT gibt den Parameter GLOBAL_EVENT aus und füllt im 

Fall von Events, die von BSP-Elementen ausgelöst werden, das HTMLB-Event-Objekt. DO_FINISH_INPUT 

reagiert mithilfe des GLOBAL _EVENT-Parameters auf Ereignisse. Es ist die letzte Methode der 

Eingabeverarbeitung. 

Eintreffende Client-Requests werden direkt an den Hauptcontroller geleitet mittels des URL-Aufrufs. Nach 

DO_INIT und DO_INITATTRIBUT wird die zentrale Methode DO_ REQUEST aufgerufen. Von dieser Methode 

können eingehende Daten an eventuelle Subcontroller weitergeleitet werden. Dies übernimmt die Methode 

DISPATCH_INPUT. Sie liest die Daten aus den Formfeldern des Request-Objekts aus und leitet sie an die 

jeweils adressierten Subcontroller weiter. Ferner sogt diese Methode dafür, dass die Methoden 

DO_HANDLE_DATA, DO_HANDLE_EVENT und DO_FINISH_INPUT aufgerufen werden 

Daten, die für den Hauptcontroller bestimmt sind, werden innerhalb von DO_REQUEST durch die Methoden 

DO_HANDLE_DATA, DO_HANDLE_EVENT und DO_FINISH_INPUT verarbeitet. Subcontroller verarbeiten 

ihnen zugeordnete Daten ebenfalls über ihre Implementation dieser Methoden. 

Zur Ausgabeverarbeitung werden ein oder mehrere Views erzeugt und aufgerufen. Dies wird mittels der Methode 

CALL_VIEW ausgeführt. Controller können auf den Status inaktiv gesetzt oder neue Controller erzeugt werden. 

(41)

MVC mit BSP – typische Strukturen 

Model 

Controller 

Aufrufe 

Ein Controller kann mehrere Views 

nacheinander ansteuern …… 

BSP-Anwendung 

Controller 1 

Model 1 

Aufruf 

View 1 

View 1 

View 1 

View 1 

Controller 2 

Model 2 

Aufruf 

View 2 

BSP-Seite 

Model 

Controller 

Ein übergeordneter Haupt-Controller 

steuert die Verteilung der Anwendungslogik 

durch Aufruf von Sub-Controllern …. 

Controller 3 

Model 3 

Aufruf 

View 3 

Aufrufe 

Model 1 

Model 2 

Model 3 

Jede einzelne "BSP-Seite" implementiert alle 

drei MVC-Komponenten. Views durch 

zugeordnete Controller gerufen ….. 

(42) 

Controller 1 

Controller 2 

Aufruf 

View 2 

Aufruf 

View 1 

Controller 3 

Aufruf 

View 3 

In einer BSP-Anwendung können sowohl Seiten mit Ablauf-Logik als auch Controller, Models und 

Views vorhanden sein. Aus einem Controller können auch Controller anderer BSP-Anwendungen 

aufgerufen werden. 

Je komplexer eine BSP-Anwendung ist, desto eher lohnt sich der zusätzliche Aufwand des MVC- 

Patterns. Es gibt eine Vielzahl von Kombinationsmöglichkeiten. Insgesamt nimmt die Wartbarkeit der 

Anwendung zu, da eine saubere Trennung und Strukturierung nach MVC-Anteilen besteht. 

Einzelnen Komponenten können relativ leicht ausgetauscht werden. 

Da der Umgang mit dem MVC-Pattern relativ komplex ist und Einarbeitungszeit erfordert, hat SAP 

im WebDynpro-Programmiermodell die Anwendungsentwicklung durch grafische Entwicklungsanteile 

vereinfacht, durch die das MVC-Grundgerüst automatisch generiert wird. 

Durch den Controller können Views aufgerufen und an deren Seitenattribute Daten übergeben 

werden. Dazu könnte auch die Referenz auf ein Model-Objekt gehören! (Es ist aber auch möglich, den 

HTML-Datenstrom direkt in der Methode do_request() mit der Methode write() zu erzeugen.) 

Aus einem Controller kann ein SubController-Objekt erzeugt und diesem auch gleich ein Model- 

Objekt übergeben werden. Dazu dienen die geerbten Methoden create_controller( ) und 

set_model(). 

SubController können auch dynamisch aktiviert und deaktiviert werden, so dass sie nicht 

überflüssigerweise abgearbeitet werden. Dazu dient ebenfalls eine geerbte Methode: 

controller_set_active( controller_id = 'sub1' active = 0 ).

Controller-Methoden überschreiben 

METHOD do_init. " Einbinden Model-Objekt, DB-Zugriffe, ….. 

model ?= create_model( model_id = 'm1' class_name = 'Z_M_DEMO' ). 

model→carrid = 'LH'. 

model→read_flight_data( ). " Datenbeschaffung + Geschäftslogik …… 

ENDMETHOD. 

Zentrale Methoden der Controller-Klasse 

METHOD do_request. " Redefintion / Überschreiben 

data: view type ref to if_bsp_page. " View-Objekt 

data: input type string. 

input = request→get_form_field( name = 'input' ). 

dispatch_input( ). " Trigger Eingabe-Verarbeitung + Events 

if input = 'Einstieg'. 

view = create_view( view_name = 'main.htm' ). call_view( view ). 

else. " View mit Werten versehen 

view = create_view( view_name = 'next.htm' ). 

view→set_attribute( name = 'text' value = sy-uname ). 

call_view( view ). 

endif. 

ENDMETHOD. 

(43) 

Ziel : 

Erzeugen Modell- und View-Objekte. 

Model-Objekte als Controller-Attribute 

verwaltet 

Möglichkeiten : 

1. Request-Datenzugriff, View 

erzeugen, View-Seitenattribute 

übergegen, View rufen. 

2. Aus Controller verschiedene Views 

aufrufbar. 

3. Controller kann andere Controller 

aufrufen. Hierarchie von Controllern ! 

4. Aus View sind Controller aufrufbar 

oder Redirects möglich …….. 

View next.htm 

 

 

 

Aufruf View 

 

 

Benutzer 

 

 

Eine Controllerklasse verfügt typischerweise über Attribute vom Typ der verwendeten Models und instanziiert 

entsprechende Objekte in seiner Methode do_init(). Jeder erzeugten Model-Instanz wird eine ID gegeben. Auf diese Weise 

sind sie auch in dem geerbten Attribut M_MODELS des Controller-Objekts unterscheidbar. Es existieren geerbte Methoden 

SET_MODEL, GET_MODEL, CREATE_MODEL, DELETE_MODEL im Controller, durch die gespeicherte Liste der Model- 

Objekte verwaltet werden kann. Der Controller kontrolliert somit auch die Erzeugung von Model-Objekten und deren 

Lebensdauer. 

MVC wird typischerweise in stateful BSP-Anwendungen verwendet. Grund ist, dass es aufwendig ist, in stateless- 

Anwendungen die erforderlichen Controller- und Model-Objekte immer wieder neu zu erzeugen und insbesondere deren 

korrekten internen Zustand konsistent zu rekonstruieren. Das Controller-Objekt enthält als Attribut eine Tabelle mit 

Referenzen auf erzeugte Model-Objekte. In stateless-Anwendungen müsste diese Tabelle erst immer wieder hergestellt und 

die darin enthaltenen Model-Objekte zustandsmäßig korrekt rekonstruiert werden. Allerdings existieren Techniken mit denen 

man Model-Instanzen zwischenspeichern und wiederherstellen kann. Dazu gehören die Serialisierung und Deserialisierung 

von Model-Objekten als XML-Strings und deren Zwischenspeicherung als Server-Cookie. 

Der Aufruf der Methode dispatch_input() sogt dafür, dass alle für die Eingabe-Verarbeitung erforderlichen Events ausgelöst 

werden und alle dafür vorgesehenen Controller-Methoden aufgerufen werden. Diese Methode muss nur einmal aus dem 

Haupt-Controller aufgerufen werden. 

Aus einem Controller können andere Controller gerufen werden, so dass neben Haupt-Controllern auch Sub-Controller 

definiert werden können: 

data: ctl type ref to zcl_bsp_subcontroller . 

ctl ?= create_controller( controller_name = 'sub1.do' controller_id = 'sub' ) . 

ctl→testdata = 'Irgendwas'. 

call_controller( controller_instance = ctl ). " Aufruf aus Hauptcontroller. Dieser behält Kontrolle 

* navigation->goto_page( 'sub1.do' ). " Navigation zu Subcontroller: Hauptcontroller wird abgebaut: 

Auch aus einer View lässt sich mittels BSP-Extensions eine anderer Controller aufrufen : 

 

Auch Redirects sind möglich:

WebAppServer_1B.pdf - DHBW Mosbach

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?