Verwaltung von Construction-Kit-Bibliotheken

OctoMesh bietet eingebaute Werkzeuge zur Verwaltung von Construction-Kit-(CK-)Modellbibliotheken über Tenants hinweg. Dazu gehören das Durchsuchen verfügbarer Bibliotheken aus Katalogen, das Prüfen der Kompatibilität, das Auflösen von Abhängigkeiten und das Importieren von Bibliotheken mit vollständiger Abhängigkeitsauflösung.

Katalogquellen

CK-Modellbibliotheken werden über Kataloge verteilt. OctoMesh unterstützt mehrere Katalogquellen:

Katalog	Beschreibung	Standard
EmbeddedResource	In die Service-Binärdateien eingebettete Systemmodelle	Immer aktiv
PublicGitHub	Öffentliches GitHub-Repository mit veröffentlichten CK-Bibliotheken	Aktiviert
PrivateGitHub	Privates GitHub-Repository für Entwicklungs-/Vorabversionen von Bibliotheken	In Produktion deaktiviert
LocalFileSystem	Lokales Dateisystem für die Verwendung in der Entwicklung	In Produktion deaktiviert

Katalogquellen können pro Umgebung über Helm-Values oder Umgebungsvariablen konfiguriert werden.

Systemverwaltete Modelle

Modelle, deren Name System ist oder mit System. beginnt (z. B. System.Identity, System.Communication), werden von den OctoMesh-Services selbst verwaltet. Diese Modelle:

• Werden während der Tenant-Erstellung und beim Start der Services automatisch importiert
• Können von Benutzern nicht über die Benutzeroberfläche der Bibliotheksverwaltung oder die CLI aktualisiert werden
• Werden im Bibliotheksüberblick mit einem „Service-Managed"-Badge angezeigt
• Sind von der Stapeloperation „Fix All" ausgeschlossen

Versionskompatibilität

Bei der Bewertung, ob eine CK-Bibliothek in einen Tenant importiert werden kann, prüft OctoMesh die transitive Kompatibilität gegen die installierten Systemmodellversionen:

• Die Prüfung durchläuft die vollständige Abhängigkeitskette rekursiv
• Für jede Abhängigkeit von einem systemverwalteten Modell muss die Major-Version mit der installierten Version übereinstimmen
• Beispiel: Wenn System-2.0.7 installiert ist, ist eine Bibliothek, die System-3.0.0 (andere Major-Version) erfordert, inkompatibel
• Eine Bibliothek, die System-2.0.3 erfordert, ist kompatibel (gleiche Major-Version, installierte Version ist höher)

Inkompatible Bibliotheken werden sowohl in der UI als auch in der CLI markiert und können nicht importiert werden.

Abhängigkeitsauflösung

Beim Importieren einer CK-Bibliothek löst OctoMesh automatisch deren vollständigen Abhängigkeitsbaum auf:

1. Abrufen des Zielmodells aus dem Katalog
2. Durchlaufen seiner Dependencies-Liste (exakte Versionsreferenzen)
3. Für jede Abhängigkeit rekursives Auflösen der Unterabhängigkeiten
4. Deduplizieren nach Modellname, wobei die höchste erforderliche Version behalten wird
5. Ausschließen systemverwalteter Modelle (sie werden von Services verwaltet)
6. Topologisches Sortieren (Abhängigkeiten vor den abhängigen Elementen)

Das Ergebnis ist eine flache, geordnete Liste von zu importierenden Modellen. Jedes Modell wird nacheinander über Hangfire-Hintergrundjobs importiert, wodurch sichergestellt wird, dass Abhängigkeiten verfügbar sind, bevor die von ihnen abhängigen Elemente importiert werden.

Wie aus Versionsbereichen exakte Pins werden

Eine Quell-ckModel.yaml deklariert Abhängigkeiten als Versionsbereiche (Basic.Energy-[1.3,2.0)), aber eine kompilierte CK-Bibliothek trägt exakte Abhängigkeits-Pins. Der Compiler löst jeden Bereich gegen die Kataloge auf — er wählt die höchste veröffentlichte Version, die den Bereich erfüllt — und friert das Ergebnis in das kompilierte Modell ein. Von da an erfordert jeder Import dieser Bibliothek genau die eingefrorenen Versionen.

Dieses Pinning zur Kompilierungszeit ist der Grund, warum sich Abhängigkeits-Bumps kaskadenartig fortpflanzen: Wenn Basic.Energy eine neue Version veröffentlicht, pinnt ein bereits kompiliertes abhängiges Element wie EnergyCommunity weiterhin die alte. Das abhängige Element muss neu gebaut und neu veröffentlicht werden (mit einem Versions-Bump — das SemVer-Gate erzwingt dies), bevor ein Tenant beide halten kann. Siehe Versionierungsregeln für den vollständigen Regelsatz, einschließlich der abweichenden floor-basierten Auflösung, die Blueprints verwenden.

Import-Pipeline

Der Importablauf verwendet die bestehende asynchrone Job-Pipeline:

Backfill von Anzeigeregeln

Wenn ein importiertes Modell die auf seinen Typen deklarierten Anzeigenamen-Regeln ändert, werden bestehende Entitäten der betroffenen Typ-Teilbäume durch einen automatischen Hintergrunddurchlauf aktualisiert, der rtDisplayName / rtDisplayDescription neu berechnet. Der Durchlauf ist dauerhaft und wird wiederholt (nachverfolgt in der Systemsammlung display_rule_sweep); es ist keine manuelle Aktion erforderlich.

Autorisierung

Verwaltungsoperationen für CK-Bibliotheken sind durch die Autorisierungsrichtlinie Data Model Management geschützt:

Operation	Erforderlicher Scope
Kataloge durchsuchen (auflisten, suchen)	octo_api.read_only oder octo_api
Bibliotheksstatus anzeigen	octo_api.read_only oder octo_api
Abhängigkeiten auflösen	octo_api.read_only oder octo_api
Modelle importieren / Caches aktualisieren	octo_api.data_model_management oder octo_api

Die Rolle DataModelManagement ist in der Standardgruppe TenantOwners enthalten.

REST-API-Endpunkte

System-Scope

Methode	Endpunkt	Beschreibung
GET	system/v1/ckmodelcatalog	Alle Modelle aus allen Katalogen auflisten
GET	system/v1/ckmodelcatalog/search?q={term}	Modelle suchen
GET	system/v1/ckmodelcatalog/catalogs	Katalogquellen auflisten
GET	system/v1/ckmodelcatalog/{catalogName}	Modelle aus einem bestimmten Katalog auflisten
POST	system/v1/ckmodelcatalog/refresh	Alle Katalog-Caches aktualisieren

Tenant-Scope

Methode	Endpunkt	Beschreibung
GET	{tenantId}/v1/models/LibraryStatus	Zusammengeführte Ansicht: installiert + Katalog
POST	{tenantId}/v1/models/ResolveDependenciesBatch	Abhängigkeitsbäume auflösen
POST	{tenantId}/v1/models/ImportFromCatalogBatch	Stapelimport mit Jobs
POST	{tenantId}/v1/models/CheckUpgrade	Vorabprüfung der Migration
POST	{tenantId}/v1/models/ImportFromCatalog	Import eines einzelnen Modells