Ronny Schrader

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>