Delphi-työpöydän ja web-portaalien yhdistäminen: arkkitehtuuri, rajapinnat ja modernisointi ilman katkoksia

Monissa yrityksissä operatiivinen „ohjauskeskus“ on vuosien saatossa kasvanut Delphi-työpöytäsovellukseksi: VCL-asiakas, syvällinen prosessiosaaminen, nopea tiedon syöttö, tulostus- ja raportointiketjut, erikoislaitteet ja usein suora tietokantayhteys LAN-verkossa. Samalla itsepalveluun ja ulkoiseen yhteistyöhön liittyvät odotukset kasvavat: asiakkaat haluavat tarkistaa tilauksensa tilan, vaihtaa dokumentteja tai kirjata reklamaatioita – ilman VPN:ää, ilman työpöytäjakelua ja ilman paikallisia asennuksia.

Delphi-työpöytä ja web-portaalit yhdistää käytännössä se, että nämä kaksi maailmaa kootaan siten, että käyttö, turvallisuus ja datan eheys pysyvät hallittavina. Oleellista ei ole maskien „kloonaaminen“ selaimeen, vaan arkkitehtuuri, joka erottaa prosessit, oikeudet ja datan kulut siisteihin kerroksiin ja sallii molempien fronttien toimia yhteisten sääntöjen mukaisesti. Hyöty on modernisointipolku ilman Big-Bangia: työpöytä pysyy tuottavana samalla kun portaali kasvaa hallitusti.

Tämä artikkeli on suunnattu IT-johtajille, ylläpitäjille ja teknisille projektivastaaville. Keskitymme vaikutuksiin käytössä, hallinnassa, rajapinnoissa, turvallisuudessa, tietojen säilytyksessä ja migraatiossa – vähemmän framework-yksityiskohtiin. Saat käytännönmukaisia malleja, päätöskriteerejä ja tyypillisiä sudenkuoppia korjaustoimenpiteineen.

Miksi „portaali sijaan työpöytä“ harvoin on realistinen

B2B-ympäristöissä on monia syitä, miksi työpöytäasiakas on yhä perusteltu. Ylläpitäjät kohtaavat tämän usein konkreettisesti: portaali on erinomainen hajautetuille käyttäjille, mutta tietyt tehtävät ovat työpöydällä tehokkaampia tai edes mahdollisia.

Työpöydän vahvuudet, jotka arjessa ratkaisevat

• Monimutkainen tietojen keruu hyvin tiiviillä lomakkeilla, näppäimistöohjauksella, suurilla taulukkonäkymillä ja nopeilla siirtymillä tietueiden välillä.
• Periferia ja paikalliset integraatiot kuten tarra-aasimet, skannerit, sarjaliitännät tai erikoiset Windows-komponentit.
• LAN-läheinen suorituskyky, kun käsitellään suuria datamääriä tai prosessi vaatii erittäin alhaisia latensseja.
• Kehittyneet työnkulut monine poikkeustapauksineen, joissa 1:1-siirto portaaliin voi aluksi tuoda merkittäviä riskejä.

Portaalin vahvuudet, jotka kattavat uusia vaatimuksia

• Ulkoiset pääsyt asiakkaille, toimittajille tai kumppaneille ilman asiakasohjelmiston jakelua.
• Keskitetty ohjattavuus (versiot, ominaisuudet, oikeudet) selkeällä ulkorajalla.
• Laiteriippumattomuus (selain, mobiili) kenttätyöhön ja johtoon.
• Rajoitetut prosessin avaamiset kuten tilankyselyt, tiedostojen lähetykset, hyväksynnät tai tikettiprosessit.

Yhdistelmässä on hyöty: työpöytä pysyy sisäisten roolien tehotyökaluna, portaali on hallittu pääsy ulkoisille käyttäjäryhmille. Jotta tämä ei johtaisi kahteen rinnakkaiseen „totuuteen“, tarvitaan yhdistävä ydin.

Kun yhdistätte Delphi-työpöydän ja web-portaalit: kolme tavoitearkkitehtuuria

Arkkitehtuurivalinnassa on kyse ennen kaikkea vastuista: missä liikkuu liiketoimintasääntö? Kuka saa muuttaa dataa? Mikä kerros on „Single Source of Truth“ (eli sääntöjen ja tilojen määräävä lähde)? Teknisenä päättäjänä on tärkeää ymmärtää: valinnalla on suorat vaikutukset käyttöön, vianetsintään, release-hallintaan ja tietoturvaan.

