Kdaj ERP API ni dovolj: ko sinhronizacija prek vmesne baze deluje bolje

"ERP ima API, integracija je torej rešena." Ne.

Pri prvih sestankih s strankami pogosto slišim isto trditev. "Naš ERP ima API, dobavitelj nam je to potrdil." Iz tega sledi sklep, da bo povezovanje s spletno trgovino preprosto. V praksi je odgovor pogosto drugačen.

API obstaja, vendar bere samo en del podatkov. Ali ne piše naročil. Ali piše, ampak je tako počasen, da se uporabniki pritožujejo. Ali se zaklepa, kadar ERP ponoči izvaja interne procese. Vsak od teh primerov pomeni, da samo API ni rešitev. Včasih pomeni, da je čistejša pot postaviti vmesno bazo ali izmenjavo datotek, čeprav to zveni kot korak nazaj.

Kaj API dejansko obljublja in kaj naredi

API je vmesnik, prek katerega se sistemi pogovarjajo. V ERP-ju to pomeni, da zunanji sistem lahko prebere podatke ali jih spremeni, ne da bi mu dali neposreden dostop do baze. Razvit je za idealni scenarij: nekaj klicev na minuto, en zunanji sistem, dobro razumljene operacije.

Realnost spletne trgovine z ERP-jem je drugačna:

• Stotine ali tisoče klicev na uro za prikazovanje cen, zaloge in artiklov
• Več zunanjih sistemov hkrati: trgovina, sistem zvestobe, mobilna aplikacija, partnerski portal
• Kompleksne operacije, ki potrebujejo več zaporednih klicev, da se izvrši ena naloga
• Obdobja, ko ERP izvaja interne procese in je manj odziven

Razlika med "API obstaja" in "API zdrži tako uporabo" je velika. Prva trditev je tehnična, druga je operativna.

Trije problemi, ki jih API ne reši

Hitrostne omejitve

Modernejši API-ji imajo vgrajene omejitve. 100 klicev na minuto, 1.000 na uro, ali pa imajo počasen odziv pri kompleksnih vprašanjih. Pri spletni trgovini, kjer 50 obiskovalcev naenkrat brska po katalogu, se ta meja hitro doseže.

Pri starejših ERP sistemih je situacija obrnjena. API ni omejen, ampak je sam po sebi počasen. En klic za zalogo artikla traja 800 milisekund. Pri petih artiklih v košarici je to 4 sekunde čakanja. Spletna trgovina, ki dela tako, ni uporabna.

Reši se lahko z lokalnim predpomnilnikom v trgovini, ki klice združi in jih pošilja v paketih. Vendar to že ni več "samo API". To je arhitekturna odločitev, ki zahteva svoj sistem.

Bralni dostop, brez pisanja

Veliko ERP-jev je naredilo API zato, da poročilni sistemi berejo podatke. Branje deluje. Pisanje, recimo zapis novega naročila, je drugo poglavje. Ali ni uvedeno. Ali zahteva določeno obliko, ki ni dokumentirana. Ali piše v napačno tabelo in zapisa interni proces ne prevzame.

Pri spletni trgovini je pisanje naročil ključno. Naročilo, ki se ne zapiše v ERP, ni naročilo. Če API tega ne podpira, je treba pot ubrati drugače. Naročila se shranijo v vmesno bazo, od koder jih ERP uvozi v rednem ritmu.

Zanesljivost in vzdrževalna okna

ERP izvaja svoje notranje procese. Mesečna obračunavanja, vzdrževanje baze, varnostne kopije. V tem času API odpove ali postane neuporabno počasen. Pri spletni trgovini, ki dela 24 ur na dan, je to težava. Trgovina ne sme padati zato, ker ERP nekaj počne v ozadju.

Edina zaščita je vmesni sloj, ki ima zadnje znano stanje. Trgovina se pogovarja z vmesnim slojem, ne neposredno z ERP-jem. Če ERP pade, vmesnik vrne zadnje znano stanje. Ko se ERP vrne, se vmesnik uskladi.

Alternative: vmesna baza in izmenjava datotek

Ko API ne zadošča, sta v rabi dve preverjeni rešitvi in njuna kombinacija.

Vmesna baza

Postavi se ločena baza, do katere imata dostop oba sistema. ERP zapiše ali izvaža podatke v vmesno bazo (artikli, zaloge, ceniki, stranke). Spletna trgovina jih bere iz te baze. Naročila iz trgovine se zapišejo v vmesno bazo, ERP jih uvozi v ritmu, ki mu ustreza.

Prednosti:

• ERP ne čuti obremenitve od trgovine. Trgovina se pogovarja z bazo, ne z aplikacijo.
• Trgovina deluje, tudi če je ERP v vzdrževanju
• Struktura podatkov v vmesni bazi se prilagodi potrebam trgovine, ne ERP-ja
• Zlahka se priključijo novi sistemi (mobilna aplikacija, portal)

Slabosti:

• Zamik med spremembo v ERP in pojavom v trgovini (od minute do ure)
• Zahteva razvoj sinhronizacijskih procesov, ki redno prepisujejo podatke
• Treba je upravljati napake: kaj, če sinhronizacija pade, kaj, če pridejo dvojni zapisi

Izmenjava datotek

Najstarejša oblika integracije, ki se v določenih primerih še zdaj izkaže za najbolj zanesljivo. ERP izvozi datoteko CSV ali XML in jo postavi na strežnik. Trgovina jo prevzame in obdela. Naročila gredo v obratni smeri: trgovina pripravi datoteko, ERP jo uvozi.

Smiselna pot za primere, kjer:

• ERP nima API ali je preveč nestabilen
• Frekvenca posodobitev je nizka (cenik se osveži enkrat na dan)
• Količina podatkov je velika (pri 100.000 artiklih je paketna datoteka pogosto hitrejša kot več tisoč API klicev)
• Stranka želi minimalno odvisnost od dobavitelja ERP-ja

Slabost je rigidnost. Vsaka sprememba strukture datoteke zahteva spremembo na obeh straneh. In ker datoteke gredo v paketih, je zamik nekaj ur ali en dan, ne nekaj minut.

Hibridna rešitev

V praksi najpogosteje uporabljam hibridno pot. Pristope razdelim po naravi podatkov:

• Artikli in cenik: nočna izmenjava datotek (statični podatki, niso občutljivi na zamik)
• Zaloga: vmesna baza s sinhronizacijo vsakih 5 do 15 minut
• Naročila in stranke: API klic neposredno v ERP, ker proces zahteva sledljivost in potrditev

Vsak sloj uporabi tisto tehnologijo, ki najbolje ustreza zahtevam. Brez vsiljevanja "vsega prek API" ali "vsega prek datotek".

Kdaj API zadošča in kdaj ne

Okvirno pravilo, ki velja v praksi:

• API zadošča, kadar je ERP modernejši (Pantheon, Microsoft Business Central, SAP B1, Odoo), promet ni velik in en zunanji sistem komunicira
• API ni dovolj, kadar je ERP starejši (RCL, večina Vasco modulov, lokalne razvite rešitve) ali kadar promet preseže tehnične omejitve
• Vmesna baza je smiselna, kadar imate več zunanjih sistemov ali ko trgovina ne sme biti odvisna od razpoložljivosti ERP
• Izmenjava datotek je smiselna, kadar so podatki statični, paketi veliki ali kadar je ERP zaprt sistem brez API

Najpogostejša napaka pri postavitvi je predpostavka, da je API edina prava pot. Ko se izkaže, da API ne zdrži, projekt zaide v krpanje. Bolje je na začetku pošteno preveriti, kaj ERP prenese, in potem izbrati arhitekturo, ki temu ustreza.