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 yra pasirinkti netinkamą įrankį ir likti su trapiu sprendimu, kuris sugriūva per kitą naujinimą. Taip mes mąstome apie šias galimybes, ir tokia 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.
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.
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?”. 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. 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. 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 naudoja deleguotas teises. Entra suteikia atšaukiamą, audituojamą, mažiausių privilegijų prieigą be bendrinamų slaptažodžių konfigūracijos failuose.
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, ir įdiekite kartojimus, idempotenciją ir žurnalavimą, kad laikinas sutrikimas nesugadintų duomenų ir neprarastų pranešimų.
Integracijos yra ten, kur kyla dauguma incidentų po paleidimo. Projektavimas su sutrikimų prielaida iš anksto skiria integraciją, kurią pamirštate, nuo tos, kuri kas mėnesį kelia ką nors iš lovos.
Reikia sujungti „Business Central” su kita sistema taip, kad sprendimas išgyventų kitą naujinimą? Papasakokite savo istoriją ir rekomenduosime paprastiausią bei ilgaamžiškiausią sprendimą jūsų atvejui.