Üks meeldivamaid omadusi 1C:Ettevõtte tehnoloogias on see, et rakenduslahendus, mis on välja töötatud hallatavate vormide tehnoloogias, saab töötada nii õhukeses (käitatavas) töökliendis Windows, Linux, MacOS X-s kui ka veebikliteena viies brauseris – Chrome, Internet Explorer, Firefox, Safari, Edge, ja kõik see – ilma rakenduse lähtekoodi muutmata. Rohkemgi veel – visuaalselt toimib ja näeb rakendus õhukeses kliendis ja brauseris välja praktiliselt identse.
Leia 10 erinevust (allpool on 2 pilti):
Õhukese kliendi aken Linuxis:
Sama aken veebiklient (brauseris Chrome):
Miks me veebiklienti tegime? Ütleme natuke pidulikumalt, selle ülesande seadis meile aeg. Juba ammu on Internetis töötamine saanud äriorenduste jaoks vajalikuks tingimuseks. Alguses lisasime oma õhukesele kliendile Interneti kaudu töötamise võimaluse (mõned meie konkurendid, muide, jäidki sellele üpjünetele; teised, vastupidi, loobusid õhukesest kliendist ja piirdusid veebiklientide teostamisega). Meie aga otsustasime anda oma kasutajatele võimaluse valida, kumba kliendi varianti nad eelistavad.
Õhukese kliendi jaoks interneti kasutamise võimaluse lisamine oli suur projekt, mis nõudis täielikku kliendi ja serveri vahelise suhtluse arhitektuuri muutmist. Veebikliendi loomine on aga sootuks uus projekt, mis algab nullist.
Ülesande seadmine
Seega on projekti nõuded: veebiklient peab tegema seda, mida teeb õhuke klient, nimelt:
- Kasutajaliidese kuvamine
- 1C keeles kirjutatud kliendikoodi täitmine
Kasutajaliides 1C-s kirjeldatakse visuaalses redigeerijas deklareerival moel, ilma elementide täpse paigutuseta; kasutatakse umbes kolm tosinat erinevat liideselementi — nuppe, sisendvälju (tekst, number, kuupäev/aeg), nimekirju, tabeleid, graafikuid jne.
1C keeles kirjutatud kliendikood võib sisaldada serverikutsungeid, töötada kohalike ressurssidega (failid jne), printida ja palju muud.
N tanto õhuke klient (veebi kaudu töötades) kui ka veebiklient kasutavad sama veebiteenuste komplekti, et suhelda 1C rakendusserveriga. Klientide rakendused on muidugi erinevad – õhuke klient on kirjutatud C++ keeles, veebiklient aga JavaScriptis.
Veidi ajalugu
Veebiklientide arendamise projekt algas 2006. aastal, kus osales keskmiselt 5 inimest. Projekti erinevates etappides tõmmati appi arendajad spetsiifilise funktsionaalsuse (nt tabelid, diagrammid jne) teostamiseks; reeglina olid need samad arendajad, kes selle funktsionaalsuse eelnevalt õhukeses kliendis lõid. See tähendab, et arendajad kirjutasid JavaScriptis uuesti komponendid, mille nad olid varem loonud C++ keeles.
Algusest peale lükkasime tagasi mõtte automaatse (ükskõik kui osalise) C++ koodi konvertimise kohta õhukesest kliendist JavaScripti veebiklientiks, arvestades nende kahe keele tugevaid kontseptuaalseid erinevusi; veebiklient kirjutati JavaScriptis puhtalt lehelt.
Projekti esimestel iteratsioonidel konverteeris veebiklient kliendikoodi 1C sisseehitatud keeles otse JavaScripti. Õhuke klient toimib teisiti – 1C sisseehitatud keeles kirjutatud kood kompileeritakse byte-koodiks, mis seejärel tõlgitakse kliendis. Hiljem hakkas veebiklient sama tegema – esiteks, see tõi kaasa jõudluse kasvu, teiseks võimaldas see unifitseerida õhukese ja veebikliendi arhitektuuri.
1С:Предприятие esimesed veebiklientide toetusega versioon ilmus 2009. aastal. Selle aja veebiklient toetas kahte brauserit – Internet Explorer ja Firefox. Algsetes plaanides oli kavandatud Opera tugi, kuid tookordsete probleemide tõttu rakenduse sulgemise käsitlemises Operas (ei olnud võimalik 100%-liselt jälgida, et rakendus sulguks, ja sellel hetkel serverist 1C rakenduse väljalülitamise protseduuri läbi viia) tuli neist plaanidest loobuda.
Projekti struktuur
1С:Предприятие platvormil on kokku 4 projekti, mis on kirjutatud JavaScriptis:
- WebTools – üldised raamatukogud, mida kasutavad teised projektid (siia kuuluvad ka ).
- Kasutuselemendi (rakendatud JavaScriptis nii õhukliendis kui ka veebikliendis)
- Kasutuselemendi (rakendatud JavaScriptis nii õhukliendis kui ka veebikliendis)
- Veebiklient
Iga projekti struktuur sarnaneb Java projektide (või .NET projektidega – kellele mis sobib) struktuurile; meil on nimed, ja iga nimi asub eraldi kaustas. Kaustas asuvad nimede failid ja klassid. Veebiklientide projektis on ligikaudu 1000 faili.
Struktuuriliselt jaguneb veebiklient peamiselt järgmistesse alamsüsteemidesse:
- Hallatav kliendirakenduse liides
- Rakenduse üldliides (süsteemimenüüd, paneelid)
- Hallatav vormide liides, mis sisaldab kokku umbes 30 juhtnööri (nupud, erinevad sisestusväljade tüübid – tekstilised, numbrilised, kuupäeva/aega jne, tabelid, loetelud, graafikud jne.)
- Objektimudel, mis on ligipääsetav arendajatele kliendis (kokku üle 400 tüübi: hallatava liidese objektimudel, andmete paigutuse seadistused, tingimuslik vormindamine jne.)
- Sisseehitatud keele 1C tõlgendaja
- Brauserilaiendused (kasutatakse funktsionaalsuseks, mida JavaScript ei toeta)
- Krüptograafiaga töötamine
- Failidega töötamine
- Väliste komponentide tehnoloogia, mis võimaldab neid kasutada nii õhukeses kui ka veebikliendis
Arenduse eripärad
Kõik ülaltoodud rakendamine JavaScriptis on keeruline. Võib-olla on 1C veebi klient üks suurimaid klient-poolseid rakendusi, mis on kirjutatud JavaScriptis – umbes 450 000 rida. Me kasutame veebikliendi koodis aktiivselt objekt-orientatsiooni lähenemist, mis hõlbustab nii suure projekti käsitlemist.
Kliendi koodi suuruse minimiseerimiseks kasutasime alguses oma obfuskaatorit, kuid alates platvormi versioonist 8.3.6 (oktober 2014) oleme hakanud kasutama . Obfuskatsiooni mõju numbrites – veebiklientide raamistik pärast obfuskatsiooni:
- Oma obfuskaator – 1556 kB
- Google Closure Compiler – 1073 kB
Google Closure Compiler'i kasutamine aitas meil veebiklientide jõudlust parandada 30% võrreldes meie enda obfuskaatoriga. Samuti vähenes 15-25% (sõltuvalt brauserist) rakenduse mälutarve.
Google Closure Compiler töötab väga hästi objektorienteeritud koodiga, seega on selle efektiivsus veebikliendi jaoks maksimaalne. Closure Compiler teeb meie jaoks paar head asja:
- Projektide kogumise etapis staatiline tüüpide kontroll (tagatud koodi JSDoc'i annotatsioonidega katmise kaudu). Lõpptulemus on staatiline tüpiseerimine, mis on väga sarnane C++ tüpiseerimise tasemega. See aitab kinni püüda piisavalt suure osa vigu projekti kompileerimise etapil.
- Koodi suuruse vähendamine obfuskatsiooni kaudu
- Koodide optimeerimise reaalsed näited, näiteks:
- funktsioonide inline-asendamine. Funktsiooni kutsumine JavaScriptis on üsna kulukas tegevus, ja väikeste sageli kasutatavate meetodite inline-asendamine kiirendab koodi töötlemist oluliselt.
- Konstantide arvestamine kompileerimise etapis. Kui avaldis sõltub konstandist, asendatakse selles kohaliku konstandi tegeliku väärtusega.
Veebiklientide arenduskeskkonnana kasutame WebStormi.
Koodi analüüsimiseks kasutame , kuhu integreerime staatilisi koodi analüsaatoreid. Analüsaatorite abil jälgime JavaScripti lähtekoodi kvaliteedi halvenemist ja püüame seda vältida.
Milliseid ülesandeid oleme lahendanud/lahendame
Projekti teostamise käigus sattusime mitmete huvitavate probleemide ette, mis tuli lahendada.
Andmevahetus serveri ja akende vahel
On olukordi, kus lähtekoodi obfuskeering võib takistada süsteemi tööd. Obfuskeeritud kood, mis on eraldi meie veebiklientide välisest koodist, võib omada funktsioonide ja parameetrite nimesid, mis erinevad sellest, mida meie käivitatav kood ootab. Meie jaoks on väline kood:
- Serverist tulev kood struktureeritud andmete vormis
- Teise rakenduse akna kood
Serveriga suhtlemisel obfuskatsiooni vältimiseks kasutame märgendit @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;
}Ja et vältida obfuskatsiooni teiste akendega suhtlemisel, kasutame nn eksporditavaid liideseid (liideseid, millel on kõik meetodid eksporditavad).
/**
* Экспортируемый интерфейс контрола 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 (){}KASUTASIME Virtuaalset DOM-i enne, kui see sai peavooluks)
Nagu kõik arendajad, kes tegelevad keerulise veebiliidesega, mõistsime kiiresti, et DOM ei sobi dünaamilise kasutajaliidese jaoks. Peaaegu kohe loodi Virtuaalse DOM-i analoog, et optimeerida töötlust UI-ga. Ürituste töötlemise käigus salvestatakse kõik DOMi muudatused mällu ning alles pärast kõigi operatsioonide lõpetamist rakendatakse kogutud muudatused DOM-puud.
Veebi-kliendi töö optimeerimine
Kuna me soovime, et meie veebiklient töötaks kiiremini, püüame maksimaalselt kasutada brauseri vaikimisi funktsioone (CSS jne). Seega joonistatakse vormi käsukonsool (mis asub põhimõtteliselt igas rakenduse vormis) ainult brauseri vahendite ja CSS-i põhjal enamasti dünaamilise paigutuse kaudu.
Testimine
Funktsionaalse testimise ja jõudlustestimise jaoks kasutame meie enda arendatud tööriista (kirjutatud Java ja C++ keeles), samuti testide kogumit, mis põhineb .
Meie tööriist on universaalne – see võimaldab testida praktiliselt kõiki aknaprogramme, mistõttu sobib see nii õhukese kliendi kui ka veebikliendi testimiseks. Tööriist salvestab kasutaja toimingud, kes käivitas rakenduse "1C", skriptifaili. Samal ajal tehakse ekraani tööaluse ala piltide – etalonide – salvestamine. Uute veebikliendi versioonide kontrollimisel mängitakse skripte ilma kasutaja sekkumiseta. Kui mõnel testietapis skriinipilt ei vasta etalonile, loetakse test ebaõnnestunuks, mille järel kvaliteedi spetsialist viib läbi uurimise – kas see on viga või etteplaneeritud süsteemi käitumise muutus. Etteplaneeritud käitumise korral asendatakse etalonid automaatselt uutega.
Tööriist mõõdab rakenduste jõudlust kuni 25 millisekundi täpsusega. Mõnel juhul kordame stsenaariumi osi (näiteks tellimuse sisestamist mitu korda) täitmise ajade halvenemise analüüsimiseks. Kõik mõõtmiste tulemused registreeritakse analüüsiks logis.
Meie testimisvahend ja testitav rakendus
Meie tööriist ja Selenium täiendavad üksteist; näiteks, kui mõni nupp ühe ekraani peal on oma asukohta muutnud — Selenium ei pruugi seda jälgida, kuid meie tööriist märgib selle kinni, kuna teeb täpse piksliga võrdluse ekraanipildist alusversiooniga. Tööriist suudab jälgida ka klaviatuuri või hiire sisendiga seotud probleeme, kuna just neid ta ka kordab.
Testid mõlemal tööriistal (meie ja Selenium) käivitavad tüüpilised stsenaariumid meie rakenduslahendustest. Testid käivitatakse automaatselt pärast igapäevast „1C:Enterprise” platvormi versiooni. Kui stsenaariumide töö aeglustub (võrreldes eelmise versiooniga), uurime juhtumit ja kõrvaldame aeglustumise põhjuse. Meie kriteerium on lihtne – uus versioon peab töötama mitte aeglasemalt kui eelmine.
Aegluse juhtumite uurimiseks kasutavad arendajad erinevaid tööriistu; peamiselt kasutatakse ettevõtte . Probleemse operatsiooni logide salvestamine toimub nii eelnevas kui ka uues versioonis, seejärel analüüsitakse logisid. Üksikute operatsioonide täitmise aeg (millisekundites) ei pruugi olla määrav tegur – brauseris käivitatakse aeg-ajalt teenusprotsesse, nagu mäluhaldus, mis võivad kattuda funktsioonide täitmise ajaga ja moonutada pilti. Sel juhul on asjakohasemad parameetrid JavaScripti käsuridade arv, DOMi aatomsete toimingute arv jne. Kui uue versiooni puhul on sama stsenaariumi käskude/toimingute arv suurenenud, tähendab see peaaegu alati jõudluse langust, mida on vaja parandada.
Samuti võib jõudluse languse põhjuseks olla see, et Google Closure Compiler ei suutnud mingil põhjusel funktsiooni inline-asendust teostada (näiteks kui funktsioon on rekursiivne või virtuaalne). Sel juhul püüame olukorda parandada, kirjutades lähtekoodi ümber.
Brauseri laiendused
Kui rakendusele on vajalik funktsionaalsus, mida JavaScriptis pole, kasutame brauseri laiendusi:
- failidega töötamiseks
- krüptograafiaga töötamiseks
- töötamine
Meie laiendused koosnevad kahest osast. Esimene osa on see, mida nimetatakse brauseri laienduseks (tavaliselt JavaScripti laiendused Chrome'i ja Firefoxi jaoks), mis suhtleb teise osaga — binaarse laiendusega, mis implementeerib vajaliku funktsionaalsuse. Tuleb mainida, et me kirjutame 3 versiooni binaarsetest laiendustest – Windowsi, Linuxi ja MacOS-i jaoks. Binaarne laiendus tarnitakse 1C:Enterprise platvormiga ja asub 1C rakenduste serveris. Esimese veebiklientide kutse korral laaditakse see klienditeenuse arvutisse ja installitakse brauserisse.
Safari kasutamisel kasutavad meie laiendused NPAPI-d, Internet Exploreri kasutades ActiveX-tehnoloogiat. ei toeta veel laiendusi, seega töötab veebiklient seal piirangutega.
edasiarendamine
Üks veebikliendi arendusmeeskonna ülesannetest on funktsionaalsuse edasine arendamine. Veebikliendi funktsionaalsus peab olema identne õhukese kliendi funktsionaalsusega, kogu uus funktsionaalsus rakendatakse samal ajal nii õhukeses kui ka veebikliendis.
Teised ülesanded hõlmavad arhitektuuri arendamist, refaktooringut, jõudluse ja usaldusväärsuse parandamist. Näiteks üks suund on liikuda edasi asünkroonse töömudeli suunas. Praegu on osa veebikliendi funktsionaalsusest rajatud sünkroonsele serveriga suhtlemise mudelile. Asünkroonne mudel muutub nüüd brauserites (ja mitte ainult brauserites) üha aktuaalsemaks, mis sunnib meid veebikliendi modifitseerimisele, asendades sünkroonsed kõned asünkroonsetega (ja vastava koodi refaktooringuga). Üleminek asünkroonsele mudelile toimub järk-järgult vajaduse tõttu toetada välja antud lahendusi ja nende järk-järgulist kohandamist.
Allikas: habr.com
