Logo Oracle Deutschland   Application Express Community

[Show in English]

Versionierung und Simulationen für Tabellendaten:
Oracle Workspace Manager und Application Express
Erscheinungsmonat APEX-Version Datenbankversion Cloud oder on Premise
Dezember 2016 alle alle on Premise und Cloud

Einführung: Oracle Workspace Manager

Nicht selten besteht in einer Geschäftsanwendung der Bedarf, mit Daten zu "spielen", Änderungen zu simulieren und verschiedene Versionen eines Datenbestandes zu verwalten. Solche Simulationen sind quasi eine "langlaufende Transaktion" - Änderungen (eine Simulation) werden zu einem späteren Zeitpunkt komplett angewendet oder zurückgerollt. Für kurze Transaktionszeiträume ist dieses Problem seit langem gelöst - die Oracle Datenbank beherrscht Transaktionen, die nötige Isolation, sowie COMMIT und ROLLBACK seit den frühen Anfängen.

Die genannten, langlaufenden Transaktionenen haben jedoch einen anderen Charakter: Sie erstrecken sich über viele Datenbanksitzungen, gegebenenfalls mehrere Anwendungen und auch viele Nutzer. Mit Datenbanktransaktionen kommt man hier nicht weit, denn diese sind auf jeden Fall durch die Datenbanksitzung begrenzt. Man muss diese fachlichen Transaktionen separat abbilden. Die dazu nötige Anwendungslogik kann allerdings sehr komplex und fehlerträchtig werden.

Zeit Langlaufende Transaktion "(Simulation)" COMMIT / ROLLBACK (als Ganzes) COMMIT COMMIT Datenbanksitzung 1 Datenbanksitzung 2 COMMIT Datenbanksitzung 2 COMMIT

Langlaufende Transaktionen und Datenbank-Transaktionen

Nur wenigen ist die Tatsache bekannt, dass die Oracle-Datenbank eine Komponente enthält, mit der sich solche Anforderungen umsetzen lassen: Oracle Workspace Manager. Das ist nicht zu verwechseln mit den Workspaces in Application Express. Ein Workspace des Oracle Workspace Manager ist der Rahmen für eine "langlaufende" Transaktion - damit wird es möglich ...

Wenn eine oder mehrere Tabellen für den Workspace Manager aktiviert wurde, werden die Workspaces (und damit die langlaufenden Transaktionen) hierarchisch organisiert. Die Wurzel ist der Workspace LIVE; der ist bereits aus dem Stand enthalten. Jede Datenbanksession befindet sich zunächst im Workspace LIVE. Richtet man keine weiteren Workspaces ein, so ist das Verhalten genauso, als wenn der Workspace Manager abgeschaltet wäre.

Neue Workspaces werden zunächst als Child-Workspaces des Workspace LIVE erstellt. Jeder Workspace kann wiederum Child-Workspaces enthalten, so dass sich eine Hierarchie ergibt. Der Einfachheit halber belassen wir es in diesem Community Tipp aber bei nur einer Hierarchieebene.

PLAN_1 child of LIVE PLAN_2 child of LIVE Workspace "LIVE" Workspace "PLAN 1" Workspace "PLAN 2"

Abbildung 1: Zwei Workspaces werden auf erster Ebene (unterhalb von "LIVE") eingerichtet

Eine Datenbanksitzung kann nun in einen der Workspaces wechseln und die Tabellendaten mit SQL Kommandos ändern. Diese Änderungen sind nur in dem Workspace sichtbar, in dem sie gemacht wurden - im Workspace LIVE oder dem anderen Workspace sind sie nicht sichtbar. Das ist völlig unabhängig von der technischen Transaktion in der Datenbank. Auch wenn ein COMMIT abgesetzt wurde, bleibt die Änderung nur im Workspace selbst sichtbar.

Am Ende der Transaktion steht die Entscheidung, ob die Änderungen (als Ganzes) akzeptiert oder verworfen werden. Werden die Änderungen verworfen, so findet ein "Rollback" für den Workspace statt; alle Änderungen werden rückgängig gemacht; auch wenn sie schon Tage oder Wochen alt sind. Werden die Änderungen akzeptiert, so findet eine "Merge" Operation in den Parent-Workspace statt; danach sind die Änderungen im LIVE Workspace sichtbar.

Darüber hinaus gibt es den Fall des "Refresh"; der ist dann von Bedeutung, wenn sich, nach dem Erstellen eines Workspace, Änderungen im Parent-Workspace (also "LIVE") ergeben haben. Diese werden nicht automatisch sichtbar, sie müssen vielmehr durch die Refresh-Operation "gezogen" werden.

Merge Refresh Workspace "LIVE" Workspace "PLAN 1" Workspace "PLAN 2"

Abbildung 2: "Merge" erfolgt vom Child zum Parent, "Refresh" in umgekehrter Richtung

Eine detaillierte technische Beschreibung des Workspace Manager und wie er arbeitet, würde hier zu weit führen, dazu sei auf die Dokumentation Introduction to Workspace Manager verwiesen. Hier sei nur soviel gesagt: Wenn eine Tabelle für den Workspace Manager aktiviert wird, wird sie umbenannt und erhält zusätzliche Spalten, in denen der Workspace Manager die Informationen ablegt, welche Zeilen welchen Status in welchem Workspace haben.

Schließlich wird eine View mit dem Originalnamen der Tabelle erzeugt - DML-Anweisungen auf die Tabelle zielen von nun an auf die View, wo sie mit INSTEAD-OF Triggern abgefangen werden. Ein DELETE, ausgelöst in einem Workspace, löscht die Zeile dann nicht mehr tatsächlich, vielmehr werden Informationen in die Zusatzspalten eingetragen, die festlegen, dass die Zeile in diesem Workspace gelöscht ist. Weitere, auch sehr detaillierte, Informationen finden sich in der Dokumentation.

Workspace Manager und Application Express: Vorbereitungen

Der Workspace Manager wird mit dem PL/SQL-Paket DBMS_WM bedient. Für den Aufruf des Pakets aus Application Express heraus gibt es allerdings eine Besonderheit:

