Einrichtung und Nutzung des PL/SQL Embedded Gateways
Bei Nutzung des PL/SQL Embedded Gateway wird
die Aufgabe des Webservers von der
Datenbank und dem Listener selbst übernommen - auf dem Datenbankrechner werden also
keine weiteren Prozesse benötigt. Insofern ist der Setup sehr einfach und die
Administration des Webservers ist mit der normalen Datenbankadministration abgedeckt.
Allerdings bietet das Embedded Gateway nicht so viele Webserver-Features wie ein
Apache - so gibt es kein URL Rewriting, keine virtuellen Hosts, keine Proxy- und keine speziellen
Authentifizierungsmodule. Insofern eignet sich das Embedded Gateway vor allem für
Entwicklermaschinen und kleinere Intranet-Umgebungen. Aus Lizenzsicht ist das
Embedded Gateway mit der Datenbanklizenz abgedeckt. Für SSL-Zugriff ist allerdings
eine Lizenz sowohl der Enterprise Edition der Datenbank als auch der Advanced Security Option
erforderlich.
Abbildung 1: Architektur von Application Express mit dem PL/SQL Embedded Gateway
Die technische Grundlage des Embedded PL/SQL Gateway sind die
Protokollserver der XML DB. Der
HTTP-Endpoint wird durch den normalen
Oracle Listener bereitgestellt, die
HTTP-Anfragen der Browser werden durch
Shared Server Prozesse der Datenbank bearbeitet.
Mehr zur Architektur der XML DB Protokollserver findet sich im XML DB Developers' Guide
der
Oracle-Dokumentation.
Ein besonderes Merkmal des PL/SQL Embedded Gateway ist, dass alle Inhalte
aus der Datenbank kommen - auch die zum APEX-Lieferumfang gehörenden
statischen Bild-, CSS- und Javascript-Dateien. Diese werden im sog. XML DB Repository
abgelegt - ein virtuelles Dateisystem speziell für die XML DB Protokollserver . Alle
Inhalte liegen in einer Systemtabelle - XDB$RESOURCE im Schema XDB. Auf SQL-Ebene
können Sie sich diese mit den Views RESOURCE_VIEW und PATH_VIEW ansehen. Mit den
PL/SQL-Paket DBMS_XDB können Verzeichnisse und Dateien (Ressourcen) bearbeitet werden.
Zur Einrichtung des Embedded Gateways mit APEX sind bereits
fertige Konfigurationsskripte vorhanden.
-
Starten Sie als SYS das
Skript $ORACLE_HOME/apex/apxconf.sql. Es fragt Sie nach
dem HTTP-Port, den Sie für Application Express verwenden möchten, und führt dann
die nötigen Konfigurationsschritte durch.
-
Starten Sie im APEX-Verzeichnis als SYS das Skript
apxldimg.sql. Als Parameter geben Sie
das Verzeichnis, in das Sie das heruntergeladene
APEX-Archiv ausgepackt haben, an.
-
Entsperren Sie den Datenbanknutzer ANONYMOUS.
Geben Sie dazu als (ebenfalls als SYS) folgendes Kommando ein:
FTP-Zugang zu den statischen Dateien
Es gibt neben dem XML DB Protokollserver für HTTP auch einen für FTP. Diesen
schalten Sie (als DBA) mit einem einfachen PL/SQL-Aufruf wie folgt frei.
Verwenden Sie danach einen "normalen" FTP-Client und verbinden Sie sich mit
der Datenbank. Verwenden Sie für die FTP-Verbindung einen DBA-User, aber
nicht SYS. Nach dem Login befinden Sie sich im "Root"-Verzeichnis des virtuellen
Dateisystems. Der
APEX-Pfad /i/ ist auf das Verzeichnis
/images abgebildet. Sie können die statischen Dateien
also nun auch mit dem FTP-Client bearbeiten, löschen oder neue hochladen. Beachten Sie
bitte, dass nur die Dateien unterhalb von /images unter /i/ extern erreichbar sind. Die
anderen Verzeichnisse sind zwar für HTTP-Zugriffe erreichbar, Sie müssen sich
jedoch vorher wie für FTP mit einem Datenbank-Nutzernamen und -passwort anmelden.
Wenn Sie den FTP-Zugang nicht mehr benötigen, sollten Sie ihn abschalten. Das
geschieht einfach durch Setzen des Ports auf "0" (Null).
Den HTTP Port nachträglich ändern
Um den HTTP Port des Embedded PL/SQL Gateway nachträglich zu ändern, benötigen Sie nur
einen PL/SQL Aufruf:
Wenn Sie auf einem Unix oder Linux-System einen Port unter 1024 nutzen möchten, müssen
Sie ein wenig mehr tun - eine Beschreibung der nötigen Schritte finden Sie in der
Dokumentation zur Oracle XML DB.
TCP/IP Ports überprüfen
Die Ports werden, wie weiter oben schon erwähnt, vom Oracle Listener bedient. Ein
lsnrctl status gibt Ihnen eine Übersicht über die aktuell aktiven Ports.
Performance-Optimierungen für das Embedded Gateway
Nach einer Standardeinrichtung funktioniert
das Embedded Gateway; allerdings lässt die Performance doch massiv zu wünschen übrig.
Das liegt aber nicht daran, dass die Protokollserver an sich langsam sind. Vielmehr
ist die Default-Konfiguration eher schlecht - und bei APEX merkt man das auch.
Es ist aber sehr einfach, die Performance zu verbessern.
-
Setzen Sie (als DBA) die Parameter
shared_servers und
max_shared_servers so,
dass Serverprozesse (Shared Server) in
hinreichender Anzahl bereitstehen. Beachten Sie dabei, dass eine APEX-Seite
während des Ladens einer Anwendungsseite mehrere HTTP-Anfragen absetzt (Bilder, JavaScript, CSS); ein
APEX-Nutzer belegt also für einen Seitenabruf durchaus mehr als einen
Server-Prozess. Der
Parameter max_shared_servers legt dabei die Obergrenze für die Server-Prozesse fest,
während shared_servers eine Art "Zielgröße" darstellt. Mit dem folgenden Beispiel
werden beim Start der Datenbank sofort 15 Server-Prozesse gestartet. Bei starker Last
können nochmals 10 Prozesse nachgestartet werden, die allerdings auch wieder zerstört
werden, wenn die Last zurückgeht. Die 15 Server-Prozesse bleiben jedoch bestehen.
-
Auch die Anzahl der Dispatcher ist
von Bedeutung; diese nehmen die Browser-Anfragen
entgegen - auch hier ist es meist sinnvoll, mehr als einen Dispatcher zu starten. Der
Parameter dispatchers ist bei Ihnen schon gesetzt, wir
ändern nur die Anzahl - es kommt auf den rot markierten Teil an:
Wenn die SID Ihrer Datenbank also orcl ist, sieht der Parameter so aus:
Embedded Gateway und sichere Verbindungen (SSL)
Das PL/SQL Embedded Gateway kann auch im SSL-Modus betrieben werden. Dabei sind jedoch
zwei Voraussetzungen zu beachten:
- Diese Funktionalität ist Teil der Advanced Security Option
- Sie benötigen ein Server Zertifikat, mit welchem sich die Datenbank gegenüber
dem Webbrowser "ausweist".
Genaue Anweisungen zur Konfiguration des PL/SQL Embedded Gateway mit SSL
finden Sie im
Handbuch zur Oracle XML DB.
Logging
Verwendet man den Apache, ist alles ganz einfach. Wenn es ein Zugriffsproblem
gibt und auf dem Bildschirm nur die berühmte HTTP 404 oder HTTP 500-Meldung
erscheint, schaut man am besten in die Datei error_log
hinein - dort findet
man dann in aller Regel einen ORA-Fehlercode, der beim Analysieren des Problems
weiterhilft.
Standardmäßig findet beim PL/SQL Embedded Gateway keinerlei Logging statt. Auch
im Fehlerfall sieht man außer der HTTP Fehlermeldung oder einem ggfs. leeren
Bildschirm nichts. Bei Problemen sollte also zunächst das Logging aktiviert
werden - und zwar wie folgt:
Von nun an werden Debugging-Informationen in die Datenbank-Tracedateien
geschrieben (user dump destination).
Der Loglevel LOG_DEBUG führt
zu recht umfangreichen
Informationen. Aus Performancegründen sollten Sie das Logging (wie immer) nur
einschalten, wenn Sie es tatsächlich benötigen - es kostet ebenfalls
Ressourcen.
Mit Hilfe des Loggings können Sie auch eine weitere Eigenheit des Embedded Gateways
ergründen - dazu der nächste Abschnitt.
Eigene PL/SQL Prozeduren direkt per URL aufrufen
Im Gegensatz zum Apache erlaubt das Embedded Gateway den direkten
Aufruf von eigenen PL/SQL-Prozeduren nicht. Wenn Sie also als Beispiel im
Parsing Schema Ihrer APEX-Anwendung
die folgende Prozedur erzeugen und
die Ausführungsprivilegien an alle vergeben ...
... und diese Prozedur dann im Browser aufrufen ...
Abbildung 4: 1. Versuch: Direkter Aufruf einer eigenen PL/SQL Prozedur mit dem Embedded Gateway"
... stellen Sie fest, dass dies offensichtlich nicht erlaubt ist. Verwendet man den
Apache, funktioniert es ohne Probleme. Woran liegt das? Ein Blick in die Logging-Informationen
gibt Auskunft:
Das PL/SQL Embedded Gateway erlaubt das direkte Aufrufen nur für die Prozeduren der
APEX-Engine. Möchte man (wie im Beispiel) auch andere Prozeduren aufrufen, müssen diese
freigeschaltet werden. Dir Prüfung erfolgt, indem das Embedded Gateway die Prozedur
wwv_flow_epg_include_mod_local im Schema
der APEX-Engine (hier: APEX_040000) aufruft.
Standardmäßig liefert diese stets false zurück. Spielen
Sie also als SYS folgende Prozedur ein.
Ein neuer Versuch mit dem Browser funktioniert nun. Natürlich können Sie die
Namen der Prozeduren auch in einer Tabelle speichern und im PL/SQL Code anhand
dieser Tabelle prüfen, ob das Aufrufen der Prozedur erlaubt ist. Das einfachste
denkbare Beispiel wäre, stets true zurückzugeben - damit würde sich das
Embedded Gateway genauso wie der Apache verhalten.
Abbildung 5: Direkter Aufruf einer eigenen PL/SQL Prozedur mit dem Embedded Gateway nach Freischaltung
Wie schon weiter oben erwähnt, bietet das PL/SQL Gateway bei weitem nicht die
Funktionsfülle wie der Apache Webserver mit seinen vielen Modulen. Die sehr populäre
Funktion des URL Rewritings, also das Umschreiben einer APEX-URL (f?p=129:1) in eine
leicht zu merkende /myapplication, kann jedoch auch mit dem Embedded Gateway nachgebildet
werden. Wie das geht, ist in
diesem Community-Tipp beschrieben.
Zurück zur Community-Seite
|