Zum Hauptinhalt springen

Konfiguration

Xchange arbeitet mit versionierten Konfigurationsständen. Zu jedem Zeitpunkt gibt es genau eine aktive Konfiguration, die den laufenden Betrieb steuert. Daneben kann es einen Entwurf geben – eine Arbeitskopie, in der Änderungen an Anbindungen, Routen und Wertetabellen vorbereitet werden.

Solange ein Entwurf existiert, werden alle Bearbeitungen darin gespeichert. Die aktive Konfiguration bleibt unberührt. Erst wenn der Entwurf geprüft und anschließend aktiviert wird, übernimmt Xchange die neuen Einstellungen in den Betrieb.

Dieses Prinzip hat zwei wichtige Konsequenzen: Laufende Vorgänge werden nie durch eine Konfigurationsänderung unterbrochen – sie laufen immer auf Basis des Stands, unter dem sie gestartet wurden. Und fehlerhafte Konfigurationen können den Betrieb nicht unbeabsichtigt beeinträchtigen, weil die Aktivierung nur nach erfolgreicher Prüfung möglich ist.

Was die Prüfung leistet

Die Prüfung sieht sich den Entwurf als Ganzes an: Pflichtangaben, Verweise zwischen Routen und Anbindungen sowie die logische Konsistenz der Konfiguration. Sie arbeitet dabei ausschließlich auf dem Entwurf selbst – kein externes System wird kontaktiert, keine Verbindung aufgebaut, keine Daten übertragen.

Eine bestandene Prüfung sagt deshalb, dass der Entwurf in sich stimmig ist. Sie sagt nicht, dass die angebundenen Systeme erreichbar sind – dafür gibt es den Verbindungstest –, und auch nicht, was die Aktivierung inhaltlich ändert; das zeigt der Vergleich.

Genau ein Entwurf

Es existiert immer höchstens ein Entwurf gleichzeitig – nie mehrere parallele Arbeitsstände. Jede Änderung, unabhängig davon an welcher Route oder Anbindung, fließt in denselben Entwurf, bis er aktiviert oder verworfen wird. Diese Beschränkung ist bewusst gewählt: Ein einzelner Entwurf lässt sich als Ganzes prüfen und als Ganzes aktivieren – es gibt weder konkurrierende Arbeitsstände, zwischen denen entschieden werden müsste, noch die Frage, welcher von mehreren Entwürfen als Nächstes produktiv geht. Wird ein bereits geprüfter Entwurf weiter bearbeitet, wechselt sein Status auf Prüfung veraltet: Das zuletzt ermittelte Ergebnis bleibt sichtbar, gilt aber nicht mehr für den aktuellen Inhalt, bis erneut geprüft wird.

Frühere Stände bleiben erhalten

Mit jeder Aktivierung entsteht ein neuer Konfigurationsstand; der bisherige wird nicht überschrieben, sondern archiviert. Daraus folgen zwei Möglichkeiten, die den Umgang mit Änderungen entspannter machen.

Vergleichen stellt zwei Stände gegenüber und zeigt Feld für Feld, was sich unterscheidet – üblicherweise der Entwurf gegen die aktive Konfiguration, also genau das, was die nächste Aktivierung bewirken würde. Das beantwortet vor der Aktivierung die Frage, was über Tage und über mehrere Bearbeiter hinweg tatsächlich im Entwurf gelandet ist.

Wiederherstellen holt einen archivierten Stand zurück: Er wird wieder zur aktiven Konfiguration, und der bisher aktive rückt seinerseits ins Archiv. Verloren geht dabei nichts, auch ein vorhandener Entwurf bleibt unberührt. Ein Rückweg ist damit immer offen – auch nach einer Aktivierung, die sich als falsch erweist.

Konfiguration zwischen Systemen übertragen

Ein Konfigurationsstand lässt sich als Datei exportieren und in ein anderes System importieren – etwa um eine in einer Testumgebung aufgebaute Konfiguration nach der Freigabe in eine Produktivumgebung zu übernehmen, oder um vor einem größeren Umbau eine Sicherung anzulegen. Der Export enthält Anbindungen, Routen und Wertetabellen vollständig, jedoch bewusst keine Zugangsdaten: Passwörter, Client-Secrets und Tokens verbleiben im Ursprungssystem und müssen im Zielsystem erneut hinterlegt werden.

Ein Import erzeugt oder erweitert immer nur den Entwurf des Zielsystems – nie dessen aktive Konfiguration direkt. Importierte Konfiguration durchläuft damit denselben Weg wie jede manuell erstellte Änderung: erst prüfen, dann aktivieren. So bleibt der Betrieb auch beim Übertragen von Konfiguration zwischen Systemen durchgängig geschützt.

Siehe auch