ProHoster > Blog > Pangangasiwa > Tungkol sa 1C web client

Tungkol sa 1C web client

Ang isa sa mga magagandang tampok ng 1C:Enterprise na teknolohiya ay ang solusyon sa aplikasyon, na binuo gamit ang teknolohiya ng mga pinamamahalaang form, ay maaaring ilunsad kapwa sa isang manipis (maipapatupad) na kliyente para sa Windows, Linux, MacOS X, at bilang isang web client para sa 5 browser - Chrome, Internet Explorer, Firefox, Safari, Edge, at lahat ng ito nang hindi binabago ang source code ng application. Bukod dito, sa panlabas ang application sa thin client at sa browser ay gumagana at halos magkapareho.
Maghanap ng 10 pagkakaiba (2 larawan sa ilalim ng hiwa):

Manipis na window ng kliyente sa Linux:

Tungkol sa 1C web client

Ang parehong window sa web client (sa Chrome browser):

Tungkol sa 1C web client

Bakit tayo gumawa ng web client? Upang ilagay ito medyo pathetically, oras ay nagtakda ng ganoong gawain para sa amin. Ang pagtatrabaho sa Internet ay matagal nang kinakailangan para sa mga aplikasyon sa negosyo. Una, idinagdag namin ang kakayahang magtrabaho sa pamamagitan ng Internet para sa aming manipis na kliyente (ang ilan sa aming mga kakumpitensya, sa pamamagitan ng paraan, ay tumigil dito; ang iba, sa kabaligtaran, ay inabandona ang manipis na kliyente at limitado ang kanilang sarili sa pagpapatupad ng isang web client). Nagpasya kaming bigyan ang aming mga user ng pagkakataon na piliin ang opsyon ng kliyente na pinakaangkop sa kanila.

Tungkol sa 1C web client

Ang pagdaragdag ng web-based na mga kakayahan sa thin client ay isang malaking proyekto na may kumpletong pagbabago sa arkitektura ng client-server. Ang paglikha ng isang web client ay isang ganap na bagong proyekto, simula sa simula.

Pahayag ng problema

Kaya, ang mga kinakailangan sa proyekto: dapat gawin ng web client ang parehong bilang ng thin client, ibig sabihin:

  1. Ipakita ang user interface
  2. Ipatupad ang code ng kliyente na nakasulat sa 1C na wika

Ang user interface sa 1C ay inilarawan sa isang visual na editor, ngunit deklaratibo, nang walang pixel-by-pixel na pag-aayos ng mga elemento; Humigit-kumulang tatlong dosenang uri ng mga elemento ng interface ang ginagamit - mga pindutan, input field (teksto, numeric, petsa/oras), mga listahan, mga talahanayan, mga graph, atbp.

Ang code ng kliyente sa wikang 1C ay maaaring maglaman ng mga tawag sa server, nagtatrabaho sa mga lokal na mapagkukunan (mga file, atbp.), pag-print, at marami pa.

Parehong ginagamit ng thin client (kapag nagtatrabaho sa pamamagitan ng web) at ng web client ang parehong hanay ng mga serbisyo sa web upang makipag-ugnayan sa 1C application server. Ang mga pagpapatupad ng kliyente, siyempre, ay iba - ang manipis na kliyente ay nakasulat sa C++, ang web client ay nakasulat sa JavaScript.

Ang isang maliit na kasaysayan

Nagsimula ang proyekto ng web client noong 2006, na may isang pangkat ng (sa karaniwan) na 5 tao. Sa ilang mga yugto ng proyekto, ang mga developer ay kasangkot upang ipatupad ang partikular na pagpapaandar (spreadsheet na dokumento, mga diagram, atbp.); bilang panuntunan, ito ang parehong mga developer na gumawa ng pagpapaandar na ito sa thin client. Yung. muling isinulat ng mga developer ang mga bahagi sa JavaScript na dati nilang ginawa sa C++.

