ProHoster > Blog > Pentadbiran > Mengenai klien web 1C

Mengenai klien web 1C

Salah satu ciri bagus teknologi 1C:Enterprise ialah penyelesaian aplikasi, yang dibangunkan menggunakan teknologi borang terurus, boleh dilancarkan dalam kedua-dua klien nipis (boleh laku) untuk Windows, Linux, MacOS X dan sebagai klien web untuk 5 penyemak imbas - Chrome, Internet Explorer, Firefox, Safari, Edge, dan semua ini tanpa mengubah kod sumber aplikasi. Selain itu, secara luaran aplikasi dalam thin client dan dalam fungsi pelayar dan kelihatan hampir sama.
Cari 10 perbezaan (2 gambar di bawah potongan):

Tetingkap klien nipis pada Linux:

Mengenai klien web 1C

Tetingkap yang sama dalam klien web (dalam penyemak imbas Chrome):

Mengenai klien web 1C

Mengapa kami membuat klien web? Untuk meletakkannya agak menyedihkan, masa telah menetapkan tugas sedemikian untuk kita. Bekerja melalui Internet telah lama menjadi prasyarat untuk aplikasi perniagaan. Mula-mula, kami menambah keupayaan untuk bekerja melalui Internet untuk klien tipis kami (sebilangan pesaing kami, dengan cara itu, berhenti di sana; yang lain, sebaliknya, meninggalkan klien tipis dan menghadkan diri mereka untuk melaksanakan klien web). Kami memutuskan untuk memberi pengguna kami peluang untuk memilih pilihan pelanggan yang paling sesuai dengan mereka.

Mengenai klien web 1C

Menambah keupayaan berasaskan web pada klien nipis merupakan projek besar dengan perubahan lengkap dalam seni bina pelayan-pelanggan. Mencipta klien web ialah projek yang sama sekali baharu, bermula dari awal.

Pernyataan masalah

Jadi, keperluan projek: klien web mesti melakukan perkara yang sama seperti klien tipis, iaitu:

  1. Paparkan antara muka pengguna
  2. Laksanakan kod klien yang ditulis dalam bahasa 1C

Antara muka pengguna dalam 1C diterangkan dalam editor visual, tetapi secara deklaratif, tanpa susunan elemen piksel demi piksel; Kira-kira tiga dozen jenis elemen antara muka digunakan - butang, medan input (teks, angka, tarikh/masa), senarai, jadual, graf, dsb.

Kod pelanggan dalam bahasa 1C boleh mengandungi panggilan pelayan, bekerja dengan sumber tempatan (fail, dll.), percetakan dan banyak lagi.

Kedua-dua klien nipis (apabila bekerja melalui web) dan klien web menggunakan set perkhidmatan web yang sama untuk berkomunikasi dengan pelayan aplikasi 1C. Pelaksanaan pelanggan, sudah tentu, berbeza - klien nipis ditulis dalam C++, klien web ditulis dalam JavaScript.

Sedikit sejarah

Projek pelanggan web bermula pada tahun 2006, dengan pasukan (secara purata) 5 orang. Pada peringkat tertentu projek, pembangun terlibat untuk melaksanakan fungsi tertentu (dokumen hamparan, gambar rajah, dsb.); sebagai peraturan, ini adalah pembangun yang sama yang melakukan fungsi ini dalam klien nipis. Itu. pembangun menulis semula komponen dalam JavaScript yang telah mereka cipta sebelum ini dalam C++.

Sejak awal lagi, kami menolak idea sebarang penukaran automatik (walaupun separa) kod klien nipis C++ ke dalam klien web JavaScript kerana perbezaan konseptual yang kukuh antara kedua-dua bahasa; klien web telah ditulis dalam JavaScript dari awal.

Dalam lelaran pertama projek, klien web menukar kod klien dalam bahasa 1C terbina dalam terus ke JavaScript. Pelanggan nipis bertindak secara berbeza - kod dalam bahasa 1C terbina dalam disusun menjadi kod bait, dan kemudian kod bait ini ditafsirkan pada klien. Selepas itu, pelanggan web mula melakukan perkara yang sama - pertama, ia memberikan keuntungan prestasi, dan kedua, ia memungkinkan untuk menyatukan seni bina pelanggan nipis dan web.

Versi pertama platform 1C:Enterprise dengan sokongan pelanggan web telah dikeluarkan pada tahun 2009. Pelanggan web pada masa itu menyokong 2 pelayar - Internet Explorer dan Firefox. Pelan asal termasuk sokongan untuk Opera, tetapi disebabkan masalah yang tidak dapat diatasi pada masa itu dengan pengendali penutupan aplikasi dalam Opera (tidak mungkin untuk menjejaki dengan pasti 100% bahawa aplikasi ditutup, dan pada masa itu menjalankan prosedur pemutusan sambungan daripada pelayan aplikasi 1C) daripada rancangan ini terpaksa ditinggalkan.

Struktur projek

Secara keseluruhan, platform 1C:Enterprise mempunyai 4 projek yang ditulis dalam JavaScript:

  1. WebTools – perpustakaan kongsi yang digunakan oleh projek lain (kami turut sertakan Pustaka Penutupan Google).
  2. Elemen kawalan FormattedDocument (dilaksanakan dalam JavaScript dalam kedua-dua klien nipis dan klien web)
  3. Elemen kawalan Penjadual (dilaksanakan dalam JavaScript dalam kedua-dua klien nipis dan klien web)
  4. Pelanggan web

Struktur setiap projek menyerupai struktur projek Java (atau projek .NET - yang mana lebih dekat); Kami mempunyai ruang nama, dan setiap ruang nama berada dalam folder yang berasingan. Di dalam folder terdapat fail dan kelas ruang nama. Terdapat kira-kira 1000 fail dalam projek klien web.

Secara struktur, klien web sebahagian besarnya dibahagikan kepada subsistem berikut:

  • Antara muka aplikasi klien terurus
    • Antara muka aplikasi umum (menu sistem, panel)
    • Antara muka borang terurus, termasuk, antara lain, kira-kira 30 kawalan (butang, pelbagai jenis medan input - teks, angka, tarikh/masa, dsb., jadual, senarai, graf, dsb.)

  • Model objek tersedia untuk pembangun pada klien (jumlah lebih daripada 400 jenis: model objek antara muka terurus, tetapan susun atur data, penggayaan bersyarat, dsb.)
  • Penterjemah bahasa 1C terbina dalam
  • Sambungan penyemak imbas (digunakan untuk fungsi yang tidak disokong dalam JavaScript)
    • Bekerja dengan kriptografi
    • Bekerja dengan fail
    • Teknologi komponen luaran, membolehkan mereka digunakan dalam kedua-dua klien nipis dan web

Ciri-ciri Pembangunan

Melaksanakan semua perkara di atas dalam JavaScript bukanlah mudah. Mungkin klien web 1C ialah salah satu aplikasi sisi klien terbesar yang ditulis dalam JavaScript - kira-kira 450.000 baris. Kami secara aktif menggunakan pendekatan berorientasikan objek dalam kod klien web, yang memudahkan kerja dengan projek yang begitu besar.

Untuk meminimumkan saiz kod pelanggan, kami mula-mula menggunakan obfuscator kami sendiri, dan bermula dengan versi platform 8.3.6 (Oktober 2014) kami mula menggunakan Penyusun Penutupan Google. Kesan penggunaan dalam nombor – saiz rangka kerja klien web selepas kekeliruan:

  • Obfuscator sendiri – 1556 kb
  • Penyusun Penutupan Google – 1073 kb

Menggunakan Google Closure Compiler membantu kami meningkatkan prestasi klien web sebanyak 30% berbanding dengan obfuscator kami sendiri. Di samping itu, jumlah memori yang digunakan oleh aplikasi telah berkurangan sebanyak 15-25% (bergantung pada penyemak imbas).

Pengkompil Penutupan Google berfungsi dengan baik dengan kod berorientasikan objek, jadi kecekapannya untuk klien web adalah setinggi mungkin. Pengkompil Penutup melakukan beberapa perkara yang baik untuk kami:

  • Pemeriksaan jenis statik pada peringkat binaan projek (memastikan bahawa kami menutup kod dengan anotasi JSDoc). Hasilnya ialah menaip statik, sangat hampir dengan tahap menaip dalam C++. Ini membantu untuk menangkap peratusan ralat yang agak besar pada peringkat penyusunan projek.
  • Mengurangkan saiz kod melalui kekeliruan
  • Beberapa pengoptimuman kod yang dilaksanakan, sebagai contoh, seperti:
    • penggantian fungsi sebaris. Memanggil fungsi dalam JavaScript adalah operasi yang agak mahal, dan penggantian sebaris kaedah kecil yang kerap digunakan mempercepatkan kod dengan ketara.
    • Mengira pemalar pada masa penyusunan. Jika ungkapan bergantung pada pemalar, nilai sebenar pemalar akan digantikan ke dalamnya

Kami menggunakan WebStorm sebagai persekitaran pembangunan pelanggan web kami.

Untuk analisis kod yang kami gunakan soundQube, di mana kami menyepadukan penganalisis kod statik. Menggunakan penganalisis, kami memantau kemerosotan kualiti kod sumber JavaScript dan cuba menghalangnya.

Mengenai klien web 1C

Apakah masalah yang telah/sedang kita selesaikan?

Semasa pelaksanaan projek, kami menghadapi beberapa masalah menarik yang perlu kami selesaikan.

Bertukar data dengan pelayan dan antara tingkap

Terdapat situasi di mana kekeliruan kod sumber boleh mengganggu operasi sistem. Kod luaran kepada kod boleh laku klien web, disebabkan oleh kekeliruan, mungkin mempunyai nama fungsi dan parameter yang berbeza daripada nama yang dijangkakan oleh kod boleh laku kami. Kod luaran untuk kami ialah:

  • Kod yang datang dari pelayan dalam bentuk struktur data
  • Kod untuk tetingkap aplikasi lain

Untuk mengelakkan kekeliruan semasa berinteraksi dengan pelayan, kami menggunakan teg @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;
}

Dan untuk mengelakkan kekeliruan apabila berinteraksi dengan tetingkap lain, kami menggunakan antara muka yang dipanggil dieksport (antara muka di mana semua kaedah dieksport).

/**
 * ЭкспортируСмый интСрфСйс ΠΊΠΎΠ½Ρ‚Ρ€ΠΎΠ»Π° 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 (){}

Kami menggunakan DOM Maya sebelum ia menjadi arus perdana)

Seperti semua pembangun yang berurusan dengan UI Web yang kompleks, kami dengan cepat menyedari bahawa DOM kurang sesuai untuk bekerja dengan antara muka pengguna dinamik. Hampir serta-merta, analog DOM Maya telah dilaksanakan untuk mengoptimumkan kerja dengan UI. Semasa pemprosesan acara, semua perubahan DOM disimpan dalam ingatan dan, hanya apabila semua operasi selesai, perubahan terkumpul digunakan pada pepohon DOM.

Mengoptimumkan klien web

Untuk menjadikan pelanggan web kami berfungsi dengan lebih pantas, kami cuba menggunakan keupayaan pelayar standard (CSS, dsb.) secara maksimum. Oleh itu, panel arahan borang (terletak pada hampir setiap bentuk aplikasi) dipaparkan secara eksklusif menggunakan alat penyemak imbas, menggunakan reka letak dinamik berdasarkan CSS.

Mengenai klien web 1C

Ujian

Untuk ujian kefungsian dan prestasi, kami menggunakan alat proprietari (ditulis dalam Java dan C++), serta set ujian yang dibina di atas Selenium.

Alat kami adalah universal - ia membolehkan anda menguji hampir mana-mana program bertingkap, dan oleh itu sesuai untuk menguji kedua-dua klien nipis dan klien web. Alat ini merekodkan tindakan pengguna yang melancarkan penyelesaian aplikasi 1C ke dalam fail skrip. Pada masa yang sama, imej kawasan kerja skrinβ€”standardβ€”dirakam. Apabila memantau versi baharu klien web, skrip dimainkan tanpa penyertaan pengguna. Dalam kes di mana tangkapan skrin tidak sepadan dengan rujukan pada mana-mana langkah, ujian itu dianggap gagal, selepas itu pakar kualiti menjalankan penyiasatan untuk menentukan sama ada ini ralat atau perubahan yang dirancang dalam tingkah laku sistem. Dalam kes tingkah laku yang dirancang, piawaian secara automatik digantikan dengan yang baharu.

Alat ini juga mengukur prestasi aplikasi dengan ketepatan sehingga 25 milisaat. Dalam sesetengah kes, kami menggelungkan bahagian skrip (contohnya, mengulangi entri pesanan beberapa kali) untuk menganalisis kemerosotan masa pelaksanaan dari semasa ke semasa. Keputusan semua ukuran direkodkan dalam log untuk analisis.

Mengenai klien web 1C
Alat dan aplikasi ujian kami sedang diuji

Alat kami dan Selenium saling melengkapi; sebagai contoh, jika beberapa butang pada salah satu skrin telah menukar lokasinya, Selenium mungkin tidak menjejaki perkara ini, tetapi alat kami akan menyedarinya, kerana membuat perbandingan piksel demi piksel tangkapan skrin dengan standard. Alat ini juga dapat menjejaki masalah dengan memproses input daripada papan kekunci atau tetikus, kerana ini adalah apa yang dihasilkan semula.

Ujian pada kedua-dua alatan (kami dan Selenium) menjalankan senario kerja biasa daripada penyelesaian aplikasi kami. Ujian dilancarkan secara automatik selepas binaan harian platform 1C:Enterprise. Jika skrip lebih perlahan (berbanding binaan sebelumnya), kami menyiasat dan menyelesaikan punca kelembapan. Kriteria kami adalah mudah - binaan baharu seharusnya berfungsi tidak lebih perlahan daripada yang sebelumnya.

Pembangun menggunakan alat yang berbeza untuk menyiasat insiden kelembapan; digunakan terutamanya Edisi AJAX Dynatrace syarikat pengeluaran DynaTrace. Log pelaksanaan operasi bermasalah pada binaan sebelumnya dan baharu direkodkan, kemudian log dianalisis. Pada masa yang sama, masa pelaksanaan operasi tunggal (dalam milisaat) mungkin bukan faktor penentu - proses perkhidmatan seperti pengumpulan sampah dilancarkan secara berkala dalam penyemak imbas, mereka boleh bertindih dengan masa pelaksanaan fungsi dan memesongkan gambar. Parameter yang lebih berkaitan dalam kes ini ialah bilangan arahan JavaScript yang dilaksanakan, bilangan operasi atom pada DOM, dsb. Jika bilangan arahan/operasi dalam skrip yang sama telah meningkat dalam versi baharu, ini hampir selalu bermakna penurunan dalam prestasi yang perlu diperbetulkan.

Selain itu, salah satu sebab penurunan prestasi mungkin kerana Google Closure Compiler atas sebab tertentu tidak dapat melakukan penggantian sebaris fungsi (contohnya, kerana fungsi itu adalah rekursif atau maya). Dalam kes ini, kami cuba membetulkan keadaan dengan menulis semula kod sumber.

Sambungan penyemak imbas

Apabila penyelesaian aplikasi memerlukan fungsi yang tidak tersedia dalam JavaScript, kami menggunakan sambungan penyemak imbas:

  • untuk bekerja dengan fail
  • untuk bekerja dengan kriptografi
  • bekerja dengan komponen luaran

Sambungan kami terdiri daripada dua bahagian. Bahagian pertama ialah apa yang dipanggil sambungan penyemak imbas (biasanya sambungan untuk Chrome dan Firefox ditulis dalam JavaScript), yang berinteraksi dengan bahagian kedua - sambungan binari yang melaksanakan fungsi yang kami perlukan. Perlu dinyatakan bahawa kami menulis 3 versi sambungan binari - untuk Windows, Linux dan MacOS. Sambungan binari dibekalkan sebagai sebahagian daripada platform 1C:Enterprise dan terletak pada pelayan aplikasi 1C. Apabila dipanggil buat kali pertama daripada klien web, ia dimuat turun ke komputer klien dan dipasang dalam penyemak imbas.

Apabila berjalan dalam Safari, sambungan kami menggunakan NPAPI; apabila berjalan dalam Internet Explorer, sambungan kami menggunakan teknologi ActiveX. Microsoft Edge belum lagi menyokong sambungan, jadi klien web di dalamnya berfungsi dengan sekatan.

Perkembangan selanjutnya

Salah satu tugas untuk pasukan pembangunan pelanggan web ialah pembangunan fungsi selanjutnya. Kefungsian klien web hendaklah sama dengan kefungsian klien nipis; semua fungsi baharu dilaksanakan secara serentak dalam kedua-dua klien nipis dan web.

Tugas lain termasuk membangunkan seni bina, pemfaktoran semula, meningkatkan prestasi dan kebolehpercayaan. Sebagai contoh, salah satu arah adalah pergerakan selanjutnya ke arah model kerja tak segerak. Beberapa kefungsian klien web pada masa ini dibina pada model interaksi segerak dengan pelayan. Model tak segerak kini menjadi lebih relevan dalam penyemak imbas (dan bukan sahaja dalam penyemak imbas), dan ini memaksa kami mengubah suai klien web dengan menggantikan panggilan segerak dengan panggilan tak segerak (dan memfaktorkan semula kod dengan sewajarnya). Peralihan beransur-ansur kepada model tak segerak dijelaskan oleh keperluan untuk menyokong penyelesaian yang dikeluarkan dan penyesuaian beransur-ansur mereka.

Sumber: www.habr.com

Tambah komen