Stellen Sie sich vor ...

• Sie könnten eine Tabelle in einer APEX-Anwendung über einen längeren Zeitraum verändern (INSERT, UPDATE, DELETE)
• Diese Änderungen erfolgen mit normalen APEX-Formularen - in der Datenbank findet also stets das COMMIT statt ...
• ... und dennoch sind diese Änderungen nur für Sie sichtbar .
• Und am Ende können Sie den Änderungsblock als Ganzes verwerfen oder für alle sichtbar machen.

Geht nicht? Geht doch! Mit dem Oracle Workspace Manager, über den Sie in diesem Tipp mehr erfahren, ist das möglich. Sie können in ein- und derselben Tabelle mehrere unabhängige Arbeitsbereiche (Workspaces) einrichten. Die Workspaces bilden eine Hierarchie (Abbildung 1). Alle SQL-Abfragen und DML-Anweisungen (Insert, Update, Delete) beziehen sich auf einen bestimmten Workspace. In einem Workspace gemachte Änderungen sind in den anderen Workspaces solange nicht sichtbar, bis eine explizite Merge oder Refresh -Operation erfolgt. Die Wurzel der Workspace-Hierarchie ist der LIVE-Workspace; wenn man keinen bestimmten Workspace auswählt, so befindet man sich stets in diesem.

Die Workspaces des Oracle Workspace Managers sind völlig unabhängig von den APEX Workspaces; das Feature kann auch unabhängig von APEX (bspw. nur mit SQL*Plus) genutzt werden. Wenn in diesem Artikel von einem "Workspace" die Rede ist, so ist der Arbeitsbereich (Workspace) des Oracle Workspace Managers gemeint und nicht der APEX Workspace.

Änderungen an der Tabelle im Workspace Änderung 1 sind weder für den Workspace LIVE noch für den Workspace Änderung 2 sichtbar. Erst wenn der Workspace "Änderung 1" in den LIVE-Workspace ge"merged" wurde, sind die Änderungen für alle sichtbar. Alternativ können die Änderungen natürlich auch verworfen werden. Im LIVE-Workspace selbst können ebenfalls Änderungen vorgenommen werden - diese sind dann in den abgeleiteten Workspaces solange nicht sichtbar, bis eine Refresh-Operation erfolgt. Die Operation "Merge" überträgt Änderungen also stets vom Child-Workspace zum Parent-Workspace; eine Refresh-Operation in umgekehrter Richtung.

Wozu das gut ist? Umfangreiche Änderungen können auch über einen längeren Zeitraum gemacht und dann als ganzes freigeschaltet oder verworfen werden; der Workspace Manager eignet sich gut zur Unterstützung solcher langlaufender Transaktionen. Einige Anwendungsbeispiele ...

• Umfangreiche, länger laufende Simulationen können in einem Workspace durchgeführt werden. So könnte ein Kreditinstitut eine Simulation mit neuen Konditionen ein einem eigenen Workspace durchführen, die Auswirkungen analysieren und die Änderungen dann verwerfen.
• Ein weiteres praktisches Einsatzgebiet ist die Arbeit mit Geodaten bzw. Katasterdaten. Hier finden Planungen und Simulationen typischerweise über lange Zeiträume statt und sind mit Vermessungsarbeit verbunden. Umfangreiche Änderungen werden in einem Workspace gemacht und erst nach Abschluß der Arbeiten als Ganzes für alle freigegeben. Solange diese Freigabe noch nicht erfolgt ist, sind die im Workspace gemachten Änderungen für alle anderen nicht sichtbar.

Werden Tabellenzeilen von mehreren Workspaces konkurrierend geändert, entsteht eine Konfliktsituation - hierfür bietet der Workspace-Manager entsprechende Mechanismen an, die in einem anderen Community-Tipp beschrieben sind.

Tabelle für Workspace-Manager einrichten

Damit Sie Workspaces in einer Tabelle nutzen können, müssen Sie den Workspace-Manager für diese Tabelle aktivieren. Beachten Sie bitte, dass Sie per Fremdschlüssel verbundene Tabellen gemeinsam aktivieren müssen. Die Funktionalität des Workspace-Manager wird im Paket DBMS_WM bereitgestellt. Die Prozedur enableVersioning aktiviert Workspaces für eine oder mehrere Tabellen. Setzen Sie dazu in SQL*Plus oder im SQL Workshop folgendes Kommando ab:

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

Wenn Sie mehrere Tabellen aktivieren möchten, trennen Sie die Tabellennamen mit Kommas.

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

Zusätzlich können Sie bestimmen, dass eine Historie über die gemachten Änderungen geführt wird.

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

Technisch werden Workspaces durch das Einrichten von Views und Instead-Of-Triggern ermöglicht. Das Kommando enableVersioning richtet die für den Workspace Manager nötige Infrastruktur ein - diese ist im Handbuch zum Workspace Manager näher beschrieben. Im wesentlichen wird die Tabelle umbenannt und Spalten zur Aufnahme der Workspace-Informationen hinzugefügt. Für die Anwendung wird die Tabellenstruktur als View bereitgestellt. Alle SQL-Operationen werden auf dieser View durchgeführt - Instead-Of-Trigger übertragen die Änderungen auf die eigentlichen Tabellen (Abbildung 3).

Workspace-Manager in einer APEX-Anwendung nutzen

Im folgenden erfahren Sie nun, wie Sie den Workspace-Manager in einer APEX-Anwendung nutzen können. Richten Sie sich zunächst eine Anwendung mit Bericht und Formular auf die Tabellen EMP bzw. DEPT ein; eine Anwendungsseite könnte dann wie in Abbildung 3 aussehen.

Achtung: Wenn Sie Workspaces für eine Tabelle mit DBMS_WM.enableVersioning aktiviert haben, funktionieren einige APEX-Assistenten für Formulare nicht, weil die Primärschlüsselspalten nicht mehr gefunden werden. Auf manuellem Wege können Formulare jedoch immer noch erstellt werden. Wenn Sie dennoch die Assistenten nutzen möchten, müssen Sie die Workspaces vorher mit DBMS_WM.disableVersioning ab- und ggfs. nach Erstellung der Anwendung wieder einschalten.

Wenn Sie das Formular per Assistent erstellt haben und damit einen "Automatic Row Processing" Prozess zum Durchführen der Änderungen haben, müssen Sie bei diesem noch eine zusätzliche Bedingung eintragen; dieser Prozess darf nur bei Klick auf die Schaltflächen des Formulars ausgeführt werden (Abbildung 5). Ohne diese Bedingung arbeitet APEX nicht richtig mit dem Workspace Manager zusammen.

GUI-Elemente für den Workspace Manager auf Seite 0 einrichten

Fügen Sie nun die Elemente zur Nutzung des Workspace-Manager hinzu. Dies wollen wir mit Hilfe der Seite 0 (Page Zero) erledigen. Ziel wäre es, dass jede Anwendungsseite eine GUI-Leiste zum Umgang mit dem Workspace-Manager bekommt; der Anwender kann also an jedem beliebigen Punkt zwischen den Workspaces wechseln. Erzeugen Sie also in Ihrer Anwendung die Seite 0 und navigieren Sie zu dieser (Abbildung 6).

Fügen Sie nun eine neue Region hinzu. Achten Sie darauf, dass diese eine möglichst kleine Sequence-Number erhält (Abbildung 7). In diese Region werden nun die GUI-Elemente platziert, die zum Arbeiten mit dem Workspace-Manager benötigt werden. Da sie sich auf der Seite Null befindet, wird sie auf allen Anwendungsseiten dargestellt.

Fügen Sie dieser Region nun folgende Elemente hinzu:

• Textfeld P0_NEW_WSNAME: hier soll der Name eines neu zu erstellenden Workspace eingegeben werden
• Textfeld P0_CURR_WS: in diesem Read Only-Textfeld soll der Workspace angezeigt werden, der gerade aktiv ist. Wichtig sind die Angaben zur Elementquelle:
  
• Auswahlliste P0_EXISTING_WS: diese zeigt die existierenden Workspaces an - der Workspace, in den gewechselt werden soll, wird hier ausgewählt. Nehmen Sie folgendes SQL als Wertelistenabfrage.

  select WORKSPACE d, WORKSPACE r from USER_WORKSPACES
  union all (select 'LIVE' d, 'LIVE' r from dual)
  

• Schaltfläche CREATE_WS: zum Erstellen eines neuen Workspace
• Schaltfläche GOTO_WS: zum Wechseln in einen anderen Workspace
• Schaltfläche MERGE_WS: um den Stand des Workspace in den Parent-Workspace zu übernehmen (Merge-Operation)
• Schaltfläche ROLLBACK_WS: um die Änderungen des Workspace zu verwerfen

Die Schaltflächen sollen die Seite weiterleiten (keine reine Umleitung). Wenn Sie Ihre Anwendungsseite nun starten, könnte das Ergebnis in etwa wie in Abbildung 8 aussehen.

Prozeßlogik für den Workspace-Manager einrichten

Navigieren Sie dann zu den Gemeinsamen Komponenten und dort zu den Anwendungsprozessen. Nun müssen drei Prozesse erstellt werden.

Erzeugen Sie einen Prozeß namens Workspace erstellen und wählen Sie als Punkt (siehe Abbildung 9) "Bei Weiterleitung: Nach Seitenweiterleitung ..." aus. Dieser Prozeß ist dann (da er bei den Anwendungsprozessen angelegt wird) für alle Seiten gültig.