Sa simula pa lang, tinanggihan namin ang ideya ng anumang awtomatikong (kahit bahagyang) conversion ng C++ thin client code sa JavaScript web client dahil sa malakas na pagkakaiba ng konsepto sa pagitan ng dalawang wika; ang web client ay isinulat sa JavaScript mula sa simula.

Sa mga unang pag-ulit ng proyekto, na-convert ng web client ang client code sa built-in na 1C na wika nang direkta sa JavaScript. Iba ang pagkilos ng thin client - ang code sa built-in na 1C na wika ay pinagsama-sama sa bytecode, at pagkatapos ang bytecode na ito ay binibigyang-kahulugan sa client. Kasunod nito, nagsimula ang web client na gawin ang parehong - una, nagbigay ito ng performance gain, at pangalawa, ginawa nitong posible na pag-isahin ang arkitektura ng manipis at web client.

Ang unang bersyon ng 1C:Enterprise platform na may suporta sa web client ay inilabas noong 2009. Sinuportahan ng web client noong panahong iyon ang 2 browser - Internet Explorer at Firefox. Kasama sa orihinal na mga plano ang suporta para sa Opera, ngunit dahil sa hindi malulutas na mga problema sa oras na iyon sa mga humahawak ng pagsasara ng application sa Opera (hindi posible na subaybayan nang may 100% na katiyakan na nagsasara ang application, at sa sandaling iyon ay isagawa ang pamamaraan ng pagdiskonekta mula sa ang 1C application server) mula sa mga planong ito ay kinailangang iwanan.

Istraktura ng proyekto

Sa kabuuan, ang 1C:Enterprise platform ay may 4 na proyektong nakasulat sa JavaScript:

  1. WebTools – mga shared library na ginagamit ng ibang mga proyekto (kasama rin namin Google Closure Library).
  2. Elemento ng kontrol FormattedDocument (ipinatupad sa JavaScript sa parehong thin client at web client)
  3. Elemento ng kontrol Tagapag-iskedyul (ipinatupad sa JavaScript sa parehong thin client at web client)
  4. Web client

Ang istraktura ng bawat proyekto ay kahawig ng istraktura ng mga proyekto ng Java (o mga .NET na proyekto - alinman ang mas malapit); Mayroon kaming mga namespace, at ang bawat namespace ay nasa isang hiwalay na folder. Sa loob ng folder ay may mga file at mga klase ng namespace. Mayroong humigit-kumulang 1000 mga file sa proyekto ng web client.

