Menggunakan Kerangka Kerja SysExtension untuk Menemukan Subkelas Mana yang Akan Dibuat Instansi di Dynamics AX 2012

Diterbitkan: 16 Februari 2025 pukul 00.25.45 UTC

Artikel ini menguraikan cara menggunakan kerangka kerja SysExtension yang kurang dikenal dalam Dynamics AX 2012 dan Dynamics 365 for Operations untuk membuat instance sub kelas berdasarkan dekorasi atribut, yang memungkinkan desain hierarki kelas pemrosesan yang mudah diperluas.

Halaman ini diterjemahkan oleh mesin dari bahasa Inggris agar dapat diakses oleh sebanyak mungkin orang. Sayangnya, terjemahan mesin belum merupakan teknologi yang sempurna, sehingga kesalahan dapat terjadi. Jika Anda mau, Anda dapat melihat versi bahasa Inggris aslinya di sini:

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

Informasi dalam posting ini berdasarkan Dynamics AX 2012 R3. Informasi ini mungkin berlaku atau tidak berlaku untuk versi lain. (Pembaruan: Saya dapat mengonfirmasi bahwa informasi dalam artikel ini juga berlaku untuk Dynamics 365 for Operations)

Saat mengimplementasikan kelas pemrosesan di Dynamics AX, Anda sering dihadapkan dengan pembuatan hierarki kelas di mana setiap subkelas sesuai dengan nilai enum atau memiliki beberapa penggabungan data lainnya. Desain klasik adalah dengan memiliki metode konstruksi di kelas super, yang memiliki sakelar yang menentukan kelas mana yang akan dibuat berdasarkan input.

Hal ini pada prinsipnya bekerja dengan baik, tetapi jika Anda memiliki banyak kemungkinan masukan yang berbeda (banyak elemen dalam sebuah enum atau mungkin masukan tersebut merupakan gabungan dari beberapa nilai yang berbeda), hal tersebut dapat menjadi membosankan dan rawan kesalahan untuk dipelihara dan desainnya selalu memiliki kelemahan yaitu Anda perlu memodifikasi metode konstruksi tersebut jika Anda menambahkan subkelas baru atau membuat perubahan pada subkelas mana yang harus digunakan berdasarkan masukan yang mana.

Untungnya, ada cara yang jauh lebih elegan, tetapi sayangnya juga kurang dikenal, untuk melakukan ini, yaitu dengan menggunakan kerangka kerja SysExtension.

Kerangka kerja ini memanfaatkan atribut yang dapat Anda gunakan untuk menghias subkelas Anda agar sistem dapat menentukan subkelas mana yang harus digunakan untuk menangani apa. Anda tetap memerlukan metode konstruksi, tetapi jika dilakukan dengan benar, Anda tidak perlu mengubahnya saat menambahkan subkelas baru.

Mari kita lihat contoh imajiner dan katakan bahwa Anda akan menerapkan hierarki yang melakukan semacam pemrosesan berdasarkan tabel InventTrans. Pemrosesan yang akan dilakukan bergantung pada StatusReceipt dan StatusIssue dari catatan, juga pada apakah catatan tersebut terkait dengan SalesLine, PurchLine atau tidak keduanya. Sekarang, Anda melihat banyak kombinasi yang berbeda.

Katakanlah Anda tahu bahwa untuk saat ini Anda hanya perlu menangani beberapa kombinasi saja, tetapi Anda juga tahu bahwa Anda akan diminta untuk mampu menangani lebih banyak kombinasi seiring berjalannya waktu.

Mari kita buat agar relatif sederhana dan katakan bahwa untuk saat ini Anda hanya perlu menangani rekaman yang terkait dengan SalesLine dengan StatusIssue ReservPhysical atau ReservOrdered. Semua kombinasi lainnya dapat diabaikan untuk saat ini. Namun, karena Anda tahu bahwa Anda harus menanganinya nanti, Anda perlu mendesain kode sedemikian rupa sehingga mudah diperluas.

Hirarki Anda mungkin terlihat seperti ini untuk saat ini:

Prosesor Saya
- Penjualan_ProsesorSaya
  - Prosesor_Penjualan_Reservasi_Dipesan
  - Prosesor_Penjualan_Reservasi_Fisik

Sekarang, Anda dapat dengan mudah mengimplementasikan metode di kelas super yang membuat subkelas berdasarkan enum ModuleInventPurchSales dan StatusIssue. Namun, Anda kemudian perlu memodifikasi kelas super setiap kali Anda menambahkan subkelas, dan itu bukanlah ide pewarisan dalam pemrograman berorientasi objek. Lagi pula, Anda tidak perlu memodifikasi RunBaseBatch atau SysOperationServiceBase setiap kali Anda menambahkan pekerjaan batch baru.

Sebagai gantinya, Anda dapat menggunakan kerangka kerja SysExtension. Itu akan mengharuskan Anda untuk menambahkan kelas lain, yang perlu memperluas SysAttribute. Kelas ini akan digunakan sebagai atribut yang dapat Anda gunakan untuk menghias kelas pemrosesan Anda.

Kelas ini sangat mirip dengan cara Anda membuat kelas kontrak data untuk implementasi SysOperation, yang mana kelas ini akan memiliki beberapa anggota data dan metode parameter untuk mendapatkan dan menetapkan nilai tersebut.

Dalam kasus kita, ClassDeclaration mungkin terlihat seperti ini:

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

Anda perlu membuat metode new() untuk membuat semua anggota data. Jika Anda ingin, Anda dapat memberikan beberapa atau semua nilai default, tetapi saya belum melakukannya.

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

    super();

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

Dan Anda juga harus mengimplementasikan metode parm untuk setiap anggota data, tetapi saya menghilangkannya di sini karena saya yakin Anda tahu cara melakukannya - jika tidak, mari kita anggap ini sebagai latihan ;-)

Sekarang Anda dapat menggunakan kelas atribut untuk menghias setiap kelas pemrosesan Anda. Misalnya, deklarasi kelas dapat terlihat seperti ini:

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

Tentu saja Anda dapat memberi nama kelas sesuai keinginan, yang penting di sini adalah Anda menghias kelas dengan atribut yang sesuai dengan jenis pemrosesan yang dilakukannya. (Namun perlu diingat bahwa ada konvensi penamaan untuk hierarki kelas di Dynamics AX dan sebaiknya selalu ikuti konvensi tersebut, jika memungkinkan).

Sekarang, setelah Anda mendekorasi kelas-kelas Anda untuk mengidentifikasi jenis pemrosesan yang dilakukan masing-masing kelas, Anda dapat memanfaatkan kerangka kerja SysExtension untuk membuat instance objek-objek subkelas sesuai kebutuhan.

Di kelas super Anda (MyProcessor), Anda dapat menambahkan metode konstruksi seperti ini:

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

Bagian yang benar-benar menarik - dan benar-benar objek (maaf atas kata-katanya) dari seluruh tulisan ini - adalah metode getClassFromSysAttribute() di kelas SysExtensionAppClassFactory. Metode ini menerima nama kelas super hierarki (dan kelas super ini tidak perlu berada di puncak hierarki; artinya hanya kelas yang memperluas kelas ini yang memenuhi syarat) dan objek atribut.

Kemudian mengembalikan objek kelas yang memperluas kelas super yang ditentukan dan didekorasi dengan atribut yang sesuai.

Anda tentu saja dapat menambahkan validasi atau logika lebih lanjut ke metode konstruksi sesuai keinginan, tetapi hal penting yang dapat diambil di sini adalah bahwa setelah diterapkan, Anda tidak perlu mengubah metode ini lagi. Anda dapat menambahkan subkelas ke hierarki dan selama Anda memastikan untuk menghiasnya dengan tepat, metode konstruksi akan menemukannya meskipun subkelas tersebut tidak ada saat ditulis.

Bagaimana dengan kinerja? Sejujurnya saya belum mencoba membandingkannya, tetapi firasat saya mengatakan bahwa kinerjanya mungkin lebih buruk daripada desain pernyataan switch klasik. Namun, mengingat bahwa sejauh ini sebagian besar masalah kinerja di Dynamics AX disebabkan oleh akses basis data, saya tidak akan terlalu mengkhawatirkannya.

Tentu saja, jika Anda mengimplementasikan sesuatu yang mengharuskan ribuan objek dibuat dengan cepat, Anda mungkin ingin menyelidikinya lebih lanjut, tetapi dalam kasus klasik saat Anda hanya membuat satu objek untuk melakukan pemrosesan yang panjang, saya ragu itu akan menjadi masalah. Selain itu, dengan mempertimbangkan kiat pemecahan masalah saya (paragraf berikutnya), tampaknya kerangka kerja SysExtension bergantung pada caching, jadi dalam sistem yang sedang berjalan saya ragu itu akan berdampak signifikan pada kinerja. Pemecahan Masalah: Jika metode konstruksi tidak menemukan subkelas Anda meskipun Anda yakin mereka didekorasi dengan benar, itu mungkin masalah caching. Coba bersihkan cache pada klien dan server. Seharusnya tidak perlu benar-benar memulai ulang AOS, tetapi mungkin itu pilihan terakhir.