Power BI FileMaker: So bringst du FileMaker-Daten sauber in Power BI

Definition

Power BI FileMaker bezeichnet die technische und fachliche Integration von Daten aus Claris FileMaker in Power BI für Reporting und Analyse. Es ist kein Ersatz für FileMaker als operatives System und auch keine reine „Export-und-hoffen“-Lösung, sondern eine wiederholbare Datenversorgung.

Einleitung

Wenn FileMaker dein operatives System ist, willst du in Power BI vor allem eins: Zahlen, die automatisch aktuell sind und denen man vertraut. Dafür brauchst du eine klare Entscheidung für den Datenweg (ODBC, REST API oder Export), plus saubere Modellierung in Power BI. Der Nutzen ist simpel: weniger Excel-Handarbeit, weniger Abstimmungsstress und schnelleres Steering in Meetings.

Wann lohnt sich Power BI FileMaker wirklich?

Relevant wird das Thema, sobald du wiederkehrende Reports baust (Management, Controlling, Operations) und der FileMaker-Export jedes Mal Zeit frisst oder Fehler produziert. Richtig stark ist die Integration, wenn mehrere Personen mit denselben KPIs arbeiten sollen, inklusive Drilldown auf Details (z. B. Auftrag, Kunde, Vorgang).

• Du willst einen zentralen KPI-Stand statt verteilter Excel-Dateien
• Du brauchst regelmäßige Aktualisierung (täglich, wöchentlich, intraday)
• Du willst nachvollziehbare Logik statt „Zahl kommt aus irgendeinem Sheet“

Die 3 Datenfluss-Modelle: ODBC, REST API oder Export

Es gibt drei praxistaugliche Wege. Entscheidend ist nicht die „coolste“ Option, sondern die stabilste für deinen Betrieb.

• ODBC: Direkter Zugriff auf FileMaker über den FileMaker ODBC Driver. Gut für strukturierte Tabellen und wenn du Daten eher „SQL-nah“ abziehen willst.

• REST über die FileMaker Data API: Gut, wenn du gezielt Datensätze per HTTPS holen willst oder eine kontrollierte, webbasierte Integration bevorzugst.

• Export/Import (CSV/Excel/XML): Der pragmatische Start für Prototypen oder wenn Schnittstellen (noch) nicht sauber freigegeben sind.

Schritt für Schritt: Verbindung in Power BI einrichten

Variante A: ODBC (direkt aus FileMaker)

1) Stelle sicher, dass FileMaker Server bzw. FileMaker Pro ODBC-Verbindungen zulässt und Nutzerrechte dafür sauber gesetzt sind. 2) Installiere den passenden FileMaker ODBC Driver auf dem Rechner/Server, auf dem Power BI Desktop bzw. der Datenzugriff läuft. 3) In Power BI Desktop: Daten abrufen > ODBC, DSN auswählen, Tabellen auswählen. 4) Im Power Query Editor nur die Felder laden, die du wirklich brauchst (weniger Daten = stabilerer Refresh).

Variante B: REST (FileMaker Data API)

1) FileMaker Data API am FileMaker Server aktivieren. 2) In Power BI: Daten abrufen > Web, API-Endpunkt über HTTPS (Port 443) nutzen. 3) Authentifizierung einrichten (meist Bearer Token; je nach Setup auch OAuth-ähnliche Flows). 4) JSON-Antwort in Power Query in Tabellen transformieren und Typen setzen.

Variante C: Export/Import (CSV/Excel/XML)

1) Aus FileMaker per Script/Export Job Daten als CSV, Excel oder XML erzeugen. 2) Dateien in eine definierte Ablage legen (z. B. zentraler Fileshare/SharePoint). 3) In Power BI importieren und Transformationen in Power Query so bauen, dass sie bei jeder neuen Datei identisch laufen (gleiche Spaltennamen, gleiches Format).

Authentifizierung & Sicherheit: so bleibt es beherrschbar

Bei API-Szenarien solltest du Sicherheit wie ein Betriebskonzept denken, nicht wie eine einmalige Einstellung. Nutze HTTPS/SSL, halte Token kurzlebig, und verhindere, dass Power BI mit einem „Alleskönner“-Account auf alle Daten zugreift. Für ODBC gilt dasselbe: lieber ein dedizierter Reporting-User mit minimalen Rechten als ein Admin-Login.

• Least Privilege: nur Tabellen/Felder, die im Reporting gebraucht werden
• Token-Handling: Bearer Tokens erneuern und nicht hart im Klartext verteilen
• Trennung von Arbeit und Produktion: Test- vs. Produktivzugänge

Datenmodellierung in Power BI: hier entsteht der Nutzen

Die Verbindung ist nur der Anfang. Der eigentliche Mehrwert entsteht, wenn Anwender ein Modell bekommen, das sie verstehen: klare Dimensionen (z. B. Kunde, Artikel, Status) und saubere Fakten (z. B. Vorgänge, Zeiten, Mengen). Im Power Query Editor bereinigst du Datentypen, normalisierst Codes und baust wiederverwendbare Schritte, statt jedes Mal manuell zu „reparieren“.

Wichtig: Wenn du aus FileMaker eher „breite“ Tabellen ziehst, lohnt sich oft eine Sternschema-Logik in Power BI, damit Dashboards schnell bleiben und Filter sauber greifen.

Mini-Beispiel: Dashboard aus FileMaker für Operations

Ein Team nutzt FileMaker für Vorgänge und Statuswechsel. Über ODBC werden täglich die Vorgänge importiert, in Power Query werden Statuswerte vereinheitlicht, und im Datenmodell gibt es eine Status-Dimension plus Zeitdimension. Ergebnis: ein Management-Dashboard mit Durchlaufzeiten, offenen Fällen und Engpässen, das sich automatisch aktualisiert und nicht mehr „per Excel zusammengeklickt“ wird.

Troubleshooting: häufige Fehlerquellen

• Refresh klappt lokal, aber nicht im Service: meist fehlt ein sauberes Gateway-Konzept oder Credentials sind anders als in Desktop.

• Leere/kaputte Datums- und Zahlenfelder: Typkonvertierungen in Power Query explizit setzen, statt auf Auto-Erkennung zu vertrauen.

• Langsame Abfragen: zu viele Spalten/Zeilen, fehlende Filter, oder „alles auf einmal“-Import ohne inkrementelles Denken.

Voraussetzungen & Systemanforderungen

• Claris FileMaker (FileMaker Pro und/oder FileMaker Server), mit freigegebenen Schnittstellen
• ODBC: installierter FileMaker ODBC Driver und funktionierende Netzwerkverbindung
• REST: aktivierte FileMaker Data API, HTTPS/SSL, erreichbarer Endpunkt
• Power BI Desktop für Aufbau von Power Query und Datenmodell

Glossar

• Claris FileMaker: Plattform für individuelle Business-Apps und Datenbanken.

• FileMaker Server: Server-Komponente für Hosting, Security und zentralen Zugriff.

• ODBC: Standard-Schnittstelle, um Datenbankdaten abzufragen.

• FileMaker Data API: REST-API, um FileMaker-Daten per HTTP/HTTPS abzurufen.

• Bearer Token: Token, das API-Zugriff autorisiert; muss meist erneuert werden.

• Power Query Editor: Bereich in Power BI zum Laden, Transformieren und Bereinigen von Daten.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn du schnell von „Verbindung steht“ zu „Dashboard ist stabil und wird genutzt“ kommen willst. Typische Trigger sind: Security-Freigaben (wer darf was?), ein Refresh, der im Betrieb zuverlässig laufen muss, oder ein Datenmodell, das aktuell eher nach Export aussieht als nach Reporting-Struktur. Dann spart ein sauberer Aufbau Zeit, reduziert Fehlersuche und macht Ergebnisse messbar (z. B. weniger manueller Abstimmungsaufwand, schnellere Monats- und Wochenreports).