Plugin-Entwicklung für EULANDA 2026.6+ #

Dieser Leitfaden beschreibt, wie man ein PowerShell-Plugin für die EULANDA-Warenwirtschaft (Version 2026.6 und neuer) baut - vom headless lauffähigen Cmdlet über den komfortablen WebView2-Dialog bis zur Einbindung als Menü-Action und zur Auslieferung. Er richtet sich an EULANDA-Hauspartner ebenso wie an externe (3rd-Party-)Anbieter. Wer den Leitfaden befolgt, baut ein Plugin, das sich in das EULANDA-Ökosystem einfügt, statt eigene Infrastruktur nachzubauen.

Ziel dieses Kapitels: Ein Mensch - oder ein Cloud-/KI-System eines 3rd-Party-Anbieters - soll damit ein lauffähiges Plugin erstellen können, das auf EulandaXtools aufsetzt.

Die zwei Grundprinzipien #

Alles in diesem Leitfaden folgt aus zwei Regeln. Wer sie verinnerlicht, verzettelt sich nicht.

1. Headless zuerst - die GUI ist nur Komfort #

Jede Fachfunktion muss ohne grafische Oberfläche lauffähig sein. EULANDA startet ein Plugin immer parameter-gesteuert: mit dem Pfad zur Datenbank-Verbindung (-Udl), einem Connection-String (-ConnStr) oder einer Datensatz-ID (-Id). Genau so läuft auch ein Server-/Batch-Aufruf oder ein automatisierter Test.

Die WebView2-GUI ist nur eine bequeme Eingabeschicht darüber: Sie sammelt Parameter und ruft dieselben Fachfunktionen auf, die auch headless laufen. Daraus folgt:

• Die gesamte Domänenlogik lebt in parameter-gesteuerten Cmdlets (lesen, prüfen, rechnen, schreiben). Diese sind einzeln aufrufbar und testbar.
• Der GUI-Einstieg (Show-...) ist ein dünner Aufrufer: Dialog aufbauen, Eingaben einsammeln, Fachfunktion rufen, Ergebnis darstellen. Keine Fachlogik im Dialog.
• Caller-owns-Connection: Wer die Verbindung öffnet, schließt sie auch. Fachfunktionen bekommen eine offene Verbindung (-Conn) oder öffnen selbst aus -Udl/-ConnStr und schließen wieder. Verbindungen werden nie heimlich offen gelassen.

Der Lohn dieses Prinzips: Dieselben headless Funktionen lassen sich hinter beliebige Oberflächen setzen - heute das WebView2-Plugin auf dem Desktop, ebenso aber REST-Endpunkte auf einem Webserver und damit Web-Seiten oder PWA-Apps für Handy und Tablet (siehe Ausblick).

Details und Beispiel: WebView2 in PowerShell und Einbindung in EULANDA.

2. Nichts nachbauen, was EulandaXtools schon liefert #

EulandaXtools ist die gemeinsame Basis aller Plugins. Es liefert DB-Reflection, das WebView2-UI-Bundle (Get-EulWebUiJs / Get-EulWebUiCss / Get-EulWebUiStrings), die eul-*-Web-Components, Get-EulModuleAboutInfo, die Bridge EulUI, den Breadcrumb-Filter und vieles mehr. Plugin-spezifisch ist nur die Domänenlogik - Dialoge, Tabellen, About-Box, Status-Toasts, Icons, Lokalisierung kommen aus EulandaXtools und sehen damit über alle Plugins gleich aus. Bevor man etwas selbst schreibt: prüfen, ob es in EulandaXtools schon existiert.

Architektur im Überblick #

flowchart TD A["EULANDA (Delphi)
cnreg-Action · Menü/Kontext"]:::anlegen B["PowerShell-Worker
EulandaPluginHost · persistent · Named Pipe"]:::umwandlung C["Plugin-Modul
Show-… (GUI) · Fachfunktionen (headless)"]:::buchen D["EulandaXtools
WebView2-UI · DB-Reflection · Helfer"]:::teilstorno A -->|"löst aus, übergibt UDL / Datensatz-ID"| B B -->|"importiert Requirements, ruft CommandText"| C C -->|"nutzt eul-* · Get-EulWebUi* · About"| D classDef anlegen fill:#2e86c1,color:#fff,stroke:#1a5276 classDef buchen fill:#27ae60,color:#fff,stroke:#196f3d classDef umwandlung fill:#8e44ad,color:#fff,stroke:#5b2c6f classDef teilstorno fill:#e67e22,color:#fff,stroke:#af601a

• EULANDA löst über eine cnreg-Action (Registry-Eintrag) den Aufruf aus und übergibt Kontext (UDL, aktuelle Datensatz-ID, DataObject) als Umgebungsvariablen.
• Ein persistenter PowerShell-Worker (EulandaPluginHost) führt den CommandText aus. Er startet einmal pro EULANDA-Sitzung und bedient alle weiteren Aufrufe über eine Named Pipe - kein Prozess-Startup pro Klick.
• Das Plugin-Modul stellt den Einstieg bereit; benötigte Module werden über die Requirements der Action automatisch importiert (ab EulandaXtools 1.0.97).
• EulandaXtools liefert UI und Helfer.

Wegweiser #

1. WebView2 in PowerShell - die Technik dahinter: ein echter Chromium-Browser im PowerShell-Prozess, HTML/JS/CSS aus EulandaXtools, die JavaScript-zu-PowerShell-Brücke.
2. Dialog-Aufbau und Bausteine - der Standard-Aufbau (linke Navigation, obere Leiste, statischer Teil, Tabs, Statusleiste) und die eul-*-Komponenten.
3. Einbindung und Auslieferung - die cnreg-Action, Umgebungsvariablen, das verallgemeinerte Beispiel, Namenskonvention für 3rd-Party, Modulpfad und Auslieferung.

Verwandt: das Konzeptkapitel Plugins (EulandaXtools) und - für die internen UI-Detailregeln im Quellrepo - die Plugin-UI-Guideline in EulandaXtools.

Ausblick #

REST-API und mobile PWA-Apps #

Weil die Fachlogik headless ist, kann derselbe PowerShell-Layer sie auch als REST-API bereitstellen - IIS-gehostete PowerShell-Scripts mit EulandaXtools als Modul (geplantes Repo EulandaStoreAPI, ErpXe #425; Shop-Endpunkte /api/v1/..., #482). Das ist eine zusätzliche, optionale Schiene neben dem In-House-WebView2-Plugin: damit lassen sich im Webserver gehostete Seiten und vor allem PWA-Apps für Handy und Tablet umsetzen. Der WebView2-Desktop-Dialog bleibt die Primärform; REST/PWA ist die mobile Alternative - beide greifen auf dieselben headless Funktionen zu. Das ist der eigentliche Grund, warum die Headless-/Worker-Schicht so wichtig ist.

EULANDA Marketplace #

Mittelfristig hostet EULANDA 3rd-Party-Plugins in einem Marketplace mit Bezahlschranke (PayPal/Kreditkarte) direkt in der Anwendung: Der Anwender lädt die Demo, sieht sie sich an und kauft bei Gefallen direkt - mit anschließender automatischer Lizenzaktivierung. Die Bausteine dazu sind als Issue-Cluster in Arbeit (ErpXe: EulandaStoreAPI #425, Demo-Request/-Generator/-Installation #427/#428/#429, Kauf-Flow mit Lizenzaktivierung #435, Shop-Endpunkte #482, Lizenzierungs-Dialog #561; EulandaXtools: Lizenzprüfung beim Modulimport #14). Wer ein Plugin nach diesem Leitfaden baut und sauber ausliefert (cninst, Demo-fähig, lizenzierbar), ist für den Marketplace vorbereitet.