Ronny Schrader

Wer schon einmal versucht hat, in FileMaker mit vielen Adressen eine Route über die Google Maps API zu planen, kennt das Problem. Ab einer gewissen Anzahl von Stopps schnellen die Kosten nach oben und die Performance leidet. Aber genau hier setzt mein Ansatz an: -Clustering-.

Warum Clustering?

Google erlaubt pro Request in der Directions API nur 25 Zwischenstopps (plus Start und Ziel). Mehr geht nicht. Mit 80 Kundenadressen wären das also drei bis vier Requests, wenn man clever plant.

Ohne Clustering würde man mit der Distance Matrix API schnell in den vierstelligen Bereich an Elementen kommen (80 × 80 = 6.400), die abgerechnet werden. Mit Clustering dagegen, vier kleine Matrizen a 20 × 20 = 400. Macht in Summe 1.600. Das sind 75 % weniger Kosten und dazu deutlich weniger Wartezeit.

1.	Geocoding – jede Adresse bekommt saubere Koordinaten.
2.	K-Means Clustering – die Adressen werden nach geografischer Nähe in Gruppen aufgeteilt (z. B. vier Cluster mit je 20 Stopps).
3.	Optimierung je Cluster – innerhalb des Clusters wird die Reihenfolge berechnet.
4.	Routes API – für jedes Cluster wird die Route berechnet, nie mehr als 25 Stopps.
5.	FileMaker-Integration – die Ergebnisse landen als einfache JSON-/GET-Antwort wieder in FileMaker, wo sie importiert und angezeigt werden können.

Das Ganze läuft mit Session-IDs, sodass FileMaker volle Kontrolle über den Ablauf hat und wir persistente Daten auch später noch abrufen können.

Demo-Daten für den Praxistest

Für das nächste FileMaker-Magazin haben wir Demo-Daten vorbereitet: • 80 Adressen im Raum Berlin/Brandenburg (kann natürlich geändert werden) • passende Kontaktdaten • und natürlich die fertige Clusterlösung

Damit kann jeder sofort ausprobieren, wie aus einer unübersichtlichen Masse von Stopps überschaubare Touren werden.

Nach etlichen Projekten mit WebViewer-Integration in FileMaker kennt man das: Eine aufwendig generierte HTML-Darstellung wird in eine Variable geschrieben und mit WebViewer.SetHTML in das Layout eingebunden. Doch irgendwann, meist nach einem Update, einer Layoutänderung oder schlicht durch zu große Datenmengen, bleibt der WebViewer plötzlich leer. Keine Fehlermeldung, kein Hinweis.

Die Lösung, die sich in meinem Fall bewährt hat. Statt den HTML-Inhalt direkt aus FileMaker in eine Variable zu übergeben, wird dieser über ein PHP-Skript auf dem Server dynamisch aufgebaut. FileMaker überträgt die Inhalte per POST, der Server speichert sie mit einer eindeutigen Session-ID in einer temporären Datei. Anschließend ruft FileMaker einfach https://meinserver.de/tour.php?session=ava_65df75dca14f8 auf und der WebViewer lädt die fertige Darstellung wie jede andere Webseite auch.

Vorteile dieser Methode:

– Kein Zeichenlimit oder Kodierungsproblem in FileMaker-Variablen – HTML, CSS und JavaScript können deutlich umfangreicher sein – Die Darstellung ist im Browser direkt testbar (z. B. mit ?debug=1) – Die Daten sind temporär gespeichert und nach Ablauf automatisch gelöscht

Vorgangsweise: Daten werden per POST an den Server gesendet, dort in einer temporären JSON-Datei abgelegt und über eine Session-ID abrufbar gemacht. Der WebViewer muss dann nur noch die Session-ID in der URL übergeben. Der Server liefert die fertige Darstellung. Also eigentlich wie mit dem Browser.

Dieser Code-Bereich ist das Herzstück für den POST-Empfang. Er übernimmt Daten aus FileMaker, speichert sie temporär als JSON-Datei und gibt eine eindeutige Session-ID zurück. Wenn sonst nach dem FileMaker Befehl -Aus URL einfügen- eine ganze HTML-Strucktur zurückkommt, bekommen wir nur noch die Session-ID zurück. Diese wird dann nur noch an die eigentliche URL der PHP-Datei gehangen. Z.B. so: https://deinserver.de/tour_post_neu.php?session=id123456.7654321.

