SysExtension Framework-un istifadə edərək Dynamics AX 2012-də Hansı Subklass-ın aniləşdirmək lazım olduğunu öyrənin

Nəşr olundu: 16 fevral 2025 at 00:29:32 UTC
Son yeniləmə: 12 yanvar 2026 at 08:43:49 UTC

Bu məqalədə, Dynamics AX 2012 və Dynamics 365 for Operations-da az tanınan SysExtension çərçivəsinin atribut bəzəklərinə əsaslanan alt sinifləri necə yaratmaq və emal sinfi iyerarxiyasının asanlıqla genişləndirilə bilən dizaynını təmin etmək üçün necə istifadə ediləcəyi təsvir olunur.

Bu səhifə mümkün qədər çox insan üçün əlçatan olması üçün ingilis dilindən maşın tərcümə edilib. Təəssüf ki, maşın tərcüməsi hələ mükəmməl texnologiya deyil, ona görə də səhvlər baş verə bilər. İstəyirsinizsə, orijinal ingilis versiyasına buradan baxa bilərsiniz:

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

Bu yazıdakı məlumat Dynamics AX 2012 R3-ə əsaslanır. Digər versiyalar üçün keçərli ola bilər və ya olmaya bilər. (Yeniləmə: Bu məqalədəki məlumatın Dynamics 365 for Operations üçün də keçərli olduğunu təsdiqləyə bilərəm)

Dynamics AX-da emal siniflərini tətbiq edərkən, tez-tez hər bir alt sinifin enum dəyərinə uyğun olduğu və ya başqa bir məlumat bağlantısına malik olduğu bir sinif iyerarxiyası yaratmaqla qarşılaşırsınız. Klassik bir dizayn, girişə əsasən hansı sinfi yaratmağı müəyyən edən bir açara malik super sinifdə bir konstruksiya metoduna sahib olmaqdır.

Bu, prinsipcə yaxşı işləyir, amma bir çox fərqli mümkün girişiniz varsa (enumda bir çox element və ya giriş bir neçə fərqli dəyərin kombinasiyasıdır), bu, yorucu və səhvə meylli ola bilər və dizaynın həmişə mənfi cəhəti var ki, yeni bir alt sinif əlavə etsəniz və ya hansı girişə əsasən hansı alt sinifin istifadə olunacağına dəyişiklik etsəniz, sözügedən konstruksiya metodunu dəyişdirməli olacaqsınız.

Xoşbəxtlikdən, bunu etməyin daha zərif, lakin təəssüf ki, daha az tanınan bir yolu var, yəni SysExtension çərçivəsindən istifadə etməklə.

Bu çərçivə, sistemin hansı alt sinifdən nəyi idarə etmək üçün istifadə olunacağını müəyyən edə bilməsi üçün alt siniflərinizi bəzəmək üçün istifadə edə biləcəyiniz atributlardan faydalanır. Sizə hələ də konstruksiya metodu lazım olacaq, lakin düzgün şəkildə edilərsə, yeni alt siniflər əlavə edərkən onu heç vaxt dəyişdirmək lazım olmayacaq.

Gəlin xəyali bir nümunəyə baxaq və deyək ki, InventTrans cədvəlinə əsaslanaraq bir növ emal edən bir iyerarxiya tətbiq edəcəksiniz. Hansı emalın ediləcəyi qeydlərin StatusReceipt və StatusIssue-dan, eləcə də qeydlərin SalesLine, PurchLine ilə əlaqəli olub-olmamasından asılıdır. Artıq bir çox fərqli kombinasiyaya baxırsınız.

Tutaq ki, hələlik yalnız bir neçə kombinasiyanı idarə etməyiniz lazım olduğunu bilirsiniz, eyni zamanda zamanla daha çox kombinasiyanı idarə edə bilməyinizin istənəcəyini də bilirsiniz.

Gəlin bunu nisbətən sadələşdirək və deyək ki, hələlik yalnız SalesLine ilə əlaqəli ReservPhysical və ya ReservOrdered StatusIssue ilə əlaqəli qeydləri idarə etməlisiniz, digər bütün kombinasiyalar hələlik nəzərə alınmaya bilər, ancaq onları daha sonra idarə etməli olduğunuzu bildiyiniz üçün kodunuzu asanlıqla genişləndirilə bilən şəkildə dizayn etməlisiniz.

İndi iyerarxiyanız belə görünə bilər:

MənimProsessorumMənimProsessorum_SatışlarıMənimProsessorum_Satış_RezervSifariş edilmişMənimProsessorum_Satış_RezervFiziki

İndi super sinifdə ModuleInventPurchSales və StatusIssue enum əsasında alt sinif yaradan bir metodu asanlıqla tətbiq edə bilərsiniz. Lakin hər dəfə alt sinif əlavə etdikdə super sinfi dəyişdirməli olacaqsınız və bu, obyekt yönümlü proqramlaşdırmada varislik ideyası deyil. Axı, hər dəfə yeni bir toplu iş əlavə etdikdə RunBaseBatch və ya SysOperationServiceBase-i dəyişdirməyə ehtiyac yoxdur.

