Oracle Forms LOVs durch modernes Type-ahead ersetzen: Ein Muster-Leitfaden

Das meistgenutzte Widget in Unternehmenssoftware#

Eine Regionalbank, mit der wir letztes Jahr zusammengearbeitet haben, hat LOV-Aufrufe über ihren gesamten Oracle Forms Bestand eine Woche lang gezählt. Die Zahl lag bei 11,4 Millionen. Über 238 Bildschirme und 1.700 tägliche Benutzer wurde das LOV ungefähr alle zwei Sekunden geöffnet. Kein anderes Steuerelement kam auch nur annähernd heran.

Diese Häufigkeit ist relevant. Wenn LOVs bei der Migration an Qualität verlieren, merken die Benutzer es innerhalb einer Stunde. Wenn sie sich verbessern, zeigt sich der Produktivitätsgewinn am ersten Tag des Parallelbetriebs.

Was ein Oracle Forms LOV tatsächlich tut#

Ein LOV ist ein modaler Picker, der auf einer Datensatzgruppe basiert. Die Datensatzgruppe ist meist eine SELECT-Anweisung, manchmal eine statische Liste, gelegentlich ein programmatischer Cursor. Es unterstützt Auto-Reduktion (Zeichen tippen zum Filtern), Spaltenzuordnung (ausgewählte Zeile befüllt mehrere Felder) und Validierung (Werte, die nicht in der Liste stehen, können abgelehnt werden).

Die typische .fmb-Datei enthält 18 LOVs. Etwa 60 % sind einspaltige Nachschlagewerte. Die verbleibenden 40 % leisten Anspruchsvolleres: kaskadierende Parameter, abhängige Filter oder mehrspaltige Befüllung.

-- Eine repräsentative LOV-Datensatzgruppe
SELECT customer_id, customer_name, credit_limit, region_code
FROM   customers
WHERE  status = 'A'
  AND  region_code = :ORDERS.REGION
ORDER  BY customer_name;

Diese :ORDERS.REGION-Bind-Variable ist der Grund, warum naive Migrationen scheitern. Das LOV ist nicht unabhängig — es ist auf den aktuellen Formularstatus parametrisiert.

Das moderne Äquivalent ist kein Dropdown#

Ein natives HTML-<select> deckt vielleicht 10 % der LOV-Fälle ab. Alles andere benötigt eine Type-ahead-Komponente mit serverseitiger Filterung, entprellten Abfragen, Tastaturnavigation und der Fähigkeit, mehrere gebundene Felder aus einer Auswahl zu befüllen. Wir haben uns für eine einzelne React-Komponente entschieden, die einen OpenAPI-beschriebenen Such-Endpoint und eine Spaltenzuordnung akzeptiert.

Die Endpoint-Signatur, die wir für jedes LOV generieren, sieht so aus:

GET /api/lov/customers?q=acm&region=EU&limit=25

// Antwort
{
  items: [
    { customer_id: 4821, customer_name: "Acme Industrial",
      credit_limit: 250000, region_code: "EU" }
  ],
  total: 1
}

Jedes LOV in der Quell-.fmb wird zu einem Endpoint plus einer Komponenteninstanz. Das SQL der Datensatzgruppe wird zum Abfragekörper. Die Bind-Variablen werden zu Query-Parametern, die mit dem Formularstatus verbunden sind.

Auto-Reduktion, Entprellung und die 150-ms-Regel#

Forms LOVs fühlen sich sofort an, weil sie gegen einen lokalen Cursor laufen. Netzwerk-Roundtrips nicht. Um das ursprüngliche Bediengefühl zu erreichen, muss das Type-ahead Ergebnisse in unter 150 ms für den p95-Fall liefern. Wir erreichen diese Zahl, indem wir indizierte Such-Endpoints direkt aus dem LOV-SQL generieren, die erste Seite pro Benutzersitzung zwischenspeichern und die Eingabe bei 80 ms entprellen.

Über 14 Deployments haben wir LOV-Antwortzeiten zwischen 38 ms und 110 ms im Median gemessen. Die Benutzer berichten, dass sich die neuen Picker schneller anfühlen als die Originale — nicht weil das Netzwerk schneller ist, sondern weil die Tastaturbehandlung besser ist.

Kaskadierende LOVs und Formularstatus#

Das schwierigste Muster ist die Kaskade: Die Auswahl eines Kunden filtert das Lieferadressen-LOV, das das Kontakt-LOV filtert, das wiederum das Produkt-LOV filtert. In Forms sind diese Beziehungen implizit — Bind-Variablen lesen aktuelle Feldwerte zum Öffnungszeitpunkt. In einem modernen Stack müssen die Beziehungen explizit sein.

Wir kodieren sie im JSON-Deskriptor als dependsOn-Array. Die Komponente ruft bei jeder Abhängigkeitsänderung erneut ab und löscht nachgelagerte Auswahlen. Der Generator erzeugt die Verdrahtung automatisch aus der ursprünglichen Bind-Variablen-Analyse.

Validierungsparität#

Forms LOVs können strikt (Wert muss in der Liste existieren) oder beratend (Wert wird vorgeschlagen, Freitext ist aber erlaubt) sein. Etwa 70 % der LOVs, die wir migriert haben, sind strikt. Die Type-ahead-Komponente erzwingt dies mit einer abschließenden serverseitigen Prüfung beim Absenden — nicht nur clientseitig — weil das ursprüngliche Forms-Verhalten gegen Live-Daten validierte, nicht gegen eine zwischengespeicherte Liste.

Die Erkenntnis#

LOVs sind keine Dropdowns. Sie sind parametrisierte, kaskadierende, mehrspaltige Picker, die 30 Jahre Enterprise-UX angetrieben haben. Sie gut zu ersetzen erfordert eine Komponente, die den Formularstatus versteht, einen Endpoint, der aus dem Original-SQL generiert wurde, und Latenzbudgets, die in Millisekunden gemessen werden. Richtig umgesetzt, macht die Migration das meistgenutzte Widget der Anwendung schneller als zuvor.