Oracle Application Express Tipps für Entwicklung und ... - Trivadis

oracle 

applicaTion 

express 

Tipps fÜr enTWicklunG 

und BeTrieB 

Version 1.0

Oracle 

Application Express 

Tipps für Entwicklung und Betrieb 

Trivadis AG 

Dokument Version 1.0 

©2011 Trivadis AG

Vorwort 

Urban Lankes 

CEO Trivadis 

Carsten Czarski 

Leitender 

Systemberater 

Oracle 

Die hier entstandenen Richtlinien und Empfehlungen sind ein 

wertvoller Baustein für die effiziente Entwicklung von Applikationen 

mit Oracle Application Express. Je früher man Fehler findet, desto 

weniger Kosten entstehen später bei der Behebung. Deshalb sind 

klare Richtlinien und Vorgaben in der Entwicklung, basierend auf 

langjährigen Erfahrungen, besonders wertvoll. Unabhängig von der 

Grösse und der Bedeutung einer Applikation und unabhängig von 

der Anzahl der mitwirkenden Entwickler bin ich überzeugt, dass 

unsere Erfahrungen helfen, solche Fehler von Anfang an zu 

vermeiden und Kosten deutlich zu reduzieren. 

Seit 2003 ist APEX ein Bestandteil der Oracle Datenbank und 

erlaubt die schnelle und flexible Erstellung datenbankgestützter 

Web-Anwendungen. APEX ist inzwischen sehr populär: 1200 

registrierte Leser der deutschsprachigen APEX-Community im 

September 2011 und mehr als 20 Vorträge auf der DOAG 2011 

zeigen, dass man als APEX-Entwickler Teil einer grossen und 

lebhaften Community ist. 

Die hier vorliegenden APEX Tipps zeigen deutlich, was man vom 

Erfahrungsaustausch in der Community hat. Als Entwickler profitiert 

man von den Erfahrungen, die in praktischen Projekten gemacht 

wurden. Zudem vermeidet man typische Fehler und ist mit APEX 

noch produktiver. Daher wünsche ich viel Spass und neue 

Erkenntnisse bei der Lektüre und stets gutes Gelingen bei der 

Entwicklung mit APEX. 

Oracle Application Express Tipps für Entwicklung und Betrieb 2

Anja Zahn 

Consultant Trivadis 

Volker Strasser 

Senior Consultant 

Trivadis 

Ein Sprichwort sagt: „Erfahrungen sind billig zu haben doch viele 

wollen sie teuer bezahlen“ 

Die APEX Tipps sollen als Grundlage für die Sicherstellung von 

Qualität in Entwicklungsprojekten dienen und sie sollen helfen, 

bekannte Probleme zu vermeiden. 


Lizenz 

Geschützte Marken 

Alle Bezeichnungen, die dem Autor als geschützte Marken bekannt sind, wurden 

entsprechend gekennzeichnet. Alle Schutzrechte sind Eigentum der rechtmässigen 

Eigentümer. 

Haftungsausschluss 

Die Autoren und Herausgeber schliessen jegliche Haftung aus für eventuelle direkte oder 

indirekte Schäden, die aus der Nutzung oder Anwendung der aufgeführten Informationen 

entstehen. Die Informationen können Fehler enthalten und stellen ausschliesslich die 

unverbindliche Meinung des Autors dar. Die Autoren behalten sich das Recht vor, die 

Unterlagen ohne Benachrichtigung periodisch anzupassen, ohne jedoch Anspruch auf 

jederzeitige Aktualität der Informationen zu gewährleisten. 


Änderungshistorie 

Version Wer Datum Kommentar 

0.1 Volker Strasser 09.11.2010 Initiale Struktur Development 

0.2 Anja Zahn 03.01.2011 Überarbeitung, Erweiterung um Betrieb und 

Deployment 

0.3 Anja Zahn 11.03.2011 Umbau der Kapitelstruktur 

0.4 Anja Zahn 03.06.2011 Erweiterung 

0.5 Perry Pakull 04.07.2011 Formatierung 

0.6 Anja Zahn 11.08.2011 Übernahme Inhalte aus Originaldokument 

0.7 Anja Zahn 26.08.2011 Erweiterung/Kennzeichnung mit Grafiken 

0.8 Anja Zahn 01.09.2011 Finale Version 

0.9 Perry Pakull 08.09.2011 Review und Formatierung 

0.9 Anja Zahn 14.09.2011 Vorwort Carsten Czarski und eigenes eingefügt 

0.9 Perry Pakull 19.09.2011 Vorwort Urban Lankes 

1.0 Perry Pakull 29.09.2011 Version 1.0 

1.0 Perry Pakull 05.10.2011 Interner inhaltlicher Review 

1.0 Julian Chan 11.10.2011 Redaktionelle Korrekturen Rechtschreibung 

1.0 Perry Pakull 12.10.2011 Titel und letzte Änderungen 


Inhaltsverzeichnis 

Vorwort .................................................................................................................................. 2 

Lizenz ..................................................................................................................................... 4 

Geschützte Marken ......................................................................................................................................... 4 

Haftungsausschluss ........................................................................................................................................ 4 

Änderungshistorie ................................................................................................................ 5 

Inhaltsverzeichnis ................................................................................................................. 6 

Abbildungsverzeichnis ......................................................................................................... 8 

1 Einleitung ..................................................................................................................... 10 

1.1 Anwendungsbereich ..................................................................................................................... 10 

1.2 Konventionen im Dokument ..................................................................................................... 10 

1.2.1 Kurzbezeichnungen.................................................................................................................. 10 

1.2.2 Farben ........................................................................................................................................... 10 

1.2.3 Schlüsselworte ........................................................................................................................... 11 

1.2.4 Grafiken ........................................................................................................................................ 11 

2 Warum Standards und Richtlinien wichtig sind ....................................................... 12 

3 Systemlandschaft ........................................................................................................ 13 

3.1 Datenbank ........................................................................................................................................ 13 

3.2 Webserver und Application Server .......................................................................................... 13 

3.2.1 Embedded PL/SQL Gateway ................................................................................................. 13 

3.2.2 Oracle HTTP Server (Apache) mit konfiguriertem mod_plsql .................................. 14 

3.2.3 Application Server mit konfiguriertem APEX-Listener ................................................ 14 

3.3 Web-Browser ................................................................................................................................... 15 

3.4 Rollen und Aufgaben bei APEX ................................................................................................ 15 

4 Entwicklung .................................................................................................................. 17 

4.1 Konzepte ........................................................................................................................................... 17 

4.2 Das Fundament: die Datenmodellierung .............................................................................. 18 

4.3 Application Builder ........................................................................................................................ 20 

4.4 Reports ............................................................................................................................................... 27 

4.5 Formulare .......................................................................................................................................... 29 

4.6 Namenskonventionen für Elemente ....................................................................................... 31 

4.7 Pages, Items, Shared Components & Co. ............................................................................. 33 

5 Deployment .................................................................................................................. 43 

5.1 Deployment-Arten......................................................................................................................... 43 

5.2 Empfehlungen für das Deployment ........................................................................................ 45 

6 Betrieb .......................................................................................................................... 48 

6.1 Instanzen ........................................................................................................................................... 48 

6.2 Versionen .......................................................................................................................................... 49 

6.3 Workspace Design ......................................................................................................................... 49 


6.4 Security .............................................................................................................................................. 50 

6.5 Userverwaltung ............................................................................................................................... 51 

6.6 Accounting (Ressourcennutzung)............................................................................................ 56 

6.7 Monitoring........................................................................................................................................ 57 

7 Hilfsmittel und Tools ................................................................................................... 58 

Referenzen ........................................................................................................................... 64 


Abbildungsverzeichnis 

Abbildung 1 Schematischer Aufbau APEX und EPG ............................................................................. 13 

Abbildung 2 Schematischer Aufbau APEX und Oracle HTTP Server .............................................. 14 

Abbildung 3 Schematischer Aufbau APEX mit Application Server und APEX-Listener ........... 15 

Abbildung 4 Auswahl Applikationstypen.................................................................................................. 20 

Abbildung 5 CSS ins APEX-Repository hochladen ................................................................................ 24 

Abbildung 6 Bild-Verwaltung in APEX ....................................................................................................... 25 

Abbildung 7 Session State Protection Einstellungen ........................................................................... 25 

Abbildung 8 Anzeige der Versionsnummer in der Anwendung ...................................................... 27 

Abbildung 9 Features der Interactive Reports ........................................................................................ 28 

Abbildung 10 Beispiel einer Tabular Form ............................................................................................... 30 

Abbildung 11 Button Name darf nicht geändert werden .................................................................. 33 

Abbildung 12 Übersicht über die Pages und ihren Status ................................................................. 34 

Abbildung 13 Pagelock-Verwaltung ........................................................................................................... 34 

Abbildung 14 JavaScript ins APEX-Repository hochladen ................................................................. 36 

Abbildung 15 Beispiel für eine Page 0 mit Menu und Report .......................................................... 37 

Abbildung 16 Link als Navigation Bar Entry in der Anwendung in APEX 4 ................................. 38 

Abbildung 17 Feedbackbearbeitung in APEX ......................................................................................... 38 

Abbildung 18 Angabe des Items, das die Formatierung enthält ..................................................... 39 

Abbildung 19 Anlegen der Texte ................................................................................................................. 39 

Abbildung 20 Einstellungen auf Ebene der Komponenten ............................................................... 40 

Abbildung 21 Einstellungen für das XLIFF-File ....................................................................................... 40 

Abbildung 22 Create as copy from existing Item .................................................................................. 41 

Abbildung 23 Kopieren oder referenzieren? ........................................................................................... 41 

Abbildung 24 Dokumentation in der Anwendung................................................................................ 42 

Abbildung 26 Möglichkeiten des Exports über die APEX GUI .......................................................... 43 

Abbildung 27 Kontextmenü Application Express im SQL Developer ............................................. 44 

Abbildung 28 Überblick Supporting Objects in APEX ......................................................................... 46 

Abbildung 29 Applikation als run only importieren ............................................................................. 48 

Abbildung 30 Anmeldung am Workspace internal .............................................................................. 49 

Abbildung 31 Administration über den Workspace internal ............................................................ 50 

Abbildung 32 Anlegen der Authentifizierungsschemas ...................................................................... 50 

Abbildung 33 Autorisierungsschemas prüfen mittels Views ............................................................. 51 

Abbildung 34 User-Einstellungen ................................................................................................................ 52 

Abbildung 35 Konfiguration für LDAP-Anbindung ............................................................................... 54 

Abbildung 36 Page Sentry Function mit Package-Aufruf ................................................................... 55 

Abbildung 37 Session-Timeout .................................................................................................................... 55 

Abbildung 38 Account-Steuerung .............................................................................................................. 55 

Abbildung 39 SSL Verschlüsselung einstellen ........................................................................................ 56 

Abbildung 40 Ansicht Metriken im OEM .................................................................................................. 57 

Abbildung 41 Beispiel für die Auswirkungen der Ressourcenpriorisierung ................................ 57 

