Dynamics AX 2012 တွင် Instantiate လုပ်ရန် မည်သည့် Subclass ကိုရှာဖွေရန် SysExtension Framework ကိုအသုံးပြုခြင်း

ထုတ်ဝေသည်- ၂၀၂၅၊ ဖေဖော်ဝါရီ ၁၆ UTC ၀၀:၃၀:၁၁

ဤဆောင်းပါးတွင် လူသိနည်းသော SysExtension framework ကို Dynamics AX 2012 နှင့် Dynamics 365 တွင် Operations အတွက် အသုံးပြုရပုံကို ဖော်ပြထားပြီး၊ စီမံဆောင်ရွက်ဆဲ အတန်း၏ အထက်အောက် ဒီဇိုင်းကို လွယ်ကူစွာ ချဲ့ထွင်နိုင်စေမည့် အရည်အချင်းဆိုင်ရာ အလှဆင်မှုများအပေါ် အခြေခံ၍ အတန်းခွဲခွဲများကို ချက်ခြင်းပြုလုပ်ရန် ဖော်ပြထားပါသည်။

ဤစာမျက်နှာကို လူများတတ်နိုင်သမျှ ဝင်ရောက်ကြည့်ရှုနိုင်စေရန်အတွက် ဤစာမျက်နှာကို အင်္ဂလိပ်မှ စက်ဖြင့် ဘာသာပြန်ထားခြင်းဖြစ်ပါသည်။ ကံမကောင်းစွာဖြင့်၊ စက်ဘာသာပြန်ခြင်းသည် ပြီးပြည့်စုံသောနည်းပညာမဟုတ်သေးသောကြောင့် အမှားအယွင်းများဖြစ်ပေါ်လာနိုင်သည်။ သင်နှစ်သက်ပါက မူရင်းအင်္ဂလိပ်ဗားရှင်းကို ဤနေရာတွင် ကြည့်ရှုနိုင်ပါသည်။

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 တွင် စီမံဆောင်ရွက်ပေးသည့် အတန်းများကို အကောင်အထည်ဖော်သည့်အခါ၊ အတန်းခွဲတစ်ခုစီသည် enum တန်ဖိုးတစ်ခုနှင့် သက်ဆိုင်သည့် သို့မဟုတ် အခြားဒေတာချိတ်ဆက်မှုအချို့ပါရှိသည့် အတန်း၏ အထက်တန်းအဆင့်ကို ဖန်တီးခြင်းနှင့် ကြုံတွေ့ရတတ်သည်။ ဂန္တဝင်ဒီဇိုင်းတစ်ခုသည် စူပါအတန်းတွင် တည်ဆောက်ရေးနည်းလမ်းတစ်ခုရှိရန်ဖြစ်ပြီး၊ ၎င်းတွင် ထည့်သွင်းမှုအပေါ်အခြေခံ၍ မည်သည့်အတန်းကို ချက်ချင်းလုပ်ဆောင်ရမည်ကို ဆုံးဖြတ်သည့်ခလုတ်တစ်ခုပါရှိသည်။

၎င်းသည် နိယာမအရ ကောင်းမွန်စွာ အလုပ်လုပ်သော်လည်း သင့်တွင် မတူညီသော ဖြစ်နိုင်သော သွင်းအားစုများ (enum တွင် များစွာသော ဒြပ်စင်များ သို့မဟုတ် ထည့်သွင်းမှုသည် မတူညီသော တန်ဖိုးများစွာ၏ ပေါင်းစပ်မှုဖြစ်နိုင်သည်)၊ ၎င်းသည် ထိန်းသိမ်းရန် ပျင်းရိပြီး အမှားအယွင်းဖြစ်နိုင်ကာ ဒီဇိုင်းသည် သင် subclass အသစ်တစ်ခုထပ်ထည့်ပါက သို့မဟုတ် မည်သည့် subclass ကိုအသုံးပြုသင့်သည်ဆိုသည်ကို အပြောင်းအလဲပြုလုပ်ပါက ဒီဇိုင်းသည် အမြဲတမ်း အားနည်းချက်ရှိနေပါသည်။

ကံကောင်းထောက်မစွာ၊ ပိုမိုပြေပြစ်သောနည်းလမ်းတစ်ခုရှိသော်လည်း၊ SysExtension မူဘောင်ကိုအသုံးပြုခြင်းဖြင့်၊ ဤအရာကိုလုပ်ဆောင်ရန် လူသိနည်းသောနည်းလမ်းလည်းရှိသည်။

