🥇O spletnem odjemalcu 1C

Ena od lepih lastnosti tehnologije 1C:Enterprise je, da je aplikacijsko rešitev, razvito s tehnologijo upravljanih obrazcev, mogoče zagnati tako v tankem (izvršljivem) odjemalcu pod Windows, Linux, MacOS X kot spletni odjemalec za 5 brskalnikov - Chrome, Internet Explorer, Firefox, Safari, Edge, in vse to brez spreminjanja izvorne kode aplikacije. Poleg tega navzven aplikacija v tankem odjemalcu in v brskalniku deluje in izgleda skoraj enako.
Poišči 10 razlik (pod izrezom 2 sliki):

Okno tankega odjemalca v sistemu Linux:

Isto okno v spletnem odjemalcu (v brskalniku Chrome):

Zakaj smo naredili spletno stranko? Tako nalogo nam je, nekoliko patetično povedano, postavil čas. Delo preko interneta je že dolgo postalo predpogoj za poslovne aplikacije. Najprej smo našemu tankemu odjemalcu dodali možnost dela prek interneta (mimogrede, nekateri naši konkurenti so se tam ustavili, drugi pa so, nasprotno, opustili tankega odjemalca in se omejili na implementacijo spletnega odjemalca). Odločili smo se, da našim uporabnikom damo možnost, da izberejo možnost odjemalca, ki jim najbolj ustreza.

Dodajanje spletne zmogljivosti tankemu odjemalcu je bil velik podvig s popolno spremembo arhitekture odjemalec/strežnik. Izdelava spletnega odjemalca je popolnoma nov projekt, ki se je začel iz nič.

Izjava o težavah

Torej, zahteve za projekt: spletni odjemalec mora delati enako kot tanek odjemalec, in sicer:

Prikaz uporabniškega vmesnika
Izvedite odjemalsko kodo, napisano v jeziku 1C

Uporabniški vmesnik v 1C je opisan v vizualnem urejevalniku, vendar deklarativno, brez razporeditve elementov po pikslovih; Uporablja se približno tri ducate vrst elementov vmesnika - gumbi, vnosna polja (besedilo, digitalno, datum / čas), seznami, tabele, grafi itd.

Odjemalska koda v jeziku 1C lahko vsebuje klice strežnika, delo z lokalnimi viri (datoteke itd.), tiskanje in še veliko več.

Tako tanki odjemalec (pri delu preko spleta) kot spletni odjemalec uporabljata isti nabor spletnih storitev za komunikacijo z aplikacijskim strežnikom 1C. Izvedba odjemalcev je seveda drugačna - tanek odjemalec je napisan v C ++, spletni odjemalec je napisan v JavaScriptu.

Malo zgodovine

Projekt spletnega odjemalca se je začel leta 2006 s (povprečno) ekipo 5 ljudi. V določenih fazah projekta so bili vključeni razvijalci, ki so implementirali določene funkcionalnosti (tabelarni dokument, diagrami itd.); praviloma so bili to isti razvijalci, ki so naredili to funkcionalnost v tankem odjemalcu. Tisti. razvijalci so v JavaScriptu prepisali komponente, ki so jih prej ustvarili v C++.

Že od samega začetka smo zavrnili zamisel o kakršni koli samodejni (vsaj delni) pretvorbi kode tankega odjemalca C++ v JavaScript spletnega odjemalca zaradi velikih konceptualnih razlik med obema jezikoma; spletni odjemalec je bil napisan v JavaScriptu od začetka.

V prvih iteracijah projekta je spletni odjemalec pretvoril odjemalsko kodo v vgrajenem jeziku 1C neposredno v JavaScript. Tanki odjemalec deluje drugače - koda v vgrajenem jeziku 1C se prevede v bajtno kodo, nato pa se ta bajtna koda interpretira na odjemalcu. Kasneje je spletni odjemalec začel delati enako - prvič, povečal je zmogljivost, in drugič, omogočil poenotenje arhitekture tankih in spletnih odjemalcev.

Prva različica platforme 1C:Enterprise s podporo za spletne odjemalce je bila izdana leta 2009. Takratni spletni odjemalec je podpiral 2 brskalnika - Internet Explorer in Firefox. Prvotni načrti so bili podpora Operi, a zaradi takrat nerešljivih težav z obdelovalci zapiranja aplikacij v Operi (ni bilo mogoče s 100% gotovostjo slediti, da se aplikacija zapira, in v tistem trenutku izvesti postopek odklopa od aplikacijskega strežnika 1C), je bilo treba te načrte opustiti.

Struktura projekta

Skupno ima platforma 1C:Enterprise 4 projekte, napisane v JavaScriptu:

Spletna orodja - knjižnice v skupni rabi, ki jih uporabljajo drugi projekti (tu vključujemo Google Closure Library).
Krmilni element FormattedDocument (implementirano v JavaScript tako v tankem odjemalcu kot v spletnem odjemalcu)
Krmilni element Razporejevalnik (implementirano v JavaScript tako v tankem odjemalcu kot v spletnem odjemalcu)
Spletni odjemalec

Struktura vsakega projekta je podobna strukturi projektov Java (ali projektov .NET - kar vam je bližje); imamo imenske prostore in vsak imenski prostor je v ločeni mapi. Znotraj mape so datoteke in razredi imenskega prostora. V projektu spletnega odjemalca je približno 1000 datotek.

Strukturno je spletni odjemalec v veliki meri razdeljen na naslednje podsisteme:

Vmesnik upravljane odjemalske aplikacije
- Splošni aplikacijski vmesnik (sistemski meniji, plošče)
- Vmesnik za upravljane obrazce, ki med drugim vključuje približno 30 kontrol (gumbi, različni tipi vnosnih polj – besedilna, digitalna, datum/čas, itd., tabele, seznami, grafi, itd.)
Objektni model, ki je na voljo razvijalcem na odjemalcu (skupaj več kot 400 vrst: objektni model upravljanega vmesnika, nastavitve sestave podatkov, pogojno oblikovanje itd.)
Vgrajeni jezikovni tolmač 1C
Razširitve brskalnika (uporabljajo se za funkcije, ki jih JavaScript ne podpira)
- Delo s kriptografijo
- Delo z datotekami
- Tehnologija zunanjih komponent, ki omogoča njihovo uporabo v tankih in spletnih odjemalcih

Razvojne značilnosti

Implementacija vsega naštetega v JavaScriptu ni lahka naloga. Morda je spletni odjemalec 1C ena največjih aplikacij na strani odjemalca, napisanih v JavaScriptu - približno 450.000 vrstic. V kodi spletnega odjemalca aktivno uporabljamo objektno usmerjen pristop, ki poenostavi delo pri tako velikem projektu.

Da bi čim bolj zmanjšali kodo odjemalca, smo najprej uporabili lasten obfuscator, od različice platforme 8.3.6 (oktober 2014) pa smo začeli uporabljati Google Closure Compiler. Učinek uporabe v številkah je velikost ogrodja spletnega odjemalca po zamegljevanju:

Lasten obfuscator - 1556 kb
Google Closure Compiler - 1073 kb

Uporaba Googlovega prevajalnika Closure Compiler nam je pomagala izboljšati delovanje spletnega odjemalca za 30 % v primerjavi z našim lastnim obfuskatorjem. Poleg tega se je količina pomnilnika, ki ga porabi aplikacija, zmanjšala za 15–25 % (odvisno od brskalnika).

Google Closure Compiler zelo dobro deluje z objektno usmerjeno kodo, zato je njegova učinkovitost najvišja za spletnega odjemalca. Closure Compiler naredi nekaj dobrih stvari za nas:

Statično preverjanje tipa v fazi izdelave projekta (zagotovljeno z dejstvom, da kodo prekrijemo z opombami JSDoc). Rezultat je statično tipkanje, ki je po ravni zelo blizu tipkanju v C++. To pomaga ujeti dokaj velik odstotek napak v fazi prevajanja projekta.
Zmanjšanje velikosti kode z zamegljevanjem
Številne optimizacije izvedljive kode, na primer, kot so:
- vgrajene zamenjave funkcij. Klicanje funkcije v JavaScriptu je precej draga operacija in vgrajene zamenjave pogosto uporabljenih majhnih metod lahko znatno pospešijo kodo.
- Štetje konstant v času prevajanja. Če je izraz odvisen od konstante, bo nadomeščen z dejansko vrednostjo konstante

