API-liidestused ettevõttes: kuidas ühendada e-pood, ERP ja CRM?
Sisukord
- Miks API-liidestust vaja on?
- Milliseid andmeid saab süsteemide vahel liigutada?
- Milliseid süsteeme saab liidestada?
- Kuidas API integratsioon töötab?
- API päringud ja webhookid – mis vahe neil on?
- Levinud API-liidestuste näited
- Ühesuunaline või kahesuunaline sünkroniseerimine?
- Integratsiooni protsess samm-sammult
- Mis mõjutab API-liidestuse mahtu ja hinda?
- Kuidas tagada liidestuse turvalisus?
- Sümptom, võimalik põhjus ja lahendus
- Populaarsemad küsimused API-liidestuste kohta
API integratsioon on kontrollitud ühendus, mille kaudu saavad erinevad tarkvarasüsteemid omavahel andmeid vahetada. Näiteks võib e-poe tellimus liikuda automaatselt majandustarkvarasse, ERP saata e-poodi uuendatud laoseisu ning CRM lisada uue kliendi õigesse müügiprotsessi. Hästi kavandatud API-liidestused vähendavad andmete käsitsi sisestamist, dubleerimist ja inimlike vigade tekkimise võimalust. Kõiki protsesse ei pea täielikult automatiseerima – eesmärk on valida need andmevood, mille ühendamine annab ettevõttele reaalse kasu.
Paljud ettevõtted kasutavad korraga mitut süsteemi: e-poodi, raamatupidamistarkvara, kliendihaldust, laoprogrammi, makselahendust ja turundusplatvormi. Kui need süsteemid omavahel ei suhtle, tuleb samu tellimusi, kliente, tooteid ja makseid korduvalt sisestada.
Sellises olukorras võib API-liidestus muuta eraldiseisvad programmid üheks toimivaks tööprotsessiks.
Miks API-liidestust vaja on?
API-liidestuse peamine eesmärk on panna vajalikud andmed süsteemide vahel liikuma kokkulepitud reeglite järgi.
Ilma liidestuseta võib ettevõtte tavapärane töövoog näha välja selline:
- klient esitab e-poes tellimuse
- töötaja kopeerib tellimuse ERP-i või raamatupidamistarkvarasse
- tooted ja kliendiandmed sisestatakse uuesti
- laoseisu muudetakse käsitsi
- arve koostatakse eraldi
- tellimuse staatust uuendatakse e-poes
- kliendi kontakt lisatakse CRM-i või meililisti.
Iga käsitsi tehtav samm võtab aega ja loob võimaluse, et tootekood, kogus, aadress või hind sisestatakse valesti. Probleem suureneb koos tellimuste arvu, müügikanalite ja kasutatavate süsteemide hulgaga.
Süsteemide integratsioon ei pea tähendama kogu ettevõtte töö täielikku automatiseerimist. Mõnikord annab suurima tulemuse üks konkreetne andmevoog, näiteks uute e-poe tellimuste edastamine Directosse või müügiarvete saatmine Merit Aktivasse.
Milliseid andmeid saab süsteemide vahel liigutada?
Liidestuse kaudu liikuv info sõltub tarkvarade võimalustest ja ettevõtte töökorraldusest.
Kõige sagedamini sünkroniseeritakse:
- tellimusi ja tellimuste staatuseid
- tooteid, variatsioone ja tootekategooriaid
- hindu ja kampaaniahindu
- laoseisu erinevates ladudes
- klientide ja ettevõtete andmeid
- müügiarveid ja kreeditarveid
- maksete staatuseid
- tarneviise ja saadetiste infot
- pakiautomaatide valikuid
- CRM-i müügivihjeid ja tegevusi
- uudiskirja kontakte
- aruandluseks vajalikke koondandmeid.
Enne arendamist tuleb määrata, milline süsteem on iga andmeliigi peamine allikas. Kui näiteks laoseisu hallatakse Directos, ei tohiks e-pood ja ERP mõlemad sama väärtust sõltumatult muuta.
Vastasel juhul võib tekkida olukord, kus üks süsteem kirjutab teise tehtud muudatuse üle.
Milliseid süsteeme saab liidestada?
Liidestada saab üldjuhul süsteeme, millel on sobiv API, webhook, ekspordi-impordi võimalus või muu dokumenteeritud andmevahetuskanal.
Tavapärased kombinatsioonid on:
- WooCommerce ja Directo
- WooCommerce ja Merit Aktiva
- Shopify ja ERP
- e-pood ja raamatupidamistarkvara
- e-pood ja laohaldus
- e-pood ja CRM
- CRM ja e-posti turundusplatvorm
- veebivorm ja CRM
- e-pood ja makselahendus
- e-pood ja transporditeenus
- ERP ja aruandluslahendus
- mitu e-poodi ja üks keskne laosüsteem.
WordPress sisaldab REST API-t, mille kaudu saab rakendus lugeda ja sobivate õiguste olemasolul muuta WordPressi andmeid. Ka WooCommerce’i REST API võimaldab töötada muu hulgas tellimuste, toodete, klientide ja tarneandmetega. WordPress REST API dokumentatsioon, WooCommerce REST API dokumentatsioon
Kui ettevõte alles kavandab uut müügikanalit, tasub integratsioonivajadused läbi mõelda juba e-poe arenduse alguses. Hiljem lisatud liidestus võib samuti hästi toimida, kuid olemasolevate toodete, tellimuste ja kliendiandmete struktuur seab arendusele oma piirangud.
Kuidas API integratsioon töötab?
API on kokkulepitud tehniline liides, mille kaudu üks süsteem saab teiselt andmeid küsida või talle uusi andmeid saata.
Näiteks võib e-pood saata API kaudu ERP-i:
- tellimuse numbri
- kliendi nime ja kontaktandmed
- tellitud tooted
- kogused ja hinnad
- käibemaksuinfo
- tarneviisi
- makse staatuse.
ERP võib omakorda tagastada e-poodi:
- uuendatud laoseisu
- muudetud hinnad
- tellimuse töötlemise staatuse
- arve numbri
- saadetise jälgimiskoodi.
Andmed liiguvad enamasti JSON- või XML-vormingus. Need formaadid võimaldavad süsteemidel infot kindla struktuuri järgi lugeda, kuid kahe süsteemi väljad ei pruugi omavahel üks ühele kattuda. Seetõttu on integratsiooni üheks oluliseks osaks andmete kaardistamine.
Näiteks võib e-poes olla väli billing_company, kuid ERP ootab selle asemel eraldi kliendikoodi, registrikoodi ja juriidilist nime. Liidestus peab teadma, kuidas need väärtused õigesse formaati teisendada.
API päringud ja webhookid – mis vahe neil on?
API päringu puhul küsib üks süsteem teiselt regulaarselt, kas andmed on muutunud. Seda nimetatakse sageli perioodiliseks sünkroniseerimiseks.
Näiteks võib e-pood iga 15 minuti järel ERP-ist uuendatud laoseisu küsida. Sobiv intervall sõltub müügimahust, andmete kriitilisusest ja süsteemi piirangutest.
Webhook töötab sündmusepõhiselt. Kui e-poes tekib uus tellimus, saadab WooCommerce selle kohta kohe teate kokkulepitud aadressile. WooCommerce’i webhookid võivad reageerida näiteks tellimuse, toote, kupongi või kliendi loomisele ja muutmisele. WooCommerce’i webhookide dokumentatsioon
Praktikas võib üks integratsioon kasutada mõlemat lahendust:
- webhook käivitab uue tellimuse kiire edastamise
- perioodiline kontroll leiab üles andmed, mis jäid ajutise vea tõttu saatmata
- öine sünkroniseerimine kontrollib suuremaid toote- või laoseisumuudatusi.
Webhook ei ole automaatselt parem kui regulaarne API päring. Õige valik sõltub sellest, kui kiiresti peab info liikuma ja milliseid võimalusi ühendatavad süsteemid pakuvad.
Levinud API-liidestuste näited
WooCommerce ja Directo
WooCommerce’i ja Directo integratsiooni korral võib e-poe tellimus liikuda automaatselt Directosse. Samal ajal võivad tooteinfo, hinnad või laoseis liikuda Directost e-poodi.
Võimalik andmevoog:
- tooted ja laoseis tulevad Directost
- klient esitab WooCommerce’is tellimuse
- tellimus edastatakse Directosse
- Directos toimub edasine lao- ja arveprotsess
- tellimuse või saadetise staatus liigub tagasi e-poodi.
Enne arendust tuleb kokku leppida tootekoodide, ladude, käibemaksumäärade, kliendikaartide, transpordi ja makseviiside vastavus.
Directol on dokumenteeritud REST API ning lisaks XML Directi liides. Konkreetsete andmete kasutatavus sõltub aktiveeritud komponentidest, õigustest ja kliendi Directo keskkonnast. Directo API dokumentatsioon, Directo XML Direct
E-pood ja Merit Aktiva
E-poe ning Merit Aktiva vaheline liidestus võib vähendada müügiarvete ja kliendiandmete käsitsi sisestamist. Näiteks saab liidestus saata edukalt vormistatud tellimuse põhjal raamatupidamistarkvarasse müügiarve.
Merit Aktiva pakub kolmandatele osapooltele REST API-t, mis kasutab HTTP- ja JSON-põhist andmevahetust. API kasutatavus sõltub muu hulgas ettevõtte Meriti paketist ning konkreetsete toimingute toest. Merit Aktiva API dokumentatsioon
Enne ühendamist tuleb määrata:
- millal arve luuakse
- milline tellimuse staatus käivitab saatmise
- kuidas käsitletakse allahindlusi ja transporti
- kuidas leitakse või luuakse klient
- kuidas seotakse tooted raamatupidamise kontodega
- kuidas käsitletakse tagastusi ja kreeditarveid.
Kõiki e-poe tellimusi ei pruugi olla õige kohe raamatupidamisse saata. Näiteks tasumata või tühistatud tellimused võivad vajada teistsugust reeglit.
E-pood ja Maksekeskus
Levinud e-poeplatvormidele on Maksekeskusel olemas valmismoodulid. Kohandatud lahenduse puhul saab kasutada ka avalikku API-t, kui valmismoodul ei kata projekti vajadusi. Maksekeskuse moodulid ja liidestused
Integratsioon võib käsitleda näiteks:
- makse algatamist
- makse staatuse kontrollimist
- tagasimakseid
- makseviiside kuvamist
- transporditeenuseid
- saadetise registreerimist.
Valmismoodul on sageli mõistlikum kui erilahendus, kui selle funktsioonid vastavad ettevõtte vajadustele. Kohandatud API-liidestus on põhjendatud siis, kui ostuprotsess, andmemudel või kasutatav platvorm erineb standardlahendusest.
CRM-i ja veebivormide integratsioon
Veebilehe kontaktivorm võib lisada päringu automaatselt CRM-i, määrata sellele vastutaja ning käivitada teavituse.
Liidestuse kaudu võib CRM-i saata:
- kontaktandmed
- huvipakkuva teenuse
- päringu sisu
- kampaania või lehe, kust päring tuli
- nõusolekud
- müügivihje staatuse.
Oluline on vältida olukorda, kus iga vormisaatmine tekitab sama kliendi kohta uue kontakti. Enne kirje loomist võib liidestus kontrollida, kas sama e-posti või registrikoodiga klient on juba olemas.
CRM-i ja e-posti turunduse integratsioon
CRM-i ning uudiskirjaplatvormi ühendus võib hoida kontaktide nimekirjad ja nõusolekud kooskõlas.
Siin tuleb eristada:
- turundusnõusolekut
- teenusega seotud teavitusi
- kliendi staatust
- nimekirjast lahkumist
- kustutamis- ja parandamistaotlusi.
Integratsioon ei tohiks lisada inimest turundusnimekirja pelgalt seetõttu, et ta esitas hinnapäringu, kui selleks puudub sobiv nõusolek.
Ühesuunaline või kahesuunaline sünkroniseerimine?
Ühesuunalise integratsiooni puhul liiguvad andmed ühest süsteemist teise. Näiteks liiguvad e-poe tellimused Directosse, kuid Directo ei saada andmeid e-poodi tagasi.
Kahesuunalise integratsiooni korral liiguvad andmed mõlemas suunas. Näiteks:
- tellimused liiguvad e-poest ERP-i
- laoseis liigub ERP-ist e-poodi
- saadetise staatus liigub ERP-ist e-poodi
- kliendi parandatud andmed võivad liikuda tagasi CRM-i.
Kahesuunaline süsteemide integratsioon vajab täpsemaid reegleid. Tuleb otsustada, kumb süsteem on iga andmeliigi puhul peamine ja mida teha siis, kui sama kirjet muudetakse mõlemas süsteemis.
Rohkem liikumissuundi ei tähenda automaatselt paremat lahendust. Kui ettevõtte protsess vajab ainult ühesuunalist tellimuste edastamist, ei ole põhjust ehitada keerulisemat kahesuunalist sünkroniseerimist.
Integratsiooni protsess samm-sammult
1. Vajaduste ja praeguse töövoo audit
Kõigepealt kaardistatakse, kuidas info praegu liigub, millised tegevused tehakse käsitsi ning kus tekivad viivitused või vead.
Audit peaks vastama küsimustele:
- milliseid süsteeme kasutatakse
- millised andmed neis asuvad
- kes andmeid muudab
- milline süsteem on peamine andmeallikas
- kui kiiresti peab info liikuma
- millised erandid vajavad inimese otsust.
2. Tehniliste võimaluste kontroll
Seejärel kontrollitakse süsteemide API dokumentatsiooni, ligipääsu, autentimist, piiranguid ja testkeskkonna olemasolu.
API olemasolu ei tähenda automaatselt, et kõik vajalikud andmed on kättesaadavad. Mõni funktsioon võib sõltuda paketist, eraldi aktiveeritavast komponendist või teenusepakkuja antud ligipääsust.
3. Andmevoo ja spetsifikatsiooni koostamine
Spetsifikatsioon kirjeldab:
- millised andmed liiguvad
- mis suunas need liiguvad
- milline sündmus sünkroniseerimise käivitab
- kuidas väljad omavahel seotakse
- kuidas tuvastatakse olemasolev kirje
- kuidas välditakse duplikaate
- mida tehakse vea korral
- milline info logitakse.
Hea spetsifikatsioon vähendab arenduse käigus tekkivaid oletusi.
4. Arendus
Arenduse käigus luuakse API-päringud, andmete teisendamine, autentimine, vigade käsitlemine ja vajalikud taustaprotsessid.
Mahukama integratsiooni puhul võib e-poe ja ärisüsteemi vahel olla eraldi vahekiht. See võtab sõnumid vastu, töötleb neid järjekorras ning proovib ajutise vea korral saatmist hiljem uuesti.
5. Testimine
Testida tuleb nii tavapärast töövoogu kui ka erandeid:
- uus tellimus
- tühistatud tellimus
- tagastus
- puuduv tootekood
- vale käibemaksumäär
- olemasolev klient
- ajutiselt mittetöötav API
- sama sündmuse korduv saatmine
- väga suur tellimus
- puudulik või ootamatu vastus.
E-poe integratsiooni ei tohiks hinnata ainult selle järgi, kas üks testtellimus jõudis teise süsteemi.
6. Käivitamine ja jälgimine
Pärast käivitamist kontrollitakse tegelikke andmevooge ja logisid. Vajadusel täpsustatakse andmete vastavust või erandite käsitlemist.
API-liidestus vajab ka hilisemat jälgimist, sest ühendatud süsteemide API-d, autentimisviisid, väljad ja äriprotsessid võivad muutuda.
Mis mõjutab API-liidestuse mahtu ja hinda?
Integratsiooni töömahtu mõjutavad eelkõige:
- ühendatavate süsteemide arv
- ühe- või kahesuunaline andmevahetus
- sünkroniseeritavate andmete hulk
- API dokumentatsiooni kvaliteet
- vajalike funktsioonide olemasolu
- andmete praegune kvaliteet
- toodete ja klientide sidumise loogika
- erandite arv
- testkeskkondade olemasolu
- turva- ja logimisnõuded
- vajaliku jälgimise ulatus.
Lihtne ühe andmevooga e-poe liidestus ja mitme süsteemi kahesuunaline ERP integratsioon on täiesti erineva mahuga projektid. Seetõttu saab realistliku hinnangu anda pärast süsteemide ja soovitud töövoo kaardistamist.
Kuidas tagada liidestuse turvalisus?
Turvalisus algab õigesti piiratud ligipääsudest.
API integratsiooni puhul tuleks arvestada vähemalt järgmisega:
- andmed liiguvad HTTPS-ühenduse kaudu
- API-võtmeid ei paigutata avalikku JavaScripti ega koodihoidlasse
- ligipääsule antakse ainult vajalikud õigused
- sisendandmed valideeritakse
- webhookide allkiri või saladus kontrollitakse
- tundlikke andmeid ei kirjutata täielikult logidesse
- ligipääsuvõtmeid saab vajadusel vahetada
- vigased päringud ei jää märkamatuks.
WooCommerce’i API-võtmetele saab määrata lugemis-, kirjutamis- või mõlemad õigused. Mõistlik on anda integratsioonile ainult selle tööks vajalik juurdepääs. WooCommerce’i autentimise dokumentatsioon
Turvaline tehniline lahendus vähendab riske, kuid ükski integratsioon ei anna absoluutset garantiid kõigi rikete või rünnete vastu. Vajalikud on ka süsteemide uuendamine, ligipääsude haldamine ja regulaarne kontroll.
Sümptom, võimalik põhjus ja lahendus
| Sümptom | Võimalik põhjus | Võimalik lahendus |
|---|---|---|
| Tellimusi kopeeritakse iga päev käsitsi | E-pood ja ERP pole ühendatud | Saata uued tellimused API kaudu automaatselt ERP-i |
| E-poe laoseis ei vasta tegelikkusele | Mitmes süsteemis hallatakse eraldi koguseid | Määrata üks põhiladu ja sünkroniseerida laoseis sellest süsteemist |
| Sama klient tekib korduvalt | Kirjeid luuakse ilma olemasolevat klienti otsimata | Siduda kliendid e-posti, registrikoodi või keskse ID järgi |
| Arved jõuavad raamatupidamisse hilinemisega | Arveid luuakse käsitsi perioodi lõpus | Luua arve sobiva tellimuse või makse staatuse alusel |
| Tellimuse staatus ei jõua tagasi e-poodi | Integratsioon liigub ainult ühes suunas | Lisada vajalik staatuse või saadetise info tagasisünkroniseerimine |
| Mõni tellimus jääb teadmata põhjusel saatmata | Puudub vigade logimine ja korduskatse | Lisada jälgitavad vealogid, teavitus ning kontrollitud kordussaatmine |
| Toodete hinnad erinevad süsteemide vahel | Puudub kokkulepe, milline süsteem hinda juhib | Määrata hinna põhisüsteem ja sünkroniseerimise suund |
| Sama tellimus tekib kaks korda | Korduv webhook loob alati uue kirje | Kasutada unikaalset tellimuse ID-d ja idempotentset töötlemist |
| API-võti on nähtav veebilehe lähtekoodis | Salajane päring tehakse brauserist | Viia tundlik andmevahetus serveripoolsesse lahendusse |
| Integratsiooni viga avastatakse kliendi kaebusest | Puudub jälgimine ja teavitamine | Lisada logid ning teavitus korduvate või kriitiliste vigade kohta |
Populaarsemad küsimused API-liidestuste kohta
Mis on API-liidestus?
API-liidestus on tehniline ühendus, mis võimaldab kahel tarkvarasüsteemil kokkulepitud kujul andmeid küsida, saata ja uuendada.
Kas e-poodi saab ühendada Merit Aktiva või Maksekeskusega?
Ühendamine on sageli võimalik, sest Merit Aktival on ametlik API ning Maksekeskus pakub nii valmismooduleid kui ka avalikku API-t. Täpne lahendus sõltub kasutatavast e-poeplatvormist, paketist ja vajalikust andmevoost.
Mis saab siis, kui Directol pole vajalikku avalikku API otspunkti?
Kõigepealt kontrollitakse Directo REST API ja XML Directi toetatud komponente ning kliendi ligipääse. Kui vajalikku toimingut ametlik liides ei toeta, tuleb liidestuse ulatust muuta või kasutada mõnda muud Directo toetatud andmevahetusviisi.
Kui kaua API integratsiooni arendamine aega võtab?
Ajakulu sõltub süsteemide arvust, dokumentatsioonist, andmevoogudest, eranditest ja testimise mahust. Realistliku hinnangu saab anda pärast tehniliste võimaluste ja soovitud protsessi kaardistamist.
Kas API-liidestus töötab reaalajas?
Mõni andmevoog võib liikuda sündmusepõhise webhookiga peaaegu kohe, teine töötab sobiva intervalliga. Reaalajas liikumine pole alati vajalik ega kõigi süsteemide puhul võimalik.
Kuidas API-liidestuse turvalisus tagatakse?
Ligipääsud piiratakse vajalike õigustega, võtmeid hoitakse serveris, ühendused krüpteeritakse ning sisendid ja webhookide ehtsus kontrollitakse. Lisaks tuleb vältida tundlike andmete liigset salvestamist logidesse.
Kas olemasolevale e-poele saab integratsiooni lisada?
Jah, kui e-poe tehniline lahendus ja ühendatava süsteemi liides võimaldavad vajalikke toiminguid. Enne arendust tuleb kontrollida olemasolevate toodete, klientide ja tellimuste andmestruktuuri.
Kuidas välditakse topelttellimusi?
Liidestus peab kasutama unikaalset tellimuse või sündmuse tunnust ning kontrollima enne uue kirje loomist, kas see on juba töödeldud.
Mis juhtub, kui üks süsteem on ajutiselt maas?
Korralik lahendus salvestab vea, ei märgi toimingut ekslikult edukaks ning võimaldab ebaõnnestunud andmevahetust kontrollitult korrata. Täpne korduskatsete loogika sõltub integratsiooni kriitilisusest.
Kas API-liidestus vajab pärast valmimist hooldust?
Jah, sest ühendatud süsteemide API-d, õigused, väljad ja äriprotsessid võivad muutuda. Hoolduse ulatus sõltub integratsioonist ja sellest, kui oluline on andmevoog ettevõtte igapäevatöös.
Kui palju API-liidestus maksab?
Hind sõltub süsteemidest, andmete liikumise suunast, väljade kaardistamisest, eranditest ja testimise mahust. Konkreetne pakkumine koostatakse pärast soovitud andmevoo ja tehniliste võimaluste ülevaatamist.