Sa istruktura, ang web client ay higit na nahahati sa mga sumusunod na subsystem:

  • Pinamamahalaang interface ng application ng kliyente
    • Pangkalahatang interface ng application (mga menu ng system, mga panel)
    • Interface ng mga pinamamahalaang form, kabilang ang, bukod sa iba pang mga bagay, mga 30 control (mga button, iba't ibang uri ng input field - text, numeric, petsa/oras, atbp., mga talahanayan, listahan, graph, atbp.)

  • Modelo ng object na available sa mga developer sa client (mahigit sa 400 uri sa kabuuan: pinamamahalaang modelo ng object ng interface, mga setting ng layout ng data, conditional styling, atbp.)
  • Interpreter ng built-in na 1C na wika
  • Mga extension ng browser (ginagamit para sa functionality na hindi suportado sa JavaScript)
    • Paggawa gamit ang cryptography
    • Makipagtulungan sa mga file
    • Teknolohiya ng mga panlabas na bahagi, na nagpapahintulot sa mga ito na magamit sa parehong manipis at web client

Mga Tampok ng Pag-unlad

Ang pagpapatupad ng lahat ng nasa itaas sa JavaScript ay hindi madali. Marahil ang 1C web client ay isa sa pinakamalaking client-side na application na nakasulat sa JavaScript - humigit-kumulang 450.000 linya. Aktibo kaming gumagamit ng isang object-oriented na diskarte sa web client code, na nagpapasimple sa pagtatrabaho sa ganoong kalaking proyekto.

Para mabawasan ang laki ng client code, ginamit muna namin ang sarili naming obfuscator, at simula sa platform version 8.3.6 (Oktubre 2014) nagsimula kaming gumamit Google Closure Compiler. Ang epekto ng paggamit sa mga numero – ang laki ng web client framework pagkatapos ng obfuscation:

  • Sariling obfuscator – 1556 kb
  • Google Closure Compiler – 1073 kb

Ang paggamit ng Google Closure Compiler ay nakatulong sa amin na mapabuti ang pagganap ng web client ng 30% kumpara sa sarili naming obfuscator. Bilang karagdagan, ang halaga ng memorya na natupok ng application ay nabawasan ng 15-25% (depende sa browser).

Napakahusay na gumagana ang Google Closure Compiler sa object-oriented na code, kaya ang kahusayan nito para sa web client ay kasing taas ng posible. Gumagawa ang Closure Compiler ng ilang magagandang bagay para sa amin:

  • Static type checking sa yugto ng pagbuo ng proyekto (tinitiyak na saklaw namin ang code ng mga anotasyon ng JSDoc). Ang resulta ay static na pag-type, napakalapit sa antas sa pag-type sa C++. Nakakatulong ito upang mahuli ang isang medyo malaking porsyento ng mga error sa yugto ng pagsasama-sama ng proyekto.
  • Pagbabawas ng laki ng code sa pamamagitan ng obfuscation
  • Ang isang bilang ng mga pag-optimize ng naisakatuparan na code, halimbawa, tulad ng:
    • inline na pagpapalit ng function. Ang pagtawag sa isang function sa JavaScript ay isang medyo mahal na operasyon, at ang mga inline na pagpapalit ng madalas na ginagamit na maliliit na pamamaraan ay makabuluhang nagpapabilis sa code.
    • Nagbibilang ng mga constant sa oras ng pag-compile. Kung ang isang expression ay nakasalalay sa isang pare-pareho, ang aktwal na halaga ng pare-pareho ay papalitan dito

Ginagamit namin ang WebStorm bilang aming web client development environment.

Para sa pagsusuri ng code na ginagamit namin soundQube, kung saan isinasama namin ang mga static na code analyzer. Gamit ang mga analyzer, sinusubaybayan namin ang pagkasira ng kalidad ng source code ng JavaScript at sinusubukan naming pigilan ito.

Tungkol sa 1C web client

Anong mga problema ang nalutas/namin?

Sa panahon ng pagpapatupad ng proyekto, nakatagpo kami ng ilang mga interesanteng problema na kailangan naming lutasin.

Palitan ng data sa server at sa pagitan ng mga bintana

May mga sitwasyon kung saan ang obfuscation ng source code ay maaaring makagambala sa pagpapatakbo ng system. Ang code sa labas ng executable code ng web client, dahil sa obfuscation, ay maaaring may function at mga pangalan ng parameter na naiiba sa mga inaasahan ng aming executable code. Ang panlabas na code para sa amin ay:

  • Ang code na nagmumula sa server sa anyo ng mga istruktura ng data
  • Code para sa isa pang window ng application

Upang maiwasan ang obfuscation kapag nakikipag-ugnayan sa server, ginagamit namin ang tag na @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;
}

At upang maiwasan ang obfuscation kapag nakikipag-ugnayan sa ibang mga window, gumagamit kami ng tinatawag na mga na-export na interface (mga interface kung saan ang lahat ng mga pamamaraan ay na-export).

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

Gumamit kami ng Virtual DOM bago ito naging mainstream)

Tulad ng lahat ng mga developer na nakikitungo sa mga kumplikadong Web UI, mabilis naming napagtanto na ang DOM ay hindi angkop sa pagtatrabaho sa mga dynamic na interface ng gumagamit. Halos kaagad, isang analogue ng Virtual DOM ang ipinatupad upang i-optimize ang trabaho sa UI. Sa panahon ng pagpoproseso ng kaganapan, lahat ng mga pagbabago sa DOM ay iniimbak sa memorya at, kapag nakumpleto lamang ang lahat ng mga operasyon, ang mga naipon na pagbabago ay inilalapat sa puno ng DOM.

