ડાયનેમિક્સ એએક્સ 2012 માં કયા પેટા વર્ગને પ્રારંભ કરવો તે શોધવા માટે SysExtension ફ્રેમવર્કનો ઉપયોગ કરીને

પ્રકાશિત: 16 ફેબ્રુઆરી, 2025 એ 12:28:18 AM UTC વાગ્યે
છેલ્લે અપડેટ કરેલ: 12 જાન્યુઆરી, 2026 એ 08:43:41 AM UTC વાગ્યે

આ લેખ વર્ણવે છે કે ડાયનેમિક્સ AX 2012 અને ડાયનેમિક્સ 365 માં ઓછા જાણીતા SysExtension ફ્રેમવર્કનો ઉપયોગ ઓપરેશન્સ માટે કેવી રીતે કરવો જેથી એટ્રિબ્યુટ ડેકોરેશન પર આધારિત પેટા વર્ગો સ્થાપિત થાય, જે પ્રોસેસિંગ ક્લાસ હાયરાર્કીની સરળતાથી એક્સ્ટેન્સિબલ ડિઝાઇન માટે પરવાનગી આપે છે.

આ પૃષ્ઠ શક્ય તેટલા વધુ લોકો સુધી સુલભ બને તે માટે અંગ્રેજીમાંથી મશીન અનુવાદ કરવામાં આવ્યો હતો. કમનસીબે, મશીન અનુવાદ હજુ સુધી સંપૂર્ણ તકનીક નથી, તેથી ભૂલો થઈ શકે છે. જો તમે ઇચ્છો, તો તમે મૂળ અંગ્રેજી સંસ્કરણ અહીં જોઈ શકો છો:

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

આ પોસ્ટમાંની માહિતી ડાયનેમિક્સ AX 2012 R3 પર આધારિત છે. તે અન્ય સંસ્કરણો માટે માન્ય હોઈ શકે છે અથવા ન પણ હોઈ શકે. (અપડેટ: હું પુષ્ટિ કરી શકું છું કે આ લેખમાંની માહિતી ઓપરેશન્સ માટે ડાયનેમિક્સ 365 માટે પણ માન્ય છે)

ડાયનેમિક્સ AX માં પ્રોસેસિંગ ક્લાસ લાગુ કરતી વખતે, તમને ઘણીવાર એક ક્લાસ હાયરાર્કી બનાવવાનો સામનો કરવો પડે છે જેમાં દરેક સબક્લાસ એક enum મૂલ્યને અનુરૂપ હોય અથવા કોઈ અન્ય ડેટા કપ્લિંગ હોય. ક્લાસિક ડિઝાઇન એ છે કે પછી સુપર ક્લાસમાં એક કન્સ્ટ્રક્ટ મેથડ હોય, જેમાં એક સ્વીચ હોય છે જે ઇનપુટના આધારે કયા ક્લાસને ઇન્સ્ટન્ટિએટ કરવો તે નક્કી કરે છે.

આ સિદ્ધાંતમાં સારી રીતે કાર્ય કરે છે, પરંતુ જો તમારી પાસે ઘણા બધા અલગ અલગ શક્ય ઇનપુટ્સ હોય (એનમમાં ઘણા બધા તત્વો અથવા કદાચ ઇનપુટ ઘણા જુદા જુદા મૂલ્યોનું સંયોજન હોય), તો તે જાળવવા માટે કંટાળાજનક અને ભૂલ-પ્રભાવી બની શકે છે અને ડિઝાઇનમાં હંમેશા ગેરલાભ રહે છે કે જો તમે ક્યારેય નવો સબક્લાસ ઉમેરો છો અથવા કયા ઇનપુટના આધારે કયા સબક્લાસનો ઉપયોગ કરવો જોઈએ તેમાં ફેરફાર કરો છો તો તમારે કથિત કન્સ્ટ્રક્ટ પદ્ધતિમાં ફેરફાર કરવાની જરૂર પડશે.

સદનસીબે, આ કરવાની એક વધુ ભવ્ય, પરંતુ કમનસીબે ઘણી ઓછી જાણીતી રીત છે, એટલે કે SysExtension ફ્રેમવર્કનો ઉપયોગ કરીને.

આ ફ્રેમવર્ક એવા ગુણોનો લાભ લે છે જેનો ઉપયોગ તમે તમારા પેટા વર્ગોને સજાવવા માટે કરી શકો છો જેથી સિસ્ટમ નક્કી કરી શકે કે કયા પેટા વર્ગનો ઉપયોગ શેના સંચાલન માટે થવો જોઈએ. તમારે હજુ પણ એક કન્સ્ટ્રક્ટ પદ્ધતિની જરૂર પડશે, પરંતુ જો યોગ્ય રીતે કરવામાં આવે, તો તમારે નવા પેટા વર્ગો ઉમેરતી વખતે તેમાં ક્યારેય ફેરફાર કરવાની જરૂર રહેશે નહીં.

ચાલો એક કાલ્પનિક ઉદાહરણ જોઈએ અને કહીએ કે તમે એક વંશવેલો અમલમાં મૂકવા જઈ રહ્યા છો જે InventTrans કોષ્ટકના આધારે અમુક પ્રકારની પ્રક્રિયા કરે છે. કઈ પ્રક્રિયા કરવી તે રેકોર્ડ્સના StatusReceipt અને StatusIssue પર તેમજ રેકોર્ડ્સ SalesLine, PurchLine કે બેમાંથી કોઈ સાથે સંબંધિત છે કે નહીં તેના પર આધાર રાખે છે. પહેલેથી જ, તમે ઘણા બધા વિવિધ સંયોજનો જોઈ રહ્યા છો.

ચાલો કહીએ કે તમને ખબર છે કે હમણાં માટે તમારે ફક્ત થોડા જ સંયોજનોને હેન્ડલ કરવાની જરૂર છે, પરંતુ તમને એ પણ ખબર છે કે સમય જતાં તમને વધુને વધુ સંયોજનોને હેન્ડલ કરવા માટે સક્ષમ બનવાનું કહેવામાં આવશે.

ચાલો તેને પ્રમાણમાં સરળ રાખીએ અને કહીએ કે હમણાં માટે તમારે ફક્ત સેલ્સલાઈન સંબંધિત રેકોર્ડ્સને જ હેન્ડલ કરવાની જરૂર છે જેમાં ReservPhysical અથવા ReservOrdered ના StatusIssue હોય, અન્ય બધા સંયોજનોને હાલ માટે અવગણી શકાય છે, પરંતુ કારણ કે તમે જાણો છો કે તમારે તેમને પછીથી હેન્ડલ કરવા પડશે, તમારે તમારા કોડને એવી રીતે ડિઝાઇન કરવા માંગશો કે તે સરળતાથી એક્સટેન્સિબલ બને.

તમારો વંશવેલો હમણાં માટે કંઈક આના જેવો દેખાઈ શકે છે:

મારો પ્રોસેસરમારો પ્રોસેસર_વેચાણમારો પ્રોસેસર_વેચાણ_અનામત ઓર્ડર કરેલમારો પ્રોસેસર_વેચાણ_અનામતભૌતિક

હવે, તમે સુપર ક્લાસમાં એક પદ્ધતિ સરળતાથી અમલમાં મૂકી શકો છો જે ModuleInventPurchSales અને StatusIssue enum પર આધારિત સબક્લાસને ઇન્સ્ટન્ટિયેટ કરે છે. પરંતુ પછી તમારે દર વખતે સબક્લાસ ઉમેરતી વખતે સુપર ક્લાસમાં ફેરફાર કરવાની જરૂર પડશે, અને તે ખરેખર ઑબ્જેક્ટ-ઓરિએન્ટેડ પ્રોગ્રામિંગમાં વારસાનો વિચાર નથી. છેવટે, તમારે દર વખતે નવી બેચ જોબ ઉમેરતી વખતે RunBaseBatch અથવા SysOperationServiceBase માં ફેરફાર કરવાની જરૂર નથી.

તેના બદલે, તમે SysExtension ફ્રેમવર્કનો ઉપયોગ કરી શકો છો. તેના માટે તમારે બીજો ક્લાસ ઉમેરવો પડશે, જેને 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
{
}

અલબત્ત, તમે તમારા વર્ગોને ગમે તે રીતે નામ આપી શકો છો, અહીં મહત્વનો ભાગ એ છે કે તમે તમારા વર્ગોને એવા લક્ષણોથી સજાવો જે તેઓ કયા પ્રકારની પ્રક્રિયા કરે છે તેને અનુરૂપ હોય. (પરંતુ ધ્યાનમાં રાખો કે ડાયનેમિક્સ AX માં વર્ગ વંશવેલો માટે નામકરણ પરંપરાઓ છે અને જો શક્ય હોય તો તેનું પાલન કરવું હંમેશા સારો વિચાર છે).

હવે જ્યારે તમે તમારા વર્ગોને સજાવી લીધા છે કે તે દરેક વર્ગ કયા પ્રકારની પ્રક્રિયા કરે છે તે ઓળખી શકાય, તો તમે જરૂરિયાત મુજબ સબક્લાસના ઑબ્જેક્ટ્સને ઇન્સ્ટન્ટિએટ કરવા માટે SysExtension ફ્રેમવર્કનો લાભ લઈ શકો છો.

