Tipps für Entwicklung und Betrieb

APEX 5.0
Guidelines
Tipps für Entwicklung und Betrieb
Dokument Version 2.1
© 2015 Trivadis AG
BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M.
FREIBURG I. BR. GENF HAMBURG KOPENHAGEN LAUSANNE
MÜNCHEN STUTTGART WIEN ZÜRICH
Oracle Application Express Tipps für Entwicklung und Betrieb mit APEX 5.0 Trivadis AG Dokument Version 2.1 ©2015 Trivadis AG 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 unsere Erfahrungen helfen, solche Fehler von Anfang an zu Urban Lankes Verwaltungsratspräsident vermeiden und Kosten deutlich zu reduzieren. Trivadis Seit 2003 ist APEX ein Bestandteil der Oracle Datenbank und erlaubt die schnelle und flexible Erstellung datenbankgestützter Web-­Anwendungen. Durch die Einbettung leistungsfähiger Frameworks erlaubt es APEX, neueren Trends wie Mobile Enterprise und Responsive Design Dr. Martin Luckow komfortabel Rechnung zu tragen. Daher ist APEX inzwischen Senior Solution Manager sehr populär und wird in vielen Unternehmen auch für Application Development komplexe und teilweise kritische Applikationen eingesetzt. Trivadis Zudem tauschen sich APEX Entwickler lokal und international in Communitites aus. Die Mitarbeiter von Trivadis beteiligen sich ebenfalls durch Vorträge, Artikel, Blogs oder Diskussionen am Wissens-­ und Ideenaustausch. Die hier vorliegende neue Version der APEX Guidelines zeigt 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. 2 Oracle Application Express Tipps für Entwicklung und Betrieb 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. 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. 4 Oracle Application Express Tipps für Entwicklung und Betrieb Änderungshistorie Version Wer Datum Kommentar 0.1 Volker Strasser 09.11.2010 Initiale Struktur Development 0.2 Anja Zahn 03.01.2011 Überarbeitung, Erweiterung um Betrieb und Deployment 0.3 Anja Zahn 11.03.2011 Umbau der Kapitelstruktur 0.4 Anja Zahn 03.06.2011 Erweiterung 0.5 Perry Pakull 04.07.2011 Formatierung 0.6 Anja Zahn 11.08.2011 Übernahme Inhalte aus Originaldokument 0.7 Anja Zahn 26.08.2011 Erweiterung/Kennzeichnung mit Grafiken 0.8 Anja Zahn 01.09.2011 Finale Version 0.9 Perry Pakull 08.09.2011 Review und Formatierung 0.9 Anja Zahn 14.09.2011 Vorwort Carsten Czarski und eigenes eingefügt 0.9 Perry Pakull 19.09.2011 Vorwort Urban Lankes 1.0 Perry Pakull 29.09.2011 Version 1.0 1.0 Perry Pakull 05.10.2011 Interner inhaltlicher Review 1.0 Julian Chan 11.10.2011 Redaktionelle Korrekturen Rechtschreibung 1.0 Perry Pakull 12.10.2011 Titel und letzte Änderungen 2.0 Svenja Schriever 28.04.2015 Anpassung APEX 5.0 2.1 Svenja Schriever 05.05.2015 Umbau der Kapitelstruktur und Erweiterungen 2.1 Michael Schmid 22.05.2015 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 Anwendungsbereich ........................................................................................... 10 Konventionen im Dokument ................................................................................ 10 1.2.1 1.2.2 1.2.3 1.2.4 Kurzbezeichnungen ........................................................................................ 10 Farben ............................................................................................................ 10 Schlüsselworte ................................................................................................ 10 Grafiken .......................................................................................................... 11 2 Warum Standards und Richtlinien wichtig sind ..................................................... 12 3 Systemlandschaft ..................................................................................................... 13 3.1 3.2 Datenbank .......................................................................................................... 13 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 Oracle REST Data Services ORDS (APEX-­Listener) .......................................................................................................... 14 3.3 3.4 4 Web-­Browser ...................................................................................................... 15 Rollen und Aufgaben bei APEX .......................................................................... 15 Entwicklungsstandards ............................................................................................ 17 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 Umgebung .......................................................................................................... 17 Das Fundament: die Datenmodellierung ............................................................ 18 Funktionserweiterung durch Schnittstellen ......................................................... 19 Applikationsstruktur und Konzept ....................................................................... 19 Applikationslogik ................................................................................................. 25 Security ............................................................................................................... 27 Applikationsdesign .............................................................................................. 28 Ablage von Dateien ............................................................................................ 30 Arbeiten im Team ............................................................................................... 32 Applikationsentwicklung .......................................................................................... 35 5.1 5.2 5.3 5.4 5.5 5.6 5.7 6 Reports ............................................................................................................... 35 Formulare ........................................................................................................... 36 Charts ................................................................................................................. 38 Dynamische Operationen ................................................................................... 39 Namenskonventionen für Elemente .................................................................... 40 Mehrsprachige Applikationen ............................................................................. 42 Dokumentation und Kommentation .................................................................... 45 Deployment ................................................................................................................ 47 6.1 6 Deployment-­Arten ............................................................................................... 47 Oracle Application Express Tipps für Entwicklung und Betrieb 6.2 7 Betrieb ........................................................................................................................ 52 7.1 7.2 7.3 7.4 7.5 7.6 7.7 8 Empfehlungen für das Deployment .................................................................... 50 Instanzen ............................................................................................................ 52 Versionen ............................................................................................................ 53 Workspace Design .............................................................................................. 53 Security ............................................................................................................... 54 Userverwaltung ................................................................................................... 55 Accounting (Ressourcennutzung) ....................................................................... 61 Monitoring ........................................................................................................... 62 Hilfsmittel und Tools ................................................................................................. 64 Referenzen ........................................................................................................................ 69 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: Create as copy from existing Item ................................................................. 21 Abbildung 5: Kopieren oder referenzieren? ........................................................................ 21 Abbildung 6: Auswahl Applikationstypen ............................................................................ 22 Abbildung 7: Beispiel für eine Page 0 mit Header Quick Navigation und Breadcrumb ...... 24 Abbildung 8: Anzeige der Versionsnummer in der Anwendung ......................................... 25 Abbildung 9: Session State Protection Einstellungen ........................................................ 27 Abbildung 10: CSS ins APEX-­Repository hochladen ......................................................... 31 Abbildung 11: Bild-­Verwaltung in APEX ............................................................................. 32 Abbildung 12: Übersicht über die Pages und ihren Status ................................................. 32 Abbildung 13: Pagelock-­Verwaltung .................................................................................. 33 Abbildung 14: Features im Team Development ................................................................. 33 Abbildung 15: Link als Navigation Bar Entry in der Anwendung in APEX 4 ....................... 34 Abbildung 16: Feedbackbearbeitung in APEX ................................................................... 34 Abbildung 17: Beispiel einer Tabular Form ........................................................................ 37 Abbildung 18: JavaScript ins APEX-­Repository hochladen ............................................... 40 Abbildung 19: Button Name darf nicht geändert werden .................................................... 42 Abbildung 20: Angabe des Items, das die Formatierung enthält ........................................ 43 Abbildung 21: Anlegen der Texte ....................................................................................... 43 Abbildung 22: Einstellungen auf Ebene der Komponenten ................................................ 44 Abbildung 23: Einstellungen für das XLIFF-­File ................................................................. 45 Abbildung 24: Dokumentation in der Anwendung .............................................................. 46 Abbildung 25: Einfacher Deploymentprozess im Überblick ................................................ 47 Abbildung 26: Möglichkeiten des Exports über die APEX GUI .......................................... 47 Abbildung 27: Kontextmenü Application Express im SQL Developer ................................ 48 Abbildung 28: APEX Application Archive (Packaged Application) ..................................... 49 Abbildung 29: Überblick Supporting Objects in APEX ....................................................... 50 Abbildung 30: Applikation als run only importieren ............................................................ 52 Abbildung 31: Anmeldung am Workspace internal ............................................................ 53 Abbildung 32: Administration über den Workspace internal ............................................... 54 Abbildung 33: Anlegen der Authentifizierungsschemas ..................................................... 54 Abbildung 34: Autorisierungsschemas prüfen mittels Views .............................................. 55 Abbildung 35: User-­Einstellungen ...................................................................................... 56 Abbildung 36: Konfiguration für LDAP-­Anbindung ............................................................. 57 Abbildung 37: LDAP-­Anbindung testen .............................................................................. 58 Abbildung 38: Page Sentry Function mit Package-­Aufruf .................................................. 59 Abbildung 39: Session-­Timeout ......................................................................................... 59 Abbildung 40: Account-­Steuerung ...................................................................................... 60 Abbildung 41: Passwort-­Sicherheit .................................................................................... 60 Abbildung 42: SSL Verschlüsselung einstellen .................................................................. 61 Abbildung 43: Ansicht Metriken im OEM ............................................................................ 62 Abbildung 44: Beispiel für die Auswirkungen der Ressourcenpriorisierung ....................... 63 Abbildung 45: Plug-­In Verwaltung in APEX ........................................................................ 64 Abbildung 46: Optionen des APEX Advisor ....................................................................... 65 Abbildung 47: Zusätzliches Verzeichnis im SQL Developer für APEX ............................... 65 Abbildung 48: Anzeigemöglichkeiten auf Level Applikation ............................................... 66 Abbildung 49: Berichte auf Applikationsebene ................................................................... 66 Abbildung 50: Berichte auf Seitenebene ............................................................................ 66 Abbildung 51: Oberfläche des Firebug ............................................................................... 67 Abbildung 52: Applikationsvergleich innerhalb APEX ........................................................ 68 8 Oracle Application Express Tipps für Entwicklung und Betrieb Abbildung 53: Auf Seitenebene verfügbare Utilities ........................................................... 68 Oracle Application Express Tipps für Entwicklung und Betrieb
9 1 Einleitung 1.1 Anwendungsbereich Dieses Dokument dient dem PL/SQL-­erfahrenen Entwickler n als Einstieg in die Entwicklung mit APEX n als Übersicht über die Konventionen, die generell für APEX und die damit erstellten Anwendungen gelten n 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 APEX 5 Oracle Application Express, Version 5.0 CI Corporate Identity DB Datenbank DDL Data Definition Language DML Data Manipulation Language EPG Embedded PL/SQL Gateway LOV List of Value OEM Oracle Enterprise Manager SSO Single Sign-­on UI User Interface WS Workspace 1.2.2 Farben Farblich markierter Text hat folgende Bedeutungen: Farbe Bedeutung BLAU APEX Begriffe und Schlüsselworte sind blau markiert FETT Wichtige Begriffe sind fett markiert 1.2.3 Schlüsselworte Folgende Schlüsselworte bewerten die Wichtigkeit der Richtlinien und Empfehlungen: 10 Oracle Application Express Tipps für Entwicklung und Betrieb 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: n Probleme in der Kommunikation durch unterschiedliches Verständnis innerhalb des Projektteams n Technische Probleme durch unterschiedliche Verfahrensweisen in der Umsetzung n Probleme bei der Wartung durch Dritte n Irritationen, Missverständnisse und ggf. Unbeliebtheit bei Endanwendern Dieses Dokument liefert einen allgemeinen Grundstock dieser Standards und Richtlinien, die aber für einzelne Projekte erweitert bzw. verringert werden können. 12 Oracle Application Express Tipps für Entwicklung und Betrieb 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. APEX 5 ist erst mit der Datenbank Version 11.0.1.7 kompatibel. 3.2 Webserver und Application Server Es gibt drei Arten APEX zu betreiben: n Embedded PL/SQL Gateway n Oracle HTTP Server (Apache) mit konfiguriertem mod_plsql n 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: n Schnell einsatzbereit, geringe Konfiguration nötig Nachteile: n 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: n Rewrite, Proxy etc. möglich, daher für grössere Netzwerke geeignet n Weitreichende Konfigurationsmöglichkeiten für Security Anforderungen n Häufig eingesetzte und bewährte Variante, dadurch sind viele Erfahrungen im Internet verfügbar Nachteile: n Mehr Konfigurationsaufwand Abbildung 2: Schematischer Aufbau APEX und Oracle HTTP Server 3.2.3 Application Server mit konfiguriertem Oracle REST Data Services ORDS (APEX-­Listener) Mit der neuesten Version können verschiedene Application Server in Betrieb genommen werden, da sich der Oracle REST Data Services (ORDS, früher: APEX-­Listener) durch seine Java-­Basis in vielen Servern einsetzen lässt. Zu den Application Servern gehören: n Oracle WebLogic Server n Oracle GlassFish Server n OC4J Vorteile: n Rewrite, Proxy etc. möglich, daher für grössere Netzwerke geeignet n REST-­Service und viele weitere Funktionen von APEX nutzbar n Fokussierung des APEX-­Teams auf den Listener, daher sind hier weitere Funktionserweiterungen zu erwarten Nachteile: n Mehr Konfigurationsaufwand n Es wird zwingend ein Application Server benötigt 14 Oracle Application Express Tipps für Entwicklung und Betrieb 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. Entwicklung für den Internet Explorer Gerade die Entwicklung eines eigenen Themes erfordert ausreichendes Testen, da sich unterschiedliche Browser unterschiedlich verhalten. Gerade die Entwicklung für den Internet-­Explorer benötigt eine (fast) eigene Entwicklung des Designs. Achtung: Standardmäßig kann für den Internet Explorer der Kompatibilitätsmodus aktiviert sein. Dann werden Elemente, vorwiegend in neuern Themes auf HTML5 und CSS3 Basis, der APEX-­Anwendung nicht richtig dargestellt. Grund: n Browser interpretieren CSS-­Code unterschiedlich n Im Kompatibilitätsmodus kann der Internet Explorer kein HTML5 und CSS3 darstellen. 3.4 Rollen und Aufgaben bei APEX Aufgaben eines Datenbankadministrators Der DBA sollte nur das Grundgerüst (das Schema und den Workspace) für die Verwendung von APEX stellen. Alles andere sollte in den Händen des Entwicklers liegen. Technologische Schwerpunkte eines Entwicklers APEX vereint viele verschiedene Technologien, die zur Erstellung einer Anwendung verwendet werden können. Nachfolgend eine Übersicht der Schwerpunkte, die ein APEX-­
Entwickler abdecken sollte: n Ein APEX-­Entwickler muss mit den Möglichkeiten, Funktionsweisen und auch Eigenheiten von APEX vertraut sein. Empfehlenswert ist es, die Oracle Application Oracle Application Express Tipps für Entwicklung und Betrieb
15 Express Community oder auch die APEX Blogs zu verfolgen. Praktische Erfahrung im Umgang mit APEX ist aber durch nichts zu ersetzen! n Bei komplexeren Datenbank Applikationen, ist es unabdingbar, dass der Entwickler SQL und PL/SQL beherrscht, um die gestellten Anforderungen an Funktionalität und Geschäftslogik umsetzen zu können. Durch den Query Builder in den APEX Wizards ist es auch Anwendern ohne spezifische SQL-­Kenntnisse möglich, Berichte und Formulare zu erstellen. n 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. n 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. 16 Oracle Application Express Tipps für Entwicklung und Betrieb 4 Entwicklungsstandards 4.1 Umgebung Um die Entwicklung mit APEX zu standardisieren sind im Vorfeld der Entwicklung einige generelle Entscheidungen treffen. Es wird ebenfalls empfohlen sich bei jeder Entwicklung an Entwicklungsstandards zu orientieren. Grund: n Funktionen von APEX können so gewinnbringend eingesetzt werden n Die Entwicklungszeit kann erheblich verkürzt werden n Es werden Richtlinien aus klassischer Anwendungsentwicklung adaptiert, welche die Entwicklung mit APEX zusätzlich verbessern 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. Der APEX-­Workspace Der APEX Workspace ist eine Entwicklungsumgebung in der Entwickler autark arbeiten können ohne einen Administrator, z.B. für die Vergabe von Berechtigungen auf Applikationen zu benötigen. Einem Workspace können ein oder mehrere Datenbankschemen zugeordnet werden. Um alle Funktionen von APEX effektiv nutzen zu können, wird das Entwickeln von zusammenhängenden Applikationen und einem Entwicklerkreis auf einem Workspace empfohlen. Grund: n Applikationen oder Applikationsteile können wiederverwendet werden n Transparenter Zugriff von einer zur anderen Applikation möglich mit einer Authentifizierung n Trennung der Applikationen ist weiterhin durch Schemen möglich n Gleichzeitige Sicherung aller Applikationen z.B. durch eine Packaged Application „APEX Application Archive“ Oracle Application Express Tipps für Entwicklung und Betrieb
17 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: n Das Konzept Grant <role> to user funktioniert nicht mit APEX 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: n In den APEX Wizards können nur zwei Attribute für einen Primärschlüssel angegeben werden n Die Standard DML Operationen können sonst nicht genutzt werden n 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: n Die Applikation kann dann nicht mehr als abgeschlossene Einheit angesehen werden n Es können Konflikte mit anderen Objekten auf DB Ebene entstehen 18 Oracle Application Express Tipps für Entwicklung und Betrieb 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: n Änderungen an Daten können so einfacher nachvollzogen werden n Der Audit passiert direkt in der Datenbank und muss nicht in der Anwendung berücksichtigt werden 4.3 Funktionserweiterung durch Schnittstellen Datenbanklinks Bei der Verwendung von Datenbanklinks sollte für jede Zieltabelle oder Zielview eine View im Parsing Schema angelegt werden. Grund: n Die Wizards innerhalb APEX können diese Datenquelle sonst nicht erkennen Performance Verschlechterungen, welche hier eventuell auftreten, können mit Snapshots umgangen werden! 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: n Alle Funktionalität ist auf APEX abgestimmt, unterstützt und dokumentiert 4.4 Applikationsstruktur und Konzept 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 mehrere 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. Oracle Application Express Tipps für Entwicklung und Betrieb
19 Big Apps Vorteile n Verzweigungen innerhalb der Applikation n Nur eine Anmeldemaske (kein Single Sign-­on notwendig) Nachteile n Deployment von einzelnen Modulen fast nicht möglich n Keine modulare Versionierung n Potentiell wieder verwendbare Module können nicht wieder verwendet werden Partitioned Apps Vorteile n Modulares Deployment möglich n Modulare Versionierung möglich n Einfacheres Entwickeln in grösseren Entwicklungsteams Nachteile n Single Sign-­on notwendig, da sonst pro Applikation ein Anmeldedialog erscheint 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: n 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: n Autorisierungsschemas n Authentifizierungsschemas n List of Values n Plug-­Ins n Templates n Shortcuts n Navigation Bars 20 Oracle Application Express Tipps für Entwicklung und Betrieb n Help Text n User Interface Defaults Abbildung 4: Create as copy from existing Item Abbildung 5: Kopieren oder referenzieren? Master Applikationen sollten immer Beispielseiten enthalten, in denen die Komponenten verwendet und idealerweise auch erklärt werden. Grund: n So lässt sich die Funktionsweise der jeweiligen Komponente einfacher nachvollziehen und adaptieren Oracle Application Express Tipps für Entwicklung und Betrieb
21 Welchen Applikationstyp nehme ich für meine Applikation?
Der Application Builder Assistent in der folgenden Abbildung bietet vier unterschiedliche Applikationstypen an. Abbildung 6: Auswahl Applikationstypen Bei einer Desktop 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. Mobile Applikationen ermöglichen das Entwickeln von Webanwendungen für mobile Endgeräte wie Smartphones und Tablets. Die Entwicklung erfolgt Ähnlich wie die Entwicklung von Desktop Applikationen. Als Framework wird jQuery Mobile verwendet. Websheet Applikationen können im Gegensatz zu den Database Applikationen auch ohne Kenntnisse im Bereich SQL und PL/SQL erstellt werden. Diese Art der Anwendung ist beispielsweise als Portal für eine bestimmte Fachabteilung nutzbar und sollte ebenso durch einen Anwender aus der Fachabteilung erstellt werden. Hier können Daten aus Excel kopiert und veröffentlicht werden. Falls gewünscht, können sie auch bearbeitet werden. Es werden dazu Berichte, Formulare, HTML-­Editoren, Diagramme oder auch Data Grids zur Verfügung gestellt. Die Daten werden in durch APEX verwalteten Tabellen gespeichert. Deshalb müssen diese auch bei Übernahme der Daten in einen anderen Datenbestand abgefragt werden, was wiederum einen SQL-­Entwickler erfordert. Packaged Application stellen eine Reihe von fertigen Applikationen zur Verfügung welche installiert, angepasst und kostenlos verwendet werden können. 22 Oracle Application Express Tipps für Entwicklung und Betrieb Es lohnt sich ebenfalls sich die Packaged Applications zu installieren um Ideen für die eigene Umsetzung zu bekommen oder sich an Lösungen des APEX-­
Teams zu bedienen. Kopieren und nachbauen ist hier erlaubt und empfohlen und sogar gewünscht. Nummernkreise für Seiten und Anwendungen Für Anwendungen sollten Nummernkreise verwendet und konstant über Test und Produktion beibehalten werden. Für Seiten sollten ebenfalls Nummernkreise verwendet werden und den Seiten sollten zudem Seitengruppen zugwiesen werden. Beispiel: Seitengruppe Nummernkreis Stammdaten 1000-­1999 LookUPdaten 2000-­3999 Bewegungsdaten 4000-­… Die Zusammengehörigkeit von Query Screen, Result List Screen und Detail Screen kann nach folgendem Prinzip umgesetzt werden: Seitengruppe Seite Nummer Dialog 70 Query Screen 1 Page 700 List Screen 1 Page 701 Detail Screen 1 Page 702 Dialog 71 Query Screen 2 Page 710 List Screen 2 Page 711 Detail Screen 2 Page 712 Grund: n Erkennbarkeit der fachlichen bzw. technischen Zuordnung der Seite n Einheitliches Gerüst für die Nummerierung Es sollte für eine Anwendung eine feste Anwendungs-­ID pro APEX-­Instanz verwendet werden. Grund: n Die Anwendungs-­ID für übersetzte Anwendungen darf nicht verändert werden, da sonst die Übersetzung verloren geht n Personalisierte, interaktive Reports bleiben beim Import nur erhalten, wenn die Anwendungs-­ID gleich bleibt Oracle Application Express Tipps für Entwicklung und Betrieb
23 Page 0 (Global Page) Page 0 (Global Page) 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: n Alle Elemente auf dieser Seite werden auch auf allen anderen Seiten angezeigt bzw. sind auch dort verfügbar Abbildung 7: Beispiel für eine Page 0 mit Header Quick Navigation und Breadcrumb Die Page 0 sollte nicht übermässig gefüllt werden. Grund: n Da die Seite bei jedem Seitenaufruf mitgeladen wird, geht dies zu Lasten der Performance n Ggf. sind weitere Einschränkungen (Conditions) zu treffen um das Laden nur auf den gewünschten Seiten zu verhindern bzw. zu erlauben. Page 999 Page 999 ist reserviert für den Standard Output von CGI_ENV. Grund: n Dient zum Debuggen der Benutzerumgebung 24 Oracle Application Express Tipps für Entwicklung und Betrieb Alias Anwendungen und Seiten sollten möglichst immer einen Alias haben. Der Alias für Anwendungen kann z.B. an Endbenutzer gegeben werden. Dieser bleibt auch bestehen, wenn sich die Applikationsnummer ändern sollte. Auch bei anschließender Seitenumstrukturierung können die Links auf Seiten welche mit einem Alias aufgerufen werden beibehalten werden. Vorsicht aber bei der Vergabe von Aliasen. Grund: n Einen Alias für Applikationen kann es pro APEX-­Instanz nur einmal geben! n Einen Alias für Seiten pro Applikation nur einmal Versionsnummerierung In der APEX Applikation Definition sollte das Feld Version gefüllt sein. Grund: n So ist auch innerhalb der Applikation erkennbar, mit welchem Stand gerade gearbeitet wird Versionsnummer: 1.2.3.4.5 n 1. Stelle à Major Release (Architekturumstellung, neue Funktionalitäten, APEX Code-­ und Schemaänderungen) n 2. Stelle à Minor Release (Neue Funktionalitäten, APEX Code-­ und Schemaänderungen) n 3. Stelle à Service Pack (APEX Code-­ und Schemaänderungen) n 4. Stelle à FixPack APEX ( Nur APEX Codeänderungen) n 5. Stelle à FixPack Schema (Nur Schemaänderungen) Abbildung 8: Anzeige der Versionsnummer in der Anwendung 4.5 Applikationslogik 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 Oracle Application Express Tipps für Entwicklung und Betrieb
25 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. n Trivadis PL/SQL und SQL Coding Guidelines (im Downloadbereich der Trivadis-­Website) http://www.trivadis.com/metanavigation/downloads.html 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: n Klassischer Ansatz der Software Entwicklung n Einfacheres Debugging und Ressourcenkontrolle möglich n 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. Abfragen für Reports, Charts und Trees sollten ebenfalls über Views erfolgen. Grund: n Trennung von Logik und Visualisierung n Änderungen in den Joins oder Aggregatfunktionen können direkt in der View geändert werden und benötigen keinen Zugang zur Applikation n Eine View kann ggf. für mehrere Reports genutzt werden und muss nur einmal angepasst werden 26 Oracle Application Express Tipps für Entwicklung und Betrieb 4.6 Security 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 9: 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: n Automatische Überprüfung der URL mittels Checksum n Es ist bei einem APEX Projekt oftmals nicht abzusehen, wie wichtig die Anwendung später sein wird und wie kritisch sie betrieben wird n 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, , Oracle Application Express Tipps für Entwicklung und Betrieb
27 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: n 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: n 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: n Schutz gegen SQL-­Injection 4.7 Applikationsdesign Page Designer Die Tree-­View wurde mit APEX 5 durch den Page Designer ersetzt. Die Component-­View bleibt weiterhin enthalten, sollte aber möglichst nur für den Umstieg auf den Page Designer genutzt werden. Der Umstieg auf den Page Designer mag zwar Umgewöhnungszeit beanspruchen, diese zahlt sich aber sehr schnell aus. Grund: n Mehrere Formularelemente können gleichzeitig bearbeitet werden n Der Page Designer enthält eine Live-­Validierung n Änderungen können Rückgängig gemacht werden, da sie zunächst nur im 28 Oracle Application Express Tipps für Entwicklung und Betrieb Browser-­Cache gehalten werden n Es sind Shortcuts verfügbar (z.B. für Speichern und öffnen) n die Drag&Drop Funktion vereinfacht das gestalten der Anwendungen n der Page Designer wird weiterentwickelt, die Component View nicht 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: n Höherer Automatisierungsgrad und geringere Nacharbeitung notwendig Einheitliches Applikationsdesign Innerhalb eines Unternehmens sollte es möglichst ein einheitliches Applikationsdesign geben. Weiterhin sollte das Applikationsdesign jeweils auf dem neusten Stand sein. Grund: n alle Funktionen des modernen Webdesigns und von APEX nutzen können n Anwender mit neuem Aussehen vollständig von APEX überzeugen n Anwendern eine gewohnte, einheitliche Umgebung bieten Auswahl des passenden Themes Ab APEX 5 wird das Theme 52 (Universal Theme) empfohlen. Alte Applikationen sollten nach Möglichkeit kopiert und im neuen Theme upgedatet werden. Neue Applikationen sollten gleich mit dem neuen Theme entwickelt werden. Grund: n Der volle Umfang an Funktionen kann nur mit dem neuen Theme genutzt werden. n Das neue Theme wird laufend weiterentwickelt n Es enthält neuste Web-­Technologien n Das Universal Theme lässt sich leichter und sogar direkt über die Oberfläche anpassen Universal Theme Das Universal Theme bietet zahlreiche Erneuerungen, welche zur Usability und User Experience der Anwender beitragen und damit die Akzeptanz von APEX erheblich weiter zu steigern. Oracle Application Express Tipps für Entwicklung und Betrieb
29 Grund: n Modale Dialoge sorgen für ein Arbeiten im Kontextzusammenhang, sie sind einfach zu nutzen n Navigation Lists sind flexibler anzupassen als Tabs n iFrames bietet das Einbinden einer Seite in die Applikation ohne die Anwendung zu verlassen n Zahlreiche neue Templates sorgen für ein modernes Look and Feel n Die Farbe des Themes lässt sich einfach und ohne CSS-­Kenntnisse anpassen Das Universal Theme bietet eine große Anzahl von Flat-­Icons die über CSS-­
Klassen eigebunden werden können und sollten. Grund: n n n n Icons passen sich gut in das Design an Eine ausreichend große Auswahl ist vorhanden Vektorgrafiken können über CSS weiter angepasst werden Die Static Application Files werden sauber gehalten und nicht überladen 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: n Die Kompatibilität wird bewahrt, insbesondere bei unterschiedlichen Browsern n Wechsel zwischen dem eigenen und einem APEX-­Theme ist möglich Änderungen am Layout in einzelnen Seiten sollten vermieden werden. Grund: n Sie sind schwierig zu debuggen n Sie können bei zusätzlichen Änderungen im zentralen Theme (CI Theme) zu Problemen führen 4.8 Ablage von Dateien Ablage von CSS Zusätzliche oder überschriebene Styles sollten in einem applikationsspezifischen CSS untergebracht werden und dann im APEX-­Repository gespeichert werden. Seit APEX 5.0 werden CSS Files zusammen mit möglichen Bildern und Javascript Dateien in den Static Application Files und Static Workspace Files gespeichert. Diese können unter Shared Components à Files à Static 30 Oracle Application Express Tipps für Entwicklung und Betrieb Application Files hochgeladen werden. Grund: n Der Entwickler hat somit immer einen Zugriff und muss nicht den Administrator kontaktieren Abbildung 10: CSS ins APEX-­Repository hochladen Ablage von Bildern Bilder, die innerhalb der Applikation verwendet werden wie z. B. Buttons, Logos, etc. sollten immer auch in der Applikation als Static Application File in den Shared Components abgelegt werden. Bei Applikationen wie z. B. Produktkatalogen sollten die Bilder der Produkte in BLOBS von Tabellen hinterlegt werden. Grund: n Das Deployment wird einfacher, da die ganze Visualisierungsschicht über den APEX-­Export/Import gemacht werden kann n Es gibt keine Dateien, die auf eine andere Weise vom Filesystem gesichert werden müssen Eine weitere Neuerung bei APEX 5 bringt es mit sich, dass Bilder als ZIP-­
File hochgeladen und automatisch entpackt werden können. Es sollte auch immer ein Ordner mit angegeben werden. Grund: n Durch das zentrale Zusammenlegen aller Dateien, werden Dateien nun strukturiert abgelegt. Oracle Application Express Tipps für Entwicklung und Betrieb
31 Abbildung 11: Bild-­Verwaltung in APEX 4.9 Arbeiten im Team Pagelock während der Entwicklung Bevor ein Entwickler an einer Seite arbeitet, sollte er darauf einen Pagelock setzen. Grund: n Damit werden Konflikte vermieden, falls zwei Entwickler an derselben Seite arbeiten n Der Projektmanager weiss, an welcher Seite momentan gearbeitet wird Abbildung 12: Übersicht über die Pages und ihren Status 32 Oracle Application Express Tipps für Entwicklung und Betrieb Abbildung 13: Pagelock-­Verwaltung Team Development Das Team Development ist erst seit APEX 4 erhältlich, verfügt jedoch über alle notwendigen Funktionen, um innerhalb APEX Features der Anwendungen zu definieren, Milestones festzulegen, Aufgaben zuzuweisen, Bugs zu tracken und vieles mehr. Dadurch können externe Tools wie z. B. JIRA abgelöst werden. Abbildung 14: 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. 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: n 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. APEX 5 bietet die Möglichkeit das Feedback-­Formular als Modalen Dialog zu öffnen. Oracle Application Express Tipps für Entwicklung und Betrieb
33 Abbildung 15: 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 16: Feedbackbearbeitung in APEX 34 Oracle Application Express Tipps für Entwicklung und Betrieb 5 Applikationsentwicklung 5.1 Reports SQL Reports SQL Reports sollten für dynamische Anzeigen verwendet werden, die vom Benutzer aber nicht geändert werden sollen. Grund: n Einfach zu implementierende Standardfunktionalität Interactive Reports Seit APEX 5 besteht die Möglichkeit den Headerbereich des Interaktiven Reports an die Region zu binden. Dazu muss die Reporthöhe definiert werden. Es wird generell empfohlen dies anzuwenden. Grund: n Beim Scrollen bleibt der Header und die Überschriften auf dem Bildschirm, nur der Inhalt der Tabelle werden über die definierte Reporthöhe gescrollt n Es ist auch möglich mehrere Interaktive Reports in die Seite einzubinden. Das würde dazu führen, dass die Seite in Abhängigkeit der Einstellungen, sehr lang werden kann Auditing Attribute Auditing Attribute sollten in einem Interactive Report zur Auswahl angeboten, aber nicht standardmässig angezeigt werden. Grund: n 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: n Die fixe Spaltenüberschrift wird nicht im Übersetzungsrepository (XLIFF) berücksichtigt (siehe Mehrsprachige Applikationen) Oracle Application Express Tipps für Entwicklung und Betrieb
35 5.2 Formulare Formulare mit automatischen Prozessen Hierbei werden die APEX-­Standard-­Prozesse genutzt, um DML Operationen durchzuführen. Diese sollten für Dialoge verwendet werden, die nur Standard-­
Funktionalität auf eine Tabelle und wenig Geschäftslogik benötigen. Grund: n n n n n 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: n Mehrere Datenbankobjekte können angesprochen werden n Höhere Flexibilität bezüglich der Datenverteilung in der Datenbank n Error Handling ist einfacher zu implementieren, da hier die komplette Kontrolle über die DML Operationen gegeben ist n In der Prozedur können nachträgliche Änderungen einfacher erfolgen n 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: n Unkontrolliertes Updateverhalten n Validierungen sind nur mit viel Aufwand zu erreichen n Verbesserungen in APEX 4, jedoch noch nicht ausreichend für viele Anforderungen 36 Oracle Application Express Tipps für Entwicklung und Betrieb Abbildung 17: 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: n 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: n Unkontrolliertes Updateverhalten in Bezug auf die Reihenfolge der Transaktionen n Validierungen sind nur mit viel Aufwand zu erreichen n Verbesserungen in APEX 4, jedoch noch nicht ausreichend für viele Anforderungen Besteht für den Master-­Detail eine Fremdschlüsselverbindung, darf beim Löschen des Masters nicht vergessen werden, dass die Details mitgelöscht Oracle Application Express Tipps für Entwicklung und Betrieb
37 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: n APEX hält eine solche Funktionalität nicht bereit n 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: n So werden die Formulare übersichtlicher n Es wird klarer, dass diese Felder nicht bearbeitet werden müssen 5.3 Charts Charts können in Flash oder HTML5 dargestellt werden. Charts sollten möglichst als HTML5 Charts dargestellt oder umgewandelt werden. Grund: n Flash ist veraltet, es wird sich zunehmend auf HTML5 fokussiert n Mobile Geräte von Apple können kein Flash und damit auch Flash Charts nicht darstellen n HTML5 ist Browserunabhängig und kann mit allen Endgeräten dargestellt werden 38 Oracle Application Express Tipps für Entwicklung und Betrieb 5.4 Dynamische Operationen Dynamic Actions Dynamic Actions bieten die Möglichkeit Seiten oder Seitenelemente dynamisch auf Aktionen reagieren zu lassen. Es gibt viele vorgefertigte Dynamic Actions die JavaScript-­Code ersetzen. Diese sollten vorwiegend genutzt werden. Grund: n Dynamic Actions werden vom APEX-­Team mitgeliefert, sind getestet und werden mit aktualisiert 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: n Die Methode des OnPageLoad Prozesses hat sich in der Praxis bewährt n Die Dynamic Actions sind erst ab APEX 4 verfügbar und sind schwerer zu debuggen JavaScript Sollte keine passende Dynamic Action zur Verfügung stehen können mittels JavaScript clientseitige Aktionen ausgeführt werden. Wenn möglich natives JavaScript vermeiden und jQuery und jQuery mobile nutzen. Grund: n APEX setzt auf die Verwendung von jQuery und bietet eigene JavaScript APIs an n jQuery und die APEX APIs haben sich etabliert und fangen Unterschiede einzelner Browser ab Zusätzlicher oder überschriebener JavaScript-­Code sollte in einer (oder mehreren) applikationsspezifischen JavaScript-­Libraries gespeichert und dann im APEX-­Repository abgelegt werden. Das kann unter Shared Components à Files à Static Files geschehen. Grund: n Somit hat der Entwickler immer Zugriff auf den Code und muss nicht den Administrator kontaktieren Oracle Application Express Tipps für Entwicklung und Betrieb
39 Abbildung 18: 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: n Auf diese Weise wird die Integration von JavaScript immer gleich gehandhabt n Ist einfacher nachvollziehbar 5.5 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: n 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 n 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: n BESTELLUNGEN Beispiel für ein Formular: 40 Oracle Application Express Tipps für Entwicklung und Betrieb n BESTELLUNG Items, die lediglich auf einer bestimmten Seite vorkommen, sollten (genau wie die von APEX automatisch erzeugten Items) der folgenden Namenskonvention entsprechen: n P<Seitennr.>_ITEMNAME Beispiel für ein Item: n P4711_ARTIKELNUMMER Schaltflächen werden so benannt, wie der Request, den sie abgeben, jedoch ohne Seiten-­Präfix. Beispiel für eine Schaltfläche: n 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: n 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: n Die Applikations-­ID kann sich ändern und dann würden die Zusammenhänge verloren gehen. Namenskonvention: n A_ELEMENTNAME Beispiel für ein Anwendungs-­Item: n A_JAHR Beispiel für einen Anwendungs-­Prozess: n A_ARTIKEL_BESTELLEN Oracle Application Express Tipps für Entwicklung und Betrieb
41 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 19: Button Name darf nicht geändert werden Grund: n 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. 5.6 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. 42 Oracle Application Express Tipps für Entwicklung und Betrieb Abbildung 20: 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: n So werden alle benötigten Übersetzungen in einer Datei bereitgehalten Abbildung 21: Anlegen der Texte Wertelisten sollten immer über statische LOVs angelegt werden. Grund: n 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: Oracle Application Express Tipps für Entwicklung und Betrieb
43 n Aktuell gemachte Änderungen werden beim Entwickeln in der Applikation sonst nicht angezeigt Für dynamische Wertelisten sollte APEX_LANG.LANG und für dynamische Übersetzung von Messages APEX_LANG.MESSAGES verwendet werden. Grund: n Diese Funktionen sind auf APEX abgestimmt n 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“ auf „Yes“ gesetzt werden sollten. Grund: n Das XLIFF-­File sollte für den Übersetzer auf das Notwendigste reduziert werden Abbildung 22: Einstellungen auf Ebene der Komponenten 44 Oracle Application Express Tipps für Entwicklung und Betrieb Abbildung 23: 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: n 1. Primäre Anwendung installieren n 2. Die übersetzte(n) Anwendung(en) installieren Grund: n Die primäre Sprache einer Anwendung muss immer installiert sein, bevor eine übersetzte Anwendung installiert werden kann 5.7 Dokumentation und Kommentation 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: n 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 n 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. Grund: n So wird dem Anwender die grösstmögliche Hilfestellung geboten, um mit der Oracle Application Express Tipps für Entwicklung und Betrieb
45 Anwendung arbeiten zu können n Verständliche und konkrete Fehlermeldungen erhöhen die Akzeptanz des Anwenders gegenüber der Anwendung n Der Entwickler kann besser auf Fehlerbeschreibungen reagieren, wenn die Meldungstexte nicht uniform sind Ablage der Dokumentation Eine kurze Dokumentation im Stile eines How-­To sollte in jeder Anwendung für den Anwender verfügbar sein. Grund: n 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 46 Oracle Application Express Tipps für Entwicklung und Betrieb 6 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 6.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 Oracle Application Express Tipps für Entwicklung und Betrieb
47 Ein Sonderfall ist der Export eines Workspaces, da dieser nur durch den APEX-­Admin ausgeführt werden kann. Vorteil: n Keine Programmierung nötig n Wird von Oracle unterstützt Nachteil: n Export/Import nur einzeln möglich, daher arbeitsintensiv bei vielen Applikationen n 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: n Keine Programmierung nötig Nachteil: n Export/Import nur einzeln möglich, daher arbeitsintensiv bei vielen Applikationen n 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: n Wird von Oracle unterstützt n Durch Jobs steuerbar Nachteil: n Kein Export von Bildern und Dateien (Ausnahme Supporting Objects) 48 Oracle Application Express Tipps für Entwicklung und Betrieb 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: n Individuelle Lösung, Bilder und Dateien exportierbar n Durch Jobs steuerbar Nachteil: n Einmaliger Programmieraufwand n Kein Support von Oracle Packaged Application: APEX Application Archive Packaged Applications können kostenlos installiert werden. Zur Archivierung von Applikationen oder Applikationsständen bietet die Packaged Application „APEX Application Archive“ eine gute und vor Allem einfache Möglichkeit alle Applikationen, oder auch einzelne Applikationen eines Workspaces auf Knopfdruck zu archivieren und auch wiederherzustellen. Abbildung 28: APEX Application Archive (Packaged Application) Oracle Application Express Tipps für Entwicklung und Betrieb
49 6.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: n Automatisierter Export und Import von APEX-­Anwendungen per Kommandozeile http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/export-­script/index.html n Blog-­Eintrag bei Joel R. Kallman „APEX_APPLICATION_INSTALL“ http://joelkallman.blogspot.com/2010/07/apexapplicationinstall.html Supporting Objects Hier können Skripte abgelegt werden, die zur Anpassung des bzw. der DB-­Schemas dienen. Diese Skripte sollten jedoch nicht über die GUI ausgeführt werden, sondern auf der DB selbst. Gerade dann, wenn es mehrere Versionen eines Skripts oder auch Update-­
Skripts gibt, kann es zu Problemen kommen, da die Bedingungen (Conditions) zur Ausführung der einzelnen Skripte nicht greifen. In diesem Fall ist es besser, manuell nur die Skripte auszuführen, die man benötigt. Wenn Bilder und andere benötigte Dateien in die Supporting Objects integriert werden, lassen sich diese dann auch mit der Anwendung selbst über das Export-­Utility exportieren. Abbildung 29: Ü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. 50 Oracle Application Express Tipps für Entwicklung und Betrieb Big Apps vs. Partitioned Apps Der Unterschied zwischen „Big Apps“ und „Partitioned Apps“ spielt bei der oben empfohlenen Deploymentvariante keine Rolle. Bei den anderen beiden Methoden des Deployments sind Big Apps von Vorteil, da anstatt mehrerer Exporte und Importe nur jeweils einer durchgeführt werden muss. Workspace einrichten Ein Workspace sollte auf der Entwicklung erstellt und dann mittels Export und Import auf Test und Produktion installiert werden. Somit wird sichergestellt, dass alle Einstellungen, User usw. übernommen werden. Es sollte beachtet werden, dass kein WS auf diesen Instanzen manuell erzeugt wird! User einrichten Wird die Empfehlung aus dem vorigen Punkt befolgt, werden die User automatisch angelegt, die es in der Entwicklung gibt. Die Vorgehensweise für das Einrichten von Usern, die in der Test-­ oder Produktivumgebung zusätzlich benötigt werden, hängt von der entsprechenden Authentifizierungsmethode ab, die nachfolgend beschrieben werden. n 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. n 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. n 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
51 7 Betrieb 7.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 30: 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 52 Oracle Application Express Tipps für Entwicklung und Betrieb Option „run only“ importiert werden. Auch die Produktivinstanz kann als Run-­Only-­Instanz laufen, sofern keine Websheets verwendet werden. 7.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. 7.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 31: Anmeldung am Workspace internal Oracle Application Express Tipps für Entwicklung und Betrieb
53 Abbildung 32: Administration über den Workspace internal 7.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 33: 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. 54 Oracle Application Express Tipps für Entwicklung und Betrieb Abbildung 34: Autorisierungsschemas prüfen mittels Views 7.5 Userverwaltung Es gibt folgende drei Arten von Usern innerhalb von APEX: n Workspace Administrator n Developer n Application User Die nachfolgende Abbildung zeigt die Maske für die Anlage der drei Usertypen. Oracle Application Express Tipps für Entwicklung und Betrieb
55 Abbildung 35: User-­Einstellungen Workspace Administrator Es gibt einen speziellen Workspace-­Administrator, der für den internal WS verantwortlich ist. Dies ist der APEX-­Admin. Der APEX-­Admin sollte nur den Workspace selbst und den dazugehörigen Workspace Administrator anlegen. Diese wiederrum sollten dann alle weiteren Einstellungen vornehmen, z. B. User anlegen, entsprechend berechtigen und Schema zuweisen. So liegen die Verantwortlichkeiten gleich in den richtigen Händen. APEX bietet für dieses Szenario auch Service Requests für die Workspace Administratoren an. Developer Entwickler werden vom WS-­Admin angelegt und können ab APEX 4.0 darin eingeschränkt werden, welche Komponenten (Application Builder, SQL Workshop oder Team Development) sie nutzen dürfen oder nicht. 56 Oracle Application Express Tipps für Entwicklung und Betrieb Das Passwort für die Entwickler sollte vom DBA auf „Require Change of Password on First Use“ auf „yes“ gesetzt werden, damit der Entwickler sein persönliches Passwort vergeben kann. Application User Für eine Applikation berechtigte Anwender können über verschiedenste Arten angelegt und verwaltet werden. Diese sind immer abhängig vom jeweils verwendeten Authentifizierungsschema. Innerhalb eines Unternehmens sollte es ein einheitliches Verfahren der Anmeldung geben, soweit das technisch möglich ist. Die Variante „Application Express“ ist nur bei einem kleineren Nutzerkreis zu empfehlen, da die Verwaltung sehr zeitintensiv ist. Sollte diese Authentifizierung trotzdem eingesetzt werden, sollte die Verwaltung über APEX APIs in Verbindung mit einer GUI vereinfacht werden. Dies gelingt, indem z. B. die Mehrfachselektion von Usern zur Anlage in APEX oder auch Updates auf bestimmte Eigenschaften über mehre User angeboten werden. Bezüglich der Passwörter gilt hier das Gleiche wie bei den Entwicklern. Wie bindet man die Userverwaltung an LDAP an? Für die Anbindung der Anwenderverwaltung an LDAP stellt APEX ein vorkonfiguriertes Authentifizierungsschema bereit, das mit den entsprechenden Angaben zu Server und Pfad der berechtigten Gruppe ergänzt werden muss. Ist ein zentrales LDAP bereits vorhanden und gepflegt, sollte diese Art der Authentifizierung genutzt werden. Dies ermöglicht, dass hier kein weiterer Aufwand bezüglich der Benutzerverwaltung getrieben werden muss und der Anwender sich kein zusätzliches Passwort merken muss! Abbildung 36: Konfiguration für LDAP-­Anbindung Oracle Application Express Tipps für Entwicklung und Betrieb
57 Ohne erkennbare Vor-­ und Nachteile sind Microsoft Active Directory Server oder auch Oracle Internet Directory verwendbar. Ab APEX 5 kann der LDAP Zugang auch direkt aus den Authentication Schemen getestet werden. Abbildung 37: LDAP-­Anbindung testen 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 (Custom) innerhalb von APEX. Unabhängig von der Variante, die für SSO innerhalb eines Unternehmens gewählt wird, benötigt APEX einen Eintrag des Users, der sich erfolgreich gegen ein SSO-­System authentifiziert hat, in einer durch die DB auslesbaren Variablen wie z.B. die CGI_ENV-­
Variable „REMOTE_USER“. Mit dieser Grundlage kann dann ein Authentifizierungsschema angelegt werden, das dem User eine APEX-­Session ermöglicht, solange diese Variable gefüllt und damit valide ist. Hierfür sollte die Page Sentry Function innerhalb des Page Session Management verwendet werden, die bei jedem Seitenaufruf geprüft werden sollte! 58 Oracle Application Express Tipps für Entwicklung und Betrieb Abbildung 38: Page Sentry Function mit Package-­Aufruf Mittlerweile gibt es auch extra für diesen Verwendungszweck die HTTP Header Variable und die OAS Single Sign On – Variante für die Authentication Schemes welche ebenfalls verwendet werden kann. 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: n 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 „Manage Instance > Security“ sind die folgende Einstellungen bezüglich des Session Timeouts und der Account-­Steuerung zu beachten: Abbildung 39: Session-­Timeout Oracle Application Express Tipps für Entwicklung und Betrieb
59 Abbildung 40: Account-­Steuerung Die Password Policy sollte an die Unternehmensrichtlinien angepasst werden. Abbildung 41: Passwort-­Sicherheit Grund: 60 Oracle Application Express Tipps für Entwicklung und Betrieb n Um Anwendungen vor unerlaubten Zugriffen durch offene Sessions oder auch nicht berechtigten Usern zu schützen n Eine verstärkte Passwort-­Security sorgt für erhöhte Zugriffssicherheit 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. Grund: n 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: n 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 „Manage Instance > Security“ kann das Attribut „Require Outbound HTTPS“ auf „Yes“ eingestellt werden: Abbildung 42: SSL Verschlüsselung einstellen Grund: n Damit wird eine verschlüsselte Kommunikation für interne APEX Anwendungen erzwungen 7.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 Oracle Application Express Tipps für Entwicklung und Betrieb
61 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 Application Server 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. 7.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 43: Ansicht Metriken im OEM Ressource Manager Mit dem Ressource Manager können APEX-­Anwendungen, Seiten in APEX-­
Anwendungen oder auch User bezüglich der Nutzung vorhandener CPU priorisiert werden. So kann z. B. der Ressourcenverbrauch von Test-­
Applikationen gegenüber Produktiv-­Applikationen niedriger gehalten werden. Dazu werden die Anwendungen, Seiten oder User zu sogenannten Consumer Groups zugeordnet. Diesen Gruppen werden dann über Ressourcen Pläne bestimmte Prozentsätze von der CPU zugewiesen. USERNAME
GRUPPE
STATE
CPU_TIME CPU_WAIT_TIME
------------------------------ --------------- --------------- ---------- -------------
62 Oracle Application Express Tipps für Entwicklung und Betrieb APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
APEX_PUBLIC_USER
PRIO_HIGH
PRIO_LOW
OTHER_GROUPS
OTHER_GROUPS
OTHER_GROUPS
OTHER_GROUPS
OTHER_GROUPS
RUNNING
WAITING FOR CPU
WAITING
WAITING
WAITING
WAITING
WAITING
5077
2409
8988
8061
9068
4035
18297
0
4882
8266
8013
1
0
76
Abbildung 44: Beispiel für die Auswirkungen der Ressourcenpriorisierung Welche Applikation, Seite oder User welcher Gruppe angehört, kann auch zur Laufzeit geändert werden! So kann z. B. für eine Session eine Abfrage abgebrochen oder sogar die gesamte Session abgebrochen werden, wenn der I/O-­Wert eine festgelegte Menge überschreitet oder die Ausführungszeit zu lang ist.
Der Ressourcen Manager ist ab der Enterprise Edition verfügbar und sollte aber -­ wenn vorhanden -­ in grösseren Umgebungen auch genutzt werden. V$Session und DBMS_APPLICATION_INFO Über das Datenbank Package DBMS_APPLICATION_INFO werden von APEX hilfreiche Parameter für jede Session gesetzt. Mehr Informationen zum Package DBMS_APPLICATION_INFO sind in der Dokumentation der Datenbank unter Oracle Database PL/SQL Packages and Types Reference verfügbar. Parameter Wert Modul APEX:APPLICATION <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. Oracle Application Express Tipps für Entwicklung und Betrieb
63 8 Hilfsmittel und Tools 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: n Beim Einsatz von Plug-­Ins ist keinerlei Support gewährleistet n Plug-­Ins unterschiedlicher Anbieter können sich gegenseitig ins Gehege kommen (Seiteneffekte!) Abbildung 45: Plug-­In Verwaltung in APEX Tipp: in den Packaged Applications befinden sich zahlreiche durch die APEX-­Entwickler entwickelte Plugins die ohne Bedenken genutzt werden können. APEX 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. Es ist zusätzlich möglich einzelne Seiten zu überprüfen. 64 Oracle Application Express Tipps für Entwicklung und Betrieb Abbildung 46: Optionen des APEX Advisor SQL Developer Der SQL Developer sollte als Datenbanktool eingesetzt werden, da er einige Möglichkeiten bietet, um APEX zu verwalten. So können mit Hilfe des SQL Developers z. B. alle Applikationen bis auf Seitenebene angezeigt werden, Applikationen exportiert und importiert werden oder auch mit einem Plug-­In von Carsten Czarski Workspaces verwaltet werden. Der SQL Developer hält auch die nützliche Funktion des Remote-­Debuggings für APEX-­Anwendungen bereit. Näheres dazu lässt sich auf der APEX Community Seite finden, die von Carsten Czarski gestaltet wird. Abbildung 47: Zusätzliches Verzeichnis im SQL Developer für APEX Oracle Application Express Tipps für Entwicklung und Betrieb
65 Abbildung 48: 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 49: Berichte auf Applikationsebene Abbildung 50: Berichte auf Seitenebene Auf jedem Level findet sich auch das DDL zur Applikation oder zur Seite unter dem Reiter SQL. APEX Views Über die APEX Views kann man unter Beachtung der hierarchischen Struktur alle Komponenten einer Applikation auflisten lassen. Darüber dokumentieren sich die Applikationen gewissermassen selbst. Diese Informationen können beliebig verwendet werden, wie z. B. für Auswertungen, Dokumentationen, generische Funktionen usw. 66 Oracle Application Express Tipps für Entwicklung und Betrieb 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 51: Oberfläche des Firebug Applikationsvergleich Ein Vergleich von Applikationsversionen ist in APEX selbst möglich. Unter Workspace Utilitys à Cross Application Reports à Application Comparison findet man die Möglichkeit, Versionen von Applikationen zu vergleichen. Ein entsprechender Filter lässt sich einstellen, der selektiert, welche Komponenten berücksichtig werden sollen. Oracle Application Express Tipps für Entwicklung und Betrieb
67 Abbildung 52: Applikationsvergleich innerhalb APEX Utilities Auf der Seitendefinition existieren unter Utilities einige nützliche Funktionen. Besonders hervorzuheben ist hier Berichte in der ursprünglichen Component View, die für Entwickler sehr hilfreich sein können:
n Page Events: Hier kann man die Abläufe beim Aufbau und der Verarbeitung der Seite sehen. Abbildung 53: Auf Seitenebene verfügbare Utilities 68 Oracle Application Express Tipps für Entwicklung und Betrieb Referenzen Nützliche Links Hier ein paar Links zu Internetseiten, die man verfolgen sollte oder auf denen gegebenenfalls der Newsletter abonniert werden kann: n Oracle Application Express Community http://www.oracle.com/webfolder/technetwork/de/community/apex/index.html n Oracle Application Express API Referenz https://docs.oracle.com/cd/E59726_01/doc.50/e39149/toc.htm n Oracle Application Express Application Builder User´s Guide Substitution-­Strings https://docs.oracle.com/cd/E59726_01/doc.50/e39147/concept_sub.htm#HTMDB25032 n Blog SQL und PL/SQL in Oracle von Carsten Czarski http://sql-­plsql-­de.blogspot.com/ n Oracle Learning Library http://apex.oracle.com/pls/apex/f?p=44785:2:2055129407262164:FORCE_QUERY::2,CIR,RIR:P2_TAGS:
APEX n Trivadis PL/SQL und SQL Coding Guidelines (im Downloadbereich der Trivadis-­
Website) http://www.trivadis.com/metanavigation/downloads.html n APEX Plugin Directory http://www.apex-­plugin.com/ Weiterführende Themen n Portal der MT AG inklusive Lernvideos und Software-­Downloads http://portal.mt-­ag.com n Automatisierter Export und Import von APEX-­Anwendungen per Kommandozeile http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/export-­script/index.html n Blog Eintrag bei Joel R. Kallman „APEX_APPLICATION_INSTALL“ http://joelkallman.blogspot.com/2010/07/apexapplicationinstall.html n APEX Workspace-­Nutzer mit dem SQL Developer verwalten http://www.oracle.com/webfolder/technetwork/de/community/apex/tipps/sqldev-­apexuser/index.html n 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
69 BASEL
FREIBURG I.BR.
MÜNCHEN
Trivadis AG
Trivadis GmbH
Trivadis GmbH
Elisabethenanlage 9
Sasbacher Strasse 2
Riem Arcaden/Neue Messe
CH-4051 Basel
D-79111 Freiburg i. Br.
Lehrer-Wirth-Strasse 4
Tel. +41 58 459 57 57
Tel. +49 761 455 710
D-81829 München
Fax +41 58 459 57 77
Fax +49 761 455 7130
Tel. +49 89 99 27 59 30
Fax +49 89 99 27 59 59
BERN
GENF
STUTTGART
Trivadis AG
Trivadis SA
Trivadis GmbH
Weltpoststrasse 5
Château-Bloch 11
Industriestrasse 4
CH-3015 Bern
CH-1219 Genf
D-70565 Stuttgart
Tel. +41 58 459 56 56
Tel. +41 58 459 58 10
Tel. +49 711 903 63 230
Fax +41 58 459 56 66
Fax +41 58 459 58 11
Fax +49 711 903 63 259
BRUGG
HAMBURG
WIEN
Trivadis Services AG
Trivadis GmbH
Trivadis Delphi GmbH
Badenerstrasse 13
Paul-Dessau-Strasse 6
Millennium Tower
CH-5200 Brugg
D-22761 Hamburg
Handelskai 94 - 96
Tel. +41 58 459 58 58
Tel. +49 40 248 591 30
A-1200 Wien
Fax +41 58 459 58 88
Fax +49 40 248 591 59
Tel. +43 1 332 35 31 00
Fax +43 1 332 35 34
DÜSSELDORF
KOPENHAGEN
ZÜRICH (HAUPTSITZ)
Trivadis GmbH
Trivadis A/S
Trivadis AG
Werdener Strasse 4
Lautruphøj 1-3
Europastrasse 5
D-40227 Düsseldorf
DK-2750 Ballerup
CH-8152 Glattbrugg
Tel. +49 211 58 6664 70
Tel. +45 70 70 70 73
Tel. +41 58 459 55 55
Fax +49 211 58 6664 71
Fax +41 58 459 55 95
FRANKFURT A.M.
LAUSANNE
Trivadis GmbH
Trivadis SA
Atricom
Rue Marterey 5
Lyoner Strasse 15
CH-1005 Lausanne
D-60528 Frankfurt/Main
Tel. +41 58 459 54 54
Tel. +49 69 264 93 300
Fax +41 58 459 54 44
Fax +49 69 264 93 3019
Trivadis AG Europastrasse 5 CH- 8152 Glattbrugg
Telefon +41 58 459 55 55 Telefax +41 58 459 55 95 www.trivadis.com [email protected]