#filemaker

[filemakerexperts]

# Volltext-Suche über 100 000 Mails- und sie reagiert in 50 Millisekunden

Wie wir den klassischen FileMaker-WebViewer-Suchpatterns einen modernen Such-Backend untergeschoben haben, ohne die FileMaker-Datei selbst zu berühren. Mit einer SQLite-Datenbank, die schon im System lag. Mit einer Eingebauten von SQLite, die kaum jemand kennt. Und mit einer 2-Stunden-Implementierung, die jetzt für Datenbestände von 100 000 bis 10 Millionen Mails ausreicht, bei gleichbleibend sub-100-ms-Reaktion auf jeden Tastendruck.* --- ## Das Problem Im Mail-System eines Kunden lagen nach dem großen Legacy-Import knapp 96 000 Mails. Das vorhandene Suchpattern war ein bewährter FileMaker-WebViewer-Trick: Eine **gespeicherte Berechnung** pro Datensatz baut ein HTML-Schnipsel (`

…

`), eine zweite **ungespeicherte Berechnung** verknüpft alle Schnipsel zu einer großen HTML-Seite mit Suchfeld, der WebViewer rendert sie als `data:`-URL, JavaScript filtert clientseitig per `data-search`-Attribut. Bei 5 000 Datensätzen ist das **magisch**: man tippt, die Liste filtert sich sofort, kein Server-Roundtrip, kein Lag. Bei 10 000 noch ok. Bei 92 000 stirbt es. Konkrete Zahlen aus der Diagnose: - `Liste()` über 96 000 Datensätze: **10–30 Minuten** pro Aufruf (Oder FileMaker gibt auf) - Generiertes HTML: **~75 MB** als String - `data:`-URL: bei manchen WebKit-Versionen über 64 MB einfach gekappt - 92 000 DOM-Knoten + JS `querySelectorAll` pro Tastendruck: **mehrere hundert Millisekunden** zähes Laggen Kurz: Das Pattern skaliert auf 5–10 k Datensätze. Bei 92 k bricht es. ## Die Optionen Drei klassische Wege: **A — Vorfilter.** Statt alle Mails zu zeigen, immer nur eine sinnvolle Teilmenge (letzte 90 Tage, Mails eines Kontakts). Reduziert auf <2 000 Datensätze, dann funktioniert das alte Pattern wieder. Pragmatisch, aber zwingt den User in eine starre Vorfilter-Logik. **B — Klassische FileMaker-Suche.** Suchfeld → ExecuteSQL → Ergebnismenge in Listenansicht. Skaliert auf Millionen, verliert aber das schöne Live-Filter-Gefühl. **C — Server-side-Index.** Ein eigener Such-Endpoint im PHP-Backend, der gegen eine speziell optimierte Such-Datenbank fragt, JSON zurückliefert, vom WebViewer per Fetch konsumiert. Skaliert auf Millionen, behält Live-Filter, kostet aber ein paar Stunden Aufbau. Variante C wäre normalerweise Cadillac-Engineering. In dem Moment, als der Kunde fragte „haben wir nicht schon eine SQLite im System?", wurde sie zur Anderthalb-Stunden-Lösung. ## Der entscheidende Aha-Moment Der PHP-Mailclient hatte schon eine SQLite-Datei. Genauer: `mailclient/data/links.sqlite`, eingerichtet für die kleine Verknüpfungstabelle `mail_links`, die Mail-Message-IDs auf FileMaker-Entitäten (Kontakte, Projekte, Konten) abbildet. PDO-Treiber konfiguriert, `db()`-Helper definiert, Schema-Initialisierung idempotent. Alles da. Und dann der zweite Aha: **SQLite hat seit Version 3.9 einen eingebauten Volltext-Index namens FTS5.** Eine virtuelle Tabelle, die Token-basierte Volltext-Suche über Millionen Datensätze in <50 ms macht. Genau das, was Apple Spotlight nutzt. Kostenlos, ohne Plugin, ohne externen Index-Service. Ein schneller Check, ob FTS5 in der PHP-SQLite-Installation kompiliert ist: ```php $pdo = new PDO("sqlite::memory:"); $pdo->exec("CREATE VIRTUAL TABLE t USING fts5(x)"); $pdo->exec("INSERT INTO t VALUES ('hallo welt'), ('foo bar')"); $r = $pdo->query("SELECT x FROM t WHERE t MATCH 'hallo'")->fetchAll(PDO::FETCH_COLUMN); // → ['hallo welt'] ``` Ein „FTS5 verfügbar: ja" als Antwort, und das Projekt war von „2 Tage Aufwand" auf „2 Stunden" geschrumpft. ## Die Architektur ``` FileMaker WebViewer PHP-Mailclient SQLite +-------------------+ +-------------------+ +----------------+ | + JS | fetch(q=...) | /api/search_mails | SQL | mails_fts | | rendert Top 100 | <------------> | sucht im FTS5 | <-----> | (92k Mails) | +-------------------+ JSON +-------------------+ +----------------+ Tastendruck ^ | bei jedem neuen DS | /api/index_mail (von FM aufgerufen) ``` Drei neue PHP-Endpoints, eine FTS5-Tabelle, ein Python-Initial-Lauf, eine neue FileMaker-Berechnung mit ein paar Dutzend Zeilen JavaScript. Mehr nicht. ## Die FTS5-Tabelle ```sql CREATE VIRTUAL TABLE mails_fts USING fts5( pk_mail_id UNINDEXED, message_id UNINDEXED, betreff, body, absender, empfaenger, datum UNINDEXED, id_contacts UNINDEXED, id_account UNINDEXED, z_eingang UNINDEXED, thread_root_id UNINDEXED, tokenize = 'unicode61 remove_diacritics 2' ); ``` Zwei Details lohnen Erklärung: **`UNINDEXED`-Spalten** werden gespeichert, aber nicht in den Volltext-Index aufgenommen. Sie sind als reine Lookup- und Filter-Felder gedacht. So bleibt der Index kompakt: nur das, was wirklich durchsuchbar sein muss (`betreff`, `body`, `absender`, `empfaenger`), trifft den Tokenizer. **`remove_diacritics 2`** im Tokenizer ist der versteckte Held: er normalisiert alle Akzente und Umlaute. Eine Suche nach „muller" findet „Müller", „Mueller" und „Müller". Bei einem multilingualen Mail-Archiv mit deutschen, französischen, türkischen Namen ist das nicht Nice-to-have, sondern Funktionalität. ## Der Initial-Lauf Bei 96 000 Mails wäre ein Datensatz-für-Datensatz-Index-Update über die FileMaker-Skript-Engine vermutlich ein Stundenprozess. Python machte es in **15 Sekunden**: ```python import sqlite3, csv conn = sqlite3.connect('mailclient/data/links.sqlite') conn.execute("PRAGMA journal_mode = WAL") conn.execute("PRAGMA synchronous = NORMAL") for csv_file in [mailausgang_csv, maileingang_csv]: batch = [] with open(csv_file, encoding='utf-8') as f: for row in csv.DictReader(f): batch.append(( row['Message_ID'], row['Betreff'], row['Body_Plain'], row['Absender_mailadresse'], row['Empfaenger'], # … )) if len(batch) >= 1000: conn.executemany("INSERT INTO mails_fts (...) VALUES (?,?,...)", batch) conn.commit() batch = [] ``` 6 100 Datensätze pro Sekunde mit Batch-Inserts und WAL-Mode. Das Ergebnis: 91 935 Mails im Index, Datei-Größe der SQLite ~250 MB, Initial-Investment zum Aufbauen einmalig 15 Sekunden, danach für immer verfügbar. ## Der Such-Endpoint PHP, gut 80 Zeilen Code. Der Kern: ```php $sql = " SELECT pk_mail_id, message_id, betreff, absender, empfaenger, datum, id_contacts, id_account, z_eingang, thread_root_id, snippet(mails_fts, 3, '', '', '…', 12) AS snippet FROM mails_fts WHERE mails_fts MATCH ? ORDER BY rank LIMIT 100 "; ``` `snippet()` ist eine eingebaute FTS5-Funktion: sie nimmt das Body-Feld (Index 3), markiert die Treffer-Worte mit ``-Tags und schneidet 12 Tokens links und rechts ringsum raus. Das Ergebnis sieht aus wie Gmail-Suchergebnisse: man tippt „heiratsurkunde", sieht ein paar Zeilen Body-Kontext mit gelb hervorgehobenem Treffer. `ORDER BY rank` sortiert nach FTS5-internem Relevanz-Algorithmus (BM25). Die häufigste/beste Übereinstimmung erscheint oben. Kein Tuning, kein TF-IDF-Selbstbau nötig. Etwas mehr Sorgfalt verlangt das Mapping von **Benutzer-Eingaben in FTS5-Query-Syntax**: ```php $tokens = preg_split('/\s+/', $userInput); $clean = []; foreach ($tokens as $t) { $safe = preg_replace('/["\\\\:()*]/', '', $t); if (preg_match('/[@.\-]/', $safe)) { $clean[] = '"' . $safe . '"'; // E-Mail-Adresse als Phrase } else { $clean[] = $safe . '*'; // Prefix-Match für "mueller" → "muellermann" } } $ftsQuery = implode(' ', $clean); ``` Drei Regeln: gefährliche Sonderzeichen rausnehmen, Token mit `@`/`.` als Phrasen (sonst zerlegt FTS5 sie an Punkten), normale Wörter als Prefix-Match mit Stern (damit „mueller" sofort matcht, sobald 7 Zeichen getippt sind, ohne dass der User ENTER drücken muss). ## Das Frontend Im WebViewer: ```javascript let timer = null; function suche(q) { clearTimeout(timer); timer = setTimeout(() => doFetch(q), 200); } function doFetch(q) { if (!q || q.trim().length < 2) { document.getElementById('liste').innerHTML = '

Mindestens 2 Zeichen…

'; 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

[filemakerexperts]

Wie wir ein 50-GB-Mailarchiv aus einem 12 Jahre alten FileMaker-System gerettet haben

# 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

[filemakerexperts]

Wie wir die FileMaker-Mail-Lösung von einem Plugin befreit haben

# 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

[filemakerexperts]

Hierarchische Darstellung im FileMaker WebViewer, ganz ohne Script

# Hierarchische Darstellung im FileMaker WebViewer, ganz ohne Script **Artikel mit Einzelteilen in einem WebViewer anzeigen, aufklappbar, farblich hervorgehoben, und das Ganze nur mit zwei Formelfeldern.** --- Wer in FileMaker schon mal versucht hat, Daten aus zwei Tabellen in einem Portal darzustellen, kennt das Problem: Ein Portal zeigt immer nur Datensaetze einer Bezugstabelle. Artikel und deren Einzelteile in einer gemeinsamen, hierarchischen Liste? Geht nicht, zumindest nicht mit Bordmitteln (Geht schon, der Aufwand ist aber hoch). Die Ausgangslage, aus Artikel möchte ich die zugehörigen Katalogteile sehen. Die gaengigen Workarounds wie Hilfstabellen, Virtual Lists oder Anzeigetabellen funktionieren, bringen aber alle ihren eigenen Overhead mit. Wir haben uns fuer einen anderen Weg entschieden: **HTML im WebViewer, komplett generiert durch FileMaker-Formelfelder**. ## Das Ergebnis Der WebViewer zeigt eine kompakte, aufklappbare Stueckliste: - **Artikel** als farbige Header-Zeilen mit Bezeichnung, Menge, Preis und Kategorie - **Einzelteile** darunter eingerueckt, per Klick auf- und zuklappbar - **Farbliche Zuordnung**: Artikel des aktuell ausgewaehlten Produkts erscheinen in Gold, alle anderen in dezentem Grau Das Ganze aktualisiert sich automatisch, ohne Script-Trigger, ohne Ladevorgang. ## Die Idee Statt Daten per Script in einen WebViewer zu schaufeln, lassen wir FileMaker das HTML direkt in einem Formelfeld zusammenbauen. Der WebViewer zeigt dieses Feld einfach an. Aendert sich ein Datensatz, berechnet FileMaker das Feld neu, der WebViewer zeigt den aktuellen Stand. Dafuer braucht es genau zwei Formelfelder und einen WebViewer auf dem Layout. ## Aufbau ### Formelfeld 1: Einzelteile als HTML In der Artikel-Tabelle liegt ein ungespeichertes Formelfeld. Es holt sich per `List()` die Bezeichnungen und Mengen aller zugehoerigen Einzelteile und gibt sie als fertige HTML-Divs zurueck: ``` While ( [ ~bez = List ( Einzelteile::bezeichnung ) ; ~men = List ( Einzelteile::menge ) ; ~anz = ValueCount ( ~bez ) ; ~i = 1 ; ~html = "" ] ; ~i <= ~anz ; [ ~html = ~html & "