WebStorm uporabljamo kot okolje za razvoj spletnega odjemalca.

Za analizo kode uporabljamo soundQube, kamor integriramo statične analizatorje kode. S pomočjo analizatorjev spremljamo poslabšanje kakovosti izvorne kode JavaScript in ga poskušamo preprečiti.

Katere naloge smo/rešujemo

Med izvajanjem projekta smo se soočili s številnimi zanimivimi nalogami, ki smo jih morali rešiti.

Izmenjava podatkov s strežnikom in med okni

Obstajajo situacije, ko lahko zamegljenost izvorne kode moti delovanje sistema. Koda, ki je zunaj izvedljive kode spletnega odjemalca, ima lahko zaradi zamegljenosti imena funkcij in parametrov, ki se razlikujejo od tistih, ki jih pričakuje naša izvršljiva koda. Zunanja koda za nas je:

Koda, ki prihaja s strežnika kot podatkovne strukture
Koda za drugo okno aplikacije

Da bi se izognili zameglitvi pri interakciji s strežnikom, uporabljamo oznako @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;
}

Da bi se izognili zamegljevanju pri interakciji z drugimi okni, uporabljamo tako imenovane izvožene vmesnike (vmesnike, v katerih je vse metode mogoče izvoziti).

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

Uporabljali smo Virtual DOM, preden je postal mainstream)

Tako kot vsi razvijalci, ki se ukvarjajo s kompleksnim spletnim uporabniškim vmesnikom, smo hitro ugotovili, da DOM ni najbolj primeren za dinamične uporabniške vmesnike. Skoraj takoj je bil implementiran analog Virtual DOM za optimizacijo dela z uporabniškim vmesnikom. Med obdelavo dogodka se vse spremembe DOM shranijo v pomnilnik in šele ko so vse operacije zaključene, se zbrane spremembe uporabijo v drevesu DOM.

Optimizacija spletnega odjemalca

Za hitrejše delovanje našega spletnega odjemalca se trudimo čim bolj izkoristiti standardne funkcije brskalnika (CSS itd.). Torej, ukazno vrstico obrazca (nahaja se na skoraj vsakem prijavnem obrazcu) izriše izključno brskalnik, dinamična postavitev, ki temelji na CSS.

Testiranje

Za funkcionalno testiranje in testiranje delovanja uporabljamo lastno orodje (napisano v Javi in C++) ter nabor testov, zgrajenih na osnovi Selen.

Naše orodje je univerzalno - omogoča testiranje skoraj vseh okenskih programov, zato je primerno za testiranje tankega odjemalca in spletnega odjemalca. Orodje beleži dejanja uporabnika, ki je zagnal aplikacijsko rešitev 1C, v skriptno datoteko. Hkrati se posnamejo slike delovnega območja zaslona (standardi). Pri spremljanju novih različic spletnega odjemalca se scenariji predvajajo brez sodelovanja uporabnika. V primerih, ko se posnetek zaslona v nobenem koraku ne ujema z referenčnim, se šteje, da je test neuspešen, nakar strokovnjak za kakovost opravi preiskavo - ali gre za napako ali načrtovano spremembo vedenja sistema. V primeru načrtovanega vedenja se standardi samodejno nadomestijo z novimi.

Orodje meri tudi delovanje aplikacije z natančnostjo 25 milisekund. V nekaterih primerih dele skripta vrtimo v zanki (na primer večkratno ponavljanje vnosa naročila), da analiziramo poslabšanje časa izvajanja skozi čas. Rezultati vseh meritev se zapišejo v dnevnik za analizo.

Naše orodje za testiranje in aplikacija, ki se testira

Naše orodje in Selenium se dopolnjujeta; na primer, če je kakšen gumb na enem od zaslonov spremenil svojo lokacijo - Selenium temu morda ne bo sledil, vendar bo naše orodje opazilo, ker naredi slikovno piko primerjavo posnetka zaslona s standardom. Orodje lahko tudi izsledi težave pri obdelavi vnosa s tipkovnice ali miške, saj to reproducira.

