Tinklaraštis
Integruojame „Business Central": API, webhooks ir Azure Functions
Beveik kiekvienam „Business Central” projektui galiausiai reikia susikalbėti su kažkuo kitu — internetine parduotuve, dokumentų pasirašymo paslauga, duomenų ežeru, sandėlio sistema. Gera žinia ta, kad BC turi brandų integracijų įrankių rinkinį; rizika — pasirinkti netinkamą įrankį ir likti su trapiu sprendimu, kuris sugriūva per kitą naujinimą. Štai kaip mes mąstome apie šias galimybes ir kokia patirtimi grįstas tas mąstymas.
Įmontuoti REST ir OData v4 API
„Business Central” pateikia didelį rinkinį standartinių REST API (klientai, prekės, pardavimo užsakymai, žurnalai ir kt.) bei OData v4 galines stotis virš publikuotų puslapių ir užklausų. Daugumai skaitymo ir rašymo scenarijų su standartinėmis esybėmis nieko kurti nereikia — galinė stotis jau egzistuoja.
Kodėl tai svarbu: kiekviena esybė, kurią galite naudoti iškart, yra integracija, kurios nereikia kurti, testuoti ar prižiūrėti per būsimus naujinimus. Visada patikrinkite standartinį API paviršių prieš rašydami specialų kodą.
Specialūs API puslapiai
Kai standartiniai API neapima jūsų duomenų — specialios lentelės, pritaikytos projekcijos, konkretaus laukų rinkinio — AL kalba sukuriate savo API puslapį (arba API užklausą). Taip gaunate švarią, versijuotą, su OData suderinamą galinę stotį, kurią BC laiko pilnaverte.
Kodėl tai svarbu: tikslui sukurtas API puslapis yra kur kas stabilesnis nei UI puslapio nuskaitymas ar bendrinės galinės stoties piktnaudžiavimas. Jis išgyvena naujinimus, nes tai jūsų aiškiai apibrėžta sutartis.
Webhooks tiesioginiams pranešimams
API apklausa pagal laikmatį yra neefektyvi ir lėta. Webhooks leidžia BC nusiųsti pranešimą į jūsų galinę stotį tą akimirką, kai įrašas pasikeičia, todėl jūsų tarpinė programinė įranga reaguoja beveik realiu laiku, o ne kas kelias minutes klausia „ar yra kas naujo?”.
Kodėl tai svarbu: stūmimas nugali apklausą ir kainos, ir reagavimo greičio prasme. Užsakymų patvirtinimai, atsargų pokyčiai ir būsenos atnaujinimai pasiekia kitą sistemą greitai, neapkraunant API.
Azure Functions sunkiajam darbui
AL puikiai veikia „Business Central” viduje, tačiau tai nėra vieta sudėtingoms transformacijoms, trečiųjų šalių SDK iškvietimams ar daugiapakopių srautų orkestravimui vykdyti. Tas darbas priklauso tarpinei programinei įrangai — ir Azure Functions yra mūsų numatytoji vieta jam. BC sukelia įvykį arba kreipiasi išorėn; Function atlieka atvaizdavimą, kartojimus, paketavimą ir išorinius iškvietimus; rezultatai grįžta per API.
Būtent tokį modelį esame įdiegę su SharePoint ir Google Drive (dokumentų saugykla), AWS (debesijos paslaugos), Scrive (skaitmeninis pasirašymas) ir specialiomis Azure Functions tarpinėmis sistemomis. Pasikartojanti pamoka: laikykite BC ploną, o painią integracijos logiką iškelkite ten, kur ją galima nepriklausomai testuoti, skalti ir stebėti.
Kodėl tai svarbu: atsakomybių atskyrimas išlaiko jūsų BC plėtinį mažą ir saugų naujinimams, o sunki ar kintanti logika gyvena ten, kur ją galite diegti ir taisyti neliečiant ERP.
Jungtys: Power Platform, Shopify ir kitos
Įprastiems scenarijams yra parengtos jungtys — Power Platform jungtis (Power Automate, Power Apps), Shopify jungtis ir kitos. Tai be kodo arba su mažai kodo keliai, kurie gali duoti naudą per dienas, o ne savaites.
Kodėl tai svarbu: jei palaikoma jungtis atitinka jūsų poreikį, ji beveik visada yra pigesnė ir ilgaamžiškesnė nei specialus kodas. Specialaus sprendimo griebkitės tik tada, kai jungtis tikrai negali atlikti darbo.
Autentifikacija: OAuth per Microsoft Entra
Pagrindinė (basic) autentifikacija nebenaudojama. Šiuolaikinės BC integracijos autentifikuojasi per Microsoft Entra (OAuth 2.0) — registruotos programos, apribotos teisės ir prieiga pagal žetonus. Paslaugos su paslauga iškvietimai naudoja kliento kredencialus; interaktyvūs scenarijai — deleguotas teises.
Kodėl tai svarbu: Entra suteikia atšaukiamą, audituojamą, mažiausių privilegijų prieigą be bendrinamų slaptažodžių konfigūracijos failuose. Tai saugiau ir kur kas lengviau valdyti.
Išlaikykite saugumą naujinimams ir atsparumą
Kad ir ką kurtumėte, galioja du principai. Saugu naujinimams: naudokite įvykius ir plėtinius, niekada nemodifikuokite standartinių objektų ir remkitės dokumentuotais API, o ne vidine elgsena. Atsparu: laikykite, kad tinklas ir kita sistema suges — įdiekite kartojimus, idempotenciją ir žurnalavimą, kad laikinas sutrikimas nesugadintų duomenų ir neprarastų pranešimų.
Kodėl tai svarbu: integracijos yra ten, kur kyla dauguma incidentų po paleidimo. Projektavimas su sutrikimų prielaida iš anksto yra skirtumas tarp tylios integracijos ir skambučio trečią valandą nakties.
Reikia sujungti „Business Central” su kita sistema — ir norite, kad tai būtų padaryta taip, jog išgyventų kitą naujinimą? Papasakokite savo istoriją ir rekomenduosime paprastiausią bei ilgaamžiškiausią sprendimą jūsų atvejui.