Abbildung 42 Features im Team Development ...................................................................................... 59 

Abbildung 43 Plug-In Verwaltung in APEX .............................................................................................. 59 

Abbildung 44 Optionen des APEX Advisor .............................................................................................. 60 

Abbildung 45 Zusätzliches Verzeichnis im SQL Developer für APEX ............................................. 61 


Abbildung 46 Anzeigemöglichkeiten auf Level Applikation ............................................................. 61 

Abbildung 47 Berichte auf Applikationsebene ....................................................................................... 61 

Abbildung 48 Berichte auf Seitenebene ................................................................................................... 61 

Abbildung 49 Oberfläche des Firebug ....................................................................................................... 62 

Abbildung 50 Applikationsvergleich innerhalb APEX .......................................................................... 63 

Abbildung 51 Auf Seitenebene verfügbare Utilities ............................................................................. 63 


1 Einleitung 

1.1 Anwendungsbereich 

Dieses Dokument dient dem PL/SQL-erfahrenen Entwickler 

� als Einstieg in die Entwicklung mit APEX 

� als Übersicht über die Konventionen, die generell für APEX und die damit erstellten 

Anwendungen gelten 

� zur Vorbereitung auf typische Stolperfallen (und deren Vermeidung) 

1.2 Konventionen im Dokument 

1.2.1 Kurzbezeichnungen 

Innerhalb dieses Dokuments werden folgende Kurzbezeichnungen verwendet: 

Kurzbezeichnung Beschreibung 

AB Application Builder 

Apache Apache HTTP Server ist ein Produkt der Apache Software Foundation 

APEX Oracle Application Express 

CI Corporate Identity 

DB Datenbank 

DDL Data Definition Language 

DML Data Manipulation Language 

EPG Embedded PL/SQL Gateway 

LOV List of Value 

OEM Oracle Enterprise Manager 

SSO Single Sign-on 

UI User Interface 

WS Workspace 

1.2.2 Farben 

Farblich markierter Text hat folgende Bedeutungen: 

Farbe Bedeutung 

BLAU APEX Begriffe und Schlüsselworte sind blau markiert 

FETT Wichtige Begriffe sind fett markiert 


1.2.3 Schlüsselworte 

Folgende Schlüsselworte bewerten die Wichtigkeit der Richtlinien und Empfehlungen: 

Schlüsselwort Bedeutung 

Immer Diese Regel ist zwingend einzuhalten 

Nie Diese Aktion darf nicht stattfinden 

Sollte nicht Diese Aktion sollte nicht stattfinden 

Vermeiden Diese Aktion sollte wann immer möglich unterlassen werden, es kann aber 

berechtigte Ausnahmen geben 

Versuchen Regel oder Empfehlung, die wann immer möglich und passend 

angewendet werden sollte 

Beispiel Veranschaulichung einer Regel oder Empfehlung 

Grund Erklärt den Gedanken bzw. die Absicht hinter der Regel oder Empfehlung 

1.2.4 Grafiken 

Folgende Grafiken kategorisieren und bewerten die Richtlinien und Empfehlungen: 

Grafik Bedeutung 

Information 

Vorsicht 

Performance relevant 

Wartbarkeit 

Lesbarkeit 


2 Warum Standards und 

Richtlinien wichtig sind 

Um Projekte mit mehreren beteiligten Personen in einem definierten Rahmen zu halten 

und die Arbeit für alle einfacher und nachvollziehbarer zu machen, müssen Standards und 

Richtlinien definiert werden, an die sich die Projektmitglieder halten müssen. Werden für 

solche Projekte keine derartigen Strukturen geschaffen, gibt es: 

� Probleme in der Kommunikation durch unterschiedliches Verständnis innerhalb des 

Projektteams 

� Technische Probleme durch unterschiedliche Verfahrensweisen in der Umsetzung 

� Probleme bei der Wartung durch Dritte 

Dieses Dokument liefert einen allgemeinen Grundstock dieser Standards und Richtlinien, 

die aber für einzelne Projekte erweitert bzw. verringert werden können. 


3 Systemlandschaft 

3.1 Datenbank 

Oracle Application Express ist ein Webentwicklungstool und Bestandteil einer Oracle 

Datenbank. Die Datenbankversion sollte nicht älter als Oracle 9i sein. Prinzipiell ist APEX 

mit allen Datenbankversionen ab 9i kompatibel, jedoch ist das Embedded PL/SQL Gateway 

erst mit Version 11g verwendbar. 

3.2 Webserver und Application Server 

Es gibt drei Arten APEX zu betreiben: 

� Embedded PL/SQL Gateway 

� Oracle HTTP Server (Apache) mit konfiguriertem mod_plsql 

� Application Server mit konfiguriertem APEX-Listener 

3.2.1 Embedded PL/SQL Gateway 

Bei dieser Variante werden HTTP Anfragen durch den Oracle XML DB Listener verarbeitet. 

Dieser Listener ist der Oracle Net Listener, welcher Oracle Net Services, HTTP und FTP 

unterstützt. Der Listener kann in ausreichendem Masse optimiert werden. 

Vorteile: 

� Schnell einsatzbereit, geringe Konfiguration nötig 

Nachteile: 

� Nicht für grössere Netzwerke geeignet, da z. B. kein Rewrite („Umschreiben“ von URLs, 

um z. B. an den Webserver gerichtete Anfragen intern umzuschreiben oder extern 

weiterzuleiten) eingesetzt werden kann 

Abbildung 1 Schematischer Aufbau APEX und EPG 


3.2.2 Oracle HTTP Server (Apache) mit konfiguriertem mod_plsql 

Dies ist die älteste Version, bei der der Apache eingesetzt wird und über das Modul 

mod_plsql die DB-Zugriffe geregelt werden. 

Vorteile: 

� Rewrite, Proxy etc. möglich, daher für grössere Netzwerke geeignet 

� Weitreichende Konfigurationsmöglichkeiten für Security Anforderungen 

� Häufig eingesetzte und bewährte Variante, dadurch sind viele Erfahrungen im Internet 

verfügbar 

Nachteile: 

� Mehr Konfigurationsaufwand 

Abbildung 2 Schematischer Aufbau APEX und Oracle HTTP Server 

3.2.3 Application Server mit konfiguriertem APEX-Listener 

Mit der neuesten Version können verschiedene Application Server in Betrieb genommen 

werden, da sich der APEX-Listener durch seine Java-Basis in vielen Servern einsetzen lässt. 

Zu den Application Servern gehören: 

� Oracle WebLogic Server 

� Oracle GlassFish Server 

� OC4J 

Vorteile: 

� Rewrite, Proxy etc. möglich, daher für grössere Netzwerke geeignet 

Nachteile: 

� Noch nicht ausreichend getestet, mehr Konfigurationsaufwand 


Abbildung 3 Schematischer Aufbau APEX mit Application Server und APEX-Listener 

3.3 Web-Browser 

APEX ist webbasiert. Es sollten deshalb die neuesten Versionen von Firefox oder Internet 

Explorer im Einsatz sein. Prinzipiell sollte aber mit einer grösseren Anzahl von Browsern 

getestet werden, wenn die Anwendung im Intranet oder Internet verfügbar ist. 

Um Flash Charts und Flash Maps darstellen zu können, sollte auch immer der aktuellste 

Flash-Player installiert sein. 

3.4 Rollen und Aufgaben bei APEX 

Aufgaben eines Datenbankadministrators 

Der DBA sollte nur das Grundgerüst (das Schema und den Workspace) für die Verwendung 

von APEX stellen. Alles andere sollte in den Händen des Entwicklers liegen. 

Technologische Schwerpunkte eines Entwicklers 

APEX vereint viele verschiedene Technologien, die zur Erstellung einer Anwendung 

verwendet werden können. Nachfolgend eine Übersicht der Schwerpunkte, die ein APEX- 

Entwickler abdecken sollte: 

� Ein APEX-Entwickler muss mit den Möglichkeiten, Funktionsweisen und auch 

Eigenheiten von APEX vertraut sein. Empfehlenswert ist es, die Oracle Application 

Express Community oder auch die APEX Blogs zu verfolgen. Praktische Erfahrung im 

Umgang mit APEX ist aber durch nichts zu ersetzen! 

� Bei komplexeren Datenbank Applikationen, ist es unabdingbar, dass der Entwickler SQL 

und PL/SQL beherrscht, um die gestellten Anforderungen an Funktionalität und 

Geschäftslogik umsetzen zu können. Durch den Query Builder in den APEX Wizards ist 


es auch Anwendern ohne spezifische SQL-Kenntnisse möglich, Berichte und Formulare 

zu erstellen. 

� CSS und HTML Kenntnisse werden dann benötigt, wenn Themes bzw. Templates in 

APEX angepasst werden müssen, um sie an die Corporate Identity (CI) anzupassen. 

Grundlegende HTML-Kenntnisse sind erforderlich, wenn z. B. ein Item oder eine Region 

anders positioniert werden soll. Gleiches gilt für Items, Labels oder Werte, die einen 

speziellen Font erhalten sollen. Daher ist es empfehlenswert, auch diese Technologien 

zu beherrschen. 

� APEX verwendet intern sehr viel JavaScript bzw. jQuery als Framework für JavaScript. 

Für die Versionen vor 4.0 ist es sehr vorteilhaft, Kenntnisse in diesem Bereich zu haben, 

um z. B. Werte von Formularfeldern zu überprüfen, ohne die komplette Seite 

aktualisieren zu müssen. APEX bietet ab Version 4.0 Dynamic Actions an, die es 

ermöglichen, client-seitige Funktionen deklarativ zu definieren. Dadurch wird ein 

Grossteil der benötigten JavaScript Funktionen abgedeckt. 

User 

Der User nimmt bei der Bestimmung der Anforderungen an einer Anwendung eine 

wichtige Rolle ein. Hier sollte entsprechend durch den Entwickler beraten werden, was 

möglich ist und wie gewünschte Anforderungen sinnvoll umgesetzt werden können. Ein 

Anwender sollte die entsprechende fachliche Kompetenz für die Bedienung der 

Anwendung mitbringen und mittels einer Schulung auf die Arbeit mit der Anwendung 

vorbereitet werden. 


4 Entwicklung 

4.1 Konzepte 

Entwicklung lokal oder zentral 

Ein Entwickler kann die Oracle Datenbank und Oracle Application Express lokal 

auf seinem Rechner installieren und verwenden. Dies sollte jedoch nur gemacht 

werden, wenn völlig autark gearbeitet werden kann und keine weiteren Entwickler 

an der Erstellung der Applikation beteiligt sind. 

Die zentrale Variante sollte der Standard sein. Dabei installiert ein Administrator 

die Software auf einem Server und die Mitarbeiter des Unternehmens können mit 

den vom Administrator vergebenen Berechtigungen das Werkzeug gemeinsam 

nutzen. In diesem zentralen Verwaltungsszenario ist nur ein Browser auf den 

Entwicklerrechnern erforderlich. 

Einsatz SQL und PL/SQL 

Innerhalb von SQL-Abfragen kann mit Oracle-spezifischen Funktionen gearbeitet 

