Applikationsklasse einer BSP-Applikation 

Überblick

Eine BSP-Applikation besteht aus einer Reihe unterschiedlicher Entwicklungsobjekte. Eines dieser Objekte ist die sogenannte Applikationsklasse oder Anwendungsklasse einer BSP-Applikation.

Die Applikationsklasse ist eine normale ABAP Objects Klasse. Als solche kann sie über Methoden, Attribute und Ereignisse verfügen, die vom Entwickler frei gewählt werden können.

Ihre Aufgabe ist typischerweise, BSP-seitenübergreifende Daten in Form von Attributen zu halten und zu exponieren, sowie in der BSP Applikation verwendete Logik in Methoden zu kapseln. Hierdurch können leicht mehrere BSP Applikationen dieselbe Applikationsklasse wiederverwenden und eine einzige Business-Applikation mit mehreren, z.B. für unterschiedliche Devices spezialisierten Oberflächen verfügbar machen, ohne dass die Business- oder Applikationslogik repliziert werden muss.

In der BSP-Applikation kann dann über das globale Objekt application auf die Attribute und Methoden der Applikationsklasse zugegriffen werden.

Die Applikationsklasse muss nicht zwingend in einer BSP-Applikation eingesetzt werden. Sie ist vielmehr eine Option, die von Anwendungsentwicklern zur Strukturierung ihrer BSP-Anwendung eingesetzt werden kann.

Einer BSP-Applikation kann über den Web Application Builder in der SE80 eine Applikationsklasse zugeordnet werden.

Ein einfaches Beispiel für den sinnvollen Einsatz einer Applikationsklasse wäre eine Klasse zum Steuern der Dialoglogik und Konsistenthalten der Daten in einer Shopping-BSP-Applikation. Eine solche Klasse würde einen Warenkorb (z.B. in Form einer internen Tabelle oder eines weiteren Objektes) als Attribut exponieren und mit Methoden aufwarten, die die Manipulation dieses Warenkorbes ermöglichen, also z.B. Methoden zum Einfügen, Ändern und Löschen von Artikeln. Desweiteren wären Methoden zur Preisfindung, zur Angebotserstellung und Auftragsverbuchung wünschenswert.

In vielen Fällen wird die Applikationsklasse selbst wieder nur als Kapsel für bereits existierende Anwendungsfunktionalität dienen (z.B. aus dem Bereich CRM) und diese selbst über BAPI-Schnittstellen ansprechen. Durch die Verwendung der Kapsel „Anwendungsklasse“ wird aber erreicht, dass der zunächst in einer BSP-Applikation verwendete bzw. zur Verfügung gestellte Funktionsumfang an einer zentralen Stelle – nämlich der Applikationsklasse – explizit gemacht wird und zum anderen eine Implementierungstransparenz sowie Verteilungstransparenz (lokaler Methodenaufruf, aber Remote BAPI-Call intern) erreicht werden kann. Möchte ein Kunde oder Entwickler eine BSP-Applikation umgestalten oder für ein weiteres Device anpassen, so ist der verwendete Funktionsumfang der Original-BSP-Applikation explizit in die Schnittstelle der Applikationsklasse gegossen.

Laufzeitverhalten

Potentiell kann eine beliebige ABAP Objects Klasse als Applikationsklasse einer BSP-Applikation verwendet werden. Zu beachten ist allerdings, dass die Klasse von der BSP-Laufzeit als ein Singleton verwaltet wird, also eine Klasse, von der es maximal eine Instanz innerhalb einer Session gibt.

Die Lebensdauer der Applikationsklasse richtet sich nach dem Zustandsmodell der BSP Applikation. Zu unterscheiden sind also der stateful (zustandsvolle) Modus und der stateless (zustandslose) Modus.

Stateful BSP-Applikation

Bei Stateful BSP-Applikationen wird die einzige Instanz des Applikationsklasse – das Anwendungsobjekt – mit dem ersten Request an die BSP-Applikation erzeugt. Danach steht das Objekt über die gesamte Lebensdauer der Session zur Verfügung. Mit dem Ende der Session endet die Lebensdauer des Anwendungsobjektes.

Im stateful Modus bietet sich also die Applikationsklasse zur lokalen Pufferung von aufwendig zu bestimmenden Datenbeständen an.

Stateless BSP-Applikation

Stateless BSP-Applikationen zeichnen sich dadurch aus, dass der Anwendungskontext oder „Rollbereich“ nur für die Dauer eines einzelnen Requests zur Verfügung steht und danach wieder freigegeben wird. Gemeinsam mit dem Anwendungskontext endet aber auch die Lebensdauer aller Daten und Objekte einer Session im Applikationsserver. Dies schließt das Applikationsobjekt ein.

Dadurch ergibt sich für das Applikationsobjekt eine Lebensdauer, die nur vom Eingang des Requests bis zum Versenden der zugehörigen Response erstreckt. Das Anwendungsobjekt steht damit nicht über mehrere Seiten hinweg zur Verfügung. Vielmehr sieht jede Seite bzw. jeder Request eine andere Instanz derselben Anwendungsklasse.

Das Anwendungsobjekt ist also im stateless Modus nicht geeignet, Daten über Requests hinweg zu halten. In den meisten Fällen werden Anwendungsklassen für stateless Applikationen nur Logik in Form von Methoden exponieren, aber nicht den Aspekt der Datenpufferung ausüben können.

Zugriff auf das Applikationsobjekt

Auf das Applikationsobjekt kann über eine typisierte Objektreferenz, die als Parameter mit dem Namen application in allen Eventhandlern einer BSP zur Verfügung steht, zugegriffen werden. Zu beachten ist dabei, dass dieser Parameter natürlich nur dann existiert, wenn für eine BSP-Applikation eine Applikationsklasse definiert wurde.

