Ronny Schrader

Die Integration von FileMaker-Datenbanken mit PHP war lange Zeit kein zentraler Bestandteil vieler Webentwicklungsprojekte. Doch die Tools und Technologien, die hierfür zur Verfügung stehen, haben sich über die Jahre drastisch verändert. In diesem Beitrag werfen wir einen detaillierten Blick darauf, wie sich die Möglichkeiten seit FileMaker 17 weiterentwickelt haben und welche Vorteile die modernen Ansätze bieten. Dabei gehen wir auf Scriptaufrufe, Parameterübergaben und Unterschiede zwischen älteren und neuen Methoden ein.

Wie bin ich darauf gekommen, diesen kleinen Vergleich zu ziehen. Mir ist ein uraltes Projekt aus FileMaker 13 Zeiten wieder in die Hände gefallen. Ich hatte noch ein Backup in der iCloud gefunden. Zu dieser Zeit nutzte ich diese gerne um Daten zu sichern. Damals bauten wir das Backend in FileMaker, über IWP wurden die Daten im Webbrowser Teilnehmern der Semicon zur Verfügung gestellt. FileMaker diente als Klient am Counter und im Browser für Anmeldung, Kartenzahlung etc. Es war eine Katastrophe, was für ein Geraffel. Mehrere 1000 Zugriffe pro Stunde zwangen den Server immer wieder in die Knie. Aber wir haben sofort beschlossen, das geht im nächsten Jahr so nicht noch einmal. Ich nutze ab diesem Moment PHP und FileMaker in Kombination. Bis heute, für mich die perfekte Symbiose zweier Systeme.

1. Früher: FileMaker PHP API (bis FileMaker 17)

Vor der Einführung der FileMaker Data API (ab Version 17) war die FileMaker PHP API die Standardlösung, um eine Verbindung zwischen einer FileMaker-Datenbank und einer PHP-basierten Anwendung herzustellen. Diese API war eine PHP-Bibliothek, die speziell für FileMaker entwickelt wurde und direkt mit der Web Publishing Engine (WPE) des FileMaker Servers interagierte.

Merkmale der FileMaker PHP API • Eigene Klassenstruktur: Die API stellte Klassen wie FileMaker, FileMaker_Layout, und FileMaker_Command_Find bereit. • Datenabruf: Abfragen wurden durch spezielle Methoden ausgeführt. Ergebnisse kamen als serialisierte PHP-Arrays zurück. • Skriptausführung: FileMaker-Skripte konnten durch die Methode setScript() aufgerufen werden. • Beschränkt auf WPE: Die WPE musste auf dem FileMaker Server aktiviert sein, um die PHP API zu verwenden.

Mal ein kleines Beispiel:

getLayout('DeinLayout');
$request = $fm->newFindCommand($layout);
$request->addFindCriterion('Feldname', 'Wert');
$request->setScript('Skriptname', 'Parameterwert'); // Skript und Parameter setzen

$result = $request->execute();

if (FileMaker::isError($result)) {
    echo 'Fehler: ' . $result->getMessage();
} else {
    echo 'Skript erfolgreich ausgeführt.';
}
?>

Einschränkungen • Die API war schwergewichtig und teilweise langsam. • Abhängigkeit von der WPE machte sie weniger flexibel. • Kein modernes JSON-Format, sondern serialisierte Arrays. • Abkündigung mit der Einführung der FileMaker Data API.

Aber es hatte auch was für sich. In Gedanken bin ich immer dem FileMaker nahe geblieben. Layouts, Tabellen, Script-Namen. Als wenn ich mit FileMaker entwickeln würde, nur mit reinem Quellcode.

2. Heute: FileMaker Data API (ab FileMaker 17)

Die Einführung der FileMaker Data API markierte einen Wendepunkt in der Integration von FileMaker-Daten mit externen Anwendungen. Die neue REST-basierte API macht es einfacher, FileMaker-Daten mit Standard-HTTP-Technologien zu verwalten.

Merkmale der FileMaker Data API • RESTful Architektur: Kommunikation erfolgt über HTTP-Methoden wie GET, POST, PATCH und DELETE. • JSON-Datenformat: Anfragen und Antworten erfolgen in leicht verständlichem JSON. • Skriptausführung: Skripte können direkt über Parameter in der Anfrage ausgeführt werden. • Plattformunabhängig: Kein PHP-Modul erforderlich, funktioniert mit jedem HTTP-Client.

Skriptausführung mit der Data API

Die Data API ermöglicht die Ausführung von FileMaker-Skripten direkt während eines HTTP-Requests. Parameter können bequem als JSON übergeben werden.

Beispiel Heute:

/ Funktion zum Starten des FileMaker-Scripts
		function startFileMakerScript(orderNumber) {
			if (!orderNumber || orderNumber === "Keine") {
				alert("Keine gültige Auftragsnummer vorhanden.");
				return;
			}

			const fileMakerScriptUrl = `fmp://$/DeineDatenbank?script=DeinScript¶m=${encodeURIComponent(orderNumber)}`;
			console.log(`Starte FileMaker-Script mit URL: ${fileMakerScriptUrl}`);
			window.open(fileMakerScriptUrl, '_blank');
		}

		if (!employees || employees.length === 0) {
			alert("Keine passenden Mitarbeiter gefunden.");
			return;
		}

Vorteile der Data API • Geschwindigkeit: Die API ist schneller und effizienter als die alte PHP API. • Flexibilität: Funktioniert mit jeder Programmiersprache und nicht nur mit PHP. • Standardkonformität: Nutzung moderner Webstandards (JSON, REST). • Skalierbarkeit: Unterstützt größere Datenmengen und parallele Anfragen.

Fazit: Warum auf die Data API setzen?

Die Data API bietet eine deutlich modernere, schnellere und flexiblere Möglichkeit, mit FileMaker-Daten zu arbeiten. Für neue Projekte ist sie der klare Favorit, da sie standardisierte Technologien nutzt und unabhängig von einer spezifischen Programmiersprache ist. Es macht auch unheimlichen Spaß, FileMaker Schwächen durch HTML/PHP/Java-Script zu kompensieren. Siehe meinem Beitrag zum Thema Portale innerhalb von FileMaker Portalen anzeigen.

Ein altes Bild zu diesem Projekt. Semicon 2013 oder 2014