APEX und die Kommandozeile: Da geht mehr als man denkt!
Erscheinungsmonat |
APEX-Version |
Datenbankversion |
April 2014 |
4.2 |
ab 10.2 |
In diesem Tipp stellen wir Ihnen einige Aufgaben vor, die in APEX mit der Kommandozeile, also
typischerweise mit SQL*Plus, erledigt werden können. Das sind mittlerweile mehr als
man denkt. In einigen Fällen sind die Funktionsaufrufe, die APEX von Haus aus bereitstellt,
allerdings etwas umständlich, so dass ein wenig Skripting hilfreich sein kann. Fangen wir am besten
gleich an.
APEX Workspace erzeugen
Dies ist sicherlich eine der ersten Aufgaben, die man per Kommandozeile
ausführen möchte ... und im PL/SQL Paket APEX_INSTANCE_ADMIN findet sich
mit ADD_WORKSPACE auch ein entsprechender Aufruf dazu ...
Natürlich braucht man, um APEX_INSTANCE_ADMIN (und später APEX_UTIL.CREATE_USER) aufrufen zu können, administrative
Privilegien - Sie brauchen mindestens die APEX_ADMINISTRATOR_ROLE. Alternativ
können Sie auch mit einem DBA-User arbeiten.
Allerdings reicht das nicht aus - denn in einen damit
erzeugten Workspace kann sich zunächst niemand einloggen - mit APEX_UTIL.CREATE_USER muss vorher
ein ADMIN-User eingerichtet werden. Ebenso wird das Datenbankschema nicht automatisch
generiert - auch dies müsste mit einem CREATE USER-Kommando manuell geschehen. Um also
einen sofort nutzbaren APEX-Workspace per Skript bereitzustellen, brauchen wir ein etwas
umfangreicheres SQL-Skript, welches mehrere Dinge tut:
- Ein Datenbankschema mit den nötigen Privilegien erstellen (CREATE USER, GRANT). Das Passwort ist in diesem Fall stets oracle.
- Einen APEX Workspace gleichen Namens generieren (APEX_INSTANCE_ADMIN)
- Einen Workspace-Administrator namens ADMIN, ebenfalls mit dem Passwort oracle, erstellen (APEX_UTIL)
Speichern Sie das Skript als create-apx-workspace.sql ab. Aufgerufen es in SQL*Plus dann wie folgt.
Natürlich kann man mit diesem Skript-Code auch eine PL/SQL Stored Procedure erstellen;
dann wäre sogar der Aufruf aus anderem Umgebungen heraus denkbar.
Neuen User zum APEX Workspace hinzufügen
Basierend auf obigem Skript, ist diese Aufgabe sehr einfach.
Wichtig ist hier vor allem der Parameter p_developer_privs. Das obige Skript
generiert einen Workspace-Administrator. Wenn ein Entwicklerkonto generiert
werden soll, lässt man ADMIN weg und übergibt CREATE:DATA_LOADER:EDIT:HELP:MONITOR:SQL.
Ein End-User wird schließlich erzeugt, in dem SQL NULL übergeben wird.
Passwort eines APEX Workspace Users ändern
Analog dazu kann auch das Passwort eines APEX-Workspace-Users sehr einfach per
Kommandozeile geändert werden. Dazu bringt APEX zwar schon den einen oder anderen
Aufruf mit ...
- APEX_UTIL.CHANGE_CURRENT_USER_PW erlaubt das explizite Ändern des Passworts,
aber nur für eine gegebene APEX-Sitzung und nur für den angemeldeten User. Diese
Funktion ist geeignet, um bestehende APEX-Anwendungen mit einem Dialog
zum Ändern des Passworts auszustatten.
- APEX_UTIL.RESET_PW erlaubt das Zurücksetzen für einen angegebenen User; allerdings
bekommt dieser das neue Passwort per Mail zugeschickt. Wenn keine oder eine ungültige
Mailadresse hinterlegt ist, nutzt diese Funktion nichts.
Gesucht wäre eine PL/SQL-Funktion, welche das gleiche tut, wie der
Dialog der APEX-Administrationsoberfläche: Die Auswahl eines Users und das
explizite Eingeben des neuen Passworts. In der Praxis braucht es gerade das sehr
häufig.
Die Basis zur Umsetzung ist die Funktion APEX_UTIL.EDIT_USER. Diese erlaubt das
Ändern aller Attribute eines APEX Workspace-Users, darunter auch das Passwort. Allerdings
müssen alle Attribute neu angegeben werden - die Funktion erkennt SQL NULL eben nicht
als "keine Änderung". Der direkte Aufruf ist also wiederum etwas umständlich, also erzeugen
wir eine PL/SQL-Prozedur zum einfachen Aufrufen.
Diese neue Prozedur CHANGE_APEX_USER_PASSWORD hat eine sehr einfache Schnittstelle und
funktioniert sogar für den zentralen APEX-ADMIN-User (User ADMIN im Workspace INTERNAL). Der
Unix-Login auf dem Datenbankserver (zum Aufrufen von apxchpwd.sql) ist also nicht mehr
nötig.
Applikationen importieren
Zum Thema Export und Import von APEX-Anwendungen per Kommandozeile existieren
schon einige Community-Tipps.
Zum Exportieren per Kommandozeile braucht es den Aufruf des
Java-basierten Werkzeugs APEXExport.
Die enstehende SQL-Datei kann dann in
SQL*Plus wie jedes andere SQL Skript eingespielt werden. Soll die Anwendung
in ein anderes Workspace eingespielt werden oder eine neue Anwendungs-ID
erhalten, so leistet das Paket APEX_APPLICATION_INSTALL
wertvolle Dienste. Das folgende Skript ist ein Beispiel für ein "interaktives"
APEX Importwerkzeug in SQL*Plus. Hierfür brauchen sie übrigens keine DBA-Privilegien;
Sie müssen lediglich als der User angemeldet sein, der dem APEX-Workspace "als Schema"
zugeordnet ist.
Die Nutzung sieht etwa so aus ...
Natürlich kann man ein solches Skript noch weiter ausbauen. Interessant ist auch
die Kombination mit dem eingangs erwähnten Skript zum Erstellen von APEX-Workspaces;
denn so lässt sich ein neuer APEX-Workspace automatisch mit eigenen Beispiel-
bzw. "Kochbuch"-Anwendungen ausstatten.
Attribute von APEX-Anwendungen setzen
Im Oracle SQL Developer gibt es einen Bereich Application Express, in dem
sich das eine oder andere Attribut einer APEX-Anwendung ändern lässt. Interessant
dabei ist, dass der SQL Developer dabei stets ein Show SQL anbietet, mit dem man
sich ansehen kann, mit welchem Code die Aktion durchgeführt wird.
Abbildung 1: Attribute von APEX-Anwendungen per SQL Developer ändern
Das probieren wir
nun anhand der Global Notification aus - denn gerade diese
möchte man u.U. auch ohne Zugriff auf den APEX Application Builder ändern. Das folgende
SQL*Plus Skript macht genau dies. Allerdings muss hierzu gesagt werden, dass die verwendeten Aufrufe
des PL/SQL-Pakets WWV_FLOW_API nicht dokumentiert sind. Testen Sie also vorher.
Wichtige Nachrichten können nun auch ohne Entwicklerzugang zur APEX-Anwendung
(ggfs. sogar automatisiert) gesetzt werden.
APEX-Anwendungen löschen
Schaut man in eine APEX Exportdatei hinein, so stellt man fest, dass das Löschen
einer APEX-Anwendung sehr einfach ist. Gleich zu Beginn finden sich die
Aufrufe von WWV_FLOW_API.REMOVE_FLOW und WWV_FLOW_AUDIT.REMOVE_AUDIT_TRAIL. Damit lässt sich - analog zu obigem Importier-Skript -
ein "Lösch-Skript" bauen.
Wie bereits weiter oben, beim Ändern der Anwendungsattribute, wird auch hier
das Paket WWV_FLOW_API verwendet, welches nicht dokumentiert ist. Sie können
eine APEX-Anwendung alternativ auch mit dem dokumentierten APEX_INSTANCE_ADMIN.REMOVE_APPLICATION
löschen - dann benötigen Sie aber einen DBA-User oder die Rolle APEX_ADMINISTRATOR_ROLE.
Die Nutzung sieht etwa so aus ...
APEX-Instanzparameter verwalten
In der APEX-Administration (Workspace INTERNAL) werden neben der Workspace- und
Nutzerverwaltung auch zahlreiche Parameter eingestellt. Auf der Kommandozeile dienen dazu
die Aufrufe GET_PARAMETER und SET_PARAMETER im Paket APEX_INSTANCE_ADMIN. Hierfür brauchen Sie wiederum DBA-Privilegien. Die verschiedenen
Parameter, die sich nutzen lassen, sind in der Dokumentation zu APEX_INSTANCE_ADMIN
aufgeführt. Das folgende Beispiel ruft den aktuell eingestellten Emailserver ab und stellt
diesen um.
Fazit
Somit lassen sich sehr viele administrative Aufgaben auch ohne die APEX-Weboberfläche
ausführen. Insbesondere das Provisionieren neuer APEX Workspaces oder Nutzerkonzen bzw.
das Zurücksetzen von Passwörtern lässt sich auf diesem Wege sehr elegant in zentrale
Ticket- und Provisionierungssysteme integrieren - so dass ein APEX Workspace auf dem
gleichen Wege bereitgestellt werden kann wie ein Email-Konto.
Natürlich sind die Möglichkeiten damit noch lange nicht erschöpfend beschrieben: Nimmt
man das APEX Data Dictionary hinzu, so lassen sich auch zahlreiche Reports und ggfs.
auch Alertings aus der APEX Engine heraus generieren - die APEX-Umgebung wird damit
- ebenso wie die Oracle-Datenbank selbst - ein normaler Teil der IT-Infrastruktur. Wie die
Integration in ein Werkzeug aussehen kann, zeigt übrigens das
APEX-Workspace Plugin für den SQL Developer,
welches in der APEX Community vor einiger Zeit vorgestellt wurde. Auch
dieses basiert auf den hier beschriebenen PL/SQL-Paketen.
Zurück zur Community-Seite
|