Delphi Desktop en webportalen combineren: architectuur, interfaces en modernisering zonder onderbreking

In veel bedrijven is de functionele „schakelcentrale“ over jaren gegroeid als Delphi-desktoptoepassing: VCL-client, diep proceskennis, snelle gegevensinvoer, druk- en reportingketens, speciale hardware en vaak directe database-toegang in het LAN. Tegelijkertijd nemen de verwachtingen rond selfservice en externe samenwerking toe: klanten willen orderstatussen controleren, documenten uitwisselen of klachten registreren – zonder VPN, zonder desktop-rollout en zonder lokale installaties.

Delphi Desktop en webportalen combineren betekent in de praktijk deze twee werelden zo samen te brengen dat exploitatie, veiligheid en dataconsistentie beheersbaar blijven. Beslissend is niet het „nabloeden“ van schermen in de browser, maar een architectuur die processen, rechten en datastromen schoon scheidt en beide frontends volgens gemeenschappelijke regels laat werken. Het resultaat is een moderniseringspad zonder Big-Bang: de desktop blijft productief terwijl het webportaal gecontroleerd groeit.

Dit artikel richt zich op IT-leiding, beheerders en technische projectverantwoordelijken. De focus ligt op gevolgen voor exploitatie, administratie, interfaces, beveiliging, dataopslag en migratie – minder op framework-details. U krijgt praktijkgerichte patronen, beslissingscriteria en typische valkuilen inclusief tegenmaatregelen.

Waarom „portaal in plaats van desktop“ zelden realistisch is

In B2B-omgevingen zijn er veel redenen waarom een desktopclient zinvol blijft. Beheerders ervaren dat vaak concreet: een portaal is ideaal voor verspreide gebruikers, maar bepaalde taken blijven in de desktop efficiënter of überhaupt pas mogelijk.

Desktop-sterktes die in de praktijk tellen

• Complexe gegevensinvoer met zeer dichte schermen, toetsenbordbediening, grote tabelweergaven en snelle wisselingen tussen records.
• Periferie en lokale integraties zoals labelprinters, scanners, seriële apparaten of speciale Windows-componenten.
• LAN-nahe performance wanneer grote datavolumes worden verwerkt of een proces extreem lage latenties vereist.
• Gegroeide workflows met veel uitzonderingsgevallen, waarbij een 1:1-port in een portaal aanvankelijk hoge risico’s met zich meebrengt.

Portaal-sterktes die nieuwe eisen dekken

• Externe toegang voor klanten, leveranciers of partners, zonder dat een client uitgerold hoeft te worden.
• Centrale bestuurbaarheid (versies, features, rechten) met een duidelijke buitenrand.
• Apparaatonafhankelijkheid (browser, mobiel gebruik) voor buitendienst en management.
• Gerichte procesopeningen zoals statusvragen, uploads, vrijgaven of ticketstromen.

In de combinatie ligt het nut: de desktop blijft het power-tool voor interne rollen, het portaal wordt de gecontroleerde toegang voor externe gebruikersgroepen. Om te voorkomen dat dit in twee parallelle „waarheden“ uitmondt, is een verbindende kern nodig.

Als u Delphi Desktop en webportalen combineert: drie doelarchitecturen

Bij de architectuurkeuze gaat het vooral om verantwoordelijkheden: waar ligt de vakinhoudelijke regel? Wie mag data wijzigen? Welke laag is de „Single Source of Truth“ (dus de gezaghebbende bron voor regels en toestanden)? Voor technische beslissers is belangrijk: de keuze heeft directe gevolgen voor exploitatie, foutzoeken, release-management en security.

Variant A: portaal als aanvulling via REST-API, desktop blijft leidend

Het portaal bedient geselecteerde use-cases, typisch „lezen en aansturen“: status, documenten, vrijgaven, eenvoudige invoeren. Daarvoor wordt een Delphi REST-API of een aparte REST-server ingevoerd. De desktoptoepassing kan aanvankelijk blijven doorgaan met directe database-toegang.

Operationeel voordeel: snelle start, beperkte ingrepen in de desktop, geschikt voor een eerste portaal-meerwaarde.

Risicopunt: er bestaan twee datastromen (desktop → DB direct, portaal → API). Als bedrijfsregels alleen in de desktop zitten, ontstaan inconsistenties. Als tegenmaatregel moeten portaalfuncties bewust beginnen waar regels eenvoudig en server-side af te beelden zijn (bijv. documentbereitstellung, statusvraag, gedefinieerde vrijgaveacties).

