Migration Assistent Forms nach APEX

Transkript

1 Migration Assistent Forms nach APEX Dr. Gudrun Pabst Trivadis GmbH München Schlüsselworte: Forms, APEX, Migration Einleitung Vielfach wird die Frage gestellt, welche Alternativen es zu Forms gibt. Mit der Version 3.2 von APEX stellt Oracle einen Assistenten zur Verfügung, um Forms-Anwendungen nach APEX zu migrieren. Im folgenden wird beschrieben, welcher Anteil einer Forms-Anwendung migriert wird, wo Nacharbeit erforderlich ist und in welchen Fällen der Einsatz sinnvoll ist. Aufsetzen der Umgebung Bei der Migration werden die Module der Forms-Anwendung als XML-Dateien bzw. Textdateien in das APEX-Repository geladen und gegenüber dem Datenbank-Schema ausgewertet. Daher sind zuerst ein paar Vorarbeiten nötig: Die Object Libraries, Menus, Reports und Forms-Module der Forms-Anwendung müssen in XML konvertiert werden, die Library-Module müssen als Textdateien gespeichert werden. In APEX muss ein Workspace angelegt werden, der auf dem Schema der Forms- Anwendung basiert. Sind diese Vorarbeiten durchgeführt, kann mit der Migration begonnen werden. Nach dem Anmelden am Workspace findet man auf der rechten Seite in der Link-Liste den Link Application Migrations : 1

2 Dieser Link führt auf die Seite der Migrationsprojekte. Hier muss mit Create Project ein Migrationsprojekt angelegt werden: Um ein Migrationsprojekt anzulegen, muss man den Namen und den Typ des Projekts (Forms oder Access) festlegen. Dabei wird auch bereits das erste Forms-Modul hochgeladen. Im nächsten Schritt oder nach Abschluss des Wizard können weitere Dateien hochgeladen werden. Nachdem sämtliche Dateien der Formsanwendung in das APEX-Repository geladen sind, zeigt die Liste der Migrationsprojekte eine Übersicht über die Komponenten der Forms- Anwendung: 2

3 Unter der Überschrift Application ist noch kein Eintrag vorhanden; hier wird später der Name der Applikation erscheinen, die aus diesem Migrationsprojekt erstellt wurde. Überprüfung der globalen Einstellungen Ein Klick auf den Projektnamen führt auf eine Seite, die eine detailliertere Übersicht über die Komponenten der einzelnen Module liefert: Die Einträge in der Liste ergeben sich wie folgt: Blocks ist die Anzahl der Blöcke im Forms-Modul. DB Blocks ist die Anzahl der Blöcke im Forms-Modul, deren Property Database Block auf Yes steht. Dies muss also nicht wirklich die Anzahl der Datenbank- Blöcke wiedergeben. Items, Triggers, Record Groups, List of Values, Alerts und Program Units ist die Anzahl der entsprechenden Objekte im Forms-Modul. Component Count gibt die Anzahl der Komponenten im hochgeladenen Forms-Modul an. Completed Components wird ermittelt als die Anzahl der Komponenten, für die entweder das Complete -Kennzeichen auf Yes gesetzt ist oder das Applicable - Kennzeichen auf No. Percent Complete gibt aufgrund der Anzahl der Completed Components an, wie weit das Forms-Modul migriert ist. Damit die Prozentzahl für den Migrationsfortschritt aussagekräftig ist, müssen die Applicable -Kennzeichen korrekt gesetzt sein. Diese Kennzeichen können global gesetzt werden (dabei werden die einzelnen Kennzeichen überschrieben!) oder einzeln für jede Komponente. Da die globale Einstellung die lokale Einstellung überschreibt, ist es sinnvoll, zunächst die globale Einstellung so zu treffen, dass für die meisten Komponenten der korrekte Wert hinterlegt ist, und danach nur noch die Sonderfälle einzeln abzuändern. Zum Setzen der globalen Einstellung gibt es rechts von der Checkliste unter Tasks den Link Edit Project Details and Applicability. Der Link öffnet eine Seite, auf der die Applicable - Kennzeichen für Komponententypen und für Trigger gesetzt werden können. Für die Komponententypen sieht dies folgendermaßen aus: 3

4 Für Trigger gibt es nicht nur die Einstellung in dieser Liste, sondern es kann für jeden Trigger-Typ gezielt eingestellt werden, wie das Kennzeichen gesetzt werden soll: Leider ist die Liste nicht komplett. Es fehlt z.b. der Trigger PRE-POPUP-MENU, der mit der Einstellung Applicable=Yes übernommen wird. 4

5 Überprüfung der analysierten Objekte Sind die globalen Einstellungen korrekt gesetzt, werden die einzelnen Komponenten der Module geprüft. Ein Klick auf den Modulnamen führt zu einer Liste der Komponenten des Moduls sowie der geplanten Umsetzung in einer APEX-Anwendung: Komponenten ohne Eintrag unter Equivalent Component werden nicht automatisch umgesetzt. Hat Applicable für derartige Komponenten den Wert Yes, muss manuell für die Umsetzung gesorgt werden. Für Blocks ist eine Umsetzung als Region vorgesehen. Es sind drei Blöcke vorhanden, aber nur einer ist als Included aufgelistet. Klickt man auf den Link Blocks, können auch die anderen beiden Blöcke aufgenommen werden in die Menge der Objekte, die beim Erstellen der Applikation umgesetzt werden: Der Wert unter Title ist immer der Blockname hier sind daher im allgemeinen Anpassungen nötig! Ein Klick auf den Blocknamen führt zur Detailansicht des Blocks. Hier können die Annotations des Blocks bearbeitet werden: 5