Pag-optimize sa web client

Upang gawing mas mabilis ang aming web client, sinusubukan naming gamitin ang mga karaniwang kakayahan ng browser (CSS, atbp.) sa maximum. Kaya, ang form command panel (matatagpuan sa halos lahat ng anyo ng application) ay eksklusibong nai-render gamit ang mga tool sa browser, gamit ang dynamic na layout batay sa CSS.

Tungkol sa 1C web client

Pagsubok

Para sa functional at performance testing, gumagamit kami ng proprietary tool (nakasulat sa Java at C++), pati na rin ang isang suite ng mga pagsubok na binuo sa ibabaw ng Siliniyum.

Ang aming tool ay unibersal - ito ay nagbibigay-daan sa iyo upang subukan ang halos anumang windowed program, at samakatuwid ay angkop para sa pagsubok sa parehong isang manipis na client at isang web client. Itinatala ng tool ang mga aksyon ng user na naglunsad ng 1C application solution sa isang script file. Kasabay nito, ang mga imahe ng nagtatrabaho na lugar ng screen-mga pamantayan-ay naitala. Kapag sinusubaybayan ang mga bagong bersyon ng web client, nilalaro ang mga script nang walang partisipasyon ng user. Sa mga kaso kung saan ang screenshot ay hindi tumutugma sa reference sa anumang hakbang, ang pagsubok ay itinuturing na nabigo, pagkatapos nito ang isang espesyalista sa kalidad ay nagsasagawa ng pagsisiyasat upang matukoy kung ito ay isang error o isang nakaplanong pagbabago sa pag-uugali ng system. Sa kaso ng nakaplanong pag-uugali, ang mga pamantayan ay awtomatikong pinapalitan ng mga bago.

Sinusukat din ng tool ang performance ng application na may katumpakan na hanggang 25 milliseconds. Sa ilang mga kaso, naglo-loop kami ng mga bahagi ng script (halimbawa, paulit-ulit na pagpasok ng order nang maraming beses) upang suriin ang pagkasira ng oras ng pagpapatupad sa paglipas ng panahon. Ang mga resulta ng lahat ng mga sukat ay naitala sa isang log para sa pagsusuri.

Tungkol sa 1C web client
Ang aming tool sa pagsubok at aplikasyon sa ilalim ng pagsubok

Ang aming tool at Selenium ay umakma sa isa't isa; halimbawa, kung binago ng ilang button sa isa sa mga screen ang lokasyon nito, maaaring hindi ito subaybayan ng Selenium, ngunit mapapansin ng aming tool, dahil gumagawa ng pixel-by-pixel na paghahambing ng screenshot sa pamantayan. Nagagawa rin ng tool na subaybayan ang mga problema sa pagpoproseso ng input mula sa keyboard o mouse, dahil ito ang eksaktong ginagawa nito.

Ang mga pagsubok sa parehong mga tool (sa amin at Selenium) ay nagpapatakbo ng mga tipikal na sitwasyon sa trabaho mula sa aming mga solusyon sa aplikasyon. Awtomatikong inilulunsad ang mga pagsubok pagkatapos ng araw-araw na pagbuo ng 1C:Enterprise platform. Kung ang mga script ay mas mabagal (kumpara sa nakaraang build), sinisiyasat namin at niresolba ang sanhi ng pagbagal. Ang aming pamantayan ay simple - ang bagong build ay dapat gumana nang hindi mas mabagal kaysa sa nauna.

Gumagamit ang mga developer ng iba't ibang tool upang siyasatin ang mga insidente ng pagbagal; pangunahing ginagamit Dynatrace AJAX Edition kumpanya ng produksyon DynaTrace. Ang mga log ng pagpapatupad ng problemang operasyon sa nakaraan at bagong mga build ay naitala, pagkatapos ay sinusuri ang mga log. Kasabay nito, ang oras ng pagpapatupad ng mga solong operasyon (sa millisecond) ay maaaring hindi isang mapagpasyang kadahilanan - ang mga proseso ng serbisyo tulad ng koleksyon ng basura ay pana-panahong inilunsad sa browser, maaari silang mag-overlap sa oras ng pagpapatupad ng mga pag-andar at i-distort ang larawan. Ang mga mas may-katuturang parameter sa kasong ito ay ang bilang ng mga tagubilin sa JavaScript na isinagawa, ang bilang ng mga atomic na operasyon sa DOM, atbp. Kung ang bilang ng mga tagubilin/operasyon sa parehong script ay tumaas sa isang bagong bersyon, ito ay halos palaging nangangahulugan ng pagbaba sa pagganap na kailangang itama.

Gayundin, ang isa sa mga dahilan para sa pagbaba sa pagganap ay maaaring ang Google Closure Compiler sa ilang kadahilanan ay hindi nagawang magsagawa ng inline na pagpapalit ng function (halimbawa, dahil ang function ay recursive o virtual). Sa kasong ito, sinusubukan naming itama ang sitwasyon sa pamamagitan ng muling pagsusulat ng source code.

Mga extension ng browser

Kapag ang solusyon sa application ay nangangailangan ng functionality na hindi available sa JavaScript, gumagamit kami ng mga extension ng browser:

  • para sa pagtatrabaho sa mga file
  • para sa pagtatrabaho sa cryptography
  • magtrabaho kasama panlabas na bahagi

Ang aming mga extension ay binubuo ng dalawang bahagi. Ang unang bahagi ay tinatawag na extension ng browser (karaniwang mga extension para sa Chrome at Firefox na nakasulat sa JavaScript), na nakikipag-ugnayan sa pangalawang bahagi - isang binary extension na nagpapatupad ng functionality na kailangan namin. Dapat itong banggitin na sumulat kami ng 3 bersyon ng mga binary extension - para sa Windows, Linux at MacOS. Ang binary extension ay ibinibigay bilang bahagi ng 1C:Enterprise platform at matatagpuan sa 1C application server. Kapag tinawag sa unang pagkakataon mula sa isang web client, dina-download ito sa computer ng kliyente at naka-install sa browser.

Kapag tumatakbo sa Safari, gumagamit ang aming mga extension ng NPAPI; kapag tumatakbo sa Internet Explorer, gumagamit sila ng teknolohiyang ActiveX. Microsoft Edge ay hindi pa sumusuporta sa mga extension, kaya ang web client sa loob nito ay gumagana nang may mga paghihigpit.

Ang karagdagang pag-unlad

Isa sa mga gawain para sa web client development team ay ang karagdagang pag-unlad ng functionality. Ang functionality ng web client ay dapat na magkapareho sa functionality ng thin client; lahat ng bagong functionality ay ipinapatupad nang sabay-sabay sa parehong thin at web client.

Kasama sa iba pang mga gawain ang pagbuo ng arkitektura, refactoring, pagpapabuti ng pagganap at pagiging maaasahan. Halimbawa, ang isa sa mga direksyon ay ang karagdagang paggalaw patungo sa isang asynchronous na modelo ng trabaho. Ang ilan sa mga functionality ng web client ay kasalukuyang binuo sa isang synchronous na modelo ng pakikipag-ugnayan sa server. Ang asynchronous na modelo ay nagiging mas may-katuturan na ngayon sa mga browser (at hindi lamang sa mga browser), at pinipilit tayo nitong baguhin ang web client sa pamamagitan ng pagpapalit ng mga synchronous na tawag ng mga asynchronous (at refactoring ang code nang naaayon). Ang unti-unting paglipat sa isang asynchronous na modelo ay ipinaliwanag sa pamamagitan ng pangangailangang suportahan ang mga inilabas na solusyon at ang kanilang unti-unting pagbagay.

Pinagmulan: www.habr.com

Magdagdag ng komento