werden, da APEX ohnehin an Oracle gebunden ist. Bei der GUI-Entwicklung mit 

APEX ist es möglich, PL/SQL Code direkt auszuführen. Aus Gründen der 

Wartbarkeit und Modularisierung ist allerdings zu empfehlen, dass Geschäftslogik 

stets innerhalb von Packages, durch Funktionen oder Prozeduren, realisiert und 

somit in die Datenbank ausgelagert werden. Sofern PL/SQL in der Oberfläche 

verwendet werden muss, sollte dies soweit wie möglich nur über Aufrufe von 

Funktionen und Prozeduren erfolgen. 

Die PL/SQL und SQL Coding Guidelines von Trivadis beinhalten Standards, Best 

Practices, Empfehlungen und Beispiele für den richtigen Einsatz von PL/SQL und 

SQL in Projekten. Die Namenskonventionen für Datenbankobjekte und für PL/SQL 

Variablen in diesem Dokument sind auch für APEX Anwendungen relevant. 

� Trivadis PL/SQL und SQL Coding Guidelines 

http://www.trivadis.com/PLSQL-Guidelines 


4.2 Das Fundament: die Datenmodellierung 

Primärschlüssel für Tabellen 

Alle Tabellen, die in APEX Insert/Update/Delete erfahren, sollten einen 

Primärschlüssel haben. Dieser Primärschlüssel sollte ein künstlicher Schlüssel sein, 

der idealerweise über einen Before Insert or Update Trigger aus der 

zugehörigen Sequence gezogen wird. Die Eindeutigkeit der Datensätze bzw. 

bestimmter Attribute kann dann über einen Unique Constraint sichergestellt 

werden. 

Bis Version 4.0.x sollten Primärschlüssel für Tabellen maximal zwei Attribute 

beinhalten. 

Grund: 

� In den APEX Wizards können nur zwei Attribute für einen Primärschlüssel 

angegeben werden 

� Die Standard DML Operationen können sonst nicht genutzt werden 

� Ab Version 4.1 wird als Standardeinstellung die ROWID vorgeschlagen, um 

Datensätze in DML Operationen eindeutig zu identifizieren. Dadurch können 

die Standard DML Operationen auch für Tabellen mit einem Primärschlüssel, 

der mehr als zwei Attribute besitzt, eingesetzt werden! 

Public Objekte 

Es sollten keine Public Objekte wie z. B. Synonyme verwendet werden. 


� Die Applikation kann dann nicht mehr als abgeschlossene Einheit angesehen 

werden 

� Es können Konflikte mit anderen Objekten auf DB Ebene entstehen 

Datenbanklinks 

Bei der Verwendung von Datenbanklinks sollte für jede Zieltabelle oder Zielview 

eine View im Parsing Schema angelegt werden. 


� Die Wizards innerhalb APEX können diese Datenquelle sonst nicht erkennen 

Performance Verschlechterungen, welche hier eventuell auftreten, können mit 

Snapshots umgangen werden! 


Auditing Attribute 

Jede Tabelle sollte Attribute besitzen, die pro Datensatz den Ersteller mit 

Erstelldatum und den Editor mit Editdatum ausweisen. Das Füllen dieser vier 

Spalten sollte über Before-Insert-Update-Trigger bewerkstelligt werden. 


� Änderungen an Daten können so einfacher nachvollzogen werden 

� Der Audit passiert direkt in der Datenbank und muss nicht in der Anwendung 

berücksichtigt werden 

Geschäftslogik von Visualisierung trennen 

Geschäftslogik und Berechnungen sollten unbedingt in der Datenbank, innerhalb 

von Views, Triggers, Packages, Prozeduren und Funktionen, realisiert werden. 

Wenn der PL/SQL Code keine GUI-Elemente enthält, kann er ohnehin vollständig 

in die DB ausgelagert werden. Generell sollte so viel Geschäftslogik wie möglich in 

die DB ausgelagert bzw. so wenig PL/SQL Code wie möglich in APEX hinterlassen 

werden. Es sollten lediglich die für die Visualisierung notwendigen SQL Befehle 

und Funktions- bzw. Prozeduraufrufe in der APEX Entwicklungsumgebung 

gehalten werden. 


� Klassischer Ansatz der Software Entwicklung 

� Einfacheres Debugging und Ressourcenkontrolle möglich 

� Mehrfachverwendung von Code möglich (Modularisierung) 

View-Schicht statt direkter Tabellenzugriff 

Um einerseits die Vorteile der Wizard-getriebenen Entwicklung zu nutzen und 

andererseits ein hohes Mass an Kontrolle über die DML Transaktionen zu 

behalten, sollten sämtliche APEX-Formulare, in denen DML Operationen (Insert, 

Update, Delete) vorkommen, ausschliesslich über Views auf die Daten zugreifen. 

Die Implementierung der DML-Logik kann bei Bedarf (komplexe Views, komplexe 

Updates etc.) in Instead-Of-Trigger verlagert werden. Diese Vorgehensweise ist 

selbst dann empfehlenswert, wenn das APEX-Formular direkt nur auf eine einzige 

View zugreift. 


Berechtigungen 

Berechtigungen müssen direkt an das Workspace-Schema vergeben werden und 

dürfen nicht über eine Rolle erteilt werden. Wenn dies dennoch geschieht, wird 

ein SQL-Report, welcher auf ein solches Objekt zugreift, den Fehler „Objekt nicht 

gefunden“ liefern. 


� Das Konzept Grant to user funktioniert nicht mit APEX 

4.3 Application Builder 

Welchen Applikationstyp nehme ich für meine Applikation? 

Der Application Builder Assistent in der folgenden Abbildung bietet zwei 

unterschiedliche Applikationstypen an. 

Abbildung 4 Auswahl Applikationstypen 

Bei einer Database Applikation steht dem Entwickler der volle Umfang an 

Funktionalitäten zur Verfügung, die APEX oder die integrierten 

Programmiersprachen oder Frameworks wie PL/SQL oder jQuery bieten. Um dem 

Entwickler beim Einbinden von eigenem Code viele Freiheiten zu lassen, bietet 

APEX an unzähligen Stellen innerhalb des Application Builders die Möglichkeit 

dazu. Daher sollten diese Anwendungen auch ausschliesslich von Entwicklern mit 

entsprechendem Know-how erstellt werden. 

Websheet Applikationen können im Gegensatz zu den Database Applikationen 

auch ohne Kenntnisse im Bereich SQL und PL/SQL erstellt werden. Diese Art der 

Anwendung ist beispielsweise als Portal für eine bestimmte Fachabteilung nutzbar 

und sollte ebenso durch einen Anwender aus der Fachabteilung erstellt werden. 

Hier können Daten aus Excel kopiert und veröffentlicht werden. Falls gewünscht, 

können sie auch bearbeitet werden. Es werden dazu Berichte, Formulare, HTML- 

Editoren, Diagramme oder auch Data Grids zur Verfügung gestellt. Die Daten 


werden in durch APEX verwalteten Tabellen gespeichert. Deshalb müssen diese 

auch bei Übernahme der Daten in einen anderen Datenbestand abgefragt 

werden, was wiederum einen SQL-Entwickler erfordert. 

Unterschiede zwischen Big Apps und Partitioned Apps 

Big Apps sind Applikationen, die aus vielen Seiten bestehen. Partitioned Apps sind 

Applikationen, die in mehrere kleine APEX Anwendungen aufgeteilt sind. Die 

Entscheidung, ob Big oder Partitioned gewählt werden, muss je nach Projekt in 

Abhängigkeit der Komplexität, Funktionalität und Anforderungen getroffen 

werden. Bei Big Apps können pro Applikation mehre Oracle Schemas (Parsing 

Schemas) zugeordnet werden, da hier häufig auch Daten aus mehreren Quellen 

bezogen werden müssen. Bei Partitioned Apps sollte jedoch pro Modul (also pro 

App) nur ein Oracle Schema (Parsing Schema) verwendet werden. Diese 

Bedingung könnte sogar dazu dienen, eine Big App in eine Partitioned App und 

somit in Module zu überführen. 

Big Apps 

Vorteile 

� Verzweigungen innerhalb der Applikation 

� Nur eine Anmeldemaske (kein Single Sign-on notwendig) 

Nachteile 

� Deployment von einzelnen Modulen fast nicht möglich 

� Keine modulare Versionierung 

� Potentiell wieder verwendbare Module können nicht wieder verwendet 

werden 

Partitioned Apps 

Vorteile 

� Modulares Deployment möglich 

� Modulare Versionierung möglich 

� Einfacheres Entwickeln in grösseren Entwicklungsteams 

Nachteile 

� Single Sign-on notwendig, da sonst pro Applikation ein Anmeldedialog 

erscheint 


Nummernkreise für Seiten und Anwendungen 

Für Anwendungen sollten Nummernkreise verwendet und konstant über Test und 

Produktion beibehalten werden. Für Seiten sollten ebenfalls Nummernkreise 

verwendet werden und den Seiten sollten zudem Seitengruppen zugwiesen 

werden. 

Beispiel: 

Seitengruppe Nummernkreis 

Stammdaten 1000-1999 

LookUPdaten 2000-3999 

Bewegungsdaten 4000-… 

Die Zusammengehörigkeit von Query Screen, Result List Screen und Detail Screen 

kann nach folgendem Prinzip umgesetzt werden: 

Seitengruppe Seite Nummer 

Dialog 70 Query Screen 1 Page 700 

List Screen 1 Page 701 

Detail Screen 1 Page 702 

Dialog 71 Query Screen 2 Page 710 


List Screen 2 Page 711 

Detail Screen 2 Page 712 

� Erkennbarkeit der fachlichen bzw. technischen Zuordnung der Seite 

� Einheitliches Gerüst für die Nummerierung 

Es sollte für eine Anwendung eine feste Anwendungs-ID pro APEX-Instanz 

verwendet werden. 


� Die Anwendungs-ID für übersetzte Anwendungen darf nicht verändert 

werden, da sonst die Übersetzung verloren geht 

� Personalisierte, interaktive Reports bleiben beim Import nur erhalten, wenn 

die Anwendungs-ID gleich bleibt 


Alias 

Vorsicht bei der Vergabe von Aliasen, die sowohl auf Anwendungsebene als auch 

auf Seitenebene vergeben werden können. 


� Einen Alias kann es pro APEX-Instanz nur einmal geben! 

Themes und Templates 

Um Anpassungen am Layout vorzunehmen, sollte immer ein eigenes Theme 

angelegt und mit einem Präfix entsprechend gekennzeichnet werden. Das Theme 

sollte jedoch eine Kopie eines bestehenden APEX-Themes sein. Dieses Theme 

muss mit der Applikation ausgeliefert werden. 


� Die Kompatibilität wird bewahrt 

� Wechsel zwischen dem eigenen und einem APEX-Theme ist möglich 

Änderungen am Layout in einzelnen Seiten sollten vermieden werden. 


� Sie sind schwierig zu debuggen 

� Sie können bei zusätzlichen Änderungen im zentralen Theme (CI Theme) zu 

Problemen führen 

