ProHoster > Blogi > antaminen > Tietoja 1C-verkkoasiakkaasta

Tietoja 1C-verkkoasiakkaasta

Yksi 1C:Enterprise-tekniikan mukavista ominaisuuksista on, että hallittujen lomakkeiden teknologialla kehitetty sovellusratkaisu voidaan käynnistää sekä ohuessa (suoritettavassa) asiakasohjelmassa Windowsille, Linuxille, MacOS X:lle että verkkoasiakkaana viidelle selaimelle - Chrome, Internet Explorer, Firefox, Safari, Edge ja kaikki tämä muuttamatta sovelluksen lähdekoodia. Lisäksi ulkoisesti sovellus thin clientissa ja selaimessa toimii ja näyttää lähes identtisiltä.
Etsi 10 eroa (2 kuvaa leikkauksen alla):

Ohut asiakasikkuna Linuxissa:

Tietoja 1C-verkkoasiakkaasta

Sama ikkuna verkkoasiakassovelluksessa (Chrome-selaimessa):

Tietoja 1C-verkkoasiakkaasta

Miksi teimme verkkoasiakkaan? Hieman säälittävästi sanottuna aika on asettanut meille tällaisen tehtävän. Internetin kautta työskentely on pitkään ollut edellytys yrityssovelluksille. Ensin lisäsimme ohuelle asiakkaallemme mahdollisuuden työskennellä Internetin kautta (jotkut kilpailijoistamme muuten pysähtyivät siihen, toiset päinvastoin hylkäsivät ohuen asiakkaan ja rajoittuivat verkkoasiakkaan käyttöönottoon). Päätimme antaa käyttäjillemme mahdollisuuden valita heille parhaiten sopiva asiakasvaihtoehto.

Tietoja 1C-verkkoasiakkaasta

Web-pohjaisten ominaisuuksien lisääminen ohueen asiakaskoneeseen oli iso projekti, jossa asiakas-palvelin-arkkitehtuuri muuttui kokonaan. Verkkoasiakkaan luominen on täysin uusi projekti, joka alkaa alusta.

Ongelma

Joten, projektin vaatimukset: verkkoasiakkaan on tehtävä sama kuin ohuen asiakkaan, nimittäin:

  1. Näytä käyttöliittymä
  2. Suorita 1C-kielellä kirjoitettu asiakaskoodi

1C:n käyttöliittymä on kuvattu visuaalisessa editorissa, mutta deklaratiivisesti, ilman elementtien pikselikohtaista järjestelyä; Käyttöliittymäelementtejä käytetään noin kolmea tusinaa - painikkeita, syöttökenttiä (teksti, numero, päivämäärä/aika), luettelot, taulukot, kaaviot jne.

Asiakaskoodi 1C-kielellä voi sisältää palvelinkutsuja, paikallisten resurssien (tiedostot jne.) käyttöä, tulostusta ja paljon muuta.

Sekä ohut asiakas (työskennellessään verkon kautta) että verkkoasiakas käyttävät samoja verkkopalveluita kommunikoidakseen 1C-sovelluspalvelimen kanssa. Asiakassovellukset ovat tietysti erilaisia ​​- ohut asiakasohjelma on kirjoitettu C++:lla, verkkoasiakas JavaScript-kielellä.

Vähän historiaa

Verkkoasiakasprojekti käynnistyi vuonna 2006 (keskimäärin) 5 hengen tiimillä. Tietyissä projektin vaiheissa kehittäjät olivat mukana toteuttamassa tiettyjä toimintoja (laskentataulukkoasiakirja, kaaviot jne.); pääsääntöisesti nämä olivat samat kehittäjät, jotka tekivät tämän toiminnon ohuessa asiakasohjelmassa. Nuo. kehittäjät kirjoittivat uudelleen JavaScriptillä komponentit, jotka he olivat aiemmin luoneet C++:ssa.

Alusta alkaen hylkäsimme ajatuksen C++-pienen asiakaskoodin automaattisesta (jopa osittaisesta) muuntamisesta JavaScript-verkkoasiakkaaksi, koska näiden kahden kielen välillä on suuria käsitteellisiä eroja; web-asiakasohjelma kirjoitettiin JavaScriptillä tyhjästä.

Projektin ensimmäisissä iteraatioissa verkkoasiakasohjelma muunsi asiakaskoodin sisäänrakennetulla 1C-kielellä suoraan JavaScriptiksi. Ohut asiakas toimii eri tavalla - sisäänrakennetun 1C-kielen koodi käännetään tavukoodiksi, ja sitten tämä tavukoodi tulkitaan asiakkaalle. Myöhemmin web-asiakasohjelma alkoi tehdä samoin - ensinnäkin se paransi suorituskykyä ja toiseksi se mahdollisti ohuiden ja web-asiakkaiden arkkitehtuurin yhtenäistämisen.

