Օգտվելով SysExtension Framework-ի միջոցով պարզել, թե որ ենթադասի միջոցով է միանգամից դինամիկայում AX 2012

Հրապարակվել է՝ 16 փետրվարի, 2025 թ., 00:28:15 UTC
Վերջին թարմացումը՝ 12 հունվարի, 2026 թ., 08:43:39 UTC

Այս հոդվածը նկարագրում է, թե ինչպես օգտագործել Dynamics AX 2012 և Dynamics 365 for Operations-ի քիչ հայտնի SysExtension շրջանակը՝ ատրիբուտների զարդարանքների հիման վրա ենթադասեր ստեղծելու համար, ինչը թույլ է տալիս հեշտությամբ ընդարձակվող դիզայն ստեղծել մշակման դասի հիերարխիայի համար։

Այս էջը ավտոմատ կերպով թարգմանվել է անգլերենից՝ հնարավորինս շատ մարդկանց համար հասանելի դարձնելու համար: Ցավոք, մեքենայական թարգմանությունը դեռ կատարելագործված տեխնոլոգիա չէ, ուստի կարող են սխալներ առաջանալ: Եթե նախընտրում եք, կարող եք դիտել բնօրինակ անգլերեն տարբերակը այստեղ.

Using the SysExtension Framework to Find Out Which Subclass to Instantiate in Dynamics AX 2012

Այս գրառման մեջ տեղեկատվությունը հիմնված է Dynamics AX 2012 R3-ի վրա: Այն կարող է վավեր լինել կամ չլինել այլ տարբերակների համար: (Թարմացում. Ես կարող եմ հաստատել, որ այս հոդվածի տեղեկատվությունը վավեր է նաև Dynamics 365 for Operations-ի համար):

Dynamics AX-ում մշակման դասեր ներդնելիս հաճախ բախվում եք դասերի հիերարխիա ստեղծելու խնդրին, որտեղ յուրաքանչյուր ենթադասը համապատասխանում է համարակալման արժեքի կամ ունի որևէ այլ տվյալների կապակցում: Դասական դիզայնը սուպեր դասում կառուցվածքի մեթոդ ունենալն է, որն ունի անջատիչ, որը որոշում է, թե որ դասը պետք է ստեղծվի՝ հիմնվելով մուտքային տվյալների վրա:

Սա սկզբունքորեն լավ է աշխատում, բայց եթե դուք ունեք բազմաթիվ տարբեր հնարավոր մուտքային տվյալներ (թվարկման մեջ բազմաթիվ տարրեր կամ գուցե մուտքային տվյալները մի քանի տարբեր արժեքների համադրություն են), այն կարող է ձանձրալի և սխալների հակված լինել պահպանելու համար, և դիզայնը միշտ ունի այն թերությունը, որ դուք ստիպված կլինեք փոփոխել նշված կառուցման մեթոդը, եթե երբևէ ավելացնեք նոր ենթադաս կամ փոփոխություններ կատարեք, թե որ ենթադասը պետք է օգտագործվի՝ հիմնվելով որ մուտքային տվյալների վրա։

Բարեբախտաբար, կա դա անելու շատ ավելի էլեգանտ, բայց, ցավոք, նաև շատ ավելի քիչ հայտնի միջոց, մասնավորապես՝ SysExtension framework-ի միջոցով։

Այս շրջանակը օգտագործում է այն ատրիբուտները, որոնք կարող եք օգտագործել ձեր ենթադասերը՝ ձեր համակարգը ձևավորելու համար, որպեսզի կարողանա պարզել, թե որ ենթադասը պետք է օգտագործվի ինչի համար։ Ձեզ դեռևս անհրաժեշտ կլինի կառուցման մեթոդ, բայց եթե այն ճիշտ արվի, ապա նոր ենթադասեր ավելացնելիս երբեք անհրաժեշտ չի լինի այն փոփոխել։

Եկեք դիտարկենք մի երևակայական օրինակ և ենթադրենք, որ դուք պատրաստվում եք իրականացնել մի հիերարխիա, որը կատարում է որոշակի մշակում՝ հիմնվելով InventTrans աղյուսակի վրա: Կատարվող մշակումը կախված է գրառումների StatusReceipt-ից և StatusIssue-ից, ինչպես նաև նրանից, թե արդյոք գրառումները կապված են SalesLine-ի, PurchLine-ի հետ, թե ոչ մեկի հետ: Արդեն հիմա դուք դիտարկում եք բազմաթիվ տարբեր համադրություններ:

Ենթադրենք, որ դուք գիտեք, որ առայժմ ձեզ անհրաժեշտ է կարգավորել միայն մի քանի համադրություն, բայց նաև գիտեք, որ ժամանակի ընթացքում ձեզնից կպահանջվի կարողանալ կարգավորել ավելի ու ավելի շատ համադրություններ։

