APEX 26.2: Deployment-Dateien für APEXlang

Veröffentlicht am 12.11.2026 · Verfasst von Dominik Radojevic

Ein und dieselbe APEX-Anwendung soll häufig in mehreren Workspaces oder Schemas laufen. Bisher werden beim Umgebungswechsel leicht Werte in der exportierten Anwendung angepasst – und damit Unterschiede zwischen DEV, TEST und PROD versehentlich Teil des App-Quellcodes. APEX 26.2 ergänzt APEXlang um separate JSON-Deployment-Dateien. Sie halten deploymentspezifische Einstellungen getrennt von den eigentlichen .apx-Definitionen.

Eine Konfiguration je Ziel pflegen

Die Dateien liegen im Unterordner deployments/. default.json enthält die Standardwerte; zusätzliche Dateien können zum Beispiel test.json und prod.json heißen. Beim Import mit SQLcl lässt sich das passende Profil über die Option -deployment auswählen. Damit kann dieselbe versionierte App-Quelle in mehreren Umgebungen installiert werden, ohne für jede Umgebung einen abweichenden App-Export zu pflegen.

Je nach Bedarf lassen sich unter anderem Workspace-Name, Ziel-App-ID, Parsing-Schema, App-Alias, Logging und Debugging, Build-Status, statische Dateipfade sowie Zuordnungen abonnierter Master-Anwendungen festlegen. Nicht angegebene Werte stammen weiterhin aus der Anwendung oder den Zielumgebungs-Defaults.

Beispiel: Test- und Laufzeitkonfiguration

Ein Profil für eine reine Laufzeitinstallation könnte beispielsweise so aussehen:

{
  "app": {
    "id": 1020,
    "databaseSession": { "parsingSchema": "ORDERS_TEST" },
    "runtime": { "logging": true, "debugging": false },
    "availability": { "buildStatus": "runOnly" }
  },
  "workspace": { "name": "ORDERS_TEST" }
}

Das ist ein schematisches Beispiel: App-ID, Workspace und Parsing-Schema müssen zur Zielumgebung passen. In einer Pipeline wird das gewünschte JSON-Profil zusammen mit dem APEXlang-Artefakt versioniert und beim jeweiligen Import explizit ausgewählt. Vor dem Produktivimport sollten die effektiven Werte – besonders Parsing-Schema, App-ID und Build-Status – als Teil des Release-Reviews geprüft werden.

Wichtig für Sicherheit: Eine Deployment-Datei ist Konfiguration, kein Secret Store. Zugangsdaten gehören nicht hinein. Übernimm außerdem keinen Beispielwert für den Session-State-Checksum-Salt: Ein eigener Salt muss kryptografisch zufällig erzeugt werden. Eine Änderung kann signierte beziehungsweise gehashte Lesezeichen ungültig machen.

Werteauflösung verstehen

Ein Deployment-Profil ist nicht automatisch die einzige Quelle eines Werts. In der dokumentierten Reihenfolge haben explizite SQLcl-Importoptionen beziehungsweise Compiler-Overrides Vorrang, danach unterstützte Werte aus APEX_APPLICATION_INSTALL, dann die ausgewählte Deployment-Datei und zuletzt die App-Quelle oder der Ziel-Default. Wenn ein Profil scheinbar ignoriert wird, sollte deshalb zuerst die Pipeline auf zusätzliche Overrides geprüft werden.

Ein minimales Standardprofil aus dem APEXlang-Export als Ausgangspunkt verwenden.
Nur tatsächlich umgebungsabhängige Werte in test.json oder prod.json ergänzen.
Die Profile gemeinsam mit App-Version und Importprozess reviewen; IDs, Schema und Workspace gegen das Ziel abgleichen.
In einer Testumgebung den Import mit exakt derselben Auswahloption wie in der Pipeline ausführen.
Für Produktion einen vollständigen App-Import und einen klaren Rollback-Plan vorsehen.

Deployment-Dateien lösen keine Geheimnisverwaltung und ersetzen auch nicht die Freigabe des Zielschemas. Sie schaffen aber eine klarere Grenze: Die APEX-Anwendung bleibt als Quelle nachvollziehbar, während erlaubte Installationswerte pro Ziel kontrolliert überschrieben werden. Für Teams mit APEXlang in Git ist das eine praktische Grundlage, um Umgebungsunterschiede explizit und prüfbar zu machen.

Weiterführend: Oracles Dokumentation zu APEX 26.2 Neuerungen und APEXlang Deployment-Dateien.