Kategorie: Softwarekonfigurationsmanagement (SCM)

Veröffentlicht am

Konfigurationsmanagement für Oracle APEX -Teil 2 Delta, Merge und Forks

Im zweite Teil der Reihe geht es um das Zusammenführen (merge) von parallelen Entwicklungssträngen (fork) von Oracle APEX-Anwendungen.

Das Zusammenführen zweier paralleler Entwicklungsstränge bringt einiges an Aufwand mit sich. Ich möchte Ihnen in diesem Beitrag ein mögliches Vorgehe beschreiben.

Zu Anfang geht es darum sich das Delta der beiden Releases bewusst zu machen. In welchen Punkten weichen die Datenbank Schemas voneinander ab? Welche Datenbankobjekte müssen in dem Zielschema neu erzeugt werden? Welche werden nicht mehr benötigt oder müssen angepasst werden?

Im zweiten Schritt stellen Sie sich ähnliche Fragen für die eigentliche Anwendung. Welche Anwendungsteile, seien es Seiten, Regionen, Items oder Shared Components, sind neu, entfallen oder wurden geändert?

Aus diesen Analysen ergibt sich eine ToDo Liste der Anpassungen, die Sie durchführen müssen.

Im nächsten Schritt führen Sie die Objekte der Schemas zusammen, so dass Sie ein gemeinsames neues Datenmodell für das neue Release erhalten. Auf dieser Basis passen Sie dann die Supporting Objects im Basisentwicklungsstrang an.

Zu guter Letzt, geht es noch an das Überarbeiten der Anwendung. Dabei müssen Sie neue Seite aus dem parallelen Release in die Basisversion integrieren. Evtl. müssen Sie nicht mehr benötigte Bestandteile entfernen. Der aufwändigste Part wird in der Regel die manuelle Integration von partiellen Änderungen , z.B. in einer vorhandenen Seite sein.

Datenmodelle vergleichen und Unterschiede ermitteln

Es gibt sicher viele Ansätze, mit denen Sie ausgehend von einem Entwicklungsstand eines Datenmodells die Änderungen zu einem neues Release ermitteln können. An dieser Stelle möchte Ich Ihnen zwei Varianten vorstellen.

Änderungen protokollieren

Mit etwas Disziplin könnten Sie jede Änderung, die Sie vornehmen, als DDL-Skript speichern. Ich persönlich finde allerdings, dass man durch solche Verwaltungsaufgaben immer aus seinem Arbeitsfluss gerissen wird. Wenn Sie so ein Vorgehen präferieren, dann schauen Sie sich doch einmal diesen Beitrag Protokollieren von Strukturänderungen an. Dort stelle ich Ihnen eine Möglichkeit vor, wie Sie einen DDL-Trigger nutzen können, der alle Änderungen an einem Schema protokolliert.

Abbildung 1: Änderungshistorie

Auf Basis dieses Protokolls können Sie ein DDL-Skript entwickeln, um damit das Datenmodell eines Releases in das Modell eines neueren Releases zu überführen.

Schema vergleichen

APEX bringt aber auch von Haus aus eine sehr nützliche Funktion für diesen Fall mit. Im SQL Workshop finden Sie im Bereich Utilities den Link Schema Comparison. Da hinter verbirgt sich ein Werkzeug, mit dem Sie die Objekte eines Schemas mit denen eines anderen Schemas vergleichen können. Ihnen werden allerdings nur die Schemas angezeigt, die dem Workspace zugeordnet wurden.

Wie Sie im ersten Teil dieser Beitragsreihe lesen konnten, können Sie einem APEX-Workspace mehrere Schemas zuordnen. Möchten Sie nun für eine neue Version Ihrer Anwendung ein Upgrade-Skript entwickeln, so können Sie wie folgt vorgehen.

Stellen Sie aus Ihrem Anwendungsarchiv die Vorgängerversionen Ihrer Anwendung wieder her.

Abbildung 2: Anwendung in neuem Schema wiederherstellen

Dabei wählen Sie ein anderes Schema als bei der aktuellen Version Ihrer Anwendung. Wenn Sie in Ihrer Anwendung die notwendigen DDL-Skripte als Supporting Objects hinterlegt haben, führen Sie diese bei der Installation aus.

Abbildung 3: Install Supporting Objects

Jetzt haben Sie in Ihrem Workspace das Schema Ihres Basisentwicklungsstrangs und das Schema des Vorgänger Releases im Zugriff.

Den Vergleich der jeweils enthaltenen Objekte können Sie anschließend mit Hilfe des Utilities Schema Comparison durchführen.

Abbildung 4: Schema Vergleichen

Die Handhabung ist einfach. Wählen Sie die zu vergleichenden Schemas aus und legen Sie bei Bedarf noch einen Filter fest. Dann klicken Sie auf Compare.

Abbildung 5: Schemas vergleichen

Als Ergebnis erhalten Sie eine Übersicht der abweichenden Datenbankobjekte. Anhand dieser Liste können Sie die fehlenden DDL-Skripte erstellen.

Anwendungsteile vergleichen, Unterschiede ermitteln

Eine APEX-Anwendung wird durch Ihre Eigenschaften definiert. Diese Daten werden bei APEX in Tabellen gespeichert. Diese strukturierte Ablage der Definition macht es möglich, Anwendungen sehr detailliert vergleichen zu  können.

Im Internet findet man vereinzelt Ansätze, mit denen Sie die Unterschiede zweier Anwendungen ermitteln können. Beispielsweise existiert ein Open Source Projekt auf github namens apex-diff, welches einen Vergleich ermöglicht.

Ein andere Möglichkeit bieten die APEX-Views. Über diese können Sie entsprechende select-Statements  entwickeln, die einzelne Bestandteile zweier Anwendungen miteinander abgleichen. So ein Abgleich – hier für die Pages – kann z.B wie in Listing 1 aussehen.

SELECT
    n.page_id,
    n.page_name,
    'Page was changed ( N: '
    || n.last_updated_on
    || ' , O: '
    || o.last_updated_on || ' )' AS info
FROM
    apex_180100.apex_application_pages n,
    apex_180100.apex_application_pages o
WHERE
    n.application_id = 115
    AND o.application_id = 113
    AND n.page_id = o.page_id
    AND n.last_updated_on <> o.last_updated_on
UNION
SELECT
    n.page_id,
    n.page_name,
    'New page in application ' || n.application_id AS info
FROM
    apex_180100.apex_application_pages n
WHERE
    n.application_id = 115
    AND NOT EXISTS (
        SELECT
            'X'
        FROM
            apex_180100.apex_application_pages o
        WHERE
            o.application_id = 113
            AND n.page_id = o.page_id
    )
UNION
SELECT
    o.page_id,
    o.page_name,
    'Deleted page ' AS info
FROM
    apex_180100.apex_application_pages o
WHERE
    o.application_id = 113
    AND NOT EXISTS (
        SELECT
            'X'
        FROM
            apex_180100.apex_application_pages n
        WHERE
            n.application_id = 115
            AND n.page_id = o.page_id
    );

Listing 1: App 115 mit App 113 vergleichen

Das Ergebnis sieht dann beispielhaft so aus.

Abbildung 6: Abweichende Seiten zweier APEX-Anwendungen

Auf Basis der APEX-Views können Sie auf diese Art und Weise für alle Komponenten einer APEX -Anwendung entsprechende Vergleiche erstellen.

APEX selbst bietet für den Anwendungsvergleich unter seinen Workspace–Utilities aber auch ein entsprechendes Werkzeug namens Application Comparison.

Abbildung 7: APEX-Anwendungen vergleichen

Dieses liefert Ihnen eine Liste mit abweichenden Objekten.

Zusammenführen von Entwicklungszweigen (fork)

Grundsätzlich müssen Sie hier zwei Bereiche der Anwendung betrachten. Die Datenbankobjekte und die Anwendung.

Datenmodell bzw. Datenbankobjekte

Auf Basis der im vorhergehenden Abschnitt ermittelten Unterschiede können Sie nun das Schema des Basisentwicklungsstrangs auf den benötigten aktuellen Stand bringen.

Zuerst legen Sie die neue Objekte an. Dazu können Sie z.B. ein DDL-Statemit auf Basis des vorhandenen Objektes extrahieren oder Sie ermitteln die DDL- Anweisung wie oben beschrieben mit einem DDL-Trigger aus einer Log Tabelle.

Abweichende Datenbankobjekte (Tabellen, Views , Packages,…) müssen nun von Hand überarbeitet werden. Hier müssen Sie entscheiden, ob eine Version durch eine aktuelle Version komplett ersetzt werden kann oder ob eine manuelle Ergänzung notwendig ist. Als Beispiel seien hier neue Spalten in einer Tabelle oder neue Funktionen in einem PL/SQL Package erwähnt.

Als Ergebnis haben Sie in Ihrem Basisschema abschließend alle benötigten Datenbankobjekte aus beiden Entwicklungssträngen zusammen gefügt.

Supporting Objects

APEX bietet mit den Supporting Objects – wie bereits erwähnt – die Möglichkeit DDL und DML-Skripte in der Anwendung zu hinterlegen, die bei der Installation der Anwendung ausgeführt werden.

Ein einfacher Ansatz ist es ein DDL-Skript zu entwickeln, welches alle benötigten Datenbankobjekte von Grund auf neu erzeugt. Da es aber recht zeitaufwendig und fehleranfällig ist ein komplett neues Installationsskript zu erstellen, können Sie auch einfach ein weiteres DDL-Skript nach dem bereits vorhandenem laufen lassen. Dieses ergänzt dann die neuen Objekte.

Die Migration der bestehenden Daten einer produktiven Vorgängerversion kann in einem zweiten Schritt über ein Upgrade Skript erfolgen. Bei diesem Ansatz fügen Sie dem produktiven Workspace ein neues Schema hinzu in dem Sie die Anwendung inkl. aller Datenbankobjekte des neuen Releases installieren. Abschließend wird dann über die Supporting Objects ein Skript ausgeführt, welches die Daten aus der Vorgängerversion in die neue Tabellen des neuen Schemas überführt.

