Dynamics AX 2012 میں کون سے ذیلی طبقے کو فوری بنانا ہے یہ جاننے کے لیے SysExtension فریم ورک کا استعمال

شائع شدہ: 16 فروری، 2025 کو 12:26:08 AM UTC

یہ مضمون بیان کرتا ہے کہ Dynamics AX 2012 اور Dynamics 365 میں غیر معروف SysExtension فریم ورک کو کس طرح استعمال کیا جائے تاکہ انتساب سجاوٹ کی بنیاد پر ذیلی کلاسوں کو شروع کیا جا سکے، جس سے پروسیسنگ کلاس کے درجہ بندی کے آسانی سے قابل توسیع ڈیزائن کی اجازت دی جائے۔

یہ صفحہ انگریزی سے مشینی ترجمہ کیا گیا تھا تاکہ زیادہ سے زیادہ لوگوں تک اس تک رسائی ممکن بنائی جا سکے۔ بدقسمتی سے، مشینی ترجمہ ابھی تک ایک مکمل ٹیکنالوجی نہیں ہے، اس لیے غلطیاں ہو سکتی ہیں۔ اگر آپ چاہیں تو اصل انگریزی ورژن یہاں دیکھ سکتے ہیں:

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

اس پوسٹ میں معلومات Dynamics AX 2012 R3 پر مبنی ہے۔ یہ دوسرے ورژن کے لیے درست ہو سکتا ہے یا نہیں۔ (اپ ڈیٹ: میں اس بات کی تصدیق کر سکتا ہوں کہ اس مضمون میں دی گئی معلومات Dynamics 365 برائے آپریشنز کے لیے بھی درست ہیں)

Dynamics AX میں پروسیسنگ کلاسز کو لاگو کرتے وقت، آپ کو اکثر کلاس کا درجہ بندی بنانے کا سامنا کرنا پڑتا ہے جس میں ہر ذیلی کلاس ایک اینوم ویلیو سے مساوی ہوتی ہے یا اس میں کچھ اور ڈیٹا کپلنگ ہوتا ہے۔ ایک کلاسک ڈیزائن یہ ہے کہ پھر سپر کلاس میں ایک تعمیراتی طریقہ ہو، جس میں ایک سوئچ ہوتا ہے جو ان پٹ کی بنیاد پر یہ طے کرتا ہے کہ کس کلاس کو انسٹینٹیٹ کرنا ہے۔

یہ اصولی طور پر اچھی طرح سے کام کرتا ہے، لیکن اگر آپ کے پاس بہت سے مختلف ممکنہ ان پٹس ہیں (ایک اینوم میں بہت سے عناصر یا شاید ان پٹ کئی مختلف اقدار کا مجموعہ ہے)، یہ برقرار رکھنا مشکل اور غلطی کا شکار ہو سکتا ہے اور ڈیزائن کا ہمیشہ یہ نقصان ہوتا ہے کہ اگر آپ نے کبھی بھی کوئی نیا ذیلی طبقہ شامل کیا ہے یا تبدیلیاں کرنی ہوں گی جس میں ذیلی کلاس کی بنیاد پر استعمال کیا جانا چاہیے تو آپ کو مذکورہ تعمیراتی طریقہ میں ترمیم کرنے کی ضرورت ہوگی۔

خوش قسمتی سے، ایک بہت زیادہ خوبصورت، لیکن بدقسمتی سے بہت کم جانا جاتا ہے، ایسا کرنے کا طریقہ، یعنی SysExtension فریم ورک کے استعمال سے۔

یہ فریم ورک ان صفات سے فائدہ اٹھاتا ہے جو آپ اپنی ذیلی کلاسوں کو سجانے کے لیے استعمال کر سکتے ہیں تاکہ سسٹم کو یہ معلوم کر سکے کہ کس ذیلی کلاس کو کس چیز کو سنبھالنے کے لیے استعمال کیا جانا چاہیے۔ آپ کو ابھی بھی تعمیراتی طریقہ کی ضرورت ہوگی، لیکن اگر صحیح طریقے سے کیا جائے تو، آپ کو نئی ذیلی کلاسیں شامل کرتے وقت اس میں ترمیم کرنے کی ضرورت نہیں پڑے گی۔