તમારા સુપર ક્લાસ (માયપ્રોસેસર) માં, તમે આના જેવી કન્સ્ટ્રક્ટ પદ્ધતિ ઉમેરી શકો છો:

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() પદ્ધતિ છે. આ પદ્ધતિ જે કરે છે તે એ છે કે તે વંશવેલાના સુપર ક્લાસનું નામ સ્વીકારે છે (અને આ સુપર ક્લાસ વંશવેલાની ટોચ પર હોવું જરૂરી નથી; તેનો સીધો અર્થ એ છે કે ફક્ત આ વર્ગને વિસ્તૃત કરતા વર્ગો જ પાત્ર રહેશે) અને એક એટ્રિબ્યુટ ઑબ્જેક્ટ.

તે પછી તે ક્લાસનો એક ઑબ્જેક્ટ પરત કરે છે જે ઉલ્લેખિત સુપર ક્લાસને વિસ્તૃત કરે છે અને તેને અનુરૂપ વિશેષતાથી શણગારવામાં આવે છે.

તમે કન્સ્ટ્રક્ટ પદ્ધતિમાં ગમે તેટલી વધુ માન્યતા અથવા તર્ક ઉમેરી શકો છો, પરંતુ અહીં મહત્વપૂર્ણ બાબત એ છે કે એકવાર અમલમાં મૂક્યા પછી, તમારે આ પદ્ધતિને ફરી ક્યારેય સુધારવાની જરૂર નથી. તમે વંશવેલોમાં પેટા વર્ગો ઉમેરી શકો છો અને જ્યાં સુધી તમે તેમને યોગ્ય રીતે સજાવવાની ખાતરી કરો છો, ત્યાં સુધી કન્સ્ટ્રક્ટ પદ્ધતિ તેમને શોધી કાઢશે, ભલે તે લખાઈ ત્યારે અસ્તિત્વમાં ન હોય.

પ્રદર્શન વિશે શું? મેં પ્રામાણિકપણે તેને બેન્ચમાર્ક કરવાનો પ્રયાસ કર્યો નથી, પરંતુ મારી આંતરિક લાગણી એ છે કે આ કદાચ ક્લાસિક સ્વિચ સ્ટેટમેન્ટ ડિઝાઇન કરતાં વધુ ખરાબ પ્રદર્શન કરે છે. જોકે, ડાયનેમિક્સ AX માં અત્યાર સુધીની સૌથી વધુ પ્રદર્શન સમસ્યાઓ ડેટાબેઝ ઍક્સેસને કારણે થાય છે તે ધ્યાનમાં લેતા, હું તેના વિશે વધુ ચિંતા કરીશ નહીં.

અલબત્ત, જો તમે એવી કોઈ વસ્તુનો અમલ કરી રહ્યા છો જેના માટે હજારો ઑબ્જેક્ટ ઝડપથી બનાવવાની જરૂર પડશે, તો તમે વધુ તપાસ કરી શકો છો, પરંતુ ક્લાસિક કિસ્સાઓમાં જ્યાં તમે ફક્ત એક જ ઑબ્જેક્ટને થોડી લાંબી પ્રક્રિયા કરવા માટે ઇન્સ્ટન્ટ કરો છો, મને શંકા છે કે તે વાંધો ઉઠાવશે. ઉપરાંત, મારી મુશ્કેલીનિવારણ ટિપ (આગળનો ફકરો) ધ્યાનમાં લેતા, એવું લાગે છે કે SysExtension ફ્રેમવર્ક કેશીંગ પર આધાર રાખે છે, તેથી ચાલી રહેલ સિસ્ટમમાં મને શંકા છે કે તેનું પ્રદર્શન નોંધપાત્ર રીતે સફળ થશે.

મુશ્કેલીનિવારણ: જો કન્સ્ટ્રક્ટ પદ્ધતિ તમારા સબ ક્લાસને યોગ્ય રીતે શણગારેલા હોવા છતાં શોધી શકતી નથી, તો તે કેશીંગ સમસ્યા હોઈ શકે છે. ક્લાયંટ અને સર્વર બંને પર કેશ સાફ કરવાનો પ્રયાસ કરો. AOS ને ખરેખર ફરીથી શરૂ કરવું જરૂરી નથી, પરંતુ તે છેલ્લો ઉપાય હોઈ શકે છે.

વધુ વાંચન

જો તમને આ પોસ્ટ ગમી હોય, તો તમને આ સૂચનો પણ ગમશે: