Text
Teil Zwei der Kanban Entwicklung in FileMaker, Umstellung von GET auf POST
Die Evolution einer Kanban-Ansicht in FileMaker: Vom GET zum POST In der kontinuierlichen Weiterentwicklung von Arbeitsprozessen und deren Darstellung in FileMaker ergibt sich oft die Notwendigkeit, bestehende Lösungen zu optimieren und an neue Anforderungen anzupassen. Genau dieser Gedanke begleitete die Entwicklung der Kanban-Ansicht, die sich ursprünglich auf GET-Parameter zur Datenübertragung stützte, nun aber auf POST umgestellt wurde. Ein scheinbar kleiner Wechsel, der jedoch große Auswirkungen hat – sowohl auf die Performance als auch auf die Flexibilität der Anwendung. Der wichtigste Aspekt, alle weiteren Daten die der Kunde jetzt in noch in den Kacheln sehen möchte, kann ich ohne Probleme übertragen. Ob 100 oder nur 50 Aufgaben. Das System benötigt keinerlei Vorfilterung innerhalb von FileMaker. Ursprünglich wurde die Kanban-Ansicht über eine URL-basierte GET-Abfrage mit Daten versorgt. Die Vorteile lagen auf der Hand: einfache Implementierung, transparente Debugging-Möglichkeiten und eine schnelle Integration in den bestehenden Webviewer von FileMaker. Doch mit wachsendem Datenvolumen und steigenden Anforderungen an die übertragene Information stieß diese Methode an ihre Grenzen. Die maximale URL-Länge wurde zu einem Problem, und die Strukturierung komplexer Daten – insbesondere in Bezug auf Statusfarben, Aufträge und historische Änderungen – wurde zunehmend unübersichtlich. Die logische Konsequenz war der Wechsel auf eine POST-Übertragung, die nicht nur größere Datenmengen bewältigen kann, sondern auch eine flexiblere Handhabung ermöglicht. Dabei stellte sich heraus, dass die Umstellung zwar in der Theorie simpel erschien, in der Praxis aber einige Herausforderungen mit sich brachte. FileMaker musste so konfiguriert werden, dass die Daten nicht mehr direkt als URL-Parameter übergeben wurden, sondern als strukturierte POST-Daten in die Webanwendung flossen. Das bedeutete, dass die gesamte Datenkette angepasst werden musste – von der Generierung der Werte in FileMaker über die Verarbeitung in PHP bis hin zur Darstellung im Webviewer. Nach einigen Anpassungen und Tests zeigte sich schnell: Die POST-Methode brachte nicht nur eine sauberere und robustere Datenübertragung mit sich, sondern auch eine spürbare Verbesserung der Ladegeschwindigkeit. Während GET oft dazu führte, dass die URL unnötig aufgebläht wurde, ermöglicht POST eine strukturierte und sichere Übermittlung, die auch größere Datensätze problemlos verarbeitet. Gerade im Kontext eines Kanban-Boards mit zahlreichen Aufgaben, Statusänderungen und Nutzerinteraktionen ist das ein entscheidender Vorteil. Ein besonders interessanter Nebeneffekt der Umstellung war die Vereinfachung der Datenstruktur. Während bei der GET-Variante viele Variablen direkt in der URL codiert und dekodiert werden mussten, erlaubt die POST-Methode eine klarere Trennung zwischen Client und Server. Die Farbmarkierungen, Statushistorien und Task-IDs ließen sich nun effizienter verarbeiten, und die Fehlersuche gestaltete sich deutlich angenehmer. Zudem eröffnete sich durch die Umstellung die Möglichkeit, noch weitere Daten ohne zusätzliche URL-Komplikationen zu übertragen – ein Schritt, der langfristig gesehen weitere Optimierungen ermöglichen wird. Rückblickend zeigt diese Anpassung einmal mehr, wie wichtig es ist, Prozesse stetig zu hinterfragen und weiterzuentwickeln. Was gestern noch gut funktionierte, kann heute durch eine andere Herangehensweise erheblich verbessert werden. Die Migration von GET zu POST mag auf den ersten Blick nur eine technische Feinheit sein, doch in der Praxis trägt sie entscheidend zu einer performanten und skalierbaren Lösung bei. Die Kanban-Ansicht in FileMaker ist damit nicht nur flexibler, sondern auch zukunftssicherer geworden – und das ist letztlich das Ziel jeder guten Softwareentwicklung. Der eigentliche Vorgang innerhalb von FileMaker ist klar. Sammeln der Daten per Schleife unter Beachtung der spezifischen Vorstellungen und Kundenwünsche. Das eigentlich interessante Prozedere, der Befehl aus URL einfügen. Angabe der URL mit dem Ziel der aufgerufenen PHP-Datei. Die cURL Eintragungen. Das Endergebnis. Durch viele Tests etwas durcheinander. Grundsätzliche Farbmuster zum erkennen der im Zusammenhang stehende Aufgaben und auf der linken Seite der Kacheln befindet sich ein Farbmuster das den Verlauf durch die verschiedenen Status-Änderungen zeigt.
0 notes
Photo
Die Verwaltung von Aufgaben kann schnell unübersichtlich werden, wenn viele Prozesse gleichzeitig laufen und verschiedene Mitarbeiter involviert sind. Eine klassische Methode zur Visualisierung solcher Abläufe ist die Kanban-Tafel, die durch ihre intuitive Struktur einen schnellen Überblick über den Status der einzelnen Aufgaben bietet. Doch während viele Tools auf dem Markt existieren, soll in diesem Artikel eine maßgeschneiderte Lösung direkt in FileMaker realisiert werden – mit Hilfe von PHP und JavaScript in einem Webviewer. Es gibt natürlich eine FileMaker-Eigene Implementierung über die Add-ons. Mir persönlich ist diese Möglichkeit aber zu eingeschränkt. So sind die Tafeln nicht Dynamisch, ich kann z.B. keine Symbole oder Bilder mit integrieren und die Steuerung der Abläufe ist nicht richtig konsistent. Deshalb die Idee, ich setze das einfach mit PHP, Java-Script über den WebViewer von FileMaker um. Das Ziel ist es, eine interaktive Kanban-Tafel direkt in FileMaker zu integrieren, die alle relevanten Aufgaben übersichtlich darstellt und es ermöglicht, diese per Drag & Drop zwischen den verschiedenen Status-Spalten zu verschieben. Diese Statusänderungen sollen dann automatisch an FileMaker zurückgemeldet werden, sodass keine doppelte Pflege von Daten notwendig ist. Die Techniken dahinter: -PHP als Schnittstelle zur Verarbeitung und Bereitstellung der Daten. -JavaScript mit jQuery UI für die interaktive Drag & Drop-Funktionalität. -FileMaker-Skripte, um die Änderungen zurück in die FileMaker-Datenbank zu schreiben. Als erstes müssen wir uns klar werden wie die Daten an das PHP-Script übergeben werden. Ich persönlich nutze gern die Möglichkeit Einträge mit einem Pipe getrennt zu übertragen. Das lässt sich in FileMaker wunderbar über eine Schleife realisieren. In meinem Beispiel werden verschiedene ID,s übertragen. Damit die Kanban-Ansicht ihre Inhalte aus FileMaker beziehen kann, müssen die relevanten Daten über eine URL in PHP übergeben werden. Dazu werden die folgenden Parameter als GET-Request an eine PHP-Datei gesendet: projects: Enthält die Auftragsnummern. staff: Enthält die zugeordneten Mitarbeiter. anlage: Enthält die Referenz zur Anlage. status: Gibt den aktuellen Status der Aufgabe an (z. B. "In Planung" oder "Erledigt"). task: Enthält die eindeutige Task-ID (Aufgaben ID) zur Identifikation. image: Gibt den Namen des Symbols an, das in der Kanban-Karte angezeigt werden soll. Meine fertige URL schaut ungefähr so aus: https://maeine_url_.de/cap/kanban.php?projects=24944|24945|24946&staff=STA020|STA023|STA025&anlage=B14C380C-4329-E54B-ACA1-B2054C5D4B3A|B14C380C-4329-E54B-ACA1-B2054C5D4B3A&status=Erledigt|In Planung|Material bestellt&task=TSK004729|TSK004730|TSK004731&image=Blau|Gelb|Rot Der Weg diese zu generieren sollte klar sein. Per Schleife durch die Aufgaben, entweder gefiltert nach Datum oder Zeitraum etc. Nun wird dieser Wert in eine Globale Variable geschrieben z.B. $$URL. Dann der FileMaker Befehl, aus URL einfügen. Dabei generieren wir eine Variable z.B. $$URL_WEBVIEWER. Diese kommt dann als Inhalt in unseren Webviewer den wir uns innerhalb eines FileMaker-Layouts platzieren. Unser Script:
```php <?php // Header für UTF-8 Encoding header("Content-Type: text/html; charset=UTF-8"); // Daten aus der URL holen $projects = isset($_GET['projects']) ? explode('|', $_GET['projects']) : []; $staff = isset($_GET['staff']) ? explode('|', $_GET['staff']) : []; $anlage = isset($_GET['anlage']) ? explode('|', $_GET['anlage']) : []; $status = isset($_GET['status']) ? explode('|', $_GET['status']) : []; $task = isset($_GET['task']) ? explode('|', $_GET['task']) : []; $images = isset($_GET['image']) ? explode('|', $_GET['image']) : []; // Basis-URL für die Icons $imageBaseUrl = "http://Deine_URL.de/GoogleMarkers/"; // Status und Farben definieren $status_colors = [ "Material bestellt" => "#FFD700", // Gelb "In Planung" => "#FFA500", // Orange "Verplant" => "#FF4500", // Dunkelorange "Ausgeführt" => "#008000", // Grün "Angebot folgt" => "#FF0000", // Rot "Erledigt" => "#808080" // Grau ]; // Spalten für das Kanban-Board $columns = ["Material bestellt", "In Planung", "Verplant", "Ausgeführt", "Angebot folgt", "Erledigt"]; // Aufgaben nach Status sortieren $tasks_by_status = []; foreach ($status as $index => $task_status) { $tasks_by_status[$task_status][] = [ "id" => $task[$index] ?? "TSK-Unbekannt", "project" => $projects[$index] ?? "Unbekannt", "staff" => $staff[$index] ?? "Kein Mitarbeiter", "anlage" => $anlage[$index] ?? "Keine Anlage", "image" => isset($images[$index]) && !empty($images[$index]) ? $imageBaseUrl . $images[$index] . ".png" : "", "status" => $task_status ]; } ?> ``` ```html <!DOCTYPE html> Aufgaben Board body { font-family: Arial, sans-serif; background-color: #f4f4f4; } .kanban-board { display: flex; justify-content: space-between; padding: 20px; gap: 10px; } .kanban-column { width: 16%; min-height: 400px; background: #ddd; padding: 10px; border-radius: 5px; display: flex; flex-direction: column; align-items: center; } .kanban-card { background: white; padding: 10px; margin-bottom: 10px; border-radius: 5px; box-shadow: 2px 2px 5px rgba(0, 0, 0, 0.1); cursor: grab; width: 90%; text-align: center; transition: background-color 0.3s; position: relative; } .kanban-card img { position: absolute; top: 5px; left: 5px; width: 20px; height: 20px; } .sortable { width: 100%; min-height: 50px; } .sortable-placeholder { background: #ccc; height: 50px; border-radius: 5px; margin-bottom: 10px; width: 90%; }
Aufgaben Board
<?php foreach ($columns as $column): ?>
">
<?= htmlspecialchars($column) ?>
"> <?php if (!empty($tasks_by_status[$column])): ?> <?php foreach ($tasks_by_status[$column] as $task): ?>
" data-task-id="<?= htmlspecialchars($task['id']) ?>" data-status="<?= htmlspecialchars($task['status']) ?>" style="background-color: <?= $status_colors[$column] ?? '#ffffff' ?>;"> <?php if (!empty($task['image'])): ?> " alt="Symbol"> <?php endif; ?> Auftrag: <?= htmlspecialchars($task["project"]) ?> Anlage: <?= htmlspecialchars($task["anlage"]) ?> Mitarbeiter: <?= htmlspecialchars($task["staff"]) ?>
<?php endforeach; ?> <?php endif; ?>
<?php endforeach; ?>
// Status und zugehörige Farben var statusColors = { "Material bestellt": "#FFD700", // Gelb "In Planung": "#FFA500", // Orange "Verplant": "#FF4500", // Dunkelorange "Ausgeführt": "#008000", // Grün "Angebot folgt": "#FF0000", // Rot "Erledigt": "#808080" // Grau }; $(document).ready(function() { console.log(" jQuery und jQuery-UI wurden geladen."); $(".sortable").sortable({ connectWith: ".sortable", placeholder: "sortable-placeholder", revert: true, start: function(event, ui) { console.log("Drag gestartet für:", ui.item.attr("id")); }, stop: function(event, ui) { var newStatus = ui.item.closest(".kanban-column").attr("id"); var taskId = ui.item.attr("id"); console.log("Aufgabe verschoben:", taskId, "Neuer Status:", newStatus); // Neue Farbe setzen if (statusColors[newStatus]) { ui.item.css("background-color", statusColors[newStatus]); } // FileMaker-Skript über fmp:// URL aufrufen var fileMakerScriptURL = "fmp://$/Deine_Datei?script=UpdateTaskStatus¶m=" + encodeURIComponent(taskId + "|" + newStatus); console.log(" FileMaker-Skript aufrufen:", fileMakerScriptURL); // WebViewer öffnet FileMaker-Skript window.location = fileMakerScriptURL; } }).disableSelection(); }); ``` Die Updates der Änderungen werden über ein kleines weiteres PHP Script abgefangen. ```php <?php // POST-Daten empfangen $taskId = $_POST['id'] ?? null; $newStatus = $_POST['status'] ?? null; if ($taskId && $newStatus) { // Hier würdest du die Daten in FileMaker oder einer Datenbank speichern file_put_contents("kanban_log.txt", "ID: $taskId -> $newStatus\n", FILE_APPEND); echo "OK"; } else { echo "Fehler: Ungültige Daten"; } ?> ```
Führe ich nun eine Änderung durch, wird das FileMaker-Script -UpdateTaskStatus- aufgerufen, es übergibt als Parameter die Task-ID und den neuen Status. Damit habe ich natürlich die Möglichkeit im Hintergrund sofort die Änderungen zu verarbeiten. Also, neues Fenster, 1x1 px, bei -30000px. Dort suche ich die Task-ID und ändere den Status. Fenster schließen und der Vorgang ist abgeschlossen.
0 notes
Photo
FileMaker bietet mit Portalen eine gute Möglichkeit, Listen anzuzeigen. Doch wenn der Platz begrenzt ist, stößt man schnell an Grenzen. Ein Web Viewer bietet hier eine flexible Lösung, um Inhalte dynamisch darzustellen – inklusive automatischer Anpassung der Schriftgröße und Zeilenhöhe! Hintergrund, ein Kunde hat Formulare die mit Nadeldrucker geschrieben werden. Es ist also nicht möglich die Struktur des Ausdruckes zu ändern. Alles muss auf diese Seite. Bisher war es kein Problem, es gab für bestimmte Vorgänge einen Ansprechpartner mit Telefonnummer. Nun können es aber auch 2 oder drei Ansprechpartner sein. Was nun? Dann muss die Schriftart dynamisch kleiner werden. Das ganze geht auch mit FileMaker, aber wie bekomme ich dann das Portal dynamisch kleiner. Ich weiss nicht. Also bin ich auf die Idee gekommen, die Anzeige über den WebViewer laufen zu lassen. Dabei ist es ein ganz einfacher Prozess: 1.bauen einer Liste in einer Variablen, die Einträge Namen und Telefon 1 und Telefon zwei werden ganz einfach über einen Pipe getrennt. 2. Wir legen unds ein WebViewer in das Drucklayout, benannt z.B. -Telefonliste- , als URL bzw. Inhalt eine globale Variable, z.B. $$HTML. 3. Wir gehen wieder in unser Script, legen eine Variable an -$$HTML- die se hat folgenden Inhalt:
Set Variable [ $$html ; "data:text/html," & "" & Char(10) & "<html>" & Char(10) & "<head>" & Char(10) & " <meta charset='UTF-8'>" & Char(10) & " <style>" & Char(10) & " body {" & Char(10) & " font-family: Arial, sans-serif;" & Char(10) & " text-align: left;" & Char(10) & " margin: 5px;" & Char(10) & " }" & Char(10) & " pre {" & Char(10) & " font-family: monospace;" & Char(10) & " white-space: pre-wrap;" & Char(10) & " font-size: " & Case ( ValueCount ( $$namen_liste ) ≤ 4 ; "8px;" ; ValueCount ( $$namen_liste ) = 5 ; "7px;" ; ValueCount ( $$namen_liste ) = 6 ; "6px;" ; "5px;" ) & Char(10) & " margin-bottom: 2px;" & Char(10) & " line-height: " & Case ( ValueCount ( $$namen_liste ) ≤ 4 ; "10px;" ; ValueCount ( $$namen_liste ) = 5 ; "8px;" ; ValueCount ( $$namen_liste ) = 6 ; "6px;" ; "5px;" ) & Char(10) & " }" & Char(10) & " </style>" & Char(10) & "</head>" & Char(10) & "<body>" & Char(10) & "<pre>" & Substitute ( $$namen_liste ; "¶" ; Char(10) ) & "</pre>" & Char(10) & "</body>" & Char(10) & "</html>" ]
Wenn jetzt das Script ausgeführt wird, haben wir dynamisch die Größe der Schriftart und der Zeilenabstände. Wenn es noch nicht passt, muss nur an dieser Stelle geändert werden. Für mich eine kleine perfekte Lösung um das Platzproblem zu lösen.
0 notes
Text
Nach langer Überlegung, schaut das Ergebnis nun doch fein aus.. ZUGFeER mit FileMaker .