Manche Prozeduren in DBMS_WM (bspw. DBMS_WM.createWorkspace setzen voraus, dass man "physikalisch" als Eigentümer der Tabelle bzw. des Workspace mit der Datenbank verbunden ist. Arbeitet man mit SQL*Plus oder dem SQL Developer, so ist das der Fall. Anders bei Application Express: Hier sind Sie physikalisch als APEX_PUBLIC_USER mit der Datenbank verbunden - Application Express sorgt dafür, dass Ihre SQL-Anweisungen im richtigen Kontext ausgeführt werden. Dadurch funktioniert der Aufruf von DBMS_WM.createWorkspace aus Application Express heraus nicht richtig - mit einem kleinen Trick lässt sich hier aber leicht Abhilfe schaffen:

Erzeugen Sie in Ihrem Datenbankschema einen Database Link, der auf das gleiche Datenbankschema in der gleichen Datenbank verzweigt - also eine Art "loopback" Link. Wenn das Datenbankschema SCOTT heißt, könnte das in etwa wie folgt aussehen (passen Sie das an Ihre Umgebung an):

create database link loopback_link connect to scott 
                                   identified by *****
                                   using 'localhost:1521/orcl'; 

Nun lässt sich DBMS_WM.createWorkspace wie folgt aufrufen - durch den Database Link findet die physikalische Verbindung als der "richtige" Datenbankuser statt.

begin
  dbms_wm.createWorkspace@loopback_link( 'My Workspace Name' );
end; 

Dieser Database Link wird nur für wenige, ausgewählte Aufrufe des Pakets DBMS_WM gebraucht (in diesem Tipp ist es nur DBMS_WM.createWorkspace); alle anderen SQL- und PL/SQL Aufrufe erfolgen ganz normal.

Der nächste Schritt ist das Aktivieren der Tabelle oder der Tabellen, mit denen man arbeiten möchte. Sind Tabellen per Fremdschlüssel miteinander verbunden, so müssen diese gemeinsam für den Workspace Manager aktiviert werden. Das folgende Beispiel aktiviert die Tabellen EMP und DEPT.

begin
  dbms_wm.enableVersioning(
    table_name => 'emp,dept'
  );
end; 

Damit sind die Vorbereitungen gemacht - der Workspace Manager kann nun in der Application Express-Anwendung verwendet werden.

Oracle Workspace Manager in eine Application Express Anwendung integrieren

Als Ausgangspunkt soll eine einfache Application Express Anwendung auf Basis der Tabelle EMP dienen. Erzeugen Sie eine Anwendung mit mindestens einer Seite und erstellen Sie einen Bericht, ein Diagramm und ein Formular. Ab Application Express 5.1 können Sie natürlich auch das interactive Grid verwenden. Eine solche Seite könnte dann wie folgt aussehen:

Ausgangspunkt: Ein Bericht und ein Formular für die Tabelle EMP

Abbildung 3: Ausgangspunkt: Ein Bericht und ein Formular für die Tabelle EMP

Die Tabelle ist zwar bereits für den Workspace-Manager aktiviert, es wurden aber noch keine Workspaces erzeugt. Daher finden im Moment alle Aktionen im Workspace LIVE statt und sind für jeden sichtbar. Vom Workspace Manager merkt man (noch) nichts.

Zunächst muss sichergestellt werden, dass Application Express bei jedem Page Show- oder Page Processing-Request in den richtigen Workspace wechselt. Dazu erstellen Sie zuerst ein Application Item, welches den aktuellen Workspace halten soll. Navigieren Sie also zu den Gemeinsamen Komponenten, dort zu den Application Items und klicken Sie auf den Button Create. Nennen Sie das Element APP_CURRENT_WORKSPACE, nehmen Sie ansonsten die Defaults und speichern Sie ab.

Das Application Item "APP_CURRENT_WORKSPACE" hält den Workspace, in dem sich der Nutzer befindet

Abbildung 4: Das Application Item "APP_CURRENT_WORKSPACE" hält den Workspace, in dem sich der Nutzer befindet

Erstellen Sie danach eine Application Computation - das Item APP_CURRENT_WORKSPACE soll den Wert LIVE erhalten, wenn es leer (NULL) ist.

Setze "APP_CURRENT_WORKSPACE" auf "LIVE", wenn NULL

Abbildung 5: Setze "APP_CURRENT_WORKSPACE" auf "LIVE", wenn NULL

Navigieren Sie danach in dem Gemeinsamen Komponenten zum Bereich Security Attributes und dort zu Database Session. Hinterlegen Sie den folgenden PL/SQL-Aufruf als Initialization PL/SQL Code.

begin
  dbms_wm.gotoWorkspace( nvl( :APP_CURRENT_WORKSPACE, 'LIVE' ) );
end; 

Als Cleanup PL/SQL Code hinterlegen Sie:

begin
  dbms_wm.gotoWorkspace( 'LIVE' );
end;  
Im Session Initialization und Cleanup Code findet der Workspace-Wechsel statt

Abbildung 6: Im Session Initialization und Cleanup Code findet der Workspace-Wechsel statt

Als nächstes erstellen Sie eine neue Anwendungsseite, auf der der Anwender den Workspace auswählen, neue erstellen, bestehende löschen und andere administrative Aufgaben erledigen kann. Achten Sie bei den folgenden Anweisungen darauf, das Elementpräfix PX_ an Ihre konkrete Seitennummer anzupassen.

Mit Hilfe von Dynamic Actions können Sie die Seite noch etwas anwenderfreundlicher gestalten. So sollte das Texteingabefeld PX_NEW_WORKSPACE und der Button CREATE_WORKSPACE nur angezeigt werden, wenn die Select-Liste PX_WORKSPACE auf NULL steht, also "Create New Workspace" anzeigt. Hier können Sie gut mit den Actions Show und Hide arbeiten. Schließlich sollte die Seite etwa wie folgt aussehen.

Application Express-Seite für die Workspace-Administration

Abbildung 7: Application Express-Seite für die Workspace-Administration

Die Seite kann schon aufgerufen werden, bei Klick auf die Buttons passiert natürlich noch nichts - das kommt im nächsten Schritt. Erstellen Sie nun die folgenden Seitenprozesse.

  1. Prozess Create Workspace bei Klick auf den Button CREATE_WORKSPACE mit folgenden PL/SQL-Code:
    begin
      -- execute DBMS_WM.createWorkspace over DB Link; 
      -- correct physical connection is important here.
      --
      dbms_wm.gotoWorkspace( 'LIVE' );
      dbms_wm.createWorkspace@loopback_link( :PX_NEW_WORKSPACE );
      :APP_CURRENT_WORKSPACE := :PX_NEW_WORKSPACE;
    end;
  2. Prozess Goto Workspace bei Klick auf den Button GOTO_WORKSPACE mit folgenden PL/SQL-Code:
    begin
      :APP_CURRENT_WORKSPACE := :PX_WORKSPACE;
    end;
  3. Prozess Remove Workspace bei Klick auf den Button REMOVE_WORKSPACE mit folgenden PL/SQL-Code:
    begin
      dbms_wm.gotoWorkspace( 'LIVE' );
      dbms_wm.removeWorkspace( :PX_WORKSPACE );
      :APP_CURRENT_WORKSPACE := 'LIVE';
      :PX_WORKSPACE := 'LIVE';
    end;
  4. Prozess Merge Workspace bei Klick auf den Button MERGE_WORKSPACE mit folgenden PL/SQL-Code:
    begin
      dbms_wm.mergeWorkspace( :PX_WORKSPACE );
    end;
  5. Prozess Rollback Workspace bei Klick auf den Button ROLLBACK_WORKSPACE mit folgenden PL/SQL-Code:
    begin
      dbms_wm.rollbackWorkspace( :PX_WORKSPACE );
    end;

Vergessen Sie nicht, aussagekräftige Success Messages zu vergeben. Zum Abschluß erzeugen Sie eine Seitenverzweigung (Branch), die nach dem Processing ausgeführt wird und wieder auf die gleiche Seite zurückverzweigt.

Es dürfte eine gute Idee sein, den aktuellen Workspace und die neue Workspace-Administrationsseite zur Navigation Bar oben rechts hinzuzufügen. Navigieren Sie dazu zu den Gemeinsamen Komponenten, dort zu den Navigation Bar List und dann zur Desktop Navigation Bar. Normalerweise finden Sie dort genau einen Eintrag vor: Log Out. Fügen Sie mit mit Klick auf den Button Create Entry einen neuen Eintrag hinzu.

Eintrag für den aktuellen Workspace zur Navigation Bar hinzufügen

Abbildung 8: Eintrag für den aktuellen Workspace zur Navigation Bar hinzufügen

Oracle Workspace Manager in der Anwendung nutzen

Starten Sie nun die Anwendung und navigieren Sie zu Ihrer neuen "Administrationsseite" für den Workspace Manager. Erstellen Sie einen neuen Workspace namens Simulation mit Klick auf Create Workspace.

Neuen Workspace "Simulation" erstellen

Abbildung 9: Neuen Workspace "Simulation" erstellen

Navigieren Sie dann zu der Seite mit den Berichten und Diagrammen auf die Tabelle EMP. Achten Sie auf die Navigation Bar oben rechts. Mit dem Erstellen des neuen Workspace ist die Anwendung auch gleichzeitig in diesen gewechselt.

Tabellendaten "EMP" - im Workspace "Simulation"

Abbildung 10: Tabellendaten "EMP" - im Workspace "Simulation"

Nun können Sie die Tabelle EMP verändern; verändern Sie die Daten, bis sich in etwa folgendes Bild ergibt.

Veränderte Tabellendaten EMP - im Workspace "Simulation"

Abbildung 11: Veränderte Tabellendaten EMP - im Workspace "Simulation"

Loggen Sie sich nun aus der Anwendung aus und wieder ein - angenommen, ein anderer Nutzer beginnt das Arbeiten. Dann sieht die Tabelle EMP wieder aus wie vorher - denn standardmäßig befindet man sich zu Beginn einer Application Express-Sitzung im Workspace LIVE.

Tabellendaten EMP - im Workspace "LIVE"

Abbildung 12: Tabellendaten EMP - im Workspace "LIVE"

Die gemachten Änderungen betreffen nur den Workspace Simulation; der Rest der Anwendung kann mit den "normalen" Tabellendaten arbeiten, ohne von der Simulation behelligt zu werden. Erst wenn man explizit in den Workspace Simulation wechselt, sieht man die Änderungen.

Tabellendaten EMP - im Workspace "LIVE"

Abbildung 13: Veränderte Tabellendaten EMP - im Workspace "Simulation"

Nun soll die Simulation zur "neuen Realität" werden; die Änderungen des Workspace "Simulation" sollen in den Workspace LIVE übernommen und damit für alle sichtbar werden. Das geschieht mit der Merge Workspace Operation - für die auf der Workspace-Administrationsseite bereits die entsprechenden PL/SQL Prozesse eingerichtet wurden.

Änderungen in den LIVE Workspace übernehmen

Abbildung 14: Änderungen in den LIVE Workspace übernehmen

Von nun an sind die Änderungen für alle wirksam - die Daten des Workspace Simulation sind nun die neue Realität.

Die Änderungen sind nun für alle sichtbar

Abbildung 15: Die Änderungen sind nun für alle sichtbar

Fazit und Ausblick

Das Workspace Manager Feature der Oracle-Datenbank erlaubt es, Tabellendaten mit sehr wenig Aufwand zu versionieren und Änderungen in privaten Workspaces durchzuführen. Die Workspaces sind voneinander isoliert, so dass Änderungen in einem Workspace keine Auswirkungen auf andere Nutzer oder Anwendungen haben. Die Änderungen eines Workspace können als Ganzes verworfen oder auf den LIVE-Datenbestand angewendet werden. In Application Express-Anwendungen kann das Feature mit wenigen Handgriffen integriert werden.

Die Möglichkeiten des Workspace Manager gehen noch wesentlich weiter als in diesem Tipp gezeigt. Man kann sich vorstellen, dass es in einem solchen Szenario Konflikte geben kann. Angenommen, es gibt zwei Workspaces für zwei Simulationen. Beide machen unterschiedliche Änderungen an einer Tabellenzeile. Nun führt zuerst ein Workspace sein Merge durch, dann der zweite. Es entsteht ein Konflikt, denn das zweite Merge würde das erste überschreiben. Workspace Manager erkennt diese Konflikte und stellt per PL/SQL API und Datenbank-Views Informationen über diese Konflike bereit, so dass diese in der Anwendung gelöst werden können. Dies muss jedoch einem anderen Community-Tipp vorbehalten bleiben.

Zurück zur Community-Seite