Das Dokument beschreibt verschiedene Implementierungsvarianten für die Entwicklung von Formularen mithilfe von Oracle Application Express (APEX), darunter die Nutzung von Assistenten, Triggern und manuelle Vorgehensweisen. Es hebt die Bedeutung einer gründlichen Analysephase sowie der Flexibilität und Wartbarkeit der entwickelten Lösungen hervor. Ziel ist es, die unterschiedlichen Ansätze und deren Vor- und Nachteile klar darzustellen, um APEX-Entwicklern eine fundierte Entscheidungshilfe zu bieten.

1. |
Implementierungsvarianten
mit Oracle Application Express
Niels de Bruijn, Fachbereichsleiter
26.09.2012

2. || Implementierungsvarianten mit APEX2
EINE MARKE.
MEHRERE UNTERNEHMEN.
Hauptsitz
Ratingen
Niederlassungen
Hamburg, Dortmund, Frankfurt, Luxemburg
Tochtergesellschaften
MT-ifs GmbH, MT-ics GmbH
Inhabergeführte AG
Gründung
1994
Beschäftigte
220 Festangestellte / 80 Freiberufler

3. |
Entwicklung von Formularen mittels APEX
1. VARIANTE 1: ASSISTENTEN IM EINSATZ
2. VARIANTE 2A: „PIMP YOUR APEX“ MIT TRIGGERN
3. VARIANTE 2B: UMSTELLUNG AUF MANUELL
4. VARIANTE 3: KOMPLETT „MANUELLER“ VORGANG
Implementierungsvarianten mit APEX3

4. |
- Viele Hypes
 Mobile Computing, Cloud Computing, usw.
- Womit beschäftigen wir uns als APEX Entwickler im Alltag?
 Entwicklung von Masken!
 Hauptsächlich Formulare und Berichte
- Maske ≠ Maske, daher auch verschiedene Strategien
 Vorgehensweise bei der Entwicklung von Formularen ist sehr entscheidend und vor
der Entwicklung festzulegen!
 Eine vernünftige Analysephase ist das A und O
Implementierungsvarianten mit APEX4
Entwicklung von Formularen mittels APEX

5. |
seitenspezifische View
mit optional „instead of“ Trigger
Entwicklung von Formularen mittels APEX
Implementierungsvarianten mit APEX5
APEX Seite
Tabellen
inkl. Trigger und Sequenz, optional TAPI
seitenspezifisches Package
View
Logik
Persistenz

6. ||
Variante 1: Assistenten im Einsatz
Implementierungsvarianten mit APEX6

7. |
- Rapid Application Development
 10-60 Minuten pro Bericht
 60-240 Minuten pro Formular
- Checksum-Prüfung integriert
- Einfache Validierung direkt enthalten
 Pflichtfelder
 Datentyp
- Weitere Validierungen deklarativ möglich
- Kenntnis von SQL reicht aus
- Nur 1 SRU (= Einzelfelder) auf einer Tabelle möglich
- Nur 1 MRU (= tabellarisches Formular) auf einer Tabelle möglich
Implementierungsvarianten mit APEX7
Variante 1: Assistenten im Einsatz

8. | Implementierungsvarianten mit APEX8
Variante 1: Assistenten im Einsatz

9. ||
Variante 2a: „Pimp your APEX“ mit Triggern
Implementierungsvarianten mit APEX9

10. |
- Ermöglicht komplexe Datenverarbeitung (mehrere Tabellen)
Nachteile:
- Variante 1 + 60 Minuten extra Entw.aufwand
- PL/SQL Kenntnisse notwendig
- Trigger wird beim Löschen der View
mit gelöscht
Implementierungsvarianten mit APEX10
seitenspezifische
View
APEX
Tabelle
1
seitenspezifische
Trigger
Tabelle
2
Tabelle
N
Variante 2a: „Pimp your APEX“ mit Triggern

11. ||
Variante 2b: Umstellung auf manuell
Implementierungsvarianten mit APEX11

12. |
- Ermöglicht komplexe Datenverarbeitung (mehrere Tabellen)
- Seite wird durch Assistenten erstellt
 Items inkl. eine Standardvalidierung vorhanden
- Eigener Save Prozess (PL/SQL) oder
- Eigener Fetch und Save Prozess (PL/SQL)
Vorteile
- Keine instead-of Trigger
Nachteile
- Eigene Checksum
- Variante 1 + 60 Minuten extra Entw.aufwand
Implementierungsvarianten mit APEX12
Variante 2b: Umstellung auf manuell

13. |
- Mehrere tabellarische Formulare auf einer Seite
- Sehr viele abhängige Felder / Dynamic Actions
- Eingaben prüfen auch nach dem Speichern ermöglichen
Was passiert:
- Entwickler versucht verzweifelt die Anforderungen umzusetzen
 Folge: er produziert eine kaum wartbare Seite
- Alternative….
Implementierungsvarianten mit APEX13
Komplexe Anforderungen, was nun?

14. ||
Variante 3: Komplett „manueller“ Vorgang
Implementierungsvarianten mit APEX14

15. |
- Eigener Fetch/Save-Prozess (einer pro Seite)
 PL/SQL Package pro Seite
 Kann ohne APEX Expertise entwickelt und getestet werden (Unit Test)
- Source Type = Static Assignment
- Größtmögliche Flexibilität und Wartbarkeit
Nachteile:
- Viel PL/SQL schreiben (Generator hilfreich)
- Eigene Checksum-Prüfung notwendig
- (Rapid?) Application Development: 1-5 PT pro Formular
Implementierungsvarianten mit APEX15
Variante 3: Komplett „manueller“ Vorgang

16. | Implementierungsvarianten mit APEX16
Variante 3: Komplett „manueller“ Vorgang

17. |
- Logik gehört in der Datenbank (Workspace Schema)
- Immer (seitenspezifische) Views/Packages verwenden
- Man nutzt das, was APEX Standard bietet
 Variante 1 angehen
- Wenn es über das Standardverhalten von APEX hinausgeht
 Variante 1 erweiterbar durch Variante 2a/2b
 Komplexere Anforderungen? Variante 3 verfolgen
- Bei Großprojekten deckt APEX nur einen Teil der Anforderungen ab
 User Interface, Workflows, Berechnungen
 Integration in Backendsysteme
Implementierungsvarianten mit APEX17
FAZIT

18. |
Vielen Dank.
MT AG
Balcke-Dürr-Allee 9
40882 Ratingen
Telefon: +49 (0) 21 02 309 61-0
Telefax: +49 (0) 21 02 309 61-10
E-Mail: apex@mt-ag.com
apex.mt-ag.com