Tinklaraštis
Nuo C/AL prie AL: ką iš tikrųjų apima konvertavimas
Kai žmonės įsivaizduoja NAV į „Business Central” atnaujinimą, jie galvoja apie duomenų perkėlimą. Duomenys svarbūs, bet techninis projekto branduolys yra visai kas kita: jūsų pritaikymų konvertavimas iš C/AL į AL. Suprasti, ką tai apima, yra skirtumas tarp realistiško biudžeto ir nemalonios staigmenos.
C/AL ir AL yra du skirtingi pasauliai
C/AL buvo klasikinio NAV kalba. Kodas gyveno bazinės programos viduje — atverdavote standartinį objektą ir tiesiogiai jį redaguodavote. Būtent ši galia ir yra priežastis, kodėl senas NAV sistemas taip sunku atnaujinti: jūsų logika ir „Microsoft” logika buvo susipynusios tuose pačiuose objektuose.
AL yra moderni „Business Central” kalba ir ji veikia visiškai kitu principu. Jūsų kodas gyvena plėtiniuose — atskiruose paketuose, kurie stovi greta standartinės programos ir prisikabina prie jos per įvykius, niekada nemodifikuodami „Microsoft” objektų.
Kodėl tai svarbu: kai jūsų pritaikymai tampa švariais plėtiniais, „Microsoft” du kartus per metus vykdomi naujinimai nustoja būti projektu. Bazinė programa atsinaujina po jumis, o jūsų kodas toliau veikia viršuje. Būtent dėl to konvertavimą verta atlikti.
Kodėl modifikuoti baziniai objektai yra brangiausia kategorija
Suskirstykite savo pritaikymus į tris grupes: nepaliesti standartiniai, visiškai individualūs ir modifikuoti standartiniai. Pirmoji grupė nemokama, antroji persikelia gana mechaniškai — bet trečioji, modifikuoti baziniai objektai, yra ten, kur slypi tikrasis darbas.
Kiekvienas pakeitimas, kurį kažkas kažkada padarė tiesiai standartinio objekto viduje, dabar turi būti iškeltas ir pakartotinai išreikštas kaip plėtinys. Automatinio atitikmens nėra, nes visa AL esmė yra ta, kad tų objektų nebegalite redaguoti vietoje.
Kodėl tai svarbu: sąžiningas įvertinimas skaičiuoja modifikuotus bazinius objektus, o ne kodo eilutes. Dvi sistemos su tuo pačiu pritaikymų skaičiumi gali smarkiai skirtis kaina, priklausomai nuo to, kaip giliai tie pritaikymai įsiskverbė į standartinę programą.
Trys baigtys kiekvienai modifikacijai
Peržiūrint modifikacijas po vieną, kiekviena atsiduria vienoje iš trijų vietų:
- Pakartotinai išreiškiama kaip įvykio prenumeratorius (event subscriber). Dauguma logikos, kuri reagavo į standartinį veiksmą — patikrindavo lauką, priskirdavo numatytąją reikšmę — konvertuojama į prenumeratorių, kuris klauso atitinkamo įvykio.
- Atstatoma kaip individualus plėtinio objektas. Tikrai unikali funkcija atstatoma kaip nauji lentelės, puslapiai ir kodo vienetai jūsų pačių plėtinyje.
- Visiškai atsisakoma. Jei „Business Central” dabar pristato funkciją kaip standartinę — patvirtinimų darbo eigas, dokumentų siuntimą el. paštu, banko suderinimo importą — pritaikymo atsisakoma, o ne konvertuojama.
Štai kaip atrodo tipiškas konvertavimas. C/AL pakeitimas, kuris priskirdavo dimensiją pasikeitus klientui, tampa prenumeratoriumi:
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;
}Kodėl tai svarbu: trečioji baigtis yra vertingiausia. Kiekvienas pritaikymas, kurio atsisakote, sutaupomas du kartus — kartą konvertuojant ir dar kartą kiekvieną būsimą priežiūros bei atnaujinimo valandą, už kurią nebemokate.
Įrankiai padeda, bet darbo neatlieka
Konvertavimo įrankiai egzistuoja ir yra tikrai naudingi: jie inventorizuoja objektus, pažymi modifikuotus ir sukuria plėtinio struktūros karkasą. Bet jie negali nuspręsti, ar konkrečią modifikaciją reikėtų pakartotinai išreikšti, atstatyti ar jos atsisakyti — tam sprendimui reikia žmogaus, suprantančio ir pirminį verslo tikslą, ir dabartinį „Business Central”.
Kodėl tai svarbu: įtariai vertinkite bet kokį pasiūlymą, kuriame teigiama, kad įrankis konvertuoja automatiškai. Įrankis pagreitina mechanines dalis; sprendimai yra žmonių, o sprendimuose laimima arba prarandama kokybė.
Testavimas nėra pasirinktinis
Kadangi kiekviena modifikacija perrašoma, o ne nukopijuojama, turite įrodyti, kad naujas AL elgiasi taip pat kaip senas C/AL. Tai reiškia kiekvieno konvertuoto proceso — registravimo rutinų, individualių ataskaitų, integracijų — testavimą lyginant su žinomais gyvos NAV sistemos rezultatais.
Kodėl tai svarbu: konvertavimas yra rizikingiausia atnaujinimo dalis būtent todėl, kad kodas keičia formą. Drausmingas testavimas lyginant su senąja sistema yra tai, kas tą riziką prieš paleidimą paverčia pasitikėjimu.
Laukia NAV į „Business Central” atnaujinimas ir norite sužinoti, kiek iš tikrųjų kainuos konvertuoti jūsų pritaikymus? Papasakokite savo istoriją ir atliksime objektų auditą bei pateiksime sąžiningą, nemokamą įvertinimą.