Preizkusi obeh orodij (našega in Selenium) izvajajo tipične delovne scenarije iz naših aplikacijskih rešitev. Testi se samodejno zaženejo po dnevni gradnji platforme 1C:Enterprise. Če se skripti upočasnijo (v primerjavi s prejšnjo gradnjo), bomo raziskali in odpravili vzrok upočasnitve. Naše merilo je preprosto - novi sklop ne sme delovati počasneje od prejšnjega.

Razvijalci uporabljajo različna orodja za raziskovanje incidentov z upočasnitvijo; v glavnem rabljeno Izdaja Dynatrace AJAX proizvodnja podjetja DynaTrace. Zapišejo se dnevniki izvajanja problematične operacije na prejšnjem in novem sklopu, nato se dnevniki analizirajo. Hkrati čas izvajanja posameznih operacij (v milisekundah) morda ni odločilen dejavnik - storitveni procesi, kot je zbiranje smeti, se občasno zaženejo v brskalniku, lahko se prekrivajo s časom izvajanja funkcij in izkrivljajo sliko. Ustreznejši parametri v tem primeru bi bili število izvedenih navodil JavaScript, število atomskih operacij na DOM itd. Če se je število ukazov/operacij v istem skriptu v novi različici povečalo, to skoraj vedno pomeni padec zmogljivosti, ki ga je treba popraviti.

Eden od razlogov za padec zmogljivosti je lahko tudi ta, da Google Closure Compiler iz nekega razloga ni mogel narediti vgrajene zamenjave funkcije (na primer, ker je funkcija rekurzivna ali navidezna). V tem primeru poskušamo popraviti situacijo s prepisovanjem izvorne kode.

Razširitve brskalnika

V primeru, da aplikativna rešitev potrebuje funkcionalnost, ki ni v JavaScriptu, uporabljamo razširitve brskalnika:

za delo z datotekami
za delo s kriptografijo
delo z zunanje komponente

Naše razširitve so sestavljene iz dveh delov. Prvi del je tako imenovana razširitev brskalnika (običajno razširitve JavaScript za Chrome in Firefox), ki sodeluje z drugim delom, binarno razširitvijo, ki izvaja funkcionalnost, ki jo potrebujemo. Omeniti velja, da pišemo 3 različice binarnih razširitev - za Windows, Linux in MacOS. Binarna razširitev je dobavljena kot del platforme 1C:Enterprise in se nahaja na aplikacijskem strežniku 1C. Ko se prvič pokliče iz spletnega odjemalca, se prenese v odjemalski računalnik in namesti v brskalnik.

Ko se izvajajo v Safariju, naše razširitve uporabljajo NPAPI; ko se izvajajo v Internet Explorerju, naše razširitve uporabljajo tehnologijo ActiveX. Microsoft Edge še ne podpira razširitev, zato spletni odjemalec v njem deluje z omejitvami.

Nadaljnji razvoj

Ena izmed nalog razvojne ekipe spletnega odjemalca je nadaljnji razvoj funkcionalnosti. Funkcionalnost spletnega odjemalca mora biti enaka funkcionalnosti tankega odjemalca, vse nove funkcionalnosti so implementirane hkrati v tankem odjemalcu in spletnem odjemalcu.

Druge naloge so razvoj arhitekture, preoblikovanje, izboljšave zmogljivosti in zanesljivosti. Ena od smeri je na primer nadaljnji premik k asinhronemu modelu dela. Del funkcionalnosti spletnega odjemalca je trenutno zgrajen na sinhronem modelu interakcije s strežnikom. Asinhroni model postaja zdaj vse pomembnejši v brskalnikih (pa ne samo v brskalnikih), kar nas sili v spreminjanje spletnega odjemalca z zamenjavo sinhronih klicev z asinhronimi (in ustrezno refaktoriranje kode). Postopni prehod na asinhroni model je razložen s potrebo po podpori izdanih rešitev in njihovem postopnem prilagajanju.

Vir: www.habr.com

O spletnem odjemalcu 1C