Stand: 2026-03-06

Übergeordnet: WvdS-Plattform — Gesamtübersicht Verwandt: 2. CAFM-Architektur ← | 3. PIMS-Architektur ← | 4.1 CAFM-Extension | 4.2 PIMS-Extension

Die Seiten 01-siam, 02-cafm und 03-pims dokumentieren die Backend-Architektur — Authentifizierung, Bestandsdaten und Prozessdaten. Diese Seite dokumentiert die Präsentationsschicht: Welche VSIX-Module sieht der Benutzer, wie sind sie strukturiert, und in welcher Reihenfolge werden sie ausgeliefert?

WvdS.Shell lädt Erweiterungen als .wvdx-Pakete (identisch mit .vsix im Format). Jede Erweiterung bringt eigene Views, Forms und TreeView-Provider mit, kommuniziert über HTTPS/JWT mit dem Gateway.Service und rendert ihre Oberfläche in WebView-Panels (CEF). Die ShowCase-Extension (wvds-show-case) dient als kanonische Referenz für Verzeichnisstruktur, Build-Pipeline und Code-Konventionen.

Die Entscheidung gegen eine Extension pro Topic (z.B. wvds-amed-cafm-tp) ist bewusst: Der Overhead von 7+ Extensions wäre hoch, die Abhängigkeiten komplex, und kein Anwender installiert TP ohne OBJ. Die Domain-Ebene entspricht der Drei-Datenbank-Architektur und hält die Deployment-Einheit handhabbar.

WvdS.Shell (FPC/Lazarus)
   └── Auth: PFX → JWT (Shell-intern, ENIVERSSIAM)
            │
            ├── wvds-amed-cafm             [keine Extension-Dependencies]
            │       ├── TreeView: amedCafmExplorer
            │       ├── Views: TP, OBJ, EMR
            │       └── Gateway: GET/POST /api/v1/cafm/*
            │                    └── ENIVERSCAFM (org.*, asset.*)
            │
            └── wvds-amed-pims             [keine Extension-Dependencies]
                    ├── TreeView: amedPimsExplorer
                    ├── Views: INSP, EZA, WORK, PIPE
                    └── Gateway: GET/POST /api/v1/pims/*
                                 ├── ENIVERSPIMS (inspection.*, work.*, safety.*, fault.*)
                                 └── Cross-Ref → ENIVERSCAFM (asset.item via Synonym)

Die Extensions sind voneinander unabhängig — kein extensionDependencies untereinander. Der gemeinsame Nenner ist ausschließlich der JWT-Token, den WvdS.Shell bereits bereitstellt. Ein Anwender kann nur CAFM oder nur PIMS installieren, ohne dass die andere Extension fehlt.

Jede Business-Extension folgt dem ShowCase-Vorbild:

wvds-amed-{domain}/
├── src-pas/
│   ├── extension.pas                ← Entry point (Activate / Deactivate)
│   ├── {Domain}.Interop.pas        ← JS/asm interop (nur asm-Blöcke)
│   ├── {Domain}.{Topic}.pas        ← 1 Unit pro Topic/View
│   │    z.B. Cafm.TechPlace.pas, Cafm.Objects.pas, Cafm.Emr.pas
│   ├── services/
│   │   ├── Services.Lifecycle.pas  ← Extension-Lifecycle, Feature-Flag-Auswertung
│   │   └── Services.Gateway.pas    ← HTTP/REST-Client → Gateway.Service
│   └── tree/
│       └── Tree.{Domain}.pas       ← TreeView-Provider (Sidebar-Navigation)
│
├── forms/
│   └── {Topic}.wfm                 ← 1 WFM-Form pro Screen (JSON-Format)
│        z.B. TechPlace.wfm, TechPlaceDetail.wfm, Objects.wfm
│
├── media/
│   └── icons/
│       ├── activity-bar.svg        ← Activity-Bar-Icon
│       └── {domain}.svg            ← Allgemeines Domain-Icon
│
├── dist/                            ← pas2js Output (extension.js + .map)
├── package.json                     ← Extension-Manifest
├── package.nls.json                 ← Englische Strings
├── package.nls.de.json              ← Deutsche Strings
├── build.ps1                        ← Build-Skript (pas2js, Packaging)
├── CLAUDE.md                        ← Projekt-Richtlinien
└── .vscodeignore                    ← Packaging-Ausschlüsse

Forms werden als JSON im WFM-Format definiert — kein Binary wie bei Delphi. property_schema aus ENIVERSCAFM beschreibt, welche Felder ein Formular zur Laufzeit zeigt. Ein neuer Gerätetyp in property_schema ergibt automatisch ein neues Formular — ohne Pascal-Code-Änderung.

{
  "version": "1.0",
  "form": {
    "name": "TechPlace",
    "className": "TWvdSForm",
    "layout": "flexColumn",
    "children": [
      { "type": "TwvdsTextEdit", "name": "edtItemNumber", "bind": "item_number" },
      { "type": "TwvdsComboBox", "name": "cboTypeCode",   "bind": "type_code"   },
      { "type": "TwvdsPropertyGrid", "name": "pgProperties", "bind": "properties" }
    ]
  }
}

WvdS.Shell                    Extension (pas2js)              Gateway.Service
    │                               │                               │
    │  1. JWT bereitstellen         │                               │
    │     (IShellContext.Token)      │                               │
    │─────────────────────────────►│                               │
    │                               │                               │
    │                               │  2. REST-Call mit Bearer-Token│
    │                               │  GET /api/v1/cafm/tp?branch=3│
    │                               │─────────────────────────────►│
    │                               │                               │
    │                               │  3. JSON-Response             │
    │                               │◄─────────────────────────────│
    │                               │                               │
    │  4. WebView rendern           │                               │
    │◄─────────────────────────────│                               │

Der JWT-Token fließt über IShellContext — eine Schnittstelle, die WvdS.Shell jeder Extension zur Verfügung stellt. Die Extension ruft damit REST-Endpunkte auf dem Gateway auf. Die Antwort (JSON) wird in WFM-Forms gerendert. Der Gateway authentifiziert den Token gegen ENIVERSSIAM und routet die Anfrage an die entsprechende Datenbank.

Die Auslieferung ist synchron mit den Work Packages im MS-To-Do (Liste ENIV):