ProHoster > Blog > Administrazioa > 1C web bezeroari buruz

1C web bezeroari buruz

1C:Enterprise teknologiaren ezaugarri politetako bat da aplikazioen irtenbidea, kudeatutako inprimakien teknologia erabiliz garatutakoa, Windows, Linux, MacOS X bezero mehe (exekutagarria) eta 5 arakatzailerako web bezero gisa abiarazi daitekeela. Chrome, Internet Explorer, Firefox, Safari, Edge, eta hori guztia aplikazioaren iturburu kodea aldatu gabe. Gainera, kanpotik bezero mehean eta arakatzailean aplikazioak funtzionatzen du eta itxura ia berdina du.
Aurkitu 10 desberdintasun (2 irudi ebaki azpian):

Bezero mehearen leihoa Linux-en:

1C web bezeroari buruz

Web bezeroaren leiho bera (Chrome arakatzailean):

1C web bezeroari buruz

Zergatik egin genuen web bezero bat? Patetiko samarra esateko, denborak ezarri digu halako zeregina. Internet bidez lan egitea negozio-aplikazioetarako ezinbesteko baldintza da aspalditik. Lehenik eta behin, gure bezero meheari Internet bidez lan egiteko gaitasuna gehitu genion (gure lehiakide batzuk, bide batez, hor gelditu ziren; beste batzuk, aitzitik, bezero mehea alde batera utzi eta web bezero bat ezartzera mugatu ziren). Gure erabiltzaileei hobekien egokitzen zaien bezero aukera aukeratzeko aukera ematea erabaki dugu.

1C web bezeroari buruz

Bezero meheari web-oinarritutako gaitasunak gehitzea proiektu handia izan zen bezero-zerbitzariaren arkitekturan erabateko aldaketarekin. Web bezero bat sortzea proiektu guztiz berria da, hutsetik hasita.

Arazoaren formulazioa

Beraz, proiektuaren eskakizunak: web bezeroak bezero mehearen berdina egin behar du, hots:

  1. Erabiltzailearen interfazea bistaratu
  2. Exekutatu bezero-kodea 1C hizkuntzan idatzita

1C-ko erabiltzaile-interfazea editore bisual batean deskribatzen da, baina modu deklaratiboan, elementuen pixelez pixel antolamendurik gabe; Hiru dozena inguru interfaze-elementu mota erabiltzen dira: botoiak, sarrera-eremuak (testua, zenbakizkoa, data/ordua), zerrendak, taulak, grafikoak, etab.

1C hizkuntzan bezero-kodeak zerbitzari-deiak izan ditzake, tokiko baliabideekin (fitxategiak, etab.), inprimaketa eta askoz gehiago lantzea.

Bezero meheak (web bidez lan egiten dutenean) eta web bezeroak web zerbitzu multzo bera erabiltzen dute 1C aplikazio-zerbitzariarekin komunikatzeko. Bezeroaren inplementazioak, noski, desberdinak dira: bezero mehea C++-n idatzita dago, web-bezeroa JavaScript-en idatzita.

Historia apur bat

Web bezero proiektua 2006an hasi zen, 5 laguneko (batez beste) talde batekin. Proiektuaren zenbait fasetan, garatzaileek parte hartu zuten funtzionalitate zehatzak ezartzeko (kalkulu-orrien dokumentua, diagramak, etab.); normalean, bezero mehean funtzionalitate hori egin zuten garatzaile berberak ziren. Horiek. Garatzaileek C++-n sortu zituzten osagaiak berriro idatzi zituzten JavaScript-en.

Hasiera-hasieratik, C++ bezero meheen kodea JavaScript web bezero bihurtzearen ideia automatikoki (nahiz eta partziala ere) baztertu genuen bi hizkuntzen arteko desberdintasun kontzeptual handiak zirela eta; web-bezeroa JavaScript-en idatzi zen hutsetik.

Proiektuaren lehen iterazioetan, web-bezeroak 1C hizkuntzan integratutako bezero-kodea zuzenean JavaScript bihurtu zuen. Bezero meheak modu ezberdinean jokatzen du - 1C hizkuntza integratuan dagoen kodea bytecode batean konpilatzen da, eta, ondoren, bytecode hau bezeroarengan interpretatzen da. Ondoren, web-bezeroa gauza bera egiten hasi zen: lehenik eta behin, errendimendu-irabazi bat eman zuen eta, bigarrenik, bezero meheen eta web-bezeroen arkitektura bateratzea ahalbidetu zuen.

1C:Enterprise plataformaren lehen bertsioa web bezeroaren laguntzarekin 2009an kaleratu zen. Orduko web bezeroak 2 arakatzaile onartzen zituen: Internet Explorer eta Firefox. Jatorrizko planek Operarako laguntza barne hartzen zuten, baina une hartan Operan aplikazioak ixteko kudeatzaileek zituzten arazo gaindiezinak zirela eta (ez zen posible % 100eko ziurtasunarekin jarraitu aplikazioa ixten ari zela, eta une horretan deskonexio prozedura burutu. 1C aplikazio zerbitzaria) plan horietatik alde batera utzi behar izan zuten.

Proiektuaren egitura

Guztira, 1C:Enterprise plataformak JavaScriptn idatzitako 4 proiektu ditu:

  1. WebTools - beste proiektu batzuek erabiltzen dituzten liburutegi partekatuak (ere sartzen dugu Google Closure Liburutegia).
  2. Kontrol-elementua FormateatutakoDokumentua (JavaScript-en inplementatuta bezero mehean eta web bezeroan)
  3. Kontrol-elementua Antolatzailea (JavaScript-en inplementatuta bezero mehean eta web bezeroan)
  4. Web bezeroa

Proiektu bakoitzaren egiturak Java proiektuen (edo .NET proiektuen) egituraren antza du; Izen-espazioak ditugu, eta izen-espazio bakoitza karpeta bereizi batean dago. Karpeta barruan fitxategiak eta izen-espazio klaseak daude. Web bezero proiektuan 1000 fitxategi inguru daude.

Egitura aldetik, web bezeroa azpisistema hauetan banatzen da neurri handi batean:

  • Kudeatutako bezero-aplikazioen interfazea
    • Aplikazioen interfaze orokorra (sistemako menuak, panelak)
    • Kudeatutako inprimakien interfazea, besteak beste, 30 kontrol inguru barne (botoiak, hainbat sarrera-eremu mota - testua, zenbakizkoa, data/ordua, etab., taulak, zerrendak, grafikoak, etab.)

  • Objektu-eredua bezeroaren garatzaileentzat eskuragarri (guztira 400 mota baino gehiago: kudeatutako interfazearen objektu-eredua, datuen diseinuaren ezarpenak, baldintzazko estiloa, etab.)
  • 1C hizkuntza integratuaren interpretea
  • Arakatzailearen luzapenak (JavaScript-en onartzen ez diren funtzionalitateetarako erabiltzen dira)
    • Kriptografiarekin lan egitea
    • Fitxategiekin lan egitea
    • Kanpoko osagaien teknologia, bezero finetan zein web bezeroetan erabiltzeko aukera ematen duena

Garapen Ezaugarriak

Aurreko guztia JavaScript-en ezartzea ez da erraza. Beharbada, 1C web bezeroa JavaScript-en idatzitako bezeroen alboko aplikazio handienetako bat da - 450.000 lerro inguru. Objektuetara bideratutako ikuspegia aktiboki erabiltzen dugu web bezeroaren kodean, eta horrek proiektu handi batekin lan egitea errazten du.

Bezero-kodearen tamaina minimizatzeko, lehenik eta behin, gure oihukatzailea erabili genuen, eta plataformaren 8.3.6 bertsioarekin hasita (2014ko urria) erabiltzen hasi ginen. Google Closure konpilatzailea. Zenbakietan erabiltzearen eragina - web bezero-esparruaren tamaina offuskatu ondoren:

  • Ofuskatzaile propioa – 1556 kb
  • Google Closure Compiler - 1073 kb

Google Closure Compiler erabiltzeak web-bezeroaren errendimendua % 30 hobetzen lagundu digu gure ofuskatzailearekin alderatuta. Gainera, aplikazioak kontsumitzen duen memoria kopurua % 15-25 gutxitu da (arakatzailearen arabera).

Google Closure Compiler-ek oso ondo funtzionatzen du objektuetara zuzendutako kodearekin, beraz, bere eraginkortasuna web bezeroarentzat ahalik eta altuena da. Closure Compiler-ek gauza on batzuk egiten dizkigu:

  • Mota estatikoen egiaztapena proiektua eraikitzeko fasean (bermatzen du kodea JSDoc oharpenekin estaltzen dugula). Emaitza idazketa estatikoa da, C++-n idaztetik oso gertukoa. Horrek proiektuaren konpilazio fasean akatsen portzentaje handi samarra harrapatzen laguntzen du.
  • Kodearen tamaina murriztea ofuskazioaren bidez
  • Exekutaturiko kodearen hainbat optimizazio, adibidez, adibidez:
    • lineako funtzioen ordezkapenak. JavaScript-en funtzio bat deitzea nahiko eragiketa garestia da, eta maiz erabiltzen diren metodo txikien lerroko ordezkapenek nabarmen azkartzen dute kodea.
    • Konpilazio garaian konstanteak zenbatzea. Adierazpen bat konstante baten araberakoa bada, konstantearen benetako balioa ordezkatuko da

WebStorm gure web-bezeroaren garapen-ingurune gisa erabiltzen dugu.

Kodearen azterketarako erabiltzen dugu soundQube, non kode estatikoko analizatzaileak integratzen ditugun. Analizatzaileak erabiliz, JavaScript iturburu-kodearen kalitatearen degradazioa kontrolatzen dugu eta hori saihesten saiatzen gara.

1C web bezeroari buruz

Zein arazo konpontzen ditugu/gabiltza?

Proiektua gauzatzean, konpondu behar izan ditugun hainbat arazo interesgarri topatu ditugu.

Trukatu datuak zerbitzariarekin eta leihoen artean

Iturburu-kodea lausotzeak sistemaren funtzionamendua oztopatu dezakeen egoerak daude. Web-bezeroaren kode exekutagarritik kanpoko kodeak, lausotzearen ondorioz, gure kode exekutagarriak espero dituen funtzio eta parametro-izenak izan ditzake. Guretzat kanpoko kodea hau da:

  • Zerbitzaritik datorren kodea datu-egituren moduan
  • Beste aplikazio-leiho baterako kodea

Zerbitzariarekin elkarreraginean nahastea saihesteko, @expose etiketa erabiltzen dugu:

/**
 * @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;
}

Eta beste leiho batzuekin elkarreraginean nahastea saihesteko, esportatutako interfazeak (metodo guztiak esportatzen diren interfazeak) deitutakoak erabiltzen ditugu.

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

DOM birtuala erabili genuen nagusi bihurtu aurretik)

Web UI konplexuekin lan egiten duten garatzaile guztiek bezala, azkar konturatu ginen DOM ez dagoela erabiltzailearen interfaze dinamikoekin lan egiteko. Ia berehala, DOM birtualaren analogo bat ezarri zen UI-rekin lana optimizatzeko. Gertaeren prozesatzean, DOM aldaketa guztiak memorian gordetzen dira eta, eragiketa guztiak amaitzen direnean bakarrik, metatutako aldaketak DOM zuhaitzean aplikatzen dira.

Web bezeroa optimizatzea

Gure web bezeroak azkarrago funtzionatzeko, arakatzaile-gaitasun estandarrak (CSS, etab.) ahalik eta gehien erabiltzen saiatzen gara. Horrela, inprimakiaren komando-panela (aplikazioaren forma ia guztietan dago) arakatzaile-tresnak erabiliz soilik errendatzen da, CSSn oinarritutako diseinu dinamikoa erabiliz.

1C web bezeroari buruz

Testing

Funtzio- eta errendimendu-probak egiteko, jabedun tresna bat erabiltzen dugu (Java eta C++-n idatzia), baita proba-multzo bat ere. Selenium.

Gure tresna unibertsala da - ia edozein leiho programa probatzeko aukera ematen du, eta, beraz, bezero mehe bat eta web bezero bat probatzeko egokia da. Tresnak 1C aplikazioaren soluzioa abiarazi duen erabiltzailearen ekintzak erregistratzen ditu script fitxategi batean. Aldi berean, pantailaren lan-eremuaren irudiak grabatzen dira -estandarrak-. Web bezeroaren bertsio berriak monitorizatzean, script-ak erabiltzaileen parte-hartzerik gabe erreproduzitzen dira. Pantaila-argazkia edozein urratsetan erreferentziakoarekin bat ez datorren kasuetan, proba porrottzat jotzen da, eta, ondoren, kalitateko espezialista batek ikerketa bat egiten du sistemaren portaeran aurreikusitako akatsa edo aurreikusitako aldaketa den zehazteko. Aurreikusitako portaeraren kasuan, estandarrak automatikoki ordezten dira berriekin.

Tresnak aplikazioen errendimendua neurtzen du 25 milisegundorainoko zehaztasunarekin. Zenbait kasutan, script-aren zatiak loratzen ditugu (adibidez, eskaeraren sarrera hainbat aldiz errepikatuz) denboran zehar exekuzio-denboraren degradazioa aztertzeko. Neurketa guztien emaitzak erregistro batean erregistratzen dira aztertzeko.

1C web bezeroari buruz
Gure proba tresna eta aplikazioa proban

Gure tresna eta Selenium elkarren osagarri; adibidez, pantailaren bateko botoiren batek bere kokapena aldatu badu, baliteke Selenium-ek ez du horren jarraipena egin, baina gure tresnak ohartuko dira, zeren eta pantaila-argazkiaren pixelez pixel konparaketa egiten du estandarrekin. Tresnak teklatuaren edo saguaren sarrera prozesatzeko arazoak ere jarraitzeko gai da, horixe baita erreproduzitzen duena.

Bi tresnetako (gurea eta Selenium) probak gure aplikazio-soluzioetako ohiko lan-eszenatokiak exekutatzen ditu. Probak automatikoki abiarazten dira 1C:Enterprise plataformaren eguneroko eraikuntzaren ondoren. Scriptak motelagoak badira (aurreko eraikuntzarekin alderatuta), moteltzearen zergatia ikertzen eta konpontzen dugu. Gure irizpidea sinplea da - eraikuntza berriak ez luke aurrekoa baino motelago funtzionatu behar.

Garatzaileek tresna desberdinak erabiltzen dituzte moteltze-istiluak ikertzeko; batez ere erabiltzen Dynatrace AJAX edizioa ekoiztetxea DynaTrace. Eragiketa arazotsuaren exekuzioaren erregistroak aurreko eta eraikuntza berrietan erregistratzen dira, ondoren erregistroak aztertzen dira. Aldi berean, baliteke eragiketa bakarren exekuzio-denbora (milisegundotan) ez izatea faktore erabakigarria - zabor bilketa bezalako zerbitzu-prozesuak aldian-aldian abiarazten dira arakatzailean, funtzioen exekuzio-denborarekin gainjar daitezke eta irudia desitxuratu dezakete. Kasu honetan parametro garrantzitsuenak exekutatutako JavaScript-en instrukzioen kopurua, DOM-en eragiketa atomikoen kopurua, etab. Bertsio berri batean script bereko argibide/eragiketa kopurua handitu bada, horrek ia beti esan nahi du zuzendu beharreko errendimenduaren jaitsiera.

Gainera, errendimenduaren jaitsieraren arrazoietako bat izan daiteke Google Closure Compiler-ek arrazoiren batengatik ezin izan duela funtzioaren lineako ordezkapena egin (adibidez, funtzioa errekurtsiboa edo birtuala delako). Kasu honetan, egoera zuzentzen saiatzen gara iturburu kodea berridatziz.

Arakatzailearen luzapenak

Aplikazio-soluzio batek JavaScript-en erabilgarri ez dagoen funtzionaltasuna behar duenean, arakatzailearen luzapenak erabiltzen ditugu:

  • fitxategiekin lan egiteko
  • kriptografiarekin lan egiteko
  • lan egin kanpoko osagaiak

Gure luzapenak bi zati ditu. Lehenengo zatia arakatzaile-luzapena deitzen dena da (normalean, Chrome eta Firefox-en JavaScript-en idatzitako luzapenak), bigarren zatiarekin elkarreragiten dutenak - behar dugun funtzionalitatea inplementatzen duen luzapen bitarra. Aipatu beharra dago luzapen bitarren 3 bertsio idazten ditugula - Windows, Linux eta MacOSentzat. Luzapen bitarra 1C:Enterprise plataformaren zati gisa hornitzen da eta 1C aplikazio zerbitzarian dago. Web bezero batetik lehen aldiz deitzen denean, bezeroaren ordenagailura deskargatzen da eta arakatzailean instalatzen da.

Safari-n exekutatzen denean, gure luzapenek NPAPI erabiltzen dute; Internet Explorer-en exekutatzen denean, ActiveX teknologia erabiltzen dute. Microsoft Edge Oraindik ez ditu luzapenak onartzen, beraz, bertan dagoen web bezeroak murrizketekin lan egiten du.

Garapen gehiago

Web-bezeroaren garapen-taldearen zereginetako bat funtzionalitateak garatzea da. Web-bezeroaren funtzionaltasunak bezero mehearen funtzionalitatearen berdina izan behar du; funtzionaltasun berri guztiak aldi berean ezartzen dira bai bezero meheetan bai web-bezeroetan.

Beste zeregin batzuk arkitektura garatzea, birfactorizazioa, errendimendua eta fidagarritasuna hobetzea dira. Esate baterako, norabideetako bat lan eredu asinkrono baterako mugimendu gehiago da. Web-bezeroaren funtzionalitate batzuk zerbitzariarekiko interakzio-eredu sinkrono batean eraikita daude gaur egun. Eredu asinkronoa gero eta garrantzitsuagoa da nabigatzaileetan (eta ez nabigatzaileetan bakarrik), eta honek web bezeroa aldatzera behartzen gaitu, dei sinkronoak asinkronoekin ordezkatuz (eta kodearen arabera birfactorizatuz). Eredu asinkronorako pixkanaka-pixkanaka trantsizioa kaleratutako soluzioei eusteko beharrarekin eta pixkanakako egokitzapenarekin azaltzen da.

Iturria: www.habr.com

Gehitu iruzkin berria