1 / 41 Erfahrungsbericht: Umstellung einer komplexen Forms

Erfahrungsbericht: Umstellung einer komplexen Forms 6i Anwendung auf eine APEX Application
Francesca Meyer Tornado Systems GmbH
Dieser Vortrag beinhaltet die eigenen Erfahrungen und Fallstricke, die bei der Umstellung einer Forms 6i Anwendung auf APEX
entstanden sind.
Welche Voraussetzungen muss man schaffen, worauf muss man achten?
Ist es überhaupt möglich, ein PPS/ERP Programm so in APEX abzubilden, dass es vom Anwender verstanden und akzeptiert
wird?
Ja, aber nicht mit der automatischen Migration!
- Kurze Beschreibung der Ausgangssituation
- Scheitern mit der automatischen Migration
- Überarbeitung Datenmodell
- Alle Programmblöcke auslagern
- Redesign unter Anwenderbezug
- Ausdrucke von komplexen Formularen
- Kurze Beschreibung der Ist-Situation
Fazit: Apex ist anwenderfreundlicher und wartungsfreundlicher als Forms 6i
1 / 41
Tornado Systems GmbH
Die Tornado Systems GmbH beschäftigt sich seit 1993 mit der Erstellung
von Software für Produktionsabläufe (PPS / ERP).
Schwerpunkt ist dabei, schlanke und effiziente Software zu erstellen.
In unserer Startphase entwickelten wir mit Oracle Forms 2.3 und einer
Datenbank in der Version 5.
Damals war das noch „Character“-orientiert und lief auf Terminals oder
Emulatoren. Die Datenbank lief auf einem Linux Server.
2 / 41
Oracle Forms
Oracle Forms durchlief viele Evolutionsschritte und somit stellte sich für uns
häufig die Frage, ob wir jeden Entwicklungsschritt mitmachen sollen oder ob
wir warten und einen Schritt überspringen.
Formsentwickler wissen, dass nicht jede Version vorteilhaft war.
Die Entscheidungen waren immer schwierig, denn ab und zu stand man an
dem Punkt, an dem man eine Neuentwicklung oder eine beinahe
Neuentwicklung der Software vornehmen musste.
Eine Migration war nicht immer möglich und auch nicht sinnvoll.
In den vergangenen 20 Jahren fanden quasi 3,5 Neuentwicklungen statt.
3 / 41
Entwicklungsschritte: 2.3 auf 4.5
Forms 2.3 → Forms 4.5 → Forms 6.0 → und anschließend APEX 4.0
Oracle Forms 2.3
Oracle Forms 4.5
4 / 41
Entwicklungsschritte: 4.5 auf 6i
Forms 2.3 → Forms 4.5 → Forms 6.0 → und anschließend APEX 4.0
Oracle Forms 4.5
Oracle Forms 6i
5 / 41
Entwicklungsschritte: 6i auf APEX 4.2 / 5
Forms 2.3 → Forms 4.5 → Forms 6.0 → und anschließend APEX 4.0
Oracle Forms 6i
APEX 5.0
6 / 41
Entwicklungsschritte
Die Zwischenversionen von Forms wurden einfach mittels Migration bedient.
In der Formswelt wurde das immer unproblematischer.
Den großen Schritt, von Forms 6i zu APEX zu wechseln, vollzogen wir im
Jahr 2011.
Wir fingen mit APEX 4.0 an.
Für den Wechsel der Entwicklungsumgebung gab es mehrere Gründe:
7 / 41
Gründe für den Wechsel zu APEX
1. Die Wartbarkeit von APEX im Vergleich zu Forms 6i.
2. Die Integration von APEX in die Datenbank.
3. Die Möglichkeit mittels eigenen Tools APEX-Anwendungen direkt in
der Datenbank zu ändern.
4. Neue Technologien wie Mobilität, sollten abgedeckt werden.
5. Interaktive Reports waren vielseitiger als starre Strukturen.
6. Eine einfachere Administration für die IT-Abteilung sollte erreicht
werden.
8 / 41
Sicht der Entwickler
Erfahrungen mit APEX (damals noch HTML DB) lagen seit 2004 vor.
Kleine Projekte zeigten schon die Leistungsfähigkeit des Werkzeuges.
Leider fehlte am Anfang noch der Bedienungskomfort.
Viele Diskussionen zwischen Mitarbeiten und auch Anwendern hielten
uns lange ab, unser Hauptprodukt umzustellen. Der gefühlte
Bedienungskomfort von Forms zu APEX war für die Anwender schlecht
und eine zu große Umstellung der gewohnten Arbeitsabläufe.
Warum sollte man auch ein laufendes System umstellen?
Es kostet Geld, Zeit und viele kleine 'Bugs' schleichen sich ein.
9 / 41
Sicht der Entwickler
Entwickler sahen APEX
als Spielzeug, konnten
sich auch schwer mit
dem Entwicklungstool
anfreunden,
da der Aufbau
und die Logik
völlig anders
waren als zuvor
von Forms gewohnt.
10 / 41
Sicht der Entwickler
Beispiel APEX 4.2 hatte schon große Verbesserungen zur Version 4.0
11 / 41
Sicht der Entwickler
Mit APEX 5.0 wurde es für ehemalige Formsentwickler einfacher, da ähnlicher Aufbau
12 / 41
Sicht der Anwender
Die Anwender waren von Forms 'verwöhnt' und wollten sich mit dem
Browser nicht identifizieren. Sie empfanden die Bedienung als
Zumutung.
Es gab keine Funktionstasten und keine Schnellsprünge.
Die Masken sahen einfach anders aus, die Arbeitsweise war
umständlicher.
In Forms konnten sie in allen Feldern suchen, die dazu freigegeben
waren.
In APEX muß hier vom Entwickler eigens eine Suchabfrage
programmiert werden.
13 / 41
Sicht der Anwender
Funktionstaste F10 Suchmodus an | Suchmuster eingeben | F11 Ergebnisse anzeigen
Das war einfach für die Anwender im täglichen Gebrauch
14 / 41
Suchen in APEX
Die 'interactiv Reports', die zwar im Vergleich zur Forms-Suchabfrage
ähnlich mächtig sind, müssen aber vom Anwender verstanden werden.
Wir haben festgestellt, dass das einen längeren Zeitraum in Anspruch
nimmt und nicht jeder mit dem Algorithmus klar kommt.
Wir führten dazu ein 'Suchfeld' im oberen Block der Masken ein.
Das Feld sucht über vordefinierte Felder in der Maske.
15 / 41
Suchen in APEX
Bei mehren Treffern der Abfrage gelangt man in einen 'interactiven'
Report oder kann die 'Detailsuche' verwenden.
Hier kann der erfahrene Anwender seine speziellen Abfragen
formulieren.
16 / 41
automatische Migration
Oracle stellt in der APEX Entwicklungsumgebung ein Tool zur Migration
bereit.
Sie finden es in APEX 5 unter dem Punkt 'Migration' ganz rechts im
Menü.
Es wird in 6 Schritten beschrieben, wie sie vorgehen müssen.
Das Konvertierungstool 'Forms2XML' muss installiert werden.
Das Tool zum konvertieren in XML ist erst ab der Forms 9i Version
vorhanden. Der Zwischenschritt über XML ist nötig.
17 / 41
automatische Migration
18 / 41
Forms2XML
Mittels dem Tool frmf2xml das *.fmb File konvertieren
PL/SQL Library lassen sich ebenso wie Reports konvertieren
19 / 41
Workspace erstellen zum Schema
Workspace erstellen, Schema zuordnen, Anwender anlegen, am neuen WS anmelden
20 / 41
Ein Migrationsprojekt erstellen
Im WS ein Projekt aufmachen, Typ und Datei auswählen und 'create' drücken.
21 / 41
Das XML File importieren
Das XML File wurde geladen und man sieht den Inhalt der Formsmaske in seiner
Komplexität aufgelistet. Anzahl der Blöcke, der Items, der Programmabschnitte,
der Trigger, etc.
22 / 41
Die Metadaten analysieren / anpassen
Jetzt erfährt man, was anwendbar ist und was nicht.
Schon an dieser Stelle wurde ersichtlich, dass für diese Maske sehr viel Nacharbeit nötig
ist.
23 / 41
Die Anwendung generieren
Wir haben viele leere Blöcke verwendet, die mussten wir teilweise ausblenden.
Kleingeschriebene SQL Abfragen mussten wir teilweise auf Großbuchstaben ändern
(Tabellennamen). Schemen müssen bereinigt werden.
24 / 41
Die Anwendung generieren
In Forms haben wir oft die Abfrage Syntax mit ein „Schema“ verwendet.
select land from torn.ttland
Daraus wurde dann in XML:
DMLDataName="TORN.TTLAND" ScrollbarWidth="12" QueryAllowed="true"
QueryDataSourceType="Tabelle" RecordsBufferedCount …….‘
Die Application war so nicht erstellbar,
da die Datenbankobjekte im Schema
nicht gefunden wurden.
Nach Änderung der Abfrage in
select land from ttland
funktionierte es.
25 / 41
automatische Migration
Jeder XML Import musste analysiert und überarbeitet werden.
Trotzdem waren die Ergebnisse eher ernüchternd und mit sehr viel
Nacharbeit belastet.
Einfache Forms ließen sich umstellen, komplexe eher nicht.
Forms mit mehreren Master-Detail-Bezügen zu migrieren, war
unmöglich.
War eine Form mit aufwendigen Buchungsabläufen versehen,
scheiterte die Migration ebenfalls. Die Abläufe funktionierten nicht.
26 / 41
automatische Migration
Das manuelle Nacharbeiten hätte die Entwicklungszeit in die Höhe
getrieben. Schon nach einer Woche stand die Entscheidung fest:
Die automatische Migration von komplexen Forms ist für uns nicht
verwendbar. Es wird neu entwickelt.
Ohne Neuentwicklung war die Funktionalität von APEX nicht
ausgeschöpft.
Die Migration ergab eher ein rudimentäres Grundsystem.
27 / 41
Gründe für die Schwierigkeiten
Die unterschiedlichen Architekturen und die damit verbundenen
logischen Abläufe sind dafür verantwortlich, dass eine 1 zu 1 Umsetzung
nicht gelingt.
Forms mit vielen Canvas / Leinwänden werden teilweise als separate
APEX Masken erstellt.
Die Vorteile einer WEB-Anwendung werden nicht erzeugt.
Trigger in Forms können nicht für APEX umgesetzt werden.
28 / 41
Unterschiede Form / APEX Architektur
●
●
Forms: 3 Tier
- Logik wird in der Datenbank oder im Client verarbeitet
- Middle-Tier-Forms Server oder im Rich-Client
APEX: 2 Tier
- Logik wird in der Datenbank mittels PL/SQL abgebildet
- Clientseitig wird die Logik mit JavaScript realisiert
- HTTP Kommunikation mittels Apache und mod_pl_sql
oder Oracle REST Data Services / RESTful Services
29 / 41
Unterschiede Form / APEX zur Datenbank
Datenbankverbindung
●
●
Forms synchron
Mehrere Masken mit verschiedene Blöcken können für unterschiedliche
Tabellen bearbeitet und mittels eines „commit‘s“ in die Datenbank
geschrieben werden.
APEX unterstützt das nicht.
30 / 41
Unterschiede Form / APEX User-Session
In Forms hält jeder angemeldeter Anwender / User eine Session.
Jeder Nutzer hält vom Client zur Datenbank eine synchrone Verbindung.
APEX verhält sich anders. Eine Verbindung zur Datenbank ist asynchron
und wird nur bei POST oder READ Befehlen erzeugt, anschließend
verworfen.
31 / 41
automatische Migration
Der Aufbau und die Funktionen einer Formsumgebung zur WebAnwendung sind einfach zu unterschiedlich, so dass es besser ist, die
Anwendung neu zu konzipieren. Nur so bekommt man die zusätzliche
Webfunktionalität. Ich meine, dass jeder, der umsteigt, etwas Zeit mit der automatischen
Migration verwenden sollte.
Es ist lehrreich, um die Unterschiede der Entwicklungskonzepte und
Abläufe zu verstehen.
Außerdem waren unsere Forms sehr mit Funktionalität und Canvas
überladen, so dass man sich in den Korrekturen nach der Migration
'verzettelte'.
Vielleicht sollten sie es einmal ausprobieren und selbst eine
Entscheidung treffen.
32 / 41
Neuentwicklung
Eine Neuentwicklung ist keinesfalls unlösbar.
Die in Apex enthaltenen Wizzards sind dabei sehr hilfreich. Je sauberer
das Datenmodell definiert ist, um so besser erstellen diese Assistenten
ein grobes, aber schon ein funktionstüchtiges Gerippe der Anwendung.
Mit APEX 5 gab es hier noch einen weiteren Schritt nach vorne.
Die Arbeitsabläufe wurden vereinfacht.
Komplexe Reports und Master-Detail-Masken lassen sich jetzt als
Anwendung erzeugen. Die Entwickler machen die Feinjustage.
33 / 41
unser Vorgehen:
1. - Überarbeitung des Datenmodells
- Verriegelung der Felder
- Größen und Dimensionen der Felder setzen
2. - Erarbeitung von Richtlinien und Leitfäden für die Entwickler
3. - Die komplexen Forms nach enthaltenen Programmteilen
durchsuchen und diese durch Datenbankproceduren ersetzen 4. - Die gesamte Betriebslogik als PL-SQL-Packages und Proceduren
in die Datenbank auslagern
Tipp: Möglichst viel der Programmlogik direkt als Package oder Procedure in die
Datenbank auslagern. Nehmen sie sich Zeit dafür, es macht die Entwicklung einfacher.
34 / 41
unser Vorgehen:
5. Ein passendes Template / Theme für die neue Application finden. In
APEX sind einige enthalten, die man ganz verwenden kann oder für
seine Anwendung abändert oder ergänzt.
Wir haben das Theme 11 für unsere Zwecke abgewandelt, so dass
die zukünftige Oberfläche ähnlich der alten war. Die Anwender
sollten sich trotz neuer Technologie wiederfinden.
Der Schulungsaufwand wird so auch klein gehalten.
Die Akzeptanz der neuen Applikation ist so nach der Umstellung
leichter.
35 / 41
unser Vorgehen:
6. Erarbeitung eines Berechtigungssystems. Wir haben es bis auf
Feldebene vorbereitet.
So können Sie eine dynamische Menüstruktur erreichen und gezielt
Masken bzw. Felder sperren.
7. Nötige 'Plug Ins' erstellen. Zum Beispiel für den Aufruf von
Druckprozessen. 8. Vermehrt Datenbank-Trigger verwenden
36 / 41
An Standards halten
Bei der Entwicklung möglichst viele der Funktionen von APEX
verwenden.
Nur dann auf eigene Javascripte setzen, wenn es wirklich nötig ist.
Hält man sich daran, ist es einfacher im Apex Versionzyklus
mitzukommen.
Unsere eigenen Templates limitieren uns, leider waren sie für unsere
Anwendung nötig. Wir hoffen es irgendwann durch das Universal Theme
abzulösen.
- Kompromisse im Layout eingehen
37 / 41
Fazit
Da über 90% der migrierten Forms-Anwendungen unakzeptabel waren,
die Masken sich anders als in Forms verhielten, anders aussahen
und dazu noch stundenlang nachbearbeitet werden mussten, macht es
Sinn, eine Neuentwicklung der Anwendung zu starten.
Mit APEX lässt sich schnell und effizient ein voll funktionstüchtiges
Modell erstellen. Stück für Stück kann der Bedienungskomfort
dann nachgearbeitet werden.
Gezieltes Einsetzten von 'Dynamic Actions' verhilft zur
Anwenderakzeptanz.
38 / 41
Fazit
Basiert die zu erstellende Anwendung hauptsächlich auf Tabellen und
Views, dann ist ein Umstieg weniger problematisch.
Buchungsabläufe mit viel Interaktion sind etwas kniffelig in der Erstellung
und dauern länger in der Realisierung als unter Forms.
Für das Reporting haben wir auf Jasper Reports gesetzt.
39 / 41
Fazit
Wir haben für die Neuentwicklung ein knappes Jahr benötigt. Zwei
Entwickler, die sich in der alten Anwendung perfekt auskannten, waren
dazu nötig.
Die Entwickler müssen sich in APEX gut eingearbeitet haben und PLSQL beherrschen. Grundwissen in Java-Script, HTML und CSS sollten
vorhanden sein.
Umgesetzt wurden dazu knapp 1000 Forms und 500 Reports, wobei ein
großer Anteil der Forms und Reports entfiel, da die in APEX
vorhandenen 'interactive Reports' sehr leistungsstark sind.
Die neue Darstellung war übersichtlich und änderbar.
40 / 41
Tornado Systems GmbH
Kontakt:
Tornado Systems GmbH
Francesca Meyer
Einsteinufer 57
10587 Berlin
mail:
Telefon:
francesca.meyer @ tornado.de
030 / 456008 19
41 / 41