// POST: Daten speichern und Session-ID zurückgeben
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $postData = array_map('trim', $_POST);
    $sessionId = uniqid('ava_', true);
    $sessionDir = __DIR__ . '/sessions/';
    if (!file_exists($sessionDir)) mkdir($sessionDir, 0755, true);
    file_put_contents($sessionDir . $sessionId . '.json', json_encode([
        'data' => $postData,
        'created' => time()
    ]));
    echo $sessionId;
    exit;
}

Nun wird diese URL (https://deinserver.de/tour_post_neu.php?session=id123456.7654321) im WebViewer aufgerufen. Für die Verarbeitung ist dieser Teil zuständig.

if (isset($_GET['session'])) {
    $sessionFile = __DIR__ . '/sessions/' . $_GET['session'] . '.json';
    if (file_exists($sessionFile)) {
        $sessionData = json_decode(file_get_contents($sessionFile), true);
        if (time() - $sessionData['created'] > 3600) {
            unlink($sessionFile);
            echo "Session abgelaufen";
            exit;
        }
        $postData = $sessionData['data'];
        // hier folgt die HTML-Ausgabe
    }
}

Listenansichten in FileMaker optimieren

Nach einigen Jahren und vielen 1000 Datensätzen die neu ins FileMaker-System gekommen sind, war es soweit. Eine spürbare Verschlechterung der Performance beim Aufbau einer extrem komplexen Listenansicht. Diese Ansicht enthält sehr viele Sortierungen, diverse bedingte Formatierungen zum Ein und Ausblenden von Symbolen, Farbgebung etc. Wenn jetzt noch jemand per VPN auf die Datenbank zugreifen wollte, so konnte es einige Zeit dauern bis die Arbeitsfähigkeit hergestellt war. Dabei wurde die Struktur schon ohne Formeln entwickelt.

Die schnellste und effektivste Lösung. Alles wird über ein WebViewer abgewickelt. Betritt der User das Listen-Layout wird ein Serverscript gestartet, sammelt alle FileMaker Daten und überträgt diese dann an ein PHP-Script. Bruchteile später, steht die Liste schon zum arbeiten bereit. Da die Liste nur mit Java-Script arbeitet, sind alle Aktionen sehr schnell.

Die Daten werden mithilfe eines FileMaker-Skripts vorbereitet und mit Insert from URL an eine PHP-Datei auf dem Server geschickt. Der Request erfolgt als klassischer application/x-www-form-urlencoded-POST-Aufruf. Der Server nimmt die Daten entgegen, bereinigt sie, zerlegt ggf. Pipe-getrennte Listen, und speichert sie in einem assoziativen Array zur weiteren Verarbeitung.

<?php
// Daten säubern
function cleanData($value) {
    return trim($value);
}

// Pipe-Werte aufspalten (z. B. '4711|4712|4713')
function processPipeSeparatedValues($value) {
    return array_map('trim', explode('|', $value));
}

// POST-Verarbeitung starten
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $postData = array_map('cleanData', $_POST);
    // Weiterverarbeitung folgt...
}
?>

Auf der FileMaker-Seite wird der Post so aufbereitet

Das PHP-Skript erzeugt eine strukturierte HTML-Tabelle, die über CSS und JavaScript erweitert wird: Sticky-Header, Hover-Effekte, Icons, Kartenintegration – alles dabei. Dank JavaScript lassen sich die Einträge mit einem Klick sortieren: Nach PLZ, Straße oder Kategorie. Auch Gruppierungen sind möglich, z. B. nach Stadtvierteln oder Bezirken, die dynamisch über Google Maps Geocoding ermittelt werden.

function sortByPLZ() {
    const table = document.querySelector("table");
    const tbody = table.querySelector("tbody");
    const rows = Array.from(tbody.querySelectorAll("tr"));

    // Entferne alte Gruppenköpfe
    document.querySelectorAll(".plz-header").forEach(row => row.remove());

    // Sortiere Zeilen nach PLZ (Spalte 12, also index 12)
    rows.sort((a, b) => {
        const plzA = a.cells[12].textContent.trim();
        const plzB = b.cells[12].textContent.trim();
        return plzA.localeCompare(plzB, "de", { numeric: true });
    });

    // Neue Gruppierung einfügen
    let currentPLZ = "";
    rows.forEach(row => {
        const plz = row.cells[12].textContent.trim();
        if (plz !== currentPLZ) {
            currentPLZ = plz;
            const headerRow = document.createElement("tr");
            headerRow.className = "plz-header";
            const headerCell = document.createElement("td");
            headerCell.colSpan = row.cells.length;
            headerCell.textContent = "PLZ: " + plz;
            headerRow.appendChild(headerCell);
            tbody.appendChild(headerRow);
        }
        tbody.appendChild(row);
    });
}

In dieser Ansicht wird unter anderem die Entfernung zu den nächsten Standorten ermittelt. Nach erfolgter Sortierung ist es sehr schnell möglich Aufträge zu verketten bei minimierter Fahrzeit. In dieser Ansicht aber nur berechnet über die Haversinsche Formel. Aber es ist ein extrem schneller Anhaltspunkt um Aufträge in Gruppen zusammenzufassen.

Besonders charmant: Das ganze geht auch über die Google Maps API. Die Ansicht dann über Google Maps.

Über das InfoWindows-Fenster lassen sich unendlich viele Informationen einblenden. In meinem Fall kann aus dieser Perspektive schon die Tourenzusammenstellung erfolgen. Es wird die Arbeitszeit ermittelt und kenntlich gemacht. Eine implementierte Fahrzeiten-Anzeige hat sich für Berliner-Verhältnisse als Unsinnig herausgestellt. Zu viele Verkehrsänderungen, zu viel Stau, in diesem Fall bedarf es der Erfahrung von Mitarbeitern und Disponenten.

Wichtig, ist natürlich auch die Sequentielle-Suche. Diese kann natürlich wie schon einmal berichtet, auch in normalen FileMaker-Listen, Anwendung finden.

Eine klassische FileMaker angelehnte Suche fehlt natürlich auch nicht. Hier lassen sich verschieden Kriterien verbinden und ermöglichen eine flexible Suche, ähnlich der klassischen FileMaker-Suche.

Das ich im Regelfall innerhalb von FileMaker immer Arbeitslayouts nutze, die im Hintergrund bei -30000 Pixel arbeiten, kann ich aus dem WebViewer heraus, alle FileMaker Script nutzen, die im Vorfeld genutzt wurden. Sie bekommen die Parameter in einer etwas anderen Form, meist als Liste. Somit ist der Aufwand auf der FileMaker-Seite überschaubar.

Fehlerbehandlung und Fallbacks

Natürlich kann nicht immer alles glattlaufen, etwa wenn der Server nicht erreichbar ist oder die Daten aus FileMaker unvollständig übertragen werden. Für diesen Fall habe ich einen einfachen Mechanismus eingebaut. Wenn keine oder fehlerhafte Daten ankommen, zeigt das Skript entweder eine Hinweisbox oder einen minimalen Fallback-Inhalt an. Dabei ist es wichtig, am Anfang der Datei gleich zu prüfen, ob zentrale POST-Werte gesetzt wurden. Gerade bei VPN-Nutzern oder instabilen Mobilverbindungen ist das hilfreich, der Nutzer bekommt sofort Rückmeldung, statt auf eine leere Seite zu starren.

if (!isset($_POST['touren']) || empty($_POST['touren'])) {
    die("<div class='error'>Keine Daten empfangen. Bitte erneut versuchen.</div>");
}

Unterschied zwischen FileMaker-Client und Server

Eine kleine, aber entscheidende Stolperfalle hat mich bei diesem Projekt einige Nerven gekostet. Während der gesamte Aufbau der Liste über den FileMaker Pro Client reibungslos funktionierte, lief das gleiche Script nicht mehr, wenn es über ein Server-Script (FileMaker Server) angestoßen wurde. Die WebViewer-Seite blieb leer. Kein Fehler, kein Hinweis, einfach nichts.

Nach längerer Analyse stellte sich heraus, die Anzahl und Verschachtelungen der DOM-Elemente war der Grund. Im Client lief das Rendering noch sauber durch, aber der FileMaker Server scheint bei der Generierung und Übergabe des WebViewers, speziell in Kombination mit „Insert from URL“ -> WebViewer -> HTML-Rendering, empfindlicher zu reagieren. Besonders bei vielen verschachtelten div-Containern, Tabellen-Inlays und Icon-Ebenen war Schluss.

Die Lösung war eher pragmatisch als elegant, ich habe den DOM deutlich verschlankt, viele dekorative Elemente entfernt oder durch schlankere Varianten ersetzt. Statt

<tr class="hover">
    <td>4711</td>
    <td>Berlin</td>
    <td>…</td>
</tr>