Ein binärer Blob mit 30 Jahren Geschäftsregeln darin
Ein europäisches Logistikunternehmen übergab uns letztes Jahr 612 .fmb-Dateien. Gesamtgröße: 184 MB. In diesen Dateien steckten 28.400 Trigger, 9.100 LOVs und rund 1,2 Millionen Zeilen eingebettetes PL/SQL — nichts davon als Text gespeichert, alles serialisiert in einem Format, das Oracle nie formell veröffentlicht hat. Das Unternehmen hatte die Versionskontrollhistorie 2011 verloren. Die .fmb-Dateien waren die Wahrheitsquelle.
Dieses Szenario ist die Norm, nicht die Ausnahme. Wir haben inzwischen 2.400 .fmb-Dateien über Migrationsprojekte hinweg geparst, und die Inhalte sind bemerkenswert konsistent.
Was eine .fmb-Datei tatsächlich ist
Eine .fmb ist eine proprietäre binäre Serialisierung eines Oracle Forms-Moduls. Sie ist kein Datenbankdump und kein einfacher AST. Sie ist ein Baum von Objekten — Blöcke, Items, Trigger, Canvases, Fenster, LOVs, Record Groups, Programmeinheiten — jeweils mit einem Typcode und einer Nutzlast variabler Länge versehen. Das Format hat sich subtil über Forms 4.5, 6i, 10g, 11g und 12c verändert, aber die Kernstruktur ist stabil.
Die Begleitdateien erzählen eine ähnliche Geschichte. Eine .fmx ist die kompilierte Laufzeit-Binärdatei. Eine .fmt ist ein Text-Export, den Oracle bereitstellt, der aber verlustbehaftet ist — Layout-Koordinaten, Schriftart-Metadaten und einige Property-Defaults werden weggelassen oder umgeschrieben. Migrationen, die sich nur auf .fmt verlassen, verpassen zwischen 4 % und 9 % des ursprünglichen Verhaltens.
Der Objektbaum in Zahlen
Über unsere Stichprobe hinweg enthält eine durchschnittliche .fmb:
- 14 Datenblöcke
- 96 Items
- 47 Trigger
- 18 LOVs und Record Groups
- 6 Canvases
- 2.100 Zeilen eingebettetes PL/SQL
Die Verteilung ist stark verzerrt. Die oberen 10 % der Dateien enthalten mehr als die Hälfte der gesamten Logik. Wir haben einzelne .fmb-Dateien mit 480 Triggern und 14.000 Zeilen PL/SQL gesehen — in der Regel die Hauptbuch-Buchungsmaske oder die Auftragserfassungs-Kernmaske.
Wo die Geschäftslogik tatsächlich steckt
Forms-Entwickler hatten vier Stellen, um Code zu platzieren: Formular-Level-Trigger, Block-Level-Trigger, Item-Level-Trigger und dem Modul zugeordnete Programmeinheiten. In der Praxis landet die meiste Logik auf Item-Ebene, in WHEN-VALIDATE-ITEM, POST-QUERY und KEY-NEXT-ITEM.
-- Typische WHEN-VALIDATE-ITEM-Nutzlast in einer .fmb
IF :ORDERS.TOTAL_AMOUNT > 50000 AND :ORDERS.APPROVAL_ID IS NULL THEN
MESSAGE('Orders over 50000 require approval');
RAISE FORM_TRIGGER_FAILURE;
END IF;
Dieses Snippet ist in der Binärdatei als längenpräfixierte Zeichenkette gespeichert, die an einem Item-Knoten hängt. Um es zu finden, muss man den Objektbaum durchlaufen. Multiplizieren Sie mit 47 Triggern pro Datei und 612 Dateien, und die Extraktion wird zu einem Parser-Problem, nicht zu einem Grep-Problem.
Die Properties, die niemand dokumentiert
Über den Code hinaus trägt jedes Item zwischen 80 und 140 Properties: Standardwerte, Formatmasken, Abfragebedingungen, Navigationshinweise, Datenbank-Spaltenbindungen und Layout-Koordinaten. Rund 30 % dieser Properties kodieren Verhalten, von dem Entwickler annahmen, es sei „einfach so, wie Forms funktioniert” — kaskadierende LOVs, ausgelöst durch Formatmasken-Vererbung, zum Beispiel, oder implizites Commit-Verhalten, das an die Database-Block-Property gebunden ist.
Wenn wir eine Maske in TypeScript neu aufbauen, verursachen diese impliziten Properties die meisten Überraschungen. Der sichtbare Trigger-Code ist der einfache Teil.
Parsen ohne Oracles Laufzeit
Die meisten Migrationstools rufen Forms Builder oder die Forms API auf, um .fmb-Dateien zu lesen. Dieser Ansatz funktioniert, erfordert aber eine lizenzierte Oracle-Installation und begrenzt den Extraktionsdurchsatz auf etwa 40 Dateien pro Stunde. Wir haben einen direkten Binär-Parser gebaut, der den Objektbaum ohne die Laufzeit liest. Er verarbeitet dieselben 612 Dateien in unter 90 Sekunden und produziert einen JSON-Deskriptor für jedes Modul.
Der Deskriptor wird zum Input für alles Nachgelagerte: den TypeScript-Generator, das Kontrollinventar für das Audit und das visuelle Diff-Tool, das alte und neue Masken nebeneinander vergleicht.
Die Erkenntnis
Eine .fmb-Datei ist keine Black Box. Sie ist ein wohlstrukturierter Baum, eingewickelt in einen undokumentierten binären Umschlag. Sobald der Umschlag geöffnet ist, werden 30 Jahre Geschäftsregeln durchsuchbar, diff-fähig und migrierbar — in genau dieser Reihenfolge. Jede Migration, die wir termingerecht geliefert haben, begann mit einem vollständigen Parse der Quelldateien, weil jede Abkürzung in dieser Phase sechs Monate später als Defekt auftaucht.