ဤ framework သည် သင့် sub class များကို အလှဆင်ရန်အတွက် သင်အသုံးပြုနိုင်သည့် attribute များ၏ အားသာချက်များကို အသုံးပြု၍ system မှ sub class များကို ကိုင်တွယ်ရန်အတွက် မည်သည့် class ကို အသုံးပြုသင့်သည်ကို တွက်ချက်နိုင်စေပါသည်။ သင်တည်ဆောက်ပုံနည်းလမ်းတစ်ခု လိုအပ်နေသေးသော်လည်း မှန်ကန်စွာလုပ်ဆောင်ပါက၊ အတန်းခွဲအသစ်များထည့်သည့်အခါ ၎င်းကို ပြုပြင်ပြောင်းလဲရန် မလိုအပ်ပါ။

စိတ်ကူးယဉ်နမူနာကိုကြည့်ရအောင်၊ InventTrans ဇယားကိုအခြေခံ၍ လုပ်ငန်းစဉ်အချို့လုပ်ဆောင်သည့် အထက်တန်းအဆင့်တစ်ခုကို သင်အကောင်အထည်ဖော်တော့မည်ဟု ဆိုကြပါစို့။ လုပ်ဆောင်ရမည့်အရာသည် မှတ်တမ်းများ၏ StatusReceipt နှင့် StatusIssue ပေါ်တွင်မူတည်သည့်အပြင် မှတ်တမ်းများသည် SalesLine၊ PurchLine နှင့် ဆက်စပ်မှုရှိမရှိအပေါ်လည်း မူတည်ပါသည်။ ယခုပင်၊ သင်သည် မတူညီသော ပေါင်းစပ်မှုများကို ကြည့်နေသည်။

ပေါင်းစပ်မှုများကို ယခုအချိန်တွင် လက်တစ်ဆုပ်စာသာ ကိုင်တွယ်ရန် လိုအပ်ကြောင်း သင်သိကြောင်း ဆိုကြပါစို့၊ သို့သော် အချိန်ကြာလာသည်နှင့်အမျှ ပေါင်းစပ်မှုများကို ပိုမိုလုပ်ဆောင်နိုင်စေရန် သင့်အား တောင်းဆိုလာမည်ဖြစ်ကြောင်းကိုလည်း သင်သိပါသည်။

အတော်လေးရိုးရှင်းပြီး အခုလောလောဆယ်မှာ ReservPhysical သို့မဟုတ် ReservOrdered ရဲ့ StatusIssue Issue နဲ့ SalesLine နဲ့ပတ်သက်တဲ့ မှတ်တမ်းတွေကိုသာ ကိုင်တွယ်ဖို့ လိုအပ်ပါတယ်၊ တခြားပေါင်းစပ်မှုအားလုံးကို အခုလောလောဆယ် လျစ်လျူရှုထားနိုင်ပေမယ့် နောက်ပိုင်းမှာ အဲဒါတွေကို ကိုင်တွယ်ရမယ်ဆိုတာ သင်သိတဲ့အတွက်ကြောင့်၊ သင့်ကုဒ်ကို အလွယ်တကူ ထပ်တိုးနိုင်စေမယ့် ပုံစံနဲ့ ဒီဇိုင်းထုတ်ချင်ပါတယ်။

သင်၏ အထက်တန်းအဆင့်သည် ယခုအချိန်တွင် ဤကဲ့သို့သောပုံပေါ်နိုင်သည်-

MyProcessor
- MyProcessor_Sales
  - MyProcessor_Sales_ReservOrdered
  - MyProcessor_Sales_ReservPhysical

ယခု၊ သင်သည် ModuleInventPurchSales နှင့် StatusIssue enum ကိုအခြေခံ၍ အတန်းခွဲတစ်ခုအား လှုံ့ဆော်ပေးသည့် super class တွင် နည်းလမ်းတစ်ခုကို အလွယ်တကူ အကောင်အထည်ဖော်နိုင်မည်ဖြစ်သည်။ ဒါပေမယ့် sub class တစ်ခုထပ်ထည့်တိုင်း super class ကို ပြင်ဆင်ဖို့ လိုအပ်မှာဖြစ်ပြီး အဲဒါက object-oriented programming မှာ အမွေဆက်ခံခြင်းရဲ့ စိတ်ကူးမဟုတ်ပါဘူး။ နောက်ဆုံးအနေနဲ့၊ သင် batch အလုပ်အသစ်တစ်ခုထည့်တိုင်း RunBaseBatch သို့မဟုတ် SysOperationServiceBase ကို ပြင်ဆင်ရန် မလိုအပ်ပါ။

