Shared Component Subscriptions helfen, gemeinsame Listen, LOVs, REST Data Sources oder Plug-ins über mehrere APEX-Anwendungen hinweg zu nutzen. Die Pflege dieser Komponenten erfolgt häufig manuell im App Builder. Oracle APEX 24.2 stellt mit APEX_SHARED_COMPONENT ein neues Paket bereit, das die beiden Vorgänge Refresh und Publish per PL/SQL ansprechbar macht.
1. Refresh und Publish unterscheiden
REFRESH aktualisiert ein abonniertes Shared Component aus seiner Quelle. Das ist der passende Schritt, wenn eine Anwendung eine neue Version eines zentral gepflegten Components übernehmen soll. PUBLISH veröffentlicht dagegen einen Component aus der Master-Anwendung für abonnierende Anwendungen.
Beide Vorgänge haben unterschiedliche Auswirkungen. Ein Refresh kann das Verhalten einer einzelnen Anwendung ändern; ein Publish kann mehrere Abnehmer beeinflussen. Legen Sie deshalb fest, welche Rolle ein automatisierter Job übernehmen darf und wo ein manueller Freigabeschritt erforderlich bleibt.
2. Auf veraltete Abonnements filtern
Für einen Refresh-Prozess liefert die View APEX_SUBSCRIBED_COMPONENTS die Grundlage. Filtern Sie auf die Anwendung und den Status, der nicht „Up to date“ entspricht. So verarbeitet ein Job nur tatsächlich veraltete Components und bleibt auch bei vielen Anwendungen überschaubar.
FOR c IN (
SELECT component_type, component_id
FROM apex_subscribed_components
WHERE application_id = :APP_ID
AND subscription_status <> apex_shared_component.c_status_up_to_date
) LOOP
apex_shared_component.refresh(
p_component_type => c.component_type,
p_component_id => c.component_id);
END LOOP;Das Beispiel zeigt das Muster, nicht einen universellen Job. Verwenden Sie für produktive Abläufe eine Whitelist der erlaubten Component-Typen und protokollieren Sie jede Aktualisierung. Ein Commit sollte erst erfolgen, wenn Fehlerbehandlung und Wiederanlauf definiert sind.
3. Workspace-Kontext und Berechtigungen
Wird die API außerhalb der APEX-Umgebung ausgeführt, muss der Workspace-Kontext gesetzt werden. Die notwendigen Rechte und der technische Ausführungsort gehören in die Betriebsdokumentation. Eine unklarer Kontext kann dazu führen, dass der Prozess die gewünschte Anwendung nicht findet oder im falschen Workspace arbeitet.
Beschränken Sie außerdem die Ausführung auf einen technischen Prozess mit klarer Berechtigung. Publish und Refresh sind Änderungen an Shared Components und sollten nicht über eine frei erreichbare End User-Seite ausgelöst werden.
4. Nach dem Refresh testen
Ein erfolgreicher API-Aufruf beweist nur, dass die Komponente aktualisiert wurde. Prüfen Sie danach die wichtigsten Abnehmer: LOV-Auflösung, REST-Aufruf, Authorization Scheme, Plug-in-Rendering oder Listennavigation. Bei einer neuen Version sollten Sie außerdem die Utilization Reports und Database Object Dependencies erneut betrachten.
Planen Sie für Teilfehler einen nachvollziehbaren Wiederanlauf. Ein einzelner defekter Component darf nicht unbemerkt dazu führen, dass ein Batch als vollständig erfolgreich markiert wird. Speichern Sie Component-Typ, ID, Zeit, Status und Fehlermeldung in einem technischen Log.
Praktische Checkliste
- Master- und abonnierende Anwendungen eindeutig festlegen.
- Refresh und Publish als getrennte Prozesse mit Freigaben behandeln.
- Veraltete Components über
APEX_SUBSCRIBED_COMPONENTSermitteln. - Workspace-Kontext, Berechtigungen und Whitelist der Component-Typen prüfen.
- Abnehmer testen, Fehler protokollieren und Wiederanlauf dokumentieren.
Fazit
APEX_SHARED_COMPONENT macht die zentrale Pflege in APEX 24.2 skriptbar. Das ist besonders für Teams interessant, die Shared Components über mehrere Anwendungen verteilen und den manuellen Refresh reduzieren möchten. Mit klarer Trennung von Refresh und Publish, begrenzten Rechten und einem echten Nachtest wird daraus ein kontrollierter Deployment-Baustein.
Weiterführend: APEX_SHARED_COMPONENT API-Referenz, die REFRESH-Prozedur und die PUBLISH-Prozedur.