1C:Enterprise-alustan ensimmäinen versio verkkoasiakastuella julkaistiin vuonna 2009. Web-asiakas tuki tuolloin kahta selainta - Internet Exploreria ja Firefoxia. Alkuperäiset suunnitelmat sisälsivät Operan tuen, mutta johtuen tuolloin ylitsepääsemättömistä ongelmista sovelluksen sulkemiskäsittelijöiden kanssa Operassa (sovelluksen sulkeutumista ei voitu seurata 2% varmuudella ja sillä hetkellä suorittaa katkaisutoimenpiteet alkaen 100C-sovelluspalvelin) näistä suunnitelmista jouduttiin luopumaan.

Hankkeen rakenne

Yhteensä 1C:Enterprise-alustalla on 4 JavaScriptillä kirjoitettua projektia:

  1. WebTools – muiden projektien käyttämät jaetut kirjastot (mukaan lukien myös Google Closure Library).
  2. Ohjauselementti Muotoiltu asiakirja (toteutettu JavaScriptissä sekä ohuessa että verkkoasiakasohjelmassa)
  3. Ohjauselementti Ajastin (toteutettu JavaScriptissä sekä ohuessa että verkkoasiakasohjelmassa)
  4. Web-asiakas

Kunkin projektin rakenne muistuttaa Java-projektien (tai .NET-projektien - sen mukaan kumpi on lähempänä) rakennetta; Meillä on nimiavaruuksia, ja jokainen nimiavaruus on erillisessä kansiossa. Kansion sisällä on tiedostoja ja nimitilaluokkia. Verkkoasiakasprojektissa on noin 1000 tiedostoa.

Rakenteellisesti verkkoasiakasohjelma on suurelta osin jaettu seuraaviin alijärjestelmiin:

  • Hallittu asiakassovellusliittymä
    • Yleinen sovellusliittymä (järjestelmävalikot, paneelit)
    • Hallittujen lomakkeiden käyttöliittymä, joka sisältää muun muassa noin 30 ohjausobjektia (painikkeet, erityyppiset syöttökentät - teksti, numeeriset, päivämäärä/aika jne., taulukot, luettelot, kaaviot jne.)

  • Asiakkaan kehittäjien käytettävissä oleva objektimalli (yhteensä yli 400 tyyppiä: hallitun käyttöliittymän objektimalli, tietojen asetteluasetukset, ehdollinen tyyli jne.)
  • Sisäänrakennetun 1C-kielen tulkki
  • Selainlaajennukset (käytetään toimintoihin, joita JavaScript ei tue)
    • Työskentely kryptografian kanssa
    • Tiedostojen käsittely
    • Ulkoisten komponenttien teknologia, jonka ansiosta niitä voidaan käyttää sekä ohuissa että web-asiakkaissa

Kehitysominaisuudet

Kaikkien yllä olevien toteuttaminen JavaScriptissä ei ole helppoa. Ehkä 1C-verkkoasiakasohjelma on yksi suurimmista JavaScriptillä kirjoitetuista asiakaspuolen sovelluksista - noin 450.000 XNUMX riviä. Käytämme aktiivisesti oliolähtöistä lähestymistapaa web-asiakaskoodissa, mikä yksinkertaistaa työskentelyä näin suuren projektin kanssa.

Asiakaskoodin koon minimoimiseksi käytimme ensin omaa obfuskaattoriamme ja alustaversiosta 8.3.6 alkaen (lokakuu 2014) aloimme käyttää Google Closure Compiler. Numeroiden käytön vaikutus – verkkoasiakaskehyksen koko hämärtymisen jälkeen:

  • Oma obfuskaattori – 1556 kb
  • Google Closure Compiler – 1073 kt

Google Closure Compiler auttoi meitä parantamaan verkkoasiakasohjelman suorituskykyä 30 % verrattuna omaan obfuskaattoriimme. Lisäksi sovelluksen käyttämän muistin määrä on laskenut 15-25 % (selaimesta riippuen).

Google Closure Compiler toimii erittäin hyvin oliokoodin kanssa, joten sen tehokkuus verkkoasiakkaalle on mahdollisimman korkea. Closure Compiler tekee meille muutamia hyviä asioita:

  • Staattinen tyyppitarkistus projektin rakennusvaiheessa (varmistaa, että peitämme koodin JSDoc-merkinnöillä). Tuloksena on staattinen kirjoitus, joka on hyvin lähellä C++:n kirjoittamista. Tämä auttaa havaitsemaan melko suuren prosenttiosuuden virheistä projektin laatimisvaiheessa.
  • Koodin koon pienentäminen hämärtymisen avulla
  • Useita suoritetun koodin optimointeja, esimerkiksi:
    • rivin funktioiden korvaukset. Funktion kutsuminen JavaScriptissä on melko kallis operaatio, ja usein käytettyjen pienten menetelmien korvaukset nopeuttavat koodia huomattavasti.
    • Vakioiden laskeminen käännöshetkellä. Jos lauseke riippuu vakiosta, vakion todellinen arvo korvataan sillä

