oracle application express
Werbung
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
©2011 Trivadis AG
1.0
Vorwort
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
Urban Lankes
unsere Erfahrungen helfen, solche Fehler von Anfang an zu
CEO Trivadis
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
Carsten Czarski
Leitender
Systemberater
Oracle
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
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.
Volker Strasser
Senior Consultant
Trivadis
Oracle Application Express Tipps für Entwicklung und Betrieb
3
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
4
Änderungshistorie
Version
Wer
Datum
Kommentar
0.1
0.2
Volker Strasser
09.11.2010
Initiale Struktur Development
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
Oracle Application Express Tipps für Entwicklung und Betrieb
5
Inhaltsverzeichnis
Vorwort .................................................................................................................................. 2
Lizenz ..................................................................................................................................... 4
Geschützte Marken ......................................................................................................................................... 4
Haftungsausschluss ........................................................................................................................................ 4
Änderungshistorie ................................................................................................................ 5
Inhaltsverzeichnis ................................................................................................................. 6
Abbildungsverzeichnis ......................................................................................................... 8
1
Einleitung ..................................................................................................................... 10
1.1
1.2
1.2.1
1.2.2
1.2.3
1.2.4
2
3
Systemlandschaft ........................................................................................................ 13
3.2.1
3.2.2
3.2.3
3.3
3.4
Embedded PL/SQL Gateway ................................................................................................. 13
Oracle HTTP Server (Apache) mit konfiguriertem mod_plsql .................................. 14
Application Server mit konfiguriertem APEX-Listener ................................................ 14
Web-Browser ................................................................................................................................... 15
Rollen und Aufgaben bei APEX ................................................................................................ 15
Konzepte ........................................................................................................................................... 17
Das Fundament: die Datenmodellierung .............................................................................. 18
Application Builder ........................................................................................................................ 20
Reports............................................................................................................................................... 27
Formulare .......................................................................................................................................... 29
Namenskonventionen für Elemente ....................................................................................... 31
Pages, Items, Shared Components & Co. ............................................................................. 33
Deployment.................................................................................................................. 43
5.1
5.2
6
Datenbank ........................................................................................................................................ 13
Webserver und Application Server.......................................................................................... 13
Entwicklung .................................................................................................................. 17
4.1
4.2
4.3
4.4
4.5
4.6
4.7
5
Kurzbezeichnungen.................................................................................................................. 10
Farben ........................................................................................................................................... 10
Schlüsselworte ........................................................................................................................... 11
Grafiken ........................................................................................................................................ 11
Warum Standards und Richtlinien wichtig sind ....................................................... 12
3.1
3.2
4
Anwendungsbereich ..................................................................................................................... 10
Konventionen im Dokument ..................................................................................................... 10
Deployment-Arten......................................................................................................................... 43
Empfehlungen für das Deployment........................................................................................ 45
Betrieb .......................................................................................................................... 48
6.1
6.2
6.3
Instanzen ........................................................................................................................................... 48
Versionen .......................................................................................................................................... 49
Workspace Design......................................................................................................................... 49
Oracle Application Express Tipps für Entwicklung und Betrieb
6
6.4
6.5
6.6
6.7
7
Security .............................................................................................................................................. 50
Userverwaltung ............................................................................................................................... 51
Accounting (Ressourcennutzung)............................................................................................ 56
Monitoring........................................................................................................................................ 57
Hilfsmittel und Tools................................................................................................... 58
Referenzen ........................................................................................................................... 64
Oracle Application Express Tipps für Entwicklung und Betrieb
7
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
Oracle Application Express Tipps für Entwicklung und Betrieb
8
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
Oracle Application Express Tipps für Entwicklung und Betrieb
9
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
Oracle Application Express Tipps für Entwicklung und Betrieb
10
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
Oracle Application Express Tipps für Entwicklung und Betrieb
11
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
12
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
Oracle Application Express Tipps für Entwicklung und Betrieb
13
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
Oracle Application Express Tipps für Entwicklung und Betrieb
14
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 APEXEntwickler 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
Oracle Application Express Tipps für Entwicklung und Betrieb
15
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
16
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
Oracle Application Express Tipps für Entwicklung und Betrieb
17
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.
Grund:
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.
Grund:
Die Wizards innerhalb APEX können diese Datenquelle sonst nicht erkennen
Performance Verschlechterungen, welche hier eventuell auftreten, können mit
Snapshots umgangen werden!
Oracle Application Express Tipps für Entwicklung und Betrieb
18
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.
Grund:
Ä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.
Grund:
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
19
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.
Grund:
Das Konzept Grant <role> 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, HTMLEditoren, Diagramme oder auch Data Grids zur Verfügung gestellt. Die Daten
Oracle Application Express Tipps für Entwicklung und Betrieb
20
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
Oracle Application Express Tipps für Entwicklung und Betrieb
21
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
Dialog 70
Dialog 71
Seite
Nummer
Query Screen 1
Page 700
List Screen 1
Page 701
Detail Screen 1
Page 702
Query Screen 2
Page 710
List Screen 2
Page 711
Detail Screen 2
Page 712
Grund:
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.
Grund:
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
Oracle Application Express Tipps für Entwicklung und Betrieb
22
Alias
Vorsicht bei der Vergabe von Aliasen, die sowohl auf Anwendungsebene als auch
auf Seitenebene vergeben werden können.
Grund:
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.
Grund:
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.
Grund:
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.
Grund:
Der Entwickler hat somit immer einen Zugriff und muss nicht den
Administrator kontaktieren
Oracle Application Express Tipps für Entwicklung und Betrieb
23
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.
Grund:
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.
Grund:
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
Oracle Application Express Tipps für Entwicklung und Betrieb
24
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
);
Grund:
Automatische Überprüfung der URL mittels Checksum
Oracle Application Express Tipps für Entwicklung und Betrieb
25
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.
Grund:
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.
Grund:
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
2. v('MY_ITEM')
(kann in APEX verwendet werden)
(kann in der Datenbank verwendet werden)
Nur wenn die obengenannten Zugriffsarten nicht funktionieren, ist die Notation
&MY_ITEM. bei unkritischen Daten erlaubt.
Grund:
Schutz gegen SQL-Injection
Oracle Application Express Tipps für Entwicklung und Betrieb
26
Versionsnummerierung
In der APEX Applikation Definition sollte das Feld Version gefüllt sein.
Grund:
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.
Grund:
Einfach zu implementierende Standardfunktionalität
Interactive Reports
Für flexible Reporting Anforderungen sollten Interactive Reports immer eingesetzt
werden!
Grund:
Hohe Flexibilität in der Visualisierung (Filtern, Gruppieren, Suchen,
Highlighting,…)
Oracle Application Express Tipps für Entwicklung und Betrieb
27
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
Auditing Attribute sollten in einem Interactive Report zur Auswahl angeboten,
aber nicht standardmässig angezeigt werden.
Grund:
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.
Grund:
Die fixe Spaltenüberschrift wird nicht im Übersetzungsrepository (XLIFF)
berücksichtigt (siehe Mehrsprachige Applikationen)
Oracle Application Express Tipps für Entwicklung und Betrieb
28
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 StandardFunktionalität auf eine Tabelle und wenig Geschäftslogik benötigen.
Grund:
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.
Grund:
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.
Grund:
Unkontrolliertes Updateverhalten
Validierungen sind nur mit viel Aufwand zu erreichen
Verbesserungen in APEX 4, jedoch noch nicht ausreichend für viele
Anforderungen
Oracle Application Express Tipps für Entwicklung und Betrieb
29
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.
Grund:
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.
Grund:
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
Oracle Application Express Tipps für Entwicklung und Betrieb
30
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.
Grund:
APEX hält eine solche Funktionalität nicht bereit
Kann zu Fehlermeldungen führen, wenn hier nicht nachgearbeitet wird
Auditing Attribute
Auditing Attribute, die automatisch über Datenbank Trigger gesetzt werden,
sollten in einem Formular nur als read-only Felder angezeigt werden.
Grund:
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.
Grund:
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
Oracle Application Express Tipps für Entwicklung und Betrieb
31
Items, die lediglich auf einer bestimmten Seite vorkommen, sollten (genau
wie
die
von
APEX
automatisch
erzeugten
Items)
der
folgenden
Namenskonvention entsprechen:
P<Seitennr.>_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
Grund:
Die Applikations-ID kann sich ändern und dann würden die Zusammenhänge
verloren gehen.
Namenskonvention:
A_ELEMENTNAME
Oracle Application Express Tipps für Entwicklung und Betrieb
32
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
Grund:
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.
Grund:
Damit werden Konflikte vermieden, falls zwei Entwickler an derselben Seite
arbeiten
Oracle Application Express Tipps für Entwicklung und Betrieb
33
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.
Grund:
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
34
Grund:
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!
Grund:
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.
Grund:
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 APEXRepository abgelegt werden. Das kann unter Shared Components Files
Static Files geschehen.
Grund:
Somit hat der Entwickler immer Zugriff auf den Code und muss nicht den
Administrator kontaktieren
Oracle Application Express Tipps für Entwicklung und Betrieb
35
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).
Grund:
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.
Grund:
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.
Grund:
Alle Elemente auf dieser Seite werden auch auf allen anderen Seiten angezeigt
bzw. sind auch dort verfügbar
Oracle Application Express Tipps für Entwicklung und Betrieb
36
Abbildung 15 Beispiel für eine Page 0 mit Menu und Report
Die Page 0 sollte nicht übermässig gefüllt werden.
Grund:
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.
Grund:
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.
Grund:
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
37
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
38
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.
Grund:
So werden alle benötigten Übersetzungen in einer Datei bereitgehalten
Abbildung 19 Anlegen der Texte
Wertelisten sollten immer über statische LOVs angelegt werden.
Grund:
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
Grund:
Aktuell gemachte Änderungen werden beim Entwickeln in der Applikation
sonst nicht angezeigt
Oracle Application Express Tipps für Entwicklung und Betrieb
39
Für dynamische Wertelisten sollte APEX_LANG.LANG und für dynamische
Übersetzung von Messages APEX_LANG.MESSAGES verwendet werden
Grund:
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.
Grund:
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
Grund:
Die primäre Sprache einer Anwendung muss immer installiert sein, bevor eine
übersetzte Anwendung installiert werden kann
Oracle Application Express Tipps für Entwicklung und Betrieb
40
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.
Grund:
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?
Oracle Application Express Tipps für Entwicklung und Betrieb
41
Master Applikationen sollten immer Beispielseiten enthalten, in denen die
Komponenten verwendet und idealerweise auch erklärt werden.
Grund:
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.
Grund:
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
Oracle Application Express Tipps für Entwicklung und Betrieb
42
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
Oracle Application Express Tipps für Entwicklung und Betrieb
43
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)
Oracle Application Express Tipps für Entwicklung und Betrieb
44
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
Oracle Application Express Tipps für Entwicklung und Betrieb
45
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 UpdateSkripts 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.
Oracle Application Express Tipps für Entwicklung und Betrieb
46
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
47
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
48
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
Oracle Application Express Tipps für Entwicklung und Betrieb
49
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
50
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
51
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
52
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!
Oracle Application Express Tipps für Entwicklung und Betrieb
53
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_ENVVariable „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!
Oracle Application Express Tipps für Entwicklung und Betrieb
54
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.
Grund:
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
Grund:
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
55
Grund:
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.
Grund:
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
Grund:
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
56
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 APEXAnwendungen 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
-----------------------------APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
GRUPPE
--------------PRIO_HIGH
PRIO_LOW
OTHER_GROUPS
OTHER_GROUPS
OTHER_GROUPS
OTHER_GROUPS
OTHER_GROUPS
STATE
CPU_TIME CPU_WAIT_TIME
--------------- ---------- ------------RUNNING
5077
0
WAITING FOR CPU
2409
4882
WAITING
8988
8266
WAITING
8061
8013
WAITING
9068
1
WAITING
4035
0
WAITING
18297
76
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
Oracle Application Express Tipps für Entwicklung und Betrieb
57
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 <App Id><Page>
Client Info
User
Action
PAGE <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.
Oracle Application Express Tipps für Entwicklung und Betrieb
58
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.
Grund:
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
Oracle Application Express Tipps für Entwicklung und Betrieb
59
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.
Oracle Application Express Tipps für Entwicklung und Betrieb
60
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
Oracle Application Express Tipps für Entwicklung und Betrieb
61
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
Oracle Application Express Tipps für Entwicklung und Betrieb
62
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
entsprechender
Möglichkeit,
Filter lässt
Versionen
sich
von
einstellen,
Applikationen
der
selektiert,
zu
vergleichen.
Ein
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
Oracle Application Express Tipps für Entwicklung und Betrieb
63
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
Oracle Application Express Tipps für Entwicklung und Betrieb
64
Remote-Debugging mit dem SQL Developer und Application Express
http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/remote-debug/index.html
Oracle Application Express Tipps für Entwicklung und Betrieb
65
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
