Delo od doma 2020: aplikacija je delovala. Je bila arhitektura pripravljena?

Pogled nazaj na nastanek Database Gatewaya v prvih tednih epidemije leta 2020. Članek zajema tudi poznejše razvojne faze, izdelek pa opisuje, kakršen je bil 29. oktobra 2026.

Spomladi 2020 je bilo vprašanje preprosto: kako bo lahko človek jutri delal od doma? Danes se glasi drugače: kako zagotoviti, da bo dostop do poslovnih podatkov varen, sledljiv, dovolj hiter in vzdržen tudi čez pet let? Vmes je zgodba zasilne rešitve, ki je delovala. Prav zato jo je bilo tako težko zamenjati.

V četrtek, 12. marca 2020, ob šestih zvečer je vlada razglasila epidemijo. Naslednje jutro je bilo v marsikaterem podjetju videti podobno. Vzemimo referentko ladijske agencije: sedi doma za kuhinjsko mizo, prenosnik ima povezan v VPN. Aplikacijo, v kateri vodijo prihode ladij, posadke in dokumente za carino, pozna do zadnjega polja. V pisarni se je seznam prihodov odprl v treh sekundah. Zdaj se vrti peščena ura. Spustni seznam pristanišč potrebuje pol minute. Pri drugem obrazcu povezava pade.

Razvijalec aplikacije dobi klic ob pol osmih. Prvi osumljenec je, kot vedno, usmerjevalnik. Drugi je VPN – na slo-tech je bilo že leta prej zapisano, da je »SMB preko VPN neuporabno počasen«. Tretji je Access sam. IT medtem šteje dostope VPN, ki jih ne more podvojiti s pritiskom na tipko, in ve, da podatkovni strežnik nikoli ne bi smel biti dosegljiv iz interneta. Vodstvo pove en stavek: »Ladje ne čakajo.«

Hitrejša povezava doma bi pomagala manj, kot si mislimo. Aplikacija za en sam obrazec podatkovni zbirki postavi na stotine majhnih vprašanj in na vsak odgovor počaka. V lokalnem omrežju en tak krog traja manj kot milisekundo, prek VPN in domače povezave večkrat dlje. Več pasovne širine tega čakanja ne skrajša.

»Access ni za to.« To je najpogostejši odgovor na forumih, kadar nekdo vpraša, zakaj mu aplikacija prek VPN ne deluje. Odgovor je udoben, a zgreši. Odloča, kako aplikacija dostopa do svojih podatkov. Razlikovati je treba štiri položaje.

Datoteka zbirke na omrežnem disku. Če je zaledje datoteka ACCDB na strežniku, vsaka delovna postaja bere datoteko sama, stran za stranjo. Microsoft izrecno odsvetuje deljeno zbirko Access prek prostrane omrežne povezave (WAN): lahko je počasna, zbirka pa se lahko poškoduje. Strah pred poškodovano bazo torej ni vraževerje.

Access spredaj, SQL Server zadaj. S povezanimi tabelami prek ODBC računa strežnik. V pisarni je to preizkušena pot, praksa pa ve, da se nad približno dvajsetimi zahtevnimi uporabniki tako ali tako splača SQL Server. Access pa postavlja veliko majhnih vprašanj: vsako seznamsko polje, kombinirano polje, podobrazec in vsota je po Microsoftovi dokumentaciji svoja poizvedba. Česar strežnik ne razume, Access izračuna lokalno. Če poizvedba povezuje lokalno in oddaljeno tabelo, lahko Access pošlje po eno poizvedbo za vsako lokalno vrstico. V pisarni tega nihče ne opazi, prek VPN se vsako čakanje sešteje. Poleg tega mora vsaka delovna postaja doseči podatkovni strežnik, povezava s prijavo pa je zapisana v datoteki Access.

Access na terminalskem strežniku. Oddaljeno namizje in RemoteApp sta Microsoftova podprta pot za oddaljeno delo z Accessom. Po povezavi potujejo le slike zaslona, Access in zbirka pa tečeta v isti strežniški sobi. To deluje dobro in marsikje je bil to leta 2020 pravi odgovor. Potrebuje pa strežnik, licence, uporabniške profile in za vsakega uporabnika lasten sprednji del aplikacije – vse to mora najprej obstajati.

Podatkovni posrednik prek HTTP. Aplikacija se ne pogovarja več s podatkovno zbirko, temveč s storitvijo, ki zbirko vpraša namesto nje. Nekaj večjih zahtev nadomesti množico majhnih, podatkovni strežnik pa za delovne postaje ostane nedosegljiv.

Vse štiri poti imajo svoj smisel, le čakanje, odgovornost in napadalno površino razporedijo drugače. Za naš položaj spomladi 2020 – poslovne aplikacije, deloma v Accessu, deloma aplikacije .NET za Windows, ki so iz Accessa zrasle, in skoraj nič časa – smo izbrali četrto.

Zgradili smo jo v nekaj dneh. Na strežniku je nastala spletna storitev, ki prek HTTP sprejme stavek SQL, ga izvede v podatkovni zbirki in rezultat vrne kot tabele. Na strani aplikacije je nastala majhna knjižnica .NET, ki je bila videti natanko tako kot običajen dostop do podatkov.

Odločitve je narekoval čas in sprejeli smo jih zavestno:

• Aplikacija je pošiljala svoje stavke SQL tako, kot jih je prej pošiljala zbirki. Nobenega obrazca ni bilo treba pisati na novo.
• Aplikacija je povedala, katero zbirko želi. Storitev je ime prevedla v shranjeno povezavo.
• Vsaka zahteva je nosila uporabniško ime in geslo. Storitev je preverila, ali taka oseba obstaja.
• Napake zbirke so se vrnile kot besedilo, da je uporabnik videl, kaj je šlo narobe.

Preizkusili smo, kar so uporabniki potrebovali naslednje jutro: odpreti obrazce, spremeniti podatke, natisniti poročila. Potem je šlo v uporabo. In je delovalo. Seznam prihodov se je spet odprl v nekaj sekundah, ladje so dobile svoje dokumente, agencija ni stala.

Zakaj je bilo mogoče v nekaj dneh? Ker nismo prepisali aplikacije, ampak samo njeno pot do zbirke. Knjižnica je posnemala štiri vloge, ki jih pozna vsak razvijalec .NET iz ADO.NET: povezavo, ukaz s parametri, bralnik rezultata in adapter, ki napolni tabele. Koda aplikacije je ostala, kakršna je bila. Zamenjali smo le tisto, kar je stalo za besedo Connection.

To je bila prava ideja in velja še danes: aplikacije zaradi nove transportne poti ne bi smeli pisati na novo. Današnji Database Gateway ji sledi z gonilnikom ODBC, prek katerega Access poveže tabele kot vedno.

Znan model pa tudi nekaj skrije. Knjižnica na odjemalcu ne pokaže, kaj počne strežnik. Iz takratne kode so poučna tri opažanja, ker niso napake v običajnem pomenu:

• Parametri ščitijo vrednosti, ne stavkov. Knjižnica je vrednosti pošiljala kot parametre in storitev jih je pravilno vezala. To prepreči, da bi vrednost postala del ukaza. Ne pomaga pa nič, če ukaz napiše odjemalec sam.
• Transakcija, ki tiho ni transakcija. Začetek transakcije je knjižnica zavrnila. Če pa je ukaz transakcijo dobil, jo je sprejela in prezrla. Aplikacija, ki je računala nanjo, je dobila posamezne stavke.
• Brez omejitev. Rezultat se je v celoti naložil v pomnilnik, časovne omejitve ni bilo, zahteve ni bilo mogoče prekiniti.

Pod časovnim pritiskom je bila vsaka od teh odločitev razumljiva. Skupaj opisujejo sistem, ki deluje, dokler se vsi obnašajo tako, kot pričakujemo.

Rešitev lahko svojo nalogo opravi v celoti in je hkrati arhitekturno nezrela. To ni protislovje, saj je »deluje« le ena od lastnosti, ki jih sistem potrebuje.

Najtežja je tretja vrstica. Storitev je preverila, kdo sprašuje, ne pa, kaj ta oseba sme. Uspešna prijava še ne pomeni pravic. Z veljavnim imenom in pravim geslom je bilo mogoče poslati kateri koli stavek, ki ga je smela izvesti prijava storitve, v kateri koli shranjeni zbirki, katere ime je poznal. Dokler je s storitvijo govorila le naša aplikacija, tega ni nihče opazil – saj je postavljala samo vprašanja, za katera je bila narejena. Meja je bila v lepem vedenju odjemalca, ne v storitvi.

Manjkalo je še nekaj: dokaz. Brez samodejnih testov nihče ne more trditi, da je slabost odpravljena. Lahko reče le, da je do zdaj ni nihče opazil.

Leto pozneje. Razvijalec razloži, da bi bilo treba zasilni dostop zgraditi na novo: s pravicami za vsak objekt, z beleženjem, z omejitvami in s testi. Naročnik vidi aplikacijo, ki leto dni teče brez izpada in brez incidenta. Zanjo je plačal. Zdaj naj plača še enkrat, za nekaj, kar po njegovem že dela. V sporih med naročniki in izvajalci se pogosto sliši tudi drug argument: če je račun plačan, je bil naročnik očitno zadovoljen.

Naročnik pri tem ni nerazumen. Vidi rešitev, ki deluje, in nov račun. Razvijalec vidi isto rešitev in seznam tveganj, ki jih noben uporabnik ne vidi. Oba imata prav, a nobeden drugemu svojega pogleda ne more dokazati. Naročnik notranje kakovosti tega, kar je plačal, ne more preveriti. Razvijalec pozna pomanjkljivosti in hkrati ponuja njihovo odpravo, zato je sumljiv ravno takrat, ko ima prav. Prenovo je tako težko upravičiti prav zato, ker zasilna rešitev ni nikoli odpovedala. Saj se ni nič zgodilo.

Zasilna rešitev iz krize je tehnični dolg z visoko obrestno mero. Vsaka aplikacija, ki se nanjo naveže, ga poveča, in dlje ko teče brez težav, teže ga je odplačati. Iz tega sledi neprijetno spoznanje: uspeh zasilne rešitve lahko postane največja ovira za njeno izboljšanje. Začasne rešitve so pri nas, kot vemo, najbolj trajne.

Na koncu ni prepričala tehnika, ampak vprašanje odgovornosti: kdo danes ve, kdo je prek tega dostopa bral ali spreminjal podatke? In kdo bo to razložil, ko bo geslo v napačnih rokah?

Prvi poskus, da bi vrzel zaprli, je bila projektna študija iz januarja 2025. Postavila je pravo novo vprašanje: ne več »kateri stavek?«, ampak »kateri objekt?« – tabela, pogled, procedura, naslovljeni prek naslova zahteve. Strežnik in zbirko pa je še vedno izbiral odjemalec. Ob njej se je pokazalo, da varnosti ni mogoče dograditi, če ostane temeljna predpostavka, da odloča odjemalec. Do konca je nismo zgradili. Današnji Database Gateway je nova koda, začeta avgusta 2026.

Odločilna sprememba ni nov protokol, ampak selitev odločitev. Leta 2020 je odjemalec odločal, katera zbirka, kateri stavek, kateri podatki. Danes odjemalec vpraša, odloči pa storitev.

Danes so izrecno opisane štiri meje zaupanja: med odjemalcem in prehodom (prijava ob vsaki zahtevi, pravilnik prijave, drugi faktor), med posredniškim strežnikom pred prehodom in prehodom (podatki o izvoru štejejo le od vpisanih posrednikov), med prehodom in zbirko (s katero prijavo teče SQL) ter med prehodom in njegovo skrbniško shrambo (skrivnosti šifrirane, glavni ključ ločen od njih).

Možnost, da odjemalec pošlje lasten stavek, še obstaja, saj jo Access potrebuje za prehodne poizvedbe (pass-through). A ni več tihi privzeti primer. Varnostni model navaja natanko tri poti, po katerih besedilo odjemalca doseže zbirko. Nepreverjeno samo s posebej dodeljeno pravico sql, namenjeno zaupanja vrednim programom. Preverjeno, tako da prehod stavek razčleni, dovoli le zaključen seznam oblik in vsak objekt preveri v katalogu in pravilih. Ali nepreverjeno s prijavo odjemalca v zbirko, če vir podatkov to izrecno dovoli – takrat mejo postavi SQL Server sam. Kje te poti puščajo preostala tveganja, piše v isti dokumentaciji.

Kaj se zgodi, če podatkovni posrednik zaupa odjemalcu? Za uporabnika najprej nič. Vidi svoje obrazce. Nevarnosti so eno raven globlje, pri vprašanjih, o katerih je leta 2020 odločal odjemalec, danes pa odloča prehod.

Stavek določa, kaj se bere in spreminja, napiše pa ga odjemalec.¹⁾ Vezani parametri ščitijo samo vrednosti v njem. Danes prehod SQL za običajne zahteve sestavi sam, lastni stavki pa tečejo le po treh opisanih poteh. Dokaz so samodejni testi in meritev na delujoči storitvi, pri kateri so se vsa preverjanja preverjenih stavkov izšla po pričakovanju. Meja: s pravico sql odjemalec doseže vse, kar doseže prijava vira podatkov. Ta prijava mora zato imeti ravno prav pravic, za to pa skrbi upravljavec.

To je bila vrzel iz leta 2020.²⁾ Danes velja pravilo za vir podatkov, vrsto objekta, objekt in metodo. Objekt, ki ga odjemalec ne sme brati, odgovori kot objekt, ki ga ni. Odjemalec niti ne izve, da obstaja.

Leta 2020 je za dostop do zbirke zadoščalo poznati njeno ime, zahteva brez imena pa je pristala v privzeti zbirki.³⁾ Danes so navzven vidni samo aliasi. Nizi povezave so šifrirani v skrbniški shrambi in jih skrbniški vmesnik nikoli ne vrne.

Geslo, ki potuje z vsako zahtevo, je zaščiteno le toliko kot povezava.⁴⁾ Danes prehod za skrbništvo, drugi faktor in prijavo SQL Server zahteva zaščiteno povezavo. Osebni ključi so shranjeni le kot kontrolna vrednost, nešifriran HTTP pa po namestitvi posluša samo na strežniku samem. Izmerjeno je tudi, da ključev ni ne v dnevniku ne v shrambi v berljivi obliki. Meja: če HTTP odprete navzven, ključi potujejo nešifrirani. Dokumentacija to pove naravnost.

Leta 2020 so sporočila zbirke dobesedno prišla do uporabnika.⁵⁾ Študija iz leta 2025 bi poslala še sled izvajanja programa. Danes gredo sporočila SQL Serverja ven brez skritih imen in vrednosti, poleg pa ID korelacije, po katerem upravljavec v dnevniku najde vso zgodbo.

Rezultat brez zgornje meje, zahteva brez časovne omejitve, poljubno število zahtev na minuto – to drži, dokler nekdo ne odpre velike tabele.⁶⁾ Danes prehod vrača rezultate v oknih do zgornje meje za vsak vir podatkov in omejuje število zahtev na odjemalca ter neuspešnih prijav. Meja: ti števci so v delovnem pomnilniku in se ob ponovnem zagonu začnejo od začetka.

To je resničen odgovor lokalne namestitve z dne 29. oktobra 2026 (sporočilo je v jeziku strežnika, tu nemško):

GET /api/v1/cf/fachdaten/dbo/Kunden HTTP/1.1

HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Wkl.Data.Gateway", charset="UTF-8"
X-Request-Id: 0HNPH0GANKPIA:00000001

{"error":{"code":"UNAUTHENTICATED","message":"Es wurde weder ein gueltiger Dienstschluessel noch eine Windows-Anmeldung vorgelegt.","correlationId":"0HNPH0GANKPIA:00000001"}}

Nobenega zapisa, nobenega namiga, ali tabela obstaja, nobene različice strežnika – je pa identifikator, pod katerim je zavrnitev zapisana v dnevniku. Poti iz leta 2020 na tej storitvi ni več.

Izvedeno je vse našteto. S samodejnimi testi, ki tečejo ob vsaki gradnji, je preverjenih več kot 1100 primerov storitve. Izmerjeni na delujoči storitvi so med drugim prijava, pravice, posredovanje osebe, konflikti pri pisanju, transakcije in preverjeni stavki. Nepreverjeni so zaenkrat delovanje s Kerberosom v domeni, posredovanje prek IIS, trajna obremenitev in več instanc. Neodvisnega varnostnega pregleda še ni bilo. Podatkovni prehod je objavljen kot predogled in še nima izdane različice.

Podatkovni posrednik čakanja v omrežju ne odpravi. Poskrbi lahko le, da ga je manj. Aplikacija, ki naloži celo tabelo in jo filtrira šele sama, je prek HTTP enako počasna kot prek VPN, le na drug način.

Zato Database Gateway dela po treh pravilih iz svoje referenčne dokumentacije:

• Filtrira prehod, ne odjemalec. Izbor, filtri, razvrščanje in strani spadajo v zahtevo. Excel in Power BI filtre prek Power Queryja pošljeta prehodu, računa pa zbirka.
• Okna namesto celote. Prehod na zahtevo vrne največ eno okno do svoje zgornje meje in povezavo na naslednje.
• Brez skritega ponavljanja. Če zahteva preseže časovno omejitev, to ne pomeni, da ni bilo nič zapisano. Odjemalec je le nehal čakati. O ponovitvi odloči aplikacija. Za zahteve, ki pišejo, obstaja zaščita pred dvojnim izvajanjem, konflikte pri pisanju pa prehod prepozna po različici vrstice: če je zapis medtem spremenil nekdo drug, ne zapiše ničesar.

Največ k zmogljivosti pa prispeva vidnost. Dnevnik obremenitve združi zahteve brez vrednosti v oblike: sto poizvedb obrazca, ki se razlikujejo le po številki stranke, je ena oblika. Za drage oblike navede običajen vzrok: povezana tabela, odprta v celoti, filter po stolpcu brez indeksa, program, ki lista globoko v veliko množico. Kar je bilo leta 2020 le občutek (»danes je spet počasno«), postane seznam, ki ga lahko odkljukamo.

Za koliko hitreje se bo odprl posamezen obrazec, s številkami še ne moremo povedati: meritve obremenitve in trajnega delovanja še ni. Izmerjeno pa je, da se rezultati prek prehoda ujemajo z enakimi poizvedbami neposredno v SQL Serverju.

Database Gateway sestavljajo storitev in štirje načini, kako jo uporabljati:

Excel in Power BI ne potrebujeta ničesar dodatnega. Vir OData bereta prek Power Queryja.

Prehod upravljate z aplikacijo Access. V vsakdanjem delu je videti takole: levo področji Betrieb in Zugang (delovanje in dostop), na sredini delovni seznami, na primer »Ohne zweiten Faktor« (brez drugega faktorja) ali »Schlüssel laufen ab« (ključi potekajo), desno izbrana oseba.

Viri podatkov. Zbirko enkrat vpišete v aplikacijo za upravljanje in navzven je vidna le pod svojim aliasom. Niz povezave je šifriran z glavnim ključem, ki je shranjen ločeno od shrambe. Spremembe veljajo brez ponovnega zagona.

Osebe in pravice. Pravilo navaja vire podatkov, vrste objektov, metode in ali dovoljuje samo branje. Pravila dobijo osebe, skupine Windows, prijave SQL Server in ključi storitve. Če želite, zbirka dela s prijavo osebe same. Sprožilci in privzete vrednosti stolpcev tako vidijo, kdo je ukrepal.

Prijava glede na okolje. Račun Windows, prijava SQL Server, osebni ključ za vsako napravo ali ključ storitve za programe. Pravilnik prijave glede na način, omrežje in državo odloči, ali prijava zadošča, ali je potreben drugi faktor ali pa prijavo zavrne. V pisarni zadošča ključ, od zunaj se doda koda iz aplikacije za preverjanje pristnosti.

Sledljivost in diagnostika. Vsaka zahteva za podatke ali skrbništvo se zabeleži s klicateljem, aliasom, objektom, metodo, rezultatom in ID-jem korelacije, tudi zavrnjena. Vsaka sprememba nastavitev je v dnevniku sprememb. Dnevnik prijav pokaže izvor in nenavadne vzorce, dnevnik obremenitve drage zahteve. V dnevnikih ni ključev, gesel, nizov povezave ali vrednosti.

Namestitev. Namestitveni program nastavi storitev Windows, potrdilo za HTTPS (tudi prek Let's Encrypt) in požarni zid. Storitev s seboj prinese svoje izvajalno okolje in teče v sistemih Windows 10 in 11 ter Windows Server od različice 2016. Zbirka je SQL Server od različice 2016. Na delovni postaji Access od različice 2010 potrebuje gonilnik ODBC v isti bitni različici kot Office.

Omejitve, kot jih navaja dokumentacija sama: priložen je le priklop na SQL Server. Skrbniška shramba pripada natanko eni instanci, odpornosti na izpad z dvema instancama ni. Če prehod izpade, nobena delovna postaja ne pride do podatkov – nova odvisnost, ki je pri neposrednem dostopu ni bilo. Gonilnik ODBC pa ne ponuja vseh zmožnosti gonilnika ODBC za SQL Server.

Kaj se s tem spremeni v podjetju? Recimo, da ladijska agencija vodi prihode, posadke in carinske dokumente v SQL Serverju in jih ureja z aplikacijo Access. Po prehodu delovne postaje podatkovnega strežnika ne dosežejo več. V datotekah Access ni gesla za zbirko. Referentka v pisarni dela s svojim ključem, od doma s ključem in kodo. Zunanji špediter, ki pripravlja carinske dokumente, dobi za dva tedna ključ samo za branje, ki sam poteče. Ključ izgubljenega prenosnika se prekliče, velja od naslednje zahteve. In ko vodstvo vpraša, kdo je marca spremenil podatke o posadki, odgovor obstaja. Obrazci in poročila aplikacije ostanejo, kakršni so; preklopijo se le povezave njenih tabel.

Spletno storitev, ki SQL posreduje prek HTTP, izkušena ekipa napiše v nekaj dneh. Leta 2020 smo jo sami. Lastni razvoj torej ni slaba ideja. Vprašanje je, kaj pride po prvih dneh.

Lastni razvoj je smiseln, kadar gre za eno samo aplikacijo v lastnem omrežju, nekaj tabel, ekipo z varnostnimi izkušnjami in čas za vzdrževanje. Izdelek se splača, ko mora do istih podatkov več aplikacij, Excel in lastni programi, ko se pridruži dostop od zunaj in ko mora nekdo strankam, presojevalcem ali lastnemu vodstvu dokazati, kdo kaj sme in kdo je kaj naredil.

Z nakupom podatkovnega posrednika ne dobite le programskega vmesnika, ampak tudi delo, ki pride po prvem dnevu: preverjanja, teste, vzdrževanje. Database Gateway ima proizvajalca in opisan postopek, po katerem ranljivost prijavite in jo proizvajalec odpravi. Vsaka izdana različica naj bi pet let dobivala varnostne posodobitve – podatkovni prehod pa je še v predogledu in izdane različice še nima. Kar presega to (odzivni časi, podpora, trajanje), določi pogodba, ne ta članek. To delo mora vedno nekdo opraviti. Odprto je le, kdo.

Marca 2020 je bilo vprašanje: kako bo referentka jutri delala od doma? Odgovor je bil zasilni dostop in svojo nalogo je opravil. Današnje vprašanje je drugačno: kako zagotoviti, da bo dostop do poslovnih podatkov varen, sledljiv, dovolj hiter in vzdržen, ko je izjema od takrat že zdavnaj vsakdan? Database Gateway je naš odgovor: o dosegljivem odloča prehod, oseba pride v zbirko kot ona sama, in vsaka zahteva pusti sled.

Ni pravi odgovor za vsakogar. Podjetje z eno samo aplikacijo v lastnem omrežju in terminalskim strežnikom, ki dela, ga morda ne potrebuje. Če pa danes še vedno uporabljate dostop iz leta 2020 (sam narejen, kupljen ali podedovan), si odgovorite na eno vprašanje: ali želite podatkovni posrednik sami razvijati in leta vzdrževati, skupaj z njegovimi varnostnimi mejami, regresijskimi testi, skrbništvom in nadgradnjami – ali je smiselneje uporabiti izdelek, ki je že razvit in preverljiv?

Ali vaše aplikacije Access še vedno neposredno dostopajo do produkcijskega SQL Serverja, vi pa načrtujete delo zunanjih izvajalcev ali dostop od zunaj? Potem je smiseln prvi korak pregled obstoječih podatkovnih poti: kdo doseže katero zbirko, s katero prijavo in od kod. Na tej podlagi presodimo, ali je Database Gateway prava rešitev in kakšen bi bil obseg uvedbe. Pregled vas k uvedbi Database Gatewaya ne zavezuje.

Naslednji koraki:

• Preberite: predstavitev Database Gatewaya, stran izhodišče, primeri uporabe in druge možnosti in varnostni model s preostalimi tveganji.
• Preizkusite: od praznega strežnika do prve poizvedbe korak za korakom.
• Primer: Še en nemški kupec. Še ena povezava? pokaže, kako kupci in dobavitelji prek objavljenega pogleda berejo le svoje vrstice.
• Pogovorite se: pregled vaših današnjih podatkovnih poti, tehnična predstavitev ali pilotni projekt z eno aplikacijo. Dogovorite se za pogovor.
• Dajte pregledati: lasten podatkovni dostop lahko preverimo v varnostni presoji. Če želite prenoviti aplikacijo samo, je pot opisana pod posodobitvijo podedovanih sistemov.

Prehod, gonilnik in odjemalec nimajo licence za posamezno delovno postajo. Kaj bi uvedba pri vas zajemala (namestitev, prilagoditev, podporo), se dogovorimo v pogovoru, ne iz cenika.