Eigene Bereitstellungsverfahren für APEX Workspaces einrichten
Erscheinungsmonat |
APEX-Version |
Datenbankversion |
Juli 2014 |
ab 4.0 |
ab 10.2 |
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
- Der Name des Datenbankschemas soll generiert 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
Zur Umsetzung benötigen wir zunächst ein Datenbankschema (WSPROV) und einen APEX-Workspace.
Die APEX-Anwendung, über welche künftig APEX-Workspaces beantragt werden sollen, wird in diesem
Workspace; deren Tabellen und der PL/SQL-Code, der die neuen Datenbankuser und APEX-Workspaces konkret
erzeugt, wird im Datenbankschema liegen. Aus diesem Grund benötigt es,
neben den "normalen" Privilegien, die
APEX_ADMINISTRATOR_ROLE und das EXECUTE-Privileg auf
APEX_INSTANCE_ADMIN. Tatsächlich ausgeführt wird das
Package jedoch, da zu einem neuen APEX-Workspace auch ein neues Datenbankschema
gehört, als SYS.
Weiterhin wird das erwähnte Tablespace TS_APEX_WORKSPACES benötigt. Legen Sie es
als DBA in etwa wie folgt an - natürlich müssen Sie den Pfad zu den Datendateien, die
gewünschte Dateigröße und die Autoextend-Eigenschaften an Ihre Umgebung und Bedürfnisse anpassen.
In diesem Beispiel werden alle neuen APEX-Workspaces diesen Tablespace verwenden.
Das folgende SQL-Skript legt die Tabelle an, in
welche die Anforderungen (Requests)
gespeichert werden. Lassen Sie es im gerade erzeugten Datenbankschema
WSPROV laufen.
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.
Die Prozedur
PKG_WORKSPACE_PROVISIONING.CREATE_REQUESTED_WORKSPACES
arbeitet nun alle offenen Requests aus der Tabelle TAB_APEX_WORKSPACE_REQUESTS ab. Am besten
lassen Sie diese per Datenbank-Job in regelmäßigen Intervallen ausführen. Dieser
Job muss, da neben dem APEX Workspace auch neue Datenbankuser erzeugt werden, als SYS
ausgeführt werden. Natürlich können Sie auch einen anderen DBA-User mit entsprechenden
Privilegien nehmen.
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
APEX und die Kommandozeile - da geht mehr als man denkt.
"Vorfahrtsregeln" in einer APEX-Umgebung mit dem Ressoucen Manager
Hintergrund-Jobs mit DBMS_SCHEDULER
Zurück zur Community-Seite
|