Hinterlegen Sie folgenden PL/SQL-Code:

begin
  dbms_wm.createWorkspace(
    workspace => :P0_NEW_WSNAME
  );
end;

Achten Sie darauf, den Prozeß an eine Bedingung zu knüpfen - er soll nur bei Klick auf die Schaltfläche CREATE_WS ausgeführt worden (Abbildung 10).

Legen Sie die dann die anderen beiden Prozesse an. Der Prozeß Merge Workspace wird genauso erstellt; er wird an die Schaltfläche MERGE_WS geknüpft und erhält folgenden PL/SQL-Code.

begin
  dbms_wm.mergeWorkspace(
    workspace => :P0_EXISTING_WS
  );
end;

Und ebenso wird der Prozess Rollback Workspace erzeugt - mit folgendem PL/SQL-Code und einer Bindung an die Schaltfläche ROLLBACK_WS.

begin
  dbms_wm.rollbackWorkspace(
    workspace => :P0_EXISTING_WS
  );
end;

Der Prozeß zum Wechseln des aktuellen Workspace wird etwas anders erzeugt - hier müssen die Besonderheiten des APEX Session-Handlings berücksichtigt werden. Wir müssen sowohl für das Page Rendering (Seitenerstellung) als auch für das Page Processing (Seitenverarbeitung) sicherstellen, dass APEX sich im richtigen Workspace befindet. Zunächst zum Page Rendering: Legen Sie einen Anwendungsprozeß namens Workspace wechseln (Render) an und wählen Sie als Prozesspunkt "Beim Laden: Vor Header ..." aus. Hinterlegen Sie dort folgenden PL/SQL-Code und keine Bedingung.

begin
  dbms_wm.gotoWorkspace(
    workspace => nvl(:P0_EXISTING_WS,'LIVE')
  );
end;

Nachdem das Page Rendering abgeschlossen und die Anwendungsseite beim Browser angekommen ist, sollte wieder in den LIVE Workspace zurückgewechselt werden. Erzeugen Sie also einen weiteren Anwendungsprozeß namens Wechseln in LIVE (Render) , nehmen Sie "Beim Laden: Nach Footer ..." als Prozesspunkt und hinterlegen Sie diesen PL/SQL-Code. Auch dieser Prozess bekommt keine Bedingung.

begin
  dbms_wm.gotoWorkspace(
    workspace => 'LIVE'
  );
end;

Erzeugen Sie dann den dritten Prozeß (dieser stellt sicher, dass auch das Page Processing im richtigen Workspace stattfindet). Erstellen Sie also nochmals einen Anwendungsprozeß und wählen Sie als Prozeßpunkt "Bei Weiterleitung: Nach Seitenweiterleitung - Vor Berechnungen ..." aus. Auch dieser Prozeß bekommt keine Bedingung und folgenden PL/SQL-Code:

begin
  dbms_wm.gotoWorkspace(
    workspace => nvl(:P0_EXISTING_WS,'LIVE')
  );
end;

Testen ...

Damit ist die Applikation fertig. Starten Sie sie und probieren Sie es aus: Tragen Sie einen Namen in das Textfeld ein und klicken Sie dann auf Workspace erstellen.

Anschließend wechseln Sie in diesen Workspace - wählen Sie TRANS_1 aus und klicken Sie auf Workspace wechseln.

Nehmen Sie nun einige Änderungen an der Tabelle EMP vor.

Wechseln Sie zurück in den LIVE-Workspace - Sie sehen den Stand vor der Änderung.

Führen Sie die MERGE-Operation durch - Wählen Sie dazu TRANS_1 aus der Auswahlliste aus und klicken Sie dann auf Merge Workspace. Wie eingangs beschrieben, zielt die Merge-Operation stets auf den Parent-Workspace (LIVE). Anschließend sehen Sie die gemachte Änderung auch im LIVE-Workspace. Mit überschaubarem Aufwand haben Sie nun also eine Anwendung, in der die Endanwender in Ihre Änderungen in verschiedenen Arbeitsbereichen tätigen und dann als Ganzes verwerfen oder bestätigen können. Dieser Tipp hat die Möglichkeiten des Workspace Managers keinesfalls komplett beschrieben; das Paket DBMS_WM hat noch viel mehr Prozeduren und Funktionen; vollständige Informationen dazu finden sich hier:

• APEX Community-Tipp Teil II: Konflikte mit dem Workspace Manager lösen
• Broschüre: Überblick über den Oracle Workspace Maneger
• Oracle Dokumentation: Database Workspace Manager Developer's Guide

Zurück zur Community-Seite