Dieser Ansatz bietet aus meiner Sicht den Vorteil, dass Sie immer eine sehr einfache Fallback-Variante haben. Die Altdaten und die alte Anwendung werden nicht angetastet und können im Fehlerfall weiter genutzt werden.

Werkzeuge

APEX bietet in seinem SQL Workshop das Werkzeug Generate DDL, mit dem Sie – auch selektiv – für vorhandene Datenbankobjekte DDL-Skripte erzeugen können.

Abbildung 8: SQL Workshop-Generate DDL

Auf dieser Basis können Sie dann  entsprechende Skripte erstellen und diese in den Supporting Objects hinterlegen.

Ein anderes sehr nützliches Tool finden Sie direkt in den Supporting Objects. In dem Bereich Installation Scripts können Sie über die Schaltfläche Create > einen Wizzard starten, der Ihnen zu Beginn u.a. die Option “Create from Database Object’ anbietet.

Abbildung 9: Supporting Objects – Install

Bei dieser Variante können Sie für verschiedene Datenbankobjekte entsprechende DDL Skripte erzeugen lassen und direkt in den Supporting Objects speichern.

Abbildung 10: Create from Database Object

Anwendungsteile zusammen führen

Jetzt müssen Sie sich noch um die Anwendung selbst kümmern. Leider ist auch hier einiges an Handarbeit angesagt. Es sind verschiedene Bereiche zu berücksichtigen.

Meine Empfehlung ist es mit den Shared Components zu beginnen. Da diese von verschiedenen anderen Teilen Ihrer Anwendung verwendet werden. Anschließend sind die Seiten und deren Bestandteile an der Reihe.

Shared Components

Um die Bestandteile der Shared Components von einer Anwendungsversion in eine Andere zu übernehmen, gibt es verschiedene Methoden.

1. Es gibt Komponenten bzw. Einstellungen, die Sie schlicht manuell überführen müssen.

2. Einige der Komponenten können Sie über Create > As a Copy of an … > Copy from Application aus einer anderen Anwendung des Workspaces übernehmen. Wo immer es geht, sollten Sie diese Möglichkeit nutzen. Eine Übersicht der Shared Components, bei denen ich diese Möglichkeit gefunden habe, finden Sie in Abbildung 11.

Abbildung 11: Shared Components mit Kopierfunktion

3. Als Alternative bietet sich für die meisten Shared Components noch der Export und anschließende Import an. Wobei auch dieser Ansatz durch notwendige Anpassungen (Workdpace-Id, App-Id und evtl. ein Offset) an dem Exportfile nicht optimal ist. Beachten sie bitte, dass beim Import Komponenten wie z.B. Seiten durch Seiten mit der gleichen Id überschrieben werden. Mehr dazu finden Sie unter anderem hier.

Pages und Co.

Als letzter Schritt sind jetzt noch die eigentlichen Seiten und deren Inhalte abzugleichen.

Neue Seiten können Sie über den Application Builder aus dem parallelen Release in Ihre Basisanwendung übernehmen. Dazu klicken Sie im Page Designer auf das + in der Toolbar. In dem sich öffnenden Drop-Down-Menü wählen Sie Page as Copy.

Abbildung 12: Seite kopieren

Jetzt folgen ‘Sie nur noch dem Wizzard und geben dabei an, dass Sie eine Seite aus einer anderen Applikation kopieren möchten. (Page in another Application)

Möchten Sie eine bereits vorhandenen Seite komplett ersetzen, so können Sie die neue Seite mit einer anderen PageId erzeugen lassen oder Sie löschen im Vorfeld die ursprüngliche Seite und kopieren die Seite dann mit der herkömmlichen Seitennummer.

Abbildung 13: Seiten können nicht direkt ersetzt werden

Geht es Ihnen darum, nur einzelne Bestandteile einer Seite aus dem Fork zu übernehmen, müssen Sie im ersten Schritt die Quellseite aus dem Fork in die Basisversion als Kopie einfügen. Anschließend öffnen Sie diese Seite und klicken mit der rechten Maustaste auf die Bestandteile der Seite die Sie kopieren möchten. In dem sich öffnenden Kontextmenü wählen Sie den Eintrag Copy to other Page und beantworten anschließend die Fragen des Wizzards.

Abbildung 14: Bestandteile in eine andere Seite kopieren

Wie bereits in dem Abschnitt über das Kopieren der Shared Components erwähnt, bietet APEX die – meiner Meinung nach nicht zu Ende gedachten Funktion – des Komponenten-Exports und -Imports. Über diese Funktion ist es Ihnen möglich selektiv Bestandteile einer Anwendung zu exportieren. Vor dem Import der Komponenten müssen Sie aber auch hier vorab das SQL-Skript manuell anpassen.(s.o.)

Fazit

Es ist schon ein mühsames Geschäft, verschiedene Versionen einer Anwendung zu Verwalten und zu beherrschen. Ich versuche immer parallele Entwicklungsstränge nach Möglichkeit zu vermeiden. Der Aufwand diese Stränge wieder in einem Basisentwicklungsstrangs zusammenzuführen ist mitunter sehr aufwändig.

Allerdings treffen Sie auch auf ähnlich Probleme, wenn Sie versuchen Komponenten aus bereits vorhanden Anwendungen in einer neuen – thematisch vielleicht anders gelagerten – Anwendung zu übernehmen und wiederzuverwenden. Auf Komponentenbasis stehen Ihnen dafür Plug/Ins zur Verfügung. Für zusammenhängende Teile (Module) eine Anwendung, die aus mehreren Seiten, Shared Components und Datenbankobjekten bestehen, bietet APEX kein wirklich praxistaugliches Konzept.

Sie können Funktionalitäten höchsten in kleine, in sich abgeschlossenen Anwendungen aufteilen. Dies funktioniert in der Praxis aber meist nur, wenn Sie auf Single Sign On setzen.

Beitragsreihe

[catlist name=”APEX SCM (Reihe)”]

 

Veröffentlicht am

Konfigurationsmanagement für Oracle APEX -Teil 1 Versionsverwaltung

Versionsverwaltung und Konfigurationsmanagement ist für den Entwicklungszyklus gerade auch im Rahmen agiler bzw. iterativer Entwicklung von Oracle Application Express (APEX) Anwendungen ein wichtiges aber sicherlich oft vernachlässigtes Thema. Im ersten Teil geht es um die Versionierung und das Betreiben unterschiedlicher paralleler Versionen in einer Entwicklungsumgebung.

Was versteht man unter Konfigurationsmanagement?

Laut Wikipedia versteht man unter Konfigurationsmanagement 

“Konfigurationsmanagement (KM; englisch configuration management, CM) ist eine Managementdisziplin, die organisatorische und verhaltensmäßige Regeln auf den Lebenslauf eines Produkts und seiner Konfigurationseinheiten [..] anwendet.

[..]

Es sind vier Teilgebiete (Teilprozesse) des KM zu unterscheiden:

  • Konfigurationsidentifizierung (KI),
  • Konfigurationsbuchführung (KB),
  • Konfigurationsüberwachung (KÜ) und
  • Konfigurationsaudit (KA).

Ihre koordinierte Umsetzung ist für ein erfolgreiches Konfigurationsmanagement unumgänglich.“

Quelle: https://de.m.wikipedia.org/wiki/Konfigurationsmanagement, 24.06.2018

Im Rahmen der Entwicklung von Software spricht man von Software-Configuration-Management(SCM).

Wie bei vielen Managementsystemen kommen solche Definitionen meist sehr sperrig daher. Im Rahmen der Anwendungsentwicklung mit APEX soll hier eine pragmatische Umsetzung des Ganzen gezeigt werden.

Agile Softwareentwicklung mit APEX

Beginnt man ein neues APEX-Projekt, so wird man je nach Projektmanagementmethode und Größe des Projektes unterschiedlich an die Sache heran gehen.

Aus meiner Sicht bietet sich aber gerade ein agiles Vorgehen für die Entwicklung von APEX-Anwendungen an. Welches konkrete Vorgehensmodell Sie dabei wählen ist zweitrangig.

Bei einem agilen Ansatz starten Sie mit einem ersten Teil Ihres Datenmodells und entwickeln dann sehr zügig die jeweiligen Seiten in Ihrer Anwendung. So erhalten Sie sofort vorzeigbare Anwendungsteile, die Sie mit Ihren Kunden, Productowner, … durchsprechen und abstimmen können.

Aber auch wenn Sie grossschrittiger vorgehen müssen und Ihren Kunden fertig entwickelte Releases ausliefern, gehen Sie als Entwickler wahrscheinlich itterativ an die Sache heran.

Sie starten also mit einem leeren Schema und einem Workspace, erstellen die ersten Tabellen. Dann kann schon die erste Version der Anwendung per Application Wizzard erzeugt werden. Durch die Nutzung der Metadaten, welche die Datenbank APEX zur Verfügung stellt, fügen Sie die ersten Seiten der Anwendung hinzu. Jetzt erweitern Sie das Datenmodell und ergänzen die zugehörigen Seiten in der Anwendung. Die Businesslogik lagern Sie in PL/SQL-Packages aus. Je nach Komplexität und Umfang des Projektes abstrahieren Sie zwischen Datenmodell und Anwendung noch über Views. Auf diese Weise entstehen sukzessive weitere Datenbankobjekte und Anwendungsteile.

Alle diese Teile sind Bestandteil einer sogenannten Konfigurationseinheit.

Sie erzeugen also eine Kette von Builds, die dann weiter zu einem Release der Anwendung führen.

Anschließend oder auch schon parallel werden Sie die Anwendung in einem Testsystem mehr oder weniger ausgiebig testen (lassen) und dann an Ihren Kunden ausliefern.

Je nach Anwendung entwickeln Sie das System weiter. In Ihrem Entwicklungssystem steht dann mit großer Wahrscheinlichkeit nicht mehr die Version, mit der Sie Ihre Kunden beliefert haben, zur Verfügung. Dies führt bei Supportanfragen Ihres Kunden dazu, dass Sie in einem Supportsystem, das ausgelieferte System mit entsprechendem Releasestand wiederherstellen müssen. Fixen Sie den Fehler in dem (veralteten Release), so muss die so bereinigte Version bei Ihren Kunden eingespielt werden. Zusätzlich müssen Sie nun das Problem auch noch in Ihrem aktuellen Entwicklungsstand der Anwendung beheben.

