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. Tai techninis mūsų atnaujinimo kontrolinio sąrašo, apimančio visą projektą, papildymas.
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ų.
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.
Kelias eina per BC14
C/AL negalima konvertuoti tiesiai iš bet kurios NAV versijos. Atramos taškas yra „Business Central” 14 versija (2019 m. pavasaris), paskutinė platforma, kuri vienu metu vykdo C/AL ir supranta AL. Klasikinis kelias: perkelkite C/AL kodą iki BC14, eksportuokite objektus ir paleiskite „Microsoft” konverterį txt2al, kuris paverčia juos AL failais, o tada sutvarkykite viską, ko konverteris išreikšti negali.
Kiek ilgas kelias iki šio atramos taško, priklauso nuo starto vietos. Iš NAV 2017 ar 2018 tai trumpa kelionė. Iš NAV 2013 ar 2009 kodas ir duomenys pirmiausia šokinėja per tarpines versijas, ir kiekvienas šuolis turi savo kompiliavimą bei duomenų atnaujinimą. Būtent čia atsiperka įrankiai: daugiapakopis kelias rankomis yra lėtas ir klaidoms imlus, todėl sukūrėme savo konvertavimo ir atnaujinimo įrankius. Jie yra perkėlę sistemas net iš NAV 2009, įskaitant sprendimus su tūkstančiais objektų.
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. 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.
Patikimas į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. 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.
Tipiška modifikacija turi dvi puses. Logikos pusė tampa prenumeratoriumi. C/AL pakeitimas, kuris priskirdavo dimensiją pasikeitus klientui, konvertuojasi taip:
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;
}Duomenų pusė, laukai, kuriuos kažkas pridėjo prie standartinės lentelės, tampa lentelės plėtiniu (su puslapio plėtiniu jiems parodyti):
tableextension 50100 "Customer Ext" extends Customer
{
fields
{
field(50100; "External System Code"; Code[20])
{
Caption = 'Išorinės sistemos kodas';
DataClassification = CustomerContent;
}
}
}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.
Kas neturi SaaS atitikmens
Kai kurių C/AL konstrukcijų konvertuoti apskritai neįmanoma, ir jų radimas priklauso auditui, o ne kūrimo etapui.
Didžiausia — .NET sąsaja. C/AL galėjo kviesti bet kokias .NET bibliotekas; „Business Central” SaaS to neleidžia. Daugelis panaudojimų atitinka vietinius AL tipus, kuriuos platforma nuo to laiko įgijo (HttpClient žiniatinklio iškvietimams, JSON ir XML apdorojimas, reguliariosios išraiškos). Likusieji iškeliami iš BC visai, dažniausiai į „Azure Function”, kurią BC kviečia per HTTPS.
Tas pats galioja viskam, kas liečia serverio failų sistemą, valdo COM / Automation objektus (tą „Excel” automatizaciją, kurią kažkas parašė 2012-aisiais) arba tiesiogiai skaito SQL duomenų bazę. Nė vienas iš šių dalykų nėra kliūtis; visi jie yra perprojektavimo darbas, kurį geras auditas įkainoja iš anksto.
Kodo konvertavimas nėra duomenų atnaujinimas
Objektų konvertavimas ir duomenų atnaujinimas yra du atskiri darbų srautai, o pasiūlymuose jie kartais suplakami. Duomenų pusė perkelia jūsų lentelių turinį per visus schemos pokyčius tarp jūsų versijos ir tikslinės, įmonė po įmonės, o atnaujinimo kodo vienetai (upgrade codeunits) tvarko laukus, kurie pakeliui buvo pervadinti, išskaidyti ar pertvarkyti. Tai daugiausia mechaninis darbas, bet būtent jame sunaudojamas vykdymo laikas, ir būtent jį įrodo bandomoji migracija iš duomenų valymo sąrašo.
Įrankiai padeda, bet darbo neatlieka
Konvertavimo įrankiai, įskaitant mūsų, inventorizuoja objektus, pažymi modifikuotus, konvertuoja mechanines dalis ir sukuria plėtinio struktūros karkasą. Ko joks įrankis negali, tai 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”.
Į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.
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 konvertavimo skaičiaus, kurį galėtumėte įtraukti į biudžetą? Papasakokite savo istoriją ir atliksime objektų auditą.