Tinklaraštis
AL plėtiniai ir bazinės programos keitimas: saugus naujinimui pritaikymo būdas
Brangiausia NAV laikų klaida buvo tiesioginis bazinės programos redagavimas. Tuo metu tai atrodė efektyvu ir tyliai įkeisdavo ateitį. „Business Central” plėtinių modelis tai ištaiso — o supratimas, kodėl, yra skirtumas tarp sistemos, kuri sensta gražiai, ir tos, kuri tampa spąstais.
Kaip senasis būdas įkalino klientus
Klasikiniame NAV pritaikymas reiškė standartinio objekto atidarymą C/AL aplinkoje ir jo kodo keitimą vietoje. Jūsų logika ir „Microsoft” logika tapdavo vienu susipynusiu failu. Tai veikė, kol atkeliaudavo kita versija — ir tada kiekvienas pakeistas objektas turėjo būti rankiniu būdu sulietas su nauju „Microsoft” kodu, eilutė po eilutės, konfliktas po konflikto.
Kodėl tai svarbu: kuo daugiau pritaikydavote, tuo sunkesnis ir rizikingesnis tapdavo kiekvienas naujinimas. Daugelis organizacijų tiesiog nustojo atsinaujinti. Jos užšaldavo senoje versijoje, praleisdavo metų metus funkcijų ir pataisų, o galiausiai susidurdavo su gerokai didesne ir skausmingesne migracija nei tuo atveju, jei būtų likusios aktualios. Pritaikymas, sutaupęs savaitę pirmaisiais metais, penktaisiais kainuodavo ketvirtį.
Kaip AL plėtiniai jus apsaugo
„Business Central” neleidžia redaguoti bazinės programos. Vietoj to jūsų kodas gyvena atskirame plėtinyje, kuris yra šalia „Microsoft” kodo, niekada jo viduje. Laukus, puslapius ir logiką pridedate savo objektuose, o į standartinį elgesį įsijungiate per įvykių prenumeratorius (event subscribers), o ne jį perrašydami.
codeunit 50100 "Sales Header Subscriber"
{
[EventSubscriber(ObjectType::Table, Database::"Sales Header", OnAfterValidateEvent, "Sell-to Customer No.", false, false)]
local procedure OnAfterValidateSellToCustomer(var Rec: Record "Sales Header")
begin
Rec.Validate("Shortcut Dimension 1 Code", GetDefaultDepartment(Rec."Sell-to Customer No."));
end;
}
„Microsoft” paskelbia įvykį; jūs jį užprenumeruojate. Jūsų kodas suveikia tinkamu momentu nepaliesdamas nė vienos bazinio objekto eilutės. Kai „Microsoft” išleidžia naują to objekto versiją, jūsų prenumeratorius lieka nepaveiktas, nes niekada nebuvo įsiūtas.
Kodėl tai svarbu: riba tarp jūsų kodo ir „Microsoft” kodo dabar yra aiški ir matoma. Naujinimai nustoja būti suliejimo maratonais ir tampa tik jūsų plėtinio kompiliavimo bei elgesio su nauja baze patvirtinimu.
Ką tai reiškia du kartus per metus vykstantiems naujinimams
„Business Central” išleidžia du didelius naujinimus per metus, o SaaS aplinkoje jie atkeliauja automatiškai. Su baziniais pakeitimais toks ritmas būtų nevaldomas. Su plėtiniais tai įprasta rutina: išbandote savo programą su būsimu leidimu izoliuotoje aplinkoje (sandbox), pataisote tai, ką platforma nurodo, ir judate toliau.
Kodėl tai svarbu: liekate aktualūs pagal numatytuosius nustatymus, o ne herojiško projekto dėka. Naujos funkcijos ir saugos pataisos jus pasiekia nuolat, o atotrūkis tarp jūsų versijos ir naujausios niekada nespėja išaugti į migraciją.
Pirmiausia standartas, paskui pritaikymas
Plėtinių modelis skatina discipliną, kurią taikome kiekviename darbe: pirmiau ieškoti standartinės funkcijos, o tik tada rašyti kodą. Su kiekvienu leidimu „Business Central” perima vis daugiau to, kam anksčiau reikėjo pritaikymo — tvirtinimus, dokumentų siuntimą el. paštu, banko importus ir kt.
Kodėl tai svarbu: pigiausias plėtinys yra tas, kurio niekada neparašėte. Kiekvienas reikalavimas, įgyvendintas konfigūracija, o ne kodu, yra tai, ko nekuriate, netestuojate ir netempiate per būsimus naujinimus. Naujus darbus sąmoningai vertiname pirmiausia pagal standartinį funkcijų rinkinį.
Ilgalaikių kaštų vaizdas
Plėtiniai iš pradžių reikalauja šiek tiek daugiau disciplinos — projektuojate aplink įvykius ir paskelbtas sąsajas, o ne redaguojate, kas patogu. Nauda kaupiasi:
- Naujinimai tampa nuspėjami, mažos rizikos ir dažni
- Pritaikymai yra izoliuoti, testuojami ir lengvai perduodami
- Galite įdiegti naujas standartines funkcijas neišnarpliodami seno kodo
Kodėl tai svarbu: tikrieji sistemos kaštai yra ne tai, ką sumokate ją sukurdami, o tai, ką mokate gyvendami su ja dešimtmetį. Naujinimui saugus būdas išlaiko šią ilgąją uodegą mažą — o būtent ten dauguma ERP biudžetų tyliai prarandami arba sutaupomi.
Nešate senus pakeitimus arba planuojate naujus pritaikymus teisingai? Papasakokite savo istoriją ir parodysime, kaip sukurti tai saugiai naujinimui.