Tehnologija · Integracije
Integracija sistemov in avtomatska izmenjava podatkov.
Povežemo sisteme, določimo vir resnice za vsak podatek in poskrbimo, da so napake vidne, ne tihe.
Kdaj nas običajno vključijo
- obstoječi sistem ne zadošča več
- delo poteka v preglednicah
- podatki se podvajajo med sistemi
- potrebujete novo aplikacijo
- želite prenoviti star sistem
- razvijate nov digitalni produkt
Ni vedno treba razviti vsega na novo
Če lahko obstoječi sistem kakovostno prenovimo ali povežemo z drugimi, je to pogosto hitrejše in cenejše od nove aplikacije. Najprej pogledamo, kaj je vredno ohraniti.
Kaj to pomeni za vas
- Manj preglednic in ročnih statusov.
- Manj podvajanja podatkov med sistemi.
- Enoten pregled procesa za vodstvo in ekipo.
- Sistem, ki raste skupaj s podjetjem.
- Manj odvisnosti od posameznika, ki »edini ve, kako gre«.
Problem → rešitev
Kaj povezujemo
- ERP
- CRM
- spletne trgovine
- plačilne sisteme
- računovodstvo
- dokumentne sisteme
- Google Workspace in Microsoft okolje
- registre in zunanje API-je
- logistiko in skladišče
Kako zagotovimo zanesljivost
Vir resnice
Za vsak podatek natančno določimo, kateri sistem odloča in kaj se zgodi ob konfliktu.
Ponovni poskusi
Vrste in ponovni poskusi brez podvajanja zapisov - prenos se ne izgubi.
Nadzor
Opozorilo ob napaki, pregled zgodovine prenosov in ročni ponovni zagon.
Kdaj je integracija zaključena
Produkcijska integracija ni zaključena takrat, ko podatek prvič pride iz sistema A v sistem B. Določiti je treba tudi, kaj je veljaven podatek, kaj se zgodi ob napaki, kolikokrat se prenos ponovi, kdaj se odneha, kdo je o tem obveščen, kako se prenos pozneje preveri in kdo je odgovoren za neuspešne zapise.
Zato integracije obravnavamo kot samostojen projektni sklop z lastnimi zahtevami, testnimi scenariji in merili prevzema - ne kot zadnjo postavko na seznamu funkcionalnosti.
Načini povezave in kdaj je kateri primeren
| Način | Kdaj je primeren | Na kaj je treba paziti |
|---|---|---|
| REST API | sinhrona izmenjava, uporabnik potrebuje odgovor takoj | časovne omejitve, obravnava napak, omejitve števila klicev |
| SOAP | starejši sistemi in registri, ki drugega vmesnika nimajo | shema, različice, obsežnejša obravnava napak |
| Webhook | zunanji sistem javi dogodek takoj, ko nastane | preverjanje pristnosti, podvojena sporočila, ponovni poskusi |
| Izmenjava datotek | velike količine zapisov, sistemi brez API-ja | struktura datoteke, kodiranje, delne datoteke, zaklepanje |
| Razporejen uvoz | podatki se ne spreminjajo pogosto | okno izvedbe, obseg prenosa, ravnanje z zamudami |
| Paketna obdelava | obsežne obdelave zunaj delovnega časa | čas trajanja, ponovni zagon, delni uspeh |
| Asinhrona obdelava | obdelava traja ali cilj ni vedno dosegljiv | vrsta sporočil, ponovni poskusi, sporočila, ki jih ni mogoče obdelati |
Kadar sistem ne sme čakati na takojšen odgovor, prenos poteka asinhrono: zahteva se uvrsti v vrsto, obdela se v ozadju, ob napaki se ponovi po dogovorjenem pravilu, sporočila, ki jih po več poskusih ni mogoče obdelati, pa se odložijo v ločen sklad, kjer so vidna in jih je mogoče ponovno zagnati. Konkretne tehnologije za to izberemo glede na okolje naročnika.
Prijava, pravice in identiteta med sistemi
Vsaka povezava potrebuje odgovor na tri vprašanja: kdo kliče, kaj sme in kako se to preverja. Način izberemo glede na to, kaj zunanji sistem podpira in kakšne so varnostne zahteve naročnika.
- OAuth in žetoni z omejeno veljavnostjo
- API ključi z ločenimi pravicami po namenu
- enotna prijava za uporabniške scenarije
- strežniški certifikati in omejitve po IP, kadar so zahtevani
- ločeni dostopi za testno in produkcijsko okolje
- hramba skrivnosti zunaj izvorne kode in menjava dostopov
Validacija, napake in ponovni poskusi
Integracija, ki ob napaki samo obmolkne, je nevarnejša od integracije, ki ne deluje: podatki so videti pravilni, čeprav niso. Zato vnaprej določimo, kaj je veljaven zapis, kaj se zgodi z neveljavnim, kdaj se prenos ponovi in kdo je obveščen, če ponovni poskusi ne uspejo.
Kdo je lastnik neuspešnega zapisa
Za vsako integracijo določimo, kdo na strani naročnika obravnava zapise, ki niso bili preneseni. Brez tega se v praksi ne obravnava nihče.
- preverjanje vhodnih podatkov pred zapisom v ciljni sistem
- pretvorbe med različnimi zapisi istega podatka
- ponovni poskusi brez podvajanja zapisov
- časovne omejitve in obnašanje, ko zunanji sistem ne odgovori
- ločen sklad zapisov, ki jih ni bilo mogoče obdelati
- obveščanje odgovorne osebe ob napaki, ne šele ob reklamaciji
- ročni ponovni zagon posameznega prenosa
Nadzor, usklajevanje in revizijska sled
Po uvedbi mora biti mogoče odgovoriti na vprašanje »ali so danes vsi zapisi prišli skozi« brez ugibanja. Zato belimo zgodovino prenosov, stanje posameznega zapisa in razlog za neuspeh, ter omogočimo primerjavo med izvornim in ciljnim sistemom.
- zgodovina prenosov z izvorom, časom in izidom
- opozorila ob zastoju in ob nenavadnem obsegu prenosov
- periodično usklajevanje med sistemoma
- revizijska sled za spremembe pomembnih zapisov
- različice vmesnika in načrt prehoda ob spremembi
Migracija podatkov je svoj projektni sklop
Migracija podatkov pri kompleksnih sistemih ni uvoz baze. Je zaporedje korakov, v katerem se najprej ugotovi, kaj v virih sploh je, in šele nato, kaj od tega gre v novi sistem.
Popis vira
kateri sistemi, katere tabele, kdo je lastnik podatka in kdaj je bil nazadnje vzdrževan
Preslikava
kateri podatek v viru ustreza kateremu polju v cilju in kaj z njim, kadar ustreznika ni
Čiščenje
podvojeni zapisi, manjkajoča polja, neenotni zapisi in neveljavni identifikatorji
Pretvorba
uskladitev oblik zapisa, šifrantov in enot
Testni prenos
prenos na testno okolje in pregled rezultata z uporabniki
Preverjanje
primerjava števila zapisov, vsot in vzorčnih primerov
Usklajevanje
obravnava razlik in odločitev o zapisih, ki jih ni mogoče prenesti
Končni prenos
prehod v produkcijo z dogovorjenim oknom in načrtom vrnitve
Kakovost podatkov in vir resnice
Integracija sama po sebi ne odpravi slabih podatkov - jih samo hitreje razširi. Če ERP, CRM in portal za istega kupca uporabljajo različne identifikatorje, povezava sistemov problema ne reši, ampak ga naredi vidnega v vseh treh.
Zato za vsak pomemben podatek določimo, kateri sistem je vir resnice, kdo ga sme spreminjati in kaj se zgodi ob nasprotujočih si vrednostih.
- manjkajoči zapisi in nepopolna polja
- podvojeni zapisi iste stranke ali izdelka
- neenotni zapisi datumov, naslovov in davčnih številk
- prekinjene povezave med zapisi
- zastareli podatki, ki jih nihče ne vzdržuje
- nejasno lastništvo podatka znotraj organizacije
Tipičen primer
Spodnji primer ni referenca, ampak ponazoritev tipa naloge, kakršne rešujemo.
Spletni portal mora ob oddaji zahtevka preveriti stranko v CRM, pridobiti podatke o pogodbi iz ERP, shraniti priloženi dokument v dokumentni sistem in uporabniku vrniti status obdelave. Če ERP v tistem trenutku ni dosegljiv, mora zahtevek vseeno nastati, uporabnik mora dobiti jasen odgovor, prenos pa se mora samodejno ponoviti in ob dokončnem neuspehu opozoriti odgovorno osebo.
Kdo dela na integracijskem sklopu
Ekipa se sestavi glede na obseg. Pri manjši povezavi zadostujeta arhitekt in backend razvijalec, pri obsežnejši izmenjavi med več sistemi pa so vloge ločene.
- solution architect za načrt izmenjave in vir resnice
- poslovni analitik za pravila, izjeme in preslikave
- backend razvijalec za izvedbo vmesnikov
- strokovnjak za podatke za migracijo in usklajevanje
- QA inženir za testiranje API-jev in scenarijev napak
- DevOps inženir za okolja, nadzor in opozorila
Kaj potrebujemo od naročnika
- seznam sistemov, ki se povezujejo, in njihove različice
- dokumentacijo vmesnikov ali dostop do ponudnika sistema
- dostop do testnega okolja zunanjega sistema
- vzorčne podatke, tudi neurejene
- odgovorno osebo za pravila in izjeme
- dogovor o tem, kdo obravnava neuspešne prenose
Kaj naročnik prejme
- delujočo integracijo v produkcijskem okolju
- dokumentacijo vmesnikov, preslikav in pravil
- testne scenarije, vključno s scenariji napak
- pregled zgodovine prenosov in stanja zapisov
- opozorila in dogovorjen postopek ob napaki
- poročilo o migraciji in usklajevanju, kadar je bila del obsega
Kako sistem zgradimo
Arhitektura
Podatkovni model, moduli in meje sistema določimo pred razvojem, da kasnejše širitve ne zahtevajo prepisa.
UX/UI
Uporabniške poti in prototip ključnih zaslonov potrdite, preden se pišejo funkcionalnosti.
Frontend in backend
Vmesnik in strežniški del razvijamo z istim standardom: berljiva koda, pokrita z avtomatskimi testi.
Integracije
Povezave z ERP, CRM, dokumentnimi sistemi in registri, z beleženjem in ponovnimi poskusi.
Podatki
Migracija, čiščenje in pravila za kakovost podatkov, da nov sistem ne podeduje starih napak.
Varnost, kakovost, uvedba
Varnost
Prijava in pravice, šifriranje v prenosu in mirovanju, revizijska sled ter pregled pred objavo.
Testiranje
Avtomatski testi, regresija in prevzemno testiranje po vaših merilih, ne po naših.
Uvedba
Ločena okolja, postopna objava in možnost vrnitve na prejšnjo različico v nekaj minutah.
Primopredaja
Koda, dostopi, dokumentacija in izobraževanje ekipe. Sistem ostane vaš.
Vzdrževanje
Dogovorjen odzivni čas, nadzor delovanja in mesečni obseg ur za nadgradnje.
Sorodno delo
Pogosta vprašanja
Kaj potrebujemo, da lahko začnete?
Seznam sistemov, dokumentacijo vmesnikov ali stik s ponudnikom sistema, dostop do testnega okolja in vzorčne podatke. Če dokumentacije ni, jo v obsegu analize pripravimo sami.
Kaj, če zunanji sistem nima API-ja?
Uporabimo izmenjavo datotek, razporejen uvoz ali povezavo prek vmesne baze. Način izberemo glede na to, kaj sistem dopušča in kako sveži morajo biti podatki.
Kaj se zgodi, ko prenos ne uspe?
Zapis se ne izgubi. Prenos se ponovi po dogovorjenem pravilu, neuspešni zapisi ostanejo vidni, odgovorna oseba pa je obveščena; posamezen prenos je mogoče tudi ročno ponoviti.
Ali lahko integracijo naredite brez posega v obstoječi sistem?
Pogosto da - z uporabo obstoječih vmesnikov ali vmesnega sloja. Kadar sistem potrebne informacije ne izpostavi, je poseg neizogiben; to ugotovimo v analizi, ne med izvedbo.
Kdo je odgovoren za podatke, ki so slabe kakovosti?
Kakovost podatkov je poslovno vprašanje, ne tehnično. Napake pokažemo, predlagamo pravila čiščenja in jih izvedemo, odločitev o pravilni vrednosti pa je pri naročniku.
Ali lahko prevzamete obstoječo integracijo, ki jo je naredil nekdo drug?
Da, po pregledu izvedbe, dostopov in dokumentacije. Rezultat pregleda so ugotovitve, seznam tveganj in predlog stabilizacije.
Preberite tudi
Sorodne rešitve
Se sliši kot vaš projekt?
Pošljite opis projekta, obstoječi sistem, razpisno dokumentacijo ali datum dogodka.