Shared Components werden an vielen Stellen einer APEX-Anwendung verwendet. Eine REST Data Source kann zugleich eine Report-Region, eine LOV und eine Automation versorgen. Wird sie geändert oder ersetzt, reicht es deshalb nicht, nur eine einzelne Seite zu prüfen. Oracle APEX 24.2 erweitert die Nutzungsberichte für Task Definitions, Email Templates und REST Data Sources um Verwendungen in Workflows und Tasks.
1. Nutzung statt Vermutung prüfen
Öffnen Sie die passende Shared-Component-Seite und wechseln Sie in den Tab „Utilization“. Der Bericht zeigt, an welchen Seiten oder Komponenten das ausgewählte Objekt verwendet wird. Bei REST Data Sources sind dabei zum Beispiel Regionen und weitere Anwendungskomponenten relevant; bei Task Definitions können Workflow- und Task-Nutzungen hinzukommen.
Das Ergebnis ist eine bessere Grundlage als eine Suche nach Namen im Export. Eine Komponente kann indirekt über einen Workflow oder eine referenzierende Definition verwendet werden. Notieren Sie vor der Änderung, welche Fundstellen produktiv, experimentell oder bereits veraltet sind.
2. REST Data Sources sicher ändern
Planen Sie bei einer REST Data Source zunächst die Auswirkungen auf Data Profile, Filter, Sortierung und Pagination. Eine Änderung des Response-Felds kann mehrere Regionen gleichzeitig betreffen. Prüfen Sie für jede Fundstelle, ob sie das Feld als Anzeige-, Rückgabe- oder Sortierspalte verwendet.
Bei einer Umstellung auf eine neue URL oder einen anderen Endpoint sollten Sie nicht nur die Discovery testen. Führen Sie zusätzlich die konkreten Nutzeraktionen aus: Report laden, filtern, sortieren, Pagination verwenden und – falls erlaubt – Daten schreiben. So finden Sie auch Fehler in Parametern oder Berechtigungen, die im reinen Utilization Report nicht sichtbar sind.
3. Workflows und Tasks mitdenken
In APEX können Tasks und Workflows dieselben fachlichen Definitionen und E-Mail Templates verwenden. Der erweiterte Nutzungsbericht hilft zu erkennen, ob eine Änderung an einer Benachrichtigung oder Task Definition nur eine Seite oder einen ganzen Prozess betrifft.
Prüfen Sie bei Workflow-Nutzungen Start, Routing, Teilnehmer, Fristen und die Anzeige der Task Details. Nach einer Änderung gehören ein neuer Workflow-Lauf und ein bereits laufender Vorgang in den Testumfang. Ein neuer Prozess kann funktionieren, während alte Instanzen noch auf den vorherigen Stand verweisen.
4. Änderung dokumentieren und erneut prüfen
Dokumentieren Sie die Nutzung vor der Änderung und führen Sie den Bericht danach erneut aus. Nicht jede Änderung entfernt eine Nutzung sofort, wenn ein weiterer Shared Component oder eine Seite weiterhin referenziert. Der Vergleich vor und nach der Änderung zeigt, ob die gewünschte Bereinigung tatsächlich erreicht wurde.
Für Releases empfiehlt sich ein kleiner Ablauf: Utilization Report speichern, Änderung in einer Testumgebung durchführen, betroffene Pfade testen und anschließend den finalen Report prüfen. In Kombination mit dem Database Object Dependencies Report erhalten Sie sowohl die APEX-Komponenten- als auch die Datenbankperspektive.
Praktische Checkliste
- Utilization Report des betroffenen Shared Components öffnen.
- Jede Nutzung nach Region, Workflow, Task und E-Mail-Kontext bewerten.
- REST-Änderungen inklusive Data Profile, Filter und DML testen.
- Bei Workflows neue und laufende Instanzen prüfen.
- Nach der Änderung erneut scannen und Ergebnis dokumentieren.
Fazit
Die erweiterten Shared-Component-Nutzungsberichte in APEX 24.2 machen Auswirkungen von Änderungen sichtbarer. Besonders bei REST Data Sources sowie Workflow- und Task-Definitionen reduzieren sie das Risiko vergessener Abhängigkeiten. Der Bericht ersetzt keinen Funktionstest, gibt dem Test aber eine verlässliche Reihenfolge und einen klaren Änderungsumfang.
Weiterführend: Shared-Component-Nutzungsberichte in APEX 24.2, die REST-Data-Source-Utilization und die Workflow-Berichte.