Zusätzliche oder überschriebene Styles sollten in einem applikationsspezifischen 

CSS untergebracht werden und dann im APEX-Repository gespeichert werden. 

Dies kann unter Shared Components � Files � Cascading Style Sheets gemacht 

werden. 


� Der Entwickler hat somit immer einen Zugriff und muss nicht den 

Administrator kontaktieren 


Abbildung 5 CSS ins APEX-Repository hochladen 

UI Defaults (User Interface) 

Die UI Defaults können genutzt werden, damit beim Aufrufen der gleichen 

Tabellen und Views die entsprechenden Spalten immer in der gleichen Art und 

Weise angezeigt werden. Hier können Symbole wie z. B. das Editier-Icon für die 

gesamte Applikation (oder sogar Workspace) festgelegt werden. 


� Höherer Automatisierungsgrad und geringere Nacharbeitung notwendig 

Ablage von Bildern 

Bilder, die innerhalb der Applikation verwendet werden wie z. B. Buttons, Logos, 

etc. sollten immer auch in der Applikation als Shared Component abgelegt 

werden. 

Bei Applikationen wie z. B. Produktkatalogen sollten die Bilder der Produkte in 

BLOBS von Tabellen hinterlegt werden. 


� Das Deployment wird einfacher, da die ganze Visualisierungsschicht über den 

APEX-Export/Import gemacht werden kann 

� Es gibt keine Dateien, die auf eine andere Weise vom Filesystem gesichert 

werden müssen 


Abbildung 6 Bild-Verwaltung in APEX 

Security bei der Entwicklung 

Das Feature „Schutz für den Sessionzustand“ sollte generell aktiviert sein. Pro 

Seite sollte das Attribut Schutz für den Sessionzustand auf Argumente müssen 

Prüfsumme haben gesetzt werden. Es empfiehlt sich, als Mindestanforderung 

dieses Attribut für jedes Element auf Prüfsumme erforderlich auf Sessionebene zu 

konfigurieren. 

Abbildung 7 Session State Protection Einstellungen 

Selbsterstellte URLs erhalten dank der Prozedur apex_util.prepare_url automatisch 

eine Prüfsumme: 

apex_util.prepare_url 

( p_url => 'f?p= ' || :APP_ID || ':15:' || :APP_SESSION || '::NO::P1_X:foo 

); 


� Automatische Überprüfung der URL mittels Checksum 


� Es ist bei einem APEX Projekt oftmals nicht abzusehen, wie wichtig die 

Anwendung später sein wird und wie kritisch sie betrieben wird 

� Session State Protection nachträglich einzubauen ist mit viel Aufwand 

verbunden 

Alle Texte, die an den Browser zurückgegeben werden, sollten escaped werden, 

damit eventuell enthaltener JavaScript-Code nicht durch den Browser interpretiert 

wird. Dazu können Sie die Formularelemente vom Typ “Nur Anzeigen” durch den 

Typ “Nur Anzeigen (Escape bei Sonderzeichen, hat keinen Speicherstatus)” 

ersetzen. 

Wenn eine PL/SQL-Prozedur mit htp.p einen Text an den Browser zurückgibt, , 

sollte das wie folgt umgesetzt werden: 

htp.p(htf.escape_sc(v('SOME_ITEM'))); 

Nach der Erstellung sind alle Spalten in einem tabellarischen Formular auf 

„Standard Spalte“ gesetzt. Auch hier ist die Einstellung Display as text (escape 

special characters) zu wählen. 


� Schutz vor den sogenannten Cross-Site-Scripting-Attacken (XSS) 

Alle Elemente vom Typ Passwort sollten nicht in der Benutzersession gespeichert 

werden. Dazu sollte ein Passwortfeld vom Typ Kennwort (Zustand wird nicht 

gespeichert) verwendet werden. Alle Elementwerte sollten verschlüsselt in der 

Benutzersession gespeichert werden. Dazu wird das Elementattribut Wert 

verschlüsselt in Sessionzustand speichern auf "Ja" gesetzt. 


� Die Werte der Elemente können ausserhalb APEX so nicht ausgelesen werden 

Es sollte in der folgenden Reihenfolge auf Elementwerte zugegriffen werden: 

1. :MY_ITEM (kann in APEX verwendet werden) 

2. v('MY_ITEM') (kann in der Datenbank verwendet werden) 

Nur wenn die obengenannten Zugriffsarten nicht funktionieren, ist die Notation 

&MY_ITEM. bei unkritischen Daten erlaubt. 


� Schutz gegen SQL-Injection 


Versionsnummerierung 

In der APEX Applikation Definition sollte das Feld Version gefüllt sein. 


� So ist auch innerhalb der Applikation erkennbar, mit welchem Stand gerade 

gearbeitet wird 

Versionsnummer: 1.2.3.4.5 

� 1. Stelle � Major Release (Architekturumstellung, neue Funktionalitäten, APEX 

Code- und Schemaänderungen) 

� 2. Stelle � Minor Release (Neue Funktionalitäten, APEX Code- und 

Schemaänderungen) 

� 3. Stelle � Service Pack (APEX Code- und Schemaänderungen) 

� 4. Stelle � FixPack APEX ( Nur APEX Codeänderungen) 

� 5. Stelle � FixPack Schema (Nur Schemaänderungen) 

Abbildung 8 Anzeige der Versionsnummer in der Anwendung 

4.4 Reports 

SQL Reports 

SQL Reports sollten für dynamische Anzeigen verwendet werden, die vom 

Benutzer aber nicht geändert werden sollen. 


� Einfach zu implementierende Standardfunktionalität 

Interactive Reports 

Für flexible Reporting Anforderungen sollten Interactive Reports immer eingesetzt 

werden! 


� Hohe Flexibilität in der Visualisierung (Filtern, Gruppieren, Suchen, 

Highlighting,…) 


� Nicht gewollte Funktionen können gesperrt werden 

� Konfigurierte Reports eines Users können mit anderen Usern geteilt werden 

(sie können sogar exportiert/importiert werden) 

� Verlinkung auf Einzeldatensatz ist Standard 

Abbildung 9 Features der Interactive Reports 


Auditing Attribute sollten in einem Interactive Report zur Auswahl angeboten, 

aber nicht standardmässig angezeigt werden. 


� So werden grössere Berichte lesbarer, da sie nur relevante Informationen 

bieten 

Spaltenüberschriften 

Den Heading Type der Spalten eines Reports grundsätzlich auf Custom, wenn 

nötig auch PL/SQL oder None stellen. 


� Die fixe Spaltenüberschrift wird nicht im Übersetzungsrepository (XLIFF) 

berücksichtigt (siehe Mehrsprachige Applikationen) 


4.5 Formulare 

Formulare mit automatischen Prozessen 

Hierbei werden die APEX-Standard-Prozesse genutzt, um DML Operationen 

durchzuführen. Diese sollten für Dialoge verwendet werden, die nur Standard- 

Funktionalität auf eine Tabelle und wenig Geschäftslogik benötigen. 


� Auf eine Tabelle beschränkt 

� Nur ein Formular pro Seite möglich 

� Fehlermeldungen sind schwer nachvollziehbar 

� Änderungen sind aufwändiger 

� Grundsatz Trennung von Logik zu Visualisierung verletzt 

Formulare mit eigenen Prozessen 

Insert, Update und Delete Prozesse, die über die APEX-GUI ausgeführt werden, 

sollten immer über entsprechende Prozeduren in einem Package erfolgen. 


� Mehrere Datenbankobjekte können angesprochen werden 

� Höhere Flexibilität bezüglich der Datenverteilung in der Datenbank 

� Error Handling ist einfacher zu implementieren, da hier die komplette 

Kontrolle über die DML Operationen gegeben ist 

� In der Prozedur können nachträgliche Änderungen einfacher erfolgen 

� Teile der Geschäftslogik werden in die Datenbank ausgelagert und nicht in der 

APEX Applikation selbst gehalten 

Tabular Forms 

Tabular Forms sollten wie Formulare mit automatischen Prozessen für Dialoge 

verwendet werden, die nur Standard-Funktionalität auf eine Tabelle und wenig 

Geschäftslogik benötigen. Empfehlung: Interactive Reports mit Formular anstatt 

Tabular Form verwenden. 


� Unkontrolliertes Updateverhalten 

� Validierungen sind nur mit viel Aufwand zu erreichen 

� Verbesserungen in APEX 4, jedoch noch nicht ausreichend für viele 

Anforderungen 


Abbildung 10 Beispiel einer Tabular Form 

Mit APEX 4.1 gibt es erhebliche Verbesserungen im Bereich Tabular Forms. Dazu 

zählen die erweiterten Validierungsmöglichkeiten, besseres Error-Handling und 

das Auslesen der Werte mittels Bind-Variable. 

Beispiel Bind-Variable: 

ALT (vor 4.1): 

for i in 1 .. apex_application.g_f01.count --ID 

loop 

update my_table 

set my_column = apex_application.g_f02(i) 

where id = apex_application.g_f01(i); 

end loop; 

NEU (mit 4.1): 

update my_table 

set my_column = :MY_COLUMN-- MY_COLUMN 

where id = :ID 

Wenn Tabular Forms verwendet werden, empfiehlt es sich, das Updateverhalten 

über eigene PL/SQL Packages oder Views und Instead-of-Trigger zu 

kontrollieren. 


� Bessere Wartbarkeit der Anwendung, da die Logik in der Datenbank liegt 

Master Detail Reports 

Auch bei diesem Report lautet die Empfehlung, als Detail-Report nicht das 

Tabular Form zu verwenden, sondern eine neue Formular-Seite. 


� Unkontrolliertes Updateverhalten in Bezug auf die Reihenfolge der 

Transaktionen 

� Validierungen sind nur mit viel Aufwand zu erreichen 

� Verbesserungen in APEX 4, jedoch noch nicht ausreichend für viele 

Anforderungen 


Besteht für den Master-Detail eine Fremdschlüsselverbindung, darf beim Löschen 

des Masters nicht vergessen werden, dass die Details mitgelöscht werden müssen 

oder zu mindestens der Fremdschlüssel auf NULL gesetzt werden muss. Dies kann 

entweder über einen Trigger oder über einen Fremdschlüssel mit ON DELETE 

CASCADE bzw. ON DELETE SET NULL umgesetzt werden. 


� APEX hält eine solche Funktionalität nicht bereit 

� Kann zu Fehlermeldungen führen, wenn hier nicht nachgearbeitet wird 


Auditing Attribute, die automatisch über Datenbank Trigger gesetzt werden, 

sollten in einem Formular nur als read-only Felder angezeigt werden. 


� So werden die Formulare übersichtlicher 

� Es wird klarer, dass diese Felder nicht bearbeitet werden müssen 

4.6 Namenskonventionen für Elemente 

Seiten-Elemente (Variablen, Prozesse, Berechnungen, Validierungen) 

Die Namen von Seitenobjekten, die APEX bei Verwendung von Assistenten 

generiert hat, sollten im Nachhinein nicht geändert werden. 


� Bei der Vielzahl von originalen und nachträglich hinzugefügten Objekten, die 