Եկեք այն համեմատաբար պարզ պահենք և ասենք, որ առայժմ դուք պետք է մշակեք միայն SalesLine-ին վերաբերող գրառումները, որոնք ունեն ReservPhysical կամ ReservOrdered StatusIssue, մնացած բոլոր համակցությունները կարելի է անտեսել առայժմ, բայց քանի որ գիտեք, որ դրանք հետագայում պետք է մշակեք, ապա պետք է ձեր կոդը նախագծեք այնպես, որ այն հեշտությամբ ընդարձակվի։

Ձեր հիերարխիան այժմ կարող է այսպիսի տեսք ունենալ.

ԻմՄշակողըԻմՄշակողը_ՎաճառքԻմՄշակողը_Վաճառք_ՌեսուրսՊատվիրվածԻմՄշակողը_Վաճառք_ՌեսուրսՖիզիկական

Այժմ, դուք կարող եք հեշտությամբ իրականացնել մեթոդ գերդասում, որը ստեղծում է ենթադաս՝ հիմնվելով ModuleInventPurchSales-ի և StatusIssue համարակալման վրա։ Սակայն այդ դեպքում դուք պետք է փոփոխեք գերդասը ամեն անգամ, երբ ավելացնում եք ենթադաս, և դա իրականում օբյեկտ-կողմնորոշված ծրագրավորման ժառանգման գաղափարը չէ։ Ի վերջո, դուք պետք չէ փոփոխեք RunBatch-ը կամ SysOperationServiceBase-ը ամեն անգամ, երբ ավելացնում եք նոր խմբաքանակային աշխատանք։

Դրա փոխարեն կարող եք օգտագործել SysExtension framework-ը։ Դա կպահանջի ձեզանից ավելացնել մեկ այլ դաս, որը պետք է ընդլայնի SysAttribute-ը։ Այս դասը կօգտագործվի որպես ատրիբուտ, որով կարող եք զարդարել ձեր մշակման դասերը։

Այս դասը շատ նման է SysOperation իրականացման համար տվյալների պայմանագրի դաս ստեղծելուն, քանի որ այն կունենա որոշ տվյալների անդամներ և parm մեթոդներ այդ արժեքները ստանալու և սահմանելու համար։

Մեր դեպքում, ClassDeclaration-ը կարող է այսպիսի տեսք ունենալ՝

class MyProcessorSystemAttribute extends SysAttribute
{
    ModuleInventPurchSales  module;
    StatusIssue             statusIssue;
    StatusReceipt           statusReceipt
}

Դուք պետք է ստեղծեք new() մեթոդ բոլոր տվյալների անդամների օրինակ ստեղծելու համար։ Եթե ցանկանում եք, կարող եք դրանցից մի քանիսին կամ բոլորին տալ լռելյայն արժեքներ, բայց ես դա չեմ արել։

public void new(ModuleInventPurchSales  _module,
                StatusIssue             _statusIssue,
                StatusReceipt           _statusReceipt)
{
    ;

    super();

    module          = _module;
    statusIssue     = _statusIssue;
    statusReceipt   = _statusReceipt;
}

Եվ դուք պետք է նաև իրականացնեք parm մեթոդ յուրաքանչյուր տվյալների անդամի համար, բայց ես դրանք այստեղ բաց եմ թողել, քանի որ վստահ եմ, որ դուք գիտեք, թե ինչպես դա անել, հակառակ դեպքում, եկեք դա համարենք վարժություն ;-)

Այժմ դուք կարող եք օգտագործել ձեր ատրիբուտների դասը՝ ձեր մշակման յուրաքանչյուր դասը զարդարելու համար։ Օրինակ, դասի հայտարարագրերը կարող են այսպիսի տեսք ունենալ՝

[MyProcessorSystemAttribute(ModuleInventPurchSales::Sales,
                            StatusIssue::None,
                            StatusReceipt::None)]
class MyProcessor_Sales extends MyProcessor
{
}

[MyProcessorSystemAttribute(ModuleInventPurchSales::Sales,
                            StatusIssue::ReservOrdered,
                            StatusReceipt::None)]
class MyProcessor_Sales_ReservOrdered extends MyProcessor_Sales
{
}

[MyProcessorSystemAttribute(ModuleInventPurchSales::Sales,
                            StatusIssue::ReservPhysical,
                            StatusReceipt::None)]
class MyProcessor_Sales_ReservPhysical extends MyProcessor_Sales
{
}

Իհարկե, կարող եք ձեր դասերը անվանել այնպես, ինչպես ցանկանում եք, կարևորն այն է, որ դրանք զարդարեք ատրիբուտներով, որոնք համապատասխանում են դրանց կատարած մշակման տեսակին: (Սակայն հիշեք, որ Dynamics AX-ում դասերի հիերարխիաների համար կան անվանակոչման կոնվենցիաներ, և միշտ լավ գաղափար է հետևել դրանց, եթե հնարավոր է):

