|
Eigene Bereitstellungsverfahren für APEX Workspaces einrichten
APEX ist bereits seit dem ersten Tag für Hosting-Umgebungen ausgelegt. Wie
jedermann auf dem öffentlichen Demoserver
apex.oracle.com selbst ausprobieren kann,
kann ein Workspace in Selbstbedienung beantragt werden. Nach der Genehmigung
durch den Administrator wird der Workspace einrichtet und der Entwickler kann
mit der Arbeit beginnen.
Abbildung 1: "Beantragen" eines neuen APEX-Workspace
Dieser von APEX mit ausgelieferte Bereitstellungsprozeß ist zwar sehr
bequem - in vielen Fällen passt er jedoch nicht auf die Bedürfnisse im
Unternehmen ...
- Der Vorgesetzte muss den Workspace genehmigen und nicht der APEX-Administrator.
- Die von APEX standardmäßig erfassten Angaben reichen nicht aus - man möchte ggfs.
eine Kostenstelle oder einen Abteilungsnamen erfragen.
- Die Seiten zur Beantragung eines Workspace soll durch Login geschützt werden
- Die Email-Adresse soll nicht frei eingebbar sein, sondern aus dem Login abgeleitet werden
- Und und und ...
Fast alle Anforderungen dieser Art ließen sich mit einer eigenen APEX-Anwendung
problemlos abdecken - die Anforderungen könnten in einer eigenen Tabelle abgelegt
werden. Zur konkreten Einrichtung des Workspace wird dann allerdings ein automatisierter
Prozeß benötigt.
Bereits vor einigen APEX-Versionen wurde das PL/SQL-Paket APEX_INSTANCE_ADMIN eingeführt;
damit können APEX-Workspaces auch aus PL/SQL heraus verwaltet werden. Die Notwendigkeit
für dieses Paket kam mit der Runtime-Only-Installation auf - wenn keine APEX-Entwicklungsumgebung
mehr da ist, ist auch keine APEX-Administrationsumgebung (Workspace INTERNAL) mehr da;
die Aufgaben müssen also mit APEX_INSTANCE_ADMIN erledigt werden.
Im folgenden wird exemplarisch vorgestellt, wie ein sehr einfacher Prozess zum
Einrichten eines APEX-Workspaces implementiert werden kann. Dieser kann dann natürlich
so lange ausgebaut werden, bis konkrete Anforderungem im Unternehmen erfüllt sind.
- Die Anwendung zum Beantragen eines Workspace wird durch einen Login geschützt
- Die Mailadresse wird aus dem APEX-Usernamen Login abgeleitet (&APP_USER.@meinefirma.de)
- Der Workspace-Name wird generiert
- Es wird immer ein neues Datenbankschema erstellt - der Name wird generiert
- Alle Datenbankschemas bekommen TS_APEX_WORKSPACES als Tablespace zugewiesen
- Die Tablespace-Quota wird einheitlich auf 25MB gesetzt
Zunächst wird also eine Tabelle benötigt, in welche die Anforderungen
gespeichert werden. Das folgende SQL-Skript legt die Tabelle an. Lassen Sie es
im Parsing-Schema des APEX-Workspace, in dem die Web-Oberfläche zum Beantragen
eines Workspace liegen soll, laufen. Damit der gesamte Prozess funktioniert, muss
diesem Parsing Schema allerdings die Rolle APEX_ADMINISTRATOR_ROLE zugewiesen werden.
Erstellen Sie danach eine APEX-Anwendung mit einer Formularseite. Das Formular
sollte Eingabefelder für Namen und Vornamen enthalten; die Felder für Email
sowie für APEX-User-ID sollten auf Read Only gestellt werden. Das "Generieren"
der Emailadresse könnte in einfachen Fällen mit
mit einer Belegung des Default ("&APP_USER.@meinefirma.de")
erreicht werden; komplexere Fälle erfordern ein wenig PL/SQL-Logik. Am besten verwenden Sie
nicht den APEX-Formularassistenten - legen Sie die Formularfelder einzeln an und fügen
Sie die Daten mit einem PL/SQL-Prozess in die Tabelle ein. Eine Anwendung zur Illustration
stellen wir hier zum Download bereit.
Das fertige Formular könnte wie in Abbildung 2 aussehen. Erstellen Sie dann
einen Bericht, der alle Anforderungen des angemeldeten Nutzers anzeigt; das
SQL hierfür ist recht einfach:
Abbildung 2: Eigenes Formular zum Beantragen eines APEX-Workspace
Als nächstes wird die PL/SQL-Prozedur erstellt, die anhand dieser Angaben
den APEX-Workspace erstellt. Dazu müssen folgende Schritte ausgeführt
werden.
- Ein Passwort für den APEX-Nutzer als auch für das Datenbankschema muss generiert werden
- Ein neues Datenbankschema muss erstellt werden (CREATE USER)
- Die nötigen Privilegen wie CREATE TABLE, CREATE PROCEDURE und andere müssen vergeben werden
- Der Workspace muss mit APEX_INSTANCE_ADMIN erstellt werden
- Das Benutzerkonto ADMIN muss im neuen Workspace eingerichtet werden
Diese Aktivitäten sind im PL/SQL-Paket PKG_WORKSPACE_PROVISIONING zusammengefasst.
Spielen Sie es ebenfalls ins Parsing-Schema des APEX-Workspace ein; dieses muss jedoch EXECUTE-Privilegien
auf APEX_040000.APEX_INSTANCE_ADMIN erhalten. Tatsächlich ausgeführt wird es später
mittels eines Scheduler-Jobs als SYS.
Die Prozedur
PKG_WORKSPACE_PROVISIONING.CREATE_REQUESTED_WORKSPACES muss nun
regelmäßig ausgeführt werden - dafür sorgt ein Hintergrund-Job, der mit
dem Datenbank-Scheduler eingerichtet wird. Der Job muss ebenfalls als
SYS laufen - das folgende Beispiel richtet den Job so ein, dass er alle
fünf Minuten läuft und ausstehende Anforderungen abarbeitet. Mit
DBMS_SCHEDULER.DROP_JOB können Sie den Job wieder löschen.
Tragen Sie nun einen "Workspace-Request" in das Formular der APEX-Anwendung
ein und verfolgen Sie im Bericht den Status. Nach einigen Minuten
wird der Status zuerst auf WORKING und dann auf APPROVED gestellt. Anschließend
ist der Workspace eingerichtet (Abbildung 3).
Abbildung 3: Verfolgung des Bereitstellungs-Status im APEX-Bericht
Das erstmalige Login läuft wie immer ab. Zuerst muss das Standardpasswort geändert werden
und danach kann man im Workspace arbeiten.
Abbildung 4: Erstmaliger Login in den neuen APEX-Workspace
Dieses einfache Beispiel lässt sich natürlich weiter denken; so könnte man
durchaus verschiedene Workspace-Größen denkbar; das Formular könnte (analog zum
Prozess auf apex.oracle.com) verschiedene Größen zur Auswahl anbieten. Technisch
würde die Tablespace-Quota von 25M, die im Beispiel mit einer PL/SQL-Konstante "hart"
kodiert ist, dynamisch gestaltet. Auch Genehmigungsprozesse oder die Kombination
mit einem Abrechnungsmodul ist denkbar. APEX macht das Erstellen der "Provisioning-Anwendung",
wie immer, sehr einfach.
Mehr Informationen
Dokumentation: APEX_INSTANCE_ADMIN
Hintergrund-Jobs mit DBMS_SCHEDULER
Zurück zur Community-Seite
|