sich gemischt in einer Seite befinden, kann man so die automatisch erzeugten 

besser von den hinzugefügten Objekten unterscheiden 

� Daraus lassen sich Rückschlüsse auf deren jeweilige Funktionalität ziehen 

Berichte sollten im Plural und Formulare im Singular benannt werden! 

Beispiel für einen Bericht: 

� BESTELLUNGEN 

Beispiel für ein Formular: 

� BESTELLUNG 


Items, die lediglich auf einer bestimmten Seite vorkommen, sollten (genau 

wie die von APEX automatisch erzeugten Items) der folgenden 

Namenskonvention entsprechen: 

� P_ITEMNAME 

Beispiel für ein Item: 

� P4711_ARTIKELNUMMER 

Schaltflächen werden so benannt, wie der Request, den sie abgeben, jedoch 

ohne Seiten-Präfix. 

Beispiel für eine Schaltfläche: 

� ARTIKEL_BESTELLEN 

Prozesse sollten typischerweise so heissen wie der Request, auf den sie reagieren 

und ebenfalls ohne Seiten-Präfix sein. (Da Prozesse jedoch auch auf mehrere 

Requests reagieren können, lässt sich allein aus dem Namen noch keine 

vollständige Aussage über die Arbeitsweise ableiten. In diesem Fall ist ggf. ein 

anderer, aussagekräftiger Name zu wählen). 

Beispiel für einen Prozess: 

� ARTIKEL_BESTELLEN 

Applikations-Elemente (Variablen, Prozesse, Berechnungen, 

Validierungen) 

Für anwendungsweit gültige Items, Prozesse, etc. sollte das Präfix A_ (für 

Applikation/Anwendung) verwendet werden. 

Die Anwendungs-ID, welche APEX zunächst zur Benennung vorschlägt, ist kein 

robuster Ansatz und sollte entfernt werden 


� Die Applikations-ID kann sich ändern und dann würden die Zusammenhänge 

verloren gehen. 

Namenskonvention: 

� A_ELEMENTNAME 


Beispiel für ein Anwendungs-Item: 

� A_JAHR 

Beispiel für einen Anwendungs-Prozess: 

� A_ARTIKEL_BESTELLEN 

Benennung von Schaltflächen 

Bei durch Wizards generierten Schaltflächen dürfen die Namen (Button Name) 

nicht umbenannt werden. Bei solchen Schaltflächen darf nur das Label (Text 

Label/Alt) geändert werden. 

Abbildung 11 Button Name darf nicht geändert werden 


� Beim Verwenden der Wizards nutzt APEX die Namen von Schaltflächen als 

Wert für den Anwendungs-Request. Auf diesen Request-Wert (in der 

deutschen Entwicklungsumgebung: "Anforderung") reagieren Prozesse, die 

beispielsweise Berechnungen oder DML-Befehle durchführen. Würde sich der 

Request (durch Umbenennen des Buttons) ändern, müsste man die Prozesse 

ebenfalls ändern. 

4.7 Pages, Items, Shared Components & Co. 

Pagelock während der Entwicklung 

Bevor ein Entwickler an einer Seite arbeitet, sollte er darauf einen Pagelock setzen. 


� Damit werden Konflikte vermieden, falls zwei Entwickler an derselben Seite 

arbeiten 


� Der Projektmanager weiss, an welcher Seite momentan gearbeitet wird 

Abbildung 12 Übersicht über die Pages und ihren Status 

Abbildung 13 Pagelock-Verwaltung 

Kommentare und Beschreibungen 

APEX stellt für alle Items Kommentarfelder zur Verfügung. In diese Felder sollte 

der Entwickler unbedingt die notwendigen Informationen schreiben. 


� Dokumentation ist ein „Must Have“, da die Abläufe in APEX-Formularen sehr 

frei gestaltbar sind und pro Seite eine Vielzahl an Objekten existieren kann, 

deren Zweck durchaus nicht selbsterklärend ist 

� Die Kommentarfelder können per SQL ausgewertet und als 

Gesamtdokumentation verwendet werden 

Hilfetexte für den Anwender 

In der Anwendung sollte in Items und Seiten der Hilfetext gefüllt werden. Das 

Gleiche gilt für die Rückmeldungen (Error- und Erfolgsmeldungen) von Prozessen 

und Validierungen. Es ist durchaus empfehlenswert, die von APEX vorgegebenen 

Fehlermeldungen ("Hinzufügen von Zeile nicht möglich") durch spezifischere, 

fachlich aussagekräftigere Versionen zu ersetzen. 



� So wird dem Anwender die grösstmögliche Hilfestellung geboten, um mit der 

Anwendung arbeiten zu können 

� Verständliche und konkrete Fehlermeldungen erhöhen die Akzeptanz des 

Anwenders gegenüber der Anwendung 

� Der Entwickler kann besser auf Fehlerbeschreibungen reagieren, wenn die 

Meldungstexte nicht uniform sind 

Wertzuweisungen 

Das Setzen von Werten beim Aufruf einer Seite sollte über einen OnPageLoad 

Prozess erfolgen. 

In APEX 4 gibt es für Wertzuweisungen Dynamic Actions. Diese sollten jedoch 

vorzugsweise bei Wertzuweisungen, die ohne einen PageLoad auskommen 

müssen, eingesetzt werden. Hierbei kommt Ajax zum Einsatz! 


� Die Methode des OnPageLoad Prozesses hat sich in der Praxis bewährt 

� Die Dynamic Actions sind erst ab APEX 4 verfügbar und sind schwerer zu 

debuggen 

JavaScript 

Mittels JavaScript können clientseitige Aktionen ausgeführt werden. Wenn 

möglich natives JavaScript vermeiden und jQuery nutzen. 


� APEX setzt auf die Verwendung von jQuery und bietet eigene JavaScript APIs 

an 

� jQuery und die APEX APIs haben sich etabliert und fangen Unterschiede 

einzelner Browser ab 

Zusätzlicher oder überschriebener JavaScript-Code sollte in einer (oder mehreren) 

applikationsspezifischen JavaScript-Libraries gespeichert und dann im APEX- 

Repository abgelegt werden. Das kann unter Shared Components � Files � 

Static Files geschehen. 


� Somit hat der Entwickler immer Zugriff auf den Code und muss nicht den 

Administrator kontaktieren 


Abbildung 14 JavaScript ins APEX-Repository hochladen 

JavaScript sollte auf einer Page immer im Header eingebunden und dann mittels 

einer Dynamic Action aufgerufen werden (erst ab APEX 4.0). 


� Auf diese Weise wird die Integration von JavaScript immer gleich gehandhabt 

� Ist einfacher nachvollziehbar 

Asynchrone Jobs oder Mailversand aus APEX Anwendungen 

Um in APEX Prozesse im Hintergrund ablaufen lassen zu können oder Mails zu 

versenden, gibt es in der APEX API entsprechende Aufrufe: APEX_PLSQL_JOB und 

APEX_MAIL. 


� Alle Funktionalität ist auf APEX abgestimmt, unterstützt und dokumentiert 

Page 0 

Page 0 sollte für Items, Prozesse, Funktionen usw. benutzt werden, die in der 

ganzen Applikation verwendet werden sollen. 

Beispiel: Eine LOV muss auf allen Seiten in der Anwendung sichtbar sein, da die 

Masken/Seiten immer im Kontext zu dem dort ausgewählten Wert stehen. 


� Alle Elemente auf dieser Seite werden auch auf allen anderen Seiten angezeigt 

bzw. sind auch dort verfügbar 


Abbildung 15 Beispiel für eine Page 0 mit Menu und Report 

Die Page 0 sollte nicht übermässig gefüllt werden. 


� Da die Seite bei jedem Seitenaufruf mitgeladen wird, geht dies zu Lasten der 

Performance 

Page 999 

Page 999 ist reserviert für den Standard Output von CGI_ENV. 


� Dient zum Debuggen der Benutzerumgebung 

Feedbackformular 

Der Benutzer sollte direkt aus der Anwendung einen Prozess starten können, der 

eine Meldung generiert oder eine Mail verschickt, um Feedback an den Entwickler 

zu geben. 


� Damit ein Benutzer bequem einen aufgetretenen Fehler oder eine 

Fehlfunktion in der Anwendung melden kann 

Ab APEX 4.0 ist dies im Standard schon enthalten. Bis APEX 3.2 muss es noch 

selbst entwickelt werden. 


Abbildung 16 Link als Navigation Bar Entry in der Anwendung in APEX 4 

Dieses Feedback kann dann im Application Builder von den Entwicklern oder auch 

einem entsprechend berechtigten User bearbeitet werden. 

Abbildung 17 Feedbackbearbeitung in APEX 

Mehrsprachige Applikationen 

Im Vergleich von APEX 4 zu APEX 3, bietet die neue Version eine dynamische 

Formatierung von DATE, TIMESTAMP und TIMESTAMP WITH TIMEZONE 

Datentypen. Hierbei kann ein Item angegeben werden, welches in Abhängigkeit 

z. B. von der Browsersprache unterschiedliche Formatmasken zurückliefert. 


Abbildung 18 Angabe des Items, das die Formatierung enthält 

Für die Übersetzung der internen APEX Messages sollten zunächst nur die Texte 

für die Primary Language angelegt werden. Dann werden diese in ein XLIFF-File 

exportiert, übersetzt und wieder hochgeladen. Dadurch wird eine weitere Sprache 

hinzugefügt. Dies sollte nicht über manuelles Anlegen der Texte für eine weitere 

Sprache erfolgen. 


� So werden alle benötigten Übersetzungen in einer Datei bereitgehalten 

Abbildung 19 Anlegen der Texte 

Wertelisten sollten immer über statische LOVs angelegt werden. 


� Diese werden in das XLIFF-File exportiert 

Im Browser sollte immer die Primary Language angezeigt werden oder auch eine 

Sprache, die es nicht als Übersetzung gibt 


� Aktuell gemachte Änderungen werden beim Entwickeln in der Applikation 

sonst nicht angezeigt 


Für dynamische Wertelisten sollte APEX_LANG.LANG und für dynamische 

Übersetzung von Messages APEX_LANG.MESSAGES verwendet werden 


� Diese Funktionen sind auf APEX abgestimmt 

� Die Texte werden so immer nach XLIFF exportiert 

Bei der Erzeugung der XLIFF-Dateien gilt der Grundsatz weniger ist mehr. Dies 

bedeutet dass Optionen wie „Only those elements requiring translation“ bei der 

Erzeugung selbst, bei Templates „non-translatable“ und bei Regions „exclude title 

from translation“ genutzt werden sollten. 


� Das XLIFF-File sollte für den Übersetzer auf das Notwendigste reduziert 

werden 

Abbildung 20 Einstellungen auf Ebene der Komponenten 

Abbildung 21 Einstellungen für das XLIFF-File 

Für jede Übersetzung erstellt APEX eine Kopie der Anwendung. Beim Import der 

Anwendung in einen neuen APEX Workspace muss in folgender Reihenfolge 

vorgegangen werden: 