Noch komplizierter wird dieses Szenario, wenn Sie verschiedene Releasestände an mehrere Kunden ausgeliefert haben, dabei aber evtl. auch noch individuelle Anforderungen einzelner Kunden berücksichtigten mussten.

Aus diesem Lebenszyklus einer Software ergeben sich verschiedene Probleme:

  • Wie Verwalten Sie unterschiedliche Versionen (Releasestände und Builds) Ihrer APEX-Anwendungen ?
  • Wie erstellen Sie Test-, Integrations- und Supportsysteme, in denen Sie verschiedene Versionen Ihrer Anwendung verwalten können ?
  • Wie führen Sie parallele Entwicklungslinieren (Forkes) wieder in Ihrer Basisanwendung zusammen ?
  • Wie dokumentieren und identifizieren Sie die Änderungen an Ihren Anwendungsversionen inkl. aller Bestandteile (Tabellen, Views, Triggers, PL/SQL-Packages,…) ?

Konfigurationseinheiten: Komponenten einer APEX Anwendung

Aus welchen Bestandteilen besteht denn nun eine APEX-Anwendung?

Wenn Sie versuchen, diese Frage zu beantworten, schauen Sie sich doch einfach an, was Sie alles benötigen, um eine APEX-Anwendung in einem Produktivstem zum Laufen zu bringen.

Vorausgesetzt, dass eine laufende Oracle-Datenbank mit eingerichtetem APEX (in der korrekten Version) zur Verfügung steht, benötigen Sie zuerst ein Export-File der APEX-Anwendung. Dabei handelt es sich um ein SQL-Skript, mit dem Sie eine Anwendung in APEX exportieren und importieren können.

Die Anwendung basiert natürlich auf Tabellen und verwendet verschiedene anderen Datenbankobjekte. APEX bietet die Möglichkeit, diese Datenbankobjekte über entsprechende DDL-Skripte bei der Installation bzw. dem Import einer Anwendung anlegen zu lassen.

Um diese Tabellen initial mit Stammdaten zu füllen, erstellen Sie entsprechende DML-Skripte.

All diese Skripte können Sie in den sogenannten Supporting Objects hinterlegen, die Sie im Application Builder über die gleichnamigen Schaltfläche aufrufen können.

Abbildung 1: Supporting Objects

Auch für das Upgraden einer produktiven Anwendung, ist es möglich in den Supporting Objects Skripte zu hinterlegen, welche die Änderung zum Vorgänger-Release abdecken.

Natürlich kann man das benötigte Datenmodell über einen Dump oder separate SQL-Skripte in einem Produktivstem einrichten. Da die Supporting Objects aber Bestandteil einer APEX-Anwendung sind und diese mit in dem Anwendungs-Exportfile vorhanden sind, ist es am geschicktesten, diese Möglichkeit zu verwenden. Gerade auch im Hinblick auf die Versionsverwaltung bringt das einige Vorteile mit sich.

Versionierung

Damit Sie den Überblick über die Versionsstände Ihrer Anwendung behalten, ist es ganz hilfreich für etwas Ordnung zu sorgen. APEX bietet Ihnen die Möglichkeit, Ihren Anwendungen beschreibende Eigenschaften mitzugeben. Diese Eigenschaften finden Sie etwas versteckt hinter dem Button Edit Application Properties im Application Builder.

Abbildung 2: Anwendungseigenschaften

Wie Sie hier sehen können, finden Sie ein Textfeld namens Release. Hier können Sie für jede Version Ihrer Anwendung den zugehörigen Releasestand festhalten. Das klingt erst einmal banal, bringt aber den praktischen Vorteil mit sich, dass Sie bei einer archivierten oder  ausgeliederten Anwendung wissen, welche Version Ihrer Anwendung Sie gerade vor sich haben.

Aber wie können Sie eine Versionsnummer konzipieren, die Ihnen einen Überblick verschafft?

Es gibt da sicher verschiedene Möglichkeiten. Ich möchte Ihnen hier die von mir bevorzugte Variante vorstellen.

<Hauptentwicklungslinie>.<Entwicklungszweig>.<Build>

Zu Begin einer Anwendungsentwicklung, also vor dem ersten Release geht es also mit 0.0.1 los.

Nach einer Iteration oder dem erreichen eines Meilensteins erhöhen Sie die Build Nr. auf 0.0.2.

Haben Sie eine releasefähige Version Ihrer Anwendung erreicht, so erhöhen Sie die erste Stelle um 1.

Version 1.0.0

Diese Version nehmen Sie produktiv und entwickeln an der Anwendung weiter.

Es entsteht also Build 1.0.1… 1.0.2 …

Müssen Sie einen Fehler in Version 1.0.0 beheben, erstellen Sie einen Forke Ihrer Anwendung und geben diesem die Version 1.1.0. Änderungen an dieser Version laufen jetzt paralell zu Ihrer Hauptentwicklungslinie (Baseline), die bereits bei Version 1.0.2 angelangt ist.

Für einen anderen Kunden erweitern Sie die Version 1.0.0 um eine individuelle Funktion. Diese ist dann wieder ein Forke der Version 1.0.0 und wird mit 1.2.0 benannt.

Um nun den Aufwand dauerhaft in den Griff zu bekommen und den Überblick nicht zu verlieren, ist es ratsam, die Bugfixes aus den Strang 1.1.x und evtl. die kundenspezifischen Funktionen in den Basisentwicklungsstrang zu integrieren (merge). Was in APEX nicht immer so einfach ist. Aber dazu im zweiten Teil der Beitragsreihe später mehr.

Die neuen Funktionen und Bugfixes fulminieren dann irgendwann in einem neuen Release 2.0.0.

Ihre Entwicklungslinien sehen jetzt so aus.

Abbildung 3: Entwicklungsstränge

Im Application Builder werden Ihnen Ihre Anwendungen über ein Interaktiven Report präsentiert. Blenden Sie dort über Actions >> Columns die Version und evtl. andere für Sie relevante Spalten ein. Anschließend speichern Sie sich über Actions >> Report >> Save Report Ihre individuelle Berichtsansichten.

Abbildung 4: Version anzeigen

Hilfreich finde ich auch die Zuordnung von Anwendungen zu Gruppen. Z.B. können Sie so zwischen Test, Produktiv, Support und Entwicklung unterscheiden.

Anwendungsgruppen (Application Groups) legen Sie über das Menü App Builder >> Workspace Utilities-Database >> Application Groups fest. Über die Anwendungseigenschaften (Button Edit Application Properties) ordnen Sie Ihre Anwendung einer Gruppe zu. Diese Gruppen lassen sich genau wie die Version im Interaktiven Report einblenden.

Abbildung 5: Anwendungen gruppieren

Die Abbildung 5 zeigt ihnen eine aufbereitete Übersicht der Anwendungen in APEX, die bei dem oben skizzierten Projektablauf entstanden sind.

Archivierung von Releaseständen

APEX bietet verschiedene Möglichkeiten Anwendungen zu archivieren. Die Basis für diese Ansätze ist ein Exportfile. Über den Application Builder können Sie alle Eigenschaften eines APEX-Programms in Form eines SQL-Skriptes exportieren.

Abbildung 6: Anwendung exportieren

Diese Datei beinhaltet die komplette Definition aller Seiten, Regionen, Items, Prozesse,… aber auch aller Shared Components wie Dateien oder Listen und – wie bereits erwähnt – die Supporting Objects. Nutzen Sie all diese Möglichkeiten, so können Sie die komplette Anwendung inkl. der Datenbankobjekte in einer einzigen Datei zusammenfassen und später diesen (Release)Stand wiederherstellen.

Somit ergibt sich als einfache Möglichkeit verschiedene Versionen einer APEX-Anwendung zu archivieren, der regelmäßige manuelle Export der Anwendung und Speicherung in einer nach Versionen benannten Ordnern. Diese Idee kann man nun mit einer Software zur Versionsverwaltung wie z.B. SVN oder GIT kombinieren. Im Internet finden Sie verschiedene Beispiele, wie Sie mit verschiedenen Tolles diesen Weg automatisieren können.  In dem Artikel ORACLE APEX DEPLOYMENT:YOU’RE DOING IT WRONG stellt Martin D’Souza die Möglichkeit vor, via. SQLcl zu automatisieren.Mit APEX selbst wird der APEX Java Exporter ausgeliefert, über den Ihnen viele Möglichkeiten zum Exportieren von Anwendungen und Komponenten zur Verfügung stehen.

Wählen Sie beim manuellen Exportieren einer Anwendung das File Format “Database”, so archiviert APEX die Datei im sogenannten Export Repository. Dieses finden Sie in den Workspace Utilities-Database >> Export >> Export Repository (in der rechten Sidebar). Allerdings bietet die Tabelle nicht wirklich viele Informationen zu den archivierten Anwendungen.

Abbildung 7: Export Repository

Einen anderen Ansatz finden Sie in diesem Blog-Beitrag. Dabei werden die einzelnen Bestandteile (Seiten) einer Anwendung separat extrahiert und übersichtlich in einem Verzeichnisbaum bzw. der Datenbank gespeichert. Dieser Ansatz lässt auch automatisieren.

Eine weitere ebenfalls automatisierbare Variante bietet Oracle mit einem seiner Packaged Applications “APEX Application Archive”. Mit dieser Applikation lassen sich Backups Ihrer Anwendungen erstellen, die dann in der Datenbank verwaltet werden. Erweitern Sie das Ganze noch mit Hilfe des Datenbankschedulers ( dbms_schedule ), können Sie die Archivierung komplett automatisieren. Wie Sie das im Einzelnen funktioniert, können Sie sich in dieser Beitragsreihe genau ansehen.

[catlist name=”APEX Application Archive”]

Abbildung 8: Anwendungsarchiv auswählen

Ich persönlich favorisiere diese Möglichkeit, da Sie sich sehr schnell einrichten und anpassen lässt und mit der Package Application “APEX Application Archive” ein Programm zur Verwaltung der einzelnen Releasestände zur Verfügung steht.

Parallele Versionen in APEX betreiben

