Zum Hauptinhalt springen

Blueprints

Im Abschnitt Blueprints des Refinery Studio können Sie den Blueprint-Katalog Ihrer Umgebung durchsuchen, Blueprints auf dem aktuellen Tenant installieren oder erneut anwenden und einsehen, was bereits installiert ist.

Ein Blueprint ist ein versioniertes Bündel aus Construction-Kit-Modellen und Seed-Daten, das einen Tenant in einen betriebsbereiten Zustand versetzt. Zur zugrunde liegenden Funktionsweise siehe den Technikleitfaden: Blueprints.

Zugriff auf die Blueprint-Seiten​

Navigieren Sie im Tenant-Menü zu Repository → Blueprints. Es stehen zwei Ansichten zur Verfügung:

  • Catalog — jedes in den konfigurierten Katalogen verfügbare Blueprint, mit Aktionen zum Installieren / erneuten Anwenden.
  • Installations — jedes aktuell auf dem aktiven Tenant installierte Blueprint, mit Anwendungsverlauf und Status.

Catalog-Ansicht​

Die Catalog-Seite stellt jedes verfügbare Blueprint als Karte dar. Der Seitenkopf enthält drei Filter, die die Liste eingrenzen:

SteuerelementZweck
SearchTeilstring-Übereinstimmung mit dem Namen und der Beschreibung des Blueprints.
CatalogAuf eine einzelne Katalogquelle beschränken (LocalFileSystem, PublicGitHub usw.) oder All anzeigen.
StatusAll / Installed / Not Installed / Updates available.

Jede Karte zeigt:

  • Blueprint-Name und Version.
  • Description aus dem Blueprint-Manifest.
  • Catalog source-Badge.
  • Installation status — NOT INSTALLED, INSTALLED oder UPDATE AVAILABLE (wenn der Katalog eine höhere Version als die installierte enthält).
  • Action button — Install, Re-apply (in derselben Version installiert) oder Update (neuere Version verfügbar).

Ein Blueprint installieren​

  1. Suchen Sie das Blueprint im Katalog. Verwenden Sie bei Bedarf Suche / Filter.
  2. Klicken Sie auf der Karte auf Install.
  3. Der Bestätigungsdialog fasst zusammen, was geschehen wird: CK-Modellabhängigkeiten werden importiert, Seed-Daten werden per Upsert angewendet. Bestätigen Sie mit Yes.
  4. Während die Anwendung läuft, zeigt die Karte einen Spinner. Die Aktion ist gesperrt, bis die Anwendung abgeschlossen ist.
  5. Bei Erfolg erscheint ein grüner Toast: Installed <blueprint-id> — <N> seed file(s). Hat die Anwendung Warnungen erzeugt, hängt der Toast (<n> warning(s)) an, und es öffnet sich automatisch ein Detaildialog — siehe Warnungen lesen unten.
  6. Die Karte wechselt auf INSTALLED, und die Aktionsschaltfläche ändert sich zu Re-apply.

Ein Blueprint erneut anwenden​

Re-apply ist der Wiederherstellungspfad: Es importiert die Seed-Daten erneut per Upsert, obwohl das Blueprint in derselben Version verzeichnet ist. Verwenden Sie es, wenn:

  • Sie vermuten, dass Seed-Entitäten geändert oder teilweise gelöscht wurden, und Sie diese erneut durchsetzen möchten.
  • Eine frühere Anwendung Seed-Entitäten abgelegt, aber das Einfügen in den Verlauf nicht abgeschlossen hat (Legacy-Verhalten, behoben im Rollout des tenantspezifischen Speichers — siehe Technikleitfaden).

Der Ablauf ist identisch mit Install, aber der Bestätigungsdialog lautet Re-apply blueprint '<id>'? Existing seed entities will be upserted.

Warnungen lesen​

Wenn das Backend während der Anwendung Warnungen zurückgegeben hat, hängt der Erfolgs-Toast eine Anzahl an, und es öffnet sich automatisch ein Detaildialog:

  • Titel — Blueprint apply warnings — <blueprint-id>
  • Text — ein Aufzählungspunkt pro Warnung, in Festbreitenschrift (Leerraum erhalten).
  • Aktionen — Copy, um die vollständige Liste in die Zwischenablage zu kopieren; Close, um zu schließen.

