1 / 41

Erfahrungsbericht: Umstellung einer komplexen Forms 6i Anwendung auf eine APEX ApplicationFrancesca 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

2 / 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.

3 / 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.

 

4 / 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

5 / 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

6 / 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

7 / 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:

8 / 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.

9 / 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.

10 / 41

Sicht der EntwicklerEntwickler sahen APEX als Spielzeug, konnten sich auch schwer mit dem Entwicklungstool anfreunden, da der Aufbauund die Logik völlig anderswaren als zuvor von Forms gewohnt.

11 / 41

Sicht der Entwickler

Beispiel APEX 4.2 hatte schon große Verbesserungen zur Version 4.0

12 / 41

Sicht der Entwickler

Mit APEX 5.0 wurde es für ehemalige Formsentwickler einfacher, da ähnlicher Aufbau

13 / 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.

14 / 41

Sicht der Anwender

Funktionstaste F10 Suchmodus an | Suchmuster eingeben | F11 Ergebnisse anzeigen

Das war einfach für die Anwender im täglichen Gebrauch

15 / 41

Suchen in APEXDie '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.

16 / 41

Suchen in APEXBei mehren Treffern der Abfrage gelangt man in einen 'interactiven'Report oder kann die 'Detailsuche' verwenden.

Hier kann der erfahrene Anwender seine speziellen Abfragen formulieren.

17 / 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.

18 / 41

automatische Migration

19 / 41

Forms2XML

Mittels dem Tool frmf2xml das *.fmb File konvertieren

PL/SQL Library lassen sich ebenso wie Reports konvertieren

20 / 41

Workspace erstellen zum Schema

Workspace erstellen, Schema zuordnen, Anwender anlegen, am neuen WS anmelden

21 / 41

Ein Migrationsprojekt erstellen

Im WS ein Projekt aufmachen, Typ und Datei auswählen und 'create' drücken.

22 / 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.

23 / 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.

24 / 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.

25 / 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 Schemanicht gefunden wurden.

Nach Änderung der Abfrage in

select land from ttland

funktionierte es.

26 / 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.

27 / 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.

28 / 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.

 

 

29 / 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

 

 

30 / 41

Unterschiede Form / APEX zur Datenbank

Datenbankverbindung

● Forms synchronMehrere 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.

 

31 / 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 asynchronund wird nur bei POST oder READ Befehlen erzeugt, anschließend verworfen.

 

 

32 / 41

automatische MigrationDer Aufbau und die Funktionen einer Formsumgebung  zur Web-Anwendung 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.

33 / 41

NeuentwicklungEine 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.

34 / 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.

35 / 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.

 

36 / 41

unser Vorgehen:

6. Erarbeitung eines Berechtigungssystems. Wir haben es bis aufFeldebene 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 vonDruckprozessen. 

8. Vermehrt Datenbank-Trigger verwenden

 

 

 

37 / 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 unsereAnwendung nötig. Wir hoffen es irgendwann durch das Universal Theme abzulösen.

- Kompromisse im Layout eingehen

 

 

38 / 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 Bedienungskomfortdann nachgearbeitet werden.

Gezieltes Einsetzten von 'Dynamic Actions' verhilft zur Anwenderakzeptanz.

 

39 / 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.

 

40 / 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 PL-SQL 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.

 

41 / 41

Tornado Systems GmbH

Kontakt:

Tornado Systems GmbHFrancesca Meyer

Einsteinufer 5710587 Berlin

mail: francesca.meyer @ tornado.deTelefon: 030 / 456008 19