1:1 Forms nach Java Migration beim VDI - Ein Erfahrungsbericht -

Transkript

1 1:1 Forms nach Java Migration beim VDI - Ein Erfahrungsbericht - Alexander Orbach OPITZ CONSULTING Gummersbach GmbH Seite 1

2 Agenda 1:1 Forms nach Java Migration beim VDI 1. Kurzvorstellung des VDI und der Ausgangssituation 2. Gründe für eine Migration weg von Oracle Forms 3. Entscheidungskriterien des VDI für eine Migration 4. Unterschiede im Systemverhalten Forms vs. Java 5. Die verwendete Technik Seite 2

3 1 Kurzvorstellung des VDI und der Ausgangssituation Seite 3

4 Verein Deutscher Ingenieure (VDI) Der ist... einer der größten technisch-wissenschaftlichen Vereine Europas persönliche Mitglieder Sprecher der Ingenieure und der Technik in Deutschland Institution für die Weiterbildung und den Erfahrungsaustausch Sein Know-how bezieht der VDI aus... dem Netzwerk seiner Mitglieder und Kooperationspartner der Zusammenarbeit mit Wirtschaft und Wissenschaft ehrenamtlich tätigen Experten Ziel: Bereitstellung dieses Wissens in Form von Beratungsleistungen, Broschüren, Seminaren, Tagungen, VDI-Richtlinien, Messen, etc. Die VDI-Gruppe umfasst u. a.... VDI e. V., VDI GmbH, VDI Wissensforum GmbH, VDI Versicherungsdienst GmbH, VDI Technologiezentrum GmbH Seite 4

5 Die Ausgangssituation 1998 und 1999: Erstellung Forms- und Reports-Applikationen durch OPITZ CONSULTING MGL-CS (Mitgliederverwaltung) REC-CS (Rechnungsfakturierung) 2005: Erstellung einer CRM-Lösung zur Geschäftspartnerverwaltung durch OPITZ CONSULTING auf Java-Basis Starke Integration der 3 Anwendungen war/ist notwendig Seite 5

6 Integration der vorhandenen Systeme Geschäftsvorfälle Artikel-, Artikel-, Rechnungs- Rechnungs-und und Lieferempfänger Lieferempfänger Fakturierung Fakturierung Forms 6i (REC-CS) Rechnungsfakturierung Namen, Adressen Namen Namen Adressen Adressen Beziehungen Beziehungen Merkmale Merkmale Geschäftsvorfälle Geschäftsvorfälle etc. etc. Java (CRM) Geschäftspartnerverwaltung Mitgliedsdaten Mitgliedsdaten Zahldaten Zahldaten Anschreiben Anschreiben Ehrungen Ehrungen etc. etc. Forms 6i (MGL-CS) Mitgliederverwaltung relevante Mitgliedsdaten Seite 6

7 2 Gründe für eine Migration weg von Oracle Forms Seite 7

8 Gründe für eine Migration weg von Oracle Forms Weiterentwicklung findet nur noch im Bereich Integrationsmöglichkeiten statt (z. B. Nutzung von WebServices, JavaScript-Integration ab Release 11g) GUI-Elemente haben sich in den letzten Jahren kaum geändert Keine moderne Tabellendarstellung Forms-Fenster sind starr Standardmäßige Forms-Oberflächen wirken oft antiquiert Forms ist nicht objektorientiert Themen wie Testautomation und kontinuierliche Integration sind nur schwer realisierbar Seite 8

9 Gründe für eine Migration weg von Oracle Forms Keine Wahlfreiheit bzgl. der Architektur Zwang zur 3-Schicht-Architektur Umstieg von C/S auf 3-Schicht-Architektur technologisch meistens unproblematisch Oracle Application Server ist notwendig und erzeugt Kosten Lizenzen Hardware Administration Seite 9

10 3 Entscheidungskriterien des VDI für eine Migration Seite 10

11 Entscheidungskriterien des VDI für eine Migration Auslöser: Ende des Supports für die Client/Server-Architektur von Oracle Forms (01/2008) Feststellung: Keine funktionalen Änderungen bei MGL-CS und REC-CS notwendig! Es wurden zwei Varianten durch eine Nutzwertanalyse gegenübergestellt: 1. Migration auf die aktuelle 3-Schichten-Architektur von Oracle Forms 2. Migration nach Java (Swing, C/S) Ergebnis: Java-Migration ist deutlich teurer bzgl. des Realisierungsaufwands Aber: Gesamtkostenbetrachtung (inkl. Beschaffungs- und Betriebskosten für Test-, Produktionsumgebung über 4 Jahre) fiel dennoch zugunsten der Java-Migration aus Seite 11