Variant B: service-kern als gemeenschappelijke proceslaag (aanbevolen bij parallelbedrijf)

Hier verlegt u stap voor stap bedrijfslogica uit de desktop naar services. Desktop en portaal gebruiken dezelfde endpoints. De desktop wordt meer een rich client (UI, lokale integraties), de regels en validaties liggen serverzijdig.

Operationeel voordeel: één centrale plek voor rechten, audit, statuslogica en validaties; consistent gedrag over alle frontends.

Inspanning: hoger in het begin, omdat API-standaarden, foutformaten, versiebeheer, monitoring en deployment zorgvuldig gepland moeten worden. Daar staat tegenover dat de inspanning later aanzienlijk daalt, omdat er minder uitzonderingsroutes zijn.

Variant C: portaal voert, desktop blijft als special client

Deze variant is zinvol wanneer de browser strategisch standaardtoegang moet worden (bijv. sterk verspreide organisatie), maar de desktop voor bepaalde rollen met special hardware of high-performance invoer blijft bestaan. De service-kern moet hiervoor extra stabiel en schaalbaar zijn.

Layer-3-architectuur als begrijpelijke leidraad

Ongeacht de variant helpt een Layer-3-architectuur: (1) presentatie (desktop/portaal), (2) applicatie- en domeinlaag (use-cases, regels), (3) infrastructuur (database, bestandsopslag, messaging, externe systemen). Voor beheerders is dit belangrijk omdat de grensvlakken voor exploitatie helder worden: wat is een „frontend-probleem“, wat is een „service-probleem“, wat ligt in de database of in het storage? Deze scheiding verkort foutzoekwerk en vermindert neveneffecten bij deployments.

De praktijktoepassing: hoe desktop en portaal hetzelfde proces delen

De grootste uitdaging is zelden het „portaal bouwen“, maar de vraag: hoe delen desktop en portaal verantwoordelijkheden in hetzelfde proces, zonder dat regels dubbel worden geïmplementeerd? Drie patronen zijn in de praktijk bijzonder relevant.

1) Use-case-API’s in plaats van tabel- of CRUD-API’s

Een veelvoorkomende doodlopende weg is een API die alleen database-tabellen naar buiten afbeeldt („Create/Read/Update/Delete“). Dan moeten regels in het portaal worden nagedaan en houdt de desktop zijn eigen regels. Beter zijn use-case-API’s: endpoints beschrijven vakinhoudelijke acties zoals „reclamatie aanmaken“, „order vrijgeven“, „document uploaden“, „leverstatus bevestigen“.

Het effect in exploitatie is merkbaar: validaties gebeuren serverzijdig, foutmeldingen zijn reproduceerbaar en beide clients (desktop en portaal) starten dezelfde flow via dezelfde logica.

2) Conflicten en herhalingen beheersbaar maken

Met een portaal neemt de kans op parallelle wijzigingen en herhaalde requests toe (bijv. door timeouts, retries of dubbelklikken van gebruikers). Drie concepten helpen hier, zonder dat men „permanente locks“ introduceert:

• Idempotentie: kritieke acties zijn zo ontworpen dat herhaling hetzelfde effect heeft en niets dubbel uitvoert. Praktisch gebeurt dit vaak via een unieke request-identificatie (Idempotency Key).
• Optimistische gelijktijdigheidscontrole: een record draagt een versiedatum/versie-informatie (bijv. „rijversie“). Bij wijzigingen controleert de service of de versie nog klopt en meldt conflicten netjes terug.
• Korte transacties: in plaats van „alles blokkeren“ worden schrijfoperaties kort gehouden. Lange taken (bijv. exports, report-pakketten) lopen asynchroon.

Voor technische beslissers is belangrijk: deze mechanismen verlagen de supportlast, omdat foutbeelden („is twee keer gebeurd“, „mijn wijziging is weg“) veel minder voorkomen.

3) Statussen en overdrachten schoon modelleren

Als de desktop complexe gevallen behandelt en het portaal „alleen“ aanvragen of voorstappen levert, heeft u gedefinieerde statusovergangen nodig. Een praktisch bruikbare indeling is: het portaal creëert of vult processen aan in duidelijk begrensde statusgebieden (bijv. „ingediend“), de desktop behandelt special cases en de service-kern beslist en logt statuswisselingen. Zo voorkomt u dat de portaal-client indirect processen „kapot configureert“.

Data en documenten: het vaak onderschatte integratiegebied