Bunun əvəzinə, SysExtension çərçivəsindən istifadə edə bilərsiniz. Bu, SysAttribute-u genişləndirməli olan başqa bir sinif əlavə etməyinizi tələb edəcək. Bu sinif, emal siniflərinizi bəzəyə biləcəyiniz atribut kimi istifadə olunacaq.

Bu sinif, SysOperation tətbiqi üçün məlumat müqaviləsi sinfi yaratmağınıza çox bənzəyir, çünki bu sinifdə bəzi məlumat üzvləri və bu dəyərləri əldə etmək və təyin etmək üçün parm metodları olacaq.

Bizim vəziyyətimizdə, ClassBəyannaməsi belə görünə bilər:

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

Bütün məlumat üzvlərini instantiasiya etmək üçün new() metodu yaratmalısınız. İstəsəniz, onların bəzilərini və ya hamısını standart dəyərlər olaraq verə bilərsiniz, amma mən bunu etməmişəm.

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

    super();

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

Həmçinin hər bir məlumat üzvü üçün parm metodu tətbiq etməlisiniz, amma əminəm ki, bunu necə edəcəyinizi bilirsiniz, çünki mən bunları burada buraxdım - əks halda, gəlin bunu bir məşq hesab edək ;-)

İndi hər bir emal sinifinizi bəzəmək üçün atribut sinifinizdən istifadə edə bilərsiniz. Məsələn, sinif bəyannamələri belə görünə bilər:

[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
{
}

Əlbəttə ki, siniflərinizə istədiyiniz kimi ad verə bilərsiniz, burada vacib olan odur ki, siniflərinizi onların hansı növ emal etdiyinə uyğun atributlarla bəzəyəsiniz. (Amma unutmayın ki, Dynamics AX-da sinif iyerarxiyaları üçün adlandırma konvensiyaları mövcuddur və mümkün olduqda onlara əməl etmək həmişə yaxşı fikirdir).

Artıq siniflərinizin hər birinin hansı növ emal etdiyini müəyyən etmək üçün bəzədiyinizə görə, lazım olduqda alt siniflərin obyektlərini yaratmaq üçün SysExtension çərçivəsindən istifadə edə bilərsiniz.

Super sinifinizdə (MyProcessor) bu kimi bir konstruksiya metodu əlavə edə bilərsiniz:

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;
}

Ən maraqlı hissəsi - və bütün bu yazının obyekti (söz oyunu üçün üzr istəyirəm) - SysExtensionAppClassFactory sinifindəki getClassFromSysAttribute() metodudur. Bu metodun funksiyası iyerarxiyanın super sinfinin adını (və bu super sinfin iyerarxiyanın başında olmasına ehtiyac yoxdur; bu, sadəcə olaraq yalnız bu sinfi genişləndirən siniflərin uyğun olacağı deməkdir) və atribut obyektini qəbul etməsidir.

Daha sonra göstərilən super sinfi genişləndirən və müvafiq atributla bəzədilmiş bir sinfin obyektini qaytarır.

Əlbəttə ki, konstruksiya metoduna istədiyiniz qədər əlavə validasiya və ya məntiq əlavə edə bilərsiniz, amma burada əsas məqam odur ki, tətbiq edildikdən sonra bu metodu bir daha dəyişdirməyə ehtiyac yoxdur. İyerarxiyaya alt siniflər əlavə edə bilərsiniz və onları düzgün şəkildə bəzədiyiniz müddətcə, konstruksiya metodu yazıldığı zaman mövcud olmasalar belə, onları tapacaq.

Bəs performans necədir? Düzünü desəm, onu müqayisə etməyə çalışmamışam, amma daxili hisslərim budur ki, bu, klassik keçid operatoru dizaynından daha pis işləyir. Bununla belə, Dynamics AX-da əksər performans problemlərinin verilənlər bazasına girişdən qaynaqlandığını nəzərə alsaq, bu barədə çox da narahat olmazdım.

Əlbəttə ki, minlərlə obyektin tez bir zamanda yaradılmasını tələb edən bir şey tətbiq edirsinizsə, daha ətraflı araşdırmaq istəyə bilərsiniz, amma uzun bir emal üçün sadəcə tək bir obyekt yaratdığınız klassik hallarda bunun əhəmiyyəti olacağına şübhə edirəm. Həmçinin, problemlərin aradan qaldırılması ilə bağlı məsləhətimi (növbəti abzas) nəzərə alsaq, SysExtension çərçivəsinin keşləmədən asılı olduğu görünür, buna görə də işləyən bir sistemdə onun əhəmiyyətli bir performans itkisinə səbəb olduğuna şübhə edirəm.

Problemlərin həlli: Əgər düzgün şəkildə bəzədildiyinə əmin olsanız belə, konstruksiya metodu alt siniflərinizi tapmırsa, bu, keşləmə problemi ola bilər. Həm klientdə, həm də serverdə keşləri təmizləməyə çalışın. AOS-u yenidən başlatmaq lazım olmamalıdır, amma bu, son çarə ola bilər.

Əlavə Oxu

Bu yazı xoşunuza gəldisə, bu təklifləri də bəyənə bilərsiniz: