(1)Stateful und Stateless BSP-Anwendungen HTTP ist stateless !

Stateful BSP-Programmierung :

Anwendungskontext über Response hinausgehalten � Bei Weiterführung zVfg.

NWAS "merkt" sich Daten, die zu Anwendung gehören (Rollbereich) + greift bei Fortsetzung darauf zu

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 :

- Einfachere Programmierung - Daten bleiben zVfg. ( keine Cookies etc nötig )

- Keine erneute Datenbeschaffung + keine wiederholten DB-Zugriffe !

User 1Session 1

User 2Session 2

User 3Session 3

NWAS: stateful

Zeit

session

session

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

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: sap-contextid

- Im stateful-Fall verschickt

- 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

Data: s_id TYPE string .

s_id = runtime→→→→session_id .

Explizites Beenden einer Session :

navigation→→→→exit( 'extit.htm' ) .

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

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 desruntime-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-Sessionerfolgt 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-Zustandsmodellgefä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

- Alle Seitenattribut-Werte gelöscht

- Alle Anwendungsklassen-Attributwerte

gelöscht.

Werte bei nächstem Request nicht mehr Vfg.

Server ohne "Gedächtnis" - bedient isolierteRequests.

Kompletter Kontextneuaufbau bei jedem Seitenwechsel erforderlich.

User 1

User 2

User 1

WAS : stateless

Zeit

request

response

request

response

request

response

1. SeitenattributeIn OnInitialization oder Layout wird Wert zugewiesen.

In OnInputProcessing verwendbar, Wert dort aber wieder initial

2. Attribute des Applikationsklassen-ObjektsAttribute (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 Requestbearbeitet 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-AnwendungenNachteil :- 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

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

Keine "Session Stickness" bei verteiltem SAP-System aus mehreren NWAS �

Jeder einzelnen Request kann von vorgelagerten WebDispatcher einem anderen NWAS des Systems zugeteilt werden !

NWAS 1

NWAS 2

NWAS 3

Web

Disp.

Verteiltes S

ystem

Requests

� 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. StatelessProgrammierung 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 statefuloder 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

Identisch für stateless / stateful

Unterschiedlich für AUTO und Nicht-AUTO-Seitenattribute

.....On InputProcessing

Browser

On Initialization Layout

Browser

req. req.res.

Request-Response-Zyklus

= Kontextlebensdauer

BSP 1

Formular

Seitenattribut :

test type string

Seitenattribut test füllbar in :

1. OnInitialization

2. Layout

3. Form

Wert in OnInputProcessingnoch gefüllt und abgreifbar?

Wertübergabe bei impliziter + expliziter Navigation :

OnInputProcessing OnInitializationNavigation

Bereits behandelt

1

2

Identisch für AUTO / Nicht-AUTO-Seitenattribute

Unterschiedlich für statelessund 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 statelessläuft.

(6)Weitergabe von Seitenattribut-Werten innerhalb BSP

Identisch für AUTO / Nicht-AUTO-Seitenattribute

Unterschiedlich für statelessund stateful Anwendungen

Noch gefüllt + abgreifbar in OnInputProcessing :

Seitenattribut stateless statefulgefüllt in :

OnInitialization nein ja

Layout nein ja

Form (Benutzereingabe) ja jarequest→get_form_field( )

Seitenattribut test gefüllt in: Zugriff in:

1. OnInitialization

2. Layout

3. Form

OnInputProcessing

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

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 zwischendurchdie 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 Kontextgespeichert 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 hiddenfields. 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 FieldsFü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

Form

Form

Form

WebServer

13

13

Hidden field13

13

CASE event_id.WHEN 'Opt'.

navigation→→→→set_parameter( 'user' ).navigation→goto_page( 'next.htm' ).

ENDCASE.

<form ><input type = "TEXT" name = "NAME" >

<input type = "HIDDEN" name = "user" value = "13" >

<input type = "SUBMIT"name = "OnInputProcessing(Opt)" value = "Ab!" >

</form >

Layout

OnInputProcessing

Seitenattribut Autouser X

…

next.htm

first.htm

� 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 verstecktmitgesendet. Diese Informationen sind - analog zu sichtbaren INPUT-Feldern - in Name-Wert-Paarenzusammengefasst. 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" beimRequest mitgesendet werden. Damit die eingegebenen Daten auch in der Folgeseite verarbeitetwerden 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 wiederumals 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 sindSeitenfragmente 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-Server

Request

Response

Request

HTTP-Client (Browser)

HTTP- Cookie :Bis zu 4 KB pro Cookie, nur StringsMaximal 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.

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

OnInputProcessing BSP-Objekte und Methoden zum Aus-lesen 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 derangeforderten 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. fortlaufendeNummern 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 zumBrowser. Der Client-Browser schickt den Inhalt des Cookies beim nächsten HTTP-Request zumgleichen Server automatisch wieder mit.

� Die Lebensdauer ist entweder a) temporär - der Browser hält den Cookie nur im Speicher, mit Endeder 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 wiederausgelesen 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 durchden Browseruser abschalten. Somit sind clientseitige Cookies kein sicheres Mittel. ClienseitigeCookies sollten also nicht als "Basisfunktionalität" einer Anwendung eingesetzt werden, sondernallenfalls 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

Mögliche Aufrufzeitpunkte von :get_cookie: OnRequest, OnInitialization, OnInputProcessing, OnManipulation

set_cookie: OnInitialization, OnManipulation

Importparameter von set_cookie( )Name Typ Bedeutungname 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 sendbarWert : 0 Cookie auch über ungesicherte Verbindung sendbar

� Das ICF bietet in IF_HTTP_ENTITY Methoden zum Versenden und Empfangen clientseitigerCookies. Diese Methoden stehen über die automatisch instantiierten Objekte request und responsezur 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 Cookiein 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

WAS

Request

Response

Request

HTTP-Client (Browser)

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.

(12)SAP-Server-Cookies : CL_BSP_SERVER_SIDE_COOKIE

* Server-Cookie Schreiben :Cl_BSP_SERVER_SIDE_COOKIE ����set_server_cookie (

exportingname = 'booklist'

application_namespace = runtime→application_namespace

application_name = runtime →application_name

username = sy-unamesession_id = runtime→session_iddata_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'

Anwendungsname und Session-ID als Attribute des globalem Objekt runtime in allen Eventhandlern und Layout zur Vfg.

Server-Cookie hier angelegt für :

- aktuellen User

- aktuelle Anwendung

- aktuelle Session

Nur für diese später auch zugreifbar

� 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 generischenClustertabelle 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 Objektsruntime 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)

* Server-Cookie LesenData: ex_d type SYDATE .Data: ex_t type SYTIME .Cl_BSP_SERVER_SIDE_COOKIE ����get_server_cookie (

exportingname = 'booklist'application_namespace = runtime→application_namespaceapplication_name = runtime →application_nameusername = sy-unamesession_id = runtime→session_iddata_name = 'bookshop_data'

importingexpiry_date = ex_dexpiry_time = ex_t

changingdata_value = it_book_data ) .

SAP-Server-Cookies : CL_BSP_SERVER_SIDE_COOKIE

Alle Parameter außerLebensdauer sind auchbeim Auslesenmitzugeben

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

Cl_BSP_SERVER_SIDE_COOKIE ���� delete_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 = 'booklist"application_namespace = runtime→application_namespaceapplication_name = runtime →application_nameusername = sy-unamesession_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]

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 Netzwerk

Server-Cookie + DB-Ablage

- Unbegrenzte Datenmenge

- Schont das Netzwerk

- Belastet die DB-Performanz

- Belegt DB-Speicher

- Regelmäßiges "Säubern" nötig

via Datenbank

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 Requestbearbeitet 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 Requesterfordern, 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

Quelle:

Heinemann, Rau 2005

Stateful :

Seiten-Objekt bleibt erhalten �

OnCreate nur einmaldurchlaufen !

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 OnManipulationaufgerufen; hierin kann der Datenstrom noch verändert werden. Daraufhin wird OnDestroyangestoß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

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( Aliasname )%>

<OTR> ..... </OTR>

Weitere Infos in [WOLF03]

<%@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 !

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

� 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)OTRNotation <%=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 :

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

<%@page language="ABAP" otrTrim="true" %>

OTR-Texte können in Übersetzungsvarianten unterschiedliche Länge aufweisen �

Abschneiden überschüssiger Leerzeichen im Layout durch BSP-Seitendirektive :

� Die OTR-Referenz <%=otr( aliasname )%> wird intern in einen Methoden-aufruf der runtime-Instanzaufgelö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 : 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 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

Client bekommt timeout allerdings nicht mit, nicht vom Server darüber informierbar. Erst beinä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>

Gilt für gesamten WAS und alleBSP-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 geladeneSeite 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

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

� 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

Historische BSP Error Pages →→→→ seit 6.40 inaktiv !

BSP Runtime setzt TRY / CATCHum jeden Seitenaufruf. Wenn beim Prozessieren der BSP LZ-Exceptionauftritt 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 selbst-geschriebene 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 ).

(22)Einstellung Anmeldedialog

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

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

<% DATA: server_start type i , server_end type i , dauer type i .GET RUN TIME FIELD server_start. %>

<script> var renderStart = new Date() ; </script>

<html> … </html>

<% GET RUN TIME FIELD server_end. dauer = ( server_end – server_start ) / 1000. %>

<script> var renderEnd = new Date() ;var renderTime = renderEnd.getTime() - renderStart.getTime();window.status = "Server=" + "<%=dauer%>" + " Render-Time=" + renderTime ;

</script>

ABAP- und Browser-Stoppuhr-Funktionen klammern dasSeitencoding

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

(24)Performance-AnalyseWorkbench-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

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

(26)BSP-Caching : ICM Server CacheErhö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

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

Kein Eintrag � Cachingkommt für Seite nicht zum Einsatz ......

Seite nur aus Server-Cache liefern wenn Request vom gleichen Browsertyp kommt

... aber natürlich doch für Inhalte des MIME-Repositories der Anwendung !

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

(28)NWAS als HTTP-ClientNWAS kann als Web-ClientRequests an andere WebServer(auch: NWAS) absetzen und Response entgegennehmen.

Zentral ist die Klasse :

CL_HTTP_CLIENT

REPORT ZCLIENTDEMO.DATA: myurl TYPE STRING,

myclient TYPE REF TO IF_HTTP_CLIENT,rc TYPE I,content TYPE STRING.

myurl = 'http://www.sap.de'.* Erstellen HTTP-Client :cl_http_client=>create_by_URL(

exporting url = myurlimporting 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( ).

Auf Fehlerhandling wurde verzichet

� 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 !!

(31)Übersicht BSP-Seiten-Direktiven

BSP-Direktive Beispiel Bedeutung

<%@ page %> <%@ page language="abap" %> Festlegen Server-Skriptsprache

<%@ include %> <%@ include file="nav.htm" %> Einbinden von Seitenfragmenten

<% %> <% loop at itab into wa. %> Skript-Tag

<%-- --%> <%-- Kommentar --%> BSP-Kommentar

<%= %> <%= counter %> Ausgabe-Tag

<%=otr() %> <%=otr( Paket/Alias ) %> OTR-Kurztext

<otr> </otr> <otr> Text </otr> OTR-Langtext

<%@ extension %> <%@ extension name="htmlb" BSP-Extension einbinden

prefix="htmlb" %>

� 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

(32)Bewertung + Einordnung BSP-Technologie

Nutzung bestehender SAP-Anwendungen ohne Anpassung

Konventioneller Browser Interner ITS

Neue Anwendungen mittleren UmfangsKomplette Beeinflussung + Ausprogrammierung von Look & FeelZustandslose Appl.

Neue Anwendungen großen UmfangsÜbernahme von SAP-Oberflächenelementen

Konventioneller BrowserMobile Devices mit individueller CSS-Anpassung Ausnutzen HTML5 + JS + CSS

Alle PlattformenBrowser

BSPKonventionelle Einbettung in ABAP-Workbench und vertraute ABAP-WeltOffenes FrameworkServerseitige Basis für SAPUI5 !

Web DynproDurchgängig MVCEigene BegrifflichkeitVorgegebene OberflächenelementeGeschlossenes 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. Vorteilesind :

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

(33)

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 !

(34)Mails aus BSPs mittels BCSVerwendung Business CommunicationServiceVoraussetzungen :1. SMTP-Plugin im ICM-Profil konfiguriert, zB :

icm/server_port_1 = PROT=SMTP, PORT=252. In TA SCOT Mailing via SMTP eingeschaltet::

Grün hinterlegter Eintrag SMTP3. Zuweisung Mail-Domäne an SAP-System

Beispielcoding im Report ZMAILDEMOin Paket ZBSPTEST

Erzeugte Mail und deren Zustand in SAPconnect-Administration TA SCOTüberprüfbar durch Auswahl der Sendeübersicht :

Hilfsmittel → Übersicht SendeaufträgeMit Klick auf Brille email prüfenIn 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.

(35)Eigene HTTP- HandlerVordefinierter 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 = '<html><body> Service erreicht! </body></html> '

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

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

(36)Eigener HTTP- Handler in SICF

In SICF muss neuer Serviceangelegt werden

Pfad im SICF-Baum bestimmt URL des Service

Eigene HTTP-Behandlerklasseist in Handlerliste einzutragen

Sollen weitere Handler im Anschluss aufgerufen werden, sind auch sie in gewünschter Reihenfolge in Handlerlisteaufzunehmen

Beispiel für resultierende URL :

Service HandlerTest angelegt in SICF direkt unter default_host :

http://r54z.hcc.uni-magdeburg.de:8054/handlertest

ZCL_HTTP_HANDLER

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

(37)Eigene Tag-Library = BSP-Extension

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

<%@page language="abap"%><%@extension name="ZDemoExtension" prefix="zdemo"%>

<html><head> <title> Test eigene Extension </title> </head><body>

<zdemo:Gruss name="BA Mosbach" /><zdemo:Gruss name="Duale Hochschule" /><zdemo:Gruss name="DHBW Mosbach" />

</body></html>

* Redefinition Methode in generierter Behandler-Klasse :

METHOD IF_BSP_ELEMENT~DO_AT_END.

data: grussformel type string value '<h1> Hallo, & ! <h1>',

out type ref to if_bsp_writer.

out = get_previous_out( ).

replace '&' in grussformel with name.

out→print_string( grussformel ).

ENDMETHOD.

Tag-Libraries :Einheitliche Darstellung von Oberflächen-elementen + Präsentationslogik

Zusammenfassung + Auslagerung aufwendiger statischer + dynamischer Elemente in Tag-Bibliothek

� Wiederverwendung + Lesbarkeit !

� Einheitliches Layout !

� Einbinden als selbstdefinierte

parametrisierte TagsBeispiele:

Tabellen + Suchen/Sortieren, Trees, Kalender ….

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

(38)

� Visualisieren der Anwendungsdaten� Darstellung + Benutzerinteraktion� Senden von Benutzereingaben an Controller

� Visualisieren der Anwendungsdaten� Darstellung + Benutzerinteraktion� Senden von Benutzereingaben an Controller

Model View Controller Design Pattern MVC

ControllerRequest

ViewResponse

Model

� Steuerung Kontrollfluss der Anwendung� Events behandeln� Daten an View geben / von View holen� Übersetzen Benutzereingaben für Model� Auswahl passende View für Response

� Steuerung Kontrollfluss der Anwendung� Events behandeln� Daten an View geben / von View holen� Übersetzen Benutzereingaben für Model� Auswahl passende View für Response

� Container für Geschäftsdaten und Geschäftslogik

� Kapselung Anwendungszustand� Eigentliche Datenverarbeitung

durch Geschäftslogik� Information View bei Änderung

� Container für Geschäftsdaten und Geschäftslogik

� Kapselung Anwendungszustand� Eigentliche Datenverarbeitung

durch Geschäftslogik� Information View bei Änderung

Daten-Weitergabe

View-Auswahl View-Aufruf

Aufruf

Zustandsabfragen

Server

Zustandsänderungen

Methodenaufrufe

Datenfluss

Ereignisse

Kontrollfluss

Quelle: OIO, Kursmaterial

Konsequente Entkopplung von Ablaufsteuerung, Präsentation (Layout) und Geschäftslogik in separaten Objekten

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

(39)

� BSP-Anwendung zugeordnet Anlegen → Seite → View

� Haben keine eigene URL – nicht direkt aufrufbar� Vom Controller aufgerufen + mit Daten versorgt� Haben Eigenschaften, Layout, Seitenattribute� Keine Eventhandler, keine Auto-Seitenattribute

� BSP-Anwendung zugeordnet Anlegen → Seite → View

� Haben keine eigene URL – nicht direkt aufrufbar� Vom Controller aufgerufen + mit Daten versorgt� Haben Eigenschaften, Layout, Seitenattribute� Keine Eventhandler, keine Auto-Seitenattribute

MVC mit BSP

Controller

View

Model

Einbettung in Workbench

� BSP-Anwendung zugeordnet Anlegen→ Controller

� Ablaufsteuerung (Flow Logic) der Anwendung durch entsprechende Methoden – analog BSP-Eventhandlern

� Klassen erben von ICF-Basisklasse CL_BSP_CONTROLLER2� Können Views aufrufen sowie Model-Objekt erzeugen + ansprechen� Aufrufbar mit eigener URL Endung .do� Coding hinterlegen durch Überschreiben geerbter Methoden

� BSP-Anwendung zugeordnet Anlegen→ Controller

� Ablaufsteuerung (Flow Logic) der Anwendung durch entsprechende Methoden – analog BSP-Eventhandlern

� Klassen erben von ICF-Basisklasse CL_BSP_CONTROLLER2� Können Views aufrufen sowie Model-Objekt erzeugen + ansprechen� Aufrufbar mit eigener URL Endung .do� Coding hinterlegen durch Überschreiben geerbter Methoden

� Normale ABAP-OO-Klassen� Erben von CL_BSP_MODEL� Zahlreiche geerbte Methoden� Frei definierbare eigene Methoden + Attribute zur

Darstellung der Logik� Direkt via ClassBuilder angelegt� Aufrufe erfolgen aus Methoden der Controller-Klasse

� Normale ABAP-OO-Klassen� Erben von CL_BSP_MODEL� Zahlreiche geerbte Methoden� Frei definierbare eigene Methoden + Attribute zur

Darstellung der Logik� Direkt via ClassBuilder angelegt� Aufrufe erfolgen aus Methoden der Controller-Klasse

� 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

(40)MVC mit BSP Controller-Bestandteile =

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-Seiten haben keine eigene URL, keine Eventhandler, keine Auto-Seitenattribute ….

Controller-Eigenschaften

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.

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

OnInputProcessing

OnManipulation

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

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 :

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

(42)MVC mit BSP – typische Strukturen

Ein Controller kann mehrere Views nacheinander ansteuern ……

Model

Controller

View 1

View 1

View 1

Aufrufe

BSP-Seite

Model 1

Controller 1

Aufruf

View 1

Model 3

Controller 3

Aufruf

View 3

Model 2

Controller 2

Aufruf

View 2

Model 3

Controller 3

Aufruf

View 3

Model 2

Controller 2

Aufruf

View 2

Model

Controller

Model 1

Controller 1

Aufruf

View 1

Aufrufe

Jede einzelne "BSP-Seite" implementiert alle drei MVC-Komponenten. Views durch zugeordnete Controller gerufen …..

Ein übergeordneter Haupt-Controller steuert die Verteilung der Anwendungslogik durch Aufruf von Sub-Controllern ….

BSP-Anwendung

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

(43)Controller-Methoden überschreiben

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.

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

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.

<%@page language="abap"%>

<html>

<head>

<title> Aufruf View </title>

</head>

<body>

Benutzer <%= text %>

</body>

</html>

View next.htm

Zentrale Methoden der Controller-Klasse

� 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 :<bsp:call url="next.do"> <bsp:parameter name="carrier" value="LH" /> <bsp:call>

� Auch Redirects sind möglich: <bsp:goto url="results.do"> <bsp:goto>