1C veebikliendi kohta

Üks 1C:Enterprise tehnoloogia toredaid omadusi on see, et hallatavate vormide tehnoloogiat kasutades välja töötatud rakenduslahendust saab käivitada nii õhukeses (käivitatavas) kliendis Windowsi, Linuxi, MacOS X all kui ka 5 brauseri veebikliendina - Chrome, Internet Explorer, Firefox, Safari, Edge ja kõik ilma rakenduse lähtekoodi muutmata. Veelgi enam, väliselt töötab õhukeses kliendis ja brauseris olev rakendus ja näeb peaaegu identne välja.
Leia 10 erinevust (lõike all 2 pilti):

Õhuke kliendiaken Linuxis:

Sama aken veebikliendis (Chrome'i brauseris):

Miks me tegime veebikliendi? Mõnevõrra pateetiliselt öeldes on aeg meile sellise ülesande seadnud. Interneti kaudu töötamine on pikka aega muutunud ärirakenduste eelduseks. Esiteks lisasime oma õhukese kliendi jaoks võimaluse töötada Interneti kaudu (osa konkurente, muide, peatus seal, teised, vastupidi, loobusid õhukesest kliendist ja piirdusid veebikliendi juurutamisega). Otsustasime anda oma kasutajatele võimaluse valida neile kõige sobivam kliendivariant.

Veebivõimekuse lisamine õhukesele kliendile oli suur ettevõtmine koos kliendi/serveri arhitektuuri täieliku muutmisega. Veebikliendi loomine on täiesti uus projekt, mis sai alguse nullist.

Probleemi avaldus

Niisiis, nõuded projektile: veebiklient peab tegema sama, mis õhuke klient, nimelt:

1. Kuva kasutajaliides
2. Käivitage 1C keeles kirjutatud kliendikood

1C kasutajaliidest kirjeldatakse visuaalses redaktoris, kuid deklaratiivselt, ilma elementide pikslite kaupa paigutuseta; kasutatakse umbes kolme tosinat tüüpi liidese elemente - nuppe, sisestusvälju (tekst, digitaalne, kuupäev / kellaaeg), loendeid, tabeleid, graafikuid jne.

Kliendikood 1C keeles võib sisaldada serverikõnesid, tööd kohalike ressurssidega (failid jne), printimist ja palju muud.

Nii õhuke klient (veebi kaudu töötades) kui ka veebiklient kasutavad 1C rakendusserveriga suhtlemiseks sama veebiteenuste komplekti. Klientide teostus on muidugi erinev - õhuke klient on kirjutatud C ++ keeles, veebiklient JavaScriptis.

Veidi ajalugu

Veebikliendi projekt sai alguse 2006. aastal (keskmiselt) 5-liikmelise meeskonnaga. Projekti teatud etappides kaasati arendajaid konkreetse funktsionaalsuse juurutamiseks (arvutustabeli dokument, diagrammid jne); reeglina olid need samad arendajad, kes selle funktsiooni õhukeses kliendis tegid. Need. arendajad kirjutasid JavaScriptis ümber komponendid, mille nad olid varem C++-s loonud.

Kahe keele tugevate kontseptuaalsete erinevuste tõttu lükkasime algusest peale tagasi idee õhukese kliendi C++ koodi automaatsest (vähemalt osalisest) konverteerimisest veebikliendi JavaScriptiks; veebiklient kirjutati nullist JavaScriptis.

Projekti esimestel iteratsioonidel teisendas veebiklient kliendikoodi sisseehitatud 1C keeles otse JavaScriptiks. Õhuke klient toimib erinevalt - sisseehitatud 1C keeles olev kood kompileeritakse baitkoodiks ja seejärel tõlgendatakse seda baitkoodi kliendil. Edaspidi hakkas sama tegema ka veebiklient – ​​esiteks andis see jõudluse kasvu ning teiseks võimaldas ühtlustada õhukese ja veebikliendi arhitektuuri.

Esimene veebiklienditoega platvormi 1C:Enterprise versioon ilmus 2009. aastal. Sel ajal toetas veebiklient 2 brauserit - Internet Explorer ja Firefox. Esialgsed plaanid olid küll Opera toetamine, kuid tollal tekkisid Operas ületamatud probleemid rakenduste sulgemise töötlejatega (rakenduse sulgemist ei olnud võimalik 100% kindlusega jälgida ja sel hetkel ühenduse katkestamise protseduuri teostada alates 1C rakendusserver) tuli neist plaanidest loobuda.

Projekti struktuur

Kokku on platvormil 1C: Enterprise 4 JavaScriptis kirjutatud projekti:

1. WebTools – jagatud teegid, mida kasutavad teised projektid (siia lisame Google'i sulgemise raamatukogu).
2. Juhtelement Vormindatud dokument (rakendatud JavaScriptis nii õhukeses kliendis kui ka veebikliendis)
3. Juhtelement Planeerija (rakendatud JavaScriptis nii õhukeses kliendis kui ka veebikliendis)
4. Veebiklient

Iga projekti struktuur sarnaneb Java-projektide (või .NET-projektide – olenevalt sellest, kumb on teile lähemal) ülesehitusega; meil on nimeruumid ja iga nimeruum on eraldi kaustas. Kausta sees on failid ja nimeruumi klassid. Veebikliendi projektis on umbes 1000 faili.

Struktuuriliselt jaguneb veebiklient suures osas järgmisteks alamsüsteemideks:

• Hallatud kliendirakenduse liides
  • Üldine rakenduse liides (süsteemimenüüd, paneelid)
  • Hallatavate vormide liides, mis sisaldab muuhulgas umbes 30 juhtelementi (nupud, erinevat tüüpi sisestusväljad - tekst, digitaalne, kuupäev/kellaaeg jne, tabelid, loendid, graafikud jne)

• Kliendis arendajatele saadaolev objektimudel (kokku rohkem kui 400 tüüpi: hallatud liidese objektimudel, andmete koostise sätted, tingimuslik vormindamine jne)
• Manustatud keeletõlk 1C
• Brauseri laiendused (kasutatakse funktsioonide jaoks, mida JavaScript ei toeta)
  • Töötamine krüptograafiaga
  • Töötamine failidega
  • Väliste komponentide tehnoloogia, mis võimaldab neid kasutada nii õhukeste kui ka veebiklientide puhul

Arendusfunktsioonid

Kõigi ülaltoodu rakendamine JavaScriptis ei ole lihtne ülesanne. Võib-olla on 1C veebiklient üks suurimaid JavaScriptis kirjutatud kliendipoolseid rakendusi - umbes 450.000 XNUMX rida. Kasutame veebikliendi koodis aktiivselt objektorienteeritud lähenemist, mis lihtsustab nii suure projekti puhul tööd.

Kliendikoodi suuruse minimeerimiseks kasutasime esmalt oma obfuskaatorit ja alates platvormi versioonist 8.3.6 (oktoober 2014) hakkasime kasutama Google'i sulgemise kompilaator. Arvudes kasutamise mõju on veebikliendi raamistiku suurus pärast hägustamist:

• Oma obfuskaator - 1556 kb
• Google Closure Compiler – 1073 kb

Google Closure Compileri kasutamine aitas meil parandada veebikliendi jõudlust 30% võrreldes meie enda obfuskaatoriga. Lisaks on rakenduse poolt tarbitava mälumaht vähenenud 15-25% (olenevalt brauserist).

Google Closure Compiler töötab väga hästi objektorienteeritud koodiga, seega on selle efektiivsus veebikliendi jaoks kõrgeim. Closure Compiler teeb meie jaoks mõned head asjad:

• Staatiline tüübikontroll projekti koostamise etapis (selle põhjuseks on asjaolu, et katame koodi JSDoc märkustega). Tulemuseks on staatiline tippimine, mis on tasemel C++ tippimisele väga lähedane. See aitab projekti koostamise etapis tabada üsna suure protsendi vigadest.
• Koodi suuruse vähendamine hägustamise kaudu
• Mitmed käivitatava koodi optimeerimised, näiteks:
  • funktsioonide sisesed asendused. Funktsiooni väljakutsumine JavaScriptis on üsna kulukas toiming ja sageli kasutatavate väikeste meetodite sisemised asendused võivad koodi oluliselt kiirendada.
  • Konstantide loendamine kompileerimise ajal. Kui avaldis sõltub konstandist, asendatakse see konstandi tegeliku väärtusega

Kasutame oma veebikliendi arenduskeskkonnana WebStormi.

Koodianalüüsiks kasutame soundQube, kus integreerime staatilise koodianalüsaatorid. Analüsaatorite abil jälgime JavaScripti lähtekoodi kvaliteedi halvenemist ja püüame seda ennetada.

Milliseid ülesandeid tegime/lahendame

Projekti elluviimisel seisis silmitsi mitmete huvitavate ülesannetega, mis tuli lahendada.

Andmevahetus serveriga ja akende vahel

On olukordi, kus lähtekoodi hägustamine võib süsteemi tööd häirida. Veebikliendi täitmiskoodi välisel koodil võib hägustamise tõttu olla funktsioonide ja parameetrite nimesid, mis erinevad meie käivitatava koodi ootustest. Meie jaoks on väline kood:

• Andmestruktuuridena serverist tulev kood
• Teise rakenduse akna kood

Et vältida hägusust serveriga suhtlemisel, kasutame @expose märgendit:

/**
 * @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 selleks, et vältida segadust teiste akendega suhtlemisel, kasutame nn eksporditud liideseid (liideseid, milles kõik meetodid eksporditakse).

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

Me kasutasime virtuaalset DOM-i, enne kui sellest sai peavoolu)

Nagu kõik arendajad, kes tegelevad keeruka veebi kasutajaliidesega, mõistsime kiiresti, et DOM ei sobi hästi dünaamiliste kasutajaliidestega. Peaaegu kohe rakendati kasutajaliidesega töö optimeerimiseks virtuaalse DOM-i analoog. Sündmuse töötlemise ajal salvestatakse kõik DOM-i muudatused mällu ja alles siis, kui kõik toimingud on lõpetatud, rakendatakse kogunenud muudatused DOM-i puule.

Veebikliendi optimeerimine

Meie veebikliendi kiiremaks töötamiseks püüame maksimaalselt kasutada brauseri standardseid funktsioone (CSS jne). Niisiis renderdab vormi käsuriba (asub peaaegu kõigil rakenduse vormidel) ainult brauser, CSS-il põhinev dünaamiline paigutus.

Katsetamine

Funktsionaalsuse ja jõudluse testimiseks kasutame oma tööriista (Java ja C++ keeles kirjutatud), samuti testide komplekti, mis on üles ehitatud Seleen.

Meie tööriist on universaalne – see võimaldab testida peaaegu iga aknaprogrammi ning sobib seetõttu nii õhukese kliendi kui ka veebikliendi testimiseks. Tööriist salvestab 1C rakenduse lahenduse käivitanud kasutaja toimingud skriptifaili. Samal ajal salvestatakse ekraani tööpiirkonna kujutised (standardid). Veebikliendi uute versioonide jälgimisel mängitakse stsenaariume ilma kasutaja osaluseta. Juhtudel, kui ekraanipilt ei ühti ühelgi etapil võrdluspildiga, loetakse test ebaõnnestunuks, mille järel viib kvaliteedispetsialist läbi uurimise – kas see on viga või plaanitud muudatus süsteemi käitumises. Planeeritud käitumise korral asenduvad standardid automaatselt uutega.

Tööriist mõõdab ka rakenduse jõudlust 25 millisekundi täpsusega. Mõnel juhul teeme skripti osade tsükliga (näiteks kordame tellimuse kirjet mitu korda), et analüüsida täitmisaja halvenemist aja jooksul. Kõikide mõõtmiste tulemused salvestatakse analüüsimiseks logisse.

Meie testimistööriist ja rakendus testimisel

Meie tööriist ja Seleen täiendavad üksteist; Näiteks kui mõni nupp ühel ekraanil on oma asukohta muutnud - Seleen ei pruugi seda jälgida, kuid meie tööriist märkab, sest teeb ekraanitõmmise pikslite kaupa võrdluse standardiga. Samuti suudab tööriist tuvastada probleeme klaviatuuri või hiire sisendi töötlemisega, kuna just seda see reprodutseerib.

Mõlema tööriista (meie ja seleeni) testid käitavad meie rakenduslahenduste tüüpilisi tööstsenaariume. Testid käivitatakse automaatselt pärast platvormi 1C:Enterprise igapäevast ehitamist. Kui skriptid aeglustuvad (võrreldes eelmise järguga), uurime ja parandame aeglustumise põhjuse. Meie kriteerium on lihtne – uus koost ei tohiks töötada aeglasemalt kui eelmine.

Arendajad kasutavad aeglustusjuhtumite uurimiseks erinevaid tööriistu; peamiselt kasutatud Dynatrace AJAX väljaanne ettevõtte toodang DynaTrace. Salvestatakse probleemse toimingu sooritamise logid eelmisel ja uuel koostul, seejärel analüüsitakse logisid. Samas ei pruugi üksikute toimingute täitmisaeg (millisekundites) olla määrav – teenuseprotsessid nagu prügikoristus käivituvad brauseris perioodiliselt, need võivad kattuda funktsioonide täitmise ajaga ja pilti moonutada. Asjakohasemad parameetrid oleks sel juhul käivitatud JavaScripti käskude arv, DOM-i aatomioperatsioonide arv jne. Kui sama skripti juhiste/toimingute arv uues versioonis on suurenenud, tähendab see peaaegu alati jõudluse langust, mis vajab parandamist.

Samuti võib jõudluse languse üheks põhjuseks olla see, et Google Closure Compiler ei saanud mingil põhjusel funktsiooni sisemist asendust teha (näiteks kuna funktsioon on rekursiivne või virtuaalne). Sel juhul proovime olukorda parandada lähtekoodi ümberkirjutamisega.

Brauseri laiendused

Kui rakendatud lahendus vajab funktsioone, mida JavaScriptis pole, kasutame brauseri laiendusi:

• failidega töötamiseks
• töötada krüptograafiaga
• töötama koos välised komponendid

Meie laiendused koosnevad kahest osast. Esimest osa nimetatakse brauserilaiendiks (tavaliselt JavaScripti laiendused Chrome'i ja Firefoxi jaoks), mis suhtlevad teise osaga, binaarlaiendiga, mis rakendab meile vajalikke funktsioone. Olgu mainitud, et kirjutame binaarlaienditest 3 versiooni – Windowsile, Linuxile ja MacOS-ile. Binaarne laiendus tarnitakse 1C:Enterprise platvormi osana ja see asub 1C rakendusserveris. Esmakordsel veebikliendist helistamisel laaditakse see klientarvutisse ja installitakse brauserisse.

Kui töötate Safaris, kasutavad meie laiendused NPAPI-d; Internet Exploreris töötavad meie laiendused ActiveX-tehnoloogiat. Microsoft Edge ei toeta veel laiendusi, seega töötab veebiklient selles piirangutega.

Edasine areng

Veebikliendi arendusmeeskonna üheks töörühmaks on funktsionaalsuse edasiarendus. Veebikliendi funktsionaalsus peaks olema identne õhukese kliendi funktsionaalsusega, kõik uued funktsionaalsused realiseeritakse samaaegselt nii õhukeses kliendis kui ka veebikliendis.

Muud ülesanded on arhitektuuri arendamine, ümbertöötamine, jõudluse ja töökindluse parandamine. Näiteks üks suundi on edasine liikumine asünkroonse töömudeli poole. Osa veebikliendi funktsionaalsusest on praegu üles ehitatud serveriga suhtlemise sünkroonsele mudelile. Asünkroonmudel muutub nüüd brauserites (ja mitte ainult brauserites) asjakohasemaks ning see sunnib meid muutma veebiklienti, asendades sünkroonsed kõned asünkroonsete kõnedega (ja vastavalt koodi ümber kujundama). Järkjärgulist üleminekut asünkroonsele mudelile seletatakse vajadusega toetada välja antud lahendusi ja neid järk-järgult kohandada.

Allikas: www.habr.com