� 1. Primäre Anwendung installieren 

� 2. Die übersetzte(n) Anwendung(en) installieren 


� Die primäre Sprache einer Anwendung muss immer installiert sein, bevor eine 

übersetzte Anwendung installiert werden kann 


Master Applikation 

In jedem Workspace sollte eine Master Applikation zu finden sein. In dieser 

Applikation können das CI Layout, die UI Defaults, immer wiederkehrende Items 

wie z. B. LOV’s und Authentisierungs- sowie Autorisierungsschemas implementiert 

sein. 


� Damit können Änderungen an Layout oder den Zugriffsrechten zentral über 

alle Applikationen ausgerollt werden, da Elemente aus Applikationen 

innerhalb eines Workspaces sowohl kopiert als auch referenziert werden 

können 

Folgende Komponenten können hier enthalten sein: 

� Autorisierungsschemas 

� Authentifizierungsschemas 

� List of Values 

� Plug-Ins 

� Templates 

� Shortcuts 

� Navigation Bars 

� Help Text 

� User Interface Defaults 

Abbildung 22 Create as copy from existing Item 

Abbildung 23 Kopieren oder referenzieren? 


Master Applikationen sollten immer Beispielseiten enthalten, in denen die 

Komponenten verwendet und idealerweise auch erklärt werden. 


� So lässt sich die Funktionsweise der jeweiligen Komponente einfacher 

nachvollziehen und adaptieren 

Ablage der Dokumentation 

Eine kurze Dokumentation im Stile eines How-To sollte in jeder Anwendung für 

den Anwender verfügbar sein. 


� So hat der Anwender immer die Möglichkeit, Hilfe im Umgang mit den zur 

Verfügung gestellten Funktionen zu finden 

Abbildung 24 Dokumentation in der Anwendung 


5 Deployment 

Das Deployment der APEX Applikationen kann auf verschiedene Arten stattfinden. Der 

Weg ist jedoch immer derselbe. Die nachfolgende Abbildung zeigt den Weg im Überblick. 

Dabei kann die Anzahl der Systeme variieren. 

Abbildung 25 Einfacher Deploymentprozess im Überblick 

5.1 Deployment-Arten 

APEX GUI 

Über die GUI können Applikationen, Teile von Applikationen, Bilder, CSS usw. per 

Mausklick aus einer Umgebung exportiert und in der gewünschten Umgebung importiert 

werden. 

Abbildung 26 Möglichkeiten des Exports über die APEX GUI 

Ein Sonderfall ist der Export eines Workspaces, da dieser nur durch den APEX-Admin 

ausgeführt werden kann. 

Vorteil: 

� Keine Programmierung nötig 

� Wird von Oracle unterstützt 


Nachteil: 

� Export/Import nur einzeln möglich, daher arbeitsintensiv bei vielen Applikationen 

� Kann nicht über einen Job gehandhabt und damit zeitgesteuert angestossen werden 

SQL Developer 

Über den SQL Developer können ebenfalls Applikationen exportiert und importiert werden. 

Das ist über das Kontextmenü beim Klick auf die einzelnen Anwendungen möglich. 

Abbildung 27 Kontextmenü Application Express im SQL Developer 

Vorteil: 

� Keine Programmierung nötig 

Nachteil: 

� Export/Import nur einzeln möglich, daher arbeitsintensiv bei vielen Applikationen 

� Kann nicht über einen Job gehandhabt und damit zeitgesteuert angestossen werden 

APEXExport Utility 

Das Exportwerkzeug wird standardmässig mit APEX ausgeliefert. Es befindet sich unter 

/apex/utilities/oracle/apex. Damit lassen sich sowohl einzelne als auch mehrere 

Applikationen sowie alle Applikationen aus einem WS oder der kompletten Instanz 

exportieren. Für den Import wird dann die erzeugte SQL-Datei ausgeführt. 

Vorteil: 

� Wird von Oracle unterstützt 

� Durch Jobs steuerbar 

Nachteil: 

� Kein Export von Bildern und Dateien (Ausnahme Supporting Objects) 


APEX API 

Exporte können ebenfalls mit diversen APEX APIs wie z. B. 

wwv_flow_utilities.export_application_to_clob(..) 

gemacht werden. Für den Import werden dann mit dem Package 

apex_application_install 

entsprechende Parameter gesetzt und die erzeugte SQL-Datei ausgeführt. 

Vorteil: 

� Individuelle Lösung, Bilder und Dateien exportierbar 

� Durch Jobs steuerbar 

Nachteil: 

� Einmaliger Programmieraufwand 

� Kein Support von Oracle 

5.2 Empfehlungen für das Deployment 

Für das Deployment wird eine Kombination aus den aufgeführten Möglichkeiten zur 

Kommandozeile empfohlen. Für alle Workspaces, Applikationen und Websheets sollte das 

APEXExport Utility und für alle Bilder oder Dateien sollten die APEX APIs verwendet 

werden, sofern diese nicht in den Supporting Objects abgelegt werden. Die erzeugten 

SQL-Dateien sollten in definierten Verzeichnissen mit definierten Namen abgelegt werden 

und können dann mittels Jobs über die Kommandozeile ausgeführt werden. 

Genauere Informationen zum Export und Import per Kommandozeile sind auf folgenden 

Internetseiten zu finden: 

� Automatisierter Export und Import von APEX-Anwendungen per Kommandozeile 

http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/export-script/index.html 

� Blog-Eintrag bei Joel R. Kallman „APEX_APPLICATION_INSTALL“ 

http://joelkallman.blogspot.com/2010/07/apexapplicationinstall.html 


Supporting Objects 

Hier können Skripte abgelegt werden, die zur Anpassung des bzw. der DB-Schemas 

dienen. Diese Skripte sollten jedoch nicht über die GUI ausgeführt werden, sondern auf der 

DB selbst. Gerade dann, wenn es mehrere Versionen eines Skripts oder auch Update- 

Skripts gibt, kann es zu Problemen kommen, da die Bedingungen (Conditions) zur 

Ausführung der einzelnen Skripte nicht greifen. In diesem Fall ist es besser, manuell nur die 

Skripte auszuführen, die man benötigt. 

Wenn Bilder und andere benötigte Dateien in die Supporting Objects integriert werden, 

lassen sich diese dann auch mit der Anwendung selbst über das Export-Utility exportieren. 

Abbildung 28 Überblick Supporting Objects in APEX 

Prinzipiell sollten derartige Skripte in einem Repository einer Versionsverwaltung abgelegt 

und versioniert werden. So befinden sich alle notwendigen Skripte an einem Platz. 

Big Apps vs. Partitioned Apps 

Der Unterschied zwischen „Big Apps“ und „Partitioned Apps“ spielt bei der oben 

empfohlenen Deploymentvariante keine Rolle. Bei den anderen beiden Methoden des 

Deployments sind Big Apps von Vorteil, da anstatt mehrerer Exporte und Importe nur 

jeweils einer durchgeführt werden muss. 


Workspace einrichten 

Ein Workspace sollte auf der Entwicklung erstellt und dann mittels Export und Import auf 

Test und Produktion installiert werden. Somit wird sichergestellt, dass alle Einstellungen, 

User usw. übernommen werden. Es sollte beachtet werden, dass kein WS auf diesen 

Instanzen manuell erzeugt wird! 

User einrichten 

Wird die Empfehlung aus dem vorigen Punkt befolgt, werden die User automatisch 

angelegt, die es in der Entwicklung gibt. Die Vorgehensweise für das Einrichten von Usern, 

die in der Test- oder Produktivumgebung zusätzlich benötigt werden, hängt von der 

entsprechenden Authentifizierungsmethode ab, wie nachfolgend beschrieben. 

� Application Express 

Bei dieser Methode sollten sämtliche Benutzer schon in der Entwicklungsumgebung 

angelegt werden, da über den Export/Import des WS alle Benutzer mit angelegt werden 

und so kein weiterer Aufwand entsteht. 

� LDAP 

Mit der Authentifizierung gegen LDAP liegt das Einrichten der User nicht mehr innerhalb 

von APEX, sondern bei der Stelle, die die LDAP-User pflegt. Am sinnvollsten ist es hier, eine 

Gruppe in LDAP einzurichten, die dann für die entsprechende Applikation berechtigt ist. 

Diese muss dann im Authentifizierungsschema abgefragt werden. 

� SSO 

Auch hier wird das Einrichten der User ausgelagert. Einzig die Instanz, die den User prüft 

und für SSO berechtigt, kann hier User entfernen oder hinzufügen. In APEX müssen keine 

Anpassungen gemacht werden. 

Test nach Produktion 

In der Test-Instanz sollten, wenn irgendwie möglich, genau die gleichen Bedingungen 

vorhanden sein, wie im Produktiv-System. Sprich die Workspaces, User, die Strukturen und 

Daten in der DB sowie der Aufbau und die Daten referenzierter Systeme wie ein LDAP 

müssen identisch sein. Nur so kann ein wirklicher End-to-end Test stattfinden. Ist dies der 

Fall, so ist der Schritt zum Produktiv-System nach einem erfolgreichen Test nur ein 

erneutes Deployment der Sourcen für die Produktivumgebung. 


6 Betrieb 

6.1 Instanzen 

Entwicklung 

Die Entwicklungsumgebung sollte mit dem Aufbau der Testumgebung übereinstimmen. 

Alle Abweichungen können zu Fehlern führen, die erst auf der Testebene auftreten. Der 

Entwickler sollte hier mit dem grösstmöglichen Umfang an Rechten ausgestattet sein, um 

seine Entwicklungen auch zügig umsetzen und testen zu können. 

Test 

Die Testumgebung sollte immer genau wie die Produktivumgebung gehandhabt werden. 

Hier dürfen keine Entwicklungen mehr stattfinden. Auf der Testumgebung sollten deshalb 

alle Applikationen mit der Option „run only“ installiert werden. Nur so kann gewährleistet 

werden, dass Entwicklungs- und Teststand dieselben sind. 

Abbildung 29 Applikation als run only importieren 

Werden keine Websheets verwendet, kann die Testinstanz auch als Run-Only-Instanz 

aufgesetzt werden. Websheets können in einer solchen Umgebung allerdings nicht 

bereitgestellt werden. 

Produktion 

Hier gelten die gleichen Empfehlungen wie bei der Testumgebung. Alle Applikationen, die 

auf der Testumgebung getestet und abgenommen wurden, können produktiv mit der 

Option „run only“ importiert werden. Auch die Produktivinstanz kann als Run-Only-Instanz 

laufen, sofern keine Websheets verwendet werden. 


6.2 Versionen 

APEX sollte immer auf dem neuesten Stand gehalten werden, d. h. die aktuellste Version 

bzw. das aktuellste Patch sollten Verwendung finden. Patches lassen sich ohne 

irgendwelche Anpassungen an den Anwendungen einspielen. Die einzige Änderung, die 

gemacht werden sollte, ist die Einbindung neuer Features an Stellen, wo es den Code 

erleichtert. 

Die Empfehlung lautet hier, mindestens mit Version 4.0 zu arbeiten, da diese Version 

