Modellpersistenz & Synchronisation
ITB verfolgt alle Änderungen lokal in Ihrem Browser (IndexedDB) und synchronisiert sie mit der API. Diese Seite behandelt den vollständigen Lebenszyklus des Modellzustands, einschließlich Speichern, Verwerfen, Verlauf, Sperrung und Wiederherstellung.
Lebenszyklus des Modellzustands
Ihr Modell befindet sich immer in einem von drei Zuständen:
| Zustand | Anzeige | Bedeutung |
|---|---|---|
| Sauber | Grünes Häkchen | Alle Änderungen sind auf dem Server gespeichert. |
| Geändert | Oranger Punkt | Es existieren lokale Änderungen, die noch nicht gespeichert wurden. |
| Gesperrt | (intern) | Auf dem Server wird eine Bearbeitungssperre gehalten, während Sie nicht gespeicherte Änderungen haben. |
Wenn Sie Ihre erste Bearbeitung vornehmen, fordert der Client automatisch eine serverseitige Bearbeitungssperre mit der aktuellen Modellversion an. Die Sperre wird freigegeben, sobald Sie speichern oder verwerfen.
Speichern und Verwerfen
Wenn Sie Änderungen vornehmen, zeigt die Kopfzeile eine Anzeige für nicht gespeicherte Änderungen an:
- Speichern — überträgt alle ausstehenden Änderungen an die API. Der Server erhöht die Modellversion, gibt die Sperre frei und liefert die neue Version zurück. Der Client synchronisiert diese Version lokal, bevor weitere Bearbeitungen zugelassen werden.
- Verwerfen — gibt die Sperre frei, lädt das Modell erneut vom Server und lädt alle lokalen Stores neu. Alle nicht gespeicherten lokalen Änderungen gehen verloren.
Beide Schaltflächen sind deaktiviert, während ein Speichervorgang läuft oder wenn die Modellsperre nicht erworben werden konnte.

Änderungen werden bereits vor dem Speichern lokal in IndexedDB persistiert. Wenn Sie den Browser versehentlich schließen, geht Ihre Arbeit nicht verloren — sie befindet sich jedoch noch nicht auf dem Server.
Verlauf und Zurücksetzen
Klicken Sie auf die Schaltfläche des Synchronisationsmenüs in der Kopfzeile, um die letzten Verlaufseinträge anzuzeigen, oder öffnen Sie das vollständige Verlaufsfenster für eine komplette Liste.
- Jeder Eintrag zeigt eine Bezeichnung (die Art der Änderung), einen relativen Zeitstempel und eine farbige Punktanzeige.
- Grüner Punkt — der Eintrag war Teil eines serverseitigen Speichervorgangs (zum oder vor dem letzten Speicherpunkt).
- Oranger Punkt — der Eintrag ist eine ausschließlich lokale Änderung, die noch nicht gespeichert wurde.
Der Verlauf bleibt über Speichervorgänge hinweg erhalten. Nach einem Speichervorgang werden alle aktuellen Einträge als gespeichert markiert; nachfolgende Bearbeitungen erzeugen neue, nicht gespeicherte Einträge. Der Speicherpunkt (die ID der jüngsten Transaktion zum Zeitpunkt des Speicherns) wird in IndexedDB persistiert und übersteht Seitenneuladungen.
Zurücksetzen
So setzen Sie zurück:
- Klicken Sie auf einen Verlaufseintrag, der älter ist als der jüngste Eintrag. (Der jüngste Eintrag ist deaktiviert — ein Zurücksetzen auf den aktuellen Zustand wäre wirkungslos.)
- Ein Bestätigungsdialog zeigt an, wie viele Transaktionen zurückgesetzt werden.
- Klicken Sie auf Zurücksetzen, um zu bestätigen.
Das Zurücksetzen auf einen Eintrag vor dem Speichern erzeugt einen neuen geänderten Zustand — Sie müssen erneut speichern, um den zurückgesetzten Zustand auf dem Server festzuschreiben. Dies entspricht der übrigen Semantik der App für geänderte Modelle.
Nach einem Verwerfen wird das Journal auf einen einzelnen Basiseintrag zurückgesetzt.
Verwenden Sie Verlauf löschen, um alle Transaktionsdatensätze zu entfernen und den aktuellen Zustand als Basis zu übernehmen.