Käytämme WebStormia web-asiakasohjelman kehitysympäristönä.

Käytämme koodianalyysiin soundQube, jossa integroimme staattisia koodianalysaattoreita. Analysaattoreiden avulla seuraamme JavaScript-lähdekoodin laadun heikkenemistä ja yritämme estää sen.

Tietoja 1C-verkkoasiakkaasta

Mitä ongelmia ratkaisimme/ratkaisimme?

Hankkeen toteuttamisen aikana kohtasimme useita mielenkiintoisia ongelmia, jotka meidän piti ratkaista.

Vaihda tietoja palvelimen kanssa ja ikkunoiden välillä

On tilanteita, joissa lähdekoodin hämärtäminen voi häiritä järjestelmän toimintaa. Web-asiakkaan suoritettavan koodin ulkopuolisella koodilla voi hämärtymisen vuoksi olla funktioiden ja parametrien nimet, jotka poikkeavat suoritettavan koodimme odottamista. Ulkoinen koodi meille on:

  • Koodi tulee palvelimelta tietorakenteiden muodossa
  • Toisen sovellusikkunan koodi

Käytämme @expose-tunnistetta, jotta vältytään hämärältä vuorovaikutuksessa palvelimen kanssa:

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

Ja välttääksemme hämärtymisen vuorovaikutuksessa muiden ikkunoiden kanssa, käytämme niin kutsuttuja vientiliittymiä (rajapinnat, joissa kaikki menetelmät viedään).

/**
 * Экспортируемый интерфейс контрола 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 (){}

Käytimme Virtual DOM:ia ennen kuin siitä tuli valtavirtaa)

Kuten kaikki monimutkaisia ​​verkkokäyttöliittymiä käsittelevät kehittäjät, huomasimme nopeasti, että DOM sopii huonosti työskentelemään dynaamisten käyttöliittymien kanssa. Lähes välittömästi otettiin käyttöön Virtual DOM:n analogi käyttöliittymän käytön optimoimiseksi. Tapahtumakäsittelyn aikana kaikki DOM-muutokset tallennetaan muistiin ja vasta kun kaikki toiminnot on suoritettu, kertyneet muutokset otetaan käyttöön DOM-puussa.

Web-asiakkaan optimointi

Jotta verkkoasiakasohjelmamme toimisi nopeammin, yritämme käyttää selaimen vakioominaisuuksia (CSS jne.) mahdollisimman paljon. Näin ollen lomakkeen komentopaneeli (sijaitsee lähes kaikissa sovelluksen muodoissa) renderöidään yksinomaan selaimen työkaluilla käyttäen CSS-pohjaista dynaamista asettelua.

Tietoja 1C-verkkoasiakkaasta

Testaus

Toiminnan ja suorituskyvyn testaamiseen käytämme omaa työkalua (kirjoitettu Java- ja C++-kielellä) sekä testisarja, joka on rakennettu Seleeni.

Työkalumme on universaali - sen avulla voit testata melkein mitä tahansa ikkunoitua ohjelmaa, joten se soveltuu sekä ohuen asiakkaan että web-asiakkaan testaukseen. Työkalu tallentaa 1C-sovellusratkaisun käynnistäneen käyttäjän toimet komentosarjatiedostoon. Samalla tallennetaan kuvia näytön työalueesta - standardeista. Web-asiakasohjelman uusia versioita valvottaessa skriptejä toistetaan ilman käyttäjän osallistumista. Tapauksissa, joissa kuvakaappaus ei missään vaiheessa vastaa vertailukuvaa, testi katsotaan epäonnistuneeksi, minkä jälkeen laatuasiantuntija suorittaa tutkimuksen selvittääkseen, onko kyseessä virhe vai suunniteltu muutos järjestelmän käyttäytymisessä. Suunnitellun käyttäytymisen tapauksessa standardit korvataan automaattisesti uusilla.

Työkalu mittaa myös sovelluksen suorituskykyä jopa 25 millisekunnin tarkkuudella. Joissakin tapauksissa silmukkaamme komentosarjan osia (esimerkiksi toistamme tilausmerkinnän useita kertoja) analysoidaksemme suoritusajan heikkenemistä ajan myötä. Kaikkien mittausten tulokset kirjataan lokiin analysointia varten.

Tietoja 1C-verkkoasiakkaasta
Testaustyökalumme ja sovelluksemme testattavana

Työkalumme ja Seleeni täydentävät toisiaan; Jos esimerkiksi jokin painike jollakin näytöstä on vaihtanut sijaintiaan, Selenium ei välttämättä seuraa tätä, mutta työkalumme huomaa, koska vertaa kuvakaappausta pikseli kerrallaan standardiin. Työkalu pystyy myös seuraamaan ongelmia näppäimistön tai hiiren syötteiden käsittelyssä, koska se toistaa juuri tämän.

Molempien työkalujen (meidän ja Seleenin) testit suorittavat tyypillisiä työskenaarioita sovellusratkaisuistamme. Testit käynnistetään automaattisesti 1C:Enterprise-alustan päivittäisen rakentamisen jälkeen. Jos komentosarjat ovat hitaampia (verrattuna edelliseen koontiversioon), tutkimme ja ratkaisemme hidastumisen syyn. Kriteerimme on yksinkertainen - uuden koontiversion ei pitäisi toimia hitaammin kuin edellinen.

Kehittäjät käyttävät erilaisia ​​työkaluja hidastustapausten tutkimiseen; pääasiassa käytetty Dynatrace AJAX Edition tuotantoyhtiö DynaTrace. Edellisen ja uuden koontiversion ongelmallisen toiminnon suorittamisen lokit tallennetaan, minkä jälkeen lokit analysoidaan. Samaan aikaan yksittäisten toimintojen suoritusaika (millisekunteina) ei välttämättä ole ratkaiseva tekijä - palveluprosessit, kuten roskienkeräys, käynnistetään ajoittain selaimessa, ne voivat mennä päällekkäin toimintojen suoritusajan kanssa ja vääristää kuvaa. Tässä tapauksessa merkityksellisempiä parametreja ovat suoritettujen JavaScript-käskyjen määrä, DOM:n atomioperaatioiden määrä jne. Jos ohjeiden/toimintojen määrä samassa skriptissä on lisääntynyt uudessa versiossa, tämä tarkoittaa lähes aina suorituskyvyn laskua, joka on korjattava.

Yksi syy suorituskyvyn laskuun voi myös olla se, että Google Closure Compiler ei jostain syystä pystynyt suorittamaan funktion korvaamista rivillä (esimerkiksi koska toiminto on rekursiivinen tai virtuaalinen). Tässä tapauksessa yritämme korjata tilanteen kirjoittamalla lähdekoodin uudelleen.

Selainlaajennukset

Kun sovellusratkaisu tarvitsee toimintoja, joita ei ole saatavilla JavaScriptissä, käytämme selainlaajennuksia:

Laajennukset koostuvat kahdesta osasta. Ensimmäinen osa on selainlaajennukseksi kutsuttu (yleensä JavaScriptillä kirjoitetut laajennukset Chromelle ja Firefoxille), joka on vuorovaikutuksessa toisen osan kanssa - binaarilaajennuksella, joka toteuttaa tarvitsemamme toiminnot. On syytä mainita, että kirjoitamme 3 versiota binäärilaajennuksista - Windowsille, Linuxille ja MacOS:lle. Binäärilaajennus toimitetaan osana 1C:Enterprise-alustaa ja sijaitsee 1C-sovelluspalvelimella. Kun sitä kutsutaan ensimmäisen kerran verkkoasiakkaasta, se ladataan asiakastietokoneelle ja asennetaan selaimeen.

Safarissa toiminnassamme laajennukset käyttävät NPAPI:ta, kun taas Internet Explorerissa ne käyttävät ActiveX-tekniikkaa. Microsoft Edge ei vielä tue laajennuksia, joten sen verkkoasiakasohjelma toimii rajoituksin.

Jatkokehitys

Yksi web-asiakaskehitystiimin tehtävistä on toiminnallisuuden edelleen kehittäminen. Web-asiakkaan toiminnallisuuden tulee olla identtinen ohuen asiakkaan kanssa, kaikki uudet toiminnot toteutetaan samanaikaisesti sekä ohuessa että web-asiakkaassa.

Muita tehtäviä ovat arkkitehtuurin kehittäminen, refaktorointi, suorituskyvyn ja luotettavuuden parantaminen. Esimerkiksi yksi suunnista on siirtyminen eteenpäin kohti asynkronista työmallia. Osa web-asiakasohjelman toiminnoista on tällä hetkellä rakennettu synkroniseen vuorovaikutusmalliin palvelimen kanssa. Asynkronisesta mallista on tulossa entistä merkityksellisempi selaimissa (eikä vain selaimissa), ja tämä pakottaa meidät muokkaamaan verkkoasiakasta korvaamalla synkroniset puhelut asynkronisilla (ja muokkaamalla koodia uudelleen vastaavasti). Asteittainen siirtyminen asynkroniseen malliin selittyy tarpeella tukea julkaistuja ratkaisuja ja niiden asteittaista mukauttamista.

Lähde: will.com

Lisää kommentti