Vaihtoehto A: Portaali lisänä REST-API:n kautta, työpöytä pysyy johtavana

Portaali palvelee valittuja käyttötapauksia, tyypillisesti „lukeminen ja käynnistäminen“: tilat, dokumentit, hyväksynnät, yksinkertaiset kirjaamiset. Tätä varten otetaan käyttöön Delphi REST-API tai erillinen REST-server. Työpöytäsovellus voi aluksi edelleen käyttää suoraa tietokantayhteyttä.

Operatiivinen etu: nopea aloitus, vähäiset muutokset työpöytään, hyvä ensimmäisen portaalihyödyn tuottamiseen.

Riskipiste: on olemassa kaksi datareittiä (työpöytä → DB suoraan, portaali → API). Jos liiketoimintasäännöt ovat vain työpöydässä, syntyy epäjohdonmukaisuuksia. Vastatoimenpiteenä portaaliominaisuudet kannattaa rajata aluksi sellaisiin tapauksiin, joissa säännöt ovat yksinkertaisia ja voidaan toteuttaa palvelinpuolella (esim. dokumenttien tarjoaminen, tilakyselyt, määritellyt hyväksyntätoiminnot).

Vaihtoehto B: Palveluydin yhteiseksi prosessikerrokseksi (suositeltava rinnakkaiskäytössä)

Tässä siirrätte vaiheittain liiketoimintalogiikkaa työpöydästä palveluihin. Työpöytä ja portaali käyttävät samoja päätepisteitä. Työpöytä toimittaa enemmän UI:na ja paikallisina integraatioina, kun taas säännöt ja validoinnit ovat palvelinpuolella.

Operatiivinen etu: keskitetty piste oikeuksille, auditille, tilalogikalle ja validoinneille; yhtenäinen käyttäytyminen kaikissa frontteissa.

Työmäärä: alussa suurempi, koska API-standardit, virheformaatit, versionhallinta, monitorointi ja deployment pitää suunnitella huolellisesti. Vastineeksi myöhemmät kustannukset laskevat merkittävästi, kun erikoisreittejä on vähemmän.

Vaihtoehto C: Portaali johtavaksi, työpöytä erikoisasiakkaana

Tämä vaihtoehto on järkevä, jos selain halutaan strategiseksi vakiopääsytavaksi (esim. laajasti hajautetut organisaatiot), mutta työpöytä säilyy tietyille rooleille, joilla on erikoislaitteita tai suorituskykyvaatimuksia. Palveluytimen on tällöin oltava erityisen vakaa ja skaalautuva.

Layer-3-arkkitehtuuri ymmärrettävänä ohjenuorana

Riippumatta vaihtoehdosta auttaa Layer-3-arkkitehtuuri: (1) esityskerros (työpöytä/portaali), (2) sovellus- ja domenikerros (use caset, säännöt), (3) infrastruktuuri (tietokanta, tiedostotallennus, messaging, ulkoiset järjestelmät). Ylläpitäjille tämä on tärkeää, koska se selkeyttää käyttö- ja vastuuruutuja: mikä on „frontend-ongelma“, mikä on „service-ongelma“, mikä kuuluu tietokantaan tai storageen? Tämän erottelun ansiosta vianetsintä nopeutuu ja deploymentien sivuvaikutukset vähenevät.

Käytännön taso: miten työpöytä ja portaali jakavat saman prosessin

Suurin haaste ei useimmiten ole „portaalin rakentaminen“, vaan se, miten työpöytä ja portaali jakavat vastuut samassa prosessissa ilman, että säännöt toteutetaan kahteen kertaan. Kolme käytännön mallia ovat erityisen relevantteja.

1) Use-Case-API:t taulukkorajapintojen tai CRUD-API:en sijaan

Tyypillinen ansa on API, joka vain peilaa tietokantatauluja ulospäin („Create/Read/Update/Delete“). Silloin säännöt pitää rakentaa portaalissa uudelleen ja työpöytä jatkaa omilla säännöillään. Parempi on käyttää Use-Case-API:ita: päätepisteet kuvaavat liiketoiminnallisia toimintoja kuten „reklamaation luonti“, „tilauksen hyväksyntä“, „dokumentin lataus“, „toimitustilan vahvistus“.

Käytössä vaikutus on selvä: validoinnit tapahtuvat palvelimella, virheilmoitukset ovat toistettavissa ja molemmat clientit (työpöytä ja portaali) käynnistävät saman työnkulun saman logiikan kautta.

2) Konfliktit ja toistot hallittaviksi

Portaalin myötä samanaikaisten muutosten ja toistuvien pyyntöjen (esim. timeoutit, retryt tai käyttäjän kaksoisklikkaukset) todennäköisyys kasvaa. Tässä kolme käsitettä auttavat ilman koko ajan voimassa olevia lukkoja:

• Idempotenssi: kriittiset toiminnot suunnitellaan niin, että toisto tuottaa saman lopputuloksen eikä suorita asiaa kahteen kertaan. Käytännössä tämä toteutetaan usein yksilöllisellä pyyntötunnisteella (Idempotency Key).
• Optimistic Concurrency: tietue kantaa versiotaietoa (esim. „Row Version“). Muutosten yhteydessä palvelu tarkistaa, onko versio edelleen sama, ja palauttaa konfliktit selkeästi.
• Lyhyet transaktiot: kirjoitustoiminnot pidetään lyhyinä. Pitkät työt (esim. eksportit, raporttipaketit) ajetaan asynkronisesti.

Teknisen päättäjän on tärkeää ymmärtää: nämä mekanismit vähentävät tukityötä, koska virhekuvat kuten „tapahtui kahdesti“ tai „muutokseni katosi“ ovat harvinaisempia.

3) Tilojen ja siirtojen siisti mallinnus

Kun työpöytä käsittelee monimutkaisia tapauksia ja portaali „vain“ luo hakemuksia tai lähtötasoja, tarvitsette määritellyt tilasiirtymät. Käytännöllinen jako on: portaali luo tai täydentää tapahtumia selkeästi rajatuissa tilavyöhykkeissä (esim. „lähetetty“), työpöytä käsittelee erikoistapauksia ja palveluydin päättää ja kirjaa tilanvaihdot. Näin vältetään tilanne, jossa portaali-asiakas voi epäsuorasti „rikkouttaa“ prosesseja väärällä konfiguraatiolla.

Tiedot ja dokumentit: usein aliarvostettu integraatioalue

Melkein jokainen portaali sisältää tiedostokäsittelyä: latauksia, todisteita, läheteaineistoja, kuvia, PDF-tuotantoja. Ylläpitäjille tämä on keskeinen kohta, koska se vaikuttaa varmuuskopiointiin, oikeuksiin, virustarkistukseen, tallennuskustannuksiin ja suorituskykyyn.

Missä tiedostot sijaitsevat: tietokannassa, jaossa vai objektitallennuksessa?

Kolme yleistä säilytysoptioita johtavat kukin eri käyttöönottoon:

• Tietokanta (BLOB): hyvä, kun transaktiot pitää kytkeä tiukasti ja backup/restore halutaan yhtenä pakettina. Haittapuolia ovat usein suuremmat tietokannat ja pidemmät varmuuskopiointiajat.
• Tiedostojärjestelmä/Share: tyypillinen On-Prem, helppo integroida olemassa oleviin backup-käytäntöihin. Olennaista ovat selkeät oikeudet ja API-kerros, joka kontrolloi pääsyn.
• Objektitallennus: järkevä skaalaustilanteissa, elinkaarisääntöjen hallinnassa tai kun ulkoiset pääsyt halutaan teknisesti kapseloida. Edellyttää tietoista avain- ja oikeusmallia.

Riippumatta tallennuspaikasta: portaali ei yleensä saisi ladata tiedostoja suoraan jaolta. Parempi on kontrolloitu lataus palvelun päätepisteen kautta, jossa tehdään oikeustarkistus, kirjaus ja tarvittaessa ajallisesti rajoitettu lataus-URL.

PDF:t ja raportit: palvelinpuolella sen sijaan, että toteutetaan kahdesti

Delphi-työpöytäsovelluksilla on usein kehittyneitä tulostus- ja raportointiketjuja. Portaalit tarvitsevat usein samat sisällöt PDF-muodossa. Kahden toteutuksen sijaan kannattaa keskittää dokumentin luonti palveluytimeen: mallipohjat, versiointi ja tulostusmuodot hallitaan palvelimella; sekä työpöytä että portaali kuluttavat tuloksen. Käytössä siitä seuraa etuja: todennettavat tulosteet, yhtenäinen arkistointi ja vähemmän riippuvuutta työpöytäasennuksista.

REST-serverit ja palvelut: Delphi, C# vai hybridi

Päätöksessä „Delphi vai C#“ ratkaisee yrityksille vähemmän ideologia kuin tiimien osaaminen, käyttöympäristö ja ylläpidettävyys. Monissa ympäristöissä hybridiarkkitehtuuri on realistinen, kunhan vastuut on selkeästi rajattu.