Aber wie können Sie diese unterschiedlichen Versionen Ihrer Anwendungen in APEX parallel bearbeiten und betreiben?

Eine einfache Möglichkeit ist es eine Kopie Ihrer Anwendung in dem Workspace anzulegen.

Allerdings gehören zu Ihrer Anwendung auch ein Datenmodell und die entsprechenden Datenbankobjekte. Diese werden zwischen den einzelnen Releaseständen Ihrer Anwendungen voneinander abweichen.

APEX bietet für dieses Problem eine einfache aber sehr elegante Lösung. Sie können Ihrem Workspace weitere Datenbank-Schemas zuweisen.

Dazu gehen Sie  so vor.

1. Melden Sie sich am Administration Service als Admin an.

2. Im Menü finden Sie unter Manage Workspace den Eintrag Manage Schema Assignment.

Abbildung 9: Manage Schema Assignment

3. Über Add Schema können Sie nun über einen Wizzard weitere Schemas anlegen.

Hinweis: APEX bietet hier zwei Möglichkeiten. Sie können ein vorhandenes Schema hinzufügen oder ein Neues anlegen. Diese Zweite Version lief in der von mir verwendeten Version auf einen Fehler. Um das Problem zu umgehen, legen Sie also einen User von Hand (z.B. über sqlplus) an und ordnen Sie diesen hier zu.

4. Melden Sie sich wieder als Entwickler an Ihrem Workspace an.

5. Exportieren Sie die Anwendung, die Sie in einem neuen Schema als neues Build/Release anlegen möchten.

6. Importieren Sie die Anwendung und wählen Sie im Import-Wizzard das neue Schema aus.

Abbildung 10: Schema zuordnen

7. Klicken Sie auf Next >.

8. In diesem Schritt wählen Sie die Option “Install Supporting Objects” = YES.

Abbildung 11: Install Supported Objects

9. Setzen Sie die Installation fort und folgen Sie dem Wizzard. Dabei werden nun die DDL-Skripte, welche Sie in den Supporting Objects hinterlegt haben, ausgeführt und somit die benötigten Datenbankobjekte in dem neuen Schema erzeugt.

Beitragsreihe

[catlist name=”APEX SCM (Reihe)”]

Veröffentlicht am

Oracle-Datenbank: Teamwork mit Bordmitteln

Synchronisieren Sie mit DDL-Triggern gemeinsames Arbeiten durch Ein -und Ausschenken von Objekten. Und das sogar für beliebige Datenbanktools.

Viele namhafte Tools zur Datenbankentwicklung bieten Funktionen zur Unterstützung von Entwicklerteams. So können Sie Datenbankobjekte zur Bearbeitung ausschenken. Andere Entwickler, können solange keine Änderungen an diesem Objekt mehr vornehmen, bis dieses wieder eingecheckt wurde. Leider funktioniert das meist nicht werkzeugübergreifend, da diese Tools oft eigene Tabellen für die Verwaltung der Bearbeitungszustände der Datenbankobjekte nutzen.

In diesen Beitrag möchte ich Ihnen eine einfache, aber effektive Möglichkeit zeigen, wie Sie so eine Funktion mit Bordmitteln der Oracle Datenbank selber entwickeln können. Vor allem ist bei der vorgestellten Lösung beachtenswert, dass Sie werkzeugübergreifend funktioniert.

Datenmodell

Benötigt werden zwei Tabellen. Über die Tabelle ddl_object_state wird der Bearbeitungsstand der Datenbankobjekte verwaltet. Sobald ein Entwickler ein Objekt bearbeiten möchten, blockt er dieses. Dabei wird ein Datensatz in dieser Tabelle eingefügt. Ist die Bearbeitung abgeschlossen, so wird das Objekt wieder freigegeben und der zugehörige Einträge entfernt.


CREATE TABLE ddl_object_state (
          object_type VARCHAR2(50 BYTE),
          object_owner VARCHAR2(32 BYTE),
          object_name VARCHAR2(32 BYTE), 
          changed_on DATE,
          changed_by VARCHAR2(32 BYTE)
)
/

Listing 1: Tabelle ddl_object_state

In der zweiten Tabelle ddl_object_state_hist wird beim Ein- und Auschecken neben den Statusinformationen auch ein DDL-Extrakt des bearbeiteten Objektes eingetragen. So dass Sie auf einen Stand zu Beginn und zum Ende der Bearbeitung zurückgreifen können.


CREATE TABLE ddl_object_state_hist
(
   object_type VARCHAR2 (50 BYTE),
   object_owner VARCHAR2 (32 BYTE),
   object_name VARCHAR2 (32 BYTE),
   status_code VARCHAR2 (20 BYTE),
   changed_on DATE,
   changed_by VARCHAR2 (32 BYTE),
   ddl_sql CLOB
)
/

Listing 2: Tabelle ddl_object_state_hist

PL/SQL Package ddl_util

Das PL/SQL Package fasst die benötigten Prozeduren zusammen.

PROCEDURE lock_object (
     p_object_type VARCHAR2,
     p_owner VARCHAR2,
     p_name VARCHAR2,
     p_trace_hist BOOLEAN DEFAULT true
  ) IS
    l_c NUMBER;
    l_locked_by VARCHAR2(32);
    l_changed_on DATE;
    l_ddl_extract CLOB;
BEGIN
    SELECT
      COUNT(*)
     INTO l_c
    FROM ddl_object_state
    WHERE object_owner = p_owner
       AND object_name = p_name;

  IF l_c = 0 THEN
       INSERT INTO ddl_object_state (
          object_type,
          object_owner,
          object_name,
          changed_on,
          changed_by )
       SELECT
          p_object_type,
          p_owner object_owner,
          p_name object_name,
          SYSDATE changed_on,
          ora_login_user changed_by
       FROM dual;

    IF p_trace_hist THEN
       l_ddl_extract := dbms_metadata.get_ddl(p_object_type,p_name);

       INSERT INTO ddl_object_state_hist (
          object_type,
          object_owner,
          object_name,
          ddl_sql,
          status_code,
          changed_on,
          changed_by )
       SELECT
          p_object_type,
          p_owner object_owner,
          p_name object_name,
          l_ddl_extract,
          'LOCK',
          SYSDATE changed_on,
          ora_login_user changed_by
       FROM dual;
    END IF;
 ELSE
      SELECT
          changed_by,
          changed_on
      INTO
        l_locked_by,
        l_changed_on
      FROM ddl_object_state
      WHERE object_owner = p_owner
        AND object_name = p_name;

     IF l_locked_by &lt;&gt; ora_login_user THEN
        raise_application_error(-20001,'Object was already locked by '
             || l_locked_by
             || ' at '
             || TO_CHAR(l_changed_on,'dd.mm.yyyy HH24:Mi:ss') );
     END IF;
 END IF;

END;

Listing 3: Procedure lock_object

Die Prozedur lock_object erhält als Parameter beim Aufruf den Objekttyp, den Besitzer des Objektes und den Namen des Objektes.

Als erstes prüft die Prozedur, ob das Objekt bereits von einem anderen User ausgescheckt wurde. Ist das der Fall wird ein application_error -20001 ausgelöst. Wenn das Objekt nicht in Bearbeitung ist, trägt die Prozedur diese in der Tabelle ddl_object_state ein und extrahiert eine DDL-Anweisung des Objektes. Diese wird dann in der Tabelle ddl_object_state archiviert.

PROCEDURE unlock_object (
     p_object_type VARCHAR2,
     p_owner VARCHAR2,
     p_name VARCHAR2,
     p_trace_hist BOOLEAN DEFAULT true,
     p_secure_mode BOOLEAN DEFAULT true) 
IS
     l_c NUMBER;
     l_locked_by VARCHAR2(32);
     l_changed_on DATE;
     l_ddl_extract CLOB;
BEGIN
     SELECT COUNT(*)
       INTO l_c
     FROM ddl_object_state
     WHERE object_owner = p_owner
       AND object_name = p_name;

 IF l_c = 1 THEN
     SELECT
       changed_by,
       changed_on
     INTO
       l_locked_by,
       l_changed_on
     FROM ddl_object_state
     WHERE object_owner = p_owner
       AND object_name = p_name;

    IF p_secure_mode AND l_locked_by &lt;&gt; ora_login_user  THEN
        raise_application_error(-20002,'You have no permissions in secure mode to unlock the object. The Object was locked by '
              || l_locked_by
              || ' at '
              || TO_CHAR(l_changed_on,'dd.mm.yyyy HH24:Mi:ss') );
    END IF;

    DELETE ddl_object_state
      WHERE object_owner = p_owner
        AND object_name = p_name;

    IF p_trace_hist THEN
      l_ddl_extract := dbms_metadata.get_ddl(p_object_type,p_name);

      INSERT INTO ddl_object_state_hist (
            object_type,
            object_owner,
            object_name,
            ddl_sql,
            status_code,
            changed_on,
            changed_by )
      SELECT
            p_object_type,
            p_owner object_owner,
            p_name object_name,
            l_ddl_extract,
            'UNLOCK',
            SYSDATE changed_on,
            ora_login_user changed_by
      FROM dual;
   END IF;
 
 END IF;

END;

Listing 4: Procedure unlock_object

Um ein Datenbankobjekt nach der Bearbeitung wieder frei zu geben, nutzen Sie die Prozedur unlock_object. Diese prüft im Secure Mode, ob Sie im Vorfeld das entsprechende Objekt auch selber ausgelockt haben. Ist das nicht der Fall, wird der Applikationsfehler -20002 ausgelöst. Ein von Ihnen ausgelocktes Objekt wird durch das Löschen des zugehörigen Eintrags in der Tabelle ddl_object_state wieder zur Bearbeitung frei gegeben. In der Tabelle ddl_object_state_hist wird wieder ein DDL-Extrakt gespeichert.

Objekte, die von einem anderen Entwickler als Sie selbst geblockt wurden, können Sie durch das Setzen des Parameters p_secure_mode = false wieder freigegeben. Auch dabei wird ein Historiendatensatz erzeugt. Anschließend können Sie so den Besitz durch Aufrufen von lock_object übernehmen.

PROCEDURE check_object_state (
             p_object_type VARCHAR2,
             p_owner VARCHAR2,
             p_name VARCHAR2
           );

