Babagan klien web 1C

Salah sawijining fitur apik saka teknologi 1C: Enterprise yaiku solusi aplikasi, sing dikembangake nggunakake teknologi formulir sing dikelola, bisa diluncurake ing klien tipis (bisa dieksekusi) kanggo Windows, Linux, MacOS X, lan minangka klien web kanggo 5 browser - Chrome, Internet Explorer, Firefox, Safari, Edge, lan kabeh iki tanpa ngganti kode sumber aplikasi. Menapa malih, externally aplikasi ing klien tipis lan ing fungsi browser lan katon meh podho rupo.
Temokake 10 bedane (2 gambar ing ngisor potongan):

Jendela klien tipis ing Linux:

Jendhela sing padha ing klien web (ing browser Chrome):

Napa kita nggawe klien web? Kanggo sijine iku rada pathetically, wektu wis nyetel tugas kuwi kanggo kita. Makarya liwat Internet wis suwe dadi prasyarat kanggo aplikasi bisnis. Kaping pisanan, kita nambahake kemampuan kanggo nggarap Internet kanggo klien tipis kita (sawetara pesaing kita, kanthi cara, mandheg ing kono; liyane, sebaliknya, nilar klien tipis lan mbatesi awake dhewe kanggo ngetrapake klien web). Kita mutusake kanggo menehi pangguna kesempatan kanggo milih pilihan klien sing paling cocog karo dheweke.

Nambahake kapabilitas basis web menyang klien tipis minangka proyek gedhe kanthi owah-owahan lengkap ing arsitektur klien-server. Nggawe klien web minangka proyek anyar, diwiwiti saka awal.

Formulasi masalah

Dadi, syarat proyek: klien web kudu nindakake padha karo klien tipis, yaiku:

1. Tampilan antarmuka panganggo
2. Jalanake kode klien sing ditulis nganggo basa 1C

Antarmuka pangguna ing 1C diterangake ing editor visual, nanging kanthi deklaratif, tanpa susunan unsur piksel-by-piksel; Udakara telung rolas jinis unsur antarmuka digunakake - tombol, kolom input (teks, angka, tanggal / wektu), dhaptar, tabel, grafik, lsp.

Kode klien ing basa 1C bisa ngemot panggilan server, nggarap sumber daya lokal (file, lsp), nyetak, lan liya-liyane.

Klien tipis (nalika nggarap web) lan klien web nggunakake layanan web sing padha kanggo komunikasi karo server aplikasi 1C. Implementasi klien, mesthi, beda - klien tipis ditulis ing C ++, klien web ditulis ing JavaScript.

Sawetara sejarah

Proyek klien web diwiwiti ing taun 2006, kanthi tim (rata-rata) 5 wong. Ing tataran tartamtu saka proyek kasebut, pangembang melu ngleksanakake fungsi tartamtu (dokumen spreadsheet, diagram, lan liya-liyane); minangka aturan, iki padha pangembang sing nindakake fungsi iki ing klien tipis. Sing. pangembang maneh nulis komponen ing JavaScript sing sadurunge wis digawe ing C ++.

Wiwit wiwitan, kita nolak ide babagan konversi otomatis (malah parsial) kode klien tipis C ++ menyang klien web JavaScript amarga beda konseptual sing kuat ing antarane rong basa kasebut; klien web iki ditulis ing JavaScript saka ngeruk.

Ing iterasi pisanan proyek kasebut, klien web ngowahi kode klien ing basa 1C sing dibangun langsung menyang JavaScript. Klien tipis tumindak kanthi beda - kode ing basa 1C sing dibangun dikompilasi dadi bytecode, banjur bytecode iki diinterpretasikake ing klien. Sabanjure, klien web wiwit nindakake perkara sing padha - sepisanan, menehi keuntungan kinerja, lan kaping pindho, bisa nggabungake arsitektur klien tipis lan web.

Versi pisanan saka platform 1C: Enterprise kanthi dhukungan klien web dirilis ing 2009. Klien web ing wektu iku ndhukung 2 browser - Internet Explorer lan Firefox. Rencana asli kalebu dhukungan kanggo Opera, nanging amarga masalah sing ora bisa ditanggulangi ing wektu kasebut karo panangan penutupan aplikasi ing Opera (ora bisa dilacak kanthi yakin 100% yen aplikasi ditutup, lan ing wektu kasebut nindakake prosedur pedhot sambungan saka Server aplikasi 1C) saka rencana kasebut kudu ditinggalake.

Struktur proyek

Secara total, platform 1C: Enterprise duwe 4 proyek sing ditulis ing JavaScript:

1. WebTools - perpustakaan sing dienggo bareng sing digunakake dening proyek liyane (uga kalebu Pustaka Panutup Google).
2. Elemen kontrol FormattedDocument (dilaksanakake ing JavaScript ing klien tipis lan klien web)
3. Elemen kontrol Penjadwal (dilaksanakake ing JavaScript ing klien tipis lan klien web)
4. klien web

Struktur saben proyek meh padha karo struktur proyek Jawa (utawa proyek .NET - sing luwih cedhak); Kita duwe ruang jeneng, lan saben ruang jeneng ana ing folder sing kapisah. Ing folder kasebut ana file lan kelas namespace. Ana kira-kira 1000 file ing proyek klien web.

Secara struktural, klien web umume dipérang dadi subsistem ing ngisor iki:

• Antarmuka aplikasi klien sing ngatur
  • Antarmuka aplikasi umum (menu sistem, panel)
  • Antarmuka formulir sing dikelola, kalebu, antara liya, udakara 30 kontrol (tombol, macem-macem jinis kolom input - teks, angka, tanggal / wektu, lsp., tabel, dhaptar, grafik, lsp.)

• Model obyek kasedhiya kanggo pangembang ing klien (luwih saka 400 jinis total: model obyek antarmuka sing dikelola, setelan tata letak data, gaya kondisional, lsp.)
• Interpreter basa 1C sing dibangun
• Ekstensi browser (digunakake kanggo fungsi sing ora didhukung ing JavaScript)
  • Nggarap kriptografi
  • Nggarap file
  • Teknologi komponen eksternal, supaya bisa digunakake ing klien tipis lan web

Fitur Pangembangan

Ngleksanakake kabeh ing ndhuwur ing JavaScript ora gampang. Mungkin klien web 1C minangka salah sawijining aplikasi sisih klien paling gedhe sing ditulis ing JavaScript - sekitar 450.000 baris. Kita aktif nggunakake pendekatan berorientasi obyek ing kode klien web, sing nyederhanakake nggarap proyek gedhe kasebut.

Kanggo nyilikake ukuran kode klien, kita pisanan nggunakake obfuscator kita dhewe, lan miwiti karo versi platform 8.3.6 (Oktober 2014) kita wiwit nggunakake Google Closure Compiler. Efek panggunaan ing angka - ukuran kerangka klien web sawise kebingungan:

• Obfuscator dhewe - 1556 kb
• Google Closure Compiler - 1073 kb

Nggunakake Google Closure Compiler mbantu kita ningkatake kinerja klien web kanthi 30% dibandhingake karo obfuscator kita dhewe. Kajaba iku, jumlah memori sing dikonsumsi aplikasi wis suda 15-25% (gumantung saka browser).

Google Closure Compiler bisa digunakake kanthi apik karo kode berorientasi obyek, saéngga efisiensi kanggo klien web sabisa-bisa. Closure Compiler nindakake sawetara perkara sing apik kanggo kita:

• Pemeriksa jinis statis ing tataran mbangun proyek (mesthekake yen kita nutupi kode kasebut nganggo anotasi JSDoc). Asil punika ngetik statis, banget cedhak ing tingkat kanggo ngetik ing C ++. Iki mbantu nyekel persentase kesalahan sing cukup gedhe ing tahap kompilasi proyek.
• Ngurangi ukuran kode liwat obfuscation
• Sawetara optimasi kode sing dieksekusi, contone, kayata:
  • substitusi fungsi inline. Nelpon fungsi ing JavaScript minangka operasi sing cukup larang, lan substitusi inline saka cara cilik sing kerep digunakake kanthi signifikan nyepetake kode kasebut.
  • Ngitung konstanta ing wektu kompilasi. Yen ekspresi gumantung saka konstanta, nilai nyata saka konstanta kasebut bakal diganti

Kita nggunakake WebStorm minangka lingkungan pangembangan klien web kita.

Kanggo analisis kode kita nggunakake soundQube, ing ngendi kita nggabungake penganalisa kode statis. Nggunakake analisa, kita ngawasi degradasi kualitas kode sumber JavaScript lan nyoba kanggo nyegah.

Masalah apa sing wis kita rampungake?

Sajrone implementasine proyek kasebut, kita nemoni sawetara masalah sing menarik sing kudu dirampungake.

Exchange data karo server lan antarane windows

Ana kahanan nalika obfuscation kode sumber bisa ngganggu operasi sistem. Kode njaba kanggo kode eksekusi klien web, amarga kebingungan, bisa uga duwe fungsi lan jeneng parameter sing beda karo sing dikarepake kode eksekusi. Kode eksternal kanggo kita yaiku:

• Kode teka saka server ing wangun struktur data
• Kode kanggo jendhela aplikasi liyane

Kanggo ngindhari obfuscation nalika sesambungan karo server, kita nggunakake tag @expose:

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

Lan supaya ora obfuscation nalika sesambungan karo windows liyane, kita nggunakake supaya disebut-antarmuka diekspor (antarmuka kang kabeh cara sing diekspor).

/**
 * Экспортируемый интерфейс контрола DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 * Перемещает выделение на 1 вперед или назад
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 * Перемещает выделение в начало или конец
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

Kita nggunakake Virtual DOM sadurunge dadi mainstream)

Kaya kabeh pangembang sing ngurusi UI Web sing rumit, kita kanthi cepet nyadari yen DOM kurang cocok kanggo nggarap antarmuka pangguna sing dinamis. Meh langsung, analog Virtual DOM dileksanakake kanggo ngoptimalake karya karo UI. Sajrone pangolahan acara, kabeh owah-owahan DOM disimpen ing memori lan, mung nalika kabeh operasi rampung, owah-owahan akumulasi ditrapake ing wit DOM.

Ngoptimalake klien web

Kanggo nggawe klien web bisa luwih cepet, kita nyoba nggunakake kapabilitas browser standar (CSS, lsp) kanthi maksimal. Mangkono, panel printah formulir (dumunung ing meh kabeh wangun aplikasi) digawe sacara eksklusif nggunakake alat browser, nggunakake tata letak dinamis adhedhasar CSS.

Tes

Kanggo tes fungsional lan kinerja, kita nggunakake alat proprietary (ditulis ing Jawa lan C++), uga suite tes sing dibangun ing ndhuwur selenium.

Alat kita universal - ngidini sampeyan nyoba meh kabeh program windowed, lan mulane cocog kanggo nguji klien tipis lan klien web. Alat kasebut nyathet tumindak pangguna sing ngluncurake solusi aplikasi 1C dadi file skrip. Ing wektu sing padha, gambar area kerja layar-standar-direkam. Nalika ngawasi versi anyar saka klien web, skrip diputer tanpa partisipasi pangguna. Ing kasus nalika gambar ora cocog karo referensi ing langkah apa wae, tes kasebut dianggep gagal, sawise iku spesialis kualitas nindakake investigasi kanggo nemtokake manawa iki minangka kesalahan utawa owah-owahan sing direncanakake ing prilaku sistem. Ing kasus prilaku sing direncanakake, standar kasebut kanthi otomatis diganti karo sing anyar.

Alat kasebut uga ngukur kinerja aplikasi kanthi akurasi nganti 25 milidetik. Ing sawetara kasus, kita daur ulang bagean script (contone, mbaleni entri pesenan kaping pirang-pirang) kanggo njelasno degradasi wektu eksekusi liwat wektu. Asil kabeh pangukuran dicathet ing log kanggo analisis.

Alat tes lan aplikasi sing diuji

Alat kita lan Selenium nglengkapi saben liyane; contone,, yen sawetara tombol ing salah siji layar wis diganti lokasi, Selenium bisa uga ora nglacak iki, nanging alat kita bakal sok dong mirsani, amarga ndadekake perbandingan piksel-by-piksel saka gambar karo standar. Alat kasebut uga bisa nglacak masalah karo ngolah input saka keyboard utawa mouse, amarga iki pancene ngasilake.

Tes ing loro alat (kita lan Selenium) mbukak skenario kerja khas saka solusi aplikasi kita. Tes diluncurake kanthi otomatis sawise mbangun saben dina saka platform 1C: Enterprise. Yen skrip luwih alon (dibandhingake karo bangunan sadurunge), kita nyelidiki lan mutusake panyebab kalem kasebut. Kriteria kita gampang - bangunan anyar kudu ora luwih alon tinimbang sing sadurunge.

Pangembang nggunakake macem-macem alat kanggo neliti kedadean slowdown; utamané dipigunakaké Dynatrace AJAX Edition perusahaan produksi DynaTrace. Log eksekusi operasi bermasalah ing bangunan sadurunge lan anyar direkam, banjur log dianalisis. Ing wektu sing padha, wektu eksekusi operasi siji (ing milidetik) bisa uga ora dadi faktor sing nemtokake - proses layanan kayata pengumpulan sampah diluncurake sacara periodik ing browser, bisa tumpang tindih karo wektu eksekusi fungsi lan ngrusak gambar. Parameter sing luwih relevan ing kasus iki yaiku jumlah instruksi JavaScript sing dieksekusi, jumlah operasi atom ing DOM, lsp. Yen jumlah instruksi / operasi ing script padha wis tambah ing versi anyar, iki meh tansah tegese tepak ing kinerja sing kudu didandani.

Kajaba iku, salah sawijining sebab penurunan kinerja bisa uga amarga Google Closure Compiler ora bisa nindakake substitusi inline saka fungsi kasebut (contone, amarga fungsi kasebut rekursif utawa virtual). Ing kasus iki, kita nyoba mbenerake kahanan kanthi nulis ulang kode sumber.

Ekstensi browser

Nalika solusi aplikasi mbutuhake fungsi sing ora kasedhiya ing JavaScript, kita nggunakake ekstensi browser:

• kanggo nggarap file
• kanggo nggarap kriptografi
• nggarap komponen njaba

Ekstensi kita kalebu rong bagean. Bagean pisanan yaiku apa sing diarani ekstensi browser (biasane ekstensi kanggo Chrome lan Firefox ditulis ing JavaScript), sing sesambungan karo bagean kapindho - ekstensi binar sing ngetrapake fungsi sing kita butuhake. Sampeyan kudu kasebut yen kita nulis 3 versi ekstensi binar - kanggo Windows, Linux lan MacOS. Ekstensi binar diwenehake minangka bagéan saka platform 1C: Enterprise lan dumunung ing server aplikasi 1C. Nalika pisanan diarani saka klien web, diundhuh menyang komputer klien lan diinstal ing browser.

Nalika mlaku ing Safari, ekstensi kita nggunakake NPAPI; nalika mlaku ing Internet Explorer, nggunakake teknologi ActiveX. Microsoft Edge durung ndhukung ekstensi, mula klien web kasebut bisa digunakake kanthi watesan.

Pangembangan luwih

Salah sawijining tugas kanggo tim pangembangan klien web yaiku pangembangan fungsionalitas luwih lanjut. Fungsi klien web kudu padha karo fungsi klien tipis; kabeh fungsi anyar diimplementasikake bebarengan ing klien tipis lan web.

Tugas liyane kalebu ngembangake arsitektur, refactoring, nambah kinerja lan linuwih. Contone, salah sawijining arah yaiku gerakan luwih maju menyang model kerja sing ora sinkron. Sawetara fungsi klien web saiki dibangun ing model interaksi sinkron karo server. Model asinkron saiki dadi luwih relevan ing browser (lan ora mung ing browser), lan iki meksa kita ngowahi klien web kanthi ngganti panggilan sinkron karo sing ora sinkron (lan refactoring kode kasebut). Transisi bertahap menyang model asinkron diterangake kanthi kabutuhan kanggo ndhukung solusi sing dirilis lan adaptasi bertahap.

Source: www.habr.com