Kombinere Delphi Desktop og webportaler: Arkitektur, grensesnitt og modernisering uten brudd

I mange bedrifter har den faglige „kontrollsenteret“ vokst fram over år som en Delphi-desktopapplikasjon: VCL-klient, dyp prosesskunnskap, rask datainnsamling, utskrifts- og rapportstrømmer, spesialmaskinvare og ofte direkte databaseaksess i LAN. Samtidig øker forventningene til selvbetjening og ekstern samarbeid: kunder vil sjekke ordrestatus, utveksle dokumenter eller registrere reklamasjoner – uten VPN, uten desktoputrulling og uten lokale installasjoner.

Delphi-desktop og webportaler kombinert betyr i praksis å forene disse to verdene slik at drift, sikkerhet og datakonsistens forblir håndterbare. Avgørende er ikke å „gjenbygge“ skjermbilder i nettleseren, men en arkitektur som skiller prosesser, rettigheter og dataflyt tydelig og lar begge klienttyper operere etter felles regler. Gevinsten er en moderniseringsvei uten Big-Bang: desktop-en forblir produktiv mens webportalen vokser kontrollert.

Denne artikkelen er rettet mot IT-ledelse, administratorer og tekniske prosjektansvarlige. Fokus ligger på konsekvenser for drift, administrasjon, grensesnitt, sikkerhet, datalagring og migrasjon – ikke rammeverksdetaljer. Du får praktiske mønstre, beslutningskriterier og typiske fallgruver inkludert mottiltak.

Hvorfor «Portal i stedet for Desktop» sjelden er realistisk

I B2B-miljøer finnes det mange grunner til at en desktopklient fortsatt er fornuftig. Administratorer opplever dette ofte konkret: en portal er ideell for distribuerte brukere, men enkelte oppgaver forblir mer effektive i desktop eller er bare mulig der.

Desktop-fordeler som betyr noe i hverdagen

• Kompleks datainnsamling med svært tette skjermbilder, tastaturstyring, store tabellvisninger og raske bytter mellom poster.
• Periferi og lokale integrasjoner som etikettprintere, skannere, serielle enheter eller spesielle Windows-komponenter.
• LAN-nær ytelse når store datamengder behandles eller en prosess krever ekstremt lav latenstid.
• Voksne arbeidsflyter med mange spesialtilfeller, der et 1:1-port til en portal innledningsvis medfører høy risiko.

Portal-fordeler som dekker nye krav

• Ekstern tilgang for kunder, leverandører eller partnere uten at en klient må distribueres.
• Sentralt styrbart (versjoner, funksjoner, rettigheter) med en tydelig yttergrense.
• Enhetsuavhengighet (nettleser, mobilbruk) for feltarbeid og ledelse.
• Målrettede prosessåpninger som statusforespørsler, opplastinger, godkjenninger eller saksflyt.

Nytten ligger i kombinasjonen: desktop-en forblir verktøyet for interne roller, portalen blir kontrollert tilgang for eksterne brukergrupper. For at dette ikke skal bli to parallelle „sannheter“, trengs en sammenbindende kjerne.

Når du kombinerer Delphi-desktop og webporter: tre målarkitekturer

Arkitekturvalget handler i hovedsak om ansvar: hvor ligger den faglige regelen? Hvem får endre data? Hvilket lag er „Single Source of Truth“ (altså den autoritative kilden for regler og tilstander)? For tekniske beslutningstakere er det viktig: valget har direkte konsekvenser for drift, feilsøking, release-håndtering og sikkerhet.

Variant A: Portal som tillegg via REST-API, desktop forblir førende

Portalen dekker utvalgte use-caser, typisk „lese og utløse“: status, dokumenter, godkjenninger, enkle registreringer. Til dette innføres en Delphi REST-API eller en separat REST-server. Desktop-applikasjonen kan i første omgang fortsatt ha direkte databaseaksess.

Operativ fordel: rask oppstart, få inngrep i desktop, egnet for tidlig portalverdi.

Risiko: det finnes to dataflyter (desktop → DB direkte, portal → API). Hvis forretningsreglene ligger kun i desktop, oppstår inkonsistenser. Mottiltak er å starte portal-funksjoner der reglene er enkle og kan ligge server-side (f.eks. dokumenttilgjengeliggjøring, statusforespørsler, definerte godkjenningshandlinger).

Variant B: Service-kjerne som felles proseslag (anbefalt ved parallell drift)

Her flytter dere stegvis forretningslogikk ut av desktop og inn i tjenester. Desktop og portal bruker samme endepunkter. Desktop blir tydeligere en Rich Client (UI, lokale integrasjoner), mens regler og valideringer ligger på serversiden.

Operativ fordel: ett sentralt sted for rettigheter, audit, statuslogikk og valideringer; konsistent oppførsel på tvers av frontender.

Innsats: høyere i starten, fordi API-standarder, feilformater, versjonering, monitoring og deployment må planlegges grundig. Til gjengjeld blir innsatsen senere betydelig lavere, fordi færre spesialveier oppstår.

Variant C: Portal fører, desktop forblir som spesialklient

Denne varianten gir mening hvis nettleseren skal være strategisk standardtilgang (f.eks. sterkt distribuert organisasjon), samtidig som desktop-en for visse roller med spesialmaskinvare eller høyytelsesregistrering blir værende. Service-kjernen må da være spesielt stabil og skalerbar.

Layer-3-arkitektur som forståelig rettesnor

Uavhengig av variant hjelper en Layer-3-arkitektur: (1) presentasjon (desktop/portal), (2) applikasjons- og domenelag (use-cases, regler), (3) infrastruktur (database, fil-lagring, meldingstjenester, eksterne systemer). For administratorer er dette viktig fordi driftsgrensene blir tydelige: hva er et „frontend-problem“, hva er et „service-problem“, hva ligger i databasen eller i storage? Denne separasjonen forkorter feilsøking og reduserer sideeffekter ved deploy.

Praksisnærhet: Hvordan desktop og portal deler samme prosess

Den største utfordringen er sjelden å „bygge portalen“, men spørsmålet: hvordan deler desktop og portal ansvar i samme prosess uten at regler implementeres dobbelt? Tre mønstre er særlig relevante i praksis.

1) Use-Case-APIer i stedet for tabell- eller CRUD-APIer

En vanlig blindvei er en API som kun speiler databastabeller utad („Create/Read/Update/Delete“). Da må reglene bygges opp igjen i portalen, og desktop-en forblir med sine egne regler. Bedre er Use-Case-APIer: endepunkter beskriver faglige handlinger som „opprett reklamasjon“, „frigjør ordre“, „last opp dokument“, „bekreft leveringsstatus“.

Effekten i drift er merkbar: valideringer skjer server-side, feilmeldinger er reproduserbare, og begge klienter (desktop og portal) utløser samme flyt via samme logikk.

2) Gjør konflikter og gjentakelser håndterbare

Med en portal øker sannsynligheten for parallelle endringer og gjentatte requests (f.eks. pga. timeouts, retries eller dobleklikk fra brukere). Tre konsepter hjelper uten å innføre permanente låser:

• Idempotens: kritiske handlinger utformes slik at en gjentakelse gir samme effekt og ikke dupliserer. Praktisk løses dette ofte med en entydig request-identifikator (Idempotency Key).
• Optimistisk samtidighetskontroll: en post bærer versjonsinformasjon (f.eks. „Row Version“). Ved endring sjekker tjenesten om versjonen fortsatt stemmer og returnerer konflikter ryddig.
• Korte transaksjoner: i stedet for å „låse alt“ holdes skriveoperasjoner korte. Lange arbeid (f.eks. eksport, rapportpakker) kjøres asynkront.

For tekniske beslutningstakere er det viktig: disse mekanismene reduserer supportbelastningen fordi feilbildene („skjedde to ganger“, „min endring forsvant“) blir langt sjeldnere.

3) Modellér tilstander og overleveringer tydelig

Hvis desktop-en håndterer komplekse tilfeller og portalen „kun“ leverer innsendelser eller forløp, trenger dere definerte statusoverganger. Et praktisk oppsett er: portalen oppretter eller kompletterer saker i klart avgrensede statusområder (f.eks. „innsendt“), desktop-en behandler spesialtilfeller, og service-kjernen avgjør og logger statusendringer. Slik unngår dere at portal-klienten indirekte kan „feilkonfigurere“ prosesser.

Data og dokumenter: det ofte undervurderte integrasjonsområdet

Nesten alle portaler inkluderer filhåndtering: opplastinger, bevis, følgesedler, bilder, PDF-utdata. For administratorer er dette et kjernepunkt fordi det påvirker backup, rettigheter, viruskontroll, lagringskostnader og ytelse.

Hvor lagres filer: database, filshare eller objektlagring?

Det finnes tre vanlige lagringsalternativer, som hver gir en forskjellig driftsrealitet:

• Database (BLOB): nyttig når transaksjoner må være strengt koblet og backup/restore skal være ett komplett pakke. Ulempen er ofte større databaser og lengre backup-vinduer.
• Filesystem/Share: typisk on-prem, lett å integrere i eksisterende backup-konsepter. Viktig med klare tilgangsrettigheter og et API-lag som kontrollerer tilgangen.
• Objekt-Storage: fornuftig ved skalering, livssyklusregler eller når ekstern tilgang teknisk skal kapsles rent. Krever et bevisst nøkkel- og rettighetsmodell.

Uavhengig av lagringssted gjelder: portalen bør ikke laste filer direkte fra et share. Bedre er kontrollert nedlasting via service-endepunkter med rettighetssjekk, logging og valgfritt tidsbegrensede nedlastings-URLer.

PDFer og rapporter: server-side i stedet for dobbeltimplementasjon

Delphi-desktopapplikasjoner har ofte modne utskrifts- og rapporteringsstrømmer. Portaler trenger ofte de samme innholdene som PDF. I stedet for å vedlikeholde to implementasjoner lønner det seg med sentral dokumentgenerering i service-kjernen: maler, versjonering og output-format ligger server-side; desktop og portal konsumerer resultatet. For driften gir dette klare fordeler: etterprøvbare utskrifter, enhetlig lagring og mindre avhengighet av desktop-installasjoner.

REST-server og tjenester: Delphi, C# eller en hybridarkitektur

Valget „Delphi eller C#“ handler mindre om ideologi og mer om teamets ferdigheter, driftsmiljø og vedlikeholdbarhet. I mange miljøer er en hybridarkitektur realistisk, så lenge ansvarsområder er klart avgrenset.

Delphi som serviceplattform: fornuftig når faglogikk allerede finnes

Hvis faglogikk og dataaksess allerede ligger solid i Delphi, kan en Delphi-basert REST-server være effektiv. For administratorer og beslutningstakere er det viktig: serverdrift er ikke „desktop i kontinuerlig drift“. En produksjonstjeneste trenger klar konfigurasjon, ryddige timeouts, strukturert logging, health checks og reproducerbar deploy.

Også data-tilknytningen bør moderniseres dersom gamle drivere eller BDE er i bruk. En BDE-avløsning og overgang til moderne dataaksess reduserer driftsforstyrrelser og forenkler deployment fordi færre legacy-komponenter må installeres og vedlikeholdes.

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

Hvis portalen bygges i et .NET-dominert landskap, er C#-tjenester ofte naturlige – ikke minst på grunn av identity-integrasjon, eksisterende driftsstandarder og hosting bak Microsoft IIS eller i containeriserte plattformer. Avgjørende er å unngå dobbelimplementasjon: enten forblir kjernelogikken i Delphi-tjenester og C# tar edge-oppgaver (f.eks. portal-spesifikk orkestrering), eller dere planlegger kontrollert migrasjon av logikk til .NET med klare fagavgrensninger.

API-Gateway: ordnende element, men ikke et krav

Et API-Gateway kan samle sentrale funksjoner (routing, rate-limits, logging, autentisering). For mindre startarkitekturer er ofte en konsistent API med enhetlige standarder tilstrekkelig. Når flere tjenester og brukergrupper finnes, hjelper et gateway imidlertid med å holde yttergrensen stabil og håndheve policyer sentralt.

Autentisering og rettigheter: fra intern desktop til ekstern portalverden

Med en portal endres brukerbildet: i tillegg til interne brukere kommer eksterne kontoer, roller og tenants. Det gir krav til identity, autorisasjon og audit. For administratorer er dette relevant fordi identity-systemer og rollemodeller er vanskelige å endre senere.

SSO med SAML 2.0 eller OIDC: mindre administrasjonsarbeid, bedre kontroll

I B2B-oppsett er SAML 2.0 (single sign-on via en identity provider) utbredt fordi bedrifter vil bruke eksisterende identiteter. OIDC (OpenID Connect) er også vanlig, spesielt i moderne plattformer. Klassisk brukernavn/passord er mulig, men medfører ekstra arbeid for passordpolitikk, MFA, reset-prosesser og support.

Viktig for arkitekturen: autentisering (hvem er du?) og autorisering (hva har du lov til?) må sjekkes server-side – ikke i portal-frontend.

Multitenancy og rollemodell: ikke legg til «senere»

Et kundesystem krever praktisk talt alltid tenant-separasjon: en kunde skal kun se sine data. Dette må modelleres i service-kjernen, ideelt gjennom:

• Claims i tokenet (f.eks. Tenant-ID, roller, kontraktsreferanse) slik at tjenester kan fatte beslutninger.
• Postbaserte kontroller (Row-Level-Checks i faglogikken), ikke bare å „skjule menyer“.
• Audit-trekk for viktige handlinger (hvem, hva, når), pluss korrelasjon via en Request-ID for feilanalyse.

Desktop-en kan – om ønskelig – også jobbe med tokens mot samme identity-stack. Det reduserer spesialveier og gjør endringer mer etterprøvbare, særlig når portal og desktop redigerer samme post.

Moderniser dataaksess: FireDAC, PostgreSQL og kontrollerte dataflyter

Mange Delphi-desktopløsninger er historisk vokst med direkte DB-tilgang. Når en portal skal legges til, blir dette et arkitekturtema: dataflyter må være kontrollerbare, valideringer må være sentrale, og ytelsen må være stabil også under parallell last.

FireDAC som grunnlag for vedlikeholdbar dataaksess

BDE-avløsning med native tilkobling er i Delphi-miljøer en utbredt standard for tilgang til moderne databaser. Viktigere enn komponenten er standardiseringen: parameteriserte spørringer, klare transaksjonsgrenser, enhetlig feilhåndtering og målbare responstider. For drift betyr det at timeouts og ressursforbruk blir planbare og at problemer kan spores i logger og monitoring.

PostgreSQL med Delphi: godt håndterbart med et ryddig typemapping- og migrasjonskonsept

PostgreSQL med Delphi er robust når typemapping (f.eks. UUID, tidsstempler, JSON-felt), indekser og skjema-migrasjoner håndteres konsekvent. Spesielt portaler genererer mange filtrerende listeforespørsler. Derfor bør filtrering, paging og sortering gjøres server-side slik at ikke store datamengder sendes unødvendig. Det reduserer last og forbedrer brukeropplevelsen uten å gjøre desktop-en tregere.

Drift, deployment og monitoring: gi Delphi-backends portal-modenhet

En portal er normalt alltid tilgjengelig og dermed mer driftsintensiv enn en ren desktop. For administratorer er dette området hvor god arkitektur gir umiddelbar avkastning: gjennom etterprøvbare deploys, klar observability (logger/metrikker) og definerte vedlikeholdsvinduer.

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

En Delphi-tjeneste kan kjøres som Windows- og Linux-services eller som Linux-daemon. Viktigere enn OS er driftsstandarder som sikrer stabilitet:

• Health-Checks for monitoring og lastbalanserer (f.eks. „tjenesten lever“ og „database er tilgjengelig“).
• Strukturert logging (inkl. Request-ID, bruker/tenant, responstid, statuskoder) slik at support-saker kan reproduceres.
• Konfigurasjon uten ny build (f.eks. miljøvariabler, sentrale konfig-filer) slik at deploys kan automatiseres rent.
• Rollback-evne gjennom klare versjoner og migrasjonssikre databaseendringer.

Lastprofiler: portal er «mange korte forespørsler» i stedet for «få lange sesjoner»

Desktopbruk skaper ofte lengre arbeidsøkter per bruker, mens portaler genererer mange korte, parallelle forespørsler. Typiske tekniske tiltak er:

• konsekvent paging, server-side filter og begrensede svarstørrelser
• caching for stamdata og sjeldne spørringer
• asynkrone jobber for lange oppgaver (eksporter, rapportpakker)
• rate-limits og beskyttelsesmekanismer mot misbruk

For beslutningstakere er det sentralt: ytelse er ikke et „finjusteringsproblem på slutten“, men en del av API-definisjonen (svarstørrelser, timeouts, bakgrunnsbehandling).

Modernisering uten Big-Bang: en robust vei i fem steg

En fullstendig nyskriving er sjelden nødvendig og ofte risikabel fordi prosesskunnskapen sitter i Delphi-klienten. En etablert fremgang er å sikre at hver fase er produktivt brukbar og ikke setter driften i fare.

1) Kartlegging: prosesser, dataeierskap, integrasjoner

Start ikke ved skjermbilder, men ved use-cases: hvilke prosesser skal i portalen? Hvilke data kan en ekstern bruker se eller endre? Hvilke grensesnitt finnes mot ERP, DMS eller CRM? Dette gir en prioritert API-liste som leverer reell verdi.

2) Definer service-basics: auth, feilmønster, logging, versjonering

Denne basis avgjør senere vedlikeholdbarhet. Enes tidlig om standarder for autentisering/autorisering, et konsistent feilformat, request-korrelasjon, API-versjonering og telemetri. Det reduserer friksjon mellom portal-team, backend-team og drift.

3) Lever første portalstrøm end-to-end

Velg en prosess med tydelig avgrensning (f.eks. dokumentområde eller statusforespørsel). Viktig at hele kjeden er på plass: login, rettighetskontroll, API, UI, logging, monitoring, drift. Dermed ser organisasjonen tidlig hvilke standarder som fungerer i praksis.

4) Koble desktop målrettet til: kritiske skriveveier over tjenester

Når tjenestene er stabile, flytt utvalgte desktop-funksjoner over: spesielt statusendringer, godkjenninger eller sentrale valideringer. Desktop-en forblir kraftig, men reglene blir mer konsistente og direkte DB-skriving fases ned stegvis.

5) Konsolider: fjern doble regler og spesialveier

Uten dette oppstår fort „to systemer“. Planlegg jevnlig konsolidering: hvilke regler finnes dobbelt? Hvor kan portalen bruke desktopens tjenester? Hvilke rapporter bør genereres sentralt? Målet er en håndterbar plattform, ikke et dogme.

Typiske fallgruver fra driftsvinkel – og hvordan unngå dem

Regler bygges opp igjen i portalen

Det fører til avvik og support-saker. Mottiltak: use-case-APIer med server-side valideringer, klare feilresponsmeldinger, og om mulig felles faglige testscenarier.

Uklart dataeierskap mellom desktop og portal

Hvis begge klienter „kan endre alt“, oppstår konflikter. Mottiltak: statusmodell, definerte ansvarsområder og optimistisk samtidighetskontroll for konkurrerende endringer.

Sikkerhet behandles som et tillegg

Særlig for kundesystemer er SSO, tenant-sjekker, sikre filnedlastinger og audit nødvendig fra starten. Å legge dette på i etterkant er dyrere og øker risiko for sikkerhetshull.

Manglende transparens i drift

Uten Request-IDer, strukturert logging og health-checks blir feilsøking detektivarbeid. Mottiltak: observability som en obligatorisk del av de første service-utgivelsene.

Konklusjon: en service-kjerne forener desktop-styrke med portal-rekkevidde

Kombinasjonen av Delphi-desktop og webportal er for mange bedrifter den mest realistiske veien for å bevare kjerneprosesser samtidig som ekstern samarbeid muliggjøres. Avgørende er at dere ikke driver to adskilte verdener, men bygger en sammenbindende service-kjerne: use-case-APIer, ryddige rettigheter, etterprøvbare tilstander, kontrollerte dataflyter og et driftsmønster med logging, monitoring og planbare deployer.

Slik oppnås en modernisering med mellommål: desktop-en forblir produktiv, portalen leverer tidlig verdi, og arkitekturen blir gradvis mer konsistent og vedlikeholdbar.

I det faglige landskapet spiller også Delphi Modernisierung en viktig rolle når integrasjoner, dataflyt og videreutvikling må samhandle ryddig.

Diskuter prosjekt eller moderniseringsinitiativ med Net-Base.