SysExtension ჩარჩოს გამოყენებით იმის გასარკვევად, თუ რომელი ქვეკლასი უნდა იყოს მყისიერი Dynamics AX 2012-ში

გამოქვეყნებულია: 16 თებერვალი, 2025, 00:28:48 UTC

ამ სტატიაში აღწერილია, თუ როგორ უნდა გამოიყენოთ ნაკლებად ცნობილი SysExtension ჩარჩო Dynamics AX 2012 და Dynamics 365 ოპერაციებისთვის ქვეკლასების ინსტანციის დეკორაციებზე დაყრდნობით, რაც საშუალებას იძლევა ადვილად გაფართოვდეს დამუშავების კლასის იერარქიის დიზაინი.

ეს გვერდი მანქანურად ითარგმნა ინგლისურიდან, რათა რაც შეიძლება მეტი ადამიანისთვის ხელმისაწვდომი ყოფილიყო. სამწუხაროდ, მანქანური თარგმანი ჯერ კიდევ არ არის სრულყოფილი ტექნოლოგია, ამიტომ შეიძლება მოხდეს შეცდომები. თუ გსურთ, შეგიძლიათ ნახოთ ორიგინალური ინგლისური ვერსია აქ:

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 ცხრილის საფუძველზე. რომელი დამუშავება უნდა გააკეთოს, დამოკიდებულია ჩანაწერების სტატუსზე და სტატუსზე, ასევე იმაზე, უკავშირდება თუ არა ჩანაწერები SalesLine- ს, PurchLine- ს ან არცერთს. უკვე ახლა, თქვენ უყურებთ უამრავ სხვადასხვა კომბინაციას.

მოდით ვთქვათ, რომ თქვენ იცით, რომ ახლა თქვენ მხოლოდ უნდა გაუმკლავდეთ რამდენიმე კომბინაციას, მაგრამ თქვენ ასევე იცით, რომ მოგეთხოვებათ დროთა განმავლობაში უფრო და უფრო მეტი კომბინაციის მოგვარება.

მოდით შევინარჩუნოთ ეს შედარებით მარტივი და ვთქვათ, რომ ახლა თქვენ მხოლოდ უნდა გაუმკლავდეთ SalesLine– სთან დაკავშირებულ ჩანაწერებს StatusIssue of ReservPhysical ან ReservOrdered– ით, ყველა სხვა კომბინაცია შეიძლება იგნორირებული იყოს ახლა, მაგრამ რადგან თქვენ იცით, რომ მოგვიანებით მოგიწევთ მათი მოგვარება, თქვენ გსურთ შეიმუშაოთ თქვენი კოდი ისე, რომ ის ადვილად გაფართოვდეს.

თქვენი იერარქია შეიძლება ახლა ასე გამოიყურებოდეს:

MyProcessor
- MyProcessor_Sales
  - MyProcessor_Sales_ReservOrdered
  - MyProcessor_Sales_ReservPhysical

ახლა, თქვენ შეგიძლიათ მარტივად განახორციელოთ მეთოდი სუპერ კლასში, რომელიც ხელს აწვება ქვეკლასს მოდულის საფუძველზეPurchSales და StatusIssue enum. მაგრამ შემდეგ თქვენ უნდა შეცვალოთ სუპერ კლასი ყოველ ჯერზე, როდესაც დაამატებთ ქვეკლასს და ეს ნამდვილად არ არის მემკვიდრეობის იდეა ობიექტზე ორიენტირებულ პროგრამირებაში. საბოლოოდ, თქვენ არ გჭირდებათ RunBaseBatch ან SysOperationServiceBase შეცვლა ყოველ ჯერზე, როდესაც დაამატებთ ახალ ჯგუფურ სამუშაოს.

ამის ნაცვლად, შეგიძლიათ გამოიყენოთ SysExtension ჩარჩო. ეს მოითხოვს კიდევ ერთი კლასის დამატებას, რომელიც უნდა გააგრძელოს SysAttribute. ეს კლასი გამოყენებული იქნება როგორც ატრიბუტი, რომლითაც შეგიძლიათ დაამშვენოთ თქვენი დამუშავების კლასები.

ეს კლასი ძალიან ჰგავს იმას, თუ როგორ გააკეთებდით მონაცემთა კონტრაქტის კლასს SysOperation განხორციელებისთვის, რადგან მას ექნება მონაცემთა გარკვეული წევრები და პარმის მეთოდები ამ ღირებულებების მიღებისა და დასადგენად.

ჩვენს შემთხვევაში, 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;
}

თქვენ ასევე უნდა განახორციელოთ პარმის მეთოდი მონაცემთა თითოეული წევრისთვის, მაგრამ მე გამოტოვე ისინი აქ, რადგან დარწმუნებული ვარ, რომ თქვენ იცით როგორ გააკეთოთ ეს - წინააღმდეგ შემთხვევაში, მოდით განვიხილოთ ეს სავარჯიშო;-)

ახლა თქვენ შეგიძლიათ გამოიყენოთ თქვენი ატრიბუტის კლასი, რომ დაამშვენოთ თქვენი დამუშავების თითოეული კლასი. მაგალითად, კლასის დეკლარაციები შეიძლება ასე გამოიყურებოდეს:

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

მართლაც საინტერესო ნაწილი - და ნამდვილად ობიექტი (შეიწყალეთ pun) მთელი ამ პოსტის - არის getClassFromSysAttribute() მეთოდი SysExtensionAppClassFactory კლასში. რას აკეთებს ეს მეთოდი არის ის, რომ იგი იღებს იერარქიის სუპერ კლასის სახელს (და ამ სუპერ კლასს არ სჭირდება იერარქიის ზედა ნაწილში ყოფნა; ეს უბრალოდ ნიშნავს, რომ მხოლოდ ამ კლასის გაფართოებულ კლასებს მიეცემათ) და ატრიბუტის ობიექტი.

შემდეგ ის უბრუნებს კლასის ობიექტს, რომელიც აფართოებს მითითებულ სუპერ კლასს და გაფორმებულია შესაბამისი ატრიბუტით.

თქვენ აშკარად შეგიძლიათ დაამატოთ იმდენი შემდგომი დადასტურება ან ლოგიკა მშენებლობის მეთოდს, როგორც გსურთ, მაგრამ აქ მნიშვნელოვანი წაღება ის არის, რომ განხორციელების შემდეგ, თქვენ აღარ უნდა შეცვალოთ ეს მეთოდი. თქვენ შეგიძლიათ დაამატოთ ქვეკლასები იერარქიაში და სანამ დარწმუნდებით, რომ მათ სათანადოდ დაამშვენებთ, მშენებლობის მეთოდი იპოვის მათ, მიუხედავად იმისა, რომ ისინი არ არსებობდნენ, როდესაც ის დაიწერა.

რაც შეეხება შესრულებას? მე გულწრფელად არ ვცდილობდი ამის ნიშნულს, მაგრამ ჩემი ნაწლავის შეგრძნება ის არის, რომ ეს ალბათ უარესია, ვიდრე კლასიკური გადართვის განცხადების დიზაინი. თუმცა, იმის გათვალისწინებით, რომ Dynamics AX– ში ყველაზე მეტი შესრულების საკითხი გამოწვეულია მონაცემთა ბაზის წვდომით, ამაზე ძალიან არ ვინერვიულებდი.

რა თქმა უნდა, თუ თქვენ ახორციელებთ ისეთ რამეს, რაც მოითხოვს ათასობით ობიექტის სწრაფად შექმნას, შეიძლება დაგჭირდეთ შემდგომი გამოკვლევა, მაგრამ კლასიკურ შემთხვევებში, როდესაც თქვენ უბრალოდ აწვებათ ერთ ობიექტს გარკვეული ხანგრძლივი დამუშავების გასაკეთებლად, ეჭვი მეპარება, რომ ამას მნიშვნელობა ექნება. ასევე, ჩემი პრობლემების მოგვარების წვერი (შემდეგი აბზაცი) გათვალისწინებით, როგორც ჩანს, SysExtension ჩარჩო ეყრდნობა ქეშირებას, ასე რომ, გაშვებულ სისტემაში ეჭვი მეპარება, რომ მას აქვს მნიშვნელოვანი შესრულების ჰიტი. პრობლემების მოგვარება: თუ კონსტრუქციის მეთოდი ვერ პოულობს თქვენს ქვეკლასებს, მიუხედავად იმისა, რომ დარწმუნებული ხართ, რომ ისინი სწორად არის მორთული, ეს შეიძლება იყოს ქეშირების პრობლემა. სცადეთ ქეშის გასუფთავება როგორც კლიენტზე, ასევე სერვერზე. არ უნდა იყოს საჭირო AOS- ის რეალურად გადატვირთვა, მაგრამ ეს შეიძლება იყოს უკანასკნელი საშუალება.