" & GetValue ( ~bez ; ~i ) & "" & GetAsNumber ( GetValue ( ~men ; ~i ) ) & "x" & "

" ; ~i = ~i + 1 ] ; ~html ) ``` Das Ergebnis ist ein Textblock wie: ```html

Schraube M6x204x

Duebel S84x

``` 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*

[filemakerexperts]

# Echte RAL-Farben im FileMaker WebViewer – mit Suche, Detailansicht und Script-Aufruf

Manchmal entstehen die schönsten Lösungen aus einer simplen Frage: „Kann ich aus meiner Farbtabelle im WebViewer die Farbe anzeigen lassen?" Was harmlos klingt, führte zu einer kompakten aber richtig nützlichen Lösung, vollständig in einer einzigen FileMaker-Calculation, ohne Plugin, ohne externe Datei. ## Die Ausgangssituation In einer Produktdatenbank gibt es eine Tabelle mit Lackfarben. Gespeichert sind Farbname, Farbnummer und Kategorie, klassisch eben. Die Farbnummern folgen dem Schema `FST6002`, was nichts anderes bedeutet als RAL 6002 (Laubgrün). Das ist der entscheidende Kniff: **Die RAL-Nummer steckt direkt in der Farbnummer drin.** RAL-Farben haben definierte HEX-Werte. Also lässt sich aus `FST6002` direkt `#2D572C` ableiten – kein manuelles Nachschlagen, kein externes API. ## Der WebViewer-Ansatz Der Plan: Ein WebViewer zeigt eine komplette Farbgalerie mit Suchfunktion, Kategoriefilter und Detailansicht. Klick auf eine Farbe öffnet die Detailansicht, von dort kann per Button ein FileMaker-Script aufgerufen werden – mit der Farbnummer als Parameter. Die gesamte Logik steckt in einer einzigen Calculation: ``` "data:text/html,..." ``` Kein `GetAsURLEncoded`, kein externes File. Einfach ein langer String. ## Der entscheidende Trick: Einfache Anführungszeichen Hier lauert die häufigste Falle beim WebViewer mit `data:text/html`. FileMaker erwartet den HTML-Inhalt als String in **doppelten Anführungszeichen**. Sobald im HTML selbst doppelte Anführungszeichen auftauchen (und HTML ist voll davon), gibt es Probleme. Die Lösung ist denkbar einfach: **Das gesamte HTML ausschließlich mit einfachen Anführungszeichen schreiben.** ```html

●

``` Statt: ```html

●

``` Auch `GetAsURLEncoded` entfällt komplett – FileMaker rendert den `data:text/html`-String direkt, solange keine doppelten Anführungszeichen darin stecken. ## Das RAL-Mapping Das Herzstück ist ein JavaScript-Array mit allen 231 RAL-Farben direkt im HTML: ```javascript var F=[ {n:'Laubgrün', r:'FST6002', k:'RAL', h:'#2D572C'}, {n:'Seidengrau', r:'FST7044', k:'RAL', h:'#CAC4B0'}, // ... ]; ``` Das Array wird beim Generieren der Calculation einmalig aus einer Tabelle und dem RAL-Mapping aufgebaut. Farben ohne definierten HEX-Code (Holzdekore, Sonderfarben) zeigen ein Schraffur-Muster. ## FileMaker-Script aus dem WebViewer aufrufen In der Detailansicht gibt es einen „Übernehmen"-Button. Per JavaScript wird direkt ein FileMaker-Script aufgerufen: ```javascript function fmScript(){ var nr = document.getElementById('snr').textContent; if(typeof FileMaker != 'undefined'){ FileMaker.PerformScript('Farbe_Uebernehmen', nr); } } ``` `FileMaker.PerformScript()` ist die offizielle Schnittstelle zwischen WebViewer und FileMaker. Der zweite Parameter ist der Script-Parameter – hier die Farbnummer, die im Script dann per `Get(ScriptParameter)` abgerufen wird. ## Der Farbkreis in Listen und Portalen Als Bonus lässt sich aus der Farbnummer auch ein farbiger Kreis direkt in FileMaker-Layouts erzeugen, ganz ohne WebViewer (Kein WebViewer in FileMaker-Ausschnitten). Eine Berechnungsformel mit `Falls` und `RGB()`: ``` SetzeVar ( [ farbnr = Farben::FarbNr ; rgb = Falls ( farbnr = "FST6002" ; RGB ( 45 ; 87 ; 44 ) ; farbnr = "FST7044" ; RGB ( 202 ; 196 ; 176 ) ; // alle 231 Einträge... RGB ( 180 ; 180 ; 180 ) ) ] ; TextFarbe ( "●" ; rgb ) ) ``` Das `●` Zeichen erscheint dann direkt in der Listenansicht oder im Portal in der korrekten RAL-Farbe. Klein, schnell, effektiv. ## Fazit Die fertige Lösung braucht keine externen Ressourcen, keinen Server, kein Plugin. Der WebViewer rendert eine vollständige Single-Page-App aus einem einzigen FM-String heraus. Die Kombination aus RAL-Mapping, einfachen Anführungszeichen und `FileMaker.PerformScript()` macht daraus ein vollwertiges Farbauswahl-Tool. Manchmal sind die elegantesten Lösungen die, die aus einer schlichten Frage entstehen.

[phologlass]

ChatGPT を使うように AI に質問・指示：Claris FileMaker 2025 - AI 活用

AI を活用するための新機能を、深掘りして解説します。今回は第 1 弾として、[モデルから応答を生成] スクリプトステップにフォーカスします。

[filemakerexperts]

Wenn Starlink dein VPN blockiert: Die Relay-Server-Lösung

*Ein praktischer Leitfaden für FileMaker-Entwickler und Remote-Worker* ## Das Problem: VPN über Starlink schlägt fehl Als FileMaker-Entwickler arbeite ich regelmäßig remote an Kundenprojekten. Der Zugriff auf interne FileMaker-Server erfolgt dabei manchmal über OpenVPN. Das funktionierte über Jahre hinweg problemlos, bis ich auf Starlink als Internet-Provider wechselte. ### Die Symptome Die VPN-Verbindung schien auf den ersten Blick zu funktionieren: - TLS-Handshake erfolgreich - Zertifikate werden akzeptiert - Verbindung zum VPN-Server wird aufgebaut Aber dann: **AUTH_FAILED** Interessanterweise zeigte der VPN-Server keinerlei Login-Versuche in seinen Logs. Es war, als würde die Authentifizierung ins Leere laufen. ### Der Beweis: Es liegt an Starlink Ein schneller Test mit dem Smartphone als Hotspot (mobiles Netz) brachte Klarheit: **Die VPN-Verbindung funktionierte sofort einwandfrei.** Das bedeutet: - Die Credentials sind korrekt - Die VPN-Konfiguration ist valide - **Starlink manipuliert oder blockiert OpenVPN-Traffic** ## Warum blockiert Starlink OpenVPN? Starlink ist bekannt dafür, dass es mit bestimmten VPN-Protokollen auf Standard-Ports Probleme gibt. Die Gründe sind vielfältig: 1. **Carrier-Grade NAT (CGNAT)**: Starlink nutzt oft mehrere NAT-Ebenen, was VPN-Protokolle verwirren kann 2. **Traffic-Shaping**: Bestimmte Protokolle werden priorisiert oder gedrosselt 3. **Deep Packet Inspection**: OpenVPN-Pakete auf Port 1194 (TCP) werden möglicherweise erkannt und anders behandelt 4. **Satellitenlatenz**: Die hohe Latenz kann bei bestimmten Protokollen zu Timeouts führen In meinem Fall wurde die Verbindung technisch aufgebaut, aber die Authentifizierungs-Pakete kamen nie beim Server an oder wurden fehlerhaft übertragen. ## Die Lösung: Ein VPN-Relay-Server Statt gegen Starlink anzukämpfen, habe ich einen Workaround entwickelt: **Ein Relay-Server als VPN-Vermittler**. ### Die Architektur ``` Mein Mac (Starlink) ↓ [Normaler TCP-Traffic] Windows Server (Cloud/Rechenzentrum) ↓ [OpenVPN] Kunden-FileMaker-Server ``` Der Trick: Der Relay-Server hat eine normale Internet-Verbindung ohne Starlink-Einschränkungen und baut die OpenVPN-Verbindung problemlos auf. ### Warum einen eigenen Server nutzen? In meinem Fall hatte ich bereits einen gemieteten Windows Server. Statt einen zusätzlichen VPS zu mieten, nutze ich einfach diesen: **Vorteile:** - Keine zusätzlichen Kosten - Bestehende Infrastruktur nutzen - Volle Kontrolle über die Konfiguration - Kann für mehrere Kundenprojekte genutzt werden - Einfach ein-/ausschaltbar ## Technische Umsetzung ### Schritt 1: OpenVPN auf dem Relay-Server Auf dem Windows Server (könnte auch Linux sein): 1. OpenVPN Client installieren 2. Die VPN-Config des Kunden importieren 3. Verbindung aufbauen – funktioniert problemlos! ### Schritt 2: Port-Forwarding einrichten Der elegante Teil: Ich richte auf dem Relay-Server ein Port-Forwarding ein, sodass ich vom Mac aus direkt auf den Kunden-FileMaker-Server zugreifen kann. **Windows (PowerShell als Admin):** ```powershell # Port 15003 auf den FileMaker-Server weiterleiten netsh interface portproxy add v4tov4 ^ listenport=15003 ^ listenaddress=0.0.0.0 ^ connectport=5003 ^ connectaddress=192.168.00.00 # Firewall öffnen netsh advfirewall firewall add rule ^ name="FileMaker Relay" ^ dir=in action=allow protocol=TCP localport=15003 ``` **Linux Alternative:** ```bash # Mit iptables iptables -t nat -A PREROUTING -p tcp --dport 15003 \ -j DNAT --to-destination 192.168.00.00:5003 iptables -t nat -A POSTROUTING -j MASQUERADE # Oder mit socat (einfacher für Tests) socat TCP-LISTEN:15003,fork TCP:192.168.00.00:5003 ``` ### Schritt 3: Vom Mac aus verbinden In FileMaker Pro einfach als Host eintragen: ``` mein-relay-server.de:15003 ``` **Fertig!** Der FileMaker Server ist erreichbar, als wäre er direkt im Internet. ### Sicherheitsüberlegungen **Wichtig:** 1. **Port-Forwarding nur für vertrauenswürdige Ziele** – du leitest Traffic durch deinen Server 2. **Firewall-Regeln eng fassen** – nur die benötigten Ports öffnen 3. **Starke Authentifizierung** am FileMaker-Server selbst 4. **Logging aktivieren** – um unbefugte Zugriffe zu erkennen 5. **IP-Whitelist** in Betracht ziehen, falls deine eigene IP stabil ist ### Performance Durch den zusätzlichen Hop (Relay-Server) entsteht minimal zusätzliche Latenz: - **Direkt (ohne Starlink-Problem)**: ~50ms - **Via Relay**: ~70-100ms Für FileMaker-Development ist das völlig akzeptabel. Die Satellitenlatenz von Starlink (20-40ms) ist da meist der größere Faktor. ## Kosten-Nutzen-Rechnung **Ohne eigenen Server:** - VPS-Kosten: ~5€/Monat - Zeitaufwand Setup: ~1-2 Stunden einmalig - **Nutzen**: Produktives Arbeiten von jedem Ort mit Starlink **Mit eigenem Server:** - Zusatzkosten: 0€ - Zeitaufwand Setup: ~30 Minuten - **Nutzen**: Mehrere Kundenprojekte über einen Relay **Alternative (Handy-Hotspot):** - Kosten: Mobiles Datenvolumen - **Nachteil**: Umständlich, langsamer, Akku leer Für mich war die Relay-Lösung die perfekte Alternative. ## Fazit Starlink ist eine fantastische Technologie für Remote-Work – aber mit VPN-Verbindungen gibt es bekannte Hürden. Statt zu verzweifeln oder ständig auf Handy-Hotspot auszuweichen, bietet ein Relay-Server eine **elegante, dauerhafte Lösung**. Die Einrichtung ist in unter einer Stunde erledigt und funktioniert dann zuverlässig. Besonders für FileMaker-Entwickler, die regelmäßig auf verschiedene Kunden-Server zugreifen müssen, ist diese Methode Gold wert. ### Zusammengefasst **Problem**: Starlink blockiert OpenVPN-Authentifizierung **Lösung**: Relay-Server als VPN-Vermittler **Aufwand**: 30-60 Minuten Setup **Kosten**: 0-5€/Monat (falls kein eigener Server vorhanden) **Ergebnis**: Produktives Arbeiten von überall --- ## Weiterführende Ressourcen - [Starlink Network Architecture](https://www.starlink.com/) – Offizielle Dokumentation - [OpenVPN Best Practices](https://openvpn.net/community-resources/) - [WireGuard vs OpenVPN](https://www.wireguard.com/papers/wireguard.pdf) – Technischer Vergleich - [FileMaker Server Remote Access](https://help.claris.com/de/pro-help/content/remote-access.html) --- *Hast du ähnliche Erfahrungen mit Starlink und VPN gemacht? Welche Lösungen hast du gefunden? Schreib es in die Kommentare!*

[filemakerexperts]

Frohe Weihnachten von FileMaker-Experts!

Unsere kreative Abteilung hat dieses Jahr die Weihnachtskarte übernommen, ganz ohne Prompts, ganz ohne API-Calls. Wir wünschen euch wunderbare Feiertage und freuen uns auf ein spannendes 2026!