Delphi Desktop und Web-Portale kombinieren: Architektur, Schnittstellen und Modernisierung ohne Bruch

In vielen Unternehmen ist die fachliche „Schaltzentrale“ über Jahre als Delphi-Desktopanwendung gewachsen: VCL-Client, tiefes Prozesswissen, schnelle Datenerfassung, Druck- und Reportingstrecken, Spezialhardware und oft ein direkter Datenbankzugriff im LAN. Gleichzeitig steigen die Erwartungen an Self-Service und externe Zusammenarbeit: Kunden möchten Auftragsstände prüfen, Dokumente austauschen oder Reklamationen erfassen – ohne VPN, ohne Desktop-Rollout und ohne lokale Installationen.

Delphi Desktop und Web-Portale kombinieren bedeutet in der Praxis, diese beiden Welten so zusammenzuführen, dass Betrieb, Sicherheit und Datenkonsistenz beherrschbar bleiben. Entscheidend ist nicht das „Nachbauen“ von Masken im Browser, sondern eine Architektur, die Prozesse, Rechte und Datenwege sauber trennt und beide Frontends über gemeinsame Regeln arbeiten lässt. Der Gewinn ist ein Modernisierungspfad ohne Big-Bang: Der Desktop bleibt produktiv, während das Web-Portal kontrolliert wächst.

Dieser Beitrag richtet sich an IT-Leitung, Administratoren und technische Projektverantwortliche. Im Fokus stehen Auswirkungen auf Betrieb, Administration, Schnittstellen, Sicherheit, Datenhaltung und Migration – weniger Framework-Details. Sie erhalten praxistaugliche Muster, Entscheidungskriterien und typische Fallstricke inklusive Gegenmaßnahmen.

Warum „Portal statt Desktop“ selten realistisch ist

In B2B-Umgebungen gibt es viele Gründe, warum ein Desktopclient weiterhin sinnvoll bleibt. Administratoren erleben das häufig ganz konkret: Ein Portal ist für verteilte Nutzer ideal, aber bestimmte Aufgaben bleiben im Desktop effizienter oder überhaupt erst möglich.

Desktop-Stärken, die im Alltag zählen

• Komplexe Datenerfassung mit sehr dichten Masken, Tastaturbedienung, großen Tabellenansichten und schnellen Wechseln zwischen Datensätzen.
• Peripherie und lokale Integrationen wie Etikettendrucker, Scanner, serielle Geräte oder spezielle Windows-Komponenten.
• LAN-nahe Performance, wenn große Datenmengen verarbeitet werden oder ein Prozess extrem geringe Latenzen benötigt.
• Gewachsene Workflows mit vielen Sonderfällen, bei denen ein 1:1-Port in ein Portal zunächst hohe Risiken birgt.

Portal-Stärken, die neue Anforderungen abdecken

• Externer Zugriff für Kunden, Lieferanten oder Partner, ohne dass ein Client ausgerollt werden muss.
• Zentrale Steuerbarkeit (Versionen, Features, Berechtigungen) mit klarer Außenkante.
• Geräteunabhängigkeit (Browser, mobile Nutzung) für Außendienst und Management.
• Gezielte Prozessöffnungen wie Statusabfragen, Uploads, Freigaben oder Ticketstrecken.

In der Kombination liegt der Nutzen: Der Desktop bleibt das Power-Tool für interne Rollen, das Portal wird der kontrollierte Zugang für externe Nutzergruppen. Damit das nicht in zwei parallele „Wahrheiten“ auseinanderläuft, braucht es einen verbindenden Kern.

Wenn Sie Delphi Desktop und Web-Portale kombinieren: drei Zielarchitekturen

Bei der Architekturentscheidung geht es vor allem um Zuständigkeiten: Wo liegt die fachliche Regel? Wer darf Daten ändern? Welche Schicht ist „Single Source of Truth“ (also die maßgebliche Quelle für Regeln und Zustände)? Für technische Entscheider ist wichtig: Die Wahl hat direkte Folgen für Betrieb, Fehlersuche, Release-Management und Security.

Variante A: Portal als Ergänzung über REST-API, Desktop bleibt führend

Das Portal bedient ausgewählte Use Cases, typischerweise „lesen und anstoßen“: Status, Dokumente, Freigaben, einfache Erfassungen. Dafür wird eine Delphi REST-API oder ein separater REST-Server eingeführt. Die Desktopanwendung kann zunächst weiter direkt auf die Datenbank zugreifen.

Operativer Vorteil: schneller Start, geringe Eingriffe in den Desktop, gut für einen ersten Portal-Mehrwert.

Risikopunkt: Es existieren zwei Datenwege (Desktop → DB direkt, Portal → API). Wenn Geschäftsregeln nur im Desktop stecken, entstehen Inkonsistenzen. Als Gegenmaßnahme sollten Portal-Funktionen bewusst dort beginnen, wo Regeln einfach und serverseitig abbildbar sind (z. B. Dokumentenbereitstellung, Statusabfrage, definierte Freigabeaktionen).

Variante B: Service-Kern als gemeinsame Prozessschicht (empfohlen bei Parallelbetrieb)

Hier verlagern Sie schrittweise Geschäftslogik aus dem Desktop in Services. Desktop und Portal nutzen dieselben Endpunkte. Der Desktop wird stärker zum Rich Client (UI, lokale Integrationen), die Regeln und Validierungen liegen serverseitig.

Operativer Vorteil: eine zentrale Stelle für Rechte, Audit, Statuslogik und Validierungen; konsistentes Verhalten über alle Frontends.

Aufwand: höher am Anfang, weil API-Standards, Fehlerformate, Versionierung, Monitoring und Deployment sauber geplant werden müssen. Dafür sinkt der Aufwand später deutlich, weil weniger Sonderwege bestehen.

Variante C: Portal führt, Desktop bleibt als Spezialclient

Diese Variante ist sinnvoll, wenn der Browser strategisch der Standardzugang werden soll (z. B. stark verteilte Organisation), der Desktop aber für bestimmte Rollen mit Spezialhardware oder Hochleistungserfassung bestehen bleibt. Der Service-Kern muss hierfür besonders stabil und skalierbar sein.

Layer-3 Architektur als verständliche Leitlinie

Unabhängig von der Variante hilft eine Layer-3 Architektur: (1) Präsentation (Desktop/Portal), (2) Anwendungs- und Domänenschicht (Use Cases, Regeln), (3) Infrastruktur (Datenbank, Dateispeicher, Messaging, externe Systeme). Für Administratoren ist das wichtig, weil die Betriebsgrenzen klar werden: Was ist „Frontend-Problem“, was ist „Service-Problem“, was liegt in der Datenbank oder im Storage? Diese Trennung verkürzt Fehlersuche und reduziert Nebenwirkungen bei Deployments.

Der Praxisbezug: Wie Desktop und Portal denselben Prozess teilen

Die größte Herausforderung ist selten das „Portal bauen“, sondern die Frage: Wie teilen sich Desktop und Portal Verantwortlichkeiten im selben Prozess, ohne dass Regeln doppelt implementiert werden? Drei Muster sind in der Praxis besonders relevant.

1) Use-Case-APIs statt Tabellen- oder CRUD-APIs

Eine häufige Sackgasse ist eine API, die nur Datenbanktabellen nach außen abbildet („Create/Read/Update/Delete“). Dann müssen Regeln im Portal nachgebaut werden, und der Desktop bleibt bei seinen eigenen Regeln. Besser sind Use-Case-APIs: Endpunkte beschreiben fachliche Aktionen wie „Reklamation anlegen“, „Auftrag freigeben“, „Dokument hochladen“, „Lieferstatus bestätigen“.

Der Effekt im Betrieb ist spürbar: Validierungen passieren serverseitig, Fehlermeldungen sind reproduzierbar, und beide Clients (Desktop und Portal) lösen denselben Ablauf über die gleiche Logik aus.

2) Konflikte und Wiederholungen beherrschbar machen

Mit einem Portal steigt die Wahrscheinlichkeit paralleler Änderungen und wiederholter Requests (z. B. durch Timeouts, Retries oder Nutzer-Doppelklicks). Hier helfen drei Konzepte, ohne dass man „Dauer-Sperren“ einführt:

• Idempotenz: Kritische Aktionen sind so gestaltet, dass eine Wiederholung denselben Effekt hat und nichts doppelt ausführt. Praktisch geschieht das häufig über eine eindeutige Request-Kennung (Idempotency Key).
• Optimistic Concurrency: Ein Datensatz trägt eine Versionsinformation (z. B. „Row Version“). Bei Änderungen prüft der Service, ob die Version noch passt, und meldet Konflikte sauber zurück.
• Kurze Transaktionen: Statt „alles sperren“ werden Schreiboperationen kurz gehalten. Lange Arbeiten (z. B. Exporte, Report-Pakete) laufen asynchron.

Für technische Entscheider ist wichtig: Diese Mechanismen reduzieren Supportaufwand, weil Fehlerbilder („ist zweimal passiert“, „meine Änderung ist weg“) deutlich seltener werden.

3) Zustände und Übergaben sauber modellieren

Wenn der Desktop komplexe Fälle bearbeitet und das Portal „nur“ Anträge oder Vorstufen liefert, brauchen Sie definierte Statusübergänge. Ein praxistauglicher Zuschnitt ist: Portal erzeugt oder ergänzt Vorgänge in klar begrenzten Statusbereichen (z. B. „eingereicht“), Desktop bearbeitet Spezialfälle, der Service-Kern entscheidet und protokolliert Statuswechsel. So vermeiden Sie, dass der Portal-Client indirekt Prozesse „kaputt konfigurieren“ kann.

Daten und Dokumente: der häufig unterschätzte Integrationsbereich

Fast jedes Portal bringt Dateivorgänge mit: Uploads, Nachweise, Lieferscheine, Bilder, PDF-Ausgaben. Für Administratoren ist das ein Kernpunkt, weil er Backup, Berechtigungen, Virenprüfung, Storage-Kosten und Performance beeinflusst.

Wo liegen Dateien: Datenbank, Fileshare oder Objekt-Storage?

Es gibt drei gängige Ablageoptionen, die jeweils zu einer anderen Betriebsrealität führen:

• Datenbank (BLOB): gut, wenn Transaktionen streng gekoppelt sein müssen und Backup/Restore alles in einem Paket bleiben soll. Nachteile sind häufig größere Datenbanken und längere Backup-Fenster.
• Filesystem/Share: typisch On-Prem, gut integrierbar in bestehende Backup-Konzepte. Wichtig sind klare Berechtigungen und eine API-Schicht, die den Zugriff kontrolliert.
• Objekt-Storage: sinnvoll bei Skalierung, Lebenszyklusregeln oder wenn externe Zugriffe technisch sauber gekapselt werden sollen. Erfordert ein bewusstes Schlüssel- und Berechtigungsmodell.

Unabhängig vom Speicherort gilt: Das Portal sollte Dateien nicht „direkt“ von einem Share laden. Besser ist ein kontrollierter Download über Service-Endpunkte mit Rechteprüfung, Protokollierung und optionaler zeitlich begrenzter Download-URL.

PDFs und Reports: serverseitig statt doppelt

Delphi-Desktopanwendungen haben oft gewachsene Druck- und Reportingstrecken. Portale benötigen häufig dieselben Inhalte als PDF. Statt zwei Implementierungen zu pflegen, lohnt sich eine zentrale Dokumentenerzeugung im Service-Kern: Vorlagen, Versionierung und Ausgabeformat liegen serverseitig; Desktop und Portal konsumieren das Ergebnis. Für den Betrieb bringt das klare Vorteile: nachvollziehbare Ausgaben, einheitliche Ablage und weniger Abhängigkeit von Desktop-Installationen.

REST-Server und Services: Delphi, C# oder eine Mischarchitektur

Bei der Entscheidung „Delphi oder C#“ geht es für Unternehmen weniger um Ideologie, sondern um Teamfähigkeit, Betriebsumfeld und Wartbarkeit. In vielen Umgebungen ist eine Mischarchitektur realistisch, solange Zuständigkeiten sauber geschnitten sind.

Delphi als Service-Plattform: sinnvoll bei vorhandener Fachlogik

Wenn Fachlogik und Datenzugriff bereits solide in Delphi vorliegen, kann ein Delphi-basierter REST-Server effizient sein. Für Administratoren und Entscheider ist dabei wichtig: Serverbetrieb ist nicht „Desktop im Dauerlauf“. Ein produktiver Service braucht klare Konfiguration, saubere Timeouts, strukturierte Logs, Health-Checks und ein reproduzierbares Deployment.

Auch die Datenanbindung sollte modernisiert werden, falls noch alte Treiber oder die BDE im Spiel sind. Eine BDE-Ablösung und Umstellung auf moderne Datenzugriffe reduziert Störungen im Betrieb und erleichtert das Deployment, weil weniger Legacy-Komponenten installiert und gepflegt werden müssen.

C# Services im Portal-Ökosystem: häufig wegen Hosting und Identity

Wenn das Portal in einer .NET-dominierten Landschaft entsteht, sind C# Services oft naheliegend – nicht zuletzt wegen Identity-Integration, bestehender Betriebsstandards und Hosting hinter Microsoft IIS oder in containerisierten Plattformen. Entscheidend ist, Doppelimplementierung zu vermeiden: Entweder bleibt die fachliche Kernlogik in Delphi-Services und C# übernimmt Edge-Themen (z. B. Portal-spezifische Orchestrierung), oder Sie planen bewusst eine Migration von Logik in .NET – dann aber kontrolliert und mit klaren Fachbereichsgrenzen.

API-Gateway: Ordnungselement, aber kein Muss

Ein API-Gateway kann zentrale Funktionen bündeln (Routing, Rate-Limits, Logging, Authentifizierung). Für kleinere Startarchitekturen reicht oft eine konsistente API mit einheitlichen Standards. Spätestens wenn mehrere Services und Nutzergruppen existieren, hilft ein Gateway jedoch, die Außenkante stabil zu halten und Policies zentral umzusetzen.

Authentifizierung und Rechte: vom internen Desktop zur externen Portalwelt

Mit einem Portal ändert sich die Nutzerlandschaft: Neben internen Benutzern kommen externe Accounts, Rollen und Mandanten hinzu. Daraus entstehen Anforderungen an Identity, Berechtigungen und Auditierbarkeit. Für Administratoren ist das relevant, weil Identity-Systeme und Rollenmodelle später schwer umzustellen sind.

SSO mit SAML 2.0 oder OIDC: weniger Admin-Aufwand, bessere Kontrolle

In B2B-Setups ist SAML 2.0 (Single Sign-on über einen Identity Provider) verbreitet, weil Unternehmen bestehende Identitäten nutzen wollen. OIDC (OpenID Connect) ist ebenfalls gängig, insbesondere in moderneren Plattformen. Klassische Benutzer/Passwort-Logins sind möglich, bedeuten aber zusätzlichen Aufwand für Passwortpolitik, MFA, Reset-Prozesse und Support.

Wichtig für die Architektur: Authentifizierung (wer bist du?) und Autorisierung (was darfst du?) müssen serverseitig geprüft werden – nicht im Portal-Frontend.

Mandantenfähigkeit und Rollenmodell: nicht „später“ ergänzen

Ein Kundenportal erfordert praktisch immer Mandantentrennung: Ein Kunde sieht nur seine Daten. Das muss im Service-Kern abgebildet werden, idealerweise über:

• Claims im Token (z. B. Tenant-ID, Rollen, Vertragsbezug), damit Services Entscheidungen treffen können.
• Datensatzbezogene Prüfungen (Row-Level-Checks in der Fachlogik), nicht nur „Menü ausblenden“.
• Audit-Trails für wichtige Aktionen (wer, was, wann), plus Korrelation über eine Request-ID zur Fehleranalyse.

Der Desktop kann – wenn gewünscht – ebenfalls mit Tokens gegen denselben Identity-Stack arbeiten. Das reduziert Sonderwege und erleichtert die Nachvollziehbarkeit von Änderungen, gerade wenn Portal und Desktop denselben Datensatz bearbeiten.

Datenzugriff modernisieren: FireDAC, PostgreSQL und kontrollierte Datenwege

Viele Delphi-Desktoplösungen sind historisch mit direktem DB-Zugriff gewachsen. Sobald ein Portal hinzukommt, wird das zum Architekturthema: Datenwege müssen kontrollierbar sein, Validierungen zentral greifen, und Performance muss auch unter paralleler Last stabil bleiben.

FireDAC als Basis für wartbaren Datenzugriff

BDE-Ablösung mit nativer Anbindung ist in Delphi-Umgebungen ein verbreiteter Standard für den Zugriff auf moderne Datenbanken. Wichtig ist weniger die Komponente selbst als die Vereinheitlichung: parametrisierte Abfragen, saubere Transaktionsgrenzen, einheitliche Fehlerbehandlung und messbare Laufzeiten. Für den Betrieb zählt, dass Timeouts und Ressourcenverbrauch planbar werden und dass sich Probleme in Logs und Monitoring nachvollziehen lassen.

PostgreSQL mit Delphi: gut beherrschbar bei sauberem Typ- und Migrationskonzept

PostgreSQL mit Delphi ist robust, wenn Typmapping (z. B. UUID, Zeitstempel, JSON-Felder), Indizes und Schema-Migrationen sauber behandelt werden. Gerade Portale erzeugen viele filternde Listenabfragen. Dafür sollten Filter, Paging und Sortierung serverseitig umgesetzt werden, damit nicht große Datenmengen unnötig übertragen werden. Das reduziert Last und verbessert die Nutzererfahrung, ohne dass der Desktop langsamer wird.

Betrieb, Deployment und Monitoring: Portal-Reife für Delphi-Backends herstellen

Ein Portal ist in der Regel dauerhaft erreichbar und damit betriebsintensiver als ein reiner Desktop. Für Administratoren ist das der Bereich, in dem sich eine gute Architektur sofort auszahlt: durch nachvollziehbare Deployments, klare Observability (Logs/Metriken) und definierte Wartungsfenster.

Windows-Service oder Linux-Service: entscheidend ist das Betriebsmodell

Ein Delphi-Service kann als Windows- und Linux-Services oder als Linux-Daemon betrieben werden. Wichtiger als das Betriebssystem sind Standards, die den Betrieb stabil machen:

• Health-Checks für Monitoring und Load Balancer (z. B. „Service lebt“ und „Datenbank erreichbar“).
• Strukturiertes Logging (inkl. Request-ID, Benutzer/Tenant, Laufzeit, Statuscodes), damit Supportfälle reproduzierbar werden.
• Konfiguration ohne Neu-Build (z. B. Umgebungsvariablen, zentrale Konfigurationsdateien), damit Deployments sauber automatisierbar sind.
• Rollback-Fähigkeit durch klare Versionen und migrationssichere Datenbankänderungen.

Lastprofile: Portal ist „viele kurze Requests“ statt „wenige lange Sessions“

Desktopnutzung erzeugt oft längere Arbeitsphasen pro Nutzer, während Portale viele kurze, parallele Requests erzeugen. Typische technische Maßnahmen sind:

• konsequentes Paging, serverseitige Filter und begrenzte Antwortgrößen
• Caching für Stammdaten und seltene Abfragen
• asynchrone Jobs für lange Aufgaben (Exporte, Report-Bundles)
• Rate-Limits und Schutzmechanismen gegen missbräuchliche Nutzung

Für Entscheider ist hier zentral: Performance ist kein „Feintuning am Ende“, sondern Teil der API-Definition (Response-Größen, Timeouts, Hintergrundverarbeitung).

Modernisierung ohne Big-Bang: ein belastbarer Pfad in fünf Schritten

Ein kompletter Neubau ist selten nötig und oft riskant, weil das Prozesswissen im Delphi-Client steckt. Bewährt hat sich ein Vorgehen, bei dem jede Stufe produktiv nutzbar ist und den Betrieb nicht gefährdet.

1) Bestandsaufnahme: Prozesse, Datenhoheit, Integrationen

Starten Sie nicht bei Masken, sondern bei Use Cases: Welche Abläufe sollen ins Portal? Welche Daten darf ein externer Nutzer sehen oder ändern? Welche Schnittstellen existieren zu ERP, DMS oder CRM? Daraus entsteht eine priorisierte API-Liste, die echten Mehrwert liefert.

2) Service-Basics definieren: Auth, Fehlerformat, Logging, Versionierung

Diese Basis entscheidet über die spätere Wartbarkeit. Vereinbaren Sie früh Standards für Authentifizierung/Autorisierung, ein konsistentes Fehlerformat, Request-Korrelation, API-Versionierung und Telemetrie. Das reduziert Reibung zwischen Portal-Team, Backend-Team und Betrieb.

3) Erste Portalstrecke end-to-end liefern

Wählen Sie einen Prozess mit klarer Abgrenzung (z. B. Dokumentenbereich oder Statusabfrage). Wichtig ist, dass die gesamte Kette steht: Login, Rechteprüfung, API, UI, Logging, Monitoring, Betrieb. So erkennt die Organisation früh, welche Standards im Alltag funktionieren.

4) Desktop gezielt anbinden: kritische Schreibpfade über Services

Sobald die Services stabil sind, ziehen Sie ausgewählte Desktop-Funktionen nach: insbesondere Statuswechsel, Freigaben oder zentrale Validierungen. Der Desktop bleibt leistungsfähig, aber die Regeln werden konsistenter, und der direkte DB-Schreibzugriff wird schrittweise reduziert.

5) Konsolidieren: Doppelregeln und Sonderwege abbauen

Über die Zeit entstehen sonst „zwei Systeme“. Planen Sie regelmäßige Konsolidierung ein: Welche Regeln existieren doppelt? Wo kann das Portal den Desktop-Service nutzen? Welche Reports sollten zentral erzeugt werden? Ziel ist eine beherrschbare Plattform, nicht ein Dogma.

Typische Fallstricke aus Betriebssicht – und wie Sie sie vermeiden

Regeln werden im Portal nachgebaut

Das führt zu Abweichungen und Supportfällen. Gegenmaßnahme: Use-Case-APIs mit serverseitigen Validierungen, klare Fehlerrückgaben, und wenn möglich gemeinsame fachliche Testszenarien.

Unklare Datenhoheit zwischen Desktop und Portal

Wenn beide Clients „alles“ ändern dürfen, entstehen Konflikte. Gegenmaßnahme: Statusmodell, definierte Zuständigkeiten und Optimistic Concurrency für konkurrierende Änderungen.

Sicherheit wird als nachträgliches Add-on behandelt

Gerade beim Kundenportal sind SSO, Mandantenchecks, sichere Datei-Downloads und Audit von Anfang an nötig. Nachträglich ist das teurer und erhöht das Risiko von Sicherheitslücken.

Fehlende Transparenz im Betrieb

Ohne Request-IDs, strukturierte Logs und Health-Checks wird Fehlersuche zur Detektivarbeit. Gegenmaßnahme: Observability als Pflichtbestandteil der ersten Service-Releases.

Fazit: Ein Service-Kern verbindet Desktop-Stärke mit Portal-Reichweite

Die Kombination aus Delphi-Desktop und Web-Portal ist in vielen Unternehmen der realistischste Weg, um bestehende Kernprozesse zu erhalten und gleichzeitig externe Zusammenarbeit zu ermöglichen. Entscheidend ist, dass Sie nicht zwei getrennte Welten betreiben, sondern einen verbindenden Service-Kern schaffen: Use-Case-APIs, saubere Rechte, nachvollziehbare Zustände, kontrollierte Datenwege und ein Betriebsmodell mit Logging, Monitoring und planbaren Deployments.

So entsteht eine Modernisierung mit Zwischenzielen: Der Desktop bleibt produktiv, das Portal liefert früh Nutzen, und die Architektur wird Schritt für Schritt konsistenter und wartbarer.

Im fachlichen Umfeld spielen auch Delphi Modernisierung eine wichtige Rolle, wenn Integrationen, Datenflüsse und Weiterentwicklung sauber zusammenspielen müssen.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.