Kombinera Delphi Desktop och webbportaler: arkitektur, gränssnitt och modernisering utan avbrott

I många företag har det affärslogiska navet under år vuxit fram som en Delphi-desktopapplikation: VCL-klient, djup processkunskap, snabb datafångst, utskrifts- och rapporteringsflöden, specialhårdvara och ofta direkt databasåtkomst i LAN. Samtidigt ökar förväntningarna på self-service och extern samverkan: kunder vill kontrollera orderstatus, utbyta dokument eller registrera reklamationer – utan VPN, utan desktop-rollout och utan lokala installationer.

Delphi Desktop och webbportaler i kombination betyder i praktiken att föra samman dessa två världar så att drift, säkerhet och datakonsistens förblir hanterbara. Avgörande är inte att „återskapa“ formulär i webbläsaren, utan en arkitektur som tydligt separerar processer, behörigheter och datavägar och låter båda klienttyperna arbeta enligt gemensamma regler. Vinsten är en moderniseringsväg utan Big-Bang: desktopen förblir produktiv medan webbportalen växer kontrollerat.

Detta inlägg vänder sig till IT-ledning, administratörer och tekniska projektansvariga. Fokus ligger på konsekvenser för drift, administration, gränssnitt, säkerhet, datahantering och migration – mindre på ramverksdetaljer. Du får praktiska mönster, beslutskriterier och typiska fallgropar inklusive motåtgärder.

Varför „Portal istället för Desktop“ sällan är realistiskt

I B2B-miljöer finns många skäl till att en desktopklient fortsatt är motiverad. Administratörer möter detta ofta konkret: en portal är idealisk för distribuerade användare, men vissa uppgifter förblir mer effektiva eller bara möjliga i desktopmiljö.

Desktopens styrkor som räknas i vardagen

• Komplex datafångst med mycket täta formulär, tangentbordsdrift, stora tabellvyer och snabba byten mellan poster.
• Periferi och lokala integrationer som etikettutskriftsenheter, skannrar, seriella enheter eller speciella Windows-komponenter.
• LAN-nära prestanda när stora datamängder bearbetas eller en process kräver extremt låg latens.
• Växande arbetsflöden med många specialfall där en 1:1-portning till en portal initialt innebär höga risker.

Portalens styrkor som täcker nya krav

• Extern åtkomst för kunder, leverantörer eller partner utan att någon klient behöver distribueras.
• Central styrning (versioner, funktioner, behörigheter) med en tydlig yttergräns.
• Enhetsoberoende (webbläsare, mobil användning) för fältpersonal och ledning.
• Målstyrd processöppning som statusfrågor, uppladdningar, godkännanden eller ticket-flöden.

I kombination ligger nyttan: desktopen förblir verktyget för avancerade interna roller, portalen blir den kontrollerade ingången för externa användargrupper. För att detta inte ska utvecklas till två parallella „sanningar“ behövs en sammanlänkande kärna.

När ni kombinerar Delphi Desktop och webbportaler: tre målarkitekturer

Vid arkitekturbeslutet handlar det framför allt om ansvar: var ligger den affärsmässiga regeln? Vem får ändra data? Vilket lager är „Single Source of Truth“ (alltså den avgörande källan för regler och tillstånd)? För tekniska beslutsfattare är det viktigt: valet får direkt konsekvenser för drift, felsökning, release-hantering och säkerhet.

Variant A: Portal som komplement via REST-API, desktopen förblir ledande

Portalen betjänar utvalda use cases, typiskt „läsa och initiera“: status, dokument, godkännanden, enkla registreringar. För detta införs en Delphi REST-API eller en separat REST-server. Desktopapplikationen kan initialt fortsätta att ha direkt databasåtkomst.

Operativ fördel: snabb start, små ingrepp i desktopen, lämpligt för en första portalnytta.

Riskpunkt: det finns två datavägar (Desktop → DB direkt, Portal → API). Om affärsregler enbart ligger i desktopen uppstår inkonsistenser. Som motåtgärd bör portalens funktioner medvetet börja där regler är enkla att avbilda server-side (t.ex. dokumenttillgänglighet, statusfrågor, definierade godkännandeåtgärder).

Variant B: Service-kärna som gemensamt processlager (rekommenderas vid parallell drift)

Här flyttar ni successivt affärslogik från desktopen till services. Desktop och portal använder samma endpoints. Desktopen blir mer av en Rich Client (UI, lokala integrationer), medan regler och valideringar ligger server-side.

Operativ fördel: en central punkt för behörigheter, audit, statuslogik och valideringar; konsekvent beteende över alla klienter.

Ansträngning: högre initialt, eftersom API-standarder, felformat, versionering, övervakning och distribution måste planeras noggrant. Däremot minskar arbetet senare avsevärt eftersom färre specialvägar kvarstår.

Variant C: Portalen i förarsätet, desktopen kvar som specialistklient

Denna variant är lämplig om webbläsaren strategiskt ska bli standardåtkomst (t.ex. mycket distribuerade organisationer), medan desktopen kvarstår för vissa roller med specialhårdvara eller högpresterande insamling. Service-kärnan måste i så fall vara extra stabil och skalbar.

Layer-3 arkitektur som en begriplig ledstjärna

Oavsett variant hjälper en Layer-3 Arkitektur: (1) presentation (desktop/portal), (2) applikations- och domänlager (use cases, regler), (3) infrastruktur (databas, filstorage, messaging, externa system). För administratörer är detta viktigt eftersom driftgränserna blir tydliga: vad är ett „frontend-problem“, vad är ett „service-problem“, vad ligger i databasen eller i lagringen? Denna separation förkortar felsökning och minskar sidoeffekter vid deploys.

Praktisk koppling: Hur desktop och portal delar samma process

Den största utmaningen är sällan att „bygga portalen“, utan frågan: hur delar desktop och portal ansvar i samma process utan att regler implementeras dubbelt? Tre mönster är i praktiken särskilt relevanta.

1) Use-Case-APIs istället för tabell- eller CRUD-API:er

En vanlig återvändsgränd är en API som bara avbildar databastabeller utåt („Create/Read/Update/Delete“). Då måste regler återskapas i portalen och desktopen behåller sina egna regler. Bättre är Use-Case-APIs: endpoints som beskriver affärsaktioner som „skapa reklamation“, „frigiv order“, „ladda upp dokument“, „bekräfta leveransstatus“.

Effekten i drift är tydlig: valideringar sker server-side, felmeddelanden är reproducerbara och båda klienterna (desktop och portal) utlöser samma flöde via samma logik.

2) Hantera konflikter och upprepningar

Med en portal ökar sannolikheten för parallella ändringar och upprepade requests (t.ex. genom timeouts, retries eller dubbelklick från användare). Här hjälper tre koncept utan att införa långvariga lås:

• Idempotens: kritiska åtgärder utformas så att en upprepning ger samma effekt och inte utförs dubbelt. Praktiskt uppnås detta ofta via en entydig request-identifierare (Idempotency Key).
• Optimistic Concurrency: en post bär versionsinformation (t.ex. „Row Version“). Vid ändring kontrollerar servicen att versionen fortfarande stämmer och rapporterar konflikter tydligt tillbaka.
• Korta transaktioner: i stället för att „låsa allt“ hålls skrivoperationer korta. Långa arbeten (t.ex. exporter, rapportpaket) körs asynkront.

För tekniska beslutsfattare är det viktigt: dessa mekanismer minskar supportbehovet eftersom felbilderna („det hände två gånger“, „min ändring försvann“) blir betydligt ovanligare.

3) Modellera tillstånd och överlämningar tydligt

Om desktopen hanterar komplexa fall och portalen „bara“ levererar ansökningar eller förstadier, behöver ni definierade statusövergångar. Ett praktiskt snitt är: portalen skapar eller kompletterar ärenden i klart avgränsade statusområden (t.ex. „insänt“), desktopen hanterar specialfallen, service-kärnan beslutar och loggar statusförändringar. Så undviker ni att portal-klienten indirekt kan „sabotera konfigurationen“ av processer.