Հիմա, երբ դուք ձևավորել եք ձեր դասերը՝ որոշելու համար, թե դրանցից յուրաքանչյուրը ինչպիսի մշակում է կատարում, կարող եք օգտագործել SysExtension framework-ը՝ անհրաժեշտության դեպքում ենթադասերի օբյեկտներ ստեղծելու համար։

Ձեր սուպեր դասում (MyProcessor) կարող եք ավելացնել այսպիսի կառուցվածքային մեթոդ՝

public static MyProcessor construct(ModuleInventPurchSales _module,
StatusIssue _statusIssue,
StatusReceipt _statusReceipt)
{
    MyProcessor                 ret;
    MyProcessorSystemAttribute  attribute;
    ;

    attribute = new MyProcessorSystemAttribute( _module,
                                                _statusIssue,
                                                _statusReceipt);

    ret = SysExtensionAppClassFactory::getClassFromSysAttribute(classStr(MyProcessor), attribute);

    if (!ret)
    {
        //  no class found
        //  here you could throw an error, instantiate a default
        //  processor instead, or just do nothing, up to you
    }

    return ret;
}

Այս ամբողջ գրառման իսկապես հետաքրքիր մասը՝ և իրականում օբյեկտը (ներողություն բառախաղի համար)՝ SysExtensionAppClassFactory դասում getClassFromSysAttribute() մեթոդն է։ Այս մեթոդը ընդունում է հիերարխիայի գերդասի անունը (և այս գերդասը պարտադիր չէ, որ լինի հիերարխիայի վերևում. դա պարզապես նշանակում է, որ միայն այս դասը ընդլայնող դասերը կլինեն իրավասու) և ատրիբուտային օբյեկտը։

Այնուհետև այն վերադարձնում է դասի օբյեկտ, որը ընդլայնում է նշված գերդասը և զարդարված է համապատասխան ատրիբուտով։

Ակնհայտ է, որ դուք կարող եք կառուցել մեթոդին ավելացնել այնքան լրացուցիչ վավերացում կամ տրամաբանություն, որքան ցանկանում եք, բայց կարևոր եզրակացությունն այն է, որ իրականացումից հետո դուք երբեք այլևս չպետք է ստիպված լինեք փոփոխել այս մեթոդը։ Դուք կարող եք ենթադասեր ավելացնել հիերարխիային, և քանի դեռ համոզվեք, որ դրանք համապատասխանաբար ձևավորված են, կառուցման մեթոդը կգտնի դրանք, նույնիսկ եթե դրանք գոյություն չեն ունեցել այն գրելու պահին։

Իսկ կատարողականության մասին ի՞նչ կասեք։ Անկեղծ ասած՝ չեմ փորձել համեմատել այն, բայց ներքին զգացողությունս այն է, որ սա, հավանաբար, ավելի վատ է աշխատում, քան դասական switch հրամանի դիզայնը։ Այնուամենայնիվ, հաշվի առնելով, որ Dynamics AX-ում կատարողականության հետ կապված խնդիրների մեծ մասը պայմանավորված է տվյալների բազայի մուտք գործելու հետ, ես այդքան էլ չէի անհանգստանա դրա համար։

Իհարկե, եթե դուք իրականացնում եք մի բան, որը կպահանջի հազարավոր օբյեկտների արագ ստեղծում, կարող եք ավելի մանրամասն ուսումնասիրել, բայց այն դասական դեպքերում, երբ դուք պարզապես ստեղծում եք մեկ օբյեկտ՝ որոշ երկարատև մշակում կատարելու համար, կասկածում եմ, որ դա նշանակություն կունենա: Բացի այդ, հաշվի առնելով իմ խնդիրների լուծման խորհուրդը (հաջորդ պարբերություն), թվում է, թե SysExtension շրջանակը հիմնված է քեշավորման վրա, ուստի աշխատող համակարգում կասկածում եմ, որ այն զգալի ազդեցություն կունենա արտադրողականության վրա:

Խնդիրների լուծում. Եթե կառուցման մեթոդը չի գտնում ձեր ենթադասերը՝ չնայած դուք վստահ եք, որ դրանք ճիշտ են զարդարված, դա կարող է քեշավորման խնդիր լինել: Փորձեք մաքրել քեշերը և՛ հաճախորդի, և՛ սերվերի վրա: AOS-ը վերագործարկելու անհրաժեշտություն չպետք է լինի, բայց դա կարող է լինել վերջին միջոցը:

Լրացուցիչ ընթերցանություն

Եթե ձեզ դուր եկավ այս գրառումը, ձեզ կարող են նաև դուր գալ այս առաջարկները.