Den som vill städa upp klient-server-arkitekturer i Delphi har sällan ett „dåligt“ system framför sig. Ofta rör det sig om robust affärsprogramvara som byggts ut över år, hanterar många specialfall och fungerar pålitligt i vardagen. Problemet ligger inte i Delphi som plattform, utan i upparbetade ansvarsstrukturer: Klienten innehåller plötsligt datalogik, „servern“ är i praktiken bara en databas, och gränssnitt har lagts till ad hoc. Det slår tillbaka när nya säkerhetskrav, databasskiften, VPN för hemarbete, Terminalserver-konfigurationer eller integrationer med ERP, DMS eller portaler tillkommer.
Detta inlägg visar hur ni strukturerat rensar upp Delphi-klient-server-landskap i praktiken: utan dogmatisk totalombyggnad, men med tydliga mål för drift, administration, datakonsistens, gränssnittsberedskap och underhållbarhet. I fokus står beslut som IT-ledning och tekniskt ansvariga i projekt kan styra: arkitekturgränser, rollout-strategier, loggning, behörighetskoncept, migrationsvägar och typiska riskkällor.
Hur man ser att klient-server-arkitekturen har vuxit ihop
Tekniska skulder visar sig i driften oftare än i källkoden. Typiska signaler är mindre „dålig kod“ än återkommande friktionspunkter mellan klient, databas och infrastruktur:
- Oklara ansvarsområden: Klienten „vet“ för mycket om tabeller, triggers, lagrade procedurer eller till och med sökvägar i delade mappar.
- Svåra releaser: Varje liten ändring kräver klient-rollout på många arbetsstationer, ofta med manuella steg.
- Sköra dataåtkomster: Slumpmässiga deadlocks, inkonsekventa transaktioner eller „hängande“ lås vid hög belastning.
- Säkerhet som eftertanke: Databasåtkomster körs med för vida behörigheter; lösenord ligger i INI-filer; nätverkssegmentering bryter funktioner.
- Integration är oproportionerligt kostsam: En kundportal eller en REST-API är svår att efterinstallera eftersom affärsreglerna är spridda.
- Svår felsökning: Utan pålitlig loggning är det oklart om fel uppstår i klienten, nätverket, databasen eller i ett gränssnitt.
Om flera av dessa punkter stämmer är „städning“ inte kosmetik, utan en åtgärd för driftssäkerhet. Målet är inte perfektion, utan ett system som förblir pålitligt och lätt att förändra.
Klient-server i Delphi: Vad som verkligen räknas i driften
I många Delphi-landskap förstås „klient-server“ implicit som „klienten pratar direkt med databasen“. Det kan fungera – så länge förutsättningarna inte förändras. För företag är andra egenskaper dock viktigare:
- Skalbarhet i vardagen: inte imponerande benchmarkresultat, utan stabil prestanda vid typiska belastningstoppar (månadsbokslut, skiftbyten, importkörningar).
- Ändringsbarhet: Anpassningar utan kedjereaktioner av rollout, datamigration och utbildning.
- Säker drift: spårbara behörigheter, revisionsmöjlighet, korrekt hantering av hemligheter (Credentials), nätverksgränser.
- Integrationsförmåga: definierade gränssnitt istället för en „annan klient“ som också kopplar direkt mot tabellerna.
Dessa mål kan nås utan att „ablösen“ Delphi. Avgörande är hur ni drar gränser: vad är UI, vad är affärslogik, vad är dataåtkomst, och via vilka gränssnitt får andra system ansluta?
Rensa upp klient-server-arkitekturer i Delphi: målbild istället för Big Bang
En praktiskt genomförbar målbild är sällan ett radikalt snitt. Ett inkrementellt tillvägagångssätt inom en tydlig arkitekturram har visat sig fungera. Ofta genomförs detta som en Layer-3-arkitektur: tre lager med tydliga ansvar. „Layer“ betyder här: en definierad separation mellan UI (presentation), affärslogik (regler/use-cases) och dataåtkomst (SQL, transaktioner, persistens). Detta kan också struktureras inom en Delphi-monolit innan ni extraherar en riktig tjänst.
Steg 1: Gör arkitekturgränser synliga
Innan ni bygger om måste ni veta var koppling uppstår. Typiska gränsöverträdelse i Delphi-klienter är:
- UI-händelser (knappklick) innehåller SQL eller direkta tabellåtkomster.
- Affärsregler är utspridda: delvis i klienten, delvis i triggers, delvis i rapporter eller importskript.
- Databasanslutningar öppnas överallt „vid sidan om“, med olika parametrar.
Målet är en överskådlig kärna: få ingångspunkter till affärsfunktioner och en central dataåtkomst som konsekvent hanterar anslutningar, transaktioner och felhantering.
Steg 2: Definiera „kontrakt“ – även utan tjänster
Många team tror att gränssnitt uppstår först med REST. I verkligheten behöver ni först interna kontrakt: vilka funktioner finns, vilka parametrar skickas, vilka felkoder är tillåtna, vilka transaktioner hör ihop? Dessa kontrakt kan initialt existera som tydligt definierade moduler/byggstenar i Delphi-projektet. Senare går de relativt rent att överföra till en REST-Server eller till Windows- respektive Windows- och Linux-tjänster.
Stabilisera dataåtkomst: FireDAC, transaktioner och tydlig anslutningsstrategi
Dataåtkomst är i klient-server-uppsättningar ofta den största hävstången för stabilitet. Två frågor dominerar: konsistenta anslutningar och rena transaktionsgränser. I Delphi-miljöer är BDE-avveckling med native anslutning (dataåtkomstbibliotek med drivrutiner och anslutningspooling) ofta moderniseringsankaret, särskilt när BDE (Borland Database Engine, ett äldre dataåtkomstlager) fortfarande är i bruk.
BDE-avveckling: mer än ett drivrutinsbyte
En BDE-avveckling underskattas om man ser den som ett „utbyte av komponenter“. I praktiken berör den:
- SQL-dialekt och parametrisering: Olika databaser och drivrutiner reagerar olika på datumformat, NULL-hantering, sortering och teckenuppsättningar.
- Transaktionsbeteende: autocommit, isolationsnivåer (regler för hur strikt låsning/läsning hanteras) och felåterställning.
- Prestanda och låsningar: Viss äldre logik förlitar sig omedvetet på implicita låsmekanismer.
Operativt viktigt är ett testkoncept som inte bara „klickar igenom“ formulär, utan som återskapar typiska bokförings- och importflöden under belastning.
Transaktionen: Weniger Magie, mehr Regeln
I många befintliga Delphi-klienter uppstår transaktioner slumpmässigt: Ett formulär sparar till flera tabeller, men felhantering rullas inte tillbaka korrekt. Det leder till delvis uppdaterade tillstånd som senare måste „rensas manuellt“. Bättre är ett konsekvent mönster:
- En transaktion per funktionellt ärende (t.ex. „Auftrag anlegen“, „Wareneingang buchen“), inte per SQL-sats.
- Tydliga felvägar: Vid valideringsfel inget halvfärdigt datatillstånd, utan kontrollerat avbrott.
- Idempotenz bei Imports: Upprepbar inläsning utan dubbla poster.
För IT-drift och support är det viktigaste: När en operation misslyckas måste det ske spårbart – med loggposter, korrelerbara ID:n och en entydig felmeddelandeklass (t.ex. behörighet, datakonflikt, tekniskt fel).
Business-Logik aus dem Client herausziehen – ohne die Bedienung zu zerstören
Många Delphi-klienter har vuxit fram historiskt som „UI-zentrerad“: Flödet ligger i formulären, valideringar i OnChange-Events, sidoeffekter i OnExit. Det är ofta snabbt och direkt ur användarens perspektiv – men ur arkitekturperspektiv svårt att testa och att utöka.
Use-Cases statt Formularlogik
Ett praktiskt mellansteg är att gruppera till funktionella Use-Cases: En Use-Case kapslar in ett ärende (t.ex. „Rechnung freigeben“) inklusive valideringar, beräkningar, dataåtkomst och loggning. UI:n anropar den och visar resultaten, i stället för att själv implementera reglerna. Fördelen: Senare kan samma Use-Case användas via en REST-API, till exempel för en portal eller en importtjänst.
Regeln zentralisieren: Validierung, Nummernkreise, Zustandsmodelle
Typiska kandidater för centralisering är:
- Valideringsregler (obligatoriska fält, värdeintervall, plausibilitetskontroller)
- Nummerserier (Belege, Chargen, Vorgänge) med konfliktundvikande
- Tillståndsmodeller (Entwurf → geprüft → freigegeben → gebucht) med tillåtna övergångar
- Behörighetskontroller nära affärsoperationen, inte bara i UI:n
Särskilt för behörigheter är detta avgörande: Om regler endast finns i klienten blir det svårt att hålla dem konsistenta för gränssnitt, automatiseringar eller framtida portaler.
Schnittstellenfähig werden: REST-API als kontrollierter Zugang, nicht als „zweiter Weg“
Många företag behöver integration: data för BI, anslutning till ERP/DMS/CRM, automatisering av import/export eller en kundportal. Det typiska felet är att bygga en REST-API „vid sidan om“ som direkt går mot tabeller eftersom det går snabbt. Det skapar två sanningar: klientlogik och API-logik divergerar, och datakonsistens blir en slump.
REST als Fassade vor stabilen Use-Cases
En REST-API (HTTP-baserat gränssnitt, oftast JSON) bör erbjuda verksamhetsoperationer, inte spegla tabeller. Exempel är: „Auftrag anlegen“, „Status abfragen“, „Dokument zu Vorgang hochladen“. API:n anropar samma Use-Cases som klienten använder. På så sätt minskar ni dubbla regler och skapar tydlig styrning: externa system får en kontrollerad åtkomst som kan versionshanteras och säkras.
Sicherheit und Betrieb einer API
Ur B2B-synpunkt är det inte ändpunkterna som är mest intressanta, utan drift och skydd:
- Autentisering: t.ex. tokenbaserade metoder; i företagsmiljöer ofta anslutning till centrala identiteter (SAML 2.0 är en vanlig standard för Single Sign-on).
- Autorisering: rättigheter per operation, inte bara „får använda API:t“.
- Ratebegränsningar och skydd mot missbruk: viktigt vid partneråtkomst.
- Versionering: planerade ändringar utan tyst kompatibilitetsbrott.
Om ni redan planerar en modernisering av gränssnittet är det värt att titta på en strukturerad metod för att eftermontera en REST-API i befintlig programvara: det förenklar prioritering och minskar driftsrisker.
Driftsättning och uppdaterbarhet: den tysta kostnadsdrivaren
Många Delphi-system misslyckas inte på grund av funktionalitet utan på grund av utrullningsprocesser. „Client-Server“ betyder i praktiken: många arbetsplatser, olika behörigheter, ibland Terminalserver eller Citrix, samt filialer med VPN. Ett välordnat system har en definierad uppdateringsprocess.
Standardisera: konfiguration, versioner, miljöer
Typiska åtgärder som har omedelbar effekt i drift:
- Hämta konfiguration från binärpaketet: separata konfigurationsfiler eller centrala konfigurationskällor, så att uppdateringar inte skriver över inställningar.
- Miljöprofiler: Test, Staging, Produktion med tydligt separerade databas- och serviceendpoints.
- Automatiserad installation: reproducerbar, även för Terminalserver-images.
Viktigt: Även om klienten „bara“ är ett skrivbordsprogram, drar ni nytta av release-disciplinen som för servertjänster: versionering med changelog-stöd, rollback-alternativ och definierade migrationssteg.
Databasmigrationer: planbara istället för riskfyllda
Vid varje strukturell ändring av tabeller, index eller vyer måste det vara tydligt: vilken version av applikationen förväntar sig vilket schema? Ett ordnat förhållningssätt använder:
- Versionsstyrda migrationsskript per release
- Bakåtkompatibla övergångsfasar, när klientutrullning inte kan ske samtidigt
- Rena backout-strategier (Backup, återställning, definierade driftstoppfönster)
Detta är ingen målsättning i sig: utan denna disciplin blir arkitekturförbättringar i det dagliga arbetet „för farliga“ och blir liggande.
Loggning, övervakning och felsökning: utan telemetri ingen stabilitet
„Det händer sällan, men när det händer står allt stilla“ är en varningssignal. Äldre Client-Server-system har ofta otillräcklig loggning, särskilt över systemgränser. För driftteam är det avgörande att en felhändelse kan rekonstrueras vad gäller tidpunkt och kontext.
Vad som bör loggas i praktiken
- Korrelation: en ärende-ID som kopplar klient, tjänst och databasoperationer
- Kontext: användare, tenant, maskin/plats, version, berörd operation
- Tekniska detaljer: databas-felkoder, timeout-information, omförsök
- Säkerhetsrelevant: misslyckade inloggningar, rättighetsintrång, avvikande anropsmönster
Det är viktigt att skilja mellan tekniska loggar och affärsprotokoll. Ett affärsprotokoll (t.ex. „Verifikat godkänt av användare X“) är ofta revisionsrelevant; tekniska loggar används för felanalys och bör skyddas och roteras därefter.
Nätverk, säkerhet och rättigheter: Från „fungerar i LAN“ till „fungerar i företaget“
Många Delphi-klient-server-system designades under en tid då „i LAN“ var liktydigt med „pålitligt“. Idag gäller: segmentering, Zero Trust-ansatser, VPN, MFA och restriktiva brandväggsregler är standard. Att städa upp arkitekturen är därför också säkerhetsarbete.
Databasbehörigheter: principen om minsta rättigheter
Ett vanligt gammalt tillstånd är en databasanvändare med omfattande rättigheter som alla klienter använder. Bättre är:
- Rollbaserade rättigheter per funktionsområde
- Separata åtkomster för klient, tjänster, batchjobb
- Inga admin-rättigheter i produktionsåtkomster för vardagliga operationer
Det begränsar konsekvenserna av fel och gör revisioner betydligt enklare. Samtidigt ökar transparensen och diagnosförmågan, eftersom behörighetsfel inte längre uppstår „slumpmässigt“.
Hemligheter och konfiguration: bort från klartextlösenord
Inloggningsuppgifter i INI-filer eller i registret är en klassiker. Beroende på miljö kan centrala secret stores, krypterad konfiguration eller åtminstone driftkoncept med restriktiva filrättigheter vara aktuella. Avgörande är: lösningen måste förbli administrerbar. Säkerhet som kringgås i vardagen är ingen säkerhet.
Stegvis modernisering: Var börjar man när allt verkar viktigt?
Prioriteringen avgör om upprensningen stannar efter två månader eller ger mätbar avlastning. En ordning som först tar itu med driftsäkerhet och därefter inför strukturförbättringar har visat sig fungera.
En pragmatisk moderniseringsplan
- Stabilisera transaktions- och felbeteende: mindre datakorruption, färre „manuella reparationer“.
- Centraliserad dataåtkomst: enhetlig anslutningskonfiguration, timeouts, omförsök, loggning.
- Samla användningsfall: flytta kritiska kärnflöden bort från användargränssnittet.
- Definiera gränssnitt utåt: REST-API eller servicefasad för integration, utan direkt åtkomst till tabeller.
- Professionaliserad deployment: reproducerbara uppdateringar, versionerade DB-migrationer.
- Säkerhetshärdning: rättigheter, hemligheter, nätverksgränser, revisionsförmåga.
Denna ordning är inte dogmatisk, men den ser till att tidiga steg märks direkt i driften och att senare steg blir lättare.
Typiska fallgropar ur projektperspektiv – och hur man undviker dem
När man rensar misslyckas projekt sällan på grund av teknik, utan på grund av randvillkor. Vissa fallgropar återkommer särskilt ofta:
Parallell ombyggnad utan kvalitetsnät
När arkitekturåtgärder körs parallellt med funktionsändringar saknas ofta ett säkerhetsnät. Minst nödvändigt är: reproducerbara testdata, definierade smoke-tester för kärnprocesser, och en release-process som ser rollback inte som ett nederlag utan som ett driftverktyg.
Två datamodeller samtidigt
Den som bygger nya moduler men låter gamla gränssnitt fortsätta att göra direkt åtkomst till tabeller får snabbt inkonsistenta regler. Bättre: definiera tydliga övergångsregler. Antingen förblir ett område tillfälligt „gammalt“ och moderniseras inte parallellt, eller så leds det konsekvent via det nya lagret.
Integration utan styrning
När partner eller interna system ansluts uppstår beroenden. Utan versionering, kontraktstester och en definierad avvecklingsstrategi blir varje ändring en avstämningsprocess. Det är mindre ett utvecklarproblem än ett arkitektur- och driftsproblem.
Slutsats: Att städa upp innebär att åter göra drift och förändring hanterbara
När ni rensar upp Client-Server-arkitekturer i Delphi handlar det inte om „modernisering för moderniseringens skull“. Det handlar om att strukturera en affärskritisk digital företagslösning så att drift, säkerhet och vidareutveckling förblir planerbara. De kraftfullaste verktygen är ofta ospektakulära: tydliga lager, konsekvent dataåtkomst, rena transaktionsgränser, pålitlig loggning och en gränssnittsstrategi som inte duplicerar regler.
Den avgörande punkten är tillvägagångssättet: inkrementellt, med en målbild och en prioritering som först skapar stabilitet. På så sätt kan ni modernisera ett befintligt Delphi-landskap utan att äventyra den dagliga verksamheten – och utan att tvingas till en riskfylld fullständig nystart.
Om ni vill pragmatiskt bedöma nästa steg för er arkitektur, databasåtkomst och gränssnitt, kontakta oss:
I den tekniska kontexten spelar även Delphi modernisering en viktig roll, när integrationer, dataflöden och vidareutveckling måste samspela på ett ordnat sätt.