0 notes
Text
Der Wahnsinn... ZUGFeRD mit FileMaker.

Linke Seite ist validiert und Funktioniert wunderbar. Rechte Seite will nocht nicht.
0 notes
Text
Die unsichtbare Macht der Arbeitstabellen in FileMaker: Optimierung und Effizienz
Die unsichtbare Macht der Arbeitstabellen in FileMaker: Optimierung und Effizienz In der Welt von FileMaker gibt es unzählige Ansätze, Daten zu verarbeiten und Aufgaben zu automatisieren. Doch nicht alle Ansätze sind gleich effizient – insbesondere wenn es um die Benutzererfahrung und die Systemperformance geht. Ein Beispiel, das oft diskutiert wird, ist der Umgang mit Layout-Wechseln, Portalnutzung und Fenstermanagement. Während manche Entwickler munter Layouts im Vordergrund wechseln und Portale als Arbeitstabellen verwenden, gibt es effizientere und sauberere Ansätze. Eine Methode, die ich seit Jahren erfolgreich einsetze, basiert auf der Verwendung von unsichtbaren Arbeitstabellen in Kombination mit strategisch positionierten Fenstern. Was sind Arbeitstabellen? Arbeitstabellen sind Tabellen oder Layouts, die ausschließlich dazu dienen, Datenoperationen durchzuführen, ohne dass diese Prozesse für den Benutzer sichtbar sind. Sie sind ideal, um: • Schleifen durchzuführen, • Temporäre Werte zu speichern, • Daten zu berechnen oder zu transformieren, bevor sie dem Benutzer präsentiert werden. Ich nutze dafür gewöhnlich die Tabellen, die nicht die Grundbezeichnung haben. Bei mir in der UML-Ansicht haben diese den Namen der auch als Tabellen-Name fungiert. Diese werden für die Layouts im Anker Bojen Prinzip angeordnet und erhalten andere Namen. Mein Ansatz: Unsichtbare Fenster für Arbeitstabellen Um die Benutzeroberfläche (UI) stabil und flackerfrei zu halten, setze ich unsichtbare Fenster für meine Arbeitstabellen ein. Der Trick: Diese Fenster werden außerhalb des sichtbaren Bereichs des Bildschirms geöffnet. Konkret arbeite ich mit Fenstern, die folgende Parameter haben: • Größe: 1x1 Pixel • Position: -30000 x -30000 Pixel (außerhalb des sichtbaren Bereichs) Vorteile dieses Ansatzes 1. Keine UI-Störungen: Da das Fenster unsichtbar ist, bleibt die Hauptoberfläche stabil. Es gibt kein Flackern oder Springen zwischen Layouts, das den Benutzer irritieren könnte. 2. Performance-Optimierung: Da die Hauptoberfläche nicht ständig aktualisiert wird, bleibt die Performance selbst bei umfangreichen Operationen hoch. 3. Klare Trennung: Arbeitstabellen bieten eine logische Trennung zwischen Backend-Prozessen und der UI. Dies erleichtert Debugging und Wartung erheblich. 4. Flexibilität: Dieser Ansatz ermöglicht es, komplexe Operationen durchzuführen, ohne das aktuelle Layout verlassen zu müssen. Besonders nützlich, wenn Daten aus mehreren Quellen aggregiert oder umfangreiche Berechnungen durchgeführt werden. Der Kontrast: Wechsel zwischen Layouts und Portale als Arbeitstabellen Viele Entwickler verwenden die Hauptlayouts oder Portale, um ihre Datenoperationen durchzuführen. Während dies auf den ersten Blick praktisch erscheinen mag, birgt es einige Nachteile: • Flackern der UI: Jeder Wechsel des Layouts führt dazu, dass der Benutzer das Gefühl hat, dass „etwas passiert“. Dies kann störend wirken. • Performance-Verlust: Layoutwechsel erfordern Ressourcen, da FileMaker jedes Layout erneut rendert. • Fehleranfälligkeit: Die Verwendung von Portalen als Arbeitstabelle kann zu unvorhersehbaren Seiteneffekten führen, insbesondere wenn Benutzeraktionen die Daten in den Portalen beeinflussen. Beispiele aus der Praxis 1. Massendaten-Update: Ein Szenario, in dem mehrere Datensätze auf Basis von Bedingungen aktualisiert werden müssen. Mit einer Arbeitstabelle kann ich eine Schleife im unsichtbaren Fenster ausführen, die Änderungen vornehmen und abschließend die Ergebnisse im Hauptlayout anzeigen. 2. Komplexe Berechnungen: Bei der Berechnung von aggregierten Werten oder der temporären Erstellung von Berichten arbeite ich in der Arbeitstabelle und zeige am Ende nur das Endergebnis an. Fazit: Sauber, effizient und nutzerfreundlich Die Verwendung von unsichtbaren Arbeitstabellen und Fenstern ist ein leistungsstarker Ansatz, um Datenoperationen in FileMaker durchzuführen, ohne die Benutzererfahrung zu beeinträchtigen. Im Vergleich zum klassischen Layoutwechsel oder der Portalnutzung bietet dieser Ansatz klare Vorteile in Bezug auf Stabilität, Performance und Wartbarkeit. Wenn du bisher noch keine Arbeitstabellen genutzt hast, probiere es aus – du wirst überrascht sein, wie viel angenehmer sich deine Anwendungen für die Benutzer anfühlen!
0 notes
Text
ZUGFeRD Rechnung mit FileMaker
Was ein Spaß, ZUGFeRD Rechnung mit FileMaker. Heute über das MBS-Plugin. Eine saubere und überschaubare Arbeit. Kleiner Bericht darüber folgt in den nächsten Tagen. Wer mehr Erfahren will: [www.filemaker-experts.de](https://www.filemaker-experts.de)

0 notes
Photo
Grundlegende Fehler bei der Nutzung von Formeln in FileMaker – und wie man sie vermeidet Formeln sind in FileMaker ein mächtiges Werkzeug, das eine Vielzahl von Funktionen und Berechnungen ermöglicht. Doch die unsachgemäße Nutzung von Formeln kann schnell zu erheblichen Performance-Problemen und schwer zu wartenden Datenbanklösungen führen. Heute will ich diese Problematik einmal beleuchten. 1. Ungespeicherte Berechnungen überstrapazieren Eine ungespeicherte Berechnung wird jedes Mal neu berechnet, wenn ein Datensatz angezeigt oder referenziert wird. Das bedeutet, dass komplexe Berechnungen in großen Tabellen die Leistung massiv beeinträchtigen können. Beispiel: Eine Formel wie Sum(Bestellungen::Betrag) wird jedes Mal neu berechnet, wenn der Kunde angezeigt wird. Lösung: • Verwende gespeicherte Felder, wenn die Werte sich nicht ständig ändern. • Nutze Skripte, um Berechnungsergebnisse in einem statischen Feld zu speichern, das nur bei Bedarf aktualisiert wird. 2. Verschachtelte und komplexe Formeln Lange verschachtelte Formeln können schwer zu lesen, zu warten und vor allem langsam sein. FileMaker muss jeden Teil einer komplexen Formel bei jeder Neuberechnung analysieren. Beispiel: If( Rechnungen::Status = "Bezahlt"; Rechnungen::Summe * 0.19; If(Rechnungen::Status = "Offen"; Rechnungen::Summe * 0.25; 0) ) Lösung: • Teile komplexe Formeln in mehrere einfache Schritte auf. • Verwende Hilfsfelder oder Skripte, um Zwischenberechnungen durchzuführen. Zumal in diesem Beispiel eine einfache Formel, im deutschen FileMaker setzeVar(), häufig die Beste Lösung ist. Gerade Anfänger scheuen sich aber diese zu verwenden weil, diese unübersichtlich erschein. Kleiner Tipp am Rande, ich habe die immer als formatierte Vorlage in meinem Textexpander. Wenn ich das -$var- eintippe, erscheint das: SetzeVar ( [ Var1 = Ausdruck1 ; Var2 = Ausdruck2... ] ; Rechenanweisung ) Einfach sofort zu erkennen was gemeint ist, so ist auch die Nutzung super übersichtlich. 3. Dynamische Formeln in Listen und Tabellen In Layouts, die viele Datensätze gleichzeitig anzeigen (z. B. Tabellenansichten), werden ungespeicherte Formeln für alle angezeigten Datensätze gleichzeitig berechnet. Dies führt zu merklichen Verzögerungen. Beispiel: Ein berechnetes Feld zeigt den Namen eines verbundenen Objekts, etwa Bestellungen::Kunden::Name. Lösung: • Verwende Lookup-Felder, um Werte aus verbundenen Tabellen einmalig zu kopieren. • Zeige in der Tabellenansicht nur unbedingt notwendige Daten an. 4. Fehlende Indizes Indizes sind entscheidend für die Geschwindigkeit von Berechnungen, insbesondere bei Relationen, Suchen und Filtern. Ohne Indizes dauert das Durchsuchen großer Tabellen erheblich länger. Beispiel: Ein Beziehungsschlüssel wie _test(Artikel::Name) ist nicht indizierbar. Lösung: • Verwende indizierbare Felder als Beziehungsschlüssel. • Füge Hilfsfelder hinzu, die den indizierten Wert speichern (z. B. ein zusätzliches Feld NameKlein mit der gespeicherten Formel Lower(Name)). 5. Formeln statt Skripte Oft werden Berechnungen in Formeln realisiert, obwohl Skripte besser geeignet wären. Skripte bieten die Möglichkeit, Berechnungen gezielt auszuführen und Ergebnisse zu speichern, ohne die Performance dauerhaft zu belasten. Beispiel: Ein Feld mit der Formel LetzteAktualisierung = Max(Änderungen::Zeitstempel) wird jedes Mal berechnet, wenn der Datensatz angezeigt wird. Lösung: • Verwende ein Skript, das das Feld bei Änderungen aktualisiert. • Nutze Skript-Trigger, um Werte bei Benutzeraktionen zu berechnen. 6. Fehlerhafte Verwendung von globalen Feldern Globale Felder sind hilfreich, aber oft werden sie für falsche Zwecke eingesetzt, was zu Performance-Problemen führen kann. Beispiel: Ein globales Feld wird in einer Beziehung verwendet, um dynamische Filter zu setzen. Lösung: • Prüfe, ob ein Skript geeigneter ist. • Verwende globale Felder nur für Werte, die sich selten ändern oder systemweit benötigt werden. Häufig nutzte ich diese nur um einen Filter zu setzen. Im allgemeinen machen diese Felder wenig Sinn. 7. Übermäßige Nutzung von Aggregatfunktionen Funktionen wie Sum, Count oder List sind praktisch, können aber bei großen Datenmengen problematisch sein, insbesondere wenn sie über mehrere Relationen hinweg berechnen. Beispiel: Sum(Bestellungen::Gesamtbetrag) Wird für jeden Kunden bei jedem Zugriff neu berechnet. Lösung: • Nutze Zwischenspeicher, z. B. ein Feld, das bei Änderungen in Bestellungen per Skript aktualisiert wird. • Verwende Statistiktabellen oder Berichte, um Aggregatwerte gezielt zu berechnen. (Aber auch hier ist Vorsicht angebracht, nutze lieber ein PHP Script, baue die Anzeige über ein HTML im WebViewer) 8. Übersehen von Feldtypen Manchmal werden Berechnungen fehlerhaft und dadurch zur echten Bremse, weil der Feldtyp nicht passt – etwa bei der Verarbeitung von Text als Zahl oder umgekehrt. Lösung: • Stelle sicher, dass die Feldtypen korrekt definiert sind (z. B. Zahlenfelder für numerische Berechnungen). 9. Layoutformel als neues Futures Layoutformeln sind eine echte Erleichterung. Mal schnell einen Wert in einem Layout darstellen, kein Feld, kein Script, keine globale Variable. Aber mit jeder Erleichterung für den Entwickler erkauft man sich ein negativen Punkt. In unserem Fall die Performance. 10. Bedingte Formatierungen in Listenansichten. Ja, wer bis hier gelesen hat, kann sich den Rest denken. Die Liste mit 20000 Datensätzen öffnet sich und FileMaker rechnet jetzt erstmal brav die Bedingungen durch um z.B. einen Farbton eines Symbols zu ändern. Bei kleinen Datenmengen überhaupt kein Problem, aber bei vielen Werten sollte es anders gemacht werden. Wie gehts auch anders? Eine extra Tabelle für Symbole, diese wird je nach Status über eine mit dem Status in Verbindung stehende Referenz verknüpft. Dann halte ich z.B. das Symbol einmal als grünes Symbol vor, einmal als gelbes, einmal als rotes Symbol. Das lässt sich natürlich gewaltig aufblähen, macht viel Arbeit, aber es bringt echten Performance-Schub. Fazit: Verwende wenig bis keine Formeln Es ist einfach wichtig wenige Formeln zu verwenden. Klar ist der Aufwand für jede Berechnung ein Script zu starten enorm, aber es bringt den Unterschied. Ich habe gerade letztens für ein Unternehmen arbeiten dürfen. Die Datenbank, eine Datenbank mit 20 Jähriger Historie. Die Anforderung des Auftraggebers, Performance-Probleme zu beheben. Aber der Erste Blick in die Tabellen zeigte das ganze Ausmass, 2/3 der Tabellen bestanden aus Formeln. Was will ich da noch retten? Eigentlich ein Fall für die Tonne. Abhilfe konnten teilweise Auslagerungen in Server-Scripts bringen, aber das grundsätzliche Problem konnte nicht behoben werden. Was sind deine Erfahrungen mit Formeln in FileMaker? Teile deine Gedanken und Tipps in den Kommentaren!
0 notes
Photo
Heute habe ich das perfekte Beispiel, für das Gegenteil des Anker Bojen-Prinzip in die Hände bekommen. Mein Kunde hat sich eine wirklich tolle Datenbank gebaut, schnell, funktionell und recht nett anzuschauen. Nur in die Datenbankstruktur darf ich kaum schauen. Die Struktur zeigt eine sehr komplexe und dicht miteinander verbundene Datenbankstruktur, die das genaue Gegenteil des Anker-Bojen-Prinzips in FileMaker darstellt. Es ist klar zu erkennen, wir erkennen nichts. Während das Anker-Bojen-Prinzip auf Modularität, Flexibilität und klare Beziehungen setzt, ist diese Struktur unübersichtlich und schwer nachvollziehbar. Hier sind die wesentlichen Merkmale und Probleme dieser Art von Struktur: 1. Unübersichtlichkeit und Komplexität • Die Datenbank ist überladen mit Beziehungen zwischen Tabellen, die sich über mehrere Ebenen hinwegziehen. Es gibt keine klare Trennung zwischen den Modulen, wodurch es schwer fällt, die Daten und deren Beziehungen auf Anhieb zu verstehen. • Tabellen wie Rechnungspositionen, Auftragspositionen, Angebotspositionen speichern ähnliche Daten, aber in unterschiedlichen Kontexten. Die Beziehungen zwischen diesen Tabellen sind nicht sofort erkennbar und erschweren die Nachvollziehbarkeit. 2. Fehlende Modularität • Es fehlt an Modularität. Zentrale Tabellen wie Kunden, Aufträge und Rechnungen sind nicht klar als Anker definiert. Sie erscheinen in verschiedenen Kontexten ohne eine erkennbare Struktur. • In einer gut strukturierten Datenbank wären diese Tabellen als Anker definiert und in verschiedene Module eingebunden. Diese fehlende Trennung der Module führt zu einem System, das schwer zu pflegen und zu erweitern ist. 3. Wartbarkeit und Erweiterbarkeit • Die Struktur erschwert es, neue Funktionen hinzuzufügen oder bestehende Funktionen zu ändern, ohne die gesamte Datenbankstruktur zu überprüfen. Änderungen an einer Tabelle können unerwünschte Auswirkungen auf viele andere Tabellen haben. • Das Anker-Bojen-Prinzip sorgt durch die Trennung der Module dafür, dass Änderungen in einem Modul nur minimale Auswirkungen auf andere Module haben. Dies macht die Wartung und Erweiterung deutlich einfacher. 4. Fehlende klare Rollen für Tabellen • In dieser Struktur übernehmen viele Tabellen gleichzeitig mehrere Rollen. Es gibt keine klare Unterscheidung, welche Tabellen als Anker fungieren und welche als Bojen. Dies führt zu einer verwirrenden und schwer verständlichen Struktur. • Das Anker-Bojen-Prinzip hingegen sorgt dafür, dass jede Tabelle eine klare Rolle hat. Sie kann entweder als Anker (zentrale Datenquelle) oder als Boje (zusätzliche Datenquelle) fungieren, je nach Bedarf. Diese klare Trennung macht die Datenbank nachvollziehbarer und flexibler.
0 notes
Text
Das Anker-Bojen-Prinzip
Das Anker-Bojen-Prinzip in FileMaker – Modularität trifft Flexibilität FileMaker ist bekannt für seine Vielseitigkeit und Effizienz bei der Erstellung maßgeschneiderter Datenbanklösungen. Ein entscheidendes Designkonzept, das in der FileMaker-Entwicklung oft zum Einsatz kommt, ist das Anker-Bojen-Prinzip. Dieses Prinzip bietet nicht nur eine klare Struktur, sondern auch die Flexibilität, sich dynamisch an die Bedürfnisse von Unternehmen anzupassen. Es kommt natürlich gerade bei Eigenentwicklungen immer wieder vor, das dieser Designansatz von Anfang an nicht umgesetzt wurde. Teils aus Unwissen, teils auch aus Bequemlichkeit. So ist es natürlich für den Laien unergründlich warum schon während der ersten Schritte eine UML erstellt wird die jede Tabelle als Anker vorhält und alle weiteren Anker schon als Bojen mit integriert werden. Das ganze bevor überhaupt an Layout-Arbeiten oder das Skripten gedacht werden kann. Doch das Anker-Bojen-Prinzip ist nicht nur ein starrer Leitfaden. In einer fortschrittlichen Interpretation kann ein Anker auch als Boje fungieren – eine Dynamik, die das volle Potenzial dieses Konzepts entfaltet. Was ist das Anker-Bojen-Prinzip? Das Anker-Bojen-Prinzip ist ein Konzept zur Organisation von Beziehungen in einer FileMaker-Datenbank. Es teilt die Struktur in sogenannte Anker und Bojen auf: • Anker: Dies ist die zentrale Tabelle eines Moduls. Sie dient als Ausgangspunkt für alle Beziehungen. • Bojen: Diese Tabellen sind mit dem Anker verknüpft und stellen zusätzliche Daten bereit. Durch diese klare Trennung bleiben Module übersichtlich, was die Entwicklung und Wartung erleichtert. Die Erweiterung: Ein Anker kann auch als Boje fungieren Das Besondere an FileMaker ist seine Flexibilität. Eine Tabelle, die in einem Modul als Anker fungiert, kann in einem anderen Modul selbst als Boje genutzt werden. Diese dynamische Nutzung erlaubt es, zentrale Datenquellen wie „Kunden“ oder „Produkte“ effizient in verschiedenen Kontexten einzubinden, ohne Redundanz zu schaffen. Ein Beispiel aus der Praxis 1. Modul “Kundenverwaltung” • Anker: Tabelle „Kunden“ • Bojen: • „Rechnungen“ (über Kunden-ID) • „Bestellungen“ (über Kunden-ID) • „Notizen“ (über Kunden-ID) In diesem Modul steht der Kunde im Zentrum. Alle Bojen liefern zusätzliche Daten, die direkt mit dem Kunden verknüpft sind. 2. Modul “Rechnungsmanagement” • Anker: Tabelle „Rechnungen“ • Bojen: • „Rechnungspositionen“ (über Rechnungs-ID) • „Produkte“ (über Produkt-ID) • „Kunden“ (über Kunden-ID) Hier wird die Tabelle „Kunden“, die zuvor der Anker war, als Boje angebunden, um Kundendaten wie Namen oder Adressen für Rechnungen bereitzustellen. Fazit: Die Tabelle „Kunden“ ist einmal Anker und einmal Boje. Dies zeigt, wie flexibel und leistungsstark das Konzept ist. Warum ist diese Flexibilität wichtig? 1. Modularität bleibt erhalten Auch wenn eine Tabelle sowohl als Anker als auch als Boje genutzt wird, bleibt die Struktur modular. Jedes Modul kann unabhängig entwickelt, getestet und erweitert werden. 2. Minimierung von Redundanz Anstatt Daten mehrfach zu speichern oder komplexe Beziehungen zu erstellen, wird eine zentrale Tabelle dynamisch eingebunden. Dies sorgt für konsistente Daten und vermeidet unnötige Speicherlast. 3. Effizienz und Wiederverwendbarkeit Tabellen wie „Kunden“ oder „Produkte“ sind in vielen Geschäftsprozessen relevant. Ihre flexible Nutzung spart Zeit und erhöht die Effizienz bei der Entwicklung. Anker und Bojen als Rollen Ein Anker ist wie ein Hafen: stabil, zentral und eine Anlaufstelle für Bojen. Doch auch ein Hafen kann Teil eines größeren Netzwerks sein und als kleiner Knotenpunkt für ein globales Handelssystem fungieren. In ähnlicher Weise sind Tabellen in FileMaker keine starren Einheiten – sie übernehmen dynamisch die Rolle, die gerade benötigt wird. Manchmal ist eine Tabelle die zentrale Quelle (Anker), manchmal eine unterstützende Verbindung (Boje). Beide Rollen sind gleichwertig und entscheidend für das Funktionieren des Systems. Vorteile des Anker-Bojen-Prinzips 1. Klarheit und Übersichtlichkeit Das Prinzip sorgt für eine saubere Trennung der Beziehungen, wodurch Datenbanken leichter zu warten und zu erweitern sind. 2. Skalierbarkeit Mit dem Wachstum eines Unternehmens können neue Module problemlos hinzugefügt werden, ohne bestehende Strukturen zu gefährden. 3. Effizienz in der Entwicklung Die Wiederverwendbarkeit von Tabellen als Anker oder Boje reduziert den Entwicklungsaufwand und beschleunigt die Implementierung neuer Anforderungen. 4. Flexibilität bei Änderungen Geschäftsprozesse ändern sich oft. Mit dem Anker-Bojen-Prinzip lassen sich Änderungen schnell und effizient umsetzen, ohne das gesamte System umstellen zu müssen. Die doppelte Funktion: Boje und Anker gleichzeitig Eine Boje kann nicht nur Informationen liefern, sondern in anderen Kontexten auch eine zentrale Anlaufstelle sein. Beispielsweise könnten „Rechnungen“ in einem Modul die Boje sein, in einem anderen Modul aber der Anker, der weitere Daten wie „Zahlungen“ oder „Mahnungen“ organisiert. Diese Dynamik macht das Anker-Bojen-Prinzip zu einem lebendigen, anpassungsfähigen Konzept. Meine persönliche Vorgehensweise Jede Tabelle ist einmal innerhalb des Datenmodels als Anker definiert. Jeder Anker ist definitiv auch als Boje an jedem Anker zu finden. Alle Tabellen werden ja namentlich in der Datenstruktur automatisch in FileMaker hinterlegt. Tabelle Rechnung, als Tabelle Rechnung, Tabelle Kontakte als Tabelle Kontakte. Diese sortiere ich mir in einen Bereich der Datenbankstruktur. Bezeichnung -Arbeitstabellen-. Dann dupliziere ich mir z.B. die Tabelle Kontakte. Als neuer Name, wird bei mir dann die Bezeichnung -T01_KONTAKTE- verwendet. Durch die Schreibweise weiss ich an jeder stelle von FileMaker, es handelt sich um die Tabelle -Kontakte-. Die Tabelle Rechnung, wäre dann z.B. -T02_RECHNUNG-. Will ich die Rechnungstabelle an die Kontakttabelle hängen, dann wäre die Bezeichnung -T01_kontakte_RECHNUNG||id_kontakt-. Nun kann ich ohne Probleme erkennen wo die Tabellen hinlaufen, über welche ID,s referenziert wird. Will ich jetzt z.B. im Layout -Kontakt- alle Rechnungen des Kontaktes sehen, reicht das anlegen eines Portals. Als Tabelle des Portals wähle ich, -T01_kontakte_RECHNUNG||id_kontakt-. Schon werden mir nur die Rechnungen dieses Kontaktes angezeigt. Kein Filter ist notwendig. Warum diese Art der Bezeichnungen? Jeder der mit FileMaker arbeitet kommt an den Punkt z.B. Werte aus oder über Referenzen zu holen. Durch die konsequente Anwendung dieser Art der Bezeichnungen kann ich immer durch alle Referenzen scrollen und diese sind sortiert. Kein langes suchen ist mehr notwendig. Zusammenfassung Das Anker-Bojen-Prinzip in FileMaker ist weit mehr als eine Designregel. Es bietet eine durchdachte Struktur, die sowohl Flexibilität als auch Modularität unterstützt. Die Fähigkeit, dass ein Anker in einem Modul auch als Boje in einem anderen fungieren kann, macht dieses Prinzip unschlagbar effizient. Egal, ob es um die Verwaltung von Kunden, die Abwicklung von Bestellungen oder die Erstellung von Berichten geht – das Anker-Bojen-Prinzip sorgt für Klarheit, Wiederverwendbarkeit und Anpassungsfähigkeit. Und genau diese Eigenschaften machen es zu einem unverzichtbaren Werkzeug für alle, die mit FileMaker arbeiten.
0 notes
Photo

FileMaker: Das perfekte Werkzeug für den kleinen Handwerker mit großem Anspruch
FileMaker: Das perfekte Werkzeug für den kleinen Handwerker mit großem Anspruch FileMaker ist eine flexible und leistungsstarke Plattform, die es Unternehmen – auch den kleineren – ermöglicht, maßgeschneiderte Lösungen für ihre individuellen Anforderungen zu entwickeln. Besonders für Handwerksbetriebe und kleine Unternehmen, die nur mit einem PC arbeiten, bietet FileMaker unschätzbare Vorteile: Einstieg leicht gemacht Mit FileMaker ist der Start unkompliziert. Die intuitive Benutzeroberfläche erlaubt es auch ohne tiefgehende Programmierkenntnisse, einfache Anwendungen zu erstellen. Beispielsweise können Handwerker Rechnungen schreiben, Kundendaten verwalten oder Arbeitsabläufe organisieren – alles in einer Anwendung. Maßgeschneidert für Ihre Bedürfnisse Jeder Betrieb hat seine eigenen Arbeitsprozesse. Statt sich an starre Softwarelösungen anzupassen, können Sie mit FileMaker Ihre bestehenden Abläufe digitalisieren und optimieren. Die Plattform passt sich an Ihr Unternehmen an – nicht umgekehrt. Das bedeutet, dass Ihre bewährten Prozesse erhalten bleiben, während Sie die Vorteile der Digitalisierung nutzen. Integration mit anderen Systemen Ob Buchhaltungssoftware, Kalender, externe Sensoren oder ein neues Planungstool – FileMaker lässt sich problemlos mit bestehenden Systemen verbinden. Dank moderner Schnittstellen wie JSON, PHP oder XML können Sie nahezu jede Software oder Hardware einbinden, die Sie bereits nutzen. Kosteneffizient und flexibel FileMaker ist eine der kostengünstigsten Optionen für Unternehmen, die eine individuelle Softwarelösung suchen. Besonders kleinere Betriebe profitieren von der Möglichkeit, mit überschaubaren Kosten zu starten und die Anwendung bei Bedarf zu erweitern, wenn das Unternehmen wächst. Für unterwegs und im Home-Office Mobilität wird immer wichtiger – auch für Handwerker. FileMaker ermöglicht es, von unterwegs auf wichtige Daten zuzugreifen. Ob über eine mobile App, den Webbrowser mit WebDirect oder klassische Remote-Verbindungen – Ihre Daten sind jederzeit sicher verfügbar. Kleine Änderungen selbst erledigen Ein neues Feld für die Kundenummer? Ein kleiner Text im Formular, der angepasst werden muss? Mit FileMaker können solche Änderungen oft direkt vom Nutzer vorgenommen werden – ohne teuren Entwickler oder lange Wartezeiten. Sicherheit, die Sie schützt Gerade bei sensiblen Kundendaten ist Sicherheit entscheidend. FileMaker bietet integrierte Sicherheitsfunktionen, damit nur autorisierte Personen Zugriff auf Ihre Daten haben. Ideal für Betriebe, die einen unkomplizierten, aber sicheren Umgang mit Daten benötigen. Datenübernahme leicht gemacht Haben Sie bereits Excel-Tabellen oder Daten aus älteren Systemen? Kein Problem. FileMaker bietet effiziente Importfunktionen, um bestehende Daten schnell zu integrieren. Sie starten direkt mit den Informationen, die Sie brauchen. Fazit: Für kleine Handwerksbetriebe und Unternehmen, die nach einer effizienten und flexiblen Lösung suchen, ist FileMaker der perfekte Partner. Vom ersten Schritt in die Digitalisierung bis hin zu komplexen, maßgeschneiderten Anwendungen – FileMaker wächst mit Ihren Anforderungen. Ob ein einzelner Handwerker mit einem PC oder ein wachsendes Unternehmen: Mit FileMaker gestalten Sie Ihre digitale Zukunft.
0 notes
Photo
FileMaker ist eine Datenbankplattform, die es Unternehmen ermöglicht, benutzerdefinierte Apps zur Verwaltung und Organisation von Daten zu erstellen. Sie eignet sich gut für den Einsatz im Mittelstand, da sie eine flexible Lösung für die Datenbankentwicklung bietet, ohne dass umfangreiche Programmierkenntnisse am Anfang erforderlich sind. Hier sind einige Gründe, warum FileMaker für den Mittelstand das Perfekte Datenbanktool ist: Einfache Entwicklung: FileMaker bietet eine benutzerfreundliche Oberfläche zur Erstellung von Datenbankanwendungen. Dies ermöglicht Mitarbeitern im Mittelstand, eigene Apps zu erstellen, um spezifische Geschäftsanforderungen zu erfüllen, ohne dass umfassende Entwicklungskenntnisse erforderlich sind. Dies gilt zumindest für den Anfang. So ist die Lernkurve am Anfang sehr flach, steigt aber rasant wenn die Ansprüche an die Software steigen. Anpassbarkeit: Mittelständische Unternehmen haben oft einzigartige Anforderungen, die nicht von Standardsoftware abgedeckt werden. FileMaker ermöglicht die Erstellung von maßgeschneiderten Lösungen, die genau auf die Bedürfnisse des Unternehmens zugeschnitten sind. So wird der Kunde zwar seine Prozesse optimieren, aber er muss seine Prozesse nicht umstellen. Dies ist gerade für Mitarbeiter, die seit Jahren die Prozesse bestimmt und optimiert haben, sehr wichtig. Integration: FileMaker kann mit anderen Anwendungen und Systemen integriert werden, was für den Mittelstand wichtig ist, da Unternehmen oft mit verschiedenen Softwarelösungen arbeiten. Integrationen können den Datenaustausch und die Effizienz verbessern. So ist es eigentlich möglich nahezu mit jedem System zu Kommunizieren. Über Schnittstellen wie Java-Script, JSON, XML oder PHP spricht FileMaker mit jeder Software oder aber auch Hardware. Skalierbarkeit: FileMaker-Anwendungen können mit dem Wachstum des Unternehmens mitwachsen. Wenn das Unternehmen wächst, können weitere Funktionen und Module hinzugefügt werden, um den steigenden Anforderungen gerecht zu werden. Datenübernahme: FileMaker besitzt ein sehr mächtiges Werkzeug zur Übernahme von Daten aus anderen Systemen. Ob nur geänderte Datensätze oder neue Datensätze importiert werden sollen, schnell und effizient ist dieser Prozess durchführbar. Mobilität: FileMaker bietet die Möglichkeit, mobile Apps für iOS- und Android-Geräte zu entwickeln. Dies ist insbesondere für Unternehmen im Mittelstand von Vorteil, da Mitarbeiter häufig unterwegs sind und dennoch auf geschäftskritische Daten zugreifen müssen. Sicherheit: FileMaker bietet Sicherheitsfunktionen, um die Daten der Unternehmen zu schützen. Mittelständische Unternehmen können sensible Daten speichern, während sie gleichzeitig sicherstellen, dass nur autorisierte Personen darauf zugreifen können. Kostenkontrolle: Im Vergleich zu vielen komplexen Softwareentwicklungsprojekten kann die Entwicklung von FileMaker-Anwendungen kostengünstiger sein. Dies liegt in der schnelleren Entwicklung der Lösungen. So ist durch die Kombination von Datenbank und Oberfläche eine effektivere Umsetzung von Projektentwicklungen für den Kunden möglich. Schnelle Implementierung: Mit FileMaker können Anwendungen vergleichsweise schnell entwickelt und implementiert werden. Änderungen in Firmenabläufen und Prozessen können schnell mit FileMaker dargestellt werden. Home Office: Was wenn die Mitarbeiter oder aber auch Kunden aus der Ferne auf die Daten zugreifen sollen? Dafür bietet FileMaker eine einzigartige Möglichkeit. WebDirect stellt die Softwarelösung Eins zu Eins im Webbrowser dar. Mit wenigen Handgriffen ermöglicht der Handwerksbetrieb, die Kanzlei einem Berechtigtem den Zugang zum System. Natürlich funktionieren auch die üblichen Zugriffsmöglichkeiten. Per RDP, per Client oder aber auch über eigens entwickelte Webseiten. Eine häufig unterschätzte Fähigkeit von FileMaker, kleine Änderungen. Wer kennt es nicht? Ein Feld fehlt im Layout, eine Bezeichnung ändert sich, der neue Drucker lässt Bereiche des Layouts unbeachtet und die Formulare sehen nicht mehr aus wie mit der alten Hardware. In diesen Fällen kann der Nutzer mit entsprechender Berechtigung selbst Hand anlegen. Es bedarf nicht unbedingt der Unterstützung eines Entwicklers.
0 notes
Text
Warum FileMaker? Die Vorteile einer Entwicklung mit der flexiblen Plattform
Die Anforderungen an moderne Softwarelösungen wachsen stetig: Daten müssen jederzeit und überall verfügbar sein, Anwendungen müssen sich nahtlos in bestehende Systeme einfügen, und die Entwicklung soll schnell und kosteneffizient bleiben. Hier kommt FileMaker ins Spiel – eine Plattform, die diese Herausforderungen mit Leichtigkeit meistert. In diesem Beitrag beleuchten wir die wichtigsten Vorteile der Entwicklung mit FileMaker, von der Geschwindigkeit über die Flexibilität bis hin zu den mobilen Möglichkeiten. 1. Schnelle Entwicklungszeit Mit FileMaker können maßgeschneiderte Lösungen in kürzester Zeit erstellt werden – ideal für Unternehmen, die schnell reagieren müssen. • Low-Code-Ansatz: FileMaker bietet eine visuelle Entwicklungsumgebung mit Drag-and-Drop-Tools, sodass viele Funktionen ohne tiefes Programmierwissen umgesetzt werden können. • Schnelles Prototyping: Änderungen oder Erweiterungen können direkt getestet und umgesetzt werden, wodurch sich Entwicklungszyklen erheblich verkürzen. • Integrierte Funktionen: Viele Standardanforderungen wie Formulare, Filter oder Berichte sind bereits vorhanden.
2. Flexibilität in der Entwicklung FileMaker passt sich problemlos an verschiedene Szenarien an und ist für viele Branchen einsetzbar. • Vielseitige Einsatzmöglichkeiten: Ob CRM, Inventarverwaltung, Terminplanung oder spezifische Geschäftsprozesse – mit FileMaker lässt sich fast jedes Szenario umsetzen. • Individuelles Design: Benutzeroberflächen können exakt an die Bedürfnisse des Unternehmens angepasst werden. • Plattformübergreifend: FileMaker-Lösungen funktionieren auf Mac, Windows, iOS und im Web. 3. Mobile Nutzung und WebDirect Die mobilen Möglichkeiten von FileMaker machen die Plattform besonders attraktiv für Unternehmen mit Außendienst oder verteilten Teams. • FileMaker Go: Mit der App für iOS-Geräte (iPhone und iPad) können Datenbanken unterwegs genutzt werden – ideal für Außendienstmitarbeiter oder Techniker. • WebDirect: FileMaker-Anwendungen können direkt im Browser genutzt werden, ohne dass eine spezielle Software erforderlich ist. • Synchronisation in Echtzeit: Änderungen werden sofort synchronisiert, sodass alle Benutzer immer auf dem neuesten Stand sind. 4. Nahtlose Schnittstellen und PHP-Integration Die Möglichkeiten, FileMaker mit anderen Systemen zu verbinden, sind nahezu unbegrenzt. • APIs und Webhooks: Über RESTful APIs können Daten zwischen FileMaker und anderen Plattformen wie SAP, Salesforce oder Google Sheets ausgetauscht werden. • PHP und Custom Web Publishing: Mit PHP lassen sich maßgeschneiderte Webanwendungen entwickeln, die direkt auf die FileMaker-Datenbank zugreifen. • SQL-Unterstützung: FileMaker kann externe SQL-Datenbanken integrieren und als zentrale Schnittstelle dienen. 5. Mehrbenutzerfreundlichkeit FileMaker ist von Grund auf für die Zusammenarbeit in Teams ausgelegt. • Zentrale Datenbank: Alle Benutzer greifen auf eine gemeinsame Datenbank zu, entweder lokal oder in der Cloud. • Rechteverwaltung: Unterschiedliche Rollen und Berechtigungen sorgen für Sicherheit und Kontrolle. • Echtzeit-Zusammenarbeit: Änderungen werden sofort synchronisiert, sodass alle Benutzer stets die aktuellen Daten sehen.
6. Sicherheit und Zuverlässigkeit FileMaker bietet umfassende Sicherheitsfunktionen, die den Schutz sensibler Daten garantieren. • SSL-Verschlüsselung: Datenübertragungen sind sicher, sowohl im lokalen Netzwerk als auch in der Cloud. • Benutzerverwaltung: Zugriffsrechte können bis auf Feldebene granular definiert werden. • Regelmäßige Updates: FileMaker wird kontinuierlich weiterentwickelt und bietet regelmäßige Sicherheitsupdates. 7. Kosteneffizienz Die Entwicklung mit FileMaker ist oft günstiger als mit anderen Plattformen: • Weniger Entwicklungszeit: Schnelle Umsetzung reduziert die Kosten erheblich. • Flexible Lizenzmodelle: FileMaker bietet Lizenzen für kleine Teams bis hin zu großen Unternehmen. • Geringe Wartungskosten: Änderungen und Erweiterungen können schnell und kostengünstig umgesetzt werden. 8. Stabilität und Zukunftssicherheit FileMaker ist eine etablierte Plattform, die sich über Jahrzehnte bewährt hat. • Regelmäßige Updates: Neue Funktionen und Verbesserungen werden regelmäßig veröffentlicht. • Rückwärtskompatibilität: Alte Lösungen lassen sich oft problemlos in neuere Versionen migrieren. • Große Entwickler-Community: Dank der aktiven Community gibt es zahlreiche Ressourcen und Unterstützung. Fazit FileMaker bietet eine flexible, schnelle und mobile Plattform, die Unternehmen dabei unterstützt, maßgeschneiderte Lösungen zu entwickeln. Ob Sie FileMaker Go für den Außendienst nutzen, Daten in WebDirect verfügbar machen oder über PHP Schnittstellen integrieren – die Möglichkeiten sind nahezu unbegrenzt. Möchten Sie mehr über die Entwicklung mit FileMaker erfahren oder Ihre eigene Lösung umsetzen? Kontaktieren Sie uns – wir helfen Ihnen.
0 notes
Text
Kreuztabellen in FileMaker – Flexibilität und Effizienz für komplexe Datenstrukturen
Eine der größten Herausforderungen in Datenbanken besteht darin, Informationen effizient und flexibel zu verknüpfen, ohne sich in starren Strukturen zu verlieren. Hier kommt das Konzept der Kreuztabelle ins Spiel. Kreuztabellen ermöglichen es, Beziehungen zwischen verschiedenen Tabellen herzustellen und dabei maximale Wiederverwendbarkeit und Konsistenz zu gewährleisten. Häufig sehe ich die Problematik in der Referenzierung und dem Datenbankdesign bei Kunden. Da wird für jede mögliche Verknüpfung ein weiteres Feld benötigt, Kontakte wiederholen sich unendlich oft, nur mit unterschiedlichen ID,s versehen. In diesem Beitrag zeige ich Ihnen, wie sie das verhindern, wie Sie Kreuztabellen in FileMaker einsetzen können – anhand eines praktischen Beispiels mit Kontakten, Objekten und Kunden. Was ist eine Kreuztabelle? Eine Kreuztabelle (auch als Join-Tabelle bezeichnet) ist eine Zwischentabelle, die zwei andere Tabellen miteinander verbindet. Sie besteht in der Regel aus: • Fremdschlüsseln (z. B. id_kontakt und id_objekt), die die Beziehung definieren. • Zusätzlichen Attributen (optional), um weitere Informationen zur Beziehung zu speichern. Der Vorteil? Jeder Eintrag in der Kreuztabelle stellt eine einzigartige Verknüpfung dar, und Sie können dieselben Datensätze mehrfach verknüpfen, ohne Redundanzen in den Stammdaten zu erzeugen. Praxisbeispiel: Kontakte und Objekte Das Problem In einer Datenbank sollen Kontakte unterschiedlichen Entitäten zugeordnet werden, z. B.: • Ein Kontakt kann ein Kundenkontakt sein. • Der gleiche Kontakt kann aber auch ein Objektkontakt sein. Zusätzlich können einem Objekt mehrere Kontakte zugeordnet werden, z. B. ein Hauptkontakt und ein Ansprechpartner für die Technik. Die Lösung Anstatt Kontakte mehrfach anzulegen oder starre Felder wie Kontakt 1, Kontakt 2 etc. in der Objekttabelle zu verwenden, nutzen wir eine Kreuztabelle, um die Beziehungen flexibel zu halten. Die Struktur 1. Tabelle: Kontakte • Enthält alle Kontaktdaten (z. B. Name, Telefonnummer, E-Mail). • Jeder Kontakt hat eine eindeutige id_kontakt. 2. Tabelle: Objekte • Enthält Informationen zu den Objekten (z. B. Adresse, Name, Beschreibung). • Jedes Objekt hat eine eindeutige id_objekt. 3. Kreuztabelle: ObjektKontakt • Verknüpft Kontakte mit Objekten. • Felder: • id_objekt: Fremdschlüssel zur Tabelle Objekte. • id_kontakt: Fremdschlüssel zur Tabelle Kontakte. • Optionale Felder: Rolle (z. B. Hauptkontakt, Technischer Ansprechpartner). Wie funktioniert die Verknüpfung in FileMaker? Beziehungsgrafik 1. Standardbeziehung: Objekte::id_objekt = ObjektKontakt::id_objekt UND ObjektKontakt::id_kontakt = Kontakte::id_kontakt Diese Beziehung zeigt alle Kontakte, die mit einem Objekt verknüpft sind. 2. Zusätzliche Beziehungen für spezifische Kontakte: • Für einen Hauptkontakt: Objekte::id_objekt = ObjektKontakt_1::id_objekt UND ObjektKontakt_1::Rolle = "Hauptkontakt" • Für einen technischen Ansprechpartner: Objekte::id_objekt = ObjektKontakt_2::id_objekt UND ObjektKontakt_2::Rolle = "Technik" Anzeige der Kontakte im Layout • Portal: • Zeigt alle Kontakte eines Objekts an (ideal für eine Übersicht). • Felder: • Für spezifische Kontakte (z. B. Hauptkontakt und technischer Ansprechpartner) können separate Felder im Layout angezeigt werden, die auf die entsprechenden Beziehungen verweisen. Vorteile von Kreuztabellen 1. Zentrale Verwaltung: • Kontakte werden nur einmal in der Stammtabelle Kontakte gespeichert, können aber flexibel verknüpft werden. 2. Flexibilität: • Neue Beziehungen (z. B. Kontakte für Anlagen, Projekte oder andere Entitäten) können einfach hinzugefügt werden, ohne die bestehende Struktur zu verändern. 3. Skalierbarkeit: • Es gibt keine Limitierung, wie viele Kontakte einem Objekt oder Kunden zugeordnet werden können. 4. Zusätzliche Informationen: • In der Kreuztabelle können weitere Attribute zur Beziehung gespeichert werden (z. B. Rolle, Priorität, Verknüpfungsdatum). Fazit Kreuztabellen sind ein unverzichtbares Werkzeug, um Datenbanken flexibel und effizient zu gestalten. Sie vermeiden Redundanzen, fördern die Wiederverwendbarkeit und ermöglichen es, Beziehungen zwischen Tabellen dynamisch zu verwalten. Ob Sie Kontakte, Objekte, Projekte oder andere Entitäten miteinander verknüpfen – mit einer durchdachten Kreuztabellen-Struktur sind Sie für alle Anforderungen bestens gerüstet.
0 notes
Text
Geodaten in FileMaker integrieren – Einfacher geht’s kaum
Häufig sprechen wir über Geodaten – doch wie bekommen wir diese eigentlich in unsere FileMaker-Datenbank? In vielen meiner kurzen Anrisse, geht es immer wieder um Geo-Daten. Wir übertragen sie in Richtung Google-Maps, in verschiedensten Formen. Nur wir benötigen diese im ersten Schritt. Wenn Sie eine Adresse in Latitude (Breitengrad) und Longitude (Längengrad) umwandeln möchten, bietet sich die Nutzung der Google Geocoding API an. Aber seien wir ehrlich: Niemand hat Lust, sich mit komplexen JSON-Daten oder unnötigem Ballast herumzuschlagen. Darum haben wir uns eine besonders „faule“, aber effektive Lösung überlegt: Wir lassen uns einfach nur die beiden benötigten Geodaten ausgeben – fertig. Ich erhalte eine Variable mit zwei Elementen. Diese kann ich dann in FileMaker mit zwei Scriptschritten weiterverarbeiten. Warum Geodaten in FileMaker nutzen? Geodaten können in einer Datenbank unglaublich vielseitig eingesetzt werden: • Visualisierung: Stellen Sie Adressen als Marker in Google Maps dar. • Navigation: Berechnen Sie Routen und Entfernungen. • Datenanalyse: Prüfen Sie, welche Kunden sich in einem bestimmten Radius befinden. Die Herausforderung? FileMaker arbeitet am besten mit einfachen, strukturierten Daten. Darum konzentrieren wir uns auf die Essenz: Breitengrad und Längengrad. Die „faule“ Lösung: Minimalistische Datenabfrage Statt alle Details wie die formattierte Adresse oder die Geometrie-Typen der Google Geocoding API zu verarbeiten, nutzen wir ein PHP-Skript, das uns genau die zwei benötigten Werte zurückgibt: Latitude und Longitude, getrennt durch einen Zeilenumbruch. So lassen sich die Daten in FileMaker besonders einfach integrieren. Mein Beispiel:
<?php // API-Key hier einfügen $apiKey = "hier der Goggle API-Key"; // Parameter prüfen if (isset($_GET['params'])) { $params = explode('|', $_GET['params']); // Erwartet: Straße|PLZ|Stadt if (count($params) >= 3) { $street = trim($params[0]); // Straße und Hausnummer $city = trim($params[2]); // Stadt $zip = trim($params[1]); // Postleitzahl $country = isset($params[3]) ? trim($params[3]) : "DE"; // Standard: Deutschland // Adresse zusammenstellen $addressComponents = array_filter([$street, $city, $zip, $country]); // Entfernt leere Werte $address = implode(',', $addressComponents); $url = "[maps.googleapis.com/maps/api/...](https://maps.googleapis.com/maps/api/geocode/json?address=)" . urlencode($address) . "&key={$apiKey}"; // API-Anfrage senden $response = file_get_contents($url); // Prüfen, ob die Antwort erfolgreich war if ($response === false) { echo "Fehler beim Abrufen der API\n"; exit; } // API-Antwort decodieren $data = json_decode($response, true); // Ergebnisse prüfen if ($data['status'] === "OK" && isset($data['results'][0]['geometry']['location'])) { $location = $data['results'][0]['geometry']['location']; // Nur Latitude und Longitude ausgeben, getrennt durch Zeilenumbruch echo $location['lat'] . "\n" . $location['lng']; } else { echo "Keine Geodaten gefunden\n"; } } else { echo "Ungültiges Format. Erwartet: Straße|PLZ|Stadt\n"; } } else { echo "Parameter 'params' fehlt. Erwartet: Straße|PLZ|Stadt\n"; }
Das ganze sind 45 Zeilen Code. In FileMaker hätte ich die JSON-Rückgabe erstmal umständlich zerlegen müssen. Über diese Form bekomme ich einen Parameter mit z.B. diesen Werten. 52.6033116 13.3534074 Dafür habe ich lediglich die Straße, PLZ und Stadt übertragen. Natürlich auch das auf ganz leichte Weise. [ihr-server.de/geocode.p...](https://ihr-server.de/geocode.php?params=Senftenberger) Ring 83|13435|Berlin Getrennt durch einen Pipe, werden die Daten in eine FileMaker-Variable geschrieben. Über den FM-Befehl -aus URL einfügen- bekomme ich dann die beiten gewünschten Werte zurück und kann sie einfach in zwei FileMaker Felder schreiben. Mein Fazit, manchmal lohnt es sich, Dinge einfach zu halten – und unsere „faule“ Lösung ist das beste Beispiel dafür. Mit nur einem Skript und einem einfachen Aufruf können Sie Geodaten in FileMaker integrieren und so Ihre Datenbank erweitern. Probieren Sie es aus und lassen Sie Ihre Adressen lebendig werden!
0 notes
Text
Individualisieren Sie Maps-Ansichten: Mitarbeiter und Auftragsstatus dynamisch visualisieren mit einfachen Symbolen
Die Darstellung von Informationen auf Karten ist ein essenzielles Werkzeug für Unternehmen mit Außendienstmitarbeitern. Warum sollten Sie sich jedoch mit Standard-Icons zufrieden geben, wenn Sie die Kartenansicht individuell anpassen können? In diesem Blog zeigen wir, wie Sie mit individuell gestalteten Symbolen auf Google Maps nicht nur Mitarbeiter und Teams visuell hervorheben, sondern auch den aktuellen Status ihrer Aufträge darstellen können. Vor einigen Jahren stand ich vor dieser Herausforderung. Also habe ich mich ans Werk gemacht. Es gab 11 Mitarbeiter die entweder allein oder mit einem weiteren Mitarbeiter unterwegs waren bzw. immer noch sind. Diese Lösung ist noch exakt so im Einsatz, muss aber im Zuge der Anforderungsänderung auf jeweils drei Mitarbeiter aufgerüstet werden. Da aber die jetzigen Anforderungen schon eine Anzahl von über 440 Symbolen notwendig macht, werde ich das über dynamische Symbolgenerierung versuchen umzusetzen. 1. Die Ausgangssituation Stellen Sie sich vor, Ihr Unternehmen verwaltet Außendienstmitarbeiter mit einer FileMaker-Lösung. Mitarbeiter arbeiten allein oder zu zweit, und ihre Aufgaben sind klar kategorisiert: • Wartung (W) • Service (S) • Reparatur (R) • Inbetriebnahme (I) Die Herausforderung besteht darin, auf einer Karte die folgenden Informationen klar darzustellen: 1. Wer arbeitet wo? 2. Arbeitet der Mitarbeiter alleine oder im Team? 3. Welcher Auftrag wird aktuell bearbeitet? 2. Visuelle Darstellung Lösen konnte ich die Herausforderung, indem wir individuelle Symbole verwenden, die: • Den Mitarbeiter (oder das Team) mit einem eindeutigen farbigen T-Shirt darstellen. • Ein Badge (W, S, R, I) am Symbol anzeigen, um die Art des Auftrags zu kennzeichnen. • Für nicht verplante Aufträge ein leeres Symbol mit dem entsprechenden Badge anzeigen. Beispiel: • Mario arbeitet alleine: Ein Symbol mit einem blauen T-Shirt. • Mario und Anna arbeiten zusammen: Ein Symbol mit zwei Figuren, Mario (blaues T-Shirt, Anna mit einem pinken Shirt) ist der Hauptmitarbeiter. • Ein unbesetzter Wartungsauftrag: Eine leere Figur mit einem Badge “W”. • Ein unbesetzter Serviceauftrag: Eine leere Figur mit einem Badge “S”. 3. Vorbereitung der Symbole Für die Symbole erstellen wir PNG-Dateien, die folgende Elemente kombinieren: 1. Figuren: Einzel- und Doppelpersonen. 2. Farben: T-Shirt-Farben für die Mitarbeiter. 3. Badges: Kleine Icons mit W, S, R oder I.
Die Namen der Symbole haben natürlich festgelegte Namenskonventionen. So z.B. Rot_Hellbraun_M.png oder Rot_Hellbraun_W.png Die Zusammensetzung erfolgt innerhalb von FileMaker über eine Schleife der anzuzeigenden Aufträge, dabei wird dann auch der Name der +.png ermittelt. Die Übergabe erfolgt sowie schon in meinen letzten Beiträgen. Die Aufbereitung ist individuell. Möchte ich das ganze noch klickbar machen um weitere Informationen in einem InfoWindow anzuzeigen, möchte ich gleich ein FileMaker-Script starten usw. Fazit Die Individualisierung von Kartenansichten mit FileMaker und Google Maps ist eine tolle Möglichkeit, Außendienstmitarbeiter effizient zu verwalten. Durch die Kombination von Symbolen, Farben und Badges erhalten wir eine klare und visuell ansprechende Darstellung der aktuellen Arbeitsaufteilung. Nur sollten wir darauf achten, das bei vielen möglichen Kombinationen diese Vorgehensweise nicht mehr zeitgemäß ist.
So schaut die Übergabe in meinem Fall aus, z.T. befinden sich Daten die für eine andere Ansichtsart Verwendung finden mit in diesem Datensatz.
1 note
·
View note
Text
FileMaker & PHP – Integration, Möglichkeiten und die Evolution von Version 12 bis heute (leicht wehmütig)
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:
<?php $fm = new FileMaker('DeineDatenbank', 'localhost', 'benutzername', 'passwort'); $layout = $fm->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
0 notes