Halo semuanya! Nama saya Tanya, saya adalah pemimpin tim tim pengembangan Axapta di Lamoda. Artikel ini akan membahas pengembangan proyek pertama kami pada platform Microsoft Dynamics 365 Untuk Keuangan dan Operasi.

gambar

Saya akan berbicara tentang pendekatan yang kami gunakan, tentang kesalahan yang dibuat, saya akan membagikan pengetahuan saya dan mendapatkan pengalaman. Artikel ini mungkin menarik bagi mereka yang mulai mengembangkan proyek di D365 atau hanya memikirkannya.

Ini adalah transkrip gratis dari laporan dari pertemuan Meetup Platform Mycrosoft Dynamics 365 & Power.

Tujuan Proyek dan Dasar Teknis

Anak perusahaan kami di Jerman membeli barang dan menjualnya ke badan hukum Rusia. Sebelumnya, kami menggunakan sistem Tsenit, yang memungkinkan kami untuk menyimpan catatan hanya pada tingkat data keuangan, tetapi tidak dapat mengatasi tugas barang dan logistik. Untuk mengatasi masalah ini, kami memiliki alat tambahan. Data disimpan di beberapa database sekaligus. Semua ini berdampak negatif pada kecepatan dan keandalan seluruh sistem.

Kami ingin sistem akuntansi membantu cabang Jerman mengirimkan laporan, membayar pajak, dan lulus audit. ERP masa lalu hampir tidak menyelesaikan masalah ini, jadi kami memutuskan untuk mengembangkan dan meluncurkan sistem akuntansi kami sendiri. ERP kami seharusnya menggabungkan keuangan, akuntansi dan logistik cabang dalam satu sirkuit. Sebagai perangkat lunak utama, kami memilih Microsoft Dynamics 365 - Dynamics AX sebelumnya, juga dikenal sebagai Axapta.

Komponen bisnis dijelaskan dalam artikel "Teknologi, Outsourcing, dan Mentalitas" . Di sini kita akan berbicara tentang implementasi teknis. Jadi, kami perlu mengotomatiskan beberapa proses bisnis:

Pembelian barang dari pemasok;
Dijual ke badan hukum Rusia;
Integrasi antara D365 dan Ax2012, sistem akuntansi badan hukum Rusia;
;
.

Dalam proyek tersebut, kami memutuskan untuk mengimplementasikan solusi cloud Microsoft Dynamics 365, karena kantor Jerman tidak memiliki infrastruktur IT untuk menyebarkan aplikasi, maupun orang-orang yang akan bertanggung jawab untuk itu. Untuk cabang jarak jauh kecil, skema SaaS optimal, karena memungkinkan Anda untuk mendapatkan semua perangkat lunak dan lingkungan pengembangan yang diperlukan untuk memulai implementasi, segera setelah menandatangani kontrak dengan penyedia.

Kami memiliki tenggat waktu yang ketat: itu perlu untuk menyelesaikan seluruh pengembangan dalam 3 bulan. Karena dalam sistem lama, akuntansi komoditas dilakukan dalam spreadsheet, mentransfer seluruh rangkaian data historis akan menjadi tugas yang mustahil di pertengahan tahun fiskal. Tetapi pada awal periode pelaporan, cukup untuk mentransfer saldo saja. Karena itu, perlu diluncurkan 1 Januari 2019, atau ditunda untuk satu tahun lagi.

Tim kami tidak memiliki pengalaman pengembangan di D365. Terlepas dari semua keadaan, kami berencana untuk memulai proyek ini secepat mungkin. Selanjutnya, saya akan menjelaskan secara terpisah semua tahap perkembangan. Saya akan membahas setiap iterasi secara terperinci: pengalaman apa yang kami dapatkan dan kesalahan apa yang kami buat.

Iterasi pertama, modifikasi pada versi aplikasi 7.3

Untuk memulai bisnis dengan cepat, pertama-tama kami mengembangkan arsitektur aplikasi sederhana. Ini terdiri dari lingkungan pengembangan - lingkungan DevBox 1-tier. Semua komponen diinstal pada satu server / mesin virtual: Application Object Server (AOS), database, Dynamics 365 Retail and Management Reporter.

Untuk pengujian, kami memutuskan untuk menggunakan lingkungan SAT - Lingkungan Uji Terima Standar 2-tier.

Lingkungan 2-tier adalah lingkungan Multi-box, komponen yang diinstal di beberapa layanan cloud dan biasanya mencakup lebih dari satu Application Object Server (AOS). Bahkan, sedekat mungkin dengan lingkungan yang produktif, jadi kami memutuskan untuk mengujinya.

Kami mengerahkan lingkungan pengembangan pertama pada infrastruktur lokal yang ada, tetapi kapasitasnya tidak cukup untuk pengembangan proyek lebih lanjut. Karena itu, ketika dua pengembang lagi bergabung dengan proyek ini, kami dengan cepat dan elegan menggunakan DevBox untuk mereka di cloud.

Lingkungan cloud kami dikelola melalui portal layanan Lifecycle.

Setelah selesai dengan lingkungan, tim mulai berkembang. Kami menyiapkan lingkungan pengembangan pada Visual Studio dan menghubungkannya ke kontrol versi Azure DevOps, setelah sebelumnya membuat cabang untuk mengunduh kode. Selanjutnya, kami mengembangkan pendekatan untuk pengembangan dan transfer perubahan ke lingkungan SAT.

Tidak ada lapisan dalam arsitektur D365, semua kode standar telah ditata dalam model. Modifikasi dipindahkan ke lingkungan SAT melalui portal LCS dengan paket yang berisi model yang dikompilasi.

– , – , .

Untuk mulai dengan, kami menerapkan modifikasi paling sederhana dan paling umum - menambahkan bidang baru ke tabel standar, menginisialisasi ketika membuat catatan, dan mengeluarkan ke bentuk standar.

gambar

Bahkan dalam proyek sederhana seperti itu, ada jenis objek baru. Kami membuat ekstensi untuk menambahkan bidang baru ke tabel standar. Untuk membawa bidang ke formulir standar, kami membuat tipe objek baru - ekstensi untuk formulir. Dan untuk menginisialisasi bidang, kami membuat kelas yang memperluas metode tabel. Dia diizinkan menginisialisasi bidang saat membuat catatan.

gambar

Pada modifikasi sederhana seperti itu, kami melihat salah satu prinsip dasar D365 - bukan perubahan, tetapi perpanjangan objek standar.

Modifikasi selanjutnya adalah penciptaan bentuk baru. Sekarang, ketika membuat formulir, perlu untuk menentukan polanya.Pola adalah pola yang sepenuhnya mendefinisikan struktur desain suatu bentuk. Sampai kami benar-benar mereproduksi struktur yang diletakkan di template, formulir kami tidak akan dikompilasi. Tidak mungkin untuk mengubah templat formulir yang sudah jadi. Karena itu, sebelum memulai pengembangan, kami memikirkan terlebih dahulu bagaimana rupa formulir kami.

gambar

Kami juga mempertahankan kemampuan untuk mengelola desain formulir sendiri. Jika kami menunjukkan pola - Kustom, maka kami bertanggung jawab penuh atas desain formulir: objek apa yang ada di atasnya dan dengan apa yang bersarang.

gambar

Kesimpulan setelah iterasi pertama

1. Jangan mengubah standar, tetapi hanya perlu mengembangkannya.

2. Lihat model jika kita menggunakan objeknya di model lain. Ini adalah salah satu perbedaan antara model D365 dari versi sebelumnya: sebuah objek hanya ada dalam satu model.

3. Ada batasan dalam mengubah properti dari objek standar. Tidak semua properti bidang standar dapat diubah dalam ekstensi objek standar. Misalnya, ekstensi tabel PurchTable adalah bidang LineDisc. Kami dapat mengontrol visibilitas bidang dan label, dan properti seperti wajib dan dapat diedit tidak dapat diubah.

gambar

4. Tidak ada pekerjaan di D365, semuanya dilakukan melalui kelas.

5. Kami mengalahkan model terlalu halus, dan ternyata prinsip kami "satu modifikasi = satu model" tidak berfungsi.

Iterasi kedua dan transisi ke satu model

Pada awal iterasi kedua, kami memiliki dua model yang merujuk satu sama lain. Karena itu, kami tidak dapat lagi mentransfer modifikasi ini secara independen. Oleh karena itu, kami memutuskan untuk bekerja dalam satu model baru, di mana perlu untuk mentransfer semua modifikasi yang ada.

Model dalam D365 adalah kumpulan file sumber yang terletak di direktori terpisah. Saat kompilasi, mereka dikumpulkan di perpustakaan terpisah yang memiliki tautan dengan perpustakaan lain.

Oleh karena itu, menggabungkan ke dalam satu model di DevBox turun untuk mentransfer file dari satu direktori ke direktori lain dan menghapus direktori lama.

Jadi, kami membangun model baru, mendapatkan versi terbarunya di setiap DevBox, dan kemudian terus bekerja dalam kerangka satu model pada lingkungan pengembangan.

Secara alami, kami telah mentransfer beberapa model untuk pengujian pada lingkungan SAT. Karena itu, perlu untuk menghapusnya, dan melepaskan yang baru.

Semua pembaruan pada lingkungan SAT dilakukan dengan menggunakan paket, termasuk penghapusan model. Kami membuat paket dengan model kosong yang perlu dihapus, dan menambahkan skrip dengan nama model ini ke dalamnya. Kemudian kami mengumpulkan paket dengan model baru dan menggulungnya ke lingkungan SAT. Maka, SAT mendapat model baru.

Ketika model digabungkan, kami perhatikan bahwa setiap pengembang menamai ekstensi objek dengan caranya masing-masing. Kami menyetujui aturan untuk memberi nama objek sesuai dengan templat: PurchTable.LamodaModelFormExtension, PurchTableTypeLamodaModelClass_Extension .

Kami juga sepakat dalam tim bahwa untuk satu objek standar kami hanya membuat satu ekstensi dan membuat perubahan untuk itu semua.

Saya memilih beberapa modifikasi menarik yang kami buat pada tahap ini. Mereka menunjukkan kemungkinan pendekatan pengembangan di D365.

Tugas 1

Dalam memposting faktur untuk pesanan penjualan, perlu untuk mengganti nomor faktur dengan nomor dari pesanan. Untuk melakukan ini, kami mendefinisikan kelas standar dengan kemungkinan ekstensi, yang memungkinkan kami untuk melakukan modifikasi ini.

gambar

Kami membuat ekstensi ke kelas SalesInvoiceJourCreate standar. Ada Berikutnya dalam metode getNumAndVoucher () - ini adalah super baru kami, ia berbicara tentang memanggil kode metode standar. Setelah memanggil kode standar, kami mengganti nomor faktur dengan nilai yang diinginkan.

Ini adalah salah satu pendekatan pengembangan kami: menggunakan ekstensi dan menambahkan kode kami sendiri sebelum atau sesudah (sebagai opsi - baik sebelum dan sesudah) pelaksanaan kode standar.

Tugas 2

Itu perlu untuk mengubah tampilan total pesanan pembelian: kelompokkan total dengan nomor faktur pemasok dari garis pesanan pembelian. Dalam hal ini, kami tidak menemukan tempat untuk ekspansi tanpa mengurangi kinerja, jadi kami membuat versi kami sendiri dari hasil tanpa menyentuh yang standar.

gambar

Tugas 3
Modifikasi menarik lainnya: pada baris formulir pemesanan pembelian, perlu menambahkan bidang dari daftar item dengan kemampuan untuk menyaring. Dalam versi sebelumnya, modifikasi itu sama sekali tidak menarik dan diselesaikan dengan hanya menambahkan tabel sebagai sumber data ke formulir dan tumpang tindih kedua metode.

Dalam versi 7.3, kami tidak dapat memperluas metode ke sumber data formulir standar. Untuk melakukan pemfilteran dan tidak membuat formulir baru untuk ini, kami menambahkan tampilan sebagai sumber data ke formulir.

Kemampuan untuk memperluas metode ke sumber data muncul di versi 8.1 dari D365.

gambar

Kesimpulan setelah iterasi kedua

Pada tahap ini, kami telah mengembangkan modifikasi dasar yang diperlukan untuk meluncurkan proyek.

Kami memperkenalkan aturan untuk penamaan ekstensi. Mereka tidak hanya membantu membuat nama-nama itu konsisten dan dapat dimengerti, tetapi lebih jauh menyederhanakan pembaruan, karena nama kami tidak sesuai dengan nama-nama objek standar dari paket layanan.
Saya senang seberapa cepat referensi silang terjadi ketika membangun proyek atau model - sangat mudah diatur dalam versi ini.
Memperbarui model dalam berbagai jenis lingkungan terjadi dengan cara yang berbeda. Kami yakin itu pada contoh penggabungan model.
Sebelum Anda mulai mengembangkan modifikasi baru, Anda perlu mendapatkan versi terbaru dari model, karena pengembangan dilakukan dalam kerangka satu model.
Mekanisme entitas data untuk memuat dan membongkar data di Excel saat memperbarui data pada prod ternyata sangat nyaman. Departemen Data & Analytics kami sekarang menggunakannya untuk mengambil data dari D365 berbasis cloud kami.

Kami melakukan pengembangan utama tepat waktu. Go Live keluar, modelnya ada di prod. Dan kami menghadapi masalah hanya merilis modifikasi yang diuji dalam model. Kami juga ingin memfasilitasi proses debugging selama pengujian modifikasi dan mempercepat pembaruan lingkungan pengujian.

Cara kerjanya sekarang

Dalam iterasi terakhir, kami menambahkan dua lingkungan: membangun dan menguji. Setelah semua lingkungan dikonfigurasi dan diverifikasi, kami menyederhanakan pengujian dan belajar untuk melepaskan hanya modifikasi yang diuji dalam model.

Untuk pengujian, kami menyebarkan lingkungan 1-tier dan menghubungkannya ke cabang pengembangan di sistem kontrol versi. Pembaruan sekarang terdiri dari memperoleh versi terbaru dari model itu sendiri dan perakitannya. Di lingkungan ini, kami memulai debutnya, seperti di DevBox biasa.

gambar

Paket build untuk rilis sekarang dilakukan pada lingkungan build baru. Modifikasi yang diuji ditransfer ke cabang baru di sistem kontrol versi oleh perubahan (paket perubahan diunggah ke sistem kontrol versi), pada prinsip dari awal sampai yang terakhir.

Kemudian kami menyebarkan paket ke lingkungan SAT tempat pengujian pengguna berlangsung, setelah itu kami menjadwalkan paket di portal LCS untuk dirilis pada prod. Jadi kami mengatur proses rilis menggunakan lingkungan build.

Dan kami memutuskan untuk tidak merevisi proyek, tetapi perubahan untuk modifikasi, diunggah ke kontrol versi.

Pembaruan versi cloud pertama

Kami bekerja pada versi cloud, jadi kami perlu diperbarui secara berkala. Pembaruan pertama adalah transisi dari versi 7.3 ke versi 8.0. Butuh sekitar dua minggu.

Tentu saja, kami menciptakan masalah utama bagi diri kami sendiri, tetapi kami juga menang:

Kami tidak langsung menyepakati aturan penamaan objek standar. Di pembaruan pertama, nama objek kami bertepatan dengan nama objek di paket layanan.
Saat memperbarui lingkungan cloud, kami harus keluar dari mesin AOS, jika tidak, proses pembaruan tidak dapat diselesaikan dengan pengguna yang login.
Paket pembaruan untuk lingkungan prod dan SAT perlu dikombinasikan dengan paket model.

Hari ini, memperbarui semua lingkungan kami membutuhkan waktu sekitar 3-4 hari dan berlangsung tanpa keterlibatan pengembang. Kami bahkan dapat merilis rilis pada saat yang sama dengan pembaruan, yang utama adalah build, SAT dan prod memiliki versi yang sama.

Proses pembaruan terdiri dari mengunduh paket pembaruan di portal lcs. The DevBox dan tes diperbarui terlebih dahulu, kemudian build diperbarui, yang terakhir adalah SAT dan prod.

Hasil dari seluruh proyek pertama

Kami telah memperoleh pengalaman dalam membangun arsitektur aplikasi D365.
Mengembangkan pendekatan baru untuk tinjauan kode.
Kami membuat aturan untuk mentransfer basis data ke DevBox (di D365 penting untuk melakukan pengujian awal pada DevBox, dan sekarang kami bahkan menguji pengembang di DevBox).
Menulis pedoman pengembangan di D365.
Belajar untuk berkembang di cloud.

Semua pengalaman ini membantu kami mengembangkan proyek dengan lebih serius. Sekarang kita tahu kemampuan sistem, kita dapat membangun arsitektur dengan lebih tepat, atau lebih tepatnya mengatur tugas. Proses built-up di sekitar proyek membuatnya cukup mudah untuk menghubungkan pengembang yang menulis untuk pertama kalinya di bawah D365.

Pengembangan proyek pertama pada platform Microsoft Dynamics 365 Untuk Keuangan dan Operasi