Automatisierter Export und Import von APEX-Anwendungen per Kommandozeile
Stand |
APEX-Version |
Datenbankversion |
März 2016 |
alle |
alle |
Wenn APEX-Installationen im Rechenzentrum betrieben werden, entsteht immer häufiger die
Notwendigkeit, Anwendungsexporte nicht mehr über die APEX-Oberfläche, sondern skriptgesteuert
durchzuführen. Ein Grund dafür kann bspw. sein, dass das die APEX-Entwicklungsumgebung auf
dem Produktivsystem entfernt wurde (Runtime-Only-Install). Neue
Anwendungen müssen also auf einem anderen Wege installiert werden. Auch kann es interessant sein,
die Anwendungen des Entwicklungssystems (bspw. jeden Abend) automatisiert zu exportieren und (zum Beispiel)
in das Versionskontrollsystem einzustellen.
Es ist nicht jedem bekannt, aber APEX bringt die nötigen Werkzeuge bereits mit. Wenn Sie
APEX heruntergeladen und das ZIP-Archiv ausgepackt haben, befinden sich die Exportwerkzeuge
im Verzeichnis utilities und dort unter oracle und apex. Allerdings liegen die Werkzeuge nur als reine Java-Klassendateien (.class) vor.
Damit sie nutzbar werden, sind noch ein paar Vorbereitungen nötig.
Unterverzeichnis "utilities"
Vorbereitungen
Um die Werkzeug benutzen zu können, erzeugen Sie sich am besten zunächst
ein Unix-Skript bzw. eine Windows-Batch-Datei.
Passen Sie jedoch bei den folgenden Skripten die
Umgebungsvariablen ORACLE_HOME und
APEX_HOME an Ihre Umgebung an.
Die Werkzeuge sind in Java geschrieben, brauchen also eine Java-Umgebung, um laufen zu können. In diesem
Beispiel nehmen wir die Java-Umgebung, die mit der Oracle-Datenbank mitinstalliert wird ($ORACLE_HOME/jdk). In einer Oracle11g-Datenbank ist das ein Java 1.5, Oracle12c bringt Java 6 mit. Sie können natürlich auch das aktuellste Java 8 herunterladen und verwenden. Welche Java-Version Ihnen vorliegt, finden Sie am einfachsten wie folgt heraus:
Wenn Sie die in den Skripten referenzierte Dateien ojdbc5.jar, ojdbc6.jar oder ojdbc7.jar in Ihrer Installation nicht finden können, laden Sie sie einfach aus dem OTN herunter und passen Sie die Skripte entsprechend an.
In diesem Beispiel wird die JDBC-Datei ojdbc6.jar angesprochen. Achten Sie hier bitte
genau darauf, die richtige zu nehmen. Prüfen Sie zunächst, wie oben bereits erwähnt,
mit java -version die Java-Version und nehmen Sie dann ...
- ojdbc5.jar, wenn Sie ein Java der Version 1.5 verwenden
- ojdbc6.jar, wenn Sie ein Java der Version 1.6 verwenden
- ojdbc7.jar, wenn Sie ein Java der Version 1.7 oder höher verwenden
Auf Windows-Systemen sieht das Skript wie folgt aus:
Informationen über den Aufruf erhält man, wenn man das Skript ohne Parameter aufruft.
Richten Sie anschließend das Splitter-Werkzeug ein. Damit können Sie die APEX-Exportdatei in
ihre Bestandteile zerlegen. Legen Sie die Skripte wie vorhin an, verwenden Sie in der letzten
Zeile nur anstelle der Klasse APEXExport die Klasse APEXExportSplitter.
Auf Windows-Systemen sieht das Skript wie folgt aus:
Exportieren per Kommandozeile
Wenn Sie die Skripte bzw. Batchdateien fertig haben, kann es losgehen. Das folgende Beispiel
exportiert eine Anwendung (in diesem Beispiel wurde das oben beschriebene Unix-Skript
export-skript.sh genannt).
Die Skriptausgabe ist recht unspektakulär, aber im Betriebssystemverzeichnis befindet sich
nun die Datei f100.sql, genauso, als ob Sie den Export
über die APEX-Oberfläche gemacht hätten.
Wenn es nun daran geht, die Datei in ein Versionskontrollsystem einzustellen, kann es interessant
sein, die Datei in ihre Komponenten aufzusplitten. Gegebenenfalls möchte man ja nur eine einzelne
Seite auf dem Produktivsystem neu einspielen. Dazu dient der APEXExportSplitter.
Und der funktioniert wie
folgt.
Auch hier ist die Ausgabe eher unspektakulär - aber im Hintergrund ist einiges entstanden ...
Abbildung 2: Die APEX Exportdatei wurde in die einzelnen Komponenten aufgespalten
Der Splitter kann übrigens auch mit Exportdateien arbeiten, die aus der Oberfläche heraus
exportiert wurden. Jede einzelne der Komponenten kann auch einzeln wieder importiert werden.
Wenn Sie den Splitter mit der Option -update aufrufen, vergleicht
das Werkzeug die Dateien
anhand einer Checksumme und generiert ein Update-Skript, welches nur die veränderten
Anwendungsteile neu einspielt. Diese Optionen sind sehr hilfreich, wenn die Komponenten in
ein Versionskontrollsystem eingecheckt werden.
Importieren der Dateien - mit der Kommandozeile
Wenn Sie sich eine Exportdatei
genauer ansehen, dann stellen Sie fest, dass es im Grunde genommen ein SQL-Skript ist - und
SQL-Skripte können mit SQL*Plus eingespielt werden. Und genau das ist schon seit
dem ersten Release von Application Express möglich - Kommandozeilen-Imports waren prinzipiell
also schon immer möglich. Man muss jedoch etwas tun, wenn eine
Exportdatei in ein anderes Workspace eingespielt werden soll oder wenn die Applikations-ID auf
dem Zielsystem eine andere sein soll (weil die Original-ID vielleicht schon belegt ist). Beginnen
wir mit dem Import in einen anderen Workspace. Zunächst loggen Sie sich mit SQL*Plus ins Datenbankschema,
welches dem Ziel-Workspace zugeordnet ist, ein ...
Danach starten Sie das Skript ...
Sie werden recht schnell feststellen, dass der Import so nicht funktioniert. Die in der Exportdatei
hinterlegte Workspace-ID ist eine andere als die des Workspace, in den Sie importieren möchten. Während
die APEX-Entwicklungsumgebung damit problemlos umgehen kann, müssen Sie beim Kommandozeilenimport
selbst aktiv werden. Und die erste Aktion ist, die Workspace-ID festzustellen - das machen Sie ebenfalls
in SQL*Plus.
Die in der Exportdatei verwendete Workspace-ID muss also durch diese ersezt werden. Es ist aber
nicht nötig, die Exportdatei zu "hacken" - APEX bringt dafür das PL/SQL Paket APEX_APPLICATION_INSTALL mit. Mit diesem Paket können Workspace- und Applikations-ID, aber auch
andere Einstellungen, die in der Zielumgebung anders sein könnten (bspw. Parsing Schema oder Applikations-Alias), gesetzt werden.
Im folgenden stellen wir
mit APEX_APPLICATION_INSTALL die richtige Workspace-ID ein und stellen darüber hinaus
die neue Application-ID auf 999999 ein.
Danach starten Sie nochmal das Skript f100.sql. Insbesondere wenn Sie auf der gleichen
Datenbank importieren, aus der heraus auch exportiert wurde, werden Sie dann aber
wahrscheinlich den folgenden Fehler sehen ...
Der Grund hierfür sind die generierten Primärschlüssel für die einzelnen Komponenten;
APEX versucht hier, eine ID wiederzuverwenden, was natürlich nicht geht - jede ID darf
nur einmal vorhanden sein. Aber auch hierfür bietet APEX_APPLICATION_INSTALL Abhilfe. Machen
Sie einen zusätzlichen Aufruf von APEX_APPLICATION_INSTALL.SET_OFFSET. Nehmen Sie irgendeine
Zufallszahl als Offset oder, wenn Sie sich eine solche nicht ausdenken wollen, nehmen Sie GENERATE_OFFSET. APEX wird diesen Offset dann
beim Erzeugen der Primärschlüssel berücksichtigen und so auf eindeutige Werte kommen.
Danach läuft das Skript problemlos durch.
Wenn Sie sich in das Workspace einloggen, ist die importiere APEX-Anwendung unter der neuen
ID 999999 vorhanden (Abbildung 3).
Abbildung 3: Die Applikation wurde per Kommandozeile erfolgreich importiert
Einzelne Anwendungskomponenten zurückspielen
Als nächstes wird gezeigt, wie Sie eine einzelne Komponente in Ihre Anwendung zurückspielen können.
Angenommen, Sie haben die Seite 2 versehentlich gelöscht oder Sie möchten aus einem anderen
Grund nur für die Seite 2 auf den Stand der Exportdateien zurückgehen. Im besten Fall liegen
die Exportdateien im Versionskontrollsystem, so dass Sie sich die gewünschte Version
aus diesem herausziehen und zurückspielen können.
Vorab sei gesagt, dass das Einspielen einzelner Dateien, die durch den Splitter erzeugt wurden, nicht
zu empfehlen ist. Es wird sehr häufig zu Fehlern führen, da nahezu jede Seite Gemeinsame Komponenten referenziert.
Insbesondere wenn die Exportdatei aus einem anderen Workspace oder einer anderen Applikation stammt, werden die
APEX-internen Primär- und Fremdschlüssel nicht mehr zusammenpassen und der Import wird mit Fehlern abgebrochen.
Einfacher ist es, die ganze Applikation als neue Anwendung zu importieren (das kann im Application Builder
oder per Kommandozeile erfolgen) und die fragliche Komponente dann als
Kopie aus dieser Anwendung neu zu generieren. Abbildung 4 zeigt dies am Beispiel
einer neuen Seite, die als Kopie einer Seite aus einer anderen Anwendung erstellt wird.
Abbildung 4: Neue Seite als Kopie einer anderen Anwendung erstellen
Diese Vorgehensweise ist auch mit vielen Gemeinsamen Komponenten möglich: Nahezu überall können diese
als Kopie einer anderen Komponente, aus einer anderen Anwendung, erzeugt werden.
Wie man sieht, können die beiden unscheinbaren Java-Dateien APEXExport.class und APEXExportSplitter.class
die Grundlage für ein mächtiges und ausgefeiltes APEX-Versionsmanagement sein. Ein Export per Kommandozeile
lässt sich als Job aufsetzen und so ist das tägliche, automatisierte Exportieren aller Anwendungen ein
Kinderspiel. Auch das automatische Einspielen in ein anderes System (bspw. ein Testsystem) lässt sich
gut realisieren. Schließlich finden Entwickler im Versionskontrollsystem auch ältere Versionen, die sie
zurückspielen und so u.U. versehentlich gelöschte oder veränderte Komponenten wiederherstellen können. So
wird mit APEX eine ebenso professionelle Entwicklung möglich wie mit anderen Umgebungen.
Zurück zur Community-Seite
|