Bijna elk portaal brengt bestandsstromen met zich mee: uploads, bewijzen, pakbonnen, afbeeldingen, PDF-uitvoer. Voor beheerders is dit een kernpunt omdat het backup, rechten, virusscans, storage-kosten en performance beïnvloedt.

Waar liggen bestanden: database, fileshare of objectopslag?

Er zijn drie gangbare opslagopties die elk tot een andere exploitatie-realiteit leiden:

• Database (BLOB): goed wanneer transacties strikt gekoppeld moeten zijn en backup/restore als één pakket moeten blijven. Nadelen zijn vaak grotere databases en langere backup-vensters.
• Filesystem/Share: typisch on-prem, goed in te passen in bestaande backup-concepten. Belangrijk zijn duidelijke permissies en een API-laag die de toegang controleert.
• Object-Storage: zinnig bij schaalbehoefte, lifecycle-regels of wanneer externe toegang technisch netjes afgeschermd moet worden. Vereist een bewust sleutel- en rechtenmodel.

Ongeacht de opslaglocatie geldt: het portaal moet bestanden niet „direct“ van een share laden. Beter is een gecontroleerde download via service-endpoints met rechtencontrole, logging en optioneel een tijdelijk beperkte download-URL.

PDF’s en rapporten: serverzijdig in plaats van dubbel

Delphi-desktoptoepassingen hebben vaak gegroeide druk- en reportingketens. Portalen hebben vaak dezelfde inhoud nodig als PDF. In plaats van twee implementaties bij te houden, loont een centrale documentgeneratie in de service-kern: sjablonen, versiebeheer en uitvoerformaten liggen serverzijdig; desktop en portaal consumeren het resultaat. Voor exploitatie levert dat duidelijke voordelen: reproduceerbare outputs, uniforme opslag en minder afhankelijkheid van desktopinstallaties.

REST-servers en services: Delphi, C# of een mixarchitectuur

Bij de keuze „Delphi of C#“ gaat het voor bedrijven minder om ideologie en meer om teamvaardigheid, exploitatieomgeving en onderhoudbaarheid. In veel omgevingen is een mixarchitectuur realistisch, zolang verantwoordelijkheden duidelijk gesneden zijn.

Delphi als serviceplatform: zinvol bij bestaande vaklogica

Als vaklogica en data-access al solide in Delphi aanwezig zijn, kan een Delphi-gebaseerde REST-server efficiënt zijn. Voor beheerders en beslissers is belangrijk: serverbetrieb is niet „desktop in continu gebruik“. Een productieve service vereist duidelijke configuratie, nette timeouts, gestructureerde logs, health-checks en reproduceerbare deployments.

Ook de data-aansluiting verdient modernisering als nog oude drivers of de BDE in het spel zijn. Een BDE-vervanging en omschakeling naar moderne data-access vermindert storingen in de exploitatie en vereenvoudigt deployment omdat minder legacy-componenten geïnstalleerd en onderhouden hoeven te worden.

C#-services in het portaal-ecosysteem: vaak vanwege hosting en identity

Als het portaal in een .NET-gedomineerde landschap ontstaat, zijn C#-services vaak vanzelfsprekend – niet in de laatste plaats vanwege identity-integratie, bestaande exploitatiestandaarden en hosting achter Microsoft IIS of in gecontaineriseerde platformen. Cruciaal is dubbelimplementatie te vermijden: óf de vakkernlogica blijft in Delphi-services en C# neemt edge-thema’s voor z’n rekening (bijv. portaal-specifieke orchestratie), óf u plant bewust migratie van logica naar .NET – maar dan gecontroleerd en met duidelijke vakgebiedgrenzen.

API-Gateway: ordenend element, maar geen must

Een API-gateway kan centrale functies bundelen (routing, rate-limiting, logging, authenticatie). Voor kleinere startarchitecturen volstaat vaak een consistente API met uniforme standaarden. Zodra er meerdere services en gebruikersgroepen bestaan, helpt een gateway echter om de buitenrand stabiel te houden en policies centraal af te dwingen.

Authenticatie en rechten: van interne desktop naar externe portaalwereld

Met een portaal verandert het gebruikerslandschap: naast interne gebruikers komen externe accounts, rollen en tenants. Daaruit volgen eisen aan identity, autorisaties en auditability. Voor beheerders is dit relevant omdat identity-systemen en rollenmodellen later moeilijk aan te passen zijn.

SSO met SAML 2.0 of OIDC: minder beheerwerk, betere controle

In B2B-setups is SAML 2.0 (single sign-on via een Identity Provider) wijdverbreid omdat bedrijven bestaande identiteiten willen gebruiken. OIDC (OpenID Connect) is ook gangbaar, zeker in modernere platformen. Klassieke gebruikersnaam/wachtwoord-logins zijn mogelijk, maar brengen extra werk met zich mee voor wachtwoordbeleid, MFA, resetprocessen en support.

Belangrijk voor de architectuur: authenticatie (wie ben je?) en autorisatie (wat mag je?) moeten serverzijdig worden gecontroleerd – niet in het portaal-frontend.

Multitenancy en rollenmodel: niet „later“ aanvullen

Een klantenportaal vereist praktisch altijd tenantscheiding: een klant ziet alleen zijn data. Dat moet in de service-kern worden afgebeeld, bij voorkeur via:

• Claims in het token (bijv. Tenant-ID, rollen, contractreferentie), zodat services besluiten kunnen nemen.
• Record-gebaseerde controles (row-level checks in de vaklogica), niet alleen „menu verbergen“.
• Audit-trails voor belangrijke acties (wie, wat, wanneer), plus correlatie via een request-ID voor foutanalyse.

De desktop kan – indien gewenst – ook met tokens tegen dezelfde identity-stack werken. Dat vermindert uitzonderingsroutes en vergemakkelijkt de traceerbaarheid van wijzigingen, zeker wanneer portaal en desktop hetzelfde record bewerken.

Data-access moderniseren: FireDAC, PostgreSQL en gecontroleerde datastromen

Veel Delphi-desktopoplossingen zijn historisch gegroeid met directe DB-toegang. Zodra een portaal erbij komt, wordt dat een architectuurvraagstuk: datastromen moeten beheersbaar zijn, validaties moeten centraal aanspreekbaar zijn en performance moet ook onder parallelle belasting stabiel blijven.

FireDAC als basis voor onderhoudbare data-access

BDE-vervanging met native aansluiting is in Delphi-omgevingen een veelgebruikte standaard voor toegang tot moderne databases. Belangrijker dan de component zelf is de uniformiteit: geparametriseerde queries, nette transactiegrenzen, eenduidige foutafhandeling en meetbare responstijden. Voor exploitatie telt dat timeouts en resourcegebruik planbaar worden en dat problemen in logs en monitoring te traceren zijn.

PostgreSQL met Delphi: goed beheersbaar met een correct type- en migratieconcept

PostgreSQL met Delphi is robuust wanneer typemapping (bijv. UUID, timestamps, JSON-velden), indexen en schema-migraties zorgvuldig worden behandeld. Portalen genereren vaak veel filterende lijstvragen. Filters, paging en sortering moeten serverzijdig worden uitgevoerd zodat niet onnodig grote datavolumes worden verstuurd. Dat verlaagt belasting en verbetert de gebruikerservaring zonder de desktop te vertragen.

Exploitatie, deployment en monitoring: portaalrijpheid voor Delphi-backends realiseren

Een portaal is doorgaans continu bereikbaar en daarmee exploitatief intensiever dan een zuivere desktop. Voor beheerders is dit het gebied waar een goede architectuur zich direct terugbetaalt: via reproduceerbare deployments, duidelijke observability (logs/metrics) en gedefinieerde onderhoudsvensters.

Windows-service of Linux-service: beslissend is het exploitatiemodel

Een Delphi-service kan als Windows- en Linux-services of als Linux-daemon worden gedraaid. Belangrijker dan het besturingssysteem zijn standaarden die de exploitatie stabiel maken:

• Health-checks voor monitoring en loadbalancer (bijv. „service leeft“ en „database bereikbaar“).
• Gestructureerde logging (incl. request-ID, gebruiker/tenant, runtime, statuscodes), zodat supportgevallen reproduceerbaar worden.
• Configuratie zonder nieuw build (bijv. omgevingsvariabelen, centrale configuratiebestanden), zodat deployments automatisch en schoon verlopen.
• Rollback-mogelijkheid door duidelijke versies en migratieveilige database-wijzigingen.

Lastprofielen: portaal is „veel korte requests“ in plaats van „weinig lange sessies“

Desktopgebruik genereert vaak langere werkfasen per gebruiker, terwijl portalen veel korte, parallelle requests genereren. Typische technische maatregelen zijn:

• consequent paging, serverzijdige filters en beperkte antwoordgroottes
• caching voor stamgegevens en zeldzame queries
• asynchrone jobs voor lange taken (exports, report-bundels)
• rate-limits en beschermingsmechanismen tegen misbruik

Voor beslissers is hier centraal: performance is geen „fine-tuning aan het eind“, maar onderdeel van de API-definitie (response-groottes, timeouts, achtergrondverwerking).

Modernisering zonder Big-Bang: een belastbaar pad in vijf stappen

Een complete herbouw is zelden nodig en vaak risicovol omdat proceskennis in de Delphi-client zit. Beproefd is een aanpak waarbij elke fase productief bruikbaar is en de exploitatie niet in gevaar brengt.

1) Inventarisatie: processen, data-eigenaarschap, integraties

Begin niet bij schermen, maar bij use-cases: welke processen moeten naar het portaal? Welke data mag een externe gebruiker zien of wijzigen? Welke interfaces bestaan naar ERP, DMS of CRM? Daaruit volgt een geprioriteerde API-lijst die echte meerwaarde levert.

2) Service-basics definiëren: auth, foutformaat, logging, versiebeheer

Deze basis bepaalt de latere onderhoudbaarheid. Spreek vroeg standaarden af voor authenticatie/authorisatie, een consistent foutformaat, request-correlatie, API-versionering en telemetrie. Dat vermindert wrijving tussen portaal-team, backend-team en exploitatie.

3) Eerste portaalstroom end-to-end opleveren

Kies een proces met duidelijke afbakening (bijv. documentdomein of statusvraag). Belangrijk is dat de hele keten werkt: login, rechtencontrole, API, UI, logging, monitoring, exploitatie. Zo ziet de organisatie vroeg welke standaarden in de praktijk functioneren.

4) Desktop gericht koppelen: kritische schrijfwegen via services

Zodra de services stabiel zijn, brengt u geselecteerde desktopfuncties over: in het bijzonder statuswisselingen, vrijgaven of centrale validaties. De desktop blijft krachtig, maar regels worden consistenter en directe DB-schrijftoegang wordt stap voor stap verminderd.

5) Consolideren: dubbele regels en uitzonderingsroutes afbouwen

Anders ontstaan er twee systemen. Plan regelmatige consolidatie: welke regels bestaan dubbel? Waar kan het portaal de desktop-service gebruiken? Welke rapporten moeten centraal gegenereerd worden? Het doel is een beheersbaar platform, geen dogma.

Typische valkuilen vanuit exploitatieperspectief – en hoe ze te vermijden

Regels worden in het portaal nagedaan

Dat leidt tot afwijkingen en supportgevallen. Tegenmaatregel: use-case-API’s met serverzijdige validaties, duidelijke foutteruggaven en, waar mogelijk, gemeenschappelijke vaktechnische testscenario’s.

Onhelder databeheer tussen desktop en portaal

Als beide clients „alles“ mogen wijzigen, ontstaan conflicten. Tegenmaatregel: statusmodel, gedefinieerde verantwoordelijkheden en optimistische gelijktijdigheidscontrole voor concurrerende wijzigingen.

Beveiliging wordt als nabehandeling gezien

Vooral bij het klantenportaal zijn SSO, tenant-checks, veilige bestanddownloads en audit vanaf het begin nodig. Later toevoegen is duurder en verhoogt het risico op beveiligingslekken.

Ontbrekende transparantie in exploitatie

Zonder request-ID’s, gestructureerde logs en health-checks wordt foutzoeken detectivewerk. Tegenmaatregel: observability als verplicht onderdeel van de eerste service-releases.

Conclusie: een service-kern verbindt desktop-sterkte met portaalbereik

De combinatie van Delphi-desktop en webportaal is in veel bedrijven de meest realistische weg om bestaande kernprocessen te behouden en tegelijkertijd externe samenwerking mogelijk te maken. Cruciaal is dat u niet twee gescheiden werelden draait, maar een verbindende service-kern creëert: use-case-API’s, schone rechten, traceerbare toestanden, gecontroleerde datastromen en een exploitatiemodel met logging, monitoring en planbare deployments.

Zo ontstaat een modernisering met tussenstappen: de desktop blijft productief, het portaal levert vroegwaarde en de architectuur wordt stap voor stap consistenter en makkelijker te onderhouden.

In het vakgebied spelen ook Delphi moderniseringen een belangrijke rol wanneer integraties, datastromen en doorgroei netjes moeten samengaan.

Project of moderniseringsvoorstel met Net-Base bespreken.