Web-Publishing mit FileMaker
Sie haben Inhalte in Ihrer FileMaker Datenbank, die im Internet veröffentlicht werden sollen?
Oder Sie wollen Anfragen von Kunden entgegennehmen und die Daten sollen in FileMaker gespeichert werden?
Oder beides?
Willkommen in der Welt des Web-Publishing mit FileMaker!
Das Schöne an der Sache: Das Ganze funktioniert problemlos!
Aber: welchen technischen Weg sollen Sie einschlagen, um das Ziel zu erreichen? Möglichkeiten gibt es nämlich viele!
Web-Publishing Möglichkeiten
- Export von statischen HTML-Daten aus FileMaker
- FileMaker WebDirect
- FileMaker Custom Web Publishing
- SQL-Datenbank mit FileMaker ESS Zugriff
- Beliebige Datenhaltung mit FileMaker REST Zugriff
Dieser Blogartikel soll die unterschiedlichen Web-Publishing Varianten aufzeigen und die Vor- und Nachteile diskutieren.
Beispiel Ferienhausvermietung
Nehmen wir an, Sie vermieten zehn Ferienhäuser auf Mallorca. Zwei davon gehören Ihnen selbst, die restlichen acht gehören drei Bekannten, in deren Namen Sie die Häuser für eine kleine Provision vermieten.
In FileMaker haben Sie alle zehn Häuser nett beschrieben inklusive Fotos und Daten, wann die Häuser an wen vermietet sind oder von den Besitzern selbst benötigt werden.
1. Export von statischen HTML-Daten aus FileMaker
Beginnen wir mit der langweiligsten Variante, dem statischen Publishing von HTML und Bilddaten.
In FileMaker bauen Sie (oder der von Ihnen beauftrage FileMaker Programmierer) per Scripts und Formeln ein paar nette HTM-Codeblöcke zusammen und per Knopfdruck werden die Daten mittels Script als HTML Datei und Bilder exportiert und möglicherweise per FileMaker Plugin sofort auf den Webserver hochgeladen.
Diese Variante hat den Vorteil, dass sie kaum Anforderungen an den Webserver stellt. Jeder Webserver kann statische HTML Dateien und Bilder veröffentlichen und das Ganze auch rasend schnell und in Normalfall gut für Suchmaschinen lesbar.
Sie benötigen dafür keinen FileMaker Server, es reicht ein FileMaker Client.
Ein Nachteil ist, dass Sie die HTML-Daten in FileMaker “zusammenbauen” müssen oder die Daten, falls Sie diese nicht direkt als HTML sondern z.B. als JSON oder XML exportieren, mit einer weiteren Software in HTML-Dateien konvertieren müssen – es wird also ein Programmierer mit mindestens HTML-Fähigkeiten benötigt.
Praxisbeispiel
Dieses Verfahren habe ich zum Beispiel beim Projekt https://salzburg-sehenswürdigkeiten.at gewählt. Es werden JSON Daten aus FileMaker exportiert, diese werden mit einem Javaprogramm dann in HTML umgewandelt und auf den Webserver hochgeladen.
Der größte Nachteil jedoch ist, dass Endkunden, die ein Ferienhaus mieten möchten, nun keine gute Möglichkeit haben, das sofort online zu machen, da ja keine Verbindung von der Webseite zu FileMaker besteht. Sie können hier höchstens eine Telefonnummer oder ein Emailformular auf der Webseite hinterlegen, und die Kunden buchen dann darüber.
2. FileMaker WebDirect – Web-Publishing ohne Programmierung
FileMaker WebDirect ist für viele Einsatzszenarien eine ganz tolle Möglichkeit, da man die FileMaker Datenbank samt Layouts und den meisten Funktionen problemlos im Internet veröffentlichen kann, ohne dass man speziell etwas programmieren muß dafür.
Wenn Sie FileMaker Layouts und Scripts beherrschen, dann können Sie auch WebDirect!
Für WebDirect wird zwingen ein FileMaker Server benötigt, der über das Internet zugänglich ist. WebDirect muss am FileMaker Server im Menüpunkt “Konnektoren” aktiviert werden.
Danach müssen Sie in der zu veröffentlichen Datenbank noch individuelle Berechtigungen setzen, denn Sie wollen ja vermutlich nicht die gesamte Datenbank für anonyme Gastbenutzer mit Lese- und Schreibrechte im Internet veröffentlichen…
Vorteil von WebDirect ist, wie bereits erwähnt, dass Sie ohne HTML/JavaScript/CSS Programmierkenntnisse, sondern einfach mit Ihrem vorhandenen FileMaker Wissen, Datenbank(en) im Internet veröffentlichen können.
Natürlich gibt es auch gravierende Nachteile…
WebDirect ist im Normalfall sau teuer! Claris, Herstellerfirma von FileMaker, verlangt pro Benutzer eine FileMaker Lizenz oder kassiert nach sogenannten Connections. Geht man von 10 gleichzeitigen WebDirect Benutzer aus, so benötigt man eine 10 Concurrent Connection Lizenz. Diese Concurrent Lizenzen sind in der Regel drei mal teurer als normale FileMaker Lizenzen. Und 10 Webseitenbenutzer sind ja nicht viel. Wenn Sie mit Ihrer Ferienhausvermietung erfolgreich sind, dann haben Sie hoffentlich (zu Stoßzeiten, wann alle Leute ihre Urlaube buchen) 1000 gleichzeitige Benutzer auf Ihrer Webseite.
Wollen Sie sich nicht auf 10 gleichzeitige, 20 gleichzeitige oder 50 gleichzeitige Benutzer einschränken, so benötigen Sie eine unlimitierte Lizenz. Das geht dann in Richtung FileMaker Site License und kostet – je nach Szenario – so viel wie ein Mittelklassewagen. Genaue Preise erfragen Sie beim Lizenzhändler ihrer Wahl.
Außerdem ist FileMaker WebDirect sehr ressourcenintensiv. Im Prinzip wird pro Benutzer am Server ein interner FileMaker Client (ohne Oberfläche) gestartet. Wenn da also 10 Benutzer gleichzeitig arbeiten, dann benötigt man hier schon einen gut ausgestatteten Server.
Der dritte große Nachteil ist, dass die WebDirect Seiten nicht von Suchmaschinen gelesen werden können. Das heißt, Sie haben das tollste Ferienhausangebot mit den besten Preisen, aber niemand wird Sie je per Google finden, da die WebDirect Seiten für Suchmaschinen unsichtbar sind.
Also, sobald Sie per Suchmaschine gefunden werden wollen, ist WebDirect tabu.
Beim der oben genannten Ferienhausvermietung wäre WebDirect beispielsweise optimal, wenn die ihre drei Hausbesitzer-Freund per Webbrowser ihre eigenen Häuser als verfügbar oder nicht verfügbar melden sowie Daten zu zukünftigen Urlaubern einsehen oder Abrechnungen anfordern können. Da kommen Sie dann theoretisch mit einer vier Benutzerlizenz aus (Sie+3 Freunde). Das kleinste FileMaker-Paket beginnt jedoch erst bei 5 User + Server.
Vermutlich würde bei diesem kleinen Szenario sogar eine einzelne Concurrent License reichen, wenn sich nicht alle gleichzeitig einloggen (wobei man die Concurrent Licenses nicht einzeln kaufen kann).
FileMaker WebDirect ist eine ganz tolle Sache die ich in vielen Kundenprojekten verwende. Aber sie eignet sich am besten für eine kleine, definierte Gruppe, die per Webbrowser auf FileMaker zugreift.
Für “normale Webseiten”, die im Internet veröffentlicht werden soll, ist es vollkommen ungeeignet. Das Schöne ist, dass man WebDirect mit den anderen Web-Publishing Varianten mischen kann, sodass man für administrative Aufgaben WebDirect zur Verfügung stellen kann und die eigene Webseite aber mit einer der anderen Möglichkeiten veröffentlicht wird.
Praxisbeispiel
Ich kann hier kein Beispiel verlinken, da, wie gesagt, WebDirect bei mir nur für Administrative und mit Passwort geschützte Zugänge in Frage kommt und nicht für öffentliche Internetseiten.
3. FileMaker Custom Web Publishing
Beim FileMaker Custom Web Publishing dient FileMaker im Prinzip nur als Datenbank. Der gesamte Webauftritt inkl. Abläufe wird in einer Programmiersprache wie PHP, Java, C#, Ruby, Python, JavaScript/Node oder ähnlichem neu programmiert.
FileMaker Layouts werden nicht genutzt, sondern die gesamte Oberfläche wird als HTML/CSS/JavaScript neu programmiert. Das ist einerseits viel Arbeit, andererseits hat man hier natürlich ganz andere (bessere) Möglichkeiten Layouts zu gestalten.
Die gesamte Businesslogik, die in FileMaker Scripts liegt, wird weitgehend ignoriert und sämtliche für den Webauftritt benötigte Funktionen werden neu programmiert. Es ist zwar möglich, einzelne FileMaker Scripts aufzurufen und so gewissen Abläufe durch FileMaker Scripts ablaufen zu lassen, aber die native Programmierung in PHP/Java/etc. ist um ein Vielfaches schneller.
In der Praxis mache ich bei solchen 96% des Codes in PHP/Java neu und rufe nur vereinzelt Scripts in FileMaker auf, beispielsweise um per E-Mail Anmeldebestätigungen mit PDF Anhang zu versenden. So kann der FileMaker Programmierer beispielsweise sich dann um die Formatierung der PDF-Dokumente kümmern.
Der Zugriff auf die FileMaker Datenbank erfolgt dabei per DataAPI, welche am FileMaker Server aktiviert werden muss.
Auch die FileMaker Data API lässt sich Claris prinzipiell bezahlen, jedoch bekommt man pro Benutzer und Jahr 24 GB Datenvolumen. Bei einem Mini-Standardserver mit 5 Benutzer sind das dann 120 GB jährlich und das Übertragen von Medienfelder wird nicht gezählt. Das reicht für 99,9% aller Anwendungen locker aus.
Vorteil des Custom Web Publishing ist, dass alle Daten live aus FileMaker ausgelesen oder zurückgeschrieben werden können.
Die Webseiten Layouts können (und müssen) neugestaltet werden, sodass man hübsche, ansprechende und responsive Webseiten gestalten kann, welche bei entsprechender Programmierung von Suchmaschinen gelesen werden können.
Die Nutzung der Data API selbst ist eher kompliziert, sodass fast niemand diese direkt nutzt. In der Regel verwendet man einen “Wrapper-Bibliothek”, welche den Zugriff mit einer geeigneten Programmiersprache stark vereinfacht. Siehe hierzu die momentan verfügbaren Libraries unter https://support.claris.com/s/article/data-api—admin-api-packages-wrappers-for-fm-17-x?language=en_US
Ich selbst nutze für eigene Projekte meistens die von mir programmierte Java Variante (die nicht auf der Liste oben zu finden ist). Diese können Sie kostenlos von https://github.com/schube/FileMaker-DataAPI-4-Java laden.
In meinen FileMaker und PHP-Schulungen nutzen wir die Bibliothek von INTER-Mediator.
Wenn Sie Interesse an FileMaker Schulungen haben, abonnieren Sie meinen Newsletter oben rechts, damit Sie keine Ankündigung verpassen!
In der Praxis findet man genug Entwickler, die zum Beispiel mit PHP eine individuelle Webseite gestalten können. Mit FileMaker haben die meisten Entwickler keine Erfahrung, denn die nutzen zu 99% MySQL. Ein Zugriff auf FileMaker sollte für einen guten PHP-Entwickler aber mithilfe der INTER-Mediator Bibliothek kein großes Problem sein.
Der Zugriff auf die FileMaker Data API ist prinzipiell schnell, aber auf eine MySQL Datenbank kann man 100- bis 1000-mal schneller zugreifen. Daher muss man Programmierer, die man erstmals an die FileMaker Data API ranlässt, warnen, mit den Abfragen sorgsam umzugehen und Daten zu cachen, damit das System performant bleibt.
Praxisbeispiele
Ein Projekt, welches mit Custom Web Publishing umgesetzt wurde (inkl. Caching) ist beispielsweise https://dinhard.biblioweb.ch
Oder als Webshop für ImmoBINGOOO unter https://bingooo.shop/immobingooo/
Unsere Ferienhausvermietung
Für unsere Ferienhausvermietung bedeutet das nun, dass wir eine wunderschöne Webseite mit PHP nach neuestem Stand der Technik und voll responsive programmieren. Die Urlaubsgäste können online direkt ein Haus buchen und per Kreditkarte bezahlen. Alle Daten landen live und sofort in FileMaker.
Durch Suchmaschinenoptimierung landen wir auf Position Eins bei Google und haben viele Anfragen. Wir implementieren daher ein vernünftiges Caching und freuen uns. Es war uns möglich, für dieses Projekt Programmierer zu finden, aber den Zugriff per FM Data API kennt kaum ein Entwickler und das hat die Suche etwas schwer gemacht.
Den FileMaker Server trauen wir uns kaum neu zu booten oder Updates einzuspielen, denn in dieser Zeit kann kein Kunde ein Ferienhaus buchen, sondern erhält nur eine Fehlermeldung.
4.SQL-Datenbank mit FileMaker ESS Zugriff
Die nächste Variante ist mit der Custom Web Publishing Variante verwandt – wieder programmiert man seine HTML-Seite und die Business Logik selbst in einer Programmiersprache wie PHP.
Die Daten kommen nun aber nicht direkt aus FileMaker, sondern werden aus einer SQL-Datenbank wie MySQL, MariaDB, Oracle SQL, MS SQL oder PostgreSQL gelesen bzw. dahin zurückgeschrieben.
FileMaker wiederum verbindet man per ESS-Technologie über ODBC mit der SQL-Datenbank. In FileMaker erscheinen die SQL-Tabellen wie Tabellen einer externen Datei und man kann darin Daten lesen, schreiben, importieren, exportieren etc. (mit kleinen Einschränkungen, zum Beispiel bei Medienfelder). Wie Sie ESS Einrichten habe ich hier erklärt.
Das hat mehrere Vorteile:
- Es gibt viele PHP/MySQL Entwickler – hier findet man leicht Dienstleister
- Schnell – Zugriff auf eine SQL Datenbank ist schnell
- Keine/Kaum Lizenzkosten – PHP und MariaDB lassen sich kostenlos nutzen.
- Auch an FileMaker sind keine Gebühren zu bezahlen!
- FileMaker Server unter Windows und Linux können kostenlose ODBC Treiber nutzen.
- FileMaker Server unter Mac benötigen jedoch kostenpflichtige ODBC Treiber von Actual Technogies (ca. 300 €).
- FileMaker Server muss nicht per Internet erreichbar sein. (Diese Aufgabe übernimmt der SQL Server).
Wie immer gibt es auch Nachteile:
- Die Daten müssen irgendwie von FileMaker in die SQL Datenbank kommen und umgekehrt.
- Sie müssen also einige Import/Export Scripts programmieren und regelmäßig ausführen.
- Die meisten Internetprovider mit so typischen 5 €/Monat-Paketen bieten zwar PHP und MySQL, erlauben aber keinen Zugriff per ODBC. Hier muss ein passender Provider ausgewählt werden.
- Die Konfiguration der ODBC Verbindung ist unter Umständen nicht ganz trivial (wobei ich das schon für Linux und für macOS beschrieben habe).
- Unter Umständen muss Ihre Firewall konfiguriert werden, um den ODBC Zugriff zu erlauben.
- Die ODBC Verbindung muss mittels SSL Zertifikat gesichert werden!
Unsere Ferienhausvermietung
Für unsere Ferienhausvermietung heißt das nun, dass wir die Webseite aus Szenario 3. FileMaker Custom Web Publishing weiternutzen, jedoch den Datenzugriffsteil austauschen, die FileMaker Data API hinausschmeißen und auf eine MariaDB SQL Datenbank setzen.
Die Webseite ist nun noch schneller als zuvor. Wir setzen keine exotischen Technologien (FM Data API) mehr ein sondern nutzen Standard PHP/MySQL bzw. MariaDB. Hierfür findet wir zig Programmierer, denn das ist deren täglich Brot.
Den Datenaustausch können wir selbst mit FileMaker Bordmittel locker programmieren.
FileMaker Server können wir rebooten wie wir wollen, denn die Webseite greift auf den SQL-Server beim Provider zu und ist immer online.
Wir sind glücklich 🙂
Das Rad nicht neu erfinden!
Ein weiteres Szenario, das in der Praxis oft eine Rolle spielt, lautet: Das Rad nicht neu erfinden!
Es gibt hunderttausende OpenSource Projekte, die alle möglichen Funktionen anbieten, beispielsweise das beliebte CMS WordPress mit seinen Millionen von Plugins.
Sehr viele dieser Projekte speichern die Daten in einer MySQL/MariaDB Datenbank, welche man meistens relativ einfach per ODBC auslesen kann. Daher, bevor man selbst etwas entwickelt oder beauftragt sollten Sie am besten mal bei GitHub vorbeischauen und prüfen, ob es nicht schon ein fertiges Projekt gibt, dass Sie nutzen können.
Achtung Updates
Angenommen, Sie installieren einen Open Source Webshop, wie beispielsweise PrestaShop und greifen direkt auf die SQL-Datenbank zu, dann werden Sie damit eine Zeitlang zufrieden arbeiten können, aber eines Tages installieren Sie ein Update, das die interne Datenbankstruktur ändert und dann klappen ihre Datenbankzugriffe per ODBC nicht mehr und Sie müssen nacharbeiten.
Der Punkt ist hier, dass die Anbieter solcher System nicht davon ausgehen, dass jemand direkt auf die SQL Daten zugreift und informieren Sie in der Regel nicht über solche Datenbankupdates in den Release Notes. Hier ist also Vorsicht geboten!
Das heißt, wenn Sie per FileMaker / ESS auf eine selbst programmierte SQL-Datenbank zugreifen, dann ist das kein Problem, denn dann wissen Sie ja selbst, ob und was Sie ändern. Wenn Sie aber eine bestehende Datenbank eines OpenSource Projektes “anzapfen”, so rechnen Sie hier früher oder später mit Problemen!
Praxisbeispiele
- Buchen Sie Tickets bei Princess for one Day. Zum Einsatz kommt MariaDB und FileMaker/ESS.
- Buchen Sie Konzertkarten in Wien. Zum Einsatz kommt MariaDB und FileMaker/ESS.
- Lernen Sie Klavier bei Austrian Master Classes. FileMaker und ESS!
- Als Schüler im Bundesland Salzburg können Sie hier Ihren Schülerausweis und das Jahres-Busticket bestellen: https://bestellung.s-pass.at/ Sie raten richtig – FileMaker und ESS.
Sie sehen, unterschiedliche Webseiten, Layouts und Designs. Alles ist möglich. Und dass im Hintergrund alles schließlich über FileMaker läuft sehen Sie als Endanwender nie.
5.Beliebige Datenhaltung mit FileMaker REST Zugriff
Kommen wir nun noch zur letzten Variante.
Wieder haben wir eine Webseite programmiert, die Daten werden irgendwie gespeichert. Sei es in einer SQL Datenbank, wie im Szenario 4, sei es in einer No-SQL Datenbank wie MongoDB oder in einfachen Textdateien. Das Wie spielt keine Rolle.
Wichtig ist, dass die Webseite eine REST-API zur Verfügung stellt.
Mittels dieser REST-API können Daten zwischen der Webseite und einem Fremdsystem, in unserem Fall FileMaker, ausgetauscht werden und zwar lesend als auch schreibend.
In FileMaker kann man mit dem Befehl Aus URL einfügen… ganz ohne Plugins diese REST-APIs nutzen. Wie so etwas funktioniert habe ich unter cURL Beispiele für FileMaker anpassen beschrieben.
Vorteil ist, dass die meisten Open Source Projekte sowie kommerziellen Anbieter für ihre Dienste REST-APIs zur Verfügung stellen und diese meistens gut dokumentiert sind.
Die APIs sind dafür da, dass sie von Fremdsystem genutzt werden und bleiben bei Updates meistens stabil, das heißt, es kommen maximal Funktionen dazu, aber es werden keine bestehenden Funktionen geändert.
Bei Szenario 4, wo man direkt auf die SQL Datenbank zugreift, ist bei Updates nicht immer gewährleistet, deshalb habe ich oben eine Warnung hinzugefügt.
Nachteil beim REST-Zugriff aus FileMaker Sicht ist der meist etwas höhere Programmieraufwand im Vergleich zu ODBC, um die Daten zwischen dem Fremdsystem und FileMaker auszutauschen.
Dafür brauchen Sie aber auch keine umständliche ODBC-Konfiguration sondern nutzen das Standard HTTP(S) Protokoll, das durch jede Firewall problemlos durchgeht.
Unsere Ferienhausvermietung
Unsere Ferienhausvermietung-Webseite können wir aus Szenario 4, also Web-Publishing mit SQL, unverändert übernehmen. Die Daten belassen wir in der SQL-Datenbank, das Ganze funktioniert ja prächtig.
Zusätzlich erweitern wir die Webseite um eine REST-API und binden FileMaker mittels Aus URL einsetzen… daran an.
Wir testen die Kommunikation zwischen FileMaker und der Webseite – alles klappt!
Die FileMaker ODBC Verbindung wird nun nicht mehr benötigt. Wir löschen den direkten SQL-Datenbankzugang, löschen die Firewall-Regel, müssen uns um keine SSL-Zertifikate für die ODBC Verbindung mehr kümmern und können die ODBC Treiber vom FileMaker Server löschen. Das System ist schlanker und sicherer geworden, da der direkte Datenbankzugriff auf SQL nicht mehr möglich ist.
Fazit
Es gibt viele Möglichkeiten, wie man FileMaker zum Web-Publishing einsetzen kann. Jede Variante hat ihre eigenen Vor- und Nachteile. Das schöne ist, dass sich alles mischen lässt und sich nichts ausschließt.
In der Praxis verwende ich fast immer Custom Web Publishing mit SQL. Dazu gibt es dann, je nach Anforderung, noch eine REST-API. Der Zugriff per FileMaker erfolgt dann per REST/JSON oder eben per ODBC/ESS.
Kommentieren und Diskutieren