Dynamics AX 2012 में किस उपवर्ग को तत्काल बनाना है, यह जानने के लिए SysExtension फ्रेमवर्क का उपयोग करना

प्रकाशित: 16 फ़रवरी 2025 को 12:26:07 am 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 के लिए भी मान्य है)

डायनेमिक्स AX में प्रोसेसिंग क्लासेस को लागू करते समय, आपको अक्सर एक क्लास पदानुक्रम बनाने का सामना करना पड़ता है जिसमें प्रत्येक उपवर्ग एक एनम मान से मेल खाता है या कुछ अन्य डेटा युग्मन होता है। एक क्लासिक डिज़ाइन तब सुपर क्लास में एक निर्माण विधि होती है, जिसमें एक स्विच होता है जो यह निर्धारित करता है कि इनपुट के आधार पर किस क्लास को इंस्टेंटिएट करना है।

सिद्धांत रूप में यह अच्छी तरह से काम करता है, लेकिन यदि आपके पास कई अलग-अलग संभावित इनपुट हैं (एक enum में कई तत्व या शायद इनपुट कई अलग-अलग मानों का संयोजन है), तो इसे बनाए रखना थकाऊ और त्रुटि-प्रवण हो सकता है और डिज़ाइन में हमेशा यह नुकसान होता है कि यदि आप कभी भी एक नया उपवर्ग जोड़ते हैं या परिवर्तन करते हैं कि किस इनपुट के आधार पर किस उपवर्ग का उपयोग किया जाना चाहिए, तो आपको उक्त निर्माण विधि को संशोधित करने की आवश्यकता होगी।

सौभाग्य से, ऐसा करने का एक बहुत ही सुंदर, लेकिन दुर्भाग्य से बहुत कम ज्ञात तरीका है, वह है SysExtension फ्रेमवर्क का उपयोग।

यह फ्रेमवर्क उन विशेषताओं का लाभ उठाता है जिनका उपयोग आप अपने उपवर्गों को सजाने के लिए कर सकते हैं ताकि सिस्टम यह पता लगा सके कि किस उपवर्ग का उपयोग किस चीज़ को संभालने के लिए किया जाना चाहिए। आपको अभी भी एक निर्माण विधि की आवश्यकता होगी, लेकिन अगर सही तरीके से किया जाता है, तो आपको नए उपवर्ग जोड़ते समय इसे कभी भी संशोधित नहीं करना पड़ेगा।

आइए एक काल्पनिक उदाहरण देखें और कहें कि आप एक पदानुक्रम लागू करने जा रहे हैं जो InventTrans तालिका के आधार पर किसी प्रकार की प्रोसेसिंग करता है। कौन सी प्रोसेसिंग करनी है यह रिकॉर्ड्स के StatusReceipt और StatusIssue पर निर्भर करता है, साथ ही इस बात पर भी निर्भर करता है कि रिकॉर्ड्स SalesLine, PurchLine या दोनों से संबंधित हैं या नहीं। अब तक, आप बहुत सारे अलग-अलग संयोजनों को देख रहे हैं।

मान लीजिए कि आप जानते हैं कि अभी आपको केवल कुछ ही संयोजनों को संभालने की आवश्यकता है, लेकिन आप यह भी जानते हैं कि समय के साथ आपसे अधिक से अधिक संयोजनों को संभालने के लिए कहा जाएगा।

आइए इसे अपेक्षाकृत सरल रखें और कहें कि अभी आपको केवल ReservPhysical या ReservOrdered के StatusIssue के साथ SalesLine से संबंधित रिकॉर्ड को संभालने की आवश्यकता है, अन्य सभी संयोजनों को अभी अनदेखा किया जा सकता है, लेकिन चूंकि आप जानते हैं कि आपको उन्हें बाद में संभालना होगा, इसलिए आप अपने कोड को इस तरह से डिज़ाइन करना चाहेंगे कि इसे आसानी से विस्तार योग्य बनाया जा सके।

फिलहाल आपका पदानुक्रम कुछ इस तरह दिख सकता है:

मायप्रोसेसर
- माईप्रोसेसर_सेल्स
  - MyProcessor_Sales_Reservऑर्डर्ड
  - MyProcessor_Sales_Reservभौतिक

अब, आप आसानी से सुपर क्लास में एक विधि लागू कर सकते हैं जो 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
{
}

आप निश्चित रूप से अपनी कक्षाओं को किसी भी तरह से नाम दे सकते हैं, यहाँ महत्वपूर्ण बात यह है कि आप अपनी कक्षाओं को उन विशेषताओं से सजाएँ जो उनके द्वारा की जाने वाली प्रोसेसिंग के प्रकार के अनुरूप हों। (लेकिन ध्यान रखें कि Dynamics AX में कक्षा पदानुक्रम के लिए नामकरण परंपराएँ हैं और यदि संभव हो तो उनका पालन करना हमेशा एक अच्छा विचार है)।

अब जबकि आपने अपनी कक्षाओं को यह पहचानने के लिए सजा दिया है कि उनमें से प्रत्येक किस प्रकार का प्रसंस्करण करता है, तो आप आवश्यकतानुसार उप-वर्गों की वस्तुओं को तत्काल बनाने के लिए SysExtension फ्रेमवर्क का लाभ उठा सकते हैं।

अपने सुपर क्लास (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() विधि है। यह विधि जो करती है वह यह है कि यह पदानुक्रम के सुपर क्लास का नाम स्वीकार करती है (और इस सुपर क्लास को पदानुक्रम के शीर्ष पर होने की आवश्यकता नहीं है; इसका सीधा सा मतलब है कि केवल इस क्लास को विस्तारित करने वाली क्लास ही योग्य होंगी) और एक विशेषता ऑब्जेक्ट।

इसके बाद यह एक क्लास का ऑब्जेक्ट लौटाता है जो निर्दिष्ट सुपर क्लास का विस्तार करता है और एक संगत विशेषता से सजाया जाता है।

आप स्पष्ट रूप से निर्माण विधि में जितना चाहें उतना सत्यापन या तर्क जोड़ सकते हैं, लेकिन यहाँ महत्वपूर्ण बात यह है कि एक बार लागू होने के बाद, आपको इस विधि को फिर से संशोधित करने की आवश्यकता नहीं होगी। आप पदानुक्रम में उप-वर्ग जोड़ सकते हैं और जब तक आप उन्हें उचित रूप से सजाना सुनिश्चित करते हैं, निर्माण विधि उन्हें खोज लेगी, भले ही वे लिखे जाने के समय मौजूद न हों।

प्रदर्शन के बारे में क्या? मैंने ईमानदारी से इसे बेंचमार्क करने का प्रयास नहीं किया है, लेकिन मेरी आंतरिक भावना यह है कि यह शायद क्लासिक स्विच स्टेटमेंट डिज़ाइन से भी खराब प्रदर्शन करता है। हालाँकि, यह देखते हुए कि Dynamics AX में अब तक की सबसे अधिक प्रदर्शन समस्याएँ डेटाबेस एक्सेस के कारण होती हैं, मैं इसके बारे में बहुत अधिक चिंता नहीं करूँगा।

बेशक, अगर आप कुछ ऐसा लागू कर रहे हैं जिसके लिए हजारों ऑब्जेक्ट को जल्दी से बनाने की आवश्यकता होगी, तो आप आगे की जांच करना चाह सकते हैं, लेकिन क्लासिक मामलों में जहां आप कुछ लंबी प्रक्रिया करने के लिए केवल एक ऑब्जेक्ट को इंस्टेंटिएट करते हैं, मुझे संदेह है कि इससे कोई फर्क पड़ेगा। साथ ही, मेरे समस्या निवारण टिप (अगले पैराग्राफ) पर विचार करते हुए, ऐसा प्रतीत होता है कि SysExtension फ्रेमवर्क कैशिंग पर निर्भर करता है, इसलिए एक चालू सिस्टम में मुझे संदेह है कि इसका प्रदर्शन पर कोई महत्वपूर्ण प्रभाव पड़ता है। समस्या निवारण: यदि निर्माण विधि आपके उपवर्गों को नहीं ढूंढ पाती है, भले ही आप निश्चित हों कि वे सही ढंग से सजाए गए हैं, तो यह कैशिंग समस्या हो सकती है। क्लाइंट और सर्वर दोनों पर कैश साफ़ करने का प्रयास करें। वास्तव में AOS को पुनरारंभ करना आवश्यक नहीं होना चाहिए, लेकिन यह अंतिम उपाय हो सकता है।