Für die Migration von Forms nach APEX stellt Oracle Assistenten zur Verfügung, die eine automatisierte Migration ermöglichen. Doch sobald komplexe Forms in APEX abgebildet werden müssen, bringen die Wizards keine Erleichterung: In 99 Prozent der Fälle bekommt man allenfalls eine rudimentäre APEX-Anwendung, an der noch viel herumgebastelt werden muss, bis die Funktionalitäten der Forms-Anwendung abgebildet sind. Darüber hinaus sind die Architekturen einer Rich Client- bzw. Web-Anwendung von Grund auf so unterschiedlich, dass es durchaus Sinn macht, die Anwendung neu zu konzipieren. Doch dabei können die Assistenten durchaus helfen.
Besser ist es also, die Anwendung neu zu entwickeln und dabei einige Richtlinien zu beachten:
- Wo immer möglich, die Assistenten (Wizards) einsetzen
- Immer auf Views aufsetzen, niemals direkt auf Tabellen
- APEX als reine View-Schicht betrachten und die komplette Geschäftslogik in PL/SQL-Packages unterbringen
- Bei komplexen Views „instead of“- Trigger verwenden, damit weiterhin die Assistenten verwendet werden können
- Richtlinien für die Entwicklung vorab aufstellen (und einhalten!)
Für kleine und einfache Forms-Anwendungen reicht eine „One-Man-Show“ meist aus. Umfangreiche und anspruchsvolle Forms-Lösungen setzen ein Team mit unterschiedlichen Kompetenzen voraus. Neben APEX-Experten sind dann auch Datenbank-Profis und Fachkräfte mit HTML-, CSS- und JavaScript/jQuery-Know-how gefragt. Ein Qualitäts- und ein Projektmanager runden optimalerweise das Team ab.
Client/Server- vs. Web-Architektur
Egal, ob die Zieltechnologie APEX, Java, .Net oder PHP ist: Sobald ein Wechsel von einer Client/Server-Architektur in eine Web-Architektur erfolgt, wird das Ergebnis für den Endanwender niemals identisch mit der bisherigen Lösung sein. Eine Benutzeroberfläche im Web verhält sich grundsätzlich anders als bei Forms – und sieht auch anders aus.
Zunächst einmal bietet APEX viele Standard-Funktionalitäten, die man zusätzlich einsetzen kann und sollte. So wird man zum Beispiel auf den Einsatz von „Interactive Reports“ kaum verzichten wollen. Damit lassen sich beispielsweise die Stammdaten einer Anwendung bequem durch den Endanwender gruppieren, sortieren, ein- und ausblenden, kalkulieren, summieren und aufbereiten.
Web-Anwendungen bedeuten das Ende der dezidierten Datenbank-Session pro Benutzer und optimistisches Locking-Verhalten. Änderungen an den Daten sind im Normallfall explizit zu speichern.
Vieles wurde bereits im Web-Umfeld getan, um die Mimik von Forms-Anwendungen auch in Web-Anwendungen nachzuahmen. Fakt bleibt aber, dass die Endanwender sich umgewöhnen müssen. Deswegen ist es umso wichtiger, die Benutzer frühzeitig am Migrationsprojekt zu beteiligen.
Auch hier kann APEX eine wichtige Rolle spielen: Damit lässt sich in wenigen Tagen ein Prototyp bereitstellen. Somit kann man das Design und die Benutzerführung schnell klären und damit den Umfang der funktionalen Spezifikation drastisch reduzieren. Innerhalb von wenigen Iterationen entstehen zusammen mit dem Fachbereich konkrete Vorstellungen, wie die Anwendung aussehen muss und wie man sie bedient.
Erfolgreich am Ziel
Der Erfolg einer Migration hängt von verschiedenen Faktoren ab:
- Wie gut ist das Datenmodell?
- Wie gut sind die Entwickler?
- Wie kompliziert sind die Masken und inwiefern muss jede Maske 1:1 nachgebaut werden?
Die hohe Geschwindigkeit der Entwicklung mit APEX ist im Wesentlichen nur dann gegeben, wenn auch das Datenmodell gut strukturiert ist. Leider ist das nicht immer der Fall und es geht viel Zeit damit verloren, das Datenmodell zu verstehen und die richtigen SQL-Abfragen zu erstellen.
Eine gute Anwendung braucht ein gutes Datenmodell, APEX hin oder her. Steht das Datenmodell, dann kommt es entscheidend auf die APEX-Entwickler an. Auch APEX-Projekte können in eine Schieflage geraten, wenn nicht gewisse Richtlinien für die Entwicklung eingehalten werden. Außerdem ist viel Erfahrung notwendig, um zu beurteilen, ob etwas mit APEX-Bordmitteln geht und wie. Hierbei bieten die Quellen im Internet eine gute Unterstützung. Besonders auf den deutschsprachigen APEX-Seiten von Carsten Czarski sind viele praktische Tutorials zu finden.
Gerade bei der Ablösung von Forms-Anwendungen ist eine gründliche Analyse pro Maske notwendig, bevor mit der Umsetzung angefangen werden kann. In dieser Phase sollte einerseits das Verhalten der Maske erörtert und andererseits abgestimmt werden, wie die Maske im Browser aussehen wird. Erfahrungsgemäß muss man einen Kompromiss zwischen Bedienbarkeit und Aufwand finden. Die 80/20-Regel gilt nämlich auch für APEX-Projekte: 80 Prozent der Funktionalität lassen sich in 20 Prozent der Entwicklungszeit realisieren und umgekehrt.
Problemfall Forms-Masken
Rein wirtschaftlich betrachtet ist die Ablösung komplexer Oracle-Forms-Anwendungen meist nicht besonders sinnvoll, egal ob APEX, Java oder .Net als Zieltechnologie favorisiert wird.
Im Falle von APEX gibt es bei APEX 4.1 noch einige Limitationen, die zwar umgangen werden können, die jedoch bei komplexen Forms-Masken ein manuelles Nacharbeiten erfordern und dadurch die Entwicklungszeit schnell in die Höhe treiben. Beispielsweise gibt es in 4.1 noch keine Möglichkeit, auf der gleichen Seite mehrere tabellarische Formulare oder Berichte vom Typ „Interactive Report“ deklarativ hinzuzufügen. Gleiches gilt für Forms-Masken mit einer dreistufigen Master-Detail-Detail-Beziehung. Erfreulicherweise ist APEX 4.2 in der Mache und wird sicherlich ein paar neue Funktionalitäten mit sich bringen.
Ein Beispiel aus der Praxis
Die Union Investment Gruppe, einer der größten deutschen Asset-Manager für private und institutionelle Anleger, nutzt das Oracle-basierte System „OraDIS“, das primär der verteilten Pflege von Fonds-Stammdaten dient.
Vor der Migration kamen als Frontend MS Access 2007 sowie Oracle Forms 6i zum Einsatz. Eine Beendigung des Standard- und Extended Supports für Oracle Forms 6i seitens des Herstellers und das unzureichende Antwortverhalten von MS Access 2007 waren die maßgeblichen Auslöser für das Migrationsprojekt.
In einem „Proof of Concept“ fand daraufhin Ende 2009 eine Realisierung mittels APEX statt (siehe Abbildungen 1 und 2). Anschließend wurden im Zeitraum April bis August 2010 etwa 160 funktionale Dialoge, zu denen auch 60 Oracle-Forms-Masken gehörten, nach APEX 3.2 migriert. Seit Mitte August 2010 wird die Applikation durch 100 Endanwender produktiv
verwendet. Die Oracle-Forms-Masken waren von der Komplexität her noch recht überschaubar und ließen sich ohne große Schwierigkeiten in APEX umsetzen. Zwei Herausforderungen gab es dennoch: In Forms-Masken können die gleichen Felder auch für die Suche verwendet werden. Da es in APEX im Standard keinen integrierten „Suchmodus“ gibt, wurden zusätzliche Suchfelder über den Bericht dargestellt, um eine ähnliche Funktionalität abzubilden.
Außerdem gab es einige Masken mit einer „fixierten“ Berichtsspalte. Wenn man horizontal scrollt, sollte die erste Spalte sichtbar bleiben. Dank einer Erweiterung auf Basis von jQuery konnte diese Funktionalität umgesetzt werden. Die Abbildungen 4 bis 7 zeigen das Ergebnis der Migration. Eine Demo dazu können Sie sich hier ansehen. Die Abbildungen 3 bis 6 zeigen das Ergebnis der Migration.
Fazit
Sehr komplexe Forms-Masken sollte man mit Application Express in der Version 4.1 vorerst noch nicht migrieren. Einfache bis mittelkomplexe Forms-Masken lassen sich dagegen durchaus mit APEX 4.1 schnell und effizient umsetzen. Wenn man dabei hauptsächlich mithilfe der APEX-Assistenten vorgeht und sich an einige Richtlinien hält, so braucht man im Vergleich zu anderen Entwicklungsumgebungen bis zu 60 Prozent weniger Entwicklungszeit – Rapid Application Development eben.
