Erfahrungsbericht: Umstellung einer komplexen Forms 6i ... 1 / 41 Erfahrungsbericht: Umstellung...

download Erfahrungsbericht: Umstellung einer komplexen Forms 6i ... 1 / 41 Erfahrungsbericht: Umstellung einer

of 41

  • date post

    01-Sep-2019
  • Category

    Documents

  • view

    0
  • download

    0

Embed Size (px)

Transcript of Erfahrungsbericht: Umstellung einer komplexen Forms 6i ... 1 / 41 Erfahrungsbericht: Umstellung...

  • 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 mglich, 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 Programmblcke 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 beschftigt sich seit 1993 mit der Erstellung von Software fr Produktionsablufe (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 fr uns hufig 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 mglich 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 anschlieend 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 anschlieend 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 anschlieend 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 groen Schritt, von Forms 6i zu APEX zu wechseln, vollzogen wir im Jahr 2011.

    Wir fingen mit APEX 4.0 an.

    Fr den Wechsel der Entwicklungsumgebung gab es mehrere Grnde:

  • 8 / 41

    Grnde fr den Wechsel zu APEX

    1. Die Wartbarkeit von APEX im Vergleich zu Forms 6i.

    2. Die Integration von APEX in die Datenbank.

    3. Die Mglichkeit mittels eigenen Tools APEX-Anwendungen direkt in der Datenbank zu ndern.

    4. Neue Technologien wie Mobilitt, sollten abgedeckt werden.

    5. Interaktive Reports waren vielseitiger als starre Strukturen.

    6. Eine einfachere Administration fr 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 Leistungsfhigkeit des Werkzeuges.

    Leider fehlte am Anfang noch der Bedienungskomfort.

    Viele Diskussionen zwischen Mitarbeiten und auch Anwendern hielten uns lange ab, unser Hauptprodukt umzustellen. Der gefhlte Bedienungskomfort von Forms zu APEX war fr die Anwender schlecht und eine zu groe Umstellung der gewohnten Arbeitsablufe.

    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 vllig anderswaren als zuvor von Forms gewohnt.

  • 11 / 41

    Sicht der Entwickler

    Beispiel APEX 4.2 hatte schon groe Verbesserungen zur Version 4.0

  • 12 / 41

    Sicht der Entwickler

    Mit APEX 5.0 wurde es fr ehemalige Formsentwickler einfacher, da hnlicher Aufbau

  • 13 / 41

    Sicht der Anwender

    Die Anwender waren von Forms 'verwhnt' und wollten sich mit dem Browser nicht identifizieren. Sie empfanden die Bedienungals Zumutung.

    Es gab keine Funktionstasten und keine Schnellsprnge.

    Die Masken sahen einfach anders aus, die Arbeitsweise war umstndlicher.

    In Forms konnten sie in allen Feldernsuchen, 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 fr die Anwender im tglichen Gebrauch

  • 15 / 41

    Suchen in APEXDie 'interactiv Reports', die zwar im Vergleich zur Forms-Suchabfrage hnlich mchtig sind, mssen aber vom Anwender verstanden werden. Wir haben festgestellt, dass das einen lngeren Zeitraum in Anspruch nimmt und nicht jeder mit dem Algorithmus klar kommt.

    Wir fhrten 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 mssen.

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

  • 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 auswhlen und 'create' drcken.

  • 22 / 41

    Das XML File importieren

    Das XML File wurde geladen und man sieht den Inhalt der Formsmaske in seiner Komplexitt aufgelistet. Anzahl der Blcke, der Items, der Programmabschnitte, der Trigger, etc.

  • 23 / 41

    Die Metadaten analysieren / anpassen

    Jetzt erfhrt man, was anwendbar ist und was nicht.Schon an dieser Stelle wurde ersichtlich, dass fr diese Maske sehr viel Nacharbeit ntig ist.

  • 24 / 41

    Die Anwendung generieren

    Wir haben viele leere Blcke verwendet, die mussten wir teilweise ausblenden.Kleingeschriebene SQL Abfragen mussten wir teilweise auf Grobuchstaben ndern (Tabellennamen). Schemen mssen 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 ernchternd und mit sehr viel Nacharbeit belastet.

    Einfache Forms lieen sich umstellen, komplexe eher nicht.

    Forms mit mehreren Master-Detail-Bezgen zu migrieren, war unmglich.

    War eine Form mit aufwendigen Buchungsablufen versehen,scheiterte die Migration ebenfalls. Die Ablufe funktionierten nicht.

  • 27 / 41

    automatische Migration

    Das manuelle Nacharbeiten htte die Entwicklungszeit in die Hhe getrieben.

    Schon nach einer Woche stand die Entscheidung fest:Die automatische Migration von komplexen Forms ist fr uns nicht verwendbar. Es wird neu entwickelt.

    Ohne Neuentwicklung war die Funktionalitt von APEX nicht ausgeschpft.

    Die Migration ergab eher ein rudimentres Grundsystem.

  • 28 / 41

    Grnde fr die Schwierigkeiten

    Die unterschiedlichen Architekturen und die damit verbundenen logischen Ablufe sind dafr verantwortlich, dass eine 1 zu 1 Umsetzung nicht gelingt.

    Forms mit vielen Canvas / Leinwnden werden teilweise als separate APEX Masken erstellt.

    Die Vorteile einer WEB-Anwendung werden nicht erzeugt.

    Trigger in Forms knnen nicht fr 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