12 Entscheidungskriterien des VDI für eine Migration Weitere weiche Faktoren pro Java Zukunftssicherheit Höhere Ergonomie in Java möglich Einheitliches Systemverhalten aller Anwendungen analog zu VDI-CRM Vorteil Der VDI betreibt selber keine Forms-Softwareentwicklung im Haus Keine (Um-)Schulung von eigenen Forms-Entwicklern notwendig Die Praxis zeigt: Umstieg von Forms nach Java aufgrund der sehr unterschiedlichen Paradigmen nur schwer möglich Seite 12

13 4 Unterschiede im Systemverhalten Forms vs. Java Seite 13

14 Suche Suchfunktionalität in Forms äußerst mächtig Unterschiede im Systemverhalten Forms vs. Java Über den Query-by-Example Modus können in allen Feldern Bedingungen und Operatoren eingegeben werden Seite 14

15 Unterschiede im Systemverhalten Forms vs. Java Suche Nachteile: Fragwürdig bzgl. der Ergonomie Nicht intuitiv (man muss dieses Feature kennen) Die eingegebenen Kriterien werden nach Ausführung der Suche nicht mehr angezeigt Seite 15

16 Unterschiede im Systemverhalten Forms vs. Java Demonstration Seite 16

17 Validierung Forms Unterschiede im Systemverhalten Forms vs. Java Meist häufige Verwendung von WHEN-VALIDATE-ITEM Triggern Starke Einschränkung, da ein Verlassen des Feldes erst nach Eingabe eines gültigen Wertes möglich ist Häufige Verwendung von WHEN-VALIDATE-RECORD Triggern Java Satz-für-Satz-Validierung Starke Einschränkung, da ein anderer Datensatz erst dann bearbeitet werden kann, wenn der aktuelle Datensatz gültig ist Grundsätzlich steht es dem Entwickler frei, wann eine Validierung durchgeführt werden soll Eventuell bestehen aber Einschränkungen/Vorgaben aufgrund der eingesetzten Java-Frameworks Im VDI-Fall: Erst beim Speichern werden alle geänderten Objekte validiert und in der Datenbank gespeichert Seite 17

18 Unterschiede im Systemverhalten Forms vs. Java Demonstration Seite 18

19 Ergonomische Vorteile in Java-Swing Sortierung in Tabellen einfach zu implementieren Ändern Spaltenreihenfolge und -breite in Tabellen Swing bietet Drag and Drop -Funktionalität Unterschiede im Systemverhalten Forms vs. Java Swing verfügt über einen größeren Satz an fertigen GUI-Komponenten, welche einfach genutzt werden können JSplitPane JSlider JSpinner + - Seite 19

20 5 Die verwendete Technik Seite 20

21 Architektur der Java-Applikation Server Client OC-Swing-Framework DAO DAO Objektmodell Objektmodell Binding Binding GUI GUI Oracle DB-Server JDBC Persistenz/ Persistenz/ DML DML Fachlogik Fachlogik Event- Event- Handling Handling Oberfläche Oberfläche Seite 21

22 Die Herausforderungen Forms2Java die speziellen Herausforderungen Migration der Fachlogik von Forms nach Java Migration der bestehenden Oracle Reports Migration von umfangreicheren Forms-Anwendungen Seite 22

23 Migration der Fachlogik eine besondere Herausforderung Vorteil beim VDI: Relativ viel Logik liegt in Datenbank-Triggern und -Packages Ein großer Teil der Fachlogik ist dennoch in den Forms- und Reports-Modulen implementiert Herausforderung Trennung der Forms spezifischen Logik von der eigentlich zu migrierenden Fachlogik Pragmatischer Lösungsansatz Erfahrene Forms-Entwickler extrahieren die relevanten Fachlogiken in PL/SQL Je nach Komplexität der PL/SQL Blöcke können diese z. B in Java reimplementiert werden... in Datenbank-Packages ausgelagert werden Voraussetzung: Java-Entwickler müssen PL/SQL Know-how mitbringen Seite 23

24 Spezialthema: Migration der Oracle Reports Oracle Reports beinhalten ggf. komplexe Layouts und aufwendige Logik Empfehlenswert: JasperReports Freies Reporting-Werkzeug für Java Report-Vorlagen werden in Form von XML beschrieben Mit ireport steht ein leistungsfähiger WYSIWYG-Editor zur Verfügung Befüllen des Reports mit Daten kann stattfinden Via SQL-Datenanfragen Via Java-Objektmodell Fachlogik kann analog zu Forms behandelt werden Für Swing bietet Jasper einen fertige Viewer-Komponente Es werden viele Standardformate für die Ausgabe unterstützt PDF, RTF, HTML, XLS, etc. Aber: Nicht alle Features von Oracle Reports existieren in Jasper Gewisse Layout-Anforderungen sind teilweise nicht realisierbar Schachtsteuerung nur auf Umwegen machbar Seite 24

25 Was tun bei größeren Forms-Projekten? Größere Forms-Projekte beinhalten oft eine Vielzahl einfacher Stammdatenmasken zur Datenpflege (CRUD-Operationen) Auf Basis der vorgestellten Java-Architektur ist relativ viel Handarbeit für eine CRUD-Maske notwendig DAO-Klasse mit allen Spalten der Tabelle Objektmodell-Klasse(n) inkl. diverser Service-Klassen Swing-Maske(n) Binding der einzelnen GUI-Komponenten an die Objektmodell-Klassen Lösungsidee im VDI-Fall (MGL): Erzeugung aller notwendigen Klassen über einen Generator Wichtige Voraussetzungen Der generierte Java-Code darf nicht mehr von Hand geändert werden Eventuell notwendige Fachlogik muss in der Datenbank implementiert werden Abstriche hinsichtlich GUI-Ergonomie sind akzeptabel Seite 25

26 Prinzip der Generator-Idee Was tun bei größeren Forms-Projekten? Vor Beginn: Die Struktur des zu erzeugenden Java-Codes muss eindeutig klar sein! Aus dem von Hand erstellten Java-Code werden Generator-Templates entwickelt (einmaliger Aufwand!) Bei der MGL-Migration wurde als Template-Engine eingesetzt: Inhalte der Platzhalter in den Templates werden über ein eigenes XML- Format vorgegeben (z. B. Tabelle, Attribute, Datentypen, etc.) XML-File muss als Input von Hand erstellt werden! Die Inhalte der XML-Elemente werden von einem Java-Parser gelesen und Velocity zur Code-Generierung übergeben. Ggf. fehlende Informationen werden aus dem DataDictionary der Datenbank bezogen. Seite 26

27 Unterschiede im Systemverhalten Forms vs. Java Demonstration Seite 27

28 Fazit Seite 28

29 Fazit Forms2Forms- vs. Forms2Java-Migration = Migration vs. Re-Implementierung Java Re-Implementierung dauert deutlich länger als eine Forms-Migration Java-Migrationen führen zu Änderungen im Systemverhalten Empfehlung: Frühzeitig via Prototyping ein ggf. anderes Verhalten mit allen Beteiligten evaluieren/testen Herausforderungen bzgl. der Vorgehensweise Aufwand für Java-Implementierung nur schwer einzuschätzen Je mehr Logik bereits in der Datenbank steckt, desto besser! Relativ hoher Aufwand für Generator- und Template-Entwicklung, der sich allerdings bei einer größeren Anzahl von CRUD-Masken wirklich lohnt! Seite 29

30 Fazit Rückblick: Die Migration auf die Java-Plattform war im VDI-Fall die langfristig bessere Entscheidung Softwaretechnische und ergonomische Aufwertung der Anwendungen Günstige Bedingungen im VDI-Fall Forms-Anwendungen wurden seit mehreren Jahren durch OC betreut Die neue Java-Architektur ist durch das CRM-System beim VDI bereits erprobt gewesen Die migrierten Java-Applikationen wurden jeweils im Big-Bang-Verfahren abgelöst. Partielle oder Teilmigrationen wären deutlich komplexer gewesen. Seite 30

31 & Fragen & Antworten Seite 31

32 Kontakt: Alexander Orbach OPITZ CONSULTING Gummersbach GmbH Vielen Dank für Ihre Aufmerksamkeit! Seite 32