WordPressi integratsiooni tegelik hind: API arendus on ainult pool tööst

WordPressi integratsiooni kirjeldatakse vahel ühe lausena: “API on olemas, vaja on ainult ühendus teha.” Tegelik töö algab aga hetkest, mil esimene päring on edukalt saadetud. Seejärel tuleb otsustada, millised andmed liiguvad, kumb süsteem on nende algallikas, kuidas lahendatakse vastuolud ja mis juhtub siis, kui üks osapool ajutiselt ei vasta.

WordPressi integratsiooni hind sõltub vähem üksikust API-päringust ja rohkem kogu andmevoo töökindlusest. Kui ühendus mõjutab tellimusi, hindu, laoseisu või kliendiandmeid, peab lahendus oskama vigu märgata, päringuid turvaliselt korrata ja anda inimesele arusaadava ülevaate.

API olemasolu ei tähenda veel valmis integratsiooni

API kirjeldab, kuidas süsteemiga tehniliselt suhelda. Näiteks võib see lubada lugeda tooteid, saata tellimusi või uuendada kliendiandmeid. WordPressi enda REST API käsiraamat selgitab samal põhimõttel, kuidas rakendused saavad WordPressiga struktureeritud andmeid vahetada.

Dokumentatsioon ei otsusta siiski sinu eest, milline süsteem on hinna, laoseisu või kliendi aadressi algallikas. Samuti ei kirjelda see tavaliselt sinu ettevõtte erandeid: millal tellimus on lõplik, kuidas käsitleda osalist tagastust või mida teha tootega, mille kood on kahes süsteemis erinev.

1. Andmete vastendamine ja algallikas

Esimene suurem töö on andmeväljade vastendamine. Ühes süsteemis võib kliendi nimi olla üks väli, teises eraldi ees- ja perekonnanimi. Ühes võib toode olla tuvastatud SKU järgi, teises sisemise numbriga. Käibemaks, ümardamine, valuuta, kampaaniahind ja tellimuse staatus võivad samuti erineda.

Enne arendust tuleb iga olulise andmeliigi kohta kokku leppida kaks asja:

• milline süsteem on selle andme algallikas;
• mis reegli järgi lahendatakse erinevad või puuduvad väärtused.

Kui seda otsust ei tehta, võib tehniliselt töötav ühendus hakata korrektseid andmeid valedega üle kirjutama. Seetõttu on andmemudeli kaardistus sageli väärtuslikum kui esimene koodirida.

2. Veaolukorrad ja turvalised korduskatsed

Välised süsteemid ei ole alati kättesaadavad. Päring võib aeguda, internetiühendus katkeda või vastus saabuda puudulike andmetega. Oluline ei ole ainult see, et viga kuvatakse, vaid et süsteem teab, mida edasi teha.

Hea integratsioon eristab ajutist ja püsivat viga. Ajutise vea korral võib päringut hiljem korrata. Püsiva vea korral, näiteks tundmatu tootekoodi puhul, peab inimene saama selge teate koos piisava infoga, et probleem lahendada.

Korduskatse peab olema ka turvaline. Kui tellimuse saatmine katkeb pärast seda, kui ERP on tellimuse juba vastu võtnud, ei tohi järgmine katse luua duplikaati. Sellised juhtumid ei paista õnnestunud demo ajal välja, kuid mõjutavad päris töövoogu kõige rohkem.

3. Autentimine ja ligipääsud

Integratsioon vajab enamasti ligipääsu, mille õigused peavad olema võimalikult täpsed. Avaliku veebivormi kaudu ei tohiks saada lugeda tellimusi ning laosüsteemile mõeldud võti ei pea lubama kasutajaid hallata. Võtmete hoiustamine, vahetamine ja aegumine kuuluvad seetõttu töömahu sisse.

WordPressi puhul sõltub sobiv autentimisviis sellest, kas ühendus töötab kasutaja brauseris või välise süsteemi kaudu. Ametlik WordPressi autentimise juhend annab tehnilise lähtekoha, kuid konkreetne lahendus peab arvestama ka ühendatava teenuse nõuete ja sinu andmete tundlikkusega.

4. Logid, teavitused ja seire

Kui integratsioon töötab taustal, peab selle seis olema nähtav. “Midagi ei sünkroniseerunud” ei ole toe jaoks piisav info. Vajalik on teada, millal töö käivitus, milline kirje ebaõnnestus, mida väline süsteem vastas ja kas korduskatse on plaanitud.