ယင်းအစား၊ သင်သည် SysExtension မူဘောင်ကို အသုံးပြုနိုင်သည်။ ၎င်းသည် သင့်အား SysAttribute ကို တိုးချဲ့ရန် လိုအပ်သည့် အခြား class ကို ထပ်ထည့်ရန် လိုအပ်မည်ဖြစ်သည်။ ဤအတန်းကို သင်လုပ်ဆောင်နေသော အတန်းများကို သင်အလှဆင်နိုင်သည့် အရည်အချင်းအဖြစ် အသုံးပြုပါမည်။

ဤအတန်းသည် SysOperation အကောင်အထည်ဖော်မှုအတွက် ဒေတာကန်ထရိုက်အတန်းတစ်ခုပြုလုပ်ပုံနှင့် အလွန်ဆင်တူသည်၊ ၎င်းတွင် ၎င်းတန်ဖိုးများကိုရယူရန်နှင့် သတ်မှတ်ရန်အတွက် အချို့သောဒေတာအဖွဲ့ဝင်များနှင့် parm နည်းလမ်းများပါရှိသည်။

ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ClassDeclaration သည် ဤကဲ့သို့သောပုံပေါ်နိုင်သည်-

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

ဒေတာအဖွဲ့ဝင်အားလုံးကို ချက်ခြင်းဖြစ်စေရန်အတွက် သင်အသစ်() နည်းလမ်းတစ်ခု ပြုလုပ်ရန် လိုအပ်ပါသည်။ သင်ဆန္ဒရှိလျှင် ၎င်းတို့အချို့ သို့မဟုတ် အားလုံးကို ပုံသေတန်ဖိုးများ ပေးဆောင်နိုင်သော်လည်း ၎င်းကို ကျွန်ုပ်မလုပ်ပါ။

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

    super();

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

ဒေတာအဖွဲ့ဝင်တစ်ဦးစီအတွက် parm နည်းလမ်းကိုလည်း အကောင်အထည်ဖော်သင့်ပါတယ်၊ ဒါပေမယ့် အဲဒါကို ဘယ်လိုလုပ်ရမလဲဆိုတာ သိထားတာကြောင့် အဲဒါတွေကို ချန်လှပ်ထားလိုက်ပါပြီ - မဟုတ်ရင် အဲဒါကို လေ့ကျင့်ခန်းတစ်ခုအနေနဲ့ စဉ်းစားကြည့်ရအောင် ;-)

ယခု သင်သည် သင်၏ လုပ်ဆောင်ခြင်းဆိုင်ရာ အတန်းတစ်ခုစီကို အလှဆင်ရန် သင်၏ attribute class ကို အသုံးပြုနိုင်သည်။ ဥပမာအားဖြင့်၊ class declarations များသည် ဤကဲ့သို့ကြည့်နိုင်သည်-

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

