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

Die Anfrage landet selten als Architekturworkshop im Kalender. Meist ist es eine E-Mail aus dem Vertrieb oder der Fachabteilung: „Wir brauchen ein Portal für Kunden und Partner – Zugriff auf Status, Belege, Reklamationen. Bitte bis Q2.“ Im nächsten Satz folgt der eigentliche Satz für die IT: „Und die Delphi-Desktopanwendung muss stabil weiterlaufen.“ Genau in dieser Spannung entscheidet sich, ob Sie einen kontrollierten Ausbau bauen oder sich ein zweites, dauerhaft erklärungsbedürftiges System ans Bein binden.

Delphi Desktop und Web-Portale kombinieren ist deshalb keine UI-Frage, sondern ein Entscheidungspfad: Welche Prozesse dürfen ins Web, ohne dass Regeln auseinanderdriften? Wo liegt die fachliche Wahrheit (Validierung, Statusübergänge, Nebenwirkungen wie Benachrichtigungen und Belegerzeugung)? Und wie verändern sich Betrieb, Security und Support, wenn externe Nutzer ohne VPN über Browser auf zentrale Daten zugreifen?

Der Beitrag führt durch realistische Architekturpfade, benennt den zentralen Zielkonflikt und leitet zu einem ersten Schritt, der im Alltag wirklich hilft: Schnittstellen- und Rechteentscheidung vor Oberflächenbau. Der Fokus liegt auf Betrieb, Administration, Daten- und Dokumentenflüssen, Rollout und Wartbarkeit – ohne Framework-Interna auszubreiten.

Delphi Desktop und Web-Portale kombinieren in der Praxis

Wenn ein Portal gefordert ist, startet der Reflex schnell mit „Welche Masken müssen wir nachbauen?“. Das ist der falsche Ausgangspunkt. Ein Portal gewinnt selten gegen einen eingespielten Desktop-Client, wenn es um schnelle Erfassung, Tastaturnavigation, Spezialhardware oder LAN-nahe Reaktionszeiten geht. Ein Portal gewinnt dort, wo Reichweite, Zugänglichkeit und kontrollierte Zusammenarbeit zählen.

Portal-Use-Cases, die in Unternehmen oft sauber abgrenzbar sind

• Status und Nachverfolgung: Auftrag/Projekt/Service-Ticket in definierten Zuständen, inklusive Historie.
• Dokumentenprozesse: Upload von Nachweisen, Download von Belegen, Austausch strukturierter Dateien.
• Freigaben und Bestätigungen: klar definierte Aktionen mit Auditspur (wer, wann, was).
• Reklamation und Rückmeldung: strukturierte Erfassung, Rückfragen, Abschluss mit Ergebnisdokument.

Desktop-Use-Cases, die häufig besser als Desktop bleiben

• Sehr dichte Datenerfassung mit vielen Feldern/Tabellen, bei der Sekunden pro Vorgang zählen.
• Spezialhardware und lokale Integrationen (Scanner, Etikettendruck, serielle Geräte, Office-/COM-Anbindung).
• Batch-nahe Tätigkeiten, bei denen Power-User mit großen Datenmengen arbeiten.

Der Zielkonflikt ist damit sichtbar: Sie wollen schnell Portalnutzen liefern, aber Sie dürfen keine zweite Logikwelt erzeugen. Je mehr Prozesse Sie ins Portal verschieben, desto stärker müssen Regeln aus dem Desktop in eine gemeinsame Prozessschicht wandern. Und genau dort liegt die nächste Weiche.

Entscheidungspunkt 2: Drei Architekturpfade – mit klaren Betriebsfolgen

Bei „Desktop plus Portal“ gibt es in der Praxis drei Pfade. Jeder ist machbar, aber jeder setzt andere Leitplanken. Entscheidend ist nicht, welchen Namen Sie dem geben, sondern welche Zuständigkeiten Sie akzeptieren: Wer schreibt Daten? Wo laufen Validierungen? Wo entsteht Audit?

Pfad A ist als Einstieg legitim, wenn er ehrlich als Übergang behandelt wird. Pfad B ist der stabilste Dauerzustand, wenn Desktop und Portal länger nebeneinander existieren. Pfad C ist eine strategische Umstellung, die operativ deutlich mehr Disziplin im Betrieb verlangt.

Entscheidungspunkt 3: REST-API als Vertrag – warum CRUD fast immer zu kurz greift

Viele Teams sagen „Wir bauen eine API“ und meinen „Wir stellen Tabellenoperationen als CRUD (Create/Read/Update/Delete) bereit“. Das ist technisch schnell, fachlich aber oft eine Sackgasse: Regeln wandern ins Portal, Nebenwirkungen werden inkonsistent, und der Desktop bleibt eine Sonderwelt. Net-Base warnt explizit vor APIs, die im Kern nur Datenbanktabellen exponieren – weil dann die Fachlogik nicht in der Server-Schicht sitzt und sich Widersprüche zwischen Kanälen praktisch vorprogrammieren.^[Quelle]

Use-Case-APIs: fachliche Aktionen statt Tabellenzugriff

Aus Betriebs- und Wartungssicht ist der bessere Schnitt: Endpunkte, die fachliche Aktionen ausdrücken. Beispiele: „Reklamation einreichen“, „Auftrag freigeben“, „Dokument hochladen“, „Lieferstatus bestätigen“. Das wirkt zunächst wie eine Formulierungsfrage, hat aber harte Folgen:

• Validierungen sind zentral: Eine Regel gilt für Desktop und Portal gleich, weil sie serverseitig geprüft wird.
• Support kann reproduzieren: Die gleiche Aktion über die gleiche API erzeugt das gleiche Ergebnis – statt „im Portal anders als im Desktop“.
• Audit wird greifbar: Fachaktionen lassen sich als Ereignisse protokollieren (wer hat welche Freigabe erteilt?).

Idempotenz und Konflikte: Web-Realitäten einplanen, nicht wegdiskutieren

Ein Portal ist nicht wie ein Desktop-Client im stabilen LAN. Requests werden wiederholt: Doppelklick, Browser-Resend, Retries durch Reverse Proxy oder Load Balancer, Timeouts in Mobilnetzen. Wenn „Speichern“ dadurch doppelt bucht, ist das kein UI-Fehler, sondern eine fehlende Eigenschaft im Service-Kern.

Für kritische Aktionen brauchen Sie mindestens zwei Mechanismen im Vertrag:

• Idempotenz: Eine Aktion wird so verarbeitet, dass Wiederholungen nicht zu doppelter Ausführung führen (z. B. über eine eindeutige Request-Kennung/Idempotency Key).
• Optimistic Concurrency: Änderungen prüfen eine Versionskennung, damit konkurrierende Updates nicht still überschrieben werden, sondern als Konflikt sichtbar werden.

Grenze: Bei langlaufenden Vorgängen (z. B. große Importjobs) reicht das nicht. Dann ist asynchrone Verarbeitung mit Status-Tracking (Job-Queue) oft die robustere Betriebsform, damit das Portal nicht „hängt“ und Nutzer nicht in Retry-Schleifen geraten.

Entscheidungspunkt 4: Identitäten, SSO und Mandantenfähigkeit nicht „nachziehen“

Mit externen Nutzern ändert sich Ihr Sicherheitsmodell. Authentifizierung beantwortet „wer bist du?“, Autorisierung „was darfst du?“. Beides muss serverseitig entschieden werden. Ein Portal, das nur Menüs versteckt, aber keine objektbezogenen Rechte am Service prüft, ist im Zweifel eine Sicherheitslücke und fast immer ein Auditproblem.

SSO (SAML 2.0 oder OIDC) als Betriebsentscheidung

In B2B-Umgebungen ist Single Sign-on über einen Identity Provider üblich, häufig via SAML 2.0 (Security Assertion Markup Language) oder OpenID Connect (OIDC). Der operative Vorteil ist greifbar: Passwortrichtlinien, MFA/Conditional Access und Offboarding liegen im IdP, nicht in einer separaten Portal-Userverwaltung. Für die Integration heißt das: Der Service-Kern muss Claims (z. B. Kunde/Tenant, Rollen) eindeutig in Berechtigungen übersetzen.

Mandanten-/Tenant-Prüfungen gehören in jede Abfrage

Ein Kunden- oder Partnerportal ist praktisch immer mandantenfähig. Diese Trennung muss im Datenzugriff und in der Use-Case-Logik verankert sein, nicht als „Filter im UI“. Praktische Konsequenz: Jede Anfrage trägt einen Tenant-Kontext; jede Aktion prüft, ob das Zielobjekt in diesem Tenant liegt. Wenn Sie das erst nach dem Go-live ergänzen, ist es oft ein Umbau im Kern – inklusive Datenmodell, Indizes, Logs und Tests.

Entscheidungspunkt 5: Dokumente und Dateien sind kein Nebenkriegsschauplatz

Portale ziehen Dokumentenflüsse nach sich: Uploads, PDFs, Bilder, Nachweise. Das ist selten die Hauptfunktion im Pflichtenheft, aber häufig der Teil, der im Betrieb Ärger macht: Speicherwachstum, Backup/Restore, Berechtigungen, Virenprüfung, Aufbewahrung, Nachweisbarkeit.

Drei Speicheroptionen – mit unterschiedlichen Folgen für Backup und Rechte

• Datenbank als BLOB: Konsistenz ist gut (Transaktionen), Backup/Restore ist „ein Paket“. Nachteil: Datenbank wächst, Wartungs- und Restorezeiten können steigen.
• Fileshare/Filesystem: Passt oft zu bestehenden On-Prem-Backups. Wichtig: Das Portal darf nicht direkt auf Shares zugreifen; der Zugriff muss über die API laufen (Rechteprüfung, Audit, Pfadlogik).
• Objekt-Storage: Skalierung und Zugriff über Tokens sind gut abbildbar. Dafür brauchen Sie sauberes IAM (Identity and Access Management), Schlüsselmanagement und klare Laufzeiten für Download-Links.

Uploads: Validierung, Quarantäne und Ownership festlegen

Für Uploads reicht „Datei speichern“ nicht. Sie brauchen Regeln, die der Betrieb später verteidigen kann: erlaubte Typen, Größenlimits, Quarantäne/Scan-Prozess, Protokollierung (wer hat was hochgeladen), und einen Lifecycle (wann wird gelöscht, wie wird Löschung nachgewiesen). Ohne Ownership endet das in „die Dateien liegen irgendwo“ – und spätestens bei Löschanforderungen oder Incident-Aufklärung wird es unangenehm.

Belege/Reports: Eine Erzeugungslinie statt doppelte Ausgabewege

Wenn die Delphi-Desktopanwendung gewachsene Druck-/Reportingstrecken hat, entsteht schnell der Wunsch, „dieselben PDFs“ im Portal auszugeben. Der robuste Weg ist meist serverseitige Belegerzeugung: eine Stelle für Vorlagenversionen, eine Stelle für Audit und Ablage, ein reproduzierbarer Prozess. Das reduziert Abhängigkeiten von Desktopinstallationen und macht Ausgaben erklärbar, wenn Prüfungen oder Reklamationen kommen.

Entscheidungspunkt 6: Delphi-Backend, C# Services oder Mischarchitektur – worauf es wirklich ankommt

Die Sprachenfrage wird oft zu früh entschieden. Relevanter ist: Passt der Stack zu Ihren Betriebsstandards (Patching, Deployment, Monitoring, Reverse Proxy, Zertifikate, Secrets)? Und vor allem: Vermeiden Sie Doppel-Logik. Herstellerseitig ist zumindest klar, dass Delphi/RAD Studio WebBroker und Server-/HTTP-Integrationsoptionen aufführt, inklusive typischer Deployment-Modelle (z. B. via IIS/ISAPI oder als eigener HTTP-Server).^[Quelle] Daraus folgt aber nicht automatisch, dass „Delphi-Backend immer richtig“ ist – nur, dass die Option technisch im Werkzeugkasten liegt.

REST-Server mit Delphi: sinnvoll, wenn Fachlogik bereits im Delphi-Stack verlässlich ist

Wenn zentrale Regeln und Datenzugriff im Delphi-Umfeld robust existieren, kann ein Delphi-basierter REST-Server als Service-Kern sinnvoll sein – unter einer Bedingung: Er wird wie ein Serverprodukt betrieben, nicht wie „Desktop ohne UI“. Das heißt: klare Konfiguration, definierte Timeouts, strukturierte Logs, Health-Checks, reproduzierbares Deployment und eine Update-Strategie, die nicht auf „manuell auf dem Server“ hinausläuft.

Net-Base ordnet beim Thema REST-Server mit Delphi ein, dass die Wahl des konkreten Frameworks zwar relevant ist, aber gegenüber Gesamtarchitektur, Security und Betrieb nachrangig bleibt.^[Quelle] Praktische Folgerung: Entscheiden Sie zuerst Logging/Korrelation, Reverse Proxy, Zertifikats- und Secret-Handhabung sowie Deploymentpfad – und erst danach, welches Delphi-Web-Framework das innerhalb Ihrer Standards am saubersten abbildet.

C# Services: naheliegend, wenn Portalbetrieb und Identity stark .NET-geprägt sind

Wenn Ihre Organisation Portale standardmäßig auf .NET betreibt (Tooling, Hosting, Identity, Skills), sind C# Services als Portal-Backbone oft pragmatisch. Die harte Regel bleibt: Keine parallelen Regelimplementierungen in Desktop, Portal und Services. Ein brauchbarer Schnitt ist häufig: Service-Kern mit Fachaktionen und ein portalnaher „Edge“-Layer (Orchestrierung, Aggregation, Rate-Limits), der bewusst keine Fachlogik dupliziert.

API-Gateway: Ordnungselement, nicht Pflicht für den Start

Ein API-Gateway kann Auth-Policies, Rate-Limits, Routing und zentrales Logging bündeln. Für kleine Einstiege reicht oft ein Service hinter einem Reverse Proxy. Sobald mehrere Services, verschiedene Clients (Portal, Desktop, mobile) und Mandantenbetrieb zusammenkommen, ist ein Gateway aber häufig ein Stabilitätsgewinn, weil die Außenkante vereinheitlicht wird und Policies zentral kontrollierbar sind.

Entscheidungspunkt 7: Betrieb und Rollout – Portale verändern Lastprofile und Erwartungshaltung

Mit einem Portal steigt die Erwartung an „immer verfügbar“. Gleichzeitig verschieben sich Lastprofile: Desktopnutzung bedeutet oft längere Sitzungen und „schwere“ Vorgänge, Portale erzeugen viele kurze Requests mit Peaks (morgens, nach Benachrichtigungen, bei Monats- oder Quartalsläufen). Das hat unmittelbare Folgen für Datenbank, Connection Pools, Timeouts und Antwortgrößen.

Minimalanforderungen, bevor Sie extern live gehen

• Health-Checks (Liveness/Readiness): Serviceprozess, Datenbank, Storage erreichbar.
• Strukturiertes Logging: Request-ID, Nutzer/Tenant, Laufzeit, Statuscode, Fehlerklasse.
• Metriken: Latenz, Fehlerraten, DB-Auslastung, Queue-Längen bei asynchronen Jobs.
• Reproduzierbare Deployments: Versionen, Konfigurationsmanagement, Rollback-Option.

Eine Grenze bleibt: Ohne realistische Testlast sehen Sie Engpässe oft erst in Produktion. Der pragmatische Weg ist, Observability von Anfang an in die ersten Portalstrecken einzubauen, damit Sie echte Betriebsdaten bekommen, statt sich auf Vermutungen zu verlassen.

Der Entscheidungspfad als erster Schritt: In 7 Etappen vom „Portalwunsch“ zum beherrschbaren Betrieb

Wenn die Deadline drückt, ist die Versuchung groß, beim Portal-Frontend zu starten. Für IT-Leitung und Betrieb ist die bessere Reihenfolge: zuerst die Risiken entkoppeln, dann Oberfläche liefern. Die Etappen sind so gewählt, dass jede Stufe einen nutzbaren Zwischenstand schafft und den Parallelbetrieb nicht sprengt.

1. Use-Cases eingrenzen: 1–2 Portalprozesse auswählen, die klar abgrenzbar sind (z. B. Status + Dokumente).
2. Zuständigkeiten festlegen: Welche Daten sind nur lesbar? Welche Aktionen dürfen externe Rollen auslösen? Welche Statusübergänge sind erlaubt?
3. Identity-Entscheidung treffen: SSO (SAML/OIDC) oder lokales Login; Mandantenmodell und Claim-Mapping skizzieren.
4. API-Vertrag definieren: Use-Case-Endpunkte, Fehlerformat, Versionierung, Idempotenzregeln für kritische Aktionen.
5. Dokumentenpfad konkret machen: Ablage (DB/Share/Object-Storage), Upload-Validierung, Quarantäne/Scan, Download-Policy mit Audit.
6. Betriebsgrundlagen implementieren: Health-Checks, Logging/Korrelation, Metriken, Deploymentpfad, Rollback.
7. Desktop kontrolliert entkoppeln: priorisierte Schreibpfade schrittweise über den Service-Kern führen, DB-Direktzugriffe reduzieren.

Typische Risiken – und wie Sie sie früh sichtbar machen

Risiko 1: Zwei Datenwege erzeugen zwei Wahrheiten

Wenn der Desktop direkt schreibt, das Portal aber über Services, entstehen Abweichungen bei Validierung, Statuslogik oder Nebenwirkungen (Benachrichtigungen, Belege). Machen Sie das Risiko messbar: Portalaktionen konsequent serverseitig auditieren und die nächste Entkopplungswelle (welcher Desktop-Schreibpfad folgt) als eigenes Arbeitspaket planen. Ohne diese Roadmap wird Pfad A zur Dauerlösung.

Risiko 2: „Security später“ führt zu Umbau im Kern

Mandantenchecks, objektbezogene Rechte, sichere Downloads und Token-Validierung sind keine Extras. Wenn das erst nach dem Portalstart kommt, müssen Sie Datenzugriff, API-Zuschnitt und Tests nachträglich umbauen. Planen Sie den Tenant-Kontext und die serverseitige Autorisierung ab Tag 1 ein – auch wenn der erste Use-Case klein ist.

Risiko 3: Dokumente ohne klare Aufbewahrung und Nachweisbarkeit

Fehlende Ownership fällt nicht sofort auf, aber sie kostet später Zeit: bei DSGVO-Löschanforderungen, bei Restore-Tests, bei Incidents. Klären Sie früh: Aufbewahrung, Löschregeln, Protokollierung von Downloads, erlaubte Typen/Größen und Verantwortliche im Betrieb.

Risiko 4: Fehlende Observability macht Support zum Rätselraten

Ohne durchgängige Request-Korrelation und strukturierte Logs bleibt unklar, ob ein Fehler im Portal, im Proxy/Gateway, im Service oder in der Datenbank entsteht. Das treibt Ticketlaufzeiten und Diskussionen. Mindeststandard: Request-ID end-to-end, konsistente Fehlercodes, Dashboard für Fehlerrate und Latenz.

Der Kern der Entscheidung: Portalnutzen liefern, ohne die Anwendungslinie zu zerreißen

Die Kombination aus Delphi-Desktop und Web-Portal ist für viele Unternehmen ein realistischer Modernisierungspfad: Der Desktop bleibt für interne Power-Workflows stark, das Portal öffnet ausgewählte Prozesse kontrolliert nach außen. Damit das nicht zu zwei Systemen mit widersprüchlichen Regeln wird, braucht es einen gemeinsamen Service-Kern mit Use-Case-APIs, serverseitiger Validierung und einem Betriebsmodell, das Monitoring, Rollouts und Security ernst nimmt.

Wenn Sie aus diesem Beitrag nur einen ersten Schritt mitnehmen: Entscheiden Sie zuerst Schnittstellenvertrag und Rechte-/Mandantenmodell – und wählen Sie dann den kleinsten Portalprozess, der damit sauber live gehen kann. Wer so startet, kann iterativ ausbauen, ohne beim dritten Portal-Use-Case in „warum ist das im Desktop anders?“ zu versinken.

Für dieses Thema sind auch Delphi REST-API und Kundenportal wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.