Logi ei pea olema tehniline sein. Sageli on parem lihtne haldusvaade, kus vastutav inimene näeb viimase sünkroniseerimise aega, vigaste kirjete arvu ja võimalust konkreetne kirje uuesti töödelda. Kriitiliste vigade korral lisandub e-kirja või muu kanali teavitus.

5. Testimine päris eranditega

Ühe korrektse tellimuse liikumine ei tõesta veel integratsiooni töökindlust. Testandmed peavad katma ka tühjad väljad, erimärgid, topeltkirjed, tagastused, muutunud hinnad ja olukorra, kus väline süsteem ei vasta.

Testkeskkond on eriti oluline siis, kui ühendus mõjutab raha või kliendisuhtlust. Tootmiskeskkonnas proovimine võib tähendada topelttellimusi, valesid kirju või vigast laoseisu. Pärast avaldamist on mõistlik hoida esimeste päevade või nädalate jooksul tavapärasest tihedamat seiret.

Näide: WooCommerce ja ERP

Tüüpilises WooCommerce’i e-poe ühenduses liiguvad ERP-ist veebipoodi tooted, hinnad ja laoseis ning veebipoest ERP-i tellimused ja kliendiandmed. Juba selle lihtsa kirjelduse sees on mitu ärilist otsust.

• Kas kampaaniahinda hallatakse ERP-is või WooCommerce’is?
• Kas laoseis broneeritakse ostukorvis või alles tasutud tellimuse järel?
• Kuidas seotakse külalisena ostnud klient olemasoleva ERP-i kontaktiga?
• Mis juhtub, kui makse õnnestub, kuid ERP ei vasta?

Korstnagrupi ERP-i projekt näitab laiemat pilti sellest, kuidas WordPress võib olla osa ettevõtte igapäevasest töövoost, mitte ainult avalik veeb. Mida lähemal on integratsioon põhitegevusele, seda olulisemad on õigused, jälgitavus ja selge vastutus.

Milline lahendus on mõistlik?

Valmis plugin sobib, kui mõlema süsteemi protsessid vastavad toetatud standardile ja erandeid on vähe. See on enamasti kiireim algus, kuid enne valikut tasub kontrollida toe kvaliteeti, uuenduste ajalugu ja seda, kelle kontrolli alla jäävad andmed.

Valmisühendus koos väikese kohandusega sobib siis, kui põhivoog töötab, kuid mõni ärireegel vajab täpsustamist. Kohandus peab olema tehtud viisil, mida saab plugina uuendamisel säilitada.

Kohandatud integratsioon on põhjendatud, kui andmevoog on ettevõtte jaoks kriitiline, süsteeme on mitu või valmisühendus sunniks protsessi ebasobivalt muutma. Algne töömaht on suurem, kuid vastutus, logika ja edasiarendus on selgemalt sinu kontrolli all.

Mida integratsiooni hinnapakkumine peaks sisaldama?

Võrreldav pakkumine ei piirdu reaga “API arendus”. Otsi sealt vähemalt järgmisi osi:

• ühendatavad süsteemid, andmeobjektid ja liikumise suund;
• andmete vastendus ja algallika reeglid;
• autentimine ja ligipääsude haldus;
• veakäsitlus, korduskatsed ja duplikaatide vältimine;
• logid, haldusvaade ja teavitused;
• testkeskkond, testjuhtumid ja vastuvõtukriteeriumid;
• avaldamise plaan, seire ja hoolduse vastutus.

Kui võrdled mitut pakkumist, aitab sind ka artikkel WordPressi hinnapakkumise võrreldavusest. Integratsiooni puhul tasub eriti kontrollida, kas pakkujad on arvestanud sama hulga andmevoogude ja veaolukordadega.

Kuidas saada realistlikum hinnavahemik?

Sa ei pea enne esimest vestlust tehnilist lähteülesannet valmis kirjutama. Piisab, kui saad kirjeldada praegust töövoogu ja soovitud tulemust: millised andmed liiguvad täna käsitsi, kui sageli, kes neid kasutab ja milline viga tekitaks ärile kõige suurema kahju.

Kasulikud on ka API dokumentatsiooni link, näidisandmed ning ligipääs testkeskkonnale. Nende põhjal saab eristada kiiret valmisühendust projektist, mis vajab eraldi kaardistust. Meie API integratsioonide teenuse juures alustame just andmevoost ja vastutusest, sest see annab hinnale tugevama aluse kui otspunktide arv.

Hea integratsioon ei ole see, mis töötab ainult demonstratsioonil. See peab jääma arusaadavaks ja taastatavaks ka siis, kui andmed on puudulikud, väline süsteem muutub või ühendus mõneks ajaks katkeb.