သင့်အတန်းများကို သင်အလိုရှိသည့်အတိုင်း အမည်ပေးနိုင်ပါသည်။ ဤနေရာတွင် အရေးကြီးသောအပိုင်းမှာ သင့်အတန်းများကို ၎င်းတို့လုပ်ဆောင်မှုပုံစံနှင့် ကိုက်ညီသော attribute များဖြင့် အလှဆင်ခြင်းပင်ဖြစ်သည်။ (သို့သော် 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() နည်းလမ်းပါ။ ဤနည်းလမ်းဖြင့် လုပ်ဆောင်ရခြင်းမှာ အထက်တန်းအဆင့်၏ စူပါအတန်း၏ အမည်ကို လက်ခံခြင်းဖြစ်သည် (ဤစူပါအတန်းသည် အထက်တန်းအဆင့်၏ ထိပ် တွင်ရှိရန် မလိုအပ်ပါ၊ ၎င်းသည် ဤအတန်းကို တိုးချဲ့ထားသော အတန်းများသာ အရည်အချင်းပြည့်မီသည်ဟု ဆိုလိုသည်) နှင့် attribute object တစ်ခုတို့ ဖြစ်သည်။

ထို့နောက် ၎င်းသည် သတ်မှတ်ထားသော စူပါအတန်းကို ချဲ့ထွင်သည့် အတန်းတစ်ခု၏ အရာဝတ္ထုတစ်ခုကို ပြန်ပေး ကာ သက်ဆိုင်ရာ attribute ဖြင့် အလှဆင်ထားသည်။

သင်ဆန္ဒရှိသလောက် တည်ဆောက်ရေးနည်းလမ်းတွင် နောက်ထပ်အတည်ပြုချက် သို့မဟုတ် ယုတ္တိဗေဒကို သင်သိသာစွာထည့်သွင်းနိုင်သော်လည်း ဤနေရာ၌ အရေးကြီးသောအချက်မှာ အကောင်အထည်ဖော်ပြီးသည်နှင့် သင်ဤနည်းလမ်းကို ထပ်မံမွမ်းမံရန်မလိုအပ်ပါ။ အတန်းခွဲများကို အထက်တန်းအဆင့်သို့ သင်ထည့်နိုင်ပြီး ၎င်းတို့ကို သင့်လျော်စွာ အလှဆင်ရန် သေချာသရွေ့၊ ၎င်းကို ရေးသားသည့်အခါတွင် ၎င်းတို့မရှိသော်လည်း တည်ဆောက်ရေးနည်းလမ်းက ၎င်းတို့ကို တွေ့ရှိမည်ဖြစ်သည်။

စွမ်းဆောင်ရည်ကော။ ရိုးရိုးသားသား စံသတ်မှတ်ရန် မကြိုးစားခဲ့ဘဲ၊ ၎င်းသည် classic switch statement design ထက် ပိုဆိုးသည်ဟု ကျွန်ုပ်၏ ရင်တွင်းခံစားချက်က ယူဆပါသည်။ သို့သော်လည်း၊ Dynamics AX တွင် စွမ်းဆောင်ရည် အများဆုံး ပြဿနာများသည် ဒေတာဘေ့စ်ဝင်ရောက်မှုကြောင့် ဖြစ်ရသည့်အကြောင်းအရင်းကို ထည့်သွင်းစဉ်းစားထားသောကြောင့် ကျွန်ုပ်သည် ၎င်းကို အလွန်စိုးရိမ်မည်မဟုတ်ပါ။

သေချာပါတယ်၊ အကယ်၍ သင်သည် အရာဝတ္ထုထောင်ပေါင်းများစွာကို လျင်မြန်စွာဖန်တီးရန် လိုအပ်မည့်အရာတစ်ခုကို အကောင်အထည်ဖော်နေသည်ဆိုပါက၊ သင်သည် နောက်ထပ်စုံစမ်းရန်လိုပေလိမ့်မည်၊ သို့သော် သင်သည် အရာဝတ္တုတစ်ခုအား ရှည်လျားစွာလုပ်ဆောင်ရန် တစ်ခုတည်းကို ချက်ချင်းလုပ်ဆောင်သည့် ဂန္တဝင်ဖြစ်ရပ်များတွင်၊ ၎င်းသည် အရေးပါလိမ့်မည်ကို ကျွန်ုပ်သံသယရှိပါသည်။ ထို့အပြင် ကျွန်ုပ်၏ ပြဿနာဖြေရှင်းခြင်းဆိုင်ရာ အကြံပြုချက် (နောက်အပိုဒ်) ကို သုံးသပ်ကြည့်ပါက SysExtension မူဘောင်သည် ကက်ချခြင်းအပေါ် မှီခိုနေပုံပေါ်သည်၊ ထို့ကြောင့် လည်ပတ်နေသည့်စနစ်တွင် ၎င်းတွင် သိသာထင်ရှားသော စွမ်းဆောင်မှုရှိသည်ကို ကျွန်ုပ်သံသယရှိပါသည်။ ပြဿနာဖြေရှင်းခြင်း- တည်ဆောက်ရေးနည်းလမ်းသည် သင့်အတန်းခွဲများကို မှန်မှန်ကန်ကန် အလှဆင်ထားကြောင်း သေချာသော်လည်း ၎င်းတို့ကို မှန်ကန်စွာ အလှဆင်ထားသည်ကို မတွေ့ရှိရပါက၊ ၎င်းသည် ကက်ရှ်ပြဿနာဖြစ်နိုင်သည်။ client နှင့် server နှစ်ခုလုံးရှိ ကက်ရှ်များကို ရှင်းလင်းကြည့်ပါ။ AOS ကို အမှန်တကယ် ပြန်လည်စတင်ရန် မလိုအပ်သော်လည်း ၎င်းသည် နောက်ဆုံးနည်းလမ်း ဖြစ်နိုင်သည်။