Sperrmechanismus
Die Sperre ist kein Mehrbenutzerschutz. Sie existiert, weil das Modell eines einzelnen Benutzers von mehreren Oberflächen aus (der Benutzeroberfläche und der API) verändert werden kann. Der Server verfolgt daher eine Versionsnummer und eine Sperre, um zu verhindern, dass gleichzeitige Änderungen den Zustand beschädigen.
Funktionsweise
- Wenn Sie Ihre erste Bearbeitung vornehmen, sendet der Client Ihre lokale Modellversion an
POST /api/v1/model/lock. - Der Server gewährt die Sperre nur, wenn Ihre Version übereinstimmt. Weichen die Versionen voneinander ab (z. B. weil ein anderer API-Aufruf das Modell verändert hat), gibt er 412 Precondition Failed zurück und der Sperrfehler wird in der Benutzeroberfläche angezeigt.
- Die Sperre hat eine serverseitige TTL (Standard: 30 Minuten). Während Sie die Sperre halten, sendet der Client einen periodischen Heartbeat (etwa alle 20 Minuten), um den Zeitstempel der Sperre zu aktualisieren. Dies verhindert ein stillschweigendes Ablaufen während langer Bearbeitungssitzungen.
- Wenn Sie zum Browser-Tab zurückkehren, nachdem Sie ihn verlassen hatten, prüft der Client, ob die Sperre noch gehalten wird. Ist sie abgelaufen, während der Tab inaktiv war, wird der Sperrfehler sofort angezeigt.
Wiederherstellung
Wenn ein Versions- oder Sperrfehler auftritt:
- Die Schaltfläche Speichern wird deaktiviert und eine Warnung wird angezeigt.
- Verwerfen ist der Wiederherstellungsmechanismus. Es gibt die Sperre frei, lädt das Modell erneut vom Server und setzt den gesamten lokalen Zustand zurück.
- Das Verwerfen ist destruktiv — alle nicht gespeicherten lokalen Änderungen gehen verloren. Dieser Kompromiss ist beabsichtigt: Er garantiert, dass Sie zu einem sauberen, konsistenten Zustand zurückkehren.
Hochladen und Herunterladen (.itb.zip)
Modell herunterladen
Öffnen Sie Modellaktionen in der Kopfleiste und wählen Sie Download Model. Das Modell wird als .model.itb.zip-Datei mit einem Dateinamen versehen mit Zeitstempel exportiert (z. B. 2026-05-04_10-30.model.itb.zip).
Modell hochladen
- Öffnen Sie Modellaktionen in der Kopfleiste und wählen Sie Upload Model.
- Wählen Sie eine
.model.itb.zip-Datei aus Ihrem Dateisystem aus. - Der Upload-Dialog zeigt den Fortschritt an: Sperre wird erworben → Wird hochgeladen → Wird abgerufen → Daten werden geladen → Erfolg.
- Klicken Sie nach Abschluss auf Schließen.
Das hochgeladene Modell ersetzt das aktuelle Modell vollständig.
Es werden nur Dateien mit der Endung .model.itb.zip akzeptiert. Wenn Ihre Datei eine andere Erweiterung hat, benennen Sie sie vor dem Hochladen um.
Modell löschen
Öffnen Sie Modellaktionen in der Kopfleiste und wählen Sie Delete Model, um das gesamte Modell vom Server zu entfernen. Zunächst erscheint ein Bestätigungsdialog.
Artefakte exportieren
Verwenden Sie nach der Codegenerierung die Option Artefakte herunterladen, um die generierte Ausgabe als .artifacts.itb.zip-Datei zu exportieren.