ENDPUNKTE
Eigene Wege unter deiner Adresse
Eine Middleware, die auf einen Pfad hört, JSON annimmt und JSON zurückgibt – mit derselben Anmeldung und denselben Rechten wie der Rest. Der Ort für alles, was ein Formular nicht kann.
Studio · Plugin-Werkstatt
Die Blackbox hat eine Tür. Sie steht offen.
Jedes Werkzeug hat eine Grenze. Der Unterschied ist, was dahinter kommt. Bei den meisten ein Formular mit dem Titel „Feature-Wunsch", das in ein Postfach fällt, aus dem nie eine Antwort kommt. Hier ein Editor. Du schreibst C#, der Server übersetzt es gegen die Version deiner Instanz, und danach läuft es als Plugin – mit eigenen Endpunkten, Batchjobs, HtmlItems und Entitäten. Kein Ticket, kein Wartelistenplatz, keine Roadmap, auf der dein Fall unter „wird beobachtet" steht.
01 — Der Weg
Projekt, Dateien, Bau, Version, Abbild.
Ein Plugin-Projekt ergibt genau eine DLL. Du legst es an oder lädst ein vorhandenes als ZIP hoch, arbeitest an den Quelldateien und lässt bauen. Jeder Bau ist eine Version mit Protokoll – und was in der Instanz landet, steht als Liste im Abbild, nicht in jemandes Kopf.
- Quelldateien im Editor, mit Syntaxhervorhebung und Baumansicht
- NuGet-Pakete mit fester Version auswählen – nicht „neueste", damit ein Bau von heute auch morgen noch derselbe ist
- Die Serverversion der Zielinstanz ist gesetzt: du baust gegen das, was dort läuft
- Buildprotokoll im Klartext, samt Fehlermeldung des Compilers
02 — Hinter der Grenze
Jedes Werkzeug sagt irgendwann Nein. Interessant ist, was danach passiert.
Vier Antworten auf denselben Satz — „das kann das System nicht". Drei davon kennst du.
Der Feature-Wunsch
„Wir nehmen das gerne auf."
- Landet in einer Liste, die du nie zu sehen bekommst
- Priorisiert wird nach fremden Kunden
- Antwortzeit: unbestimmt
- Dein Projekt wartet währenddessen
Die Erweiterung vom Markt
„Dafür gibt es ein Plugin."
- Von jemandem, den du nicht kennst, für 29 € im Monat
- Kann 80 Prozent von dem, was du brauchst
- Wird eingestellt, wenn der Entwickler das Interesse verliert
- Und liest dabei deine Daten mit
Der Dienst daneben
„Wir hängen was dran."
- Ein zweites System, das die Daten holt und zurückschreibt
- Zweiter Datenbestand, zweite Anmeldung, zweite Rechnung
- Fällt montags aus, ohne dass es auffällt
- Und niemand weiß mehr, welcher Stand der richtige ist
Die Plugin-Werkstatt
„Dann schreiben wir es eben."
- Eine .NET-Bibliothek im selben Prozess wie der openbi-Server
- Dieselbe Anmeldung, dieselben Rechte, dieselbe Datenbank
- Gebaut gegen deine Serverversion, versioniert, transportierbar
- Der Quelltext gehört dir – auch nach einem Anbieterwechsel
03 — Was ein Plugin kann
Alles, was der Server kann. Deshalb heißt es Serverplugin.
Das ist kein Skript in einer Sandbox mit fünf erlaubten Funktionen und einem Zeitlimit von 200 Millisekunden. Es ist eine .NET-Bibliothek, die im selben Prozess läuft wie das CMS.
BATCHJOBS
Arbeit, die von selbst läuft
Nächtliche Abgleiche, Aufräumläufe, Messungen im Minutentakt. Mit Zeitplan, Protokoll und der Möglichkeit, von Hand anzustoßen.
HTMLITEMS
Eigene Bausteine für Seiten
Ein eigenes Tag, das der Redakteur in eine Seite schreibt und das dein Code füllt. So wird aus Serverlogik etwas, das ein Nicht-Entwickler benutzen kann – ohne dich zu fragen.
ENTITÄTEN
Tabellen, die zum Plugin gehören
Ein Plugin bringt sein eigenes Datenmodell mit und legt es beim Ausrollen an. Es hängt nicht davon ab, dass jemand vorher die richtigen Felder geklickt hat.
04 — Bauen und Ausrollen
Ein Rebuild ersetzt das Abbild vollständig. Deshalb steht die Liste woanders.
Welche Pluginversion in welchem Abbild liegt, ist eine Liste je Instanz. Aus dieser Liste entsteht das Dockerfile bei jedem Bau neu. Ohne sie wäre beim Ausrollen von Plugin B das Plugin A verschwunden – ein Fehler, den man erst bemerkt, wenn eine Seite weiß bleibt und niemand einen Zusammenhang sieht.
- Jede Version bleibt: das Artefakt liegt getrennt von der Versionsliste, damit Listen nicht megabyteweise mitfahren
- Der Stand einer Instanz ist ablesbar – was ist ausgerollt, was läuft wirklich
- Plugins wandern denselben Weg wie alles andere: Entwicklung, QS, Produktiv, mit Prüfbericht
- Bereits ausgerollte Plugins laufen weiter, auch wenn die Buchung endet. Wer seine eigene Anwendung abgeschaltet bekommt, hat das falsche Werkzeug gekauft
05 — Der Assistent
Er kennt den Server, gegen den du baust.
Das ist der Unterschied zu einem allgemeinen Codeassistenten: Er kennt die Schnittstellen dieser Serverversion, die Bauform der Middleware, die Regeln für Entitäten und den Weg zum Ausrollen. Er erfindet deutlich seltener Methoden, die es nur in einem anderen Framework gibt – und wenn, fällt es beim Bau auf.
- Beschreibe die Aufgabe, bekomme Projektgerüst, Klassen und Registrierung
- Fehler aus dem Bauprotokoll liest er selbst und bessert nach
- Er baut Verweise statt Textfelder mit Kennungen – und sagt es, wenn ein Modell keinen einzigen hat
- Lesen ist immer frei. Gebucht wird das Bauen, Hochladen, Ändern und Ausrollen: 99 € im Monat
06 — Was fehlt
Wo die Werkstatt heute endet.
Kein Debugger
Du hast Protokoll, Serverfehler und deine eigenen Ausgaben. Wer schrittweise durch den Code laufen will, tut das lokal in seiner eigenen Entwicklungsumgebung und lädt das Ergebnis hoch. Ja, das ist 2026 eine Zumutung. Es steht trotzdem hier und nicht im Kleingedruckten.
Kein Weg um die Serverversion herum
Gebaut wird gegen die Version der Zielinstanz. Ein Plugin, das eine neuere Schnittstelle braucht, wartet auf das Update dieser Instanz.
Nicht jedes NuGet-Paket passt
Was mit der Laufzeit des Servers kollidiert, scheitert beim Bau. Das ist unangenehm, aber ehrlicher als ein Plugin, das erst im Betrieb umkippt – nachts, im Batchjob.
Weiter im Studio
Und dann muss es nach Produktiv. Ohne Handarbeit.
Landschaften, Transport mit Abhängigkeitsprüfung und ein Testplan als Tor.