6 Diese Annotations sind für alle Komponenten vorhanden und identisch aufgebaut. In diesem Bereich kann ein von der Vorgabe abweichendes Applicable -Kennzeichen hinterlegt werden. Für die manuellen Nacharbeiten können ein Bearbeiter, Notizen und Tags eingetragen werden. Ist die Komponente komplett migriert, wird das Complete - Kennzeichen auf Yes gesetzt. In der Detailansicht des Blocks sind außerdem die Items und die Trigger des Blocks aufgelistet. Über den Namen des Item oder Trigger gelangt man zu deren Annotations. Erstellen der Anwendung aus dem Migrationsprojekt Sind alle Einstellungen getroffen, wird mit dem Button Create Application auf der Übersichtsseite des Migrationsprojekts das Erstellen der Applikation gestartet. Der Assistent fragt zunächst nach dem Namen der Applikation. Danach wird ein Vorschlag für die Applikation erstellt: Als Seitennamen werden hier die Titel der Blöcke verwendet wurde der Blocktitel vorher nicht geändert, werden hier die Namen der Blöcke benutzt! 6

7 An dieser Stelle sind aber noch Korrekturen möglich: Durch einen Klick auf das X in der Spalte Delete Page können Seiten gelöscht werden; über den Link im Seitennamen werden die detaillierten Einstellungen der Seite angezeigt und können teilweise geändert werden: Erstellte Anwendung Wird die erstellte Anwendung gestartet, sieht sie folgendermaßen aus: Jede erstellte, aufrufbare Seite ist durch ein Icon dargestellt. Hat man die Icons nicht abgeändert, zeigt das Icon den Typ der Seite an. Umsetzung einiger häufiger Modul-Varianten: 7

8 Forms APEX Anmerkung Formular / Multi- Record-Formular auf Formular / tabellarisches Formular auf einer Für Multi-Record-Formulare werden alle Spalten der Tabelle übernommen, auch einer Tabelle Tabelle diejenigen, die im Forms-Modul Master-Detail Formular auf zwei Tabellen Master-Detail Formular auf mindestens einer DB- View Master mit 2 Details: Formular auf drei Tabellen Umsetzung einiger Item-Typen: Master-Detail Formular auf zwei Tabellen, ggf. mit zusätzlichem tabellarischem Formular für die Detail-Daten Zwei völlig von einander unabhängige Seiten Drei völlig von einander unabhängige Seiten vorhanden sind Das tabellarische Formular für die Detail- Daten muss i.a. beim Erstellen der Applikation aus der Liste der vorgeschlagenen Seiten gelöscht werden. Forms APEX Anmerkung Button im Single- Button Record-Formular Button im Multi- Der Button wird nicht übernommen. Record-Formular Check Box Check Box Text Item Textitem Text Item mit LOV, DB-Item Popliste Die LOV wird als List of Values in APEX umgesetzt und zum Füllen der Popliste verwendet. Text Item mit LOV, Text Item Die LOV wird nicht umgesetzt. kein DB-Item Popliste Popliste Wird die Popliste dynamisch gefüllt, muss der Code zum Füllen der Liste manuell als List of Values in APEX übertragen werden. Zusammenfassung Die Arbeit mit dem Migrationswizard erfordert umfangreiche Vorarbeiten: Konvertieren der Forms-Module in eine XML-Darstellung und Hochladen der einzelnen Module. Die Analyse-Funktion des Migrationsprojekts liefert dann eine sehr gute Übersicht über den Umfang der Forms-Anwendung. Mit der Checklisten-Funktion der Liste ist auch der Migrationsfortschritt gut überwachbar. 8

9 Der in den Forms-Modulen enthaltene Code muss manuell umgesetzt werden; dies bedeutet unter Umständen viel Nacharbeit. Der Zusammenhang zwischen einzelnen Seiten, die aus demselben Forms-Modul hervorgegangen sind, muss manuell hergestellt werden. Leider übernimmt der Wizard in Multi-Record-Formularen nicht nur die in den Forms- Modulen verwendeten Spalten in die neuen Seiten, sondern er fügt auch alle anderen Spalten der Tabelle hinzu. Die bisher durchgeführten Schritte konnten keineswegs so reibungslos durchgeführt werden wie hier beschrieben. Der Migrationsassistent hat noch einige Bugs und einige Probleme mit Modulen, die in der normalen Forms-Praxis durchaus üblich sind (siehe oben: Umsetzung von Master-Detail-Formularen auf Views). Forms-Anwendungen, die aus einfachen Formuleren, tabellarischen Formularen oder Master- Detail-Formularen mit nur zwei Tabellen bestehen, setzt der Migrationswizard einigermaßen gut um. Enthält eine Forms-Anwendung viel Code, sind umfangreiche Nacharbeiten zu erwarten: Code für Layout muss für den Einsatz im Web umgestaltet werden, andere Codeteile müssen entweder in APEX übernommen und angepasst werden oder in die Datenbank ausgelagert. Fazit In der aktuellen Version des Migration Assistent kann er gut verwendet werden, um eine Forms-Anwendung zu analysieren und den Arbeitsfortschritt zu dokumentieren. Das Erstellen einer Applikation aufgrund der hochgeladenen Forms-Module ist allerdings an vielen Stellen nicht wunschgemäß und daher nur mit viel Nacharbeit verwendbar. Nur die einfachsten Forms-Module können nach der Migration fast unverändert verwendet werden; bereits für die etwas komplexeren Module empfiehlt sich, die APEX-Seiten selbst zu erstellen. Kontaktadresse: Name Dr. Gudrun Pabst Trivadis GmbH Lehrer-Wirth-Straße 4 D München Telefon: +49(0) Fax: +49(0) gudrun.pabst@trivadis.com Internet: 9