Anforderungen an die Applikationsklasse

Die einzige „harte“ Anforderung, die an eine Applikationsklasse gestellt wird, ist, dass ihr Konstruktor parameterlos ist. Ansonsten kann sie nicht generisch von der BSP-Laufzeit instantiiert werden.

Darüber hinaus gibt es keine Einschränkungen. Zu beachten ist allerdings, dass je nachdem in welchem Zustandsmodus die Klasse eingesetzt wird, die interne Implementierung von Methoden geeignet gewählt werden muss. So macht es z.B. bei stateless Applikationen wenig Sinn, teure Vorabdatenbeschaffungen zu implementieren, da diese ja nach jedem einzelnen Request wieder verloren gehen. Stattdessen wird man eher auf eine bedarfsgesteuerte Datenbeschaffung zurückgreifen. In stateful Applikationen dagegen kann mit einer geeigneten „Initialisierungsphase“ zur Datenbeschaffung durchaus ein Gewinn an Performanz verbunden sein.

Applikationsereignisse – das Interface IF_BSP_APPLICATION_EVENTS

Insbesondere bei stateless BSP-Applikationen besteht in einer Anwendung häufig der Wunsch, zu bestimmten Zeitpunkten im Lebenszyklus der Applikation an zentraler Stelle die Kontrolle zu erhalten. Diesem Wunsch wird im BSP-Modell dadurch Rechnung getragen, dass eine Applikationsklasse das vordefinierte Interface IF_BSP_APPLICATION_EVENTS implementieren kann.

Wenn eine Applikationsklasse das Interface IF_BSP_APPLICATION_EVENTSimplementiert – was optional ist -, so werden die Methoden dieses Interfaces von der BSP-Laufzeit zu den jeweiligen Zeitpunkten aufgerufen. Im einzelnen handelt es sich um die folgenden Methoden und Zeitpunkte:

IF_BSP_APPLICATION_EVENTS~ON_START	Diese Methode wird von der BSP-Laufzeit aufgerufen, wenn die zugehörige BSP-Applikation erstmalig gestartet wird, d.h. zu Beginn der entsprechenden BSP-Session. Dies trifft für stateless wie stateful Appliktionen zu. Typischerweise wird dieser Zeitpunkt für die Ausführung von Autorisierungprüfungen, die die gesamte Applikation betreffen, oder zur Vorabdatenbeschaffung (in stateful Applikationen) eingesetzt.
IF_BSP_APPLICATION_EVENTS~ON_STOP	Diese Methode wird von der BSP-Laufzeit aufgerufen, wenn die zugehörige BSP-Applikation explizit beendet wird. Dies trifft für stateless wie stateful Appliktionen zu. Beachten Sie, dass dieser Zeitpunkt bei stateless BSP-Applikationen nicht nach jedem Request gegeben ist! Außerdem wird dieser Zeitpunkt nicht gehalten, wenn die Session durch einen Timeout implizit beendet wird. Insofern können in dieser Methode nur optionale Operationen ausgeführt werden, deren Ausbleiben keinen kritischen Charakter hat. Typischerweise wird dieser Zeitpunkt für Aufräumarbeiten wie das Löschen von Browser-Cookies oder Server-seitigen Cookies eingesetzt, falls die Applikation solche zuvor erzeugt hat.
IF_BSP_APPLICATION_EVENTS~ON_REQUEST	Diese Methode wird von der BSP-Laufzeit für jeden eingehenden Request auf eine BSP aufgerufen, bevor die BSP die Kontrolle erhält (im OnRequest-Eventhandler). Dieser Zeitpunkt kann von der Anwendungsklasse z.B. zum Wiederherstellen von Attributen verwendet werden, wenn diese in Client- oder Server-seitigen Cookies in einem vorangegangenen Request gerettet wurden.
IF_BSP_APPLICATION_EVENTS~ON_RESPONSE	Diese Methode wird von der BSP-Laufzeit für jede ausgehende Response einer BSP aufgerufen, nachdem die BSP bearbeitet wurde (nach dem OnManipulation-Eventhandler). Dieser Zeitpunkt kann von einer stateless Anwendungsklasse z.B. zum Retten von Attributen in Client- oder Server-seitigen Cookies verwendet werden.

Siehe auch:

Details des Interfaces IF_BSP_APPLICATION_EVENTSfinden Sie in der Referenzdokumentation: Interface IF_BSP_APPLICATION_EVENTS

Applikationsbasisklasse CL_BSP_APPLICATION

Wenn eine Applikationsklasse nicht bereits eine Superklasse besitzt, kann es sich anbieten, sie von der vordefinierten Basisklasse CL_BSP_APPLICATION abzuleiten. Diese Klasse bietet Methoden, die in einer BSP-Applikation typischerweise zur Einbettung in die Webumgebung benötigt werden. So können Informationen über die laufende BSP-Applikation (z.B. Session-Timeout, aktuelle URL zur BSP-Applikation, Zustandsmodus etc.) abgerufen bzw. gesetzt werden.

Da das Applikationsobjekt in jedem BSP-Eventhandler als application-Attribut zur Verfügung steht, sind die Methoden der Klasse CL_BSP_APPLICATION bei entsprechender Vererbung ebenfalls zugreifbar. Insbesondere kann hierdurch sehr einfach die entsprechende Funktionalität in tiefere Anwendungsebenen durch eine einzige Objektreferenz heruntergereicht werden.

Siehe auch:

Details zur Basisklasse CL_BSP_APPLICATION finden Sie in der Referenzdokumentation: Klasse CL_BSP_APPLICATION