Data och dokument: det ofta underskattade integrationsområdet

Nästan varje portal inkluderar filflöden: uppladdningar, intyg, följesedlar, bilder, PDF-utskrifter. För administratörer är detta en kärnfråga eftersom det påverkar backup, behörigheter, viruskontroller, lagringskostnader och prestanda.

Var lagras filer: databas, filshare eller objektlagring?

Det finns tre vanliga lagringsalternativ som vardera leder till olika driftrealiteter:

• Databas (BLOB): bra när transaktioner måste vara strikt kopplade och backup/restore ska vara ett paket. Nackdelar är ofta större databaser och längre backup-fönster.
• Filsystem/Share: typiskt On-Prem, lätt att integrera i befintliga backupkoncept. Viktigt är tydliga behörigheter och ett API-lager som kontrollerar åtkomsten.
• Objekt-Storage: lämpligt vid skalning, livscykelregler eller när extern åtkomst ska kapslas tekniskt. Förutsätter en medveten nyckel- och behörighetsmodell.

Oavsett lagringsplats gäller: portalen bör inte läsa filer „direkt“ från ett share. Bättre är en kontrollerad nedladdning via service-endpoints med behörighetskontroll, loggning och eventuellt tidsbegränsade nedladdnings-URL:er.

PDF:er och rapporter: server-side i stället för dubbla implementeringar

Delphi-desktopapplikationer har ofta växande utskrifts- och rapporteringskedjor. Portaler behöver ofta samma innehåll som PDF. I stället för att underhålla två implementationer lönar det sig med central dokumentgenerering i service-kärnan: mallar, versionering och utdataformat ligger server-side; desktop och portal konsumerar resultatet. För driften ger det klara fördelar: spårbara utskrifter, enhetlig lagring och mindre beroende av desktopinstallationer.

REST-servrar och services: Delphi, C# eller en hybridarkitektur

Vid frågan „Delphi eller C#“ handlar det mindre om ideologi och mer om teamkapacitet, driftmiljö och underhållbarhet. I många miljöer är en hybridarkitektur realistisk, så länge ansvarsgränserna är tydligt definierade.

Delphi som serviceplattform: meningsfullt vid befintlig affärslogik

Om affärslogik och dataåtkomst redan är väl förankrade i Delphi kan en Delphi-baserad REST-server vara effektiv. För administratörer och beslutsfattare är det viktigt: serverdrift är inte „desktop i nonstop-läge“. En produktiv service kräver tydlig konfiguration, väldefinierade timeouts, strukturerade loggar, health checks och reproducerbar deployment.

Även dataanslutningen bör moderniseras om gamla drivrutiner eller BDE fortfarande används. En BDE-ersättning och övergång till moderna dataåtkomster minskar driftstörningar och förenklar distributionen eftersom färre legacy-komponenter behöver installeras och underhållas.

C#-services i portalekosystemet: ofta driven av hosting och identity

Om portalen byggs i en .NET-dominerad miljö är C# Services ofta ett naturligt val – inte minst på grund av identityintegration, etablerade driftstandarder och hosting bakom Microsoft IIS eller i containeriserade plattformar. Avgörande är att undvika dubbelimplementation: antingen behålls kärnlogiken i Delphi-services och C# tar hand om edge-ämnen (t.ex. portal-specifik orkestrering), eller så planerar ni medvetet en migration av logik till .NET – men då kontrollerat och med tydliga domängränser.

API-gateway: ett ordningselement men inte ett måste

En API-gateway kan samla centrala funktioner (routing, rate-limits, logging, autentisering). För mindre startarkitekturer räcker ofta en konsekvent API med enhetliga standarder. Men så snart flera services och användargrupper finns hjälper en gateway att hålla yttergränsen stabil och att centralt tillämpa policies.

Autentisering och rättigheter: från intern desktop till extern portalvärld

Med en portal förändras användarlandskapet: förutom interna användare tillkommer externa konton, roller och kunder/tenanter. Det ger krav på identity, behörigheter och audit-spårning. För administratörer är detta viktigt eftersom identity-system och rollmodeller är svåra att ändra i efterhand.

SSO med SAML 2.0 eller OIDC: mindre adminarbete, bättre kontroll

I B2B-sammanhang är SAML 2.0 (Single Sign-on via en Identity Provider) vanligt eftersom företag vill återanvända befintliga identiteter. OIDC (OpenID Connect) är också vanligt, särskilt i modernare plattformar. Klassiska användarnamn/lösenord-inloggningar är möjliga men medför extra arbete för lösenordspolicy, MFA, återställningsprocesser och support.

Viktigt för arkitekturen: autentisering (vem är du?) och auktorisering (vad får du göra?) måste kontrolleras server-side – inte i portalens frontend.

Multitenans och rollmodell: komplettera inte „senare“

En kundportal kräver praktiskt taget alltid tenanthantering: en kund ser bara sina data. Detta måste modelleras i service-kärnan, idealiskt via:

• Claims i tokenet (t.ex. tenant-ID, roller, kontraktskoppling) så att services kan fatta beslut.
• Postbaserade kontroller (Row-Level-Checks i affärslogiken), inte bara att „dölja menyer“.
• Audit-trails för viktiga åtgärder (vem, vad, när), plus korrelation via en request-ID för felsökning.

Desktopen kan – om så önskas – också arbeta med tokens mot samma identity-stack. Det minskar specialvägar och förenklar spårbarheten av ändringar, särskilt när portal och desktop arbetar på samma post.

Modernisera dataåtkomst: FireDAC, PostgreSQL och kontrollerade datavägar

Många Delphi-desktoplösningar har historiskt vuxit fram med direkt DB-åtkomst. Så snart en portal tillkommer blir det ett arkitekturtema: datavägar måste vara kontrollerbara, valideringar måste gälla centralt och prestanda måste förbli stabil även under parallell belastning.

FireDAC som bas för underhållbar dataåtkomst

BDE-ersättning med native-anslutning är i Delphi-miljöer en vedertagen standard för åtkomst till moderna databaser. Viktigare än komponenten i sig är standardiseringen: parametriserade frågor, rena transaktionsgränser, enhetlig felhantering och mätbara körtider. För driften räknas att timeouts och resursförbrukning blir planbara och att problem kan spåras i loggar och övervakning.

PostgreSQL med Delphi: väl hanterbart med rent typ- och migrationskoncept

PostgreSQL med Delphi är robust om typmappning (t.ex. UUID, tidsstämplar, JSON-fält), index och schemamigrationer hanteras noggrant. Speciellt portaler genererar många filtrerande listfrågor. Filter, paginering och sortering bör därför implementeras server-side så att stora datamängder inte överförs i onödan. Det minskar belastning och förbättrar användarupplevelsen utan att desktopen blir långsammare.

Drift, deployment och monitoring: skapa portalmognad för Delphi-backends

En portal är normalt alltid tillgänglig och därmed mer driftintensiv än en ren desktop. För administratörer är detta området där en god arkitektur snabbt betalar sig: genom reproducerbara deploys, tydlig observability (loggar/metriker) och definierade underhållsfönster.

Windows-service eller Linux-service: avgörande är driftsmodellen

En Delphi-service kan köras som Windows- och Linux-services eller som en Linux-daemon. Viktigare än operativsystemet är standarder som gör driften stabil:

• Health-Checks för övervakning och lastbalanserare (t.ex. „service lever“ och „databas nåbar“).
• Strukturerad logging (inkl. request-ID, användare/tenant, körtid, statuskoder) så att supportfall blir reproducerbara.
• Konfiguration utan rebuild (t.ex. miljövariabler, centrala konfigurationsfiler) så att deploys kan automatiseras rent.
• Rollback-förmåga genom tydliga versioner och migrationssäkra databasändringar.

Belastningsprofiler: portalen är „många korta requests“ i stället för „få långa sessioner“

Desktopanvändning genererar ofta längre arbetsperioder per användare, medan portaler ger många korta parallella requests. Typiska tekniska åtgärder är:

• konsekvent paginering, server-side filter och begränsade svarsstorlekar
• caching för masterdata och sällan ändrade frågor
• asynkrona jobb för långa uppgifter (exporter, rapportpaket)
• rate-limits och skydd mot missbruk

För beslutsfattare är centralt här: prestanda är inte „finjustering i slutet“, utan en del av API-definitionen (svarsstorlekar, timeouts, bakgrundsbehandling).

Modernisering utan Big-Bang: en robust väg i fem steg

En fullständig nyutveckling är sällan nödvändig och ofta riskfylld eftersom processkunskapen ligger i Delphi-klienten. Ett arbetssätt som visat sig fungera innebär att varje steg är produktivt och inte äventyrar driften.

1) Inventering: processer, dataägarskap, integrationer

Börja inte med formulär utan med use cases: vilka flöden ska till portalen? Vilka data får en extern användare se eller ändra? Vilka gränssnitt finns mot ERP, DMS eller CRM? Därifrån skapas en prioriterad lista över API:er som ger verkligt värde.

2) Definiera service-basics: auth, felformat, logging, versionering

Dessa grunder avgör framtida underhållbarhet. Kom överens tidigt om standarder för autentisering/auktorisering, ett konsekvent felformat, request-korrelation, API-versionering och telemetri. Det minskar friktion mellan portalteam, backendteam och drift.

3) Leverera en första portalsträcka end-to-end

Välj ett flöde med tydlig avgränsning (t.ex. dokumentområde eller statusfråga). Viktigt är att hela kedjan finns: login, behörighetskontroll, API, UI, logging, monitoring, drift. Då förstår organisationen tidigt vilka standarder som funkar i vardagen.

4) Koppla desktopen målmedvetet: kritiska skrivvägar över services

När services är stabila flyttar ni utvalda desktopfunktioner dit: särskilt statusbyten, godkännanden eller centrala valideringar. Desktopen förblir snabb, men reglerna blir mer konsekventa och direkt DB-skrivåtkomst minskas stegvis.

5) Konsolidera: avskaffa dubbla regler och specialvägar

Annars uppstår över tiden „två system“. Planera regelbunden konsolidering: vilka regler finns dubbelt? Var kan portalen använda desktop-service? Vilka rapporter bör genereras centralt? Målet är en hanterbar plattform, inte en doktrin.

Typiska fallgropar ur driftsynpunkt – och hur ni undviker dem

Regler byggs om i portalen

Det leder till avvikelser och supportfall. Motåtgärd: Use-Case-APIs med server-side valideringar, tydliga felreturer och om möjligt gemensamma affärstester.

Otydligt dataägarskap mellan desktop och portal

Om båda klienterna får ändra „allt“ uppstår konflikter. Motåtgärd: statusmodell, definierade ansvarsgränser och Optimistic Concurrency för konkurrerande ändringar.

Säkerhet betraktas som en efterhandskonstruktion

Särskilt för kundportaler krävs SSO, tenant-kontroller, säkra filnedladdningar och audit från början. I efterhand är det dyrare och ökar risken för säkerhetsbrister.

Brister i driftsynlighet

Utan request-ID:er, strukturerade loggar och health checks blir felsökning detektivarbete. Motåtgärd: observability som ett krav i de första service-releaserna.

Slutsats: en service-kärna förenar desktopstyrka med portalens räckvidd

Kombinationen av Delphi-desktop och webbportal är i många företag den mest realistiska vägen för att behålla kärnprocesser och samtidigt möjliggöra extern samverkan. Avgörande är att ni inte driver två separata världar, utan skapar en sammanlänkande service-kärna: Use-Case-APIs, rena behörigheter, spårbara tillstånd, kontrollerade datavägar och ett driftsmönster med logging, monitoring och planbara deployment-fönster.

Så uppstår en modernisering med delmål: desktopen förblir produktiv, portalen levererar tidigt värde och arkitekturen blir stegvis mer konsekvent och underhållbar.

I det fackliga sammanhanget spelar även Delphi Modernisierung en viktig roll när integrationer, dataflöden och vidareutveckling måste fungera tillsammans.

Projekt eller moderniseringsprojekt med Net-Base diskutera.