Der Dialog ist in der Größe veränderbar und nicht blockierend — die Katalogaktualisierung läuft im Hintergrund weiter, während der Dialog geöffnet ist.

Wenn eine Warnung unklar ist, kopieren Sie den Text und prüfen Sie die asset-repo-Logs auf den entsprechenden ERROR-/WARN-Eintrag im Zeitraum um den Zeitstempel der Anwendung.

Fehlermodi​

SymptomUrsache
Roter Toast Install failed: <message>Das Backend hat die Anwendung abgelehnt. Die Meldung enthält oft einen harten Konflikt, eine fehlende CK-Abhängigkeit oder einen YAML-Schemafehler.
Spinner bleibt dauerhaft stehenNetzwerk- oder Backend-Stau. Laden Sie die Seite neu; die Anwendung wurde serverseitig möglicherweise bereits abgeschlossen.
Karte bleibt nach Erfolg auf NOT INSTALLEDVeralteter Cache. Wechseln Sie zur Ansicht Installations, um dies zu bestätigen; der Katalog wird beim Betreten der Seite neu geladen.

Installations-Ansicht​

Die Installations-Seite listet jedes aktuell auf dem aktiven Tenant installierte Blueprint auf. Jede Zeile enthält:

SpalteBedeutung
BlueprintName und Version (HelloBlueprint-1.0.0).
Installed atZeitstempel der ersten Anwendung auf diesem Tenant.
Last updatedZeitstempel der jüngsten Anwendung (Install, Update, Re-apply, Rollback).
DependencyYes, wenn dieses Blueprint transitiv installiert wurde, um die Abhängigkeit eines anderen Blueprints zu erfüllen; No, wenn es explizit angefordert wurde.
Seed checksumPrüfsumme der zuletzt angewendeten Seed-Datei (dient zur Erkennung von Drift zwischen Katalog und Tenant).

In der Symbolleiste der Seite erscheinen zwei Aktionsschaltflächen:

  • Refresh — die Installationen erneut vom Backend abrufen.
  • Apply History — zur chronologischen Verlaufsansicht aller Anwendungsvorgänge auf diesem Tenant wechseln.

Apply History​

Die Verlaufsansicht ist ein chronologisches Protokoll jedes Anwendungsvorgangs (Initial, Update, Rollback, Reapply, Uninstall) mit Zeitstempeln, der vorherigen Version (bei Updates und Rollbacks) und Entitätsanzahlen pro Vorgang:

SpalteBedeutung
Applied atUTC-Zeitstempel der Anwendung.
BlueprintName und Version, die angewendet wurde.
ModeInitial / Update / Rollback / Reapply.
Previous versionDie Version, die vor dieser Anwendung installiert war (bei Initial leer).
CreatedAnzahl der erstellten Seed-Entitäten.
UpdatedAnzahl der aktualisierten Seed-Entitäten.
DeletedAnzahl der gelöschten Seed-Entitäten.

Der Verlauf ist append-only — es gibt kein Bearbeiten/Löschen in der Benutzeroberfläche. Die Aufbewahrung erfolgt pro Tenant: Wird ein Tenant gelöscht, verschwindet sein Verlauf mit ihm.

Wo die Daten liegen​

Sowohl die Installationszeilen als auch die Verlaufseinträge werden als Construction-Kit-Entitäten im eigenen Runtime-Repository des Tenants gespeichert — es gibt keine zentrale Registry. Das ist in der Praxis für zwei Szenarien relevant:

  • Tenant-Backup — mongodump --db=<tenant> erfasst den Blueprint-Zustand zusammen mit den Seed-Entitäten.
  • Tenant-Löschung — das Verwerfen eines Tenants löscht den Blueprint-Verlauf mit. Es bleibt kein „Geister-Verlauf" in einer Systemdatenbank zurück.

Siehe auch​