آئیے ایک خیالی مثال دیکھیں اور کہتے ہیں کہ آپ ایک درجہ بندی کو نافذ کرنے جا رہے ہیں جو InventTrans ٹیبل کی بنیاد پر کسی قسم کی پروسیسنگ کرتا ہے۔ کونسی پروسیسنگ کرنی ہے اس کا انحصار ریکارڈز کی StatusReceipt اور Status Issue پر ہے، ساتھ ہی اس بات پر بھی کہ آیا ریکارڈز سیلز لائن، پورچ لائن سے متعلق ہیں یا نہ ہی۔ پہلے سے ہی، آپ بہت سے مختلف مجموعوں کو دیکھ رہے ہیں۔

چلیں پھر کہتے ہیں کہ آپ جانتے ہیں کہ ابھی کے لیے آپ کو صرف مٹھی بھر مجموعوں کو ہینڈل کرنے کی ضرورت ہے، لیکن آپ یہ بھی جانتے ہیں کہ آپ کو وقت کے ساتھ ساتھ زیادہ سے زیادہ امتزاج کو سنبھالنے کے لیے کہا جائے گا۔

آئیے اسے نسبتاً آسان رکھیں اور کہتے ہیں کہ فی الحال آپ کو SalesLine سے متعلقہ ریکارڈز کو ہینڈل کرنے کی ضرورت ہے جس میں ReservPhysical یا Reservordered کے StatusIssue کے ساتھ، باقی تمام امتزاجات کو ابھی نظر انداز کیا جا سکتا ہے، لیکن چونکہ آپ جانتے ہیں کہ آپ کو بعد میں انہیں ہینڈل کرنا پڑے گا، اس لیے آپ اپنے کوڈ کو اس طرح سے ڈیزائن کرنا چاہیں گے جس سے یہ آسانی سے قابل توسیع ہو۔

آپ کا درجہ بندی ابھی کچھ اس طرح نظر آ سکتی ہے:

مائی پروسیسر
- MyProcessor_Sales
  - MyProcessor_Sales_Reservered
  - MyProcessor_Sales_ReservPhysical

اب، آپ سپر کلاس میں ایک طریقہ آسانی سے نافذ کر سکتے ہیں جو ModuleInventPurchSales اور StatusIssue enum کی بنیاد پر ذیلی طبقے کو تیز کرتا ہے۔ لیکن اس کے بعد آپ کو ہر بار جب آپ ذیلی کلاس شامل کرتے ہیں تو آپ کو سپر کلاس میں ترمیم کرنے کی ضرورت ہوگی، اور یہ حقیقت میں آبجیکٹ پر مبنی پروگرامنگ میں وراثت کا خیال نہیں ہے۔ آخرکار، جب بھی آپ کوئی نیا بیچ جاب شامل کرتے ہیں تو آپ کو RunBaseBatch یا SysOperationServiceBase میں ترمیم کرنے کی ضرورت نہیں ہے۔

اس کے بجائے، آپ SysExtension فریم ورک کا استعمال کر سکتے ہیں۔ اس کے لیے آپ کو ایک اور کلاس شامل کرنے کی ضرورت ہوگی، جس میں SysAttribute کو بڑھانے کی ضرورت ہے۔ اس کلاس کو اس وصف کے طور پر استعمال کیا جائے گا جس کے ساتھ آپ اپنی پروسیسنگ کلاسوں کو سجا سکتے ہیں۔

یہ کلاس اس سے بہت ملتی جلتی ہے کہ آپ SysOperation کے نفاذ کے لیے ڈیٹا کنٹریکٹ کی کلاس کیسے بنائیں گے، اس میں ان اقدار کو حاصل کرنے اور سیٹ کرنے کے لیے کچھ ڈیٹا ممبرز اور پرم طریقے ہوں گے۔

ہمارے معاملے میں، کلاس ڈیکلریشن کچھ اس طرح نظر آ سکتا ہے:

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 طریقہ بھی نافذ کرنا چاہیے، لیکن میں نے انہیں یہاں چھوڑ دیا ہے کیونکہ مجھے یقین ہے کہ آپ جانتے ہیں کہ اسے کیسے کرنا ہے - بصورت دیگر، آئیے اسے ایک مشق سمجھتے ہیں ؛-)

اب آپ اپنی ہر ایک پروسیسنگ کلاس کو سجانے کے لیے اپنی انتساب کلاس کا استعمال کر سکتے ہیں۔ مثال کے طور پر، کلاس کے اعلانات اس طرح نظر آسکتے ہیں:

[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 فریم ورک کا فائدہ اٹھا سکتے ہیں۔

اپنی سپر کلاس (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 کو دوبارہ شروع کرنا ضروری نہیں ہے، لیکن یہ آخری حربہ ہو سکتا ہے۔