Delphi Desktop og Web-Portale kombinere: Arkitektur, grænseflader og modernisering uden brud

I mange virksomheder er den faglige “kontrolcentral” over år vokset som en Delphi-desktopapplikation: VCL-klient, dyb procesviden, hurtig dataindtastning, udskrivnings- og rapporteringsforløb, specialhardware og ofte direkte databaseadgang i LAN. Samtidig stiger forventningerne til self-service og ekstern samarbejde: kunder vil gerne tjekke ordrestatus, udveksle dokumenter eller registrere reklamationer – uden VPN, uden desktop-udrulning og uden lokale installationer.

Kombinere Delphi-desktop og webportaler betyder i praksis at samle disse to verdener, så drift, sikkerhed og datakonsistens forbliver håndterbare. Det afgørende er ikke at “genskabe” skærmbilleder i browseren, men en arkitektur, der klart adskiller processer, rettigheder og dataveje og får begge frontends til at arbejde efter fælles regler. Gevinsten er en moderniseringsvej uden Big-Bang: Desktoppen forbliver produktiv, mens webportalen vokser kontrolleret.

Denne artikel henvender sig til IT-ledelse, administratorer og tekniske projektansvarlige. Fokus er på konsekvenser for drift, administration, grænseflader, sikkerhed, datahåndtering og migration – ikke på rammeværksdetaljer. Du får praktiske mønstre, beslutningskriterier og typiske faldgruber inklusive modforanstaltninger.

Hvorfor “portal i stedet for desktop” sjældent er realistisk

I B2B-miljøer er der mange grunde til, at en desktopklient fortsat giver mening. Administratorer oplever det ofte konkret: En portal er ideel til distribuerede brugere, men visse opgaver forbliver mere effektive eller kun mulige i desktopmiljøet.

Desktopstyrker, der tæller i hverdagen

• Kompleks dataindtastning med meget tætte formularer, tastaturbetjening, store tabelvisninger og hurtige skift mellem poster.
• Periferi og lokale integrationer som etiketteprintere, scannere, serielle enheder eller specielle Windows-komponenter.
• LAN-nær performance, når store datamængder behandles eller en proces kræver ekstremt lav latens.
• Vækstlagede workflows med mange specialtilfælde, hvor en 1:1-portering til en portal i første omgang medfører høje risici.

Portalstyrker, der dækker nye krav

• Ekstern adgang for kunder, leverandører eller partnere, uden at en klient skal udrulles.
• Central styring (versioner, features, rettigheder) med en klar ydre kant.
• Enheds-uafhængighed (browser, mobil brug) for feltpersonale og ledelse.
• Målrettet procesåbning som statusforespørgsler, uploads, godkendelser eller ticket-flow.

Kombinationen er her værdien: Desktoppen forbliver power-værktøjet for interne roller, portalen bliver den kontrollerede adgang for eksterne brugergrupper. For at undgå to parallelle “sandheder” kræves en sammenbindende kerne.

Når I kombinerer Delphi-desktop og webportaler: tre målarkitekturer

I arkitekturvalget handler det først og fremmest om ansvarsfordeling: Hvor ligger den faglige regel? Hvem må ændre data? Hvilket lag er Single Source of Truth (altså den afgørende kilde til regler og tilstande)? For tekniske beslutningstagere er det vigtigt: Valget har direkte konsekvenser for drift, fejlfinding, release-management og sikkerhed.

Variant A: Portal som supplement via REST-API, desktop forbliver førende

Portalen dækker udvalgte use cases, typisk “læse og igangsætte”: status, dokumenter, godkendelser, simple registreringer. Til det indføres en Delphi REST-API eller en separat REST-server. Desktopapplikationen kan i første omgang fortsat få direkte adgang til databasen.

Operativ fordel: hurtig opstart, få indgreb i desktoppen, godt til et første portal-tilbud.

Risiko: Der eksisterer to dataveje (desktop → direkte DB, portal → API). Hvis forretningsregler kun ligger i desktoppen, opstår inkonsistenser. Som modforanstaltning bør portalfunktioner bevidst starte der, hvor regler er enkle og kan afbildes server-side (f.eks. dokumenttilgængeliggørelse, statusforespørgsel, definerede godkendelsesaktioner).

Variant B: Service-kerne som fælles proceslag (anbefales ved parallel drift)

Her flytter I gradvist forretningslogik ud af desktoppen og ind i services. Desktop og portal bruger de samme endpoints. Desktoppen bliver mere et Rich Client (UI, lokale integrationer), mens regler og valideringer ligger server-side.

Operativ fordel: ét centralt sted for rettigheder, audit, statuslogik og valideringer; konsistent opførsel på tværs af frontends.

Omkostning: højere i starten, fordi API-standarder, fejlformater, versionering, monitoring og deployment skal planlægges ordentligt. Til gengæld falder indsatsen senere markant, fordi færre specialveje er nødvendige.

Variant C: Portalen fører, desktop forbliver som specialklient

Denne variant giver mening, hvis browseren strategisk skal være standardadgangen (fx i meget distribuerede organisationer), men desktoppen bevares til specifikke roller med specialhardware eller højydeevneindfangning. Service-kernen skal i så fald være særligt stabil og skalerbar.

Layer-3 arkitektur som forståelig rettesnor

Uanset variant hjælper en Layer-3 arkitektur: (1) præsentation (desktop/portal), (2) applikations- og domænelag (use cases, regler), (3) infrastruktur (database, fillager, messaging, eksterne systemer). For administratorer er det vigtigt, fordi driftsgrænserne bliver klare: Hvad er ’frontend-problem’, hvad er ’service-problem’, og hvad ligger i databasen eller i storage? Denne adskillelse forkorter fejlfinding og reducerer sideeffekter ved deployment.

Praksis: Hvordan desktop og portal deler samme proces

Den største udfordring er sjældent “at bygge portalen”, men spørgsmålet: Hvordan deler desktop og portal ansvaret i samme proces uden at måtte implementere regler dobbelt? Tre mønstre er særligt relevante i praksis.

1) Use-Case-APIs i stedet for tabel- eller CRUD-APIs

En almindelig blindgyde er en API, der kun afbilder databasetabeller udadtil (“Create/Read/Update/Delete”). Så skal regler genskabes i portalen, og desktoppen beholder sine egne regler. Bedre er Use-Case-APIs: endpoints beskriver faglige handlinger som “opret reklamation”, “frigiv ordre”, “upload dokument”, “bekræft leveringsstatus”.

Effekten i drift er mærkbar: Valideringer sker server-side, fejlmeldinger er reproducerbare, og begge klienter (desktop og portal) udløser samme flow via samme logik.

2) Gør konflikter og gentagne forespørgsler håndterbare

Med en portal stiger sandsynligheden for parallelle ændringer og gentagne requests (fx pga. timeouts, retries eller dobbeltklik fra brugere). Her hjælper tre koncepter uden at indføre permanente låsninger:

• Idempotens: Kritiske handlinger designes, så en gentagelse har samme effekt og ikke udfører handlingen dobbelt. Praktisk opnås dette ofte via en unik request-identifikation (Idempotency Key).
• Optimistic Concurrency: En post bærer versionsinformation (fx “Row Version”). Ved ændringer tjekker servicen, om versionen stadig matcher, og rapporterer konflikter klart tilbage.
• Korte transaktioner: I stedet for at “låse alt” holdes skriveoperationer korte. Lange arbejdsgange (fx eksporter, rapportpakker) køres asynkront.

For tekniske beslutningstagere er det vigtigt: Disse mekanismer reducerer supportarbejdet, fordi fejlscenarier som “det skete to gange” eller “min ændring er væk” bliver langt sjældnere.

3) Modellér tilstande og overdragelser klart

Hvis desktoppen håndterer komplekse sager, og portalen kun leverer ansøgninger eller forstadier, har I brug for definerede statusovergange. Et praktisk snit er: Portalen opretter eller supplerer sager i klart afgrænsede statusområder (fx “indsendt”), desktoppen behandler specialtilfælde, og service-kernen beslutter og protokollerer statusændringer. Så undgår I, at portal-klienten indirekte kan “ødelægge” processer gennem ukontrollerede indgreb.

Data og dokumenter: det ofte undervurderede integrationsområde

Næsten enhver portal indebærer filhåndtering: uploads, bilag, følgesedler, billeder, PDF-udtræk. For administratorer er det et kernepunkt, fordi det påvirker backup, rettigheder, viruskontrol, lagringsomkostninger og performance.

Hvor ligger filer: database, filshare eller objekt-storage?

Der er tre almindelige lagringsmuligheder, som hver medfører en anden driftsrealitet:

• Database (BLOB): godt, når transaktioner skal være strengt koblede, og backup/restore skal være samlet i ét paket. Ulemper er ofte større databaser og længere backup-vinduer.
• Filsystem/Share: typisk on-prem, let at integrere i eksisterende backup-koncepter. Vigtigt er klare rettigheder og et API-lag, der kontrollerer adgangen.
• Objekt-Storage: fornuftigt ved skalering, livscyklusstyring eller når ekstern adgang teknisk skal kapsles pænt. Kræver et bevidst nøgle- og rettighedsmodel.

Uanset lagerplacering gælder: Portalen bør ikke hente filer “direkte” fra et share. Bedre er kontrolleret download via service-endpoints med rettighedstjek, logning og eventuelt tidsbegrænset download-URL.

PDF’er og rapporter: server-side i stedet for dobbeltimplementering

Delphi-desktopapplikationer har ofte voksede udskrivnings- og rapporteringsstrømme. Portaler har ofte brug for de samme indholdstyper som PDF. I stedet for at vedligeholde to implementeringer betaler det sig at centrere dokumentskabelse i service-kernen: skabeloner, versionering og outputformat ligger server-side; desktop og portal forbruger resultatet. For driften giver det klare fordele: sporbare udskrifter, ensartet arkivering og mindre afhængighed af desktopinstallationer.

REST-servere og services: Delphi, C# eller en hybridarkitektur

Ved beslutningen “Delphi eller C#” handler det for virksomheder mindre om ideologi og mere om teamkapacitet, driftsmiljø og vedligeholdbarhed. I mange landskaber er en hybridarkitektur realistisk, så længe ansvarsområderne er klart afgrænsede.

Delphi som serviceplatform: fornuftigt ved eksisterende faglogik

Hvis faglogik og dataadgang allerede er solidt forankret i Delphi, kan en Delphi-baseret REST-server være effektiv. For administratorer og beslutningstagere er det vigtigt: Serverdrift er ikke “desktop i kontinuerlig drift”. En produktiv service kræver klar konfiguration, veldefinerede timeouts, strukturerede logs, health checks og reproducerbart deployment.

Også dataforbindelsen bør moderniseres, hvis der stadig er gamle drivere eller BDE involveret. En BDE-Ablösung og overgangen til moderne dataadgang reducerer driftsforstyrrelser og gør deployment lettere, fordi færre legacy-komponenter skal installeres og vedligeholdes.

C#-services i portaløkosystemet: ofte valgt pga. hosting og identity

Hvis portalen udvikles i et .NET-domineret landskab, er C# Services ofte et naturligt valg – ikke mindst pga. Identity-integration, etablerede driftstandarder og hosting bag Microsoft IIS eller i containeriserede platforme. Det er afgørende at undgå dobbeltimplementering: Enten bevares kernelogikken i Delphi-services og C# tager sig af edge-ansvar (fx portal-specifik orkestrering), eller I planlægger bevidst en migration af logik til .NET – men da kontrolleret og med klare faglige grænser.

API-Gateway: organisatorisk element, men ikke altid nødvendigt

Et API-Gateway kan samle centrale funktioner (routing, rate-limits, logging, autentificering). For mindre startarkitekturer er en konsekvent API med fælles standarder ofte tilstrækkelig. Men når flere services og brugergrupper dukker op, hjælper et gateway med at holde yderkanten stabil og implementere politikker centralt.

Autentificering og rettigheder: fra intern desktop til ekstern portalverden

Med en portal ændres brugerlandskabet: Ud over interne brugere kommer eksterne konti, roller og lejere. Det skaber krav til identity, rettighedsstyring og auditabilitet. For administratorer er det relevant, fordi identity-systemer og rollemodeller er svære at ændre senere.

SSO med SAML 2.0 eller OIDC: mindre admin-arbejde, bedre kontrol

I B2B-opsætninger er SAML 2.0 (Single Sign-On via en Identity Provider) udbredt, fordi virksomheder ønsker at genbruge eksisterende identiteter. OIDC (OpenID Connect) er ligeledes almindeligt, især på mere moderne platforme. Klassiske brugernavn/adgangskode-logins er mulige, men medfører ekstraarbejde for passwordpolitik, MFA, reset-processer og support.

Arkitekturmæssigt er det vigtigt: Autentificering (hvem er du?) og autorisation (hvad må du?) skal altid tjekkes server-side – ikke i portal-frontendet.

Multitenancy og rollemodel: ikke noget man “tilføjer senere”

Et kundesystem/portal kræver praktisk talt altid lejeradskillelse: En kunde må kun se sine data. Det skal modelleres i service-kernen, ideelt via:

• Claims i tokenet (fx Tenant-ID, roller, kontraktforhold), så services kan træffe beslutninger.
• Postniveau-kontroller i forretningslogikken, ikke kun “skjul menupunkter”.
• Audit-trails for vigtige handlinger (hvem, hvad, hvornår) samt korrelation via en request-ID til fejlanalyse.

Desktoppen kan – hvis ønsket – også bruge tokens mod samme identity-stack. Det reducerer specialveje og forenkler sporbarheden af ændringer, især når portal og desktop arbejder på samme poster.

Modernisér dataadgang: FireDAC, PostgreSQL og kontrollerede dataveje

Mange Delphi-desktopløsninger er historisk vokset med direkte DB-adgang. Når en portal tilføjes, bliver det et arkitekturtema: Dataveje skal kunne kontrolleres, valideringer skal være centrale, og performance skal være stabil også under parallelt belastning.

FireDAC som basis for vedligeholdbar dataadgang

BDE-Ablösung mit nativer Anbindung er i Delphi-miljøer en udbredt standard for adgang til moderne databaser. Mindre vigtigt er komponenten i sig selv end standardiseringen: parametrede forespørgsler, klare transaktionsgrænser, ensartet fejlbehandling og målbare svartider. For drift betyder det, at timeouts og ressourceforbrug bliver planlæggelige, og at problemer kan spores i logs og monitoring.

PostgreSQL med Delphi: håndterbart med klart typemapping og migrationskoncept

PostgreSQL med Delphi er robust, hvis typemapping (fx UUID, tidsstempler, JSON-felter), indekser og schema-migrationer håndteres ordentligt. Netop portaler genererer mange filtrerende listeforespørgsler. Derfor bør filter, paging og sortering implementeres server-side, så store datamængder ikke overføres unødigt. Det reducerer belastning og forbedrer brugeroplevelsen, uden at desktoppen bliver langsommere.

Drift, deployment og monitoring: skab portal-modenhed for Delphi-backends

En portal er normalt altid tilgængelig og dermed mere driftsintensiv end en ren desktop. For administratorer er dette området, hvor en god arkitektur straks betaler sig: gennem reproducerbare deployments, klar observability (logs/metrikker) og definerede vedligeholdelsesvinduer.

Windows-service eller Linux-service: driftsmodellen er afgørende

En Delphi-service kan køres som Windows- og Linux-services eller som en Linux-daemon. Mere vigtigt end OS er de standards, der gør driften stabil:

• Health-Checks til monitoring og load balancer (fx “service lever” og “database tilgængelig”).
• Struktureret logging (inkl. request-ID, bruger/tenant, eksekveringstid, statuskoder), så supporttilfælde kan reproduceres.
• Konfiguration uden gen-build (fx miljøvariabler, centrale konfigfiler), så deployments kan automatiseres rent.
• Rollback-evne via klare versioner og migrationssikre databaseændringer.

Belastningsprofiler: Portalen er “mange korte requests” fremfor “få lange sessioner”

Desktopbrug producerer ofte længere arbejdssessioner pr. bruger, mens portaler genererer mange korte, parallelle requests. Typiske tekniske tiltag er:

• konsekvent paging, server-side filtre og begrænsede svarstørrelser
• caching for stamdata og sjældne forespørgsler
• asynkrone jobs for lange opgaver (eksporter, rapport-bundles)
• rate-limits og beskyttelsesmekanismer mod misbrug

For beslutningstagere er det centralt: Performance er ikke “finjustering til sidst”, men en del af API-definitionen (responsstørrelser, timeouts, baggrundsbehandling).

Modernisering uden Big-Bang: en robust vej i fem trin

Et komplet nybyg er sjældent nødvendigt og ofte risikabelt, fordi procesviden ligger i Delphi-klienten. Et fremgangsmåde, hvor hvert trin er produktivt anvendeligt og ikke truer driften, har vist sig holdbar.

1) Kortlægning: processer, dataansvar, integrationer

Start ikke ved skærmbilleder, men ved use cases: Hvilke flows skal i portalen? Hvilke data må en ekstern bruger se eller ændre? Hvilke integrationer findes til ERP, DMS eller CRM? Herfra opstår en prioriteret API-liste, der leverer reel værdi.

2) Definér service-basics: auth, fejlformat, logging, versionering

Denne basis afgør den fremtidige vedligeholdbarhed. Aftal tidligt standarder for autentificering/autorisation, et konsistent fejlformat, request-korrelation, API-versionering og telemetri. Det reducerer gnidning mellem portalteam, backendteam og drift.

3) Lever den første portalstrækning end-to-end

Vælg et flow med klar afgrænsning (fx dokumentområde eller statusforespørgsel). Det er vigtigt, at hele kæden fungerer: login, rettighedskontrol, API, UI, logging, monitoring, drift. Så kan organisationen tidligt vurdere, hvilke standarder der virker i praksis.

4) Tilslut desktop målrettet: kritiske skriveveje via services

Når services er stabile, flytter I udvalgte desktopfunktioner over: særligt statusændringer, godkendelser eller centrale valideringer. Desktoppen forbliver effektiv, men reglerne bliver mere konsistente, og direkte DB-skriv adgang reduceres gradvist.

5) Konsolider: fjern dobbeltregler og specialveje

Ellers opstår der over tid “to systemer”. Planlæg regelmæssig konsolidering: Hvilke regler findes dobbelt? Hvor kan portalen bruge desktop-servicen? Hvilke rapporter bør genereres centralt? Målet er en håndterbar platform, ikke et dogme.

Typiske faldgruber set fra drift – og hvordan I undgår dem

Regler bygges igen i portalen

Det fører til afvigelser og supporttilfælde. Modforanstaltning: Use-Case-APIs med server-side valideringer, klare fejltilbagemeldinger og, hvis muligt, fælles faglige tests.

Uklart dataansvar mellem desktop og portal

Hvis begge klienter må ændre “alt”, opstår konflikter. Modforanstaltning: statusmodel, definerede ansvarsområder og Optimistic Concurrency for konkurrerende ændringer.

Sikkerhed ses som et efterfølgende tillæg

Især i kundesystemer er SSO, lejerkontroller, sikre fil-downloads og audit nødvendigt fra starten. Efterfølgende implementering er dyrere og øger risikoen for sikkerhedshuller.

Manglende transparens i driften

Uden request-IDs, strukturerede logs og health checks bliver fejlfinding til detektivarbejde. Modforanstaltning: Observability som obligatorisk del af de første service-releases.

Konklusion: En service-kerne forbinder desktopstyrke med portal-rækkevidde

Kombinationen af Delphi-desktop og webportal er i mange virksomheder den mest realistiske vej til at bevare kerneprocesser og samtidig muliggøre ekstern samarbejde. Afgørende er, at I ikke driver to adskilte verdener, men skaber en sammenbindende service-kerne: Use-Case-APIs, klare rettigheder, sporbare tilstande, kontrollerede dataveje og et driftsmønster med logging, monitoring og planlagte deployments.

Så opnås en modernisering med mellemmål: Desktoppen forbliver produktiv, portalen leverer tidlig værdi, og arkitekturen bliver trinvis mere konsistent og vedligeholdelsesvenlig.

I det faglige rum spiller også Delphi Modernisierung en vigtig rolle, når integrationer, dataflows og videreudvikling skal spille sammen.

Projekt eller moderniseringsinitiativ med Net-Base drøfte.