Delphi palvelualustana: järkevää olemassa olevan liiketoimintalogiikan tapauksessa

Jos liiketoimintalogiikka ja datayhteydet ovat jo vankasti Delphi:ssa, voi Delphi-pohjainen REST-server olla tehokas. Ylläpitäjille ja päättäjille on tärkeää ymmärtää: palvelinajo ei ole „työpöytä jatkuvasti käynnissä“. Tuottava palvelu vaatii selkeän konfiguraation, siistit timeoutit, strukturoidut lokit, health-checkit ja toistettavan deploymentin.

Myös tietokantayhteydet kannattaa modernisoida, jos vanhat ajurit tai BDE ovat käytössä. BDE-Ablösung ja siirtyminen moderneihin datayhteyksiin vähentävät häiriöitä käytössä ja helpottavat deploymentia, koska vähemmän legacy-komponentteja tarvitsee asentaa ja ylläpitää.

C#-palvelut portaaliekosysteemissä: usein valinta isosta hosting- ja Identity-tilanteesta

Jos portaali toteutetaan .NET-vetoisessa ympäristössä, ovat C#-palvelut usein luonteva valinta – ei vähiten Identity-integraation, olemassa olevien operointistandardien ja Microsoft IIS:n tai container-alustojen takia. Olennaista on välttää kaksoistoteutusta: joko liiketoiminnan ydinlogiikka säilyy Delphi-palveluissa ja C# hoitaa reunatehtävät (esim. portaali-spesifinen orkestrointi), tai suunnittelette hallitun migroinnin logiikalle .NET:iin selkein toimialarajauksin.

API-Gateway: järjestämiselementti, mutta ei pakko

API-Gateway voi keskittää toimintoja (routing, rate-limits, lokitus, autentikointi). Pienemmille aloitusarkkitehtuureille riittää usein yhtenäinen API ja yhteiset standardit. Kun useita palveluja ja käyttäjäryhmiä on, gateway kuitenkin auttaa pitämään ulkorajan vakiona ja toteuttamaan politiikat keskitetysti.

Autentikointi ja oikeudet: sisäisestä työpöydästä ulkoiseen portaaliin

Portaalin myötä käyttäjäkenttä muuttuu: sisäisten käyttäjien lisäksi tulee ulkoisia tilejä, rooleja ja vuokralaisuuksia. Tästä syntyy vaatimuksia identitylle, oikeuksille ja auditointikyvylle. Ylläpitäjille tämä on merkittävää, koska identity-järjestelmiä ja roolimallia on vaikea muuttaa myöhemmin.

SSO SAML 2.0:lla tai OIDC:llä: vähemmän ylläpitoa, parempi kontrolli

B2B-ympäristöissä SAML 2.0 (Single Sign-on identity providerin kautta) on yleinen, koska yritykset haluavat hyödyntää olemassa olevia identiteettejä. OIDC (OpenID Connect) on myös yleinen, erityisesti modernimmissa alustoissa. Perinteiset käyttäjä/tunnus -kirjautumiset ovat mahdollisia, mutta ne lisäävät vaivaa salasana-politiikalle, MFA:lle, reset-prosesseille ja tukipalvelulle.

Arkkitehtuurin kannalta tärkeää: autentikointi (kuka olet?) ja auktorisointi (mitä saat tehdä?) pitää tarkistaa palvelinpuolella – ei portaali-frontendissä.

Monivuokralaisuus ja roolimalli: ei „lisätä myöhemmin“

Asiakaspalveluportaali vaatii käytännössä aina vuokralaisten erottelun: asiakas näkee vain omat tietonsa. Tämä pitää mallintaa palveluytimeen, mieluiten seuraavasti:

• Claims tokenissa (esim. Tenant-ID, roolit, sopimussuhde), jotta palvelut voivat tehdä päätöksiä.
• Tietuekohtaiset tarkastukset (row-level checks liiketoimintalogiikassa), ei pelkkää „valikon piilottamista“.
• Audit-trailit tärkeille toiminnoille (kuka, mitä, milloin), plus korrelaatio Request-ID:llä vianratkaisua varten.

Työpöytä voi haluttaessa myös käyttää tokeneita samaa identity-stackia vastaan. Tämä vähentää erikoisreittejä ja helpottaa muutosten jäljitettävyyttä, erityisesti kun portaali ja työpöytä käsittelevät samaa tietuetta.

Tietokantayhteyksien modernisointi: FireDAC, PostgreSQL ja hallitut datareitit

Monet Delphi-työpöytäratkaisut ovat historiallisesti kasvaneet suoran DB-yhteyden varaan. Kun portaali lisätään, tästä tulee arkkitehtuurikysymys: datareittien pitää olla hallittavia, validoinnit keskitettyjä ja suorituskyvyn pitää pysyä vakaana myös rinnakkaiskuormassa.

FireDAC pohjana ylläpidettävälle datayhteydelle

BDE-Ablösung natilla liitännällä on Delphi-ympäristöissä yleinen standardi modernien tietokantojen käyttöön. Tärkeämpää kuin komponentin nimi on yhtenäistäminen: parametroidut kyselyt, siistit transaktiorajat, yhtenäinen virheenkäsittely ja mitattavat suoritukset. Käytön näkökulmasta oleellista on, että timeoutit ja resurssien kulutus ovat ennakoitavissa ja että ongelmat näkyvät lokeissa ja monitoroinnissa.

PostgreSQL ja Delphi: hallittavissa kun tyyppien ja migraation suunnittelu on tehty

PostgreSQL Delphi:n kanssa on robusti ratkaisu, kun tyyppimapping (esim. UUID, aikaleimat, JSON-kentät), indeksit ja skeeman migraatiot hoidetaan huolellisesti. Portaalit tuottavat erityisesti paljon suodatettuja listahakuja. Näihin kannattaa toteuttaa suodatus, sivutus ja lajittelu palvelinpuolella, jotta ei siirretä tarpeettomia suuria määriä dataa. Tämä vähentää kuormitusta ja parantaa käyttökokemusta ilman, että työpöytä hidastuu.

Käyttö, käyttöönotto ja monitorointi: portaali-valmius Delphi-backendille

Portaali on yleensä jatkuvasti saavutettavissa ja siten operatiivisesti vaativampi kuin pelkkä työpöytä. Ylläpitäjille tämä on alue, jossa hyvä arkkitehtuuri maksaa itsensä takaisin: toistettavat deploymentit, selkeä observability (lokit/mitat) ja määritellyt huoltokatkokset.

Windows-service vai Linux-service: ratkaisevaa on käyttömalli

Delphi-palvelu voidaan ajaa Windows- ja Linux-servicenä tai Linux-daemonina. Oleellisempaa kuin käyttöjärjestelmä ovat standardit, jotka tekevät käytöstä vakaata:

• Health-checkit monitorointia ja load balanceria varten (esim. „palvelu elää“ ja „tietokanta saavutettavissa“).
• Strukturoitu lokitus (ml. Request-ID, käyttäjä/vuokralainen, suoritusaika, tilakoodit), jotta tukitapaukset ovat toistettavissa.
• Konfiguraatio ilman uudelleenbuildia (esim. ympäristömuuttujat, keskitetyt konfigurointitiedostot), jotta deploymentit voidaan automatisoida siististi.
• Rollback-kyvykkyys selkeiden versioiden ja migrointiturvallisten tietokantamuutosten avulla.

Kuormaprofiilit: portaali on „monia lyhyitä pyyntöjä“ eikä „muutamia pitkiä sessioita“

Työpöydän käyttö tuottaa usein pidempiä työjaksoja per käyttäjä, kun taas portaali synnyttää paljon lyhyitä, rinnakkaisia pyyntöjä. Tyypillisiä teknisiä toimenpiteitä ovat:

• järkevä sivutus, palvelinpuolen suodatus ja rajoitetut vastauskoot
• välimuisti staattisille tiedoille ja harvoin muuttuville hauille
• asynkroniset työnkulut pitkiin tehtäviin (eksportit, raporttipaketit)
• rate-limitit ja suojausmekanismit väärinkäytöksiä vastaan

Päättäjälle keskeistä on ymmärtää: suorituskyky ei ole „viime hetken hienosäätö“, vaan osa API-määrittelyä (vastauskoot, timeoutit, tausta-ajot).

Modernisointi ilman Big-Bangia: kestävä viiden askeleen polku

Täydellinen uudelleenrakennus on harvoin tarpeen ja usein riskialtis, koska prosessiosaaminen on usein sidottu Delphi-asiakkaaseen. Toimiva lähestymistapa on eteneminen, jossa jokainen vaihe on tuotantokelpoinen eikä vaaranna toimintaa.

1) Nykytilan kartoitus: prosessit, tiedon omistus, integraatiot

Aloita lomakkeiden sijaan use caseista: mitkä prosessit siirretään portaaliin? Mitä dataa ulkoinen käyttäjä saa nähdä tai muuttaa? Mitä rajapintoja on ERP:iin, DMS:ään tai CRM:ään? Näistä muodostuu priorisoitu API-lista, joka tuottaa todellista hyötyä.

2) Palveluen perusteet määrittelyyn: Auth, virheformaatti, lokitus, versionointi

Tämä perusta ratkaisee myöhemmän ylläpidettävyyden. Sopikaa varhain standardit autentikoinnille/auktorisoinnille, yhtenäiselle virheformaatille, pyynnön korrelaatiolle, API-versionoinnille ja telemetrialle. Se vähentää kitkaa portaali-, backend- ja ylläpitotiimien välillä.

3) Ensimmäinen portaalipolkku end-to-end

Valitkaa prosessi, jolla on selkeä rajaus (esim. dokumenttialue tai tilakysely). Tärkeää on, että koko ketju on toiminnassa: kirjautuminen, oikeustarkistus, API, UI, lokitus, monitorointi ja käyttö. Näin organisaatio näkee varhain, mitkä standardit toimivat arjessa.

4) Työpöydän kohdennettu liittäminen: kriittiset kirjoituspolut palveluiden kautta

Kun palvelut ovat vakaita, siirtäkää valittuja työpöytätoimintoja palveluiden alle: erityisesti tilanvaihdot, hyväksynnät ja keskeiset validoinnit. Työpöytä säilyy suorituskykyisenä, mutta säännöt yhtenäistyvät ja suora DB-kirjoitus vähenee asteittain.

5) Konsolidointi: kaksoissäännöt ja erikoisreitit pois

Muuten syntyy ajan myötä „kaksi järjestelmää“. Suunnitelkaa säännöllinen konsolidointi: mitkä säännöt ovat kaksinkertaisia? Missä portaali voi käyttää työpöytää palvelevaa palvelua? Mitkä raportit tulisi tuottaa keskitetysti? Tavoitteena on hallittava alusta, ei dogma.

Tyypilliset sudenkuopat käytöstä katsottuna – ja miten ne vältetään

Säännöt rakennetaan portaalissa uudelleen

Tämä johtaa poikkeamiin ja tukitapauksiin. Vastatoimenpide: Use-Case-API:t palvelinpuolisilla validoinneilla, selkeillä virhepalautuksilla ja mahdollisuuksien mukaan yhteisillä liiketoimintatestiskenaarioilla.

Epäselvä datan omistus työpöydän ja portaalin välillä

Jos molemmat clientit voivat muuttaa „kaikkea“, syntyy konflikteja. Vastatoimenpide: tilamalli, määritellyt vastuut ja Optimistic Concurrency kilpaileville muutoksille.

Tietoturvaa käsitellään myöhemmin lisäosana

Asiakaspalveluportaalissa SSO, vuokralaisetarkastukset, turvalliset tiedostolataukset ja auditointi ovat tarpeen alusta lähtien. Jälkikäteen tehtynä se on kalliimpaa ja lisää tietoturvariskejä.

Puutteellinen läpinäkyvyys käytössä

Ilman Request-ID:itä, strukturoituja lokeja ja health-checkeja vianetsintä muuttuu salapoliisityöksi. Vastatoimenpide: observability palvelun ensimmäisissä releasessa pakollisena.

Yhteenveto: palveluydin yhdistää työpöydän voiman ja portaalin tavoitettavuuden

Delphi-työpöydän ja web-portaalin yhdistelmä on monessa yrityksessä realistisin tapa säilyttää ydinkäsittelyt ja samalla mahdollistaa ulkoinen yhteistyö. Oleellista on, ettei operoida kahta erillistä maailmaa, vaan luoda yhdistävä palveluydin: Use-Case-API:t, siistit oikeudet, jäljitettävät tilat, kontrolloidut datareitit sekä käyttömalli, jossa on lokitus, monitorointi ja suunniteltavat deploymentit.

Tällä tavoin modernisointi etenee vaiheittain: työpöytä pysyy tuottavana, portaali tuottaa varhain hyötyä ja arkkitehtuuri muuttuu askel askeleelta yhtenäisemmäksi ja ylläpidettävämmäksi.

Ammatillisessa kontekstissa myös Delphi Modernisierung on keskeinen osa, kun integraatiot, datavirrat ja jatkokehitys pitää saada pelaamaan yhteen.

Keskustele projektista tai modernisointihankkeesta Net-Base kanssa.