Wenn ein Team parallel an einer APEX-Anwendung arbeitet, können Änderungen an der Hauptanwendung leicht kollidieren. Working Copies bieten dafür einen Arbeitsbereich innerhalb desselben Workspaces. Mit APEX 26.2 lassen sich Sperren und das Anlegen solcher Kopien zusätzlich per PL/SQL anstoßen – nützlich für interne Entwicklerportale, kontrollierte Build-Abläufe und vertrauenswürdige CI- oder KI-Integrationen.
Eine Working Copy gezielt anlegen
APEX_APPLICATION_ADMIN.CREATE_WORKING_COPY erhält die ID der Hauptanwendung und einen Namen für die Kopie. Die Funktion liefert die neue Anwendungs-ID zurück. Eine erneute Anfrage mit demselben Namen für dieselbe Hauptanwendung erzeugt keine zweite Kopie, sondern führt zu einem Fehler. Ein Orchestrator sollte daher vor dem Anlegen prüfen, ob die gewünschte Kopie bereits existiert, und Wiederholungen gezielt behandeln.
DECLARE
l_working_copy_id NUMBER;
BEGIN
l_working_copy_id := apex_application_admin.create_working_copy(
p_application_id => 100,
p_working_copy_name => 'Feature Orders',
p_working_copy_description => 'Änderungen für das nächste Release'
);
dbms_output.put_line('Working Copy: ' || l_working_copy_id);
END;
/Die ID im Beispiel ist Platzhalter. Die Working Copy startet als separate APEX-Anwendung mit eigener ID. Anwendungscode, der die Haupt-App-ID benötigt, sollte deshalb die APEX-Substitution MAIN_APP_ID statt APP_ID verwenden.
Hauptanwendung gegen parallele Änderungen schützen
Mit LOCK_APPLICATION wird die Hauptanwendung für einen bestehenden Workspace-Entwickler oder Administrator gesperrt. App Builder verhindert dann Änderungen durch andere Entwickler. Wiederholt derselbe Owner den Aufruf, kann der Sperrkommentar aktualisiert werden; ein anderer Owner erhält einen Fehler, wenn bereits eine fremde Sperre besteht.
BEGIN
apex_application_admin.lock_application(
p_application_id => 100,
p_lock_as_user => 'DEPLOY_BOT',
p_lock_comment => 'Release 2.4: Working Copy wird vorbereitet'
);
END;
/Zum kontrollierten Entsperren kann UNLOCK_APPLICATION zusätzlich mit p_unlock_as_user auf den erwarteten Besitzer begrenzt werden. Das hilft, dass ein automatischer Aufräumschritt nicht versehentlich die Sperre eines anderen Entwicklers entfernt. Die API ersetzt aber keine Ablaufsteuerung: Bei Fehlern und Abbrüchen muss klar sein, wer die Sperre wieder freigibt.
Ein sicherer Ablauf für Automatisierung
- Aufrufer und Zielanwendung gegen eine Allowlist prüfen; nur vertrauenswürdige Integrationen dürfen diese APIs ausführen.
- Vorhandene Working Copy beziehungsweise aktive Sperre prüfen und den vorgesehenen Owner eindeutig festlegen.
- Die Kopie anlegen und ihre zurückgegebene App-ID im Build-Protokoll speichern.
- Änderungen isoliert entwickeln, exportieren und mit der Hauptanwendung vergleichen.
- Konflikte und Supporting Objects separat behandeln; erst nach erfolgreicher Prüfung gezielt zusammenführen.
- Sperren im Erfolgs- und Fehlerpfad mit Owner-Prüfung lösen und verwaiste Kopien nach Teamregel entfernen.
Working Copies sind keine automatische Git-Branch- oder Merge-Lösung. Sie geben Entwicklern eine APEX-native Isolation; Vergleich und Zusammenführung bleiben bewusste Schritte. Die neuen APIs machen diesen Ablauf programmierbar, während Workspace-Berechtigungen und APEX-Sperrregeln weiterhin gelten.
Weiterführend: Oracle APEX 26.2 Neuerungen, die API-Referenz für CREATE_WORKING_COPY und LOCK_APPLICATION.