gegenüber den Versionen 3.2 und älter einen erheblichen Zuwachs an Features bietet, die 

dem Entwickler die Arbeit wesentlich erleichtern. 

Auf den offiziellen Seiten von APEX im OTN wird für neue Versionen immer ein Statement 

of Direction veröffentlicht, welches die geplanten Features enthält. 

6.3 Workspace Design 

Ein Workspace ist wie ein Container zu betrachten, in dem für einen definierten fachlichen 

Bereich Applikationen erstellt und gehalten werden. Eine geeignete Zuordnung ist hier ein 

WS zu einem Schema, da ein DB-Schema meist schon die fachliche Zuordnung hat. Es 

können jedoch ergänzend DB-Schemas in einem WS benötigt werden! Dies ist 

beispielsweise der Fall, wenn Daten aus einem fremden aber fachlich verwandten Schema 

für eine LOV oder auch einen Bericht benötigt werden. 

APEX liefert den WS internal mit. Nur in diesem WS können neue WS angelegt werden. Das 

Anlegen, Löschen oder Verwalten der DB-Schemas für Workspaces sollte zentral von einer 

Person gemacht werden. Sinnvollerweise ist das der APEX-Admin. 

Abbildung 30 Anmeldung am Workspace internal 


Abbildung 31 Administration über den Workspace internal 

6.4 Security 

Authentifizierung 

Security ist innerhalb von APEX hauptsächlich ein Zusammenspiel von Authentifizierung 

und Autorisierung. Für die Authentifizierung werden User und Passwörter benötigt. 

Nachfolgend ein Überblick zu den Möglichkeiten, wie User angelegt und deren Identität 

geprüft werden kann. 

Abbildung 32 Anlegen der Authentifizierungsschemas 

Autorisierung 

Autorisierung erfolgt über die entsprechenden Schemas in einer Applikation. Diesen 

Schemas können Items, Regions, Tabs, etc. zugewiesen werden. Es ist empfehlenswert, ein 

Konzept für die Autorisierung zu definieren, da anderenfalls schnell der Überblick verloren 

geht. Dabei sollte auf die richtige Granularität geachtet werden: Nur so granular wie nötig! 

Nachfolgende Abbildung zeigt Autorisierungsschemas, die über eine View prüfen, ob eine 

bestimmte Eigenschaft bei dem aktuellen User vorhanden ist. 


Abbildung 33 Autorisierungsschemas prüfen mittels Views 

6.5 Userverwaltung 

Es gibt folgende drei Arten von Usern innerhalb von APEX: 

� Workspace Administrator 

� Developer 

� Application User 

Die nachfolgende Abbildung zeigt die Maske für die Anlage der drei Usertypen. 


Abbildung 34 User-Einstellungen 

Workspace Administrator 

Es gibt einen speziellen Workspace-Administrator, der für den internal WS verantwortlich 

ist. Dies ist der APEX-Admin. Der APEX-Admin sollte nur den Workspace selbst und den 

dazugehörigen Workspace Administrator anlegen. Diese wiederrum sollten dann alle 

weiteren Einstellungen vornehmen, z. B. User anlegen, entsprechend berechtigen und 

Schema zuweisen. So liegen die Verantwortlichkeiten gleich in den richtigen Händen. APEX 

bietet für dieses Szenario auch Service Requests für die Workspace Administratoren an. 


Developer 

Entwickler werden vom WS-Admin angelegt und können ab APEX 4.0 darin eingeschränkt 

werden, welche Komponenten (Application Builder, SQL Workshop oder Team 

Development) sie nutzen dürfen oder nicht. 

Das Passwort für die Entwickler sollte vom DBA auf „Require Change of Password on First 

Use“ auf „yes“ gesetzt werden, damit der Entwickler sein persönliches Passwort vergeben 

kann. 

Application User 

Für eine Applikation berechtigte Anwender können über verschiedenste Arten angelegt 

und verwaltet werden. Diese sind immer abhängig vom jeweils verwendeten 

Authentifizierungsschema. Innerhalb eines Unternehmens sollte es ein einheitliches 

Verfahren der Anmeldung geben, soweit das technisch möglich ist. Die Variante 

„Application Express“ ist nur bei einem kleineren Nutzerkreis zu empfehlen, da die 

Verwaltung sehr zeitintensiv ist. Sollte diese Authentifizierung trotzdem eingesetzt werden, 

sollte die Verwaltung über APEX APIs in Verbindung mit einer GUI vereinfacht werden. Dies 

gelingt, indem z. B. die Mehrfachselektion von Usern zur Anlage in APEX oder auch 

Updates auf bestimmte Eigenschaften über mehre User angeboten werden. 

Bezüglich der Passwörter gilt hier das Gleiche wie bei den Entwicklern. 

Wie bindet man die Userverwaltung an LDAP an? 

Für die Anbindung der Anwenderverwaltung an LDAP stellt APEX ein vorkonfiguriertes 

Authentifizierungsschema bereit, das mit den entsprechenden Angaben zu Server und Pfad 

der berechtigten Gruppe ergänzt werden muss. Ist ein zentrales LDAP bereits vorhanden 

und gepflegt, sollte diese Art der Authentifizierung genutzt werden. Dies ermöglicht, dass 

hier kein weiterer Aufwand bezüglich der Benutzerverwaltung getrieben werden muss und 

der Anwender sich kein zusätzliches Passwort merken muss! 


Abbildung 35 Konfiguration für LDAP-Anbindung 

Ohne erkennbare Vor- und Nachteile sind Microsoft Active Directory Server oder auch 

Oracle Internet Directory verwendbar. 

Wie bindet man die Userverwaltung an Single Sign On (SSO) an? 

Die einfachste Variante SSO anzubinden, ist die Verwendung des SSO-Servers von Oracle. 

Hierfür gibt es ein Standard-Authentisierungsschema innerhalb von APEX. 

Unabhängig von der Variante, die für SSO innerhalb eines Unternehmens gewählt wird, 

benötigt APEX einen Eintrag des Users, der sich erfolgreich gegen ein SSO-System 

authentifiziert hat, in einer durch die DB auslesbaren Variablen wie z.B. die CGI_ENV- 

Variable „REMOTE_USER“. Mit dieser Grundlage kann dann ein Authentifizierungsschema 

angelegt werden, das dem User eine APEX-Session ermöglicht, solange diese Variable 

gefüllt und damit valide ist. Hierfür sollte die Page Sentry Function innerhalb des Page 

Session Management verwendet werden, die bei jedem Seitenaufruf geprüft werden sollte! 


Abbildung 36 Page Sentry Function mit Package-Aufruf 

Wie kann ich zusätzlich für Sicherheit sorgen? 

Es sollte mindestens die Edition „Standard Edition One“ der Datenbank für den produktiven 

Einsatz verwendet werden. 


� Die Datenbank sollte immer auf die letzte Version gepatcht und das letzte Critical Patch 

Update berücksichtigt werden. Dies ist mit der Express Edition nicht möglich. 

Im Workspace internal, unter „Service verwalten > Sicherheit“ sind die folgende 

Einstellungen zu beachten: 

Abbildung 37 Session-Timeout 

Abbildung 38 Account-Steuerung 


� Um Anwendungen vor unerlaubten Zugriffen durch offene Sessions oder auch nicht 

berechtigten Usern zu schützen 

Es sollten beim Webserver (Apache) alle nicht benötigten Apache-Module (PHP, Perl, usw.) 

abgeschaltet werden, alle nicht benötigten statischen Seiten gelöscht und alle nicht 

verwendeten Direktiven (Aliasnamen, Verzeichnisse) aus der httpd.conf entfernt werden. 

Der Database Access Descriptor (DAD) sollte auch nicht unbedingt "apex" genannt und auf 

das "pls" kann auch verzichtet werden. So ist es besser, wenn eine APEX-Umgebung mit 

"http://myserver/dev/mycompany" anstelle von "http://myserver/pls/apex" erreichbar ist. 



� der Webserver bietet so eine geringere Angriffsfläche 

Wird der Apache Webserver genutzt, sollte bei der Konfiguration des mod_plsql der 

Parameter PlsqlRequestValidationFunction eingestellt werden. Bei Verwendung des 

Embedded Gateways mit einer Oracle 11g Datenbank findet dies bereits statt. 


� So können direkte Aufrufe von PL/SQL-Prozeduren per URL eingeschränkt werden 

Die Kommunikation zwischen Browser und Webserver sollte nur über das SSL Protokoll 

erlaubt sein. Im Workspace internal, unter „Service verwalten > Sicherheit“ kann das 

Attribut „Erfordert HTTPS“ auf „Ja“ eingestellt werden: 

Abbildung 39 SSL Verschlüsselung einstellen 


� Damit wird eine verschlüsselte Kommunikation für interne APEX Anwendungen 

erzwungen 

6.6 Accounting (Ressourcennutzung) 

APEX ist ein Entwicklungswerkzeug, das sehr wenig Ressourcen braucht, da der Grossteil 

der Anwendungsdaten in der Datenbank selbst verwaltet wird. Dazu nutzt APEX die 

Schemas FLOWS_FILES (für Objekte wie Bilder, Dateien etc.) und APEX_XXXXXX für die 

Metadaten der Applikationen. Der erzeugte Netzwerkverkehr ist unwesentlich, da lediglich 

HTML Seiten aufgebaut bzw. ausgetauscht werden und alles weitere in der Datenbank 

geschieht. 

Aufgrund dessen ist es möglich, alle drei notwendigen Instanzen (Entwicklung, Test, 

Produktion) auf einem Applikationsserver laufen zu lassen. Es empfiehlt sich jedoch bei 

grösseren Umgebungen, die Instanzen auch physisch zu trennen und jede auf einem 

eigenen Server zu betreiben. 

Die genauen Speicheranforderungen für den Datenbank-Server sind plattform-spezifisch. 

Bei einer Anzahl gleichzeitiger Benutzer von 100 oder mehr sollte aber freier Speicher von 

etwa 512 MB zur Verfügung stehen. Installationen mit einem Speicher von weniger als 128 

MB sind nicht zu empfehlen. APEX-Anwendungen profitieren von mehreren CPUs und 

nicht von höherem Speicher. Schnellere CPUs stellen daher die effizienteste Art dar, wie die 

Performance von APEX zu optimiert werden kann. 


6.7 Monitoring 

OEM Database Control 

Neben den zahlreichen Berichten und Auswertungen, die APEX standardmässig über die 

„Administration“ bietet, lässt sich APEX auch über den Enterprise Manager bzw. über 

Oracle EM Database Control überwachen. Dies muss jedoch über „Benutzerdefinierte 

Metriken“ erstellt werden. Die Basis einer solchen Metrik ist immer eine SQL-Abfrage. 

Dabei werden Komponenten und zu überwachende Werte wie z. B. die Ausführungszeit 

pro Komponente selektiert und es wird im EM konfiguriert, wann welche Meldungen bei 

welchen Werten angezeigt werden sollen. Ein gutes Beispiel dazu lässt sich in den 

Community-Tipps finden. 

Abbildung 40 Ansicht Metriken im OEM 

Ressource Manager 

Mit dem Ressource Manager können APEX-Anwendungen, Seiten in APEX- 

Anwendungen oder auch User bezüglich der Nutzung vorhandener CPU 

priorisiert werden. So kann z. B. der Ressourcenverbrauch von Test-Applikationen 

gegenüber Produktiv-Applikationen niedriger gehalten werden. Dazu werden die 

Anwendungen, Seiten oder User zu sogenannten Consumer Groups zugeordnet. 

Diesen Gruppen werden dann über Ressourcen Pläne bestimmte Prozentsätze 

von der CPU zugewiesen. 

USERNAME GRUPPE STATE CPU_TIME CPU_WAIT_TIME 

------------------------------ --------------- --------------- ---------- ------------- 

APEX_PUBLIC_USER PRIO_HIGH RUNNING 5077 0 

APEX_PUBLIC_USER PRIO_LOW WAITING FOR CPU 2409 4882 

APEX_PUBLIC_USER OTHER_GROUPS WAITING 8988 8266 





Abbildung 41 Beispiel für die Auswirkungen der Ressourcenpriorisierung 

Welche Applikation, Seite oder User welcher Gruppe angehört, kann auch zur Laufzeit 

geändert werden! So kann z. B. für eine Session eine Abfrage abgebrochen oder sogar die 


gesamte Session abgebrochen werden, wenn der I/O-Wert eine festgelegte Menge 

überschreitet oder die Ausführungszeit zu lang ist. 

Der Ressourcen Manager ist ab der Enterprise Edition verfügbar und sollte aber - wenn 

vorhanden - in grösseren Umgebungen auch genutzt werden. 

V$Session und DBMS_APPLICATION_INFO 

Über das Datenbank Package DBMS_APPLICATION_INFO werden von APEX hilfreiche 

Parameter für jede Session gesetzt. Mehr Informationen zum Package 

DBMS_APPLICATION_INFO sind in der Dokumentation der Datenbank unter Oracle 

Database PL/SQL Packages and Types Reference verfügbar. 

Parameter Wert 

Modul APEX:APPLICATION 

Client Info User 

Action PAGE 

So können Dictionary Views wie V$Session aber auch V$Sql und andere effektiver 

ausgelesen werden, da eine Session in besagten Views so leichter zu identifizieren ist. 

Zudem ist der Zusammenhang zwischen der Session und der abgesetzten SQL-Statements 

leichter herzustellen, wenn z. B. Performance Probleme untersucht werden müssen. 

7 Hilfsmittel und Tools 

Team Development 

Das Team Development ist erst seit APEX 4 erhältlich, verfügt jedoch über alle 

notwendigen Funktionen, um innerhalb APEX Features der Anwendungen zu definieren, 

Milestones festzulegen, Aufgaben zuzuweisen, Bugs zu tracken und vieles mehr. Dadurch 

können externe Tools wie z. B. JIRA abgelöst werden. 


Abbildung 42 Features im Team Development 

Es sollten Feedback-Links inklusive Feedbackseiten in jeder Anwendung verfügbar sein, 

damit der Anwender mögliche Bugs, Kommentare oder auch Anfragen an die Entwickler 

senden kann. 

Plug-Ins (APEX 4) 

Plug-Ins können auf folgender Seite veröffentlicht und auch von dort bezogen werden: 

http://www.apex-plugin.com/. Hier ist es so, dass der Ersteller die Version vergibt und beim 

Update des Plug-Ins auch für eine neue Version sorgen muss. Sollte ein Plug-In selbst 

erstellt oder erweitert werden, muss hier das Plug-In auch selbst versioniert werden. 

Plug-Ins können auch für Komponenten erstellt werden, die innerhalb einer Anwendung 

oder eines Unternehmens häufig verwendet werden und dienen so quasi als „Modul“. 

Fremde Plug-Ins sollten mit Bedacht gewählt und ausführlich getestet werden. Sie sollten 

nur eingesetzt werden, wenn sie auch wirklich benötigt werden. 


� Beim Einsatz von Plug-Ins ist keinerlei Support gewährleistet 

� Plug-Ins unterschiedlicher Anbieter können sich gegenseitig ins Gehege kommen 

(Seiteneffekte!) 

Abbildung 43 Plug-In Verwaltung in APEX 


APEX 4 Advisor 

Der Advisor dient der Qualitätssicherung einer Anwendung. Es können beispielsweise 

Referenzen innerhalb einer Anwendung auf ihre Gültigkeit überprüft werden und auch 

viele andere Kontrollen gemacht werden. Anwendungen sollten in regelmässigen 

Abständen mit diesem Dienstprogramm geprüft werden, da es wenig Zeit in Anspruch 

nimmt und so die Anwendung verbessert werden kann. 

Abbildung 44 Optionen des APEX Advisor 

SQL Developer 

Der SQL Developer sollte als Datenbanktool eingesetzt werden, da er einige Möglichkeiten 

bietet, um APEX zu verwalten. So können mit Hilfe des SQL Developers z. B. alle 

Applikationen bis auf Seitenebene angezeigt werden, Applikationen exportiert und 

importiert werden oder auch mit einem Plug-In von Carsten Czarski Workspaces verwaltet 

werden. Der SQL Developer hält auch die nützliche Funktion des Remote-Debuggings für 

APEX-Anwendungen bereit. Näheres dazu lässt sich auf der APEX Community Seite finden, 

die von Carsten Czarski gestaltet wird. 


Abbildung 45 Zusätzliches Verzeichnis im SQL Developer für APEX 

Abbildung 46 Anzeigemöglichkeiten auf Level Applikation 

Der SQL Developer bietet viele Berichte rund um APEX und die angelegten Applikationen 

an. Hier kann schnell ein Überblick über die vorhandenen Applikationen und deren 

Komponenten gewonnen werden. 

Abbildung 47 Berichte auf Applikationsebene 

Abbildung 48 Berichte auf Seitenebene 


Auf jedem Level findet sich auch das DDL zur Applikation oder zur Seite unter dem Reiter 

SQL. 

APEX Views 

Über die APEX Views kann man unter Beachtung der hierarchischen Struktur alle 

Komponenten einer Applikation auflisten lassen. Darüber dokumentieren sich die 

Applikationen gewissermassen selbst. Diese Informationen können beliebig verwendet 

werden, wie z. B. für Auswertungen, Dokumentationen, generische Funktionen usw. 

Welche APEX Views vorhanden sind, kann über APEX_DICTIONARY abgefragt werden. Die 

Views sind hierarchisch aufgebaut. So gib es eine Spalte Parent View, welche die 

übergeordnete View zu einer anderen View angibt. 

Frameworks (ApexLib und Essentials) 

Ab APEX 4 sind die Frameworks ApexLib und Essentials von Patrick Wolf fest eingebaut. Für 

Entwickler, die noch mit APEX 3 arbeiten, bieten diese Frameworks einen reichhaltigen Satz 

an zusätzlichen Funktionen, wie z. B. die Cascading LOVs. 

Firebug 

Firebug ist ein kostenfreies Plug-In für Firefox, das aber mittlerweile auch für den Internet 

Explorer verfügbar ist. Dieses hilfreiche Tool sollte jeder APEX-Entwickler kennen und 

nutzen, da mit diesem Tool eine HTML-Seite sehr schnell und einfach durchsucht und auch 

on the fly verändert werden kann. Somit kann man z. B. sehen, ob eine geplante Änderung 

im Quellcode den gewünschten Effekt bringt, bzw. wo und ob sich gemachte Änderungen 

in APEX im Aufbau der Seite niederschlagen. 

Abbildung 49 Oberfläche des Firebug 


Applikationsvergleich 

Ein Vergleich von Applikationsversionen ist in APEX selbst möglich. Unter Application � 

Tasks (am rechten Rand zu finden) � Cross Application Reports � Application Comparison 

findet man die Möglichkeit, Versionen von Applikationen zu vergleichen. Ein 

entsprechender Filter lässt sich einstellen, der selektiert, welche Komponenten 

berücksichtig werden sollen. 

Abbildung 50 Applikationsvergleich innerhalb APEX 

Utilities 

Auf der Seitendefinition existieren unter Utilities einige nützliche Funktionen. Besonders 

hervorzuheben sind hier zwei Berichte, die für Entwickler sehr hilfreich sein können: 

� Page Events: Hier kann man die Abläufe beim Aufbau und der Verarbeitung der Seite 

sehen. 

� Referenced Database Objects: Hier sieht man, welche Datenbankobjekte von der 

Seite verwendet werden. 

Abbildung 51 Auf Seitenebene verfügbare Utilities 


Referenzen 

Nützliche Links 

Hier ein paar Links zu Internetseiten, die man verfolgen sollte oder auf denen 

gegebenenfalls der Newsletter abonniert werden kann: 

� Oracle Application Express Community 

http://www.oracle.com/webfolder/technetwork/de/community/apex/index.html 

� Oracle Application Express API Referenz 

http://download.oracle.com/docs/cd/E17556_01/doc/apirefs.40/e15519/toc.htm 

� Oracle Application Express Application Builder User´s Guide Substitution-Strings 

http://www.utoug.org/i/doc/concept_sub_strings.htm 

� APEX Blogs 

http://www.apexblogs.info/pls/apex/f?p=113:8:0: 

� Blog SQL und PL/SQL in Oracle von Carsten Czarski 

http://sql-plsql-de.blogspot.com/ 

� Oracle Learning Library 

http://apex.oracle.com/pls/apex/f?p=44785:2:2055129407262164:FORCE_QUERY::2,CIR,RIR:P2_TAGS:APEX 

� Trivadis PL/SQL und SQL Coding Guidelines 

http://www.trivadis.com/PLSQL-Guidelines 

� APEX Plugin Directory 

http://www.apex-plugin.com/ 

Weiterführende Themen 

� Portal der MT AG inklusive Lernvideos und Software-Downloads 

http://portal.mt-ag.com 

� Automatisierter Export und Import von APEX-Anwendungen per Kommandozeile 

http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/export-script/index.html 

� Blog Eintrag bei Joel R. Kallman „APEX_APPLICATION_INSTALL“ 

http://joelkallman.blogspot.com/2010/07/apexapplicationinstall.html 

� APEX Workspace-Nutzer mit dem SQL Developer verwalten 

http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/sqldev-apexuser/index.html 


� Remote-Debugging mit dem SQL Developer und Application Express 

http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/remote-debug/index.html 


UNSERE STANDORTE 

Basel 

Bern 

lausanne 

ZÜrich 

dÜsseldorf 

frankfurT a. M. 

freiBurG i. Br. 

haMBurG 

MÜnchen 

sTuTTGarT 

Wien 

UNSERE LÖSUNGEN 

Business inTeGraTion serVices 

Business inTelliGence 

applicaTion deVelopMenT 

infrasTrucTure enGineerinG 

ManaGed serVices 

TraininG 

Version 1.0 

© 2011 TriVadis aG 

info-Tel. 0800 874 823 47 

www.trivadis.com

Oracle Application Express Tipps für Entwicklung und ... - Trivadis

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?