#filemaker

Claris FileMaker Pro

Jessie Maple, a bacteriologist who took up filmmaking in the 1970s, became the first Black woman to join the camera operators union in New York and went on to direct trailblazing independent films. Maple turned first to journalism and then to film, working as a camera operator and a documentarian before releasing her first feature, “Will” (1981), a family drama that she made for less than $12,000. Jessie Maple passed away at her home on 30 May 2023, in Atlanta. She was 86.

(Franziska Nyffenegger)

'; return; } fetch(`${API}?q=${encodeURIComponent(q)}&limit=100&token=${TOKEN}`) .then(r => r.json()) .then(d => render(d)); } ``` Zwei Details: **Debouncing mit 200 ms.** Tippt der User „mueller", wird nicht für jeden Buchstaben ein Request abgesetzt. Erst wenn 200 ms keine neue Eingabe kommt, geht der Fetch los. Das schont den Server und ist auf modernen Maschinen subjektiv noch immer „sofort". **Race-Condition-Schutz mit `lastReq`-ID.** Wenn der User schnell tippt und der erste Request langsamer zurückkommt als der zweite, würde die Liste sonst kurz die alte Antwort zeigen. Über einen lokalen Zähler werden veraltete Antworten verworfen. ## Die CORS-Falle Beim ersten Test im WebViewer: nichts. „Load failed". Ein typisches Browser-Mysterium, das eine Stunde Diagnose verschlingt, wenn man's nicht kennt. Erklärung: Der WebViewer lädt seine HTML-Seite per `data:`-URL. Aus Browser-Sicht hat eine `data:`-URL als Origin den Wert `null`. Macht der eingebettete JavaScript-Code dann einen `fetch()` an einen HTTP-Server, prüft der Browser CORS (Cross-Origin Resource Sharing). Liefert der Server keine `Access-Control-Allow-Origin: *`-Header, wird die Antwort blockiert — der `fetch()` erhält einen generischen „Load failed"-Fehler ohne nähere Erklärung. Fix: zwei Zeilen im `json_response()`-Helper: ```php header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); ``` Sofort lief alles. Eine dieser Sachen, die man einmal gelernt hat und nie wieder vergisst, aber bis dahin Stunden kosten kann. ## Performance — die echten Zahlen Über 96 935 Mails, gemessen direkt am Server, dann inklusive HTTP-Roundtrip aus dem WebViewer: | Such-Typ | SQL-Zeit | HTTP-Roundtrip | |---|---:|---:| | Volltext „mueller*" | 4 ms | 59 ms | | Volltext „heiratsurkunde" | 4 ms | 55 ms | | Volltext + Filter (z_eingang=1) | 5 ms | 34 ms | | Phrasen-Suche „aicher.com" | 4 ms | 42 ms | Der HTTP-Roundtrip ist dabei der Löwenanteil. Die eigentliche FTS5-Query liegt **unter 10 ms** — auch bei Millionen Datensätzen würde sich daran wenig ändern. Vergleich mit dem alten Pattern: | | Liste-basierter WebViewer | FTS5-Backend | |---|---|---| | Initiales Rendering | 10–30 m | <100 ms | | Tastendruck-Reaktion | 100–500 ms (DOM-Filter) | 50–100 ms (HTTP) | | HTML-Größe initial | ~75 MB | ~1 KB pro Request | | Skalierungsgrenze | ~10 000 DS | 10 Mio+ | | Body-Volltext-Suche | begrenzt, kein Stemming | voll, mit Diacritics-Normalisierung | | Sortierung | nach Anlegen | nach Relevanz (BM25) | | Snippet-Hervorhebung | nein | ja, mit `` | | Sonderzeichen/Umlaut-Toleranz | nein | ja | ## Wartung Damit der Index nicht veraltet, muss er bei jeder neuen oder geänderten Mail aktualisiert werden: - **Mails per IMAP abholen**: das FileMaker-Skript ruft nach jedem neuen Datensatz `Mail indizieren` auf, der schickt den DS per POST an `/api/index_mail.php` - **Mails senden**: macht der PHP-Endpoint selbst nach erfolgreichem Versand - **Manuelle Änderungen** in FileMaker (Betreff editiert, Body angepasst): per Skript-Trigger OnRecordCommit → `Mail indizieren` Bei Inkonsistenzen genügt ein Reset: Python-Script neu laufen lassen, leert den Index, baut ihn neu auf. 15 Sekunden. ## Bilanz Was am Ende steht: - **Live-Volltext-Suche über 96 935 Mails** mit <100 ms Antwortzeit - **Sub-50-ms-Performance auf der DB-Ebene** — würde auch bei 10 Mio Datensätzen noch unter 100 ms bleiben - **Snippet-Hervorhebung** mit Kontext-Wörtern um den Treffer herum - **Umlaut- und Akzent-tolerant**: „muller" findet „Müller" - **Filter-Kombinationen**: Volltext + Kontakt + Richtung + Thread (über zusätzliche URL-Parameter) - **Skaliert** auf jeden Datenbestand, der realistisch in FileMaker liegt - **Wartung minimal**: PHP-Endpoint indiziert neue Mails automatisch, Python-Script setzt bei Bedarf alles zurück Das Pattern ist breit übertragbar. Überall dort, wo FileMaker mit großen Datenmengen Live-Suche bieten soll — Kontakte, Aufgaben, Dokumente, Logs — ist FTS5 in einer Helper-SQLite die richtige Antwort. Die FM-Datei selbst bleibt unangetastet, die Suche läuft daneben, der WebViewer ist die Brücke. ## Was als Nächstes käme Drei mögliche Erweiterungen, die diese Lösung von „funktional" zu „brillant" heben würden: 1. **Server-side Pagination**: aktuell 100 Treffer pro Anfrage. Bei einer „1000 Treffer für muller" könnte „Mehr laden"-Button mit `offset`-Parameter ergänzt werden. 2. **Faceted Search**: Aggregations-Endpoint, der für eine Such-Query liefert „X Treffer in Inbox, Y in Sent, Z bei Kontakt A". Bietet sofortige Verfeinerungs-Optionen. 3. **Synonyms-Wörterbuch**: für Geschäftsbegriffe Synonyme definieren („Rechnung" matcht auch „Invoice"). FTS5 unterstützt das über Custom-Tokenizer. Aber: nichts davon braucht es heute. Sub-100-ms-Volltextsuche über 96 000 Mails reicht für die nächsten Jahre. Das Pattern ist offen, falls je gebraucht. --- **Stack:** - SQLite 3.x mit FTS5 (in praktisch jeder modernen PHP-Installation enthalten) - PHP 8.x, PDO-SQLite-Treiber - FileMaker WebViewer mit `data:`-URL + JavaScript-Fetch - Python 3 für den einmaligen Initial-Index-Lauf **Code-Umfang nach Implementierung:** - `lib/helper.php`: +40 Zeilen (FTS5-Tabelle + `index_mail()`-Helper) - `api/search_mails.php`: ~100 Zeilen (komplett neu) - `api/index_mail.php`: ~40 Zeilen (komplett neu) - `/tmp/initial_index_mails.py`: ~80 Zeilen (einmalig) - FileMaker-Berechnung `wv_html_search_fts`: ~80 Zeilen JavaScript+HTML in einer FM-Calc - FileMaker-Skript `Mail indizieren`: ~12 Steps

