Geschäftssysteme bedienen häufig mehrere Kunden, Standorte oder Marken mit einer gemeinsam gepflegten Anwendung. Unterschiede betreffen Steuersätze, Beleglayouts, Zahlungsarten, Integrationen oder den Zeitpunkt neuer Funktionen. Ein eigener Build für jede Variante führt zu auseinanderlaufenden Releases. Werden dagegen alle Werte in einer Frontend-Datei abgelegt, sind Geheimnisse und sensible Schalter sichtbar und manipulierbar.
Ein Dienst für Laufzeitkonfiguration trennt auslieferbare Software vom genehmigten kundenspezifischen Verhalten. Dafür muss die Architektur harmlose Darstellungsoptionen von Einstellungen unterscheiden, die Geld, Rechte oder Datenzugriff beeinflussen.
Konfiguration nach Risiko einordnen
Zu Beginn erfassen wir alle konfigurierbaren Werte und benennen jeweils einen Verantwortlichen. Darstellungswerte wie Logo-URL oder sichtbare Bezeichnung dürfen möglicherweise an die Anwendung ausgeliefert werden. Betriebliche Werte wie Belegnummern oder zulässige Zahlungsarten benötigen serverseitige Prüfung. Secrets, Signaturschlüssel und Anbieterzugänge dürfen nie als lesbare Konfiguration an Browser, mobile App oder Kasse gelangen.
Die Einstufung bestimmt Speicherung, Auslieferung und Freigabe. Sinnvoll ist eine Trennung in öffentliche Darstellung, angemeldete Client-Einstellungen, sensible Servereinstellungen und Geheimnisse. Diese Kategorien werden im Code erzwungen und nicht nur dokumentiert. Ein Schema lehnt beispielsweise ein Secret-Feld ab, sobald es jemand in einem clientseitig sichtbaren Namensraum speichern will.
Konfiguration verleiht keine Rechte, die die Anwendung nicht bereits geprüft hat. Ein Feature Flag kann eine Oberfläche anzeigen. Vor der Ausführung kontrolliert das Backend trotzdem Benutzerberechtigung und Mandant.
Mandantenkontext auf dem Server bestimmen
Der Server leitet Kunde und Standort aus einer verifizierten Anmeldung, Geräteregistrierung oder vertrauenswürdigen Domain-Zuordnung ab. Eine beliebige tenant_id aus dem Frontend wird nicht als Wahrheit übernommen. Jede Abfrage und Änderung von Konfiguration ist an diesen geprüften Kontext gebunden.
Hierarchische Konfiguration hilft Unternehmen mit vielen Filialen. Globale Standardwerte können auf Kunden- und danach auf Standortebene überschrieben werden. Die Zusammenführungsreihenfolge ist eindeutig und für den Support sichtbar. Für jeden wirksamen Wert müssen Quelle, Version und letzte Freigabe erkennbar sein.
Datenbankbedingungen und Repository-Methoden erzwingen die Mandantentrennung. Nur auf Anwendungsfilter zu vertrauen ist riskant, weil ein Filter vergessen werden kann. Row Level Security schafft, sofern verfügbar, eine zusätzliche Grenze. Auch sie benötigt Tests mit angemeldeten Kontexten und sauber gepflegte Migrationen.
Typisierte und versionierte Werte verwenden
Ein Konfigurationsblock ohne Schema wird schnell zu einer Sammlung undokumentierter Schalter. Wir definieren Typen, Pflichtfelder, zulässige Bereiche und Kompatibilitätsregeln. Jede veröffentlichte Konfiguration erhält eine unveränderliche Version. Die Anwendung meldet, welche Version sie geladen hat. Support und Rücknahme werden dadurch deutlich einfacher.
Schemaänderungen benötigen Migrationen. Eine neue Anwendung kann während der Umstellung Version 3 und 4 verstehen, während ein älteres Terminal vorerst Version 3 nutzt. Wird die Unterstützung zu früh entfernt, fallen Geräte aus, die noch kein Update erhalten haben.
Die Validierung läuft beim Schreiben und bei Werten mit großer Wirkung erneut bei der Verwendung. Ein Steuersatz kann formal eine Zahl sein, aber dennoch Grenzwerte und Freigabe verlangen. Verweise auf Filialen, Drucker oder Zahlungskonten dürfen nur innerhalb desselben Mandanten aufgelöst werden.
Auslieferung und lokalen Cache schützen
Konfiguration wird über authentifizierte TLS-Endpunkte mit Rechteprüfung und Ratenbegrenzung ausgeliefert. Eine Antwort enthält nur Felder, die der jeweilige Anwendungstyp benötigt. Ein Küchendisplay braucht keine Einstellungen zur Zahlungsweiterleitung, nur weil beide Geräte zum selben Standort gehören.
Kassen und mobile Systeme müssen oft während einer Netzstörung weiterarbeiten. Sie können die letzte akzeptierte Konfiguration zusammen mit Version, Ausgabezeit und Integritätssignatur speichern. Vor der Nutzung prüft die Anwendung die Signatur und schützt den Cache mit den Mitteln der Plattform. Ein Cache benötigt eine Ablaufregel. Für manche Einzelhandelsabläufe ist eine kontrollierte Übergangsfrist jedoch besser als eine sofortige Stilllegung.
Geheimnisse nehmen einen anderen Weg. Der Server verwendet sie stellvertretend für den Client oder bezieht kurzlebige, eng begrenzte Zugangsdaten vom Anbieter. Verschleierung in einer ausgelieferten Anwendung ist keine sichere Speicherung.
Änderungen wie Releases kontrollieren
Eine Konfigurationsänderung kann dieselbe Wirkung wie ein Code-Deployment haben. Deshalb verwenden wir Entwürfe, Schemaprüfung, Vier-Augen-Freigabe für sensible Felder und ein vollständiges Änderungsprotokoll. Es enthält Akteur, Zeitpunkt, Grund, vorherigen Wert und neue Version. Besonders sensible Werte können verdeckt bleiben, während die Änderung selbst nachvollziehbar ist.
Neue Werte gehen zunächst an einen Teststandort oder eine Gerätegruppe. Technische und fachliche Prüfungen entdecken eine falsche Druckerzuordnung oder deaktivierte Zahlungsart, bevor alle Filialen betroffen sind. Die Freigabe verweist auf die exakt getestete Version, statt Werte manuell nachzubauen.
Rollback bedeutet, eine bekannte gültige Version auszuwählen. Unter Zeitdruck einzelne Felder aus dem Gedächtnis zu ändern ist kein kontrollierter Rückweg. Abhängigkeiten zählen ebenfalls: Eine Konfiguration kann nicht auf ein bereits deaktiviertes Konto des Zahlungsanbieters zurückgesetzt werden.
Feature Flags mit Enddatum gestalten
Feature Flags trennen Auslieferung und Aktivierung und ermöglichen gestaffelte Freigaben pro Kunde. Sie sammeln sich allerdings schnell an. Jeder Schalter braucht Verantwortlichen, Zweck, Standardwert, Erstellungsdatum und Löschbedingung. Nach vollständiger Einführung oder Ablehnung entfernen wir Flag und toten Code.
Serverseitige Auswertung ist für Rechte, Preise und sensibles Verhalten geeignet. Clientseitige Auswertung passt zu Darstellungsänderungen, solange das Backend entscheidungsbefugt bleibt. Ein Flag ist kein dauerhafter Ersatz für eine echte Produkteinstellung oder ein Berechtigungsmodell.
Tests decken relevante Kombinationen ab, besonders rund um Transaktionen. Jede mathematisch mögliche Kombination zu prüfen wird mit zunehmender Anzahl unmöglich. Auch deshalb bleiben Anzahl und Lebensdauer der Flags begrenzt.
Zeitweise nicht erreichbare Terminals betreiben
Der Konfigurationsdienst erfasst erfolgreiche Abrufe, Versionsverteilung, veraltete Caches, Validierungsfehler und abgewiesene Signaturen. Support-Werkzeuge zeigen den Gerätestatus, ohne vertrauliche Werte preiszugeben. Korrelations-IDs verbinden Terminalanfrage, API und Konfigurationsereignis.
Das Verhalten beim Start ist ausdrücklich definiert. Ein neu registriertes Gerät ohne gültigen Cache stoppt sicher und zeigt einen Wiederherstellungsweg. Ein bekanntes Gerät darf je nach Fachregel vorübergehend mit einer gültigen Cache-Version weiterlaufen. Widerrufene Zugänge oder eine Notabschaltung können eine kürzere Frist verlangen.
Tests simulieren abweichende Uhren, abgelaufene Zertifikate, unterbrochene Downloads, beschädigten Speicher und ein nicht unterstütztes Schema. In einer Demo sind solche Fälle selten. In einem großen Gerätebestand gehören sie zum normalen Betrieb.
Magnificent Services entwickelt Laufzeitkonfiguration, mit der Teams echte Kundenunterschiede ohne getrennte Softwarezweige abbilden. Klare Einstufung, serverseitige Autorität und versionierte Änderungen schützen die Sicherheit. Mehr über unsere Leistungen und Projekte.