Listing 5: Procedure check_object_state

Mit der dritten Procedur check_object_state können Sie einfach den Bearbeitungsstand eine Datenbankobjektes überprüfen.

Wie bereits erwähnt, speichern die Prozeduren beim Ein- und Auschecken jeweils ein DDL-Statements in der Historientabelle. Wenn Sie eine genaue Protokollierung aller Anpassungen benötigen, möchte ich Sie auf den Artikel Oracle Datenbankentwicklung: DDL-Trigger zur Auditierung von Strukturänderungen hinweisen.

DDL-Trigger

Anschließend benötigen Sie noch zwei DDL-Trigger, die Sie in dem Entwicklungsschema anlegen müssen.


CREATE OR REPLACE TRIGGER trg_ddl_util_before 
     BEFORE ALTER OR DROP 
    ON DATABASE 
DECLARE 
BEGIN
      IF ora_dict_obj_name NOT IN (
               'TRG_DDL_UTIL_BEFORE',
               'TRG_DDL_UTIL_AFTER',
               'DDL_UTIL' ) 
          AND ora_login_user NOT IN (
               'SYS',
               'SYSTEM' ) 
      THEN
         ddl_util.lock_object(ora_dict_obj_type,ora_dict_obj_owner,ora_dict_obj_name);
      END IF;
END;
/

Listing 6: Trigger trg_ddl_util_before

Der Trigger trg_ddl_util_before wird bei ALTER- und DROP-Anweisungen ausgeführt. Für einen Create-Befehl macht dieser Zeitpunkt keinen Sinn, da das Objekt in der Datenbank noch nicht vorliegen kann.

Bei der Verwendung von DDL-Triggern sollten Sie besondere Vorsicht walten lassen. Da diese Trigger auch bei Änderungen an sich selbst gefeuert werden, kann es vorkommen, dass man bei einer fehlerhaften Programmierung evtl. keine Änderungen mehr an den Triggern vornehmen kann. Aus diesem Grund prüft der Trigger zu Beginn, ob Änderungen an ihm selbst bzw. an dem Trigger trg_ddl_util_after ausgeführt werden sollen. Des Weiteren werden die Accounts das und system von der Verarbeitung ausgenommen. Allerdings würde auch ein invaliden Package ddl_util zu Problemen führen können.

Die eigentlich Logik des Triggers besteht dann nur noch im Aufruf der Prozedur ddl_util.lock_object. Diese prüft, ob das Objekt von einem anderen Entwickler zur Bearbeitung ausgescheckt wurde. In diesem Fall wird wie bereits erwähnt eine Exception gefeuert und so die Änderungen an dem Objekt dem aktuellen Nutzer verwährt. Bei Objekten, die noch nicht ausgescheckt sind, wird das über diesen Trigger automatisch erledigt.

Alternativ kann es aber auch durchaus sinnvoll sein, dass Ausschecken eines Objektes vor der Bearbeitung manuell durch das Aufrufen von  ddl_util.lock_object durchzuführen. So erspart man sich, dass Änderungen beim Speichern durch den Trigger erst im Nachhinein verworfen werden.

CREATE OR REPLACE TRIGGER trg_ddl_util_after 
    AFTER CREATE OR DROP 
 ON DATABASE 
DECLARE 
BEGIN
    IF ora_dict_obj_name NOT IN (
              'TRG_DDL_UTIL_BEFORE',
              'TRG_DDL_UTIL_AFTER',
              'DDL_UTIL')
    AND ora_login_user NOT IN (
              'SYS',
              'SYSTEM' )
    THEN
        IF ora_sysevent = 'CREATE' THEN
            ddl_util.lock_object(ora_dict_obj_type,ora_dict_obj_owner,ora_dict_obj_name);
       END IF;

       IF ora_sysevent = 'DROP' THEN
           ddl_util.unlock_object(ora_dict_obj_type,ora_dict_obj_owner,ora_dict_obj_name,false,true);
       END IF;

    END IF;
END;
/

Listing 7: Trigger trg_ddl_util_after

Wird nun ein neues Objekt angelegt, kann dieses nicht im Vorfeld geblockt werden. In so einem Fall kommt nun der zweite Trigger trg_ddl_util_after ins Spiel. Dieser prüft ob ein Create-Statement ausgeführt wurde. Wenn das der Fall war, wird das neu erstellte Datenbankobjekt automatisch ausgecheckt und der DDL-Extrakt archiviert.

Bei einem Drop-Befehl verhält es sich etwas anders. Hier existiert das Objekt zum Ausführungszeitpunkt ( AFTER ) des Triggers nicht mehr. Es muss aber noch aus der Tabelle ddl_objet_state entfernt werden.

Abbildung 1: Übersicht ddl_util

In Abbildung 1 sehen Sie alle beschriebenen Objekte.

Drop …

Jetzt habe ich der Einfachheit halber Ihnen noch ein kurzes Skript hier eingefügt, mit dem Sie die Tabellen, Trigger und das Package wieder los werden können.


DROP TRIGGER trg_ddl_util_before;
DROP TRIGGER trg_ddl_util_after;
DROP PACKAGE ddl_util;
DROP TABLE ddl_object_state;
DROP TABLE ddl_object_state_hist;

Beispiel

Im Folgenden möchte ich Ihnen die Nutzung der beschrieben Methode anhand einiger kleiner Beispiele demonstrieren. Dazu wurden in dem Schema MY_PROJECTS die beiden Tabellen, das Package und die beiden Trigger angelegt. diesen Account wurde eine Verbindung im SQL Developer hergestellt.

Dann gibt es einen weiteren Account namens DEVELOPER1, welcher mit DBA-Rechten versehen wurde. Der DEVELOPER1  ist via. sqlplus mit der Datenbank verbunden.

Tabelle T1 anlegen

Zu Beginn soll eine Tabelle erzeugt werden.

Abbildung 2: Tabelle T1 anlegen

Wie Sie der Abbildung 2 entnehmen können, wurde die Tabelle T1 ohne Probleme erzeugt. Dabei wurde der Trigger trg_ddl_util_after ausgeführt und ein Lock-Eintrag in der Tabelle ddl_object_state eingefügt.

Abbildung 3: Datenbanktabelle T1 für ausgecheckt

Tabelle T2 erweitern

Jetzt soll der DEVELOPER1 dieser Tabelle eine neue Spalte hinzufügen.

Abbildung 4 : Spalte in T1 ergänzen

Wie zu erwarten war, wird dieser Vorgang mit der Exception ORA-20001 durch den Trigger trg_ddl_util_before unterbunden. Der Meldung können Sie entnehmen, dass die Tabelle durch den User MY_PROJECTS am 17.06.2018 um 20:59:17 gesperrt wurde.

Abbildung 5: Objekt einchecken

Erst wenn der Benutzer MY_PROJECTS die Tabelle wieder zur Bearbeitung frei gibt, kann der DEVELOPER1 die Spalte ergänzen.

Abbildung 6: Spalte hinzufügen

Dies hat wiederum zu Folge, dass die Tabelle jetzt durch den User DEVELOPER1 ausgecheckt wurde.

Tabelle T1 löschen

Setzt nun der User MY_PROJECTS eine Drop Anweisung für die Tabelle T1 ab, wird auch diese mit einer entsprechenden Fehlermeldung abgebrochen.

Abbildung 7: Drop der Tabelle nicht möglich

Möchten Sie jetzt aber die Tabelle trotzdem löschen und die Sperre durch den DEVELOPER1 übergehen, so können Sie das durch den Aufruf der Prozedur unlock_objects mit folgenden Parametern tun.


BEGIN
  DDL_UTIL.UNLOCK_OBJECT(
         P_OBJECT_TYPE = 'TABLE',
         P_OWNER =       'MY_PROJECTS',
         P_NAME =        'T1',
         P_TRACE_HIST =  true,
         P_SECURE_MODE = false
        );
   commit;
END;

Änderungshistorie

Die Trigger bzw. das PL/SQL Package ddl_util sorgen beim Ein- und Auschecken der Datenbankobjekte auch dafür, dass ein DDL-Extrakt in der Tabelle ddl_object_state_hist archiviert wird. So können Sie auf einfache Weise auf ältere Entwicklungsstände zugreifen.

Abbildung 8: Änderungshistorie

Download

Abschließend habe ich Ihnen ein DDL-Script zum Anlegen der beschriebenen Objekte an diesen Beitrag angefügt. Die Verwendung erfolgt aber auf eigene Gefahr.

Oracle-Datenbank: Teamwork mit Bordmitteln Download ddl_util.sql

Dieses DDL-Sript ist im Rahmen des Beitrags Oracle-Datenbank: Teamwork mit Boardmitteln entstanden.

Jetzt herunterladen!
Veröffentlicht am

Oracle Datenbankentwicklung: DDL-Trigger zur Auditierung von Strukturänderungen

Oracle bietet mit sogenannten DDL-Triggern eine einfache Möglichkeit Änderungen an Datenbankobjekten zu protokollieren. Eine nützliche Methode für Entwicklerteams.

Eine automatische Auditierung von DDL (Data Definition Language) -Aktionen in einem Datenbank-Schema ist in vielerlei Situationen nützlich. Z.B. können Sie auf diese Weise in einer Entwicklungsumgebung alle Strukturänderungen, die nach einem bestimmten Zeitpunkt erfolgt sind, nachvollziehen. Auf Basis so eines Protokolls sind Sie dann beispielsweise in der Lage ein Upgrade-Skript zu erstellen, mit dem Sie anschließend das produktive System aktualisieren können. Auch aus Sicherheitsgründen kann es sinnvoll sein, strukturelle Änderungen an einer Datenbank zu protokollieren.

Das Thema der DDL- oder auch Systemtrigger ist umpfangreich, soll hier aber nicht in Gänze betrachtet werden. In diesem Beitrag geht es um die Entwicklung  eines Auditierungsmechanismusses, der alle Änderungen an einem Schema protokolliert. Das sind vor allem create, alter, drop Befehle.

Eine Oracle-Datenbank bietet verschiedene Möglichkeiten der Auditierung. Die hier vorgestellte Variante ist aber recht leichtgewichtig und bietet durch ihre Anpassbarkeit viele Gestaltungsmöglichkeiten. So können Sie beispielsweise auch eine DSGVO angepasste, datensparsame  Variante erstellen.

Die dargestellten Beispiele sind mit viel Sorgfalt entstanden, allerdings übernehme ich keine Gewähr für etwaige Fehler oder Probleme, die bei der Nutzung auftreten. Bitte prüfen Sie selber die Beispiele vor der Nutzung.

Datenmodell

Das Datenmodell für dieses Szenario besteht aus zwei Tabellen.

Die Tabelle ddl_log nimmt für jede Änderung der Datenbankobjekte deren Name und Besitzer, den Typ des Objektes, den Zeitpunkt der Änderung und die Art der Änderung auf. Auch die Benutzerdaten sowie das Programm, mit dem die Änderung durchgeführt wurde, werden vermerkt. Zur Erzeugung eines künstlicher Schlüssel wird später eine Sequence verwendet.

Die zweite Tabelle ddl_log_sql ergänzt diese Information um das eigentliche DDL-Statement, welches  ausgeführt wurde.

CREATE TABLE ddl_log
(
  event_id NUMBER (10, 0),
  event_date DATE,
  user_id VARCHAR2 (30 BYTE),
  object_name VARCHAR2 (30 BYTE),
  owner VARCHAR2 (30 BYTE),
  object_type VARCHAR2 (30 BYTE),
  system_event VARCHAR2 (30 BYTE),
  machine VARCHAR2 (64 BYTE),
  program VARCHAR2 (64 BYTE)
)
/

CREATE TABLE ddl_log_sql
(
  event_id NUMBER (10, 0),
  sqlline NUMBER (10, 0),
  sqltext VARCHAR2 (4000 BYTE)
)
/

CREATE SEQUENCE ddl_log_id INCREMENT BY 1
  START WITH 1
  MINVALUE 1
  MAXVALUE 9999999999999999999999999999
  NOCYCLE
  ORDER
  CACHE 20
/

Listing 1: Datenmodell anlegen

Mit Listing 1 können Sie die beschriebenen Objekte anlegen. Dies sollten Sie in dem Schema tun, in dem Sie die Änderungen protokollieren möchten. Alternativ können Sie aber auch ein eigenes Schema dafür definieren. Allerdings müssen Sie dann den Schema-Namen im Quellcode des Triggers ergänzen und denn Tabellen sowie der Sequence voranstellen.

DDL-Trigger

Ein DDL-Trigger wird anders als ein DML-Trigger bei DDL- bzw. Systemereignissen ausgeführt. Das können z.B. Strukturänderungen wie das Erstellen einer Tabelle oder eines PL/SQL Packages, das Droppen einer Tabelle oder das Anlegen einer View aber auch das Anmelden eines Benutzers sein.

Der Ausführungspunkt so eines Triggers kann vor (BEFORE) oder nach (AFTER) der Abarbeitung des DDL-Statements festgelegt werden.

Sie können einen DDL-Trigger global für die komplette Datenbank (DATABASE) oder nur für ein bestimmtes SCHEMA definieren.

Einen DDL-Trigger, der alle Strukturellen Änderungen an Ihrem Schema protokolliert, können Sie – wie in Listing 2 gezeigt – erzeugen. Führen Sie dazu das Skript mit einem Datenbanktool (sqlplus, SQL Developer, APEX SQL Workshop,…) aus. Melden Sie sich dabei mit dem SCHEMA Account an.

Tauschen Sie das keyword SCHEMA durch DATABASE, so wird der Trigger bei allen Änderungen an der gesamten Datenbank gefeuert. Aber Achtung, Sie müssen dafür dann das Schema, in denen sich die verwendeten Tabellen befinden, in dem Trigger hinzufügen.


CREATE OR REPLACE TRIGGER trg_ddl_log
 AFTER DDL
 ON SCHEMA
DECLARE
  l_sql ora_name_list_t;
  l_id NUMBER (10, 0);
BEGIN
  SELECT ddl_log_id.NEXTVAL INTO l_id FROM DUAL;

  INSERT INTO ddl_log (event_id,
    event_date,
    user_id,
    object_name,
    owner,
    object_type,
    system_event,
    machine,
    program)
  (SELECT l_id,
          SYSDATE,
          ora_login_user,
          ora_dict_obj_name,
          ora_dict_obj_owner,
          ora_dict_obj_type,
          ora_sysevent,
          UPPER (SYS_CONTEXT ('USERENV', 'TERMINAL')),
          SYS_CONTEXT ('USERENV', 'MODULE')
       FROM DUAL);

FOR l IN 1 .. ora_sql_txt (l_sql)
  LOOP
    INSERT INTO ddl_log_sql (event_id, sqlline, sqltext)
      VALUES (l_id, l, l_sql (l));
  END LOOP;
END;
/

Listing 2: Create DDL-Audit-Trigger

Der Trigger wird nach allen Änderungen, die an Objekten des jeweiligen Schemas ausgeführt werden, gefeuert.

Zu Begin des Triggers wird mit Hilfe der Sequence ddl_log_id ein künstlicher Schlüssel erzeugt und in der Variable l_id gespeichert.

Das erste Insert-Statement protokolliert die Art der Änderung in der Tabelle ddl_log. Dabei wird dem Datensatz die zuerst erzeugte ID aus der Variablen l_id als Primärschlüssel zugeordnet. Hier werden neben dem Zeitpunkt der Änderung und das geänderte Datenbankobjekt, auch die Benutzerdaten und das verwendete Programm ermittelt und gespeichert.

Im nächsten Schritt wird das DDL-Statement, welches zur Ausführung des Triggers geführt hat, zeilenweise in der Tabelle ddl_log_sql eingefügt. Jeder Zeile wird neben einer Nummerierung auch die l_id als Fremdschlüssel zugeordnet.

Sollten Sie auf die persohnenpersonen Daten – wie den Benutzername und den Maschinennamen des Clients – verzichten wollen, können Sie den Trigger in einer DSGVO freundlicheren Version mit dem Listing 3 anlegen. Dabei werden diese beiden Spalten einfach mit null vorbelegt.


CREATE OR REPLACE TRIGGER trg_ddl_log
 AFTER DDL
 ON SCHEMA
DECLARE
  l_sql ora_name_list_t;
  l_id NUMBER (10, 0);
BEGIN
  SELECT ddl_log_id.NEXTVAL INTO l_id FROM DUAL;

  INSERT INTO ddl_log (event_id,
    event_date,
    user_id,
    object_name,
    owner,
    object_type,
    system_event,
    machine,
    program)
  (SELECT l_id,
          SYSDATE,
          null,
          ora_dict_obj_name,
          ora_dict_obj_owner,
          ora_dict_obj_type,
          ora_sysevent,
          null,
          SYS_CONTEXT ('USERENV', 'MODULE')
       FROM DUAL);

FOR l IN 1 .. ora_sql_txt (l_sql)
  LOOP
    INSERT INTO ddl_log_sql (event_id, sqlline, sqltext)
      VALUES (l_id, l, l_sql (l));
  END LOOP;
END;
/

Listing 3: DSGVO freundlicherer DDL-Audit-Trigger

Möchten Sie den Trigger inklusive der zugehörigen Datenbankobjekte aus Ihrem Schema entfernen, können Sie dafür das Listing 4 nutzen. Wichtig dabei ist die vorgegebene Ausführungsreihenfolge. Würden Sie die Tabellen zuerst zu droppen, so würden Sie dem DDL-Trigger seine abhängigen Objekte entziehen. Anschließend würde der Trigger invalid und zu einem Fehler führen.


DROP TRIGGER trg_ddl_log;
DROP TABLE ddl_log;
DROP TABLE ddl_log_sql;
DROP SEQUENCE ddl_log_id;

Listing 4: Trigger und Tabellen löschen

Generell sollten Sie bei der Verwendung von DDL-Triggern etwas Vorsicht walten lassen, da Sie bei fehlerhafter Verwendung, sich quasi bestimmter Datenbank-Funktionalitäten entledigen könnten.

Anwendungsbeispiele

Ich habe in dem Beitrag Oracle Application Express – Quick SQL bespielhaft ein einfaches Datenmodell für eine Projektverwaltung erstellt. Das zugehörige DDL-Skript habe ich exemplarisch ausgeführt und mit Hilfe des DDL-Audit-Triggers aus Listing 3 protokollieren lassen.

Im Folgenden finden Sie einige einfachen select-Anweisungen, mit deren Hilfe Sie verschiedene Fragestellungen beantworten können.

Wie Sie der Abbildung 1 entnehmen können, wurden folgende Änderungen an der Datenbank vorgenommen.

Abbildung 1: DDL-Log Änderungshistorie

Wenn Sie sich dieses Log ansehen möchten, genügt folgende select-Statement Anweisung:


select event_id,
       event_date,
       user_id,
       object_name,
       owner,
       object_type,
       system_event,
       machine,
       program
 from ddl_log
  order by event_id

Listing 5: Änderungshistorie anzeigen

Das konkrete DDL-Statement, dass für Anlegen der Tabelle projects verantwortlich war,  wurde in der Tabelle ddl_log_sql protokolliert. Eine kleine Unschönheit bringt dieses Protokoll mit sich. Bitte achten Sie darauf, dass die zeilenweise Speicherung teilweise mitten in einer SQL-Anweisung die Zeile umbricht. Dies muss bei der Rekonstruktion des Skriptes beseitigt werden.

Abbildung 2: DDL-Statement

Dieses läßt sich für einen einzelnen Schritt – wie in Listing 6 gezeigt – ermitteln.


select event_id, 
       event_date, 
       object_type,
       sqltext
from ddl_log_sql 
  where event_id = 2
 order by sqlline

Listing 6: DDL-Anweisungen für event_id =2 ermitteln

Interessieren Sie sich für die Änderungen,  die zwischen zwei Releaseständen Ihres Datenbank-Schemas  durchgeführt wurden, können Sie die select-Anweisungen um folgende where Klausel ergänzen. Alternativ können Sie auch die Einschränkungen über den Zeitstempel vornehmen.


select l.event_id, 
       event_date, 
       object_type,
       sqltext
from ddl_log l, 
     ddl_log_sql s
where l.event_id = s.event_id
  and l.event_id > 2 and l.event_id < 10
order by l.event_id, 
         sqlline

Listing 7: Alle DDL-Anweisungen die nach event_id 2 bis zur event_id 5 ausgeführt wurden

Auf Basis so eines Protokolls, können Sie anschließend ein Upgrade-Skript erarbeiten oder die Release-Notes für die neue Softwareversion ergänzen.

Auch die Änderungen an einem bestimmten Datenbankobjekt, hier der Tabelle TO_DOS, können nachvollzogen werden. Dazu finden Sie in Listing 8 ein einfaches Beispiel.


select l.event_id , 
       l.object_name, 
       event_date, 
       object_type,  
       sqltext
from ddl_log l, 
     ddl_log_sql s
where l.event_id = s.event_id
  and l.object_name = 'TO_DOS'
order by l.event_id, 
         sqlline

Listing 8: DDL-Statement zum Erstellen der Tabelle TO_DOS ermitteln

So einen DDL-Audit-Trigger ist gerade auch für Entwicklerteams hilfreich. Hier ist für alle Programmierer leicht nachvollziehbar, welche Änderungen an dem Datenmodell durchgeführt wurden. Auch zum prüfen von Installationsvorgängen lässt sich die Protokollierung einsetzen.

Wie Sie meine ScreenShots entnehmen konnten, setzte ich diesen Trigger auch gerne bei der Entwicklung von APEX-Anwendungen ein. Gerade durch die Beschränkung seiner Ausführung auf die Änderungen eines Datenbankschemas können so geziehlt alle Entwicklungsschritte auf Datenbankebene nachvollzogen werden. Auf Basis der Tabelle ddl_log_sql lassen sich dann Scripte für die Supported Objects erstellen.

 

 

 

 

Veröffentlicht am

APEX Application Archive (Teil 1) – Installation und Anwendungen archivieren

Mit der Packaged Application “APEX Application Archive” lassen sich Backups Ihrer Anwendungen erstellen. Mit einigen kleinen Erweiterungen, können Sie diesen Prozess auch automatisieren. Wie Sie diese Anwendung einsetzen und entsprechend erweitern können, können Sie dieser dreiteiligen Artikel-Serie entnehmen.

Bei der Anwendung “APEX Application Archive” handelt es sich, wie auch bei der in diesem Artikel vorgestellten Anwendung QuickSql, um eine sogenannte Packaged Application. Oracle stellt mit den Packaged Applications den Nutzern von APEX einige nützliche Werkzeuge zur Verfügung, die Sie auch produktiv einsetzen können.

Das Programm “APEX Application Archive” dient, wie der Name schon erahnen lässt, der Sicherung und Archivierung von APEX-Anwendungen. Sie können mit diesem Programm Anwendungsarchive erstellen, die eine oder mehrere Programme eines Workspaces enthalten können. Gespeichert werden diese Archive in entsprechenden Tabellen der Datenbank.

Interressant ist diese Anwendung im Entwicklungsprozess. Sie können so eine Versionierung bzw. Archivierung von Zwischenständen durchführen. Natürlich ist das auch manuell über die Exportfunktion des Application Builder zu erreichen. Allerdings müssen Sie sich bei dieser Variante um eine entsprechende Ablagestruktur im Filesystem kümmern.

Leider sieht die Anwendung keine automatische, z.B. zeitlich geplante Archivierung vor. Dieses Manko möchte ich allerdings in einem der nachfolgenden Artikeln durch eine eigene Lösung beheben.

APEX Application Archive installieren

Die Installation einer Packaged Application geht recht einfach von der Hand.

Im Application Builder klicken Sie einfach auf die Schaltfläche “Packaged Application”.

APEX Packaged Application installieren
Abbildung 1: APEX Packaged Application installieren

In der nächsten Seite werden Ihnen alle Packaged Applications der aktuellen APEX-Version (hier 18.1 EA) aufgelistet.

Filtern Sie diese nach den produktiv einsetzbaren Anwendungen, erhalten Sie die folgende Auflistung.

Abbildung 2: Produktiv einsetzbare Packaged Applications

Jetzt müssen Sie die Anwendung APEX Application Archive auswählen und im nächsten Fenster auf Installation klicken. Folgen Sie dann einfach dem Installations-Wizzard und schließen Sie den Vorgang ab.

Abbildung 3: APEX Application Archive installieren

Nach erfolgreicher Installation der Anwendung werden Sie nach der Anmeldung mit Ihrem APEX-Account beim ersten Start noch gebeten einige Parameter festzulegen.

Abbildung 4: Parameter APEX Application Archive

Fertig.

Anwendungen archivieren

Nach der Einrichtung der Anwendung, sehen Sie das Dashboard des “APEX Application Archive” Programms.

 

Abbildung 5: Application Archive Dashboard

Nun können Sie das erste Anwendungsarchiv anlegen. Betätigen Sie einfach die Schaltfläche “Archive Applications”.

Abbildung 6: Anwendung selektieren

In diesem Schritt wählen Sie eine oder mehrere Anwendung aus dem aktuellen Workspace aus.

Klicken Sie auf Next > .

Abbildung 7: Kommentar einfügen

Jetzt noch ein paar hilfreiche Informationen ergänzen und das Archiv mit “Create Archive” erstellen.

Bitte beachten Sie, dass die so erstellten Archive lediglich die selektierten APEX-Anwendungen enthalten. Die zugehörigen Datenbankobjekte wie Tabellen, Views, Packaged,usw. sind nicht enthalten. Um ein möglichst vollständiges Abbild eines Entwicklungs(zwischen)standes einer Applikation zu erhalten, empfehle ich Ihnen, die notwendigen DDL-Skripte in den Supported Objects der APEX-Anwendung zu hinterlegen.

Alternativ können Sie auch ein Dump-file mittels expdp (bzw. exp) erzeugen. Dies bringt allerdings den Nachteil mit sich, dass Sie sich wieder selber um die Versionierung der Dateien kümmern müssen.

Teil 2-Wiederherstellen und Exportieren

Im nächsten Teil dieser Beitragsreihe wird es um das Zurücksichern und Exportieren einer Anwendung gehen.

Wenn es Sie interessiert, wie es weiter geht, bestellen Sie doch den Newsletter von INFORMATIK-TRANSPARENT oder schauen Sie später noch einmal hier vorbei.

Beitragsübersicht

[catlist name=”APEX Application Archive”]

 

 

 

Veröffentlicht am

APEX Application Archive (Teil 2) – Anwendungen wiederherstellen

Im zweiten Teil der Beitragsreihe zur “APEX Application Archive” -Anwendung, geht es um das Wiederherstellen und das Herunterladen der archivierten APEX Anwendungen.

Im ersten Teil der Reihe habe ich Ihnen gezeigt, wie Sie eine oder mehrere Anwendungen mit Hilfe des “APEX Application Archive” in einem Archive sichern können. Die Anwendungen speichert der “APEX Application Archiver” in der Tabelle APEX$ARCHIVE_CONTENTS in einem BLOB.

Um nun eine oder mehrere Anwendungen, die Sie so gesichert haben, wiederherzustellen,  können Sie auf zweierlei Arten vorgehen.

Für beide Varianten ist der Ausgangspunkt der Menüeintrag “Archived Content”. Über diesen gelangen Sie zu einem Interaktiven Grid, welches alle archivierten Applikationen auflistet.

Abbildung 8: Anwendungsarchiv auswählen

Hier können Sie über das Setzen entsprechender Filter die benötigte Version der Anwendung auswählen.

APEX-Anwendung wiederherstellen

Als erste Möglichkeit können Sie eine archivierte Anwendung direkt aus einem Archiv heraus recovern. Dazu sind aber einige Schritte notwendig.

Suchen Sie in der Tabelle “Archived Content” die wiederherzustellen dies  Anwendung. Klicken  Sie auf den  Button “Restore”, so wird Ihnen auf der nächsten Seite des Wizzards eine Zusammenfassung der gewählten Anwendungen präsentiert.

Abbildung 9: Restore Content

Wie in Abbildung 9 dargestellt, starten Sie die Extraktion über “Restore Content”.

Jetzt wird die Exportdatei aus dem Archiv geladen und direkt in Ihrem Workspace in das sogenannte “Export Repository” importiert.

Anschließend bekommen Sie eine Checkliste angezeigt, die Ihnen die nächsten Schritte zur Installation der Anwendung erklärt.

Abbildung 10: Checkliste Installation der Anwendung

Wechseln Sie nun in die APEX-Entwicklungsumgebung und dort in den “Application Builder” des zugehörigen Workspaces. Klicken Sie auf “Utilities”.

Abbildung 11: Export Repository

Wie in Abbildung 11 dargestellt geht es weiter über den Link Export.

Abbildung 12: APEX-Anwendung installieren

Danach betätigen Sie den Link “Export Repository”.

Abbildung 13:Export Repository

Nun öffnet Sie das Export Repository. In dieser Tabelle sehen Sie die zuvor extrahieren Version Ihrer Anwendung(en). Über den Link “Install” starten Sie den Anwendungs Import-Assistenten.

Dieser stellt Ihnen verschiedene Möglichkeiten zur Verfügung. So können Sie die Anwendung parallel zu der aktuellen Anwendung installieren. Der eigentliche Ablauf ist im Abschnitt “Install Database Application” beschrieben.

APEX-Anwendung herunterladen

Bei der zweiten Variante können Sie einfach ein Archiv selektieren und die gewünschten Anwendung als APEX-Exportfile herunterladen. Diese Datei können Sie dann über die Importfunktion des Application-Builders importieren.

Dabei gehen Sie so vor.

Der Ausgangspunkt ist wieder, wie bereits in Abbildung 8 gezeigt, der Menüpunkt “Archived Content”. Dort suchen Sie sich wieder die Anwendungsversion, die Sie herunterladen möchten.

Klicken Sie hier auf “Download”.

Jetzt wird die Anwendung als Exportfile über Ihren Browser heruntergeladen. Diese Datei können Sie nun in einem beliebigen Workspace importieren.

Dazu melden Sie sich an der APEX-Entwicklungsumgebung an und öffnen dort den “Application Builder”.

Im “Application Builder” gelangen Sie über das Icon “Import” zum Import-Wizzard.

Hier können Sie die eben extrahierte Datei auswählen. Den File Type belassen Sie bei “Database Application,…”. Über Next> gelangen Sie zur nächsten Seite des Import-Assistenten.

Wie bereits erwähnt, verläuft die Installation einer Anwendung bei beiden Varianten ab diesem Punkt gleich.

Install Database Application

Im Installations-Wizzards können Sie, wie in der Abbildung 14 gezeigt, festlegen, ob Sie die Anwendung mit der ursprünglichen oder einer neuen App-ID automatisch oder manuell versehen lassen möchten. Je nach Auswahl wird die vorhandene Version der Anwendung überschrieben oder als parallele Version installiert.

Abbildung 14: Import Database Application

Über “Install Application” geht es zum nächsten Schritt. Hier müssen Sie noch die Frage beantworten, ob Sie die “Supported Objects” installieren möchten.

Bei den “Supported Objects” handelt es sich  meist um DDL-Skripte, welche bei der Installation bzw. Update oder auch Deinstallation ausgeführt werden.  Diese “Supported Objects” sind Bestandteil einer Anwendung.

Hier sollten Sie sich im Klaren darüber sein, ob diese SQL- Skripte ausgeführt werden sollen. Im Zweifelsfall können Sie sich diese Skripte über den etwas versteckten Bereich Tasks in dieser Seite anzeigen lassen. Nach dem aufklappen der Tasks klicken Sie dazu einfach auf den Link “Preview Installation Script”. In dem sich nun öffnenden Fenster sind alle Skripte einsehbar.

Jetzt müssen Sie den Wizzard nur noch bis zu Ende folgen und dabei die Installation abschließend bestätigen.

APEX Application Archive (Teil 3) – Automatisieren mit dem dbms_scheduler

Im dritten Teil der Beitragsserie wird es um die automatische Erzeugung von Anwendungsarchiven gehen. Nutzt man darüber hinaus noch die Metadaten des APEX -Repositories, so lässt sich der Vorgang auch noch etwas smarter gestalten.

Beitragsübersicht

[catlist name=”APEX Application Archive”]

 

 

 

 

 

Veröffentlicht am

APEX Application Archive (Teil 3) – Automatisieren mit dem dbms_scheduler

Im dritten Teil der Beitragsserie geht es um die automatische Erzeugung von APEX-Anwendungsarchiven. Nutzt man darüber hinaus noch die Metadaten des APEX-Repositories, so lässt sich der Vorgang auch noch etwas smarter gestalten.

APEX-Anwendungen  sichern via. PL/SQL

Zu Beginn geht es darum herauszufinden, welche PL/SQL Funktion benötigt wird, um eine Anwendungsarchiv zu erzeugen.

Da die Funktion bereits in der Packaged Application “APEX Application Archive” genutzt wird, können Sie sich diese einmal ansehen.

Hierzu begeben Sie sich einfach in die Verwaltung der Packaged Applications.

Öffnen Sie dort die “APEX Application Archive”  und klicken Sie auf den Button “Manage’.

Abbildung 14: Unlock Application

Folgen Sie dem Wizzards und Entsperren Sie die Anwendung.

Jetzt können Sie die Anwendung wie gewohnt über den Application Builder bearbeiten.

Öffnen Sie die Seite 9. Dort finden Sie den Prozess der für die Archivierung der Anwendungen zuständig ist.

Abbildung 15: Archive Application

Der besseren Lesbarkeit wegen, habe ich Ihnen den Quellcode einmal heraus kopiert.

DECLARE
  l_vc_arr2 APEX_APPLICATION_GLOBAL.VC_ARR2;
  l_hdr_id number;
  z integer;
BEGIN
  l_vc_arr2 := APEX_UTIL.STRING_TO_TABLE(ltrim(rtrim(:P10_APPLICATIONS_TO_ARCHIVE,':'),':'));

  l_hdr_id := apex_cloud_archive.create_header(
                  p_workspace_id = :flow_security_group_id,
                  p_version = 1,
                  p_archive_name = :P5_ARCHIVE_NAME,
                  p_comments =:P9_COMMENTS);

  FOR z IN 1..l_vc_arr2.count LOOP
    apex_cloud_archive.archive_applications(
       p_workspace_id = :flow_security_group_id,
       p_header_id = l_hdr_id,
       p_application_id = l_vc_arr2(z));
  END LOOP;
END;

Quellcode 1: Auszug aus Seite 9 der Oracle APEX Anwendung Archive Application

Wie Sie dem Listing entnehmen können, benötigen Sie die Funktion create_header und archive_applications.

Die Funktion create_header legt ein neues Archiv an. Diesem Archiv können Sie nun mit Hilfe der Prozedur archive_applications eine oder mehrere Anwendungen hinzufügen.

Abbildung 16: APEX Views – APEX_APPLICATIONS

Die Parameter, die Sie für den Aufruf der beiden Prozeduren benötigen, liefert die APEX-View APEX_APPLICATIONS.

Um beispielsweise die “Sample Database Application” mit der App-Id 507 zu sichern, können Sie folgenden PL/SQL Block ausführen.

Abbildung 17: Anwendung via. API archivieren

Ein Hinweis am Rande. Oracle schreibt auf https://apex.oracle.com/de/  (Stand 22.05.2018 ) folgendes zum Anpassen von Packaged Applications.

“[..] Application Express bietet eine Sammlung von 35 Geschäfts- und Beispielsanwendungen. Sie können diese Anwendundungen für Produktionszwecke einsetzen oder kopieren, editieren und als Grundlage für Ihre eigenen Anwendungen verwenden.[..]”

Smarte Sicherung durch Nutzung der APEX-Views

Kombiniert  man nun die APEX-View APEX_APPLICATIONS mit den Tabellen der Anwendung “Application Archive” kann man den Prozess noch etwas smarter gestalten. Über das folgende select-Statement ermitteln Sie notwendigen Parameter. Dabei wird allerdings geprüft, ob seit der letzten Archivierung überhaupt Änderungen an der zu sichernden Anwendung durchgeführt wurden.


select WORKSPACE_ID,APPLICATION_ID, APPLICATION_NAME
  from APEX_APPLICATIONS a
  where APPLICATION_ID = 507
    and not exists (
              select 'X'
               from "APEX$ARCHIVE_CONTENTS" "APEX$ARCHIVE_CONTENTS",
                    "APEX$ARCHIVE_HEADER" "APEX$ARCHIVE_HEADER"
               where "APEX$ARCHIVE_HEADER".ID="APEX$ARCHIVE_CONTENTS".HEADER_ID
                 and "APEX$ARCHIVE_HEADER".WORKSPACE_ID = a.WORKSPACE_ID
                 and "APEX$ARCHIVE_CONTENTS".APP_ID = a.APPLICATION_ID
                 and "APEX$ARCHIVE_HEADER".CREATED > a.last_updated_on)

Quellcode 2: Änderungen berücksichtigen

Jetzt können Sie diese Erkenntnisse in Form einer Prozedur in der Datenbank speichern.


create or replace procedure back_app
(p_app_id number)
is
  l_hdr_id number;
  l_workspace_id number;
  l_archive_name varchar2(200);
BEGIN

for c in (select WORKSPACE_ID, APPLICATION_NAME
           from APEX_APPLICATIONS a
          where APPLICATION_ID = p_app_id
            and not exists (
                 select 'X'
                  from "APEX$ARCHIVE_CONTENTS" "APEX$ARCHIVE_CONTENTS",
                       "APEX$ARCHIVE_HEADER" "APEX$ARCHIVE_HEADER"
                   where "APEX$ARCHIVE_HEADER".ID = "APEX$ARCHIVE_CONTENTS".HEADER_ID
                     and "APEX$ARCHIVE_HEADER".WORKSPACE_ID = a.WORKSPACE_ID
                     and "APEX$ARCHIVE_CONTENTS".APP_ID = a.APPLICATION_ID
                     and "APEX$ARCHIVE_HEADER".CREATED > a.last_updated_on))
loop
  l_workspace_id := c.WORKSPACE_ID;
  l_archive_name := c.APPLICATION_NAME;

  l_hdr_id := apex_cloud_archive.create_header(
               p_workspace_id => l_workspace_id ,
               p_version => 1,
               p_archive_name => l_archive_name || to_char(sysdate,'dd.mm.yyyy'),
               p_comments => '' );

apex_cloud_archive.archive_applications(
               p_workspace_id => l_workspace_id ,
               p_header_id => l_hdr_id,
               p_application_id => p_app_id );
end loop;

END;

Quellcode 3: Prozeduren back_app

Um nun eine Anwendung zu archivieren genügt folgender Aufruf.

BEGIN
  back_app(507);
END

Quellcode 4: Anwendung archivieren

Sicherungen Automatisieren  mit dem dbms_scheduler

Gerade im Rahmen der Entwicklung einer Anwendung ist es oft nützlich, auf ältere Versionen einer Anwendung zurückgreifen zu können. Um das Archivieren nicht immer manuell anstoßen zu müssen, können Sie die eben konzipierte Prozedur back_app über einen Scheduler ausführen. Am einfachsten geht das über das Package dbms_schedule.


BEGIN
  DBMS_SCHEDULER.CREATE_JOB (
     job_name => 'my_backup_job1',
     job_type => 'PLSQL_BLOCK',
     job_action => 'BEGIN back_app(507); END;',
     start_date => sysdate,
     repeat_interval => 'FREQ=DAILY; BYHOUR=10,15,20;',
     end_date => sysdate + 1,
     enabled => TRUE,
     comments => 'sample app');
END;
/

Quellcode 5: Regelmäßige Sicherung

In diesem Beispiel wird die Anwendung 507 jeden Tag um 10:00, 15:00 und 20:00 immer dann gesichert, wenn die Anwendung seit der letzten Archivierung geändert wurde.

Um nun eine Anwendung wieder herzustellen, gehen Sie wie in Teil 2 dieser Reihe beschrieben vor.

Beitragsübersicht

[catlist name=”APEX Application Archive”]