# Wie wir ein 50-GB-Mailarchiv aus einem 12 Jahre alten FileMaker-System gerettet haben *Eine Detektivgeschichte über CSV-Exporte ohne Header, drei verschiedene Encoding-Katastrophen, IDs aus drei Tabellen die alle „Kontakt" hießen und am Ende doch nicht das Gleiche meinten — und darüber, was eine moderne KI in einer solchen Migration konkret leistet. Was ein Senior-FileMaker-Entwickler in zwei Wochen allein hingekriegt hätte, war im Tandem in drei Tagen erledigt. Inklusive funktionierendem Threading.* --- ## Der Ausgangspunkt: ein Archiv ohne Karte Bei einem Kunden lag eine FileMaker-Datenbank mit knapp **50 GB Mailarchiv** auf der Platte. Aufgebaut über zwölf Jahre, durchgewuchert mit einem Plugin namens „Dacons MailIT", erweitert mit eigenen Korrespondenz-Tabellen, irgendwann nicht mehr richtig gepflegt. Der ursprüngliche Entwickler war nicht mehr greifbar. Das produktive System lief auf einer alten FileMaker-Version, auf die niemand mehr Zugriff hatte. Das einzige, was noch verfügbar war: zwei CSV-Exporte. Diese wurden aus einer anderen Perspektive der Altdatenbank exportiert. Feldnamen völlig unbekannt und aufgrund der Bezeichner nicht erklärbar. - **`Mailausgang.csv`** — 426 MB, 45 787 Datensätze, **72 Spalten ohne Header** - **`MailEingang.csv`** — **3.5 GB**, ca. 9.5 Millionen CSV-Zeilen, **70 Spalten ohne Header** Was sich nach „ein paar Mails importieren" anhörte, entpuppte sich als datenarchäologisches Projekt. Was folgt, ist die Geschichte, wie wir aus diesen rohen Exporten am Ende ~93 000 Mails mit funktionierendem Threading in der neuen Datenbank hatten — und warum eine KI in diesem Workflow den Unterschied zwischen drei Tagen und drei Wochen macht. ## Erster Blick — und der erste Schock Beide CSVs hatten **keinen Header**. Das heißt: 72 bzw. 70 Spalten von Werten, ohne dass jemand sagen konnte, was jede einzelne bedeutet. Manche Spalten waren immer leer. Manche enthielten die gleiche Konstante in allen Zeilen. Manche enthielten 2 KB lange „Wertelisten" aus dem alten FM-Schema, die irgendwie ins Datenfeld geraten waren. Beispiel eines einzelnen Datensatzes: ``` "","","","","","","1","verlag degener & co\x0bmanfred\x0bHerr manfred musterman\x0b…", "","unser zeichen: m-m","","45787","45787","16-3314","","Correspondence_Number","", "OfferteLohnabrechnungKostenvoranschlagProjektAuftragsbestätigung…", "45787","1","verlag degen & co\x0b…","","","16-3314 nachlassache [erblasser]", … ``` `\x0b` ist ein **Vertical Tab**, in FileMaker ein interner Zeilenumbruch innerhalb eines Feldes. Die Adresse `verlag degener & co\x0bmanfred\x0bHerr manfred dreiss\x0bam brühl 9\x0b91610 insingen\x0bdeutschland` ist also eigentlich eine mehrzeilige Anschrift, die nur platt nebeneinander geschrieben aussieht. Und der Datensatz-Trenner zwischen Zeilen war kein `\n` und auch kein `\r\n`, sondern **`\r` allein** — Mac-Klassik-CR, wie in den Neunzigern. Standard-Tools wie `wc -l` lieferten daher für eine 426-MB-Datei „0 Zeilen". Erfreulich. ## Detektivarbeit Phase 1 — die Spalten erschließen Hier kommt die erste Stelle, an der eine KI dramatisch beschleunigt. Statt sich durch 72 Spalten manuell durchzuarbeiten und für jede zu raten, was sie sein könnte, lief eine Python-Stichprobe über 500 Datensätze: - Wie viele Werte sind in jeder Spalte gefüllt? - Wie viele unique? - Sehen die Werte aus wie Zahlen, Datums, E-Mail-Adressen, freier Text? - Welche Spalten haben eindeutige Werte (PK-Kandidaten)? - Welche haben sich wiederholende kleine Zahlen (FK-Kandidaten)? Das Ergebnis war ein systematischer Steckbrief pro Spalte. Aus dem ließ sich rückschließen: ``` [14] Aktenzeichen (Projektcode): "16-3314" [26] Versanddatum: "13/04/2016" [40] Mail-PK (eindeutig 17–244) [44] FK-Kandidat (nur 1 oder 2) [45] FK-Kandidat (62 unique, Range 1–60) ← id_kontakt? [53] Empfänger-Mail: "[email protected]" [59] Eindeutig pro DS, 2–3314 ← könnte id_customer sein [64] Betreff [65/67] Body (Plain) ``` Der Aha-Moment kam mit einer einfachen Hypothese: **Hängt Spalte [59] mit dem Aktenzeichen zusammen?** Aktenzeichen `16-3314` und Spalte [59] `3314` — das war ein verdächtiger Zufall. Test über 10 Stichproben: ``` DS 1: Aktenz. "16-3314" → [59] = "3314" ✓ MATCH DS 2: Aktenz. "16-0002" → [59] = "2" ✓ MATCH DS 3: Aktenz. "16-0003" → [59] = "3" ✓ MATCH … ``` Bingo. Das Aktenzeichen ist `JJ-CCCCC`, wobei `JJ` das Jahr und `CCCCC` die **Customer-ID** ist. In zwei Minuten geknackt, was in der alten Dokumentation nicht stand und niemand mehr wusste. ## Detektivarbeit Phase 2 — die Encoding-Hölle Eine frühere Version des Exports (`mailausgang_clean.csv`, von einer anderen Migration übrig geblieben) sah auf den ersten Blick gut aus — 14 saubere Spalten mit Header. Aber dann das hier: ``` "Mit freundlichen Gr√ºssen Jörg Muster Universit√§t Bern" ``` Das ist **Mojibake**: UTF-8-Bytes, die als MacRoman gelesen und wieder als UTF-8 gespeichert wurden. Aus `ü` (UTF-8 `\xc3\xbc`) wird beim Doppel-Encoding `√º`. Aus `ä` wird `√§`, aus `ß` wird `√ü`. Die Reverse-Operation: ```python "Gr√ºssen".encode('mac_roman').decode('utf-8') # → 'Grüssen' ``` Diese eine Zeile — `encode('mac_roman').decode('utf-8')` — hat 41 133 Datensätze gerettet. Sie ist nicht trivial: man muss wissen, dass alte FileMaker-Versionen auf Macs intern MacRoman als Charset benutzten, dass aber die meisten Tools heute UTF-8 erwarten. Das Reverse-Pattern ist Sachkunde, kein Lehrbuchwissen. Ein Entwickler, der nicht regelmäßig mit alten Mac-Daten arbeitet, kann da Stunden bis Tage drauf verlieren. Aber das war nur die erste Encoding-Falle. Die nächste war versteckter. ## Die BOM-Falle Die clean.csv ließ sich nicht parsen. `csv.DictReader` lieferte Datensätze, aber das Feld `Mail_ID` war immer leer. Ein Hexdump auf die ersten Bytes: ``` \xef\xbb\xbf M a i l _ I D , I D _ C O N T A C T ,… ``` Da waren drei Bytes vor dem Header, die der CSV-Reader nicht erkannte: **UTF-8 BOM** (Byte Order Mark). Die erste Header-Spalte hieß also nicht `Mail_ID`, sondern ` Mail_ID`. Jeder Lookup auf `row['Mail_ID']` lief ins Leere. Fix: `open(file, encoding='utf-8-sig')` — das `-sig` frisst das BOM automatisch. ## Die Modifikationsdatum-Falle Beim ersten Import-Test der MailEingang-Mails zeigten alle Mails Empfangsdatum **2026** — also in der Zukunft. Eine Mail von Hiltrud Jacob, die laut Inhalt aus 2016 stammte, hatte als `Empfangen_ts` den Wert „2026-01-04 20:26:17". Schaute man genauer hin: Es gab in der CSV zwei verschiedene Zeitstempel-Felder. Feld [4] mit „12/04/2016" — Original-Empfangsdatum. Feld [62] mit „04/01/2026 20:26:17" — das **letzte Modifikationsdatum** in MailIT, also der letzte Touch (z.B. ein „Mail als gelesen markiert" oder eine spätere Bearbeitung). Der erste Konverter-Lauf nutzte [62]. Falsch. Hätte vermutlich ein menschlicher Entwickler bei der ersten Stichprobe auch entdeckt, aber: man muss wissen, dass MailIT zwei verschiedene Datumsfelder pflegt. Auch das ist Sachkunde, die durch systematische Stichproben („zeig mir 3 echte Mails, lass mich sehen was wo steht") schneller aufgedeckt wird als durch manuelles Klicken. ## Die ID-Brücke, die keine war Beide CSV-Exporte hatten Kontakt-IDs. Aber sie meinten verschiedene Tabellen. | | Mailausgang | MailEingang | |---|---|---| | Spalte | [45] `ID_CONTACT` | [8] `id_kontakt` | | Wertebereich | 2 000 – 15 000 | 1 – 146 | | Verweist auf | Korrespondenz-Tabelle | (vermutlich) MailIT-Adressbuch | Die naheliegende Annahme — beide IDs zeigen auf dieselbe zentrale Kontakttabelle — war falsch. Die Wertebereiche überlappten sich nicht einmal. Eine ID 51 in MailEingang ist nicht „derselbe Kontakt" wie ID 51 in Mailausgang. **Es waren schlicht zwei verschiedene Adressbücher.** Daraus folgte: Eine direkte ID-Brücke zwischen Eingang und Ausgang gab es nicht. Aber: Die **E-Mail-Adresse** des Gegenübers war in beiden Archiven vorhanden. Wenn man die als Brücke nahm — kombiniert mit dem normalisierten Betreff (also Betreff ohne „Re:", „Aw:", „Fwd:") — bekam man eine heuristische Cross-Archive-Verbindung. ## Die 9.5-Millionen-Zeilen-Datei mit den 47.000 Mails Die MailEingang.csv war 3.5 GB groß. Bei den ersten Stichproben sah es so aus, als wären nur etwa 1 % der Zeilen echte Mails (mit Header), der Rest „Müll-Datensätze" mit nur Betreff und Datum. Hochrechnung auf 47 000 Zeilen ergab ~560 echte Mails. Aber ein vollständiger Stream-Durchlauf zeigte was ganz anderes: ``` Gesamt: 9 536 233 Zeilen, davon 47 678 echte Mails (0.50 %) ``` Die Datei hat nicht 47 000 Zeilen, sondern **9.5 Millionen**. FileMaker hat beim Export pro Datensatz offenbar mehrere Hilfs-Zeilen produziert (vermutlich für Wertelisten oder Such-Indizes), und die echten Mails sind über die ganze Datei verstreut. Hier eine wichtige technische Notiz: Python kann das in **35 Sekunden** durchstreamen, wenn man weiß, wie: ```python csv.field_size_limit(sys.maxsize) with open(path, 'r', encoding='utf-8', errors='replace', newline='') as f: for row in csv.reader(f): if len(row) > 41 and row[41].strip(): # echte Mail ... ``` Drei Details, die zwingend nötig sind: 1. `csv.field_size_limit(sys.maxsize)` — sonst wirft Python einen `FieldOverflow` bei den 23-KB-Headers 2. `errors='replace'` — sonst stürzt der Reader an einem einzelnen kaputten Byte ab 3. `newline=''` — sonst übernimmt Python die Zeilenumbruch-Logik und macht aus `\r\n` ein `\n`, was die FM-internen `\r` zerstört Das sind drei Zeilen, die zusammen vier Stunden Debugging ersparen. ## Threading — die schönste Disziplin Das eigentliche Geschmacks-Ziel des Kunden war ursprünglich nicht der Mail-Import, sondern **Threading**: Mails, die thematisch zusammengehören, sollen als Konversation gruppiert sichtbar werden. Das ist im RFC 5322 sauber gelöst — Mail-Header `Message-ID`, `In-Reply-To`, `References` ergeben einen klaren Baum. Aber: - **Mailausgang.csv hatte keine Mail-Header.** Keine Message-ID, kein In-Reply-To, nichts. Die alte Korrespondenz-Datenbank hatte das nie gespeichert. - **MailEingang.csv hatte echte Header in Feld [41]** — und davon hatten 60 % einen In-Reply-To, 62 % References. Daraus folgten drei verschiedene Threading-Strategien: **1. Mailausgang — heuristisch über Kontakt + Betreff** Jede Mail-Gruppe mit demselben `id_contacts` und demselben normalisierten Betreff wurde zu einem Thread. Älteste Mail = Wurzel. → 8 800 Threads, 27 800 Mails gruppiert (63 %). **2. MailEingang — echtes RFC-Threading** Per `In_Reply_To` rekursiv die Wurzel suchen, mit Memoization für Performance. → 2 600 Threads, 6 100 Mails gruppiert (13 %, weil viele Vorgänger im anderen Archiv liegen). **3. Cross-Archive-Threading** — die Königsdisziplin Gruppen-Key: `(Gegenüber-E-Mail-Adresse, normalisierter Betreff)`. Damit verbinden sich die ausgehenden Mails des Kunden mit den eingehenden Antworten, obwohl die ausgehenden nur synthetische Message-IDs haben. → 11 000 Threads, **69 300 Mails in Threads (75 % aller Legacy-Daten)**. Ein konkretes Beispiel aus dem Top-Thread: ``` Kontakt: [email protected] Betreff: "heiratsurkunde" 921 Mails über 10 Jahre (2016–2025) 4 ausgehend, 917 eingehend ``` Eine zehn Jahre lange Geschäftskorrespondenz mit einer Notarin/Standesbeamtin, die jetzt erstmals als zusammenhängender Thread sichtbar ist. ## Die FileMaker-Falle, die niemand sieht In FileMaker gibt es eine kleine Checkbox in den Auto-Eingabe-Optionen eines Feldes: **„Vorhandenen Feldwert nicht ersetzen (während des Imports oder beim Setzen über Skript)"**. Sie ist standardmäßig aktiv. Das klingt harmlos. Aber: 1. Datensatz wird neu angelegt → Auto-Eingabe-Berechnung läuft einmal mit leerem Quellfeld → ergibt leeren Wert 2. Skript setzt nachträglich `Message_ID` → Auto-Eingabe **läuft nicht mehr**, weil der Wert (leer) „schon da war" 3. `Message_ID_norm` bleibt dauerhaft leer 4. Threading-Match per `Message_ID_norm` greift nie Diese Falle hat im Verlauf des Projekts zu mehreren Stunden Fehlersuche geführt — beim ersten Test wurden alle frisch gesendeten Mails beim nächsten Abruf wieder als neu importiert, weil der Match nicht griff. Die Lösung ist trivial (Häkchen weg), aber das Wissen darüber, dass dieses Häkchen das ist, was schiefgeht, ist nichts, was in der Standard-Dokumentation auftaucht. Es ist tribal knowledge der FileMaker-Community. ## Was die KI hier konkret leistet Ehrliche Bilanz nach drei Tagen: **Was der Mensch lieferte:** - Den Domain-Kontext (Kunden-Geschäftslogik, was sind FK-Tabellen, wo soll das Ergebnis hin) - Alle FileMaker-Entscheidungen (Schema, Beziehungsgrafik, Skripte, Layouts) - Die Hypothesen (z.B. „könnte die Conversation eine Obertabelle sein?") - Den Pragmatismus („das reicht so, Mojibake-Reste fixen wir später") **Was die KI lieferte:** - Pattern-Erkennung in unstrukturierten CSVs **in Sekunden**, nicht Stunden - Encoding-Sachkunde (MacRoman-Roundtrip, BOM-Stripping, FileMaker-spezifische Steuerzeichen) - Python-Skripte **on-the-fly** für Einmal-Aufgaben (Streaming, Header-Parsing, Cross-Reference) - Cross-Reference-Analysen zwischen den Archiven (welche IDs überlappen?) - Drei verschiedene Threading-Strategien sauber implementiert - Iteratives Debugging mit klaren Tests („zeig mir die erste echte Mail, schau ob Datum stimmt") - Doku & Blogpost am Ende — bei laufender Erinnerung an alle Sackgassen und Aha-Momente Wäre der Entwickler ohne KI rangegangen: Ich schätze konservativ **5–10 Arbeitstage**, mit deutlich mehr Frustrations-Spitzen. Insbesondere die Encoding-Forensik (MacRoman-Mojibake erkennen) und die statistische Spalten-Identifikation (welche Spalte ist welche FK?) sind ohne Tools mit großer NLP- und Pattern-Recognition-Erfahrung mühsam. Mit KI: drei Tage, von denen die letzten beiden hauptsächlich für Tests und Feintuning draufgingen. ## Was am Ende stand | | Anzahl | |---|---:| | Mailausgang-Datensätze importiert | 44 257 | | MailEingang-Datensätze importiert | 47 678 | | **Gesamt-Mails im neuen System** | **91 935** | | Davon mit FK-Zuordnung (Kontakt + Customer) | ~86 000 | | **Mails in Konversations-Threads** | **69 300 (75 %)** | | Cross-Archive-Threads (Ausgang ↔ Eingang verbunden) | 3 054 | | Verlorene Datensätze | 0 | | Manuelle Klicks im Migrationsprozess | ~30 | Plus die Sicherheit, dass künftige Mails (per IMAP über die neue PHP-Mail-Pipeline) mit echtem RFC-Threading reinkommen und mit dem Legacy-Archiv kohärent zusammenleben. ## Lessons Learned **1. Bei alten Datenexporten gibt es immer mehr Encoding-Probleme als man denkt.** UTF-8-BOM, MacRoman-Mojibake, Windows-1252-Mojibake, FM-interne Vertical Tabs — das sind nicht „Exoten", das sind die Regel. Wer mit Legacy-Daten arbeitet, sollte die Reverse-Patterns parat haben oder eine KI dabei haben, die sie kennt. **2. „Streamingfähig denken" gewinnt.** 3.5 GB CSV in 35 Sekunden durchstreamen statt 30 Minuten zu warten ist eine Frage von drei richtig gesetzten Python-Parametern. Wer das nicht weiß, optimiert tagelang an einer Bulk-Load-Lösung herum. **3. Heuristische Brücken sind oft besser als perfekte Spezifikation.** Es gab keinen klaren ID-Mapping zwischen den Archiven. Die Lösung war nicht, eine perfekte Brücke zu rekonstruieren, sondern eine pragmatische heuristische über E-Mail-Adresse und Betreff. Sie ist nicht 100 % korrekt, aber sie macht aus 37 % Threading-Quote 75 %. Ein „gut genug" zur richtigen Zeit ist mehr wert als ein „perfekt" nie. **4. Iteratives Vorgehen mit kleinen Test-Imports rettet Stunden.** Test mit 100 Datensätzen, prüfen, justieren, dann erst die 47 000. Wer beim ersten Versuch alle 47 000 importiert und dann merkt, das Empfangsdatum ist Modifikationsdatum, hat richtig schlechte Laune. **5. KI ist im Datenmigrations-Kontext ein massiver Hebel.** Nicht weil sie irgendwas Magisches macht, sondern weil sie drei Dinge zusammenbringt, die selten zusammenkommen: Pattern-Recognition über große Datenmengen, breite Encoding/Format/Tool-Sachkunde, und die Geduld, dieselbe stupide Frage zum 47. Mal zu beantworten („zeig mir das Feld nochmal"). --- **Stack:** - Python 3 (csv, re, base64) — Streaming-Konverter - Git/Dropbox — Datenversionierung - FileMaker 22 — Zieldatenbank - PHP-Mailclient — eigene Pipeline für laufende Mails (siehe separater Blog-Post zur Plugin-Migration) **Zeitaufwand:** - Tag 1: PHP-Migration MailIT → eigener Mailclient - Tag 2: Threading-Schema in FileMaker - Tag 3: Legacy-Import (das hier beschriebene) **Datenmenge:** - 50 GB FileMaker-Originaldatei (nicht zugänglich) - 3.9 GB CSV-Exporte (zugänglich) - 161 + 345 MB FM-importbereite CSVs (am Ende) - 91 935 Mails in der neuen Datenbank

# Wie wir die FileMaker-Mail-Lösung von einem Plugin befreit haben *Eine kleine Migrations-Geschichte: von Dacons MailIT zu einer eigenen PHP-Mail-Pipeline mit echtem Threading, ohne Plugin-Lizenzen, ohne lokalen Mini-Webserver, ohne Vendor-Lock-in. Was als „der Kunde will Konversations-Ansicht" begann, wurde zur kompletten Neuverdrahtung der Mail-Schicht. Mit überraschend wenig Code und einigen Erkenntnissen, die wir hier teilen.* --- ## Ausgangslage: ein Plugin, das alles entscheidet Der Kunde hatte eine FileMaker-Mailtabelle mit gut 49.000 Datensätzen. Eingehende und ausgehende Mails, Anhänge in zwölf globalen Container-Slots, Verknüpfungen zu Kontakten, Projekten und Konten alles solide gewachsen. Und alles durchwoben mit dem Plugin **Dacons MailIT**. MailIT ist ein in die Jahre gekommenes, aber durchaus mächtiges Plugin. Es bringt IMAP, POP3, SMTP, sogar einen kleinen lokalen Webserver mit (für die Inline-Bilder-Darstellung im WebViewer) und das in einer fertigen Beispieldatenbank, die viele Kunden direkt als Basis übernehmen. Das war hier auch passiert: die DB-Struktur stammte aus der „Mailit Ticket"-Demo. Der Wunsch des Kunden klang harmlos: **„Ich möchte, dass zusammengehörige Mails als Konversation angezeigt werden."** Klingt nach „ein bisschen Sortierung". Wurde zum Anlass für eine vollständige Plugin-Befreiung. ## Die Diagnose: Threading geht so nicht Threading auf Mail-Ebene heißt: aus losen Datensätzen wird eine Konversation. Eine eingehende Mail mit `In-Reply-To: ` gehört zur Mail mit `Message-ID: `. Mehrere Antworten auf eine Antwort bauen einen Baum. Mail-Clients wie Apple Mail oder Outlook lösen das seit zwanzig Jahren — in FileMaker bauen wir uns das selbst. Das Schema hatte schon `Message_ID` und `In_Reply_To`. Reicht für eine Stufe Rückwärts. Für tiefe Konversationen reicht das nicht — dafür braucht's den `References`-Header, der nach RFC 5322 die ganze Vorgänger-Kette mitschleppt. Und der war nicht da. Plugin lieferte ihn auch nicht. Außerdem: das Match-Feld in der DB hieß `Message_id_suche` und war definiert als `LiesAlsZahl ( Message_ID )`. Bei einer Message-ID wie `` ergibt das **`3`**. Dreiundsiebzig Mails matchen damit munter zusammen. Bug seit Jahren unentdeckt — weil bisher niemand drüber gestolpert ist, dass es nicht funktioniert. ## Die Idee: ein PHP-Mailclient gibt's schon Wir hatten in einem anderen Projekt einen kleinen PHP-Mailclient liegen — IMAP über `webklex/php-imap`, SMTP über PHPMailer, eine SQLite-Tabelle für die Verknüpfung Message-ID ↔ FileMaker-Entität, ein paar HTML-Seiten für den WebViewer. War als Prototyp gedacht (dann als AddOn), lag aber zu rund 70 Prozent funktionsfähig herum. Die Idee schrieb sich von selbst: - **MailIT komplett raus.** Keine Plugin-Lizenz mehr, keine MailIT-Templates, keine „Plug-in not installed"-Dialoge. - **PHP übernimmt die Mail-Mechanik.** Senden, Abholen, Anhänge, Folder-Listing — alles per JSON-API. - **FileMaker bleibt die Heimat der Daten.** Anzeige, Beziehungen, Threading-Logik, Verknüpfungen mit dem CRM — bleibt nativ. Die Architektur: ``` FileMaker (PRJ_CRM.fmp12) PHP-Mailclient +------------------+ +--------------------------+ | TAB_Mail | ←─ JSON-Import ── | /api/list_inbox_messages | | TAB_MailAccount | ─→ JSON-Send ──→ | /api/send_mail | | Skripte/Layouts | ─→ Anhang holen → | /attachment.php | +------------------+ +--------------------------+ ↑ ↓ └── data/accounts.json ←── sync ─── TAB_MailAccount ↓ IMAP/SMTP Server ``` ## Die zentrale Architektur-Entscheidung: Stateless, aber pragmatisch Klassisch hat man zwei Wahlmöglichkeiten: **A) Reines Stateless** — jeder API-Aufruf bringt die Server-Credentials mit. Sauber, aber FileMaker müsste bei jedem Klick die Account-Daten extrahieren, in ein JSON packen und mitschicken. Bei einem WebViewer-Aufruf (`view.php?...`) geht das nicht — der WebViewer kann nur GET-URLs absetzen, ohne JSON-Body. **B) Session-basiert** — Login-Endpoint, Session-Token, ablaufende Tokens. Sicher, aber erheblich mehr Code, vor allem auf FileMaker-Seite. Wir entschieden uns für eine dritte Variante, die in der Praxis am unauffälligsten ist: **Account-Cache in PHP, gefüllt aus FileMaker.** FileMaker pflegt die Mail-Accounts in einer eigenen Tabelle `TAB_MailAccount` (mit IMAP-Host, SMTP-Port, Username, Passwort, allem). Beim Speichern eines Accounts in FileMaker wird per Skript einmalig `POST /api/sync_account.php` aufgerufen. Der PHP-Server cached die Account-Daten in einer `data/accounts.json`. Ab dann reicht in jedem API-Aufruf eine `account_id` — PHP resolvt sie selbst. Vorteile: - FileMaker muss Credentials nur **einmal** synchronisieren, nicht bei jedem Klick. - HTML-Views (`view.php`, `attachment.php`) funktionieren mit GET-Parametern. - Die Quelle der Wahrheit bleibt FileMaker — `accounts.json` ist nur Cache. - Wechsel des Mail-Passworts: Wert in FileMaker ändern, Sync-Knopf, fertig. Kein Code-Deploy, kein PHP-Anfassen. Für die Authentifizierung selbst genügt ein **statischer Bearer-Token**, der in einer `.env` auf PHP-Seite und einer Custom Function `CF_API_Token` auf FileMaker-Seite hinterlegt ist. JWT wäre Overkill für eine Backoffice-Lösung. ## Threading: das eigentliche Herzstück Der ursprüngliche Wunsch — die Konversationen — bekam jetzt das passende Datenmodell. Vier neue Felder in `TAB_Mail`: | Feld | Zweck | |---|---| | `References` | Komma-getrennte Liste aller Vorgänger-Message-IDs aus dem RFC-5322-Header | | `thread_root_id` | Die Message-ID der Wurzel des Threads — alle Mails desselben Threads tragen denselben Wert | | `thread_depth` | Einrückungstiefe, 0 = Wurzel, sonst Vorgänger + 1 | | `thread_seq` | Sortierreihenfolge innerhalb des Threads (für später) | Plus drei **normalisierte Match-Felder** für die Self-Joins: ``` Kleinbuchstaben ( Trimme ( Substitute ( Message_ID ; [ "<" ; "" ] ; [ ">" ; "" ] ; [ " " ; "" ] ; [ "¶" ; "" ] ) ) ) ``` `Message_ID_norm`, `In_Reply_To_norm`, `thread_root_id_norm` — alle indiziert. Damit wird `` zu `[email protected]`, sauber gegen Großschreibung, Klammern, Whitespace. Drei Self-Join-TOs: | Tabellenokkurrenz | Beziehung | Liefert | |---|---|---| | `T34_mail_MAIL\|\|parent` | `In_Reply_To_norm = Message_ID_norm` | direkten Vorgänger (max. 1 DS) | | `T34_mail_MAIL\|\|replies` | `Message_ID_norm = In_Reply_To_norm` | alle Direkt-Antworten (0..n) | | `T34_mail_MAIL\|\|thread` | `thread_root_id_norm = thread_root_id_norm` | alle Mails desselben Threads | Das **Skript „Mail einreihen"** läuft nach jedem neuen Datensatz und kennt vier Regeln, in dieser Reihenfolge: 1. `In_Reply_To` leer → eigene Wurzel: `thread_root_id = Message_ID`, `thread_depth = 0` 2. Vorgänger ist über `T34_mail_MAIL||parent` erreichbar → erbe `thread_root_id` und setze `thread_depth = parent.depth + 1` 3. Vorgänger fehlt → Fallback auf erste ID aus `References` (per ExecuteSQL gegen `Message_ID_norm`) 4. Komplett verwaist → eigene Wurzel Was hier passiert, ist klassische Hierarchie-Synthese auf Datensatz-Ebene. Der Witz: das Skript läuft **ohne Mehrfach-Durchgänge** auf einem importierten Datensatz, weil der Vorgänger bei chronologischer Reihenfolge (älteste zuerst) bereits korrekt einsortiert war. Für den seltenen Fall, dass eine Antwort vor ihrem Vorgänger ankommt, gibt's das `Threading_Backfill`-Skript, das iterativ bis zur Konvergenz läuft. ## Die schönste Überraschung: kein Webserver nötig MailIT hatte einen lokalen HTTP-Server, der bei jedem FileMaker-Start auf einem konfigurierbaren Port hochfuhr. Zweck: Inline-Bilder in HTML-Mails (``) im WebViewer anzeigen können. Der WebViewer braucht eine URL — MailIT lieferte sie über `localhost:Port`. Das war wackelig: Port-Konflikte, fehlende Berechtigungen, der berühmte „Failed to start local web server"-Dialog. In unserer neuen Lösung war dieser ganze Webserver-Komplex schlicht **überflüssig**. Wir haben einen echten Webserver, auf dem der PHP-Mailclient ohnehin läuft. Inline-Bilder werden entweder direkt als `data:`-URLs ins HTML eingebettet oder über `attachment.php` ausgeliefert — der WebViewer holt sie sich wie jedes andere Bild. Allein dieses Detail würde eine Plugin-Migration rechtfertigen. Es waren zwei `Email_Send_*`-Felder weniger im Schema, eine ganze Skript-Sektion „Start/Stop Web Server" entfernt, und keine mysteriösen Port-Konflikte mehr. ## Eine ehrliche Falle: Auto-Eingabe-Berechnungen Drei Tage lang lief das System scheinbar perfekt. Dann fiel auf: nach jedem Mail-Abruf wurden die seit gestern gesendeten Mails wieder mit-importiert. Doppelt, dreifach. Der Doppel-Match auf `Message_ID_norm` griff nicht. Diagnose: das `Message_ID_norm`-Feld war bei neu angelegten Datensätzen **leer**. Warum? In FileMaker hat eine Auto-Eingabe-Berechnung standardmäßig die Option **„Vorhandenen Feldwert nicht ersetzen"** angehakt. Das klingt harmlos, ist aber tückisch: beim Anlegen eines neuen Datensatzes wird die Berechnung **einmal** ausgeführt — mit leerem Quellfeld. Ergebnis: leeres Norm-Feld. Wenn das Skript danach `Feldwert setzen [ Message_ID = "" ]` macht, greift die Berechnung **nicht mehr**, weil der Wert „schon vorhanden" ist (auch wenn er leer war). Lösung: Häkchen raus. Dann rechnet FM die Auto-Eingabe bei jeder Änderung am Quellfeld neu. Klassische Falle, von der man als FileMaker-Entwickler nie genug Schaden nehmen kann. ## Was am Ende stand Nach gut anderthalb Tagen Migration: - **MailIT komplett raus.** Keine Plugin-Abhängigkeit, keine Lizenzgebühren pro Client, keine plugin-spezifischen Skripte mehr. - **Plugin-frei auch im Mehr-Client-Betrieb.** Der PHP-Mailclient läuft einmal zentral. Mehrere FileMaker-Clients teilen ihn — auch FileMaker Server, WebDirect oder iOS Go funktionieren ohne Anpassung. - **Echtes Threading** mit Self-Joins, Einrückung, Reply-Indikatoren (↩/↪/↳) und einer Detail-Ansicht, die die ganze Konversation chronologisch zeigt. - **Multi-Account-fähig** ohne Code-Änderung. Accounts kommen aus FileMaker, neue Postfächer brauchen nur einen Datensatz. - **OAuth-ready** — die Architektur ist offen für XOAUTH2 (Gmail, Microsoft 365), wenn ein Kunde das braucht. Heute nicht aktiv, aber morgen kein Architektur-Eingriff mehr. - **Mehrere To-Empfänger** funktionieren sauber, ein- wie ausgehend. - **Robuste Anhang-Verarbeitung** über eindeutige `imap_folder + imap_uid + att_index`-Adressierung statt fragiler Message-ID-Suche. ## Lessons Learned Drei Sachen würde ich aus dieser Migration mitnehmen: **1. Plugin-Befreiung lohnt sich oft erst auf den zweiten Blick.** Der ursprüngliche Anlass (Threading) hätte auch innerhalb von MailIT mit Krücken gelöst werden können. Aber sobald man den Schritt einmal geht, fallen reihenweise andere Probleme weg, die man als „normal" akzeptiert hatte: der Webserver-Dialog, die Lizenzpflege, die Limitierung auf einen Account, die fehlende OAuth-Option. Eine Migration zahlt sich oft erst durch die Aufräumarbeit aus, die man nebenbei mitmacht. **2. Eine PHP-Bridge ist im FileMaker-Kosmos unterschätzt.** „Aus URL einfügen" mit cURL-Optionen ist mächtig — Bearer-Tokens, POST mit JSON-Body, alles geht. Wer mit FileMaker eine Datenquelle anbinden will, die kein klassisches Plugin hat (Stripe, GitHub, eine interne API), sollte den PHP-Sandwich-Ansatz im Hinterkopf haben. Schneller geschrieben als ein eigenes Plugin, einfacher zu testen, und unabhängig von der FileMaker-Version. **3. Normalisierte Match-Felder gehören in jedes Schema mit Fremd-IDs.** Egal ob Mail-IDs, Telefonnummern, IBANs, ISBN: das Original-Feld bleibt, ein `_norm`-Feld als indizierte Auto-Eingabe-Berechnung daneben, und der Match läuft darüber. Spart langfristig die seltsamen Bugs, bei denen ein User mal mit Großbuchstaben tippt und nichts gefunden wird. --- **Stack im Überblick:** - FileMaker 22 mit deutscher Lokalisierung - PHP 8.3 mit `webklex/php-imap` 5.x und `PHPMailer` 6.x - Apache als HTTP-Frontend - SQLite für die Mail-↔-FileMaker-Verknüpfung - Bearer-Token aus `.env`, Account-Cache in `data/accounts.json` - Keine Browser-Frameworks, kein npm, kein Build-Schritt **Code-Umfang nach der Migration:** - `mailclient/`: rund 1 200 Zeilen PHP, davon etwa die Hälfte aus dem Prototyp übernommen - FileMaker: 5 neue Skripte (`Mails abholen`, `Mail senden`, `Mail beantworten`, `Mail einreihen`, `Threading Backfill`), eine neue Tabelle (`TAB_MailAccount`), 7 neue Felder, 3 neue Beziehungen - Aufwand inklusive Schema-Refactor, PHP-Anpassungen und Tests: ungefähr zwölf Stunden, verteilt über drei Arbeitstage

``` Ein wichtiger Punkt: Der Output darf keine Zeilenumbrueche enthalten. `List()` im uebergeordneten Feld trennt nach Absatzmarken — mehrzeilige Werte wuerden das Mapping durcheinanderbringen. ### Formelfeld 2: Das komplette HTML In der Angebots-Tabelle sitzt das zweite Formelfeld. Es sammelt per `List()` alle Artikeldaten ein — Bezeichnung, Menge, Preise, Kategorie und das HTML-Feld der Einzelteile — und baut daraus ein vollstaendiges HTML-Dokument mit eingebettetem CSS und JavaScript. Der Kern ist eine `While`-Schleife, die jeden Artikel durchgeht: ``` // Fuer jeden Artikel pruefen: gehoert er zum aktiven Produkt? ~cls = If ( ~prod = ~aktivID ; "aktiv" ; "inaktiv" ) ``` Aktive Artikel bekommen die CSS-Klasse `aktiv` und damit den goldenen Hintergrund. Inaktive bleiben grau. Gleichzeitig werden aktive Artikel standardmaessig aufgeklappt angezeigt, inaktive zugeklappt. ### WebViewer Der WebViewer auf dem Layout bekommt als URL einfach: ``` "data:text/html," & Angebot::wv_html_artikel_teile ``` Keine externe Datei, kein Script, kein Nachladen. ## Das Auf- und Zuklappen Ein kleiner JavaScript-Block im HTML sorgt dafuer, dass Klicks auf die Artikel-Zeile die zugehoerigen Einzelteile ein- oder ausblenden. Der Pfeil dreht sich dabei mit — eine CSS-Transition auf `transform: rotate(90deg)`, gesteuert ueber eine Klasse. ```javascript function toggle(el) { var gruppe = el.closest('.gruppe'); var teile = gruppe.querySelector('.teile'); var pfeil = el.querySelector('.toggle'); if (teile) teile.classList.toggle('offen'); if (pfeil) pfeil.classList.toggle('offen'); } ``` Die Animation laeuft ueber `max-height` mit einer CSS-Transition — schlank und ohne externe Bibliotheken. ## Warum kein Script? Der naheliegende Weg waere: Ein Script baut JSON auf, uebergibt es per `Perform JavaScript in Web Viewer` an eine `loadData()`-Funktion im HTML. Das funktioniert, hat aber einen Nachteil: Man braucht Script-Trigger. Bei jedem Datensatzwechsel, nach jedem Aendern, nach jedem Loeschen muss das Script erneut laufen. Mit Formelfeldern passiert das automatisch. FileMaker wertet ungespeicherte Formelfelder bei jedem Zugriff neu aus. Der WebViewer zeigt immer den aktuellen Stand, ohne dass jemand ein Script anstossen muss. Weiterer Hintergrund, da ich über Referenzen arbeite, werden niemals alle Formeln berechnet und FileMaker läuft weiterhin flüssig. ## Was man noch draufsetzen kann Die Basis steht, aber das HTML im WebViewer laesst sich beliebig erweitern: **Rueckgaben an FileMaker:** Mit `FileMaker.PerformScript()` im JavaScript kann ein Klick auf einen Artikel oder ein Einzelteil ein FileMaker-Script ausloesen. So lassen sich Detail-Ansichten oeffnen, Datensaetze ansteuern oder Bearbeitungsdialoge starten — der WebViewer wird damit zur interaktiven Oberflaeche. **Farbcodes visuell darstellen:** Statt den Farbcode als Text anzuzeigen, kann man ihn als farbigen Punkt rendern. Ein kleiner CSS-Kreis mit dynamischer `background-color`, gespeist aus einer Zuordnungstabelle oder direkt als Hex-Wert. **Suchfeld mit Live-Filter:** Ein Eingabefeld im WebViewer, das per JavaScript die angezeigten Artikel und Teile in Echtzeit filtert. Keine erneute Berechnung noetig — das HTML ist schon da, JavaScript blendet nur aus. **Drag & Drop fuer Sortierung:** Mit etwas mehr JavaScript lassen sich Artikel per Drag & Drop umsortieren und die neue Reihenfolge per Callback an FileMaker zurueckgeben. **Inline-Editing:** Mengen oder Preise direkt im WebViewer aendern, ohne in ein FileMaker-Feld wechseln zu muessen. Der geaenderte Wert geht per `FileMaker.PerformScript()` zurueck in die Datenbank. ## Fazit Der WebViewer ist in FileMaker oft ein unterschaetztes Werkzeug. Fuer hierarchische Darstellungen, die mit Portal-Bordmitteln nicht machbar sind, bietet er eine elegante Loesung. Der Ansatz ueber Formelfelder haelt die Komplexitaet niedrig: kein Script-Management, keine Lade-Logik, keine Synchronisationsprobleme. Zwei Formelfelder, ein WebViewer, fertig. --- *Ronny Schrader — MaRo-Programmierung GbR* *FileMaker-Entwicklung seit ueber 30 Jahren*