Download - APEX Coding Guidelines 1 0 HiRes2
-
oracle applicaTion express
Tipps fr enTWicklunG und BeTrieB
Version 1.0
-
Oracle Application Express Tipps fr Entwicklung und Betrieb Trivadis AG
Dokument Version 1.0 2011 Trivadis AG
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 2
Vorwort
Urban Lankes CEO Trivadis
Die hier entstandenen Richtlinien und Empfehlungen sind ein wertvoller Baustein fr die effiziente Entwicklung von Applikationen mit Oracle Application Express. Je frher man Fehler findet, desto weniger Kosten entstehen spter bei der Behebung. Deshalb sind klare Richtlinien und Vorgaben in der Entwicklung, basierend auf langjhrigen Erfahrungen, besonders wertvoll. Unabhngig von der Grsse und der Bedeutung einer Applikation und unabhngig 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.
Carsten Czarski Leitender Systemberater Oracle
Seit 2003 ist APEX ein Bestandteil der Oracle Datenbank und erlaubt die schnelle und flexible Erstellung datenbankgesttzter Web-Anwendungen. APEX ist inzwischen sehr populr: 1200 registrierte Leser der deutschsprachigen APEX-Community im September 2011 und mehr als 20 Vortrge 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 wnsche ich viel Spass und neue Erkenntnisse bei der Lektre und stets gutes Gelingen bei der Entwicklung mit APEX.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 3
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 fr die Sicherstellung von Qualitt in Entwicklungsprojekten dienen und sie sollen helfen, bekannte Probleme zu vermeiden.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 4
Lizenz Geschtzte Marken
Alle Bezeichnungen, die dem Autor als geschtzte Marken bekannt sind, wurden entsprechend gekennzeichnet. Alle Schutzrechte sind Eigentum der rechtmssigen Eigentmer.
Haftungsausschluss
Die Autoren und Herausgeber schliessen jegliche Haftung aus fr eventuelle direkte oder indirekte Schden, die aus der Nutzung oder Anwendung der aufgefhrten Informationen entstehen. Die Informationen knnen 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 Aktualitt der Informationen zu gewhrleisten.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 5
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 eingefgt
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 fr Entwicklung und Betrieb 6
Inhaltsverzeichnis Vorwort .................................................................................................................................. 2
Lizenz ..................................................................................................................................... 4
Geschtzte 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 Schlsselworte ........................................................................................................................... 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 fr Elemente ....................................................................................... 31 4.7 Pages, Items, Shared Components & Co. ............................................................................. 33
5 Deployment .................................................................................................................. 43
5.1 Deployment-Arten......................................................................................................................... 43 5.2 Empfehlungen fr das Deployment ........................................................................................ 45
6 Betrieb .......................................................................................................................... 48
6.1 Instanzen ........................................................................................................................................... 48 6.2 Versionen .......................................................................................................................................... 49 6.3 Workspace Design ......................................................................................................................... 49
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 7
6.4 Security .............................................................................................................................................. 50 6.5 Userverwaltung ............................................................................................................................... 51 6.6 Accounting (Ressourcennutzung)............................................................................................ 56 6.7 Monitoring........................................................................................................................................ 57
7 Hilfsmittel und Tools ................................................................................................... 58
Referenzen ........................................................................................................................... 64
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 8
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 gendert 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 fr 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 enthlt ..................................................... 39 Abbildung 19 Anlegen der Texte ................................................................................................................. 39 Abbildung 20 Einstellungen auf Ebene der Komponenten ............................................................... 40 Abbildung 21 Einstellungen fr 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 Mglichkeiten 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 prfen mittels Views ............................................................. 51 Abbildung 34 User-Einstellungen ................................................................................................................ 52 Abbildung 35 Konfiguration fr 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 Verschlsselung einstellen ........................................................................................ 56 Abbildung 40 Ansicht Metriken im OEM .................................................................................................. 57 Abbildung 41 Beispiel fr 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 Zustzliches Verzeichnis im SQL Developer fr APEX ............................................. 61
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 9
Abbildung 46 Anzeigemglichkeiten auf Level Applikation ............................................................. 61 Abbildung 47 Berichte auf Applikationsebene ....................................................................................... 61 Abbildung 48 Berichte auf Seitenebene ................................................................................................... 61 Abbildung 49 Oberflche des Firebug ....................................................................................................... 62 Abbildung 50 Applikationsvergleich innerhalb APEX .......................................................................... 63 Abbildung 51 Auf Seitenebene verfgbare Utilities ............................................................................. 63
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 10
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 fr 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 Schlsselworte sind blau markiert
FETT Wichtige Begriffe sind fett markiert
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 11
1.2.3 Schlsselworte
Folgende Schlsselworte bewerten die Wichtigkeit der Richtlinien und Empfehlungen:
Schlsselwort 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 mglich unterlassen werden, es kann aber berechtigte Ausnahmen geben
Versuchen Regel oder Empfehlung, die wann immer mglich und passend angewendet werden sollte
Beispiel Veranschaulichung einer Regel oder Empfehlung
Grund Erklrt 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 fr Entwicklung und Betrieb 12
2 Warum Standards und Richtlinien wichtig sind
Um Projekte mit mehreren beteiligten Personen in einem definierten Rahmen zu halten und die Arbeit fr alle einfacher und nachvollziehbarer zu machen, mssen Standards und Richtlinien definiert werden, an die sich die Projektmitglieder halten mssen. Werden fr solche Projekte keine derartigen Strukturen geschaffen, gibt es:
Probleme in der Kommunikation durch unterschiedliches Verstndnis 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 fr einzelne Projekte erweitert bzw. verringert werden knnen.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 13
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 untersttzt. Der Listener kann in ausreichendem Masse optimiert werden. Vorteile:
Schnell einsatzbereit, geringe Konfiguration ntig Nachteile:
Nicht fr grssere 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 fr Entwicklung und Betrieb 14
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. mglich, daher fr grssere Netzwerke geeignet Weitreichende Konfigurationsmglichkeiten fr Security Anforderungen Hufig eingesetzte und bewhrte Variante, dadurch sind viele Erfahrungen im Internet
verfgbar
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 knnen verschiedene Application Server in Betrieb genommen werden, da sich der APEX-Listener durch seine Java-Basis in vielen Servern einsetzen lsst. Zu den Application Servern gehren:
Oracle WebLogic Server Oracle GlassFish Server OC4J
Vorteile:
Rewrite, Proxy etc. mglich, daher fr grssere Netzwerke geeignet
Nachteile:
Noch nicht ausreichend getestet, mehr Konfigurationsaufwand
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 15
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 grsseren Anzahl von Browsern getestet werden, wenn die Anwendung im Intranet oder Internet verfgbar ist. Um Flash Charts und Flash Maps darstellen zu knnen, sollte auch immer der aktuellste Flash-Player installiert sein.
3.4 Rollen und Aufgaben bei APEX
Aufgaben eines Datenbankadministrators
Der DBA sollte nur das Grundgerst (das Schema und den Workspace) fr die Verwendung von APEX stellen. Alles andere sollte in den Hnden des Entwicklers liegen.
Technologische Schwerpunkte eines Entwicklers
APEX vereint viele verschiedene Technologien, die zur Erstellung einer Anwendung verwendet werden knnen. Nachfolgend eine bersicht der Schwerpunkte, die ein APEX-Entwickler abdecken sollte:
Ein APEX-Entwickler muss mit den Mglichkeiten, 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 Funktionalitt und Geschftslogik umsetzen zu knnen. Durch den Query Builder in den APEX Wizards ist
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 16
es auch Anwendern ohne spezifische SQL-Kenntnisse mglich, Berichte und Formulare zu erstellen.
CSS und HTML Kenntnisse werden dann bentigt, wenn Themes bzw. Templates in APEX angepasst werden mssen, 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 fr 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 fr JavaScript. Fr die Versionen vor 4.0 ist es sehr vorteilhaft, Kenntnisse in diesem Bereich zu haben, um z. B. Werte von Formularfeldern zu berprfen, ohne die komplette Seite aktualisieren zu mssen. APEX bietet ab Version 4.0 Dynamic Actions an, die es ermglichen, client-seitige Funktionen deklarativ zu definieren. Dadurch wird ein Grossteil der bentigten 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 mglich ist und wie gewnschte Anforderungen sinnvoll umgesetzt werden knnen. Ein Anwender sollte die entsprechende fachliche Kompetenz fr die Bedienung der Anwendung mitbringen und mittels einer Schulung auf die Arbeit mit der Anwendung vorbereitet werden.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 17
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 vllig 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 knnen 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 mglich, PL/SQL Code direkt auszufhren. Aus Grnden der Wartbarkeit und Modularisierung ist allerdings zu empfehlen, dass Geschftslogik stets innerhalb von Packages, durch Funktionen oder Prozeduren, realisiert und somit in die Datenbank ausgelagert werden. Sofern PL/SQL in der Oberflche verwendet werden muss, sollte dies soweit wie mglich nur ber Aufrufe von Funktionen und Prozeduren erfolgen.
Die PL/SQL und SQL Coding Guidelines von Trivadis beinhalten Standards, Best Practices, Empfehlungen und Beispiele fr den richtigen Einsatz von PL/SQL und SQL in Projekten. Die Namenskonventionen fr Datenbankobjekte und fr PL/SQL Variablen in diesem Dokument sind auch fr APEX Anwendungen relevant.
Trivadis PL/SQL und SQL Coding Guidelines
http://www.trivadis.com/PLSQL-Guidelines
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 18
4.2 Das Fundament: die Datenmodellierung
Primrschlssel fr Tabellen
Alle Tabellen, die in APEX Insert/Update/Delete erfahren, sollten einen Primrschlssel haben. Dieser Primrschlssel sollte ein knstlicher Schlssel sein, der idealerweise ber einen Before Insert or Update Trigger aus der zugehrigen Sequence gezogen wird. Die Eindeutigkeit der Datenstze bzw. bestimmter Attribute kann dann ber einen Unique Constraint sichergestellt werden. Bis Version 4.0.x sollten Primrschlssel fr Tabellen maximal zwei Attribute beinhalten. Grund:
In den APEX Wizards knnen nur zwei Attribute fr einen Primrschlssel angegeben werden
Die Standard DML Operationen knnen sonst nicht genutzt werden Ab Version 4.1 wird als Standardeinstellung die ROWID vorgeschlagen, um
Datenstze in DML Operationen eindeutig zu identifizieren. Dadurch knnen die Standard DML Operationen auch fr Tabellen mit einem Primrschlssel, 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 knnen Konflikte mit anderen Objekten auf DB Ebene entstehen
Datenbanklinks
Bei der Verwendung von Datenbanklinks sollte fr jede Zieltabelle oder Zielview eine View im Parsing Schema angelegt werden. Grund:
Die Wizards innerhalb APEX knnen diese Datenquelle sonst nicht erkennen
Performance Verschlechterungen, welche hier eventuell auftreten, knnen mit Snapshots umgangen werden!
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 19
Auditing Attribute
Jede Tabelle sollte Attribute besitzen, die pro Datensatz den Ersteller mit Erstelldatum und den Editor mit Editdatum ausweisen. Das Fllen dieser vier Spalten sollte ber Before-Insert-Update-Trigger bewerkstelligt werden. Grund:
nderungen an Daten knnen so einfacher nachvollzogen werden Der Audit passiert direkt in der Datenbank und muss nicht in der Anwendung
bercksichtigt werden
Geschftslogik von Visualisierung trennen
Geschftslogik 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 enthlt, kann er ohnehin vollstndig in die DB ausgelagert werden. Generell sollte so viel Geschftslogik wie mglich in die DB ausgelagert bzw. so wenig PL/SQL Code wie mglich in APEX hinterlassen werden. Es sollten lediglich die fr 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 mglich Mehrfachverwendung von Code mglich (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 smtliche 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 fr Entwicklung und Betrieb 20
Berechtigungen
Berechtigungen mssen direkt an das Workspace-Schema vergeben werden und drfen 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 to user funktioniert nicht mit APEX
4.3 Application Builder
Welchen Applikationstyp nehme ich fr 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 Funktionalitten zur Verfgung, 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 unzhligen Stellen innerhalb des Application Builders die Mglichkeit dazu. Daher sollten diese Anwendungen auch ausschliesslich von Entwicklern mit entsprechendem Know-how erstellt werden. Websheet Applikationen knnen 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 fr eine bestimmte Fachabteilung nutzbar und sollte ebenso durch einen Anwender aus der Fachabteilung erstellt werden. Hier knnen Daten aus Excel kopiert und verffentlicht werden. Falls gewnscht, knnen sie auch bearbeitet werden. Es werden dazu Berichte, Formulare, HTML-Editoren, Diagramme oder auch Data Grids zur Verfgung gestellt. Die Daten
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 21
werden in durch APEX verwalteten Tabellen gespeichert. Deshalb mssen 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 gewhlt werden, muss je nach Projekt in Abhngigkeit der Komplexitt, Funktionalitt und Anforderungen getroffen werden. Bei Big Apps knnen pro Applikation mehre Oracle Schemas (Parsing Schemas) zugeordnet werden, da hier hufig auch Daten aus mehreren Quellen bezogen werden mssen. Bei Partitioned Apps sollte jedoch pro Modul (also pro App) nur ein Oracle Schema (Parsing Schema) verwendet werden. Diese Bedingung knnte sogar dazu dienen, eine Big App in eine Partitioned App und somit in Module zu berfhren. Big Apps Vorteile
Verzweigungen innerhalb der Applikation Nur eine Anmeldemaske (kein Single Sign-on notwendig)
Nachteile
Deployment von einzelnen Modulen fast nicht mglich Keine modulare Versionierung Potentiell wieder verwendbare Module knnen nicht wieder verwendet
werden
Partitioned Apps Vorteile
Modulares Deployment mglich Modulare Versionierung mglich Einfacheres Entwickeln in grsseren Entwicklungsteams
Nachteile
Single Sign-on notwendig, da sonst pro Applikation ein Anmeldedialog erscheint
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 22
Nummernkreise fr Seiten und Anwendungen
Fr Anwendungen sollten Nummernkreise verwendet und konstant ber Test und Produktion beibehalten werden. Fr 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 Zusammengehrigkeit 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
Grund:
Erkennbarkeit der fachlichen bzw. technischen Zuordnung der Seite Einheitliches Gerst fr die Nummerierung
Es sollte fr eine Anwendung eine feste Anwendungs-ID pro APEX-Instanz verwendet werden. Grund:
Die Anwendungs-ID fr bersetzte Anwendungen darf nicht verndert 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 fr Entwicklung und Betrieb 23
Alias
Vorsicht bei der Vergabe von Aliasen, die sowohl auf Anwendungsebene als auch auf Seitenebene vergeben werden knnen. 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 Prfix entsprechend gekennzeichnet werden. Das Theme sollte jedoch eine Kopie eines bestehenden APEX-Themes sein. Dieses Theme muss mit der Applikation ausgeliefert werden. Grund:
Die Kompatibilitt wird bewahrt Wechsel zwischen dem eigenen und einem APEX-Theme ist mglich
nderungen am Layout in einzelnen Seiten sollten vermieden werden. Grund:
Sie sind schwierig zu debuggen Sie knnen bei zustzlichen nderungen im zentralen Theme (CI Theme) zu
Problemen fhren
Zustzliche 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 fr Entwicklung und Betrieb 24
Abbildung 5 CSS ins APEX-Repository hochladen
UI Defaults (User Interface)
Die UI Defaults knnen genutzt werden, damit beim Aufrufen der gleichen Tabellen und Views die entsprechenden Spalten immer in der gleichen Art und Weise angezeigt werden. Hier knnen Symbole wie z. B. das Editier-Icon fr die gesamte Applikation (oder sogar Workspace) festgelegt werden. Grund:
Hherer 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 mssen
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 25
Abbildung 6 Bild-Verwaltung in APEX
Security bei der Entwicklung
Das Feature Schutz fr den Sessionzustand sollte generell aktiviert sein. Pro Seite sollte das Attribut Schutz fr den Sessionzustand auf Argumente mssen Prfsumme haben gesetzt werden. Es empfiehlt sich, als Mindestanforderung dieses Attribut fr jedes Element auf Prfsumme erforderlich auf Sessionebene zu konfigurieren.
Abbildung 7 Session State Protection Einstellungen
Selbsterstellte URLs erhalten dank der Prozedur apex_util.prepare_url automatisch eine Prfsumme:
apex_util.prepare_url( p_url => 'f?p= ' || :APP_ID || ':15:' || :APP_SESSION || '::NO::P1_X:foo);
Grund:
Automatische berprfung der URL mittels Checksum
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 26
Es ist bei einem APEX Projekt oftmals nicht abzusehen, wie wichtig die Anwendung spter sein wird und wie kritisch sie betrieben wird
Session State Protection nachtrglich einzubauen ist mit viel Aufwand verbunden
Alle Texte, die an den Browser zurckgegeben werden, sollten escaped werden, damit eventuell enthaltener JavaScript-Code nicht durch den Browser interpretiert wird. Dazu knnen 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 zurckgibt, , 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 whlen. 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 verschlsselt in der Benutzersession gespeichert werden. Dazu wird das Elementattribut Wert verschlsselt in Sessionzustand speichern auf "Ja" gesetzt. Grund:
Die Werte der Elemente knnen 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. Grund:
Schutz gegen SQL-Injection
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 27
Versionsnummerierung
In der APEX Applikation Definition sollte das Feld Version gefllt 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 Funktionalitten, APEX Code- und Schemanderungen)
2. Stelle Minor Release (Neue Funktionalitten, APEX Code- und Schemanderungen)
3. Stelle Service Pack (APEX Code- und Schemanderungen) 4. Stelle FixPack APEX ( Nur APEX Codenderungen) 5. Stelle FixPack Schema (Nur Schemanderungen)
Abbildung 8 Anzeige der Versionsnummer in der Anwendung
4.4 Reports
SQL Reports
SQL Reports sollten fr dynamische Anzeigen verwendet werden, die vom Benutzer aber nicht gendert werden sollen. Grund:
Einfach zu implementierende Standardfunktionalitt
Interactive Reports
Fr flexible Reporting Anforderungen sollten Interactive Reports immer eingesetzt werden! Grund:
Hohe Flexibilitt in der Visualisierung (Filtern, Gruppieren, Suchen, Highlighting,)
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 28
Nicht gewollte Funktionen knnen gesperrt werden Konfigurierte Reports eines Users knnen mit anderen Usern geteilt werden
(sie knnen 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 standardmssig angezeigt werden. Grund:
So werden grssere Berichte lesbarer, da sie nur relevante Informationen bieten
Spaltenberschriften
Den Heading Type der Spalten eines Reports grundstzlich auf Custom, wenn ntig auch PL/SQL oder None stellen. Grund:
Die fixe Spaltenberschrift wird nicht im bersetzungsrepository (XLIFF) bercksichtigt (siehe Mehrsprachige Applikationen)
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 29
4.5 Formulare
Formulare mit automatischen Prozessen
Hierbei werden die APEX-Standard-Prozesse genutzt, um DML Operationen durchzufhren. Diese sollten fr Dialoge verwendet werden, die nur Standard-Funktionalitt auf eine Tabelle und wenig Geschftslogik bentigen. Grund:
Auf eine Tabelle beschrnkt Nur ein Formular pro Seite mglich Fehlermeldungen sind schwer nachvollziehbar nderungen sind aufwndiger Grundsatz Trennung von Logik zu Visualisierung verletzt
Formulare mit eigenen Prozessen
Insert, Update und Delete Prozesse, die ber die APEX-GUI ausgefhrt werden, sollten immer ber entsprechende Prozeduren in einem Package erfolgen. Grund:
Mehrere Datenbankobjekte knnen angesprochen werden Hhere Flexibilitt bezglich 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 knnen nachtrgliche nderungen einfacher erfolgen Teile der Geschftslogik werden in die Datenbank ausgelagert und nicht in der
APEX Applikation selbst gehalten
Tabular Forms
Tabular Forms sollten wie Formulare mit automatischen Prozessen fr Dialoge verwendet werden, die nur Standard-Funktionalitt auf eine Tabelle und wenig Geschftslogik bentigen. 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 fr viele
Anforderungen
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 30
Abbildung 10 Beispiel einer Tabular Form Mit APEX 4.1 gibt es erhebliche Verbesserungen im Bereich Tabular Forms. Dazu zhlen die erweiterten Validierungsmglichkeiten, 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 --IDloopupdate my_tableset my_column = apex_application.g_f02(i)where id = apex_application.g_f01(i);
end loop;
NEU (mit 4.1):update my_tableset my_column = :MY_COLUMN-- MY_COLUMNwhere 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 fr viele
Anforderungen
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 31
Besteht fr den Master-Detail eine Fremdschlsselverbindung, darf beim Lschen des Masters nicht vergessen werden, dass die Details mitgelscht werden mssen oder zu mindestens der Fremdschlssel auf NULL gesetzt werden muss. Dies kann entweder ber einen Trigger oder ber einen Fremdschlssel mit ON DELETE CASCADE bzw. ON DELETE SET NULL umgesetzt werden. Grund:
APEX hlt eine solche Funktionalitt nicht bereit Kann zu Fehlermeldungen fhren, 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 mssen
4.6 Namenskonventionen fr Elemente
Seiten-Elemente (Variablen, Prozesse, Berechnungen, Validierungen)
Die Namen von Seitenobjekten, die APEX bei Verwendung von Assistenten generiert hat, sollten im Nachhinein nicht gendert werden. Grund:
Bei der Vielzahl von originalen und nachtrglich hinzugefgten Objekten, die sich gemischt in einer Seite befinden, kann man so die automatisch erzeugten besser von den hinzugefgten Objekten unterscheiden
Daraus lassen sich Rckschlsse auf deren jeweilige Funktionalitt ziehen
Berichte sollten im Plural und Formulare im Singular benannt werden! Beispiel fr einen Bericht:
BESTELLUNGEN
Beispiel fr ein Formular:
BESTELLUNG
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 32
Items, die lediglich auf einer bestimmten Seite vorkommen, sollten (genau wie die von APEX automatisch erzeugten Items) der folgenden Namenskonvention entsprechen:
P_ITEMNAME
Beispiel fr ein Item:
P4711_ARTIKELNUMMER
Schaltflchen werden so benannt, wie der Request, den sie abgeben, jedoch ohne Seiten-Prfix. Beispiel fr eine Schaltflche:
ARTIKEL_BESTELLEN
Prozesse sollten typischerweise so heissen wie der Request, auf den sie reagieren und ebenfalls ohne Seiten-Prfix sein. (Da Prozesse jedoch auch auf mehrere Requests reagieren knnen, lsst sich allein aus dem Namen noch keine vollstndige Aussage ber die Arbeitsweise ableiten. In diesem Fall ist ggf. ein anderer, aussagekrftiger Name zu whlen). Beispiel fr einen Prozess:
ARTIKEL_BESTELLEN
Applikations-Elemente (Variablen, Prozesse, Berechnungen, Validierungen)
Fr anwendungsweit gltige Items, Prozesse, etc. sollte das Prfix A_ (fr Applikation/Anwendung) verwendet werden. Die Anwendungs-ID, welche APEX zunchst zur Benennung vorschlgt, ist kein robuster Ansatz und sollte entfernt werden Grund:
Die Applikations-ID kann sich ndern und dann wrden die Zusammenhnge verloren gehen.
Namenskonvention:
A_ELEMENTNAME
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 33
Beispiel fr ein Anwendungs-Item:
A_JAHR
Beispiel fr einen Anwendungs-Prozess:
A_ARTIKEL_BESTELLEN
Benennung von Schaltflchen
Bei durch Wizards generierten Schaltflchen drfen die Namen (Button Name) nicht umbenannt werden. Bei solchen Schaltflchen darf nur das Label (Text Label/Alt) gendert werden.
Abbildung 11 Button Name darf nicht gendert werden
Grund:
Beim Verwenden der Wizards nutzt APEX die Namen von Schaltflchen als Wert fr den Anwendungs-Request. Auf diesen Request-Wert (in der deutschen Entwicklungsumgebung: "Anforderung") reagieren Prozesse, die beispielsweise Berechnungen oder DML-Befehle durchfhren. Wrde sich der Request (durch Umbenennen des Buttons) ndern, msste man die Prozesse ebenfalls ndern.
4.7 Pages, Items, Shared Components & Co.
Pagelock whrend 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 fr Entwicklung und Betrieb 34
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 fr alle Items Kommentarfelder zur Verfgung. In diese Felder sollte der Entwickler unbedingt die notwendigen Informationen schreiben. Grund:
Dokumentation ist ein Must Have, da die Ablufe in APEX-Formularen sehr frei gestaltbar sind und pro Seite eine Vielzahl an Objekten existieren kann, deren Zweck durchaus nicht selbsterklrend ist
Die Kommentarfelder knnen per SQL ausgewertet und als Gesamtdokumentation verwendet werden
Hilfetexte fr den Anwender
In der Anwendung sollte in Items und Seiten der Hilfetext gefllt werden. Das Gleiche gilt fr die Rckmeldungen (Error- und Erfolgsmeldungen) von Prozessen und Validierungen. Es ist durchaus empfehlenswert, die von APEX vorgegebenen Fehlermeldungen ("Hinzufgen von Zeile nicht mglich") durch spezifischere, fachlich aussagekrftigere Versionen zu ersetzen.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 35
Grund:
So wird dem Anwender die grsstmgliche Hilfestellung geboten, um mit der Anwendung arbeiten zu knnen
Verstndliche und konkrete Fehlermeldungen erhhen die Akzeptanz des Anwenders gegenber 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 fr Wertzuweisungen Dynamic Actions. Diese sollten jedoch vorzugsweise bei Wertzuweisungen, die ohne einen PageLoad auskommen mssen, eingesetzt werden. Hierbei kommt Ajax zum Einsatz! Grund:
Die Methode des OnPageLoad Prozesses hat sich in der Praxis bewhrt Die Dynamic Actions sind erst ab APEX 4 verfgbar und sind schwerer zu
debuggen
JavaScript
Mittels JavaScript knnen clientseitige Aktionen ausgefhrt werden. Wenn mglich 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
Zustzlicher 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. Grund:
Somit hat der Entwickler immer Zugriff auf den Code und muss nicht den Administrator kontaktieren
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 36
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 knnen oder Mails zu versenden, gibt es in der APEX API entsprechende Aufrufe: APEX_PLSQL_JOB und APEX_MAIL. Grund:
Alle Funktionalitt ist auf APEX abgestimmt, untersttzt und dokumentiert
Page 0
Page 0 sollte fr 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 ausgewhlten Wert stehen. Grund:
Alle Elemente auf dieser Seite werden auch auf allen anderen Seiten angezeigt bzw. sind auch dort verfgbar
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 37
Abbildung 15 Beispiel fr eine Page 0 mit Menu und Report Die Page 0 sollte nicht bermssig gefllt werden. Grund:
Da die Seite bei jedem Seitenaufruf mitgeladen wird, geht dies zu Lasten der Performance
Page 999
Page 999 ist reserviert fr den Standard Output von CGI_ENV. Grund:
Dient zum Debuggen der Benutzerumgebung
Feedbackformular
Der Benutzer sollte direkt aus der Anwendung einen Prozess starten knnen, 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 fr Entwicklung und Betrieb 38
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 Abhngigkeit z. B. von der Browsersprache unterschiedliche Formatmasken zurckliefert.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 39
Abbildung 18 Angabe des Items, das die Formatierung enthlt Fr die bersetzung der internen APEX Messages sollten zunchst nur die Texte fr die Primary Language angelegt werden. Dann werden diese in ein XLIFF-File exportiert, bersetzt und wieder hochgeladen. Dadurch wird eine weitere Sprache hinzugefgt. Dies sollte nicht ber manuelles Anlegen der Texte fr eine weitere Sprache erfolgen. Grund:
So werden alle bentigten 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 fr Entwicklung und Betrieb 40
Fr dynamische Wertelisten sollte APEX_LANG.LANG und fr 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 fr den bersetzer auf das Notwendigste reduziert werden
Abbildung 20 Einstellungen auf Ebene der Komponenten
Abbildung 21 Einstellungen fr das XLIFF-File
Fr jede bersetzung erstellt APEX eine Kopie der Anwendung. Beim Import der Anwendung in einen neuen APEX Workspace muss in folgender Reihenfolge vorgegangen werden:
1. Primre Anwendung installieren 2. Die bersetzte(n) Anwendung(en) installieren
Grund:
Die primre Sprache einer Anwendung muss immer installiert sein, bevor eine bersetzte Anwendung installiert werden kann
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 41
Master Applikation
In jedem Workspace sollte eine Master Applikation zu finden sein. In dieser Applikation knnen das CI Layout, die UI Defaults, immer wiederkehrende Items wie z. B. LOVs und Authentisierungs- sowie Autorisierungsschemas implementiert sein. Grund:
Damit knnen 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 knnen
Folgende Komponenten knnen 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 fr Entwicklung und Betrieb 42
Master Applikationen sollten immer Beispielseiten enthalten, in denen die Komponenten verwendet und idealerweise auch erklrt werden. Grund:
So lsst 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 fr den Anwender verfgbar sein. Grund:
So hat der Anwender immer die Mglichkeit, Hilfe im Umgang mit den zur Verfgung gestellten Funktionen zu finden
Abbildung 24 Dokumentation in der Anwendung
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 43
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 knnen Applikationen, Teile von Applikationen, Bilder, CSS usw. per Mausklick aus einer Umgebung exportiert und in der gewnschten Umgebung importiert werden.
Abbildung 26 Mglichkeiten des Exports ber die APEX GUI Ein Sonderfall ist der Export eines Workspaces, da dieser nur durch den APEX-Admin ausgefhrt werden kann. Vorteil:
Keine Programmierung ntig Wird von Oracle untersttzt
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 44
Nachteil:
Export/Import nur einzeln mglich, daher arbeitsintensiv bei vielen Applikationen Kann nicht ber einen Job gehandhabt und damit zeitgesteuert angestossen werden
SQL Developer
ber den SQL Developer knnen ebenfalls Applikationen exportiert und importiert werden. Das ist ber das Kontextmen beim Klick auf die einzelnen Anwendungen mglich.
Abbildung 27 Kontextmen Application Express im SQL Developer Vorteil:
Keine Programmierung ntig
Nachteil:
Export/Import nur einzeln mglich, daher arbeitsintensiv bei vielen Applikationen Kann nicht ber einen Job gehandhabt und damit zeitgesteuert angestossen werden
APEXExport Utility
Das Exportwerkzeug wird standardmssig 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. Fr den Import wird dann die erzeugte SQL-Datei ausgefhrt. Vorteil:
Wird von Oracle untersttzt Durch Jobs steuerbar
Nachteil:
Kein Export von Bildern und Dateien (Ausnahme Supporting Objects)
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 45
APEX API
Exporte knnen ebenfalls mit diversen APEX APIs wie z. B.
wwv_flow_utilities.export_application_to_clob(..)
gemacht werden. Fr den Import werden dann mit dem Package
apex_application_install
entsprechende Parameter gesetzt und die erzeugte SQL-Datei ausgefhrt. Vorteil:
Individuelle Lsung, Bilder und Dateien exportierbar Durch Jobs steuerbar
Nachteil:
Einmaliger Programmieraufwand Kein Support von Oracle
5.2 Empfehlungen fr das Deployment
Fr das Deployment wird eine Kombination aus den aufgefhrten Mglichkeiten zur Kommandozeile empfohlen. Fr alle Workspaces, Applikationen und Websheets sollte das APEXExport Utility und fr 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 knnen dann mittels Jobs ber die Kommandozeile ausgefhrt 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 fr Entwicklung und Betrieb 46
Supporting Objects
Hier knnen Skripte abgelegt werden, die zur Anpassung des bzw. der DB-Schemas dienen. Diese Skripte sollten jedoch nicht ber die GUI ausgefhrt 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 Ausfhrung der einzelnen Skripte nicht greifen. In diesem Fall ist es besser, manuell nur die Skripte auszufhren, die man bentigt. Wenn Bilder und andere bentigte 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 durchgefhrt werden muss.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 47
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 fr das Einrichten von Usern, die in der Test- oder Produktivumgebung zustzlich bentigt werden, hngt von der entsprechenden Authentifizierungsmethode ab, wie nachfolgend beschrieben.
Application Express
Bei dieser Methode sollten smtliche 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 fr 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 prft und fr SSO berechtigt, kann hier User entfernen oder hinzufgen. In APEX mssen keine Anpassungen gemacht werden.
Test nach Produktion
In der Test-Instanz sollten, wenn irgendwie mglich, 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 mssen 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 fr die Produktivumgebung.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 48
6 Betrieb 6.1 Instanzen
Entwicklung
Die Entwicklungsumgebung sollte mit dem Aufbau der Testumgebung bereinstimmen. Alle Abweichungen knnen zu Fehlern fhren, die erst auf der Testebene auftreten. Der Entwickler sollte hier mit dem grsstmglichen Umfang an Rechten ausgestattet sein, um seine Entwicklungen auch zgig umsetzen und testen zu knnen.
Test
Die Testumgebung sollte immer genau wie die Produktivumgebung gehandhabt werden. Hier drfen keine Entwicklungen mehr stattfinden. Auf der Testumgebung sollten deshalb alle Applikationen mit der Option run only installiert werden. Nur so kann gewhrleistet 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 knnen 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, knnen 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 fr Entwicklung und Betrieb 49
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 gegenber 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 fr neue Versionen immer ein Statement of Direction verffentlicht, welches die geplanten Features enthlt.
6.3 Workspace Design
Ein Workspace ist wie ein Container zu betrachten, in dem fr 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 knnen jedoch ergnzend DB-Schemas in einem WS bentigt werden! Dies ist beispielsweise der Fall, wenn Daten aus einem fremden aber fachlich verwandten Schema fr eine LOV oder auch einen Bericht bentigt werden. APEX liefert den WS internal mit. Nur in diesem WS knnen neue WS angelegt werden. Das Anlegen, Lschen oder Verwalten der DB-Schemas fr Workspaces sollte zentral von einer Person gemacht werden. Sinnvollerweise ist das der APEX-Admin.
Abbildung 30 Anmeldung am Workspace internal
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 50
Abbildung 31 Administration ber den Workspace internal
6.4 Security
Authentifizierung
Security ist innerhalb von APEX hauptschlich ein Zusammenspiel von Authentifizierung und Autorisierung. Fr die Authentifizierung werden User und Passwrter bentigt. Nachfolgend ein berblick zu den Mglichkeiten, wie User angelegt und deren Identitt geprft werden kann.
Abbildung 32 Anlegen der Authentifizierungsschemas
Autorisierung
Autorisierung erfolgt ber die entsprechenden Schemas in einer Applikation. Diesen Schemas knnen Items, Regions, Tabs, etc. zugewiesen werden. Es ist empfehlenswert, ein Konzept fr die Autorisierung zu definieren, da anderenfalls schnell der berblick verloren geht. Dabei sollte auf die richtige Granularitt geachtet werden: Nur so granular wie ntig! Nachfolgende Abbildung zeigt Autorisierungsschemas, die ber eine View prfen, ob eine bestimmte Eigenschaft bei dem aktuellen User vorhanden ist.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 51
Abbildung 33 Autorisierungsschemas prfen 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 fr die Anlage der drei Usertypen.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 52
Abbildung 34 User-Einstellungen
Workspace Administrator
Es gibt einen speziellen Workspace-Administrator, der fr den internal WS verantwortlich ist. Dies ist der APEX-Admin. Der APEX-Admin sollte nur den Workspace selbst und den dazugehrigen 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 Hnden. APEX bietet fr dieses Szenario auch Service Requests fr die Workspace Administratoren an.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 53
Developer
Entwickler werden vom WS-Admin angelegt und knnen ab APEX 4.0 darin eingeschrnkt werden, welche Komponenten (Application Builder, SQL Workshop oder Team Development) sie nutzen drfen oder nicht. Das Passwort fr die Entwickler sollte vom DBA auf Require Change of Password on First Use auf yes gesetzt werden, damit der Entwickler sein persnliches Passwort vergeben kann.
Application User
Fr eine Applikation berechtigte Anwender knnen ber verschiedenste Arten angelegt und verwaltet werden. Diese sind immer abhngig vom jeweils verwendeten Authentifizierungsschema. Innerhalb eines Unternehmens sollte es ein einheitliches Verfahren der Anmeldung geben, soweit das technisch mglich 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. Bezglich der Passwrter gilt hier das Gleiche wie bei den Entwicklern.
Wie bindet man die Userverwaltung an LDAP an?
Fr die Anbindung der Anwenderverwaltung an LDAP stellt APEX ein vorkonfiguriertes Authentifizierungsschema bereit, das mit den entsprechenden Angaben zu Server und Pfad der berechtigten Gruppe ergnzt werden muss. Ist ein zentrales LDAP bereits vorhanden und gepflegt, sollte diese Art der Authentifizierung genutzt werden. Dies ermglicht, dass hier kein weiterer Aufwand bezglich der Benutzerverwaltung getrieben werden muss und der Anwender sich kein zustzliches Passwort merken muss!
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 54
Abbildung 35 Konfiguration fr 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. Hierfr gibt es ein Standard-Authentisierungsschema innerhalb von APEX. Unabhngig von der Variante, die fr SSO innerhalb eines Unternehmens gewhlt wird, bentigt 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 ermglicht, solange diese Variable gefllt und damit valide ist. Hierfr sollte die Page Sentry Function innerhalb des Page Session Management verwendet werden, die bei jedem Seitenaufruf geprft werden sollte!
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 55
Abbildung 36 Page Sentry Function mit Package-Aufruf
Wie kann ich zustzlich fr Sicherheit sorgen?
Es sollte mindestens die Edition Standard Edition One der Datenbank fr den produktiven Einsatz verwendet werden. Grund:
Die Datenbank sollte immer auf die letzte Version gepatcht und das letzte Critical Patch Update bercksichtigt werden. Dies ist mit der Express Edition nicht mglich.
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 schtzen
Es sollten beim Webserver (Apache) alle nicht bentigten Apache-Module (PHP, Perl, usw.) abgeschaltet werden, alle nicht bentigten statischen Seiten gelscht 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 fr Entwicklung und Betrieb 56
Grund:
der Webserver bietet so eine geringere Angriffsflche
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 knnen direkte Aufrufe von PL/SQL-Prozeduren per URL eingeschrnkt 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 Verschlsselung einstellen Grund:
Damit wird eine verschlsselte Kommunikation fr 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 (fr Objekte wie Bilder, Dateien etc.) und APEX_XXXXXX fr 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 mglich, alle drei notwendigen Instanzen (Entwicklung, Test, Produktion) auf einem Applikationsserver laufen zu lassen. Es empfiehlt sich jedoch bei grsseren Umgebungen, die Instanzen auch physisch zu trennen und jede auf einem eigenen Server zu betreiben. Die genauen Speicheranforderungen fr den Datenbank-Server sind plattform-spezifisch. Bei einer Anzahl gleichzeitiger Benutzer von 100 oder mehr sollte aber freier Speicher von etwa 512 MB zur Verfgung stehen. Installationen mit einem Speicher von weniger als 128 MB sind nicht zu empfehlen. APEX-Anwendungen profitieren von mehreren CPUs und nicht von hherem Speicher. Schnellere CPUs stellen daher die effizienteste Art dar, wie die Performance von APEX zu optimiert werden kann.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 57
6.7 Monitoring
OEM Database Control
Neben den zahlreichen Berichten und Auswertungen, die APEX standardmssig ber die Administration bietet, lsst 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 Ausfhrungszeit pro Komponente selektiert und es wird im EM konfiguriert, wann welche Meldungen bei welchen Werten angezeigt werden sollen. Ein gutes Beispiel dazu lsst sich in den Community-Tipps finden.
Abbildung 40 Ansicht Metriken im OEM
Ressource Manager
Mit dem Ressource Manager knnen APEX-Anwendungen, Seiten in APEX-Anwendungen oder auch User bezglich der Nutzung vorhandener CPU priorisiert werden. So kann z. B. der Ressourcenverbrauch von Test-Applikationen gegenber Produktiv-Applikationen niedriger gehalten werden. Dazu werden die Anwendungen, Seiten oder User zu sogenannten Consumer Groups zugeordnet. Diesen Gruppen werden dann ber Ressourcen Plne bestimmte Prozentstze von der CPU zugewiesen.
USERNAME GRUPPE STATE CPU_TIME CPU_WAIT_TIME------------------------------ --------------- --------------- ---------- -------------APEX_PUBLIC_USER PRIO_HIGH RUNNING 5077 0APEX_PUBLIC_USER PRIO_LOW WAITING FOR CPU 2409 4882APEX_PUBLIC_USER OTHER_GROUPS WAITING 8988 8266APEX_PUBLIC_USER OTHER_GROUPS WAITING 8061 8013APEX_PUBLIC_USER OTHER_GROUPS WAITING 9068 1APEX_PUBLIC_USER OTHER_GROUPS WAITING 4035 0APEX_PUBLIC_USER OTHER_GROUPS WAITING 18297 76 Abbildung 41 Beispiel fr die Auswirkungen der Ressourcenpriorisierung Welche Applikation, Seite oder User welcher Gruppe angehrt, kann auch zur Laufzeit gendert werden! So kann z. B. fr eine Session eine Abfrage abgebrochen oder sogar die
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 58
gesamte Session abgebrochen werden, wenn der I/O-Wert eine festgelegte Menge berschreitet oder die Ausfhrungszeit zu lang ist. Der Ressourcen Manager ist ab der Enterprise Edition verfgbar und sollte aber - wenn vorhanden - in grsseren Umgebungen auch genutzt werden.
V$Session und DBMS_APPLICATION_INFO
ber das Datenbank Package DBMS_APPLICATION_INFO werden von APEX hilfreiche Parameter fr 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 verfgbar.
Parameter Wert
Modul APEX:APPLICATION
Client Info User
Action PAGE
So knnen 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 mssen.
7 Hilfsmittel und Tools Team Development
Das Team Development ist erst seit APEX 4 erhltlich, verfgt jedoch ber alle notwendigen Funktionen, um innerhalb APEX Features der Anwendungen zu definieren, Milestones festzulegen, Aufgaben zuzuweisen, Bugs zu tracken und vieles mehr. Dadurch knnen externe Tools wie z. B. JIRA abgelst werden.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 59
Abbildung 42 Features im Team Development Es sollten Feedback-Links inklusive Feedbackseiten in jeder Anwendung verfgbar sein, damit der Anwender mgliche Bugs, Kommentare oder auch Anfragen an die Entwickler senden kann.
Plug-Ins (APEX 4)
Plug-Ins knnen auf folgender Seite verffentlicht 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 fr 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 knnen auch fr Komponenten erstellt werden, die innerhalb einer Anwendung oder eines Unternehmens hufig verwendet werden und dienen so quasi als Modul. Fremde Plug-Ins sollten mit Bedacht gewhlt und ausfhrlich getestet werden. Sie sollten nur eingesetzt werden, wenn sie auch wirklich bentigt werden. Grund:
Beim Einsatz von Plug-Ins ist keinerlei Support gewhrleistet Plug-Ins unterschiedlicher Anbieter knnen sich gegenseitig ins Gehege kommen
(Seiteneffekte!)
Abbildung 43 Plug-In Verwaltung in APEX
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 60
APEX 4 Advisor
Der Advisor dient der Qualittssicherung einer Anwendung. Es knnen beispielsweise Referenzen innerhalb einer Anwendung auf ihre Gltigkeit berprft werden und auch viele andere Kontrollen gemacht werden. Anwendungen sollten in regelmssigen Abstnden mit diesem Dienstprogramm geprft 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 Mglichkeiten bietet, um APEX zu verwalten. So knnen 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 hlt auch die ntzliche Funktion des Remote-Debuggings fr APEX-Anwendungen bereit. Nheres dazu lsst sich auf der APEX Community Seite finden, die von Carsten Czarski gestaltet wird.
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 61
Abbildung 45 Zustzliches Verzeichnis im SQL Developer fr APEX
Abbildung 46 Anzeigemglichkeiten 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 fr Entwicklung und Betrieb 62
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. Darber dokumentieren sich die Applikationen gewissermassen selbst. Diese Informationen knnen beliebig verwendet werden, wie z. B. fr 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. Fr Entwickler, die noch mit APEX 3 arbeiten, bieten diese Frameworks einen reichhaltigen Satz an zustzlichen Funktionen, wie z. B. die Cascading LOVs.
Firebug
Firebug ist ein kostenfreies Plug-In fr Firefox, das aber mittlerweile auch fr den Internet Explorer verfgbar 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 verndert werden kann. Somit kann man z. B. sehen, ob eine geplante nderung im Quellcode den gewnschten Effekt bringt, bzw. wo und ob sich gemachte nderungen in APEX im Aufbau der Seite niederschlagen.
Abbildung 49 Oberflche des Firebug
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 63
Applikationsvergleich
Ein Vergleich von Applikationsversionen ist in APEX selbst mglich. Unter Application Tasks (am rechten Rand zu finden) Cross Application Reports Application Comparison findet man die Mglichkeit, Versionen von Applikationen zu vergleichen. Ein entsprechender Filter lsst sich einstellen, der selektiert, welche Komponenten bercksichtig werden sollen.
Abbildung 50 Applikationsvergleich innerhalb APEX
Utilities
Auf der Seitendefinition existieren unter Utilities einige ntzliche Funktionen. Besonders hervorzuheben sind hier zwei Berichte, die fr Entwickler sehr hilfreich sein knnen:
Page Events: Hier kann man die Ablufe 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 verfgbare Utilities
-
Oracle Application Express Tipps fr Entwicklung und Betrieb 64
Referenzen Ntzliche 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 Users 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/
Weiterfhrende 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 fr Entwicklung und Betrieb 65
Remote-Debugging mit dem SQL Developer und Application Express
http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/remote-debug/index.html
-
Version 1.0 2011 TriVadis aG
info-Tel. 0800 874 823 47www.trivadis.com
UNSERE STANDORTE BaselBernlausanneZrichdsseldorffrankfurT a. M.freiBurG i. Br.haMBurGMnchensTuTTGarTWien
UNSERE LSUNGEN Business inTeGraTion serVices Business inTelliGence applicaTion deVelopMenT infrasTrucTure enGineerinG ManaGed serVices TraininG