Von Oracle Forms nach ADF

In 10 einfachen Schritten von Forms nach ADF migrieren
mehr erfahren

Erfolgreich mit Oracle ADF

Die Entscheidung zum Umstieg auf Oracle ADF stellt einen wichtigen Schritt zu einer moderneren, zukunftssicheren Anwendung dar. Die Möglichkeiten von ADF überzeugen auf ganzer Linie und lassen viele bekannte Entwicklungsumgebungen weit hinter sich.

Mit PITSS kommen Sie bei Ihrer Migration schneller und effektiver ans Ziel. Mit Hilfe unseres Tools PITSS.CON, minimieren wir nicht nur erheblich die typischen Risiken einer Migration. Mit seinem einzigartigen Repository-Ansatz ermöglicht es Ihnen, von der vollständigen Projekt-Abdeckung aus einer Hand zu profitieren.

Denn PITSS.CON – das ist Forschung, Jahre an Erfahrung, innovative und praktische Lösungen aus zahlreichen und vielfältigen Migrationsprojekten, vereint in einem einfach zu nutzenden Produkt mit genialer Methodik. Mithilfe der ausgeklügelten Automatismen von PITSS.CON wird die Migration von Forms nach ADF in nur 10 Schritten möglich:

Ihre Vorteile einer Migration mit PITSS.CON:

Prozessoptimierung

Bestehende Prozesse werden optimiert und migriert

Risikominimierung

Automatisierte Überführung der Business Logik nach DB
Z

Best Practices

Bewährte ADF Best Practices durch SEME

Inkrementell

Stufenweise Migration der Forms Anwendung nach ADF

Oracle Forms to ADF – made easy!

So einfach ist die Migration von Forms nach ADF mit PITSS und PITSS.CON!

Oracle Forms to ADF

Mit diesen 10 Schritten gelingt die Migration garantiert

Tag 1: FORMS APPLIKATION PARSEN UND SICHTEN – PROOF OF CONCEPT

Mithilfe von PITSS.CON parsen wir die Applikation, um sie zu sichten und einen Proof of Concept durchzuführen. Dafür wird eine Teilmenge von FMBs ausgewählt. Alle relevanten Objekte (Forms-Module, Object Libraries, Datenbankobjekte, PL/SQL Libraries) werden in das PITSS.CON Repository geladen. PITSS.CON stellt die Vollständigkeit aller Abhängigkeiten sicher und generiert aus deren Elementen einen Abhängigkeitsgraphen. Aus diesem Graphen wird ein ausgewählter Use Case, bestehend aus zwei oder drei Modulen, entnommen.

Ergebnis des Tages: Bis zu drei Module werden nach ADF migriert.

pitss-con-flowchart

Tag 2: DEAD CODE MIT PITSS.CON ANALYSIEREN UND ANWENDUNG BEREINIGEN

Zur Vorbereitung der Forms-Applikation wird der Dead Code mit PITSS.CON analysiert, um ungenutzte Codefragmente und Objekte zu entfernen. Außerdem ist das Datenbankmodell vorzubereiten, um eine ADF-freundliche Datenbankschicht sicherzustellen, die sich durch Primärschlüssel und konvertierte Boolean Parameter auszeichnet und so zustandslos wie möglich ist.

Ergebnis des Tages: Eine noch funktionierende, aber “ready for ADF” Forms-Applikation.

 

Tag 3: FORMS TO ADF USE CASE-ANALYSE MIT PITSS.CON

Es wird eine Use Case-Analyse mit PITSS.CON durchgeführt, um den Business-Case festzuhalten und den ursprünglichen Geschäftsprozess zu verstehen.

PITSS.CON versieht die ursprüngliche Forms-Applikation mit Tracker-Information und der Hauptnutzer zeichnet die verschiedenen Business-Prozesse auf, die durch die ausgesuchten Forms-Module erfasst werden. Mit den Ergebnissen kann automatisch ein Prozessablaufgraph generiert werden. Während des Projektes sind ausschließlich die berührten Objekte von Interesse. Diese Art der Dokumentation wird in der Feintuning-Phase genutzt.

Ergebnis des Tages: Vervollständigen der Prozessdokumentation mit Fokus auf alle relevanten Forms-Objekte.

Tag 4: ANALYSE UND ENTSCHEIDUNG ÜBER BUSINESS LOGIK MIGRATION

Mock-ups für das User-Interface werden modifiziert und neue Funktionalitäten oder Komponenten abgeklärt. Normalerweise finden einige Layout- und Prozessmodifikationen während der Modernisierung nach ADF statt. Alle Anforderungen, Mock-ups, Abläufe und Beschreibungen zu erfüllen, trägt dazu bei, ein gemeinsames Verständnis des Verhaltens der Zielapplikation zu entwickeln.

PITSS.CON ist in der Lage, Balsamiq-Mock-ups aus der geparsten Applikation zu generieren. Das ist ein sehr nützlicher und zeitsparender Ansatzpunkt. Durch das Abklären dieser Punkte ist es unserem Consulting möglich, die ursprüngliche Applikationsphilosophie besser zu durchdringen

Ergebnis des Tages: Eine vollständige Aufstellung und Visualisierung aller Anforderungen.

Tag 5: BUSINESS LOGIK MIGRATION

Die Business-Logik wird in die Datenbank migriert. Um getätigte Investitionen zu sichern, die existierende Qualität aufrechtzuerhalten und die PL/SQL-Performance zu optimieren, leistet PITSS.CON Unterstützung, indem es die Business-Logik aus der Forms-Applikation extrahiert und in die Datenbank überträgt.

PITSS.CON stellt Assistenten zur Verfügung, um sich auf relevante Objekte zu fokussieren, eine Namenskonvention zu erhalten, Verweise auf Forms-Objekte durch Variablen zu ersetzen und um Calls automatisch den neuen Database-Prozeduren anzupassen.

Ergebnis des Tages: Eine noch laufende Forms-Applikation, bei der alle relevanten Objekte in die Datenbank verschoben wurden.

Tag 6: ADF-APPLIKATION IN SEME (ARCHITEKTUR) EINBETTEN

Als Nächstes wird die Zielarchitektur designt und angepasst. Um einen sehr schnellen und nachhaltigen Start in die ADF-Welt zu ermöglichen, verwendet PITSS.CON SEME (Software Environment Mentor). SEME bietet neben erweiterten Oracle-Templates und zahlreichen Gestaltungselementen, die Möglichkeiten anwendungsübergreifend Coding-Konventionen zu verankern. Funktionen und Standards werden gesetzt, die von der Architektur über Security, Error-Handling, Logging, Tracing usw. bis hin zur Versionierung der zukünftigen Anwendung reichen. SEME läßt sich innerhalb des Migrationsassistenten definieren und konfigurieren.

Ergebnis des Tages: Eine klare Vorstellung von der Zielarchitektur.

Tag 7: ADF-ARTEFAKTE GENERIEREN

Alle ADF-Komponenten werden generiert. Dank dieser nützlichen Vorbereitungsaufgaben kann PITSS.CON alle ADF-Artefakte einfach generieren. Am Ende bleibt kein PITSS-eigener Code in der ADF-Applikation und selbst Oracle definiert das Ergebnis als handgemacht.

Ergebnis des Tages: Release 0.8 Ihrer Applikation – vollständig in ADF.

Tag 8: PL/SQL-TESTS, JUNIT-TESTS, SELENIUM/JMETER-TESTS EINSTELLEN

Bevor wir anfangen die Änderungswünsche zu implementieren und alle ADF-Komponenten anzupassen, empfehlen wir die Einrichtung einer vollständigen Testumgebung für Datenbanken (PL/SQL-Unit Test), ADF (JUnitTest) und die Web-Frontend (JMeter).

Einige dieser Testfälle können mit PITSS.CON durch die bisher aufgezeichneten User Stories beschleunigt werden.

Ergebnis des Tages: Eine mit Tests abgesicherte Entwicklungsumgebung, um eine stressfreie Feinabstimmungsphase zu beginnen.

Tag 9: FINETUNING VON ADF-ARTEFAKTEN, VERBESSERN DES LOOK AND FEEL DER UI

Es geht los mit dem Feintuning und der Erweiterung der generierten ADF-Applikation. Um alle nötigen Objekte einzustellen, kommt der JDeveloper zum Einsatz. PITSS stellt zusammen mit dem JDeveloper-Plugin eine Aufgabenliste und “Knowledge Transfer Support” zur Verfügung, um es den Forms-Entwicklern einfacher zu machen, die Aufgaben zu verstehen und die dazugehörigen ADF-Objekte zu finden.

Ergebnis des Tages: Eine verbesserte Version 0.9 Ihrer Ziel-ADF-Applikation.

Tag 10: SICHERSTELLEN DER PARALLELEN FUNKTION VON ADF- UND FORMSANWENDUNG

Es werden die Zusammenfassung der ADF-Implementierung und das Zusammenführen von ADF und Forms durchgeführt. Bei dem Abschluss der Implementierungsschritte ist es hilfreich, Forms und ADF miteinander interagieren zu lassen um die Akzeptanz unter den Nutzern zu fördern. Dies wird erreicht, indem Forms aus ADF heraus aufgerufen wird oder umgekehrt. Welche Integrationsform für den Anwendungsfall zum Tragen kommt, wurde bereits bei der Festlegung der Forms-Module besprochen. Das Design-Muster ermöglicht einen stressfreien, stufenweisen Ansatz während des Modernisierungslebenszyklus.

Ergebnis des Tages: Die fertige Version 1.0 Ihrer ADF Ziel-Applikation.

Kontaktieren Sie uns jetzt und legen Sie den Grundstein für Ihre digitale Transformation!