Einn af góðu eiginleikum 1C:Enterprise tækni er að forritalausnin, þróuð með tækni með stýrðum eyðublöðum, er hægt að ræsa bæði í þunnum (keyranlega) biðlara fyrir Windows, Linux, MacOS X og sem vefbiðlara fyrir 5 vafra - Chrome, Internet Explorer, Firefox, Safari, Edge og allt þetta án þess að breyta frumkóða forritsins. Þar að auki, utan virkar forritið í þunna biðlaranum og í vafranum og lítur nánast eins út.
Finndu 10 mismunandi (2 myndir undir skurðinum):
Þunnur biðlari gluggi á Linux:
Sami gluggi í vefþjóninum (í Chrome vafranum):
Af hverju gerðum við vefþjón? Til að orða það dálítið aumkunarvert hefur tíminn sett okkur slíkt verkefni. Vinna á netinu hefur lengi verið forsenda viðskiptaumsókna. Í fyrsta lagi bættum við við möguleikanum á að vinna í gegnum internetið fyrir þunnan biðlara okkar (sumir keppinautar okkar, við the vegur, hættu þar; aðrir, þvert á móti, yfirgáfu þunna biðlarann og takmarkaðu sig við að innleiða vefbiðlara). Við ákváðum að gefa notendum okkar tækifæri til að velja þann valkost sem hentar þeim best.
Að bæta vefbundnum möguleikum við þunna biðlarann var stórt verkefni með algjörri breytingu á arkitektúr viðskiptavinar-miðlara. Að búa til vefþjón er alveg nýtt verkefni, byrjað frá grunni.
Samsetning vandans
Svo, verkefniskröfurnar: vefþjónninn verður að gera það sama og þunni viðskiptavinurinn, þ.e.
- Sýna notendaviðmót
- Framkvæma kóða viðskiptavinar skrifaður á 1C tungumáli
Notendaviðmótinu í 1C er lýst í sjónrænum ritstjóra, en með yfirlýsandi hætti, án pixla-fyrir-pixla uppröðun þátta; Um það bil þrír tugir tegunda viðmótsþátta eru notaðir - hnappar, innsláttarreitir (texti, tölustafir, dagsetning/tími), listar, töflur, línurit o.s.frv.
Biðlarakóði á 1C tungumálinu getur innihaldið netþjónssímtöl, unnið með staðbundin auðlind (skrár osfrv.), prentun og margt fleira.
Bæði þunni biðlarinn (þegar unnið er í gegnum vefinn) og vefþjónninn nota sama sett af vefþjónustu til að eiga samskipti við 1C forritaþjóninn. Útfærslur viðskiptavinarins eru auðvitað mismunandi - þunni biðlarinn er skrifaður í C++, vefþjónninn er skrifaður í JavaScript.
Smá saga
Vefbiðlaraverkefnið hófst árið 2006, með (að meðaltali) 5 manns teymi. Á ákveðnum stigum verkefnisins tóku verktaki þátt í að innleiða sérstaka virkni (töflureiknisskjal, skýringarmyndir osfrv.); að jafnaði voru þetta sömu forritararnir og gerðu þessa virkni í þunnum biðlara. Þeir. forritarar endurskrifuðu hluti í JavaScript sem þeir höfðu áður búið til í C++.
Frá upphafi höfnuðum við hugmyndinni um hvers kyns sjálfvirka (jafnvel að hluta) umbreytingu á C++ þunnri biðlara kóða í JavaScript vefbiðlara vegna mikils hugmyndafræðilegs munar á tungumálunum tveimur; vefþjónninn var skrifaður í JavaScript frá grunni.
Í fyrstu endurtekningum verkefnisins breytti vefþjónninn kóða viðskiptavinar á innbyggðu 1C tungumálinu beint í JavaScript. Þunni biðlarinn virkar öðruvísi - kóðinn á innbyggða 1C tungumálinu er settur saman í bækakóða og síðan er þessi bækikóði túlkaður á biðlaranum. Í kjölfarið byrjaði vefþjónninn að gera slíkt hið sama - í fyrsta lagi gaf það frammistöðuaukningu og í öðru lagi gerði það mögulegt að sameina arkitektúr þunnra og vefbiðlara.
Fyrsta útgáfan af 1C:Enterprise pallinum með stuðningi við vefþjón var gefin út árið 2009. Vefþjónninn á þeim tíma studdi 2 vafra - Internet Explorer og Firefox. Upprunalegu áætlanirnar innihéldu stuðning við Opera, en vegna óyfirstíganlegra vandamála á þeim tíma með lokun forrita í Opera (ekki var hægt að fylgjast með með 100% vissu að forritið væri að loka, og á því augnabliki framkvæma aftengingarferlið frá kl. 1C forritaþjónninn) úr þessum áætlunum varð að yfirgefa.
Uppbygging verkefnis
Alls hefur 1C:Enterprise pallurinn 4 verkefni skrifuð í JavaScript:
- WebTools – sameiginleg bókasöfn notuð af öðrum verkefnum (við erum líka með ).
- Stjórna (útfært í JavaScript bæði í þunna biðlaranum og vefþjóninum)
- Stjórna (útfært í JavaScript bæði í þunna biðlaranum og vefþjóninum)
- Vef viðskiptavinur
Uppbygging hvers verkefnis líkist uppbyggingu Java verkefna (eða .NET verkefna - hvort sem er nær); Við erum með nafnarými og hvert nafnrými er í sérstakri möppu. Inni í möppunni eru skrár og nafnrýmisflokkar. Það eru um 1000 skrár í vefbiðlaraverkefninu.
Skipulagslega er vefþjóninum að mestu skipt í eftirfarandi undirkerfi:
- Stýrt viðskiptavinaforritsviðmót
- Almennt forritsviðmót (kerfisvalmyndir, spjöld)
- Viðmót stýrðra eyðublaða, þar á meðal meðal annars um 30 stýringar (hnappar, ýmis konar innsláttarreitir - texti, tölur, dagsetning/tími o.s.frv., töflur, listar, línurit o.s.frv.)
- Hlutalíkan í boði fyrir þróunaraðila á viðskiptavininum (yfir 400 tegundir alls: hlutlíkan með stýrðu viðmóti, gagnaútlitsstillingar, skilyrt útlit osfrv.)
- Túlkur innbyggða 1C tungumálsins
- Vafraviðbætur (notaðar fyrir virkni sem ekki er studd í JavaScript)
- Að vinna með dulmál
- Vinna með skrár
- Tækni ytri íhluta, sem gerir þeim kleift að nota bæði í þunna viðskiptavini og vefþjónustur
Þróunareiginleikar
Það er ekki auðvelt að útfæra allt ofangreint í JavaScript. Kannski er 1C vefþjónninn eitt af stærstu forritunum við hlið viðskiptavinarins skrifað í JavaScript - um 450.000 línur. Við notum virkan hlutbundinn nálgun í kóða vefbiðlara, sem auðveldar vinnu með svo stórt verkefni.
Til að lágmarka stærð biðlarakóðans notuðum við fyrst okkar eigin obfuscator og frá og með vettvangsútgáfu 8.3.6 (október 2014) byrjuðum við að nota . Áhrif notkunar í tölum – stærð vefbiðlarakerfisins eftir óskýringu:
- Eigin hyljari – 1556 kb
- Google lokunarþýðandi – 1073 kb
Notkun Google Closure Compiler hjálpaði okkur að bæta afköst vefþjónsins um 30% samanborið við okkar eigin obfuscator. Auk þess hefur minnismagnið sem forritið notar minnkað um 15-25% (fer eftir vafranum).
Google Closure Compiler virkar mjög vel með hlutbundinn kóða, þannig að skilvirkni hans fyrir vefþjóninn er eins mikil og mögulegt er. Closure Compiler gerir nokkra góða hluti fyrir okkur:
- Stöðug gerð athugun á byggingarstigi verkefnisins (tryggir að við hyljum kóðann með JSDoc athugasemdum). Niðurstaðan er kyrrstæð vélritun, mjög nálægt því að slá inn í C++. Þetta hjálpar til við að ná nokkuð stóru hlutfalli villna á stigi verkefnasamsetningar.
- Draga úr kóðastærð með þoku
- Nokkrar fínstillingar á keyrða kóðanum, til dæmis, eins og:
- inline fallaskipti. Það er frekar dýr aðgerð að hringja í fall í JavaScript og innfelldar útskipti á oft notuðum litlum aðferðum flýta verulega fyrir kóðanum.
- Telja fasta á samsetningartíma. Ef tjáning er háð fasta verður raungildi fastans skipt út í hann
Við notum WebStorm sem þróunarumhverfi vefbiðlara.
Fyrir kóðagreiningu notum við , þar sem við samþættum truflanir kóða greiningartæki. Með því að nota greiningartæki fylgjumst við með hnignun gæðum JavaScript frumkóða og reynum að koma í veg fyrir það.
Hvaða vandamál leystum/erum við að leysa?
Við framkvæmd verkefnisins lentum við í ýmsum áhugaverðum vandamálum sem við þurftum að leysa.
Skiptast á gögnum við netþjóninn og á milli glugga
Það eru aðstæður þar sem þoka frumkóðans getur truflað rekstur kerfisins. Kóði sem er utan við keyranlega kóða vefbiðlarans, vegna óskýringar, gæti haft virkni- og færibreytuheiti sem eru frábrugðin þeim sem keyranlegi kóðinn okkar gerir ráð fyrir. Ytri kóðinn fyrir okkur er:
- Kóði sem kemur frá þjóninum í formi gagnabygginga
- Kóði fyrir annan forritsglugga
Til að koma í veg fyrir þoku í samskiptum við netþjóninn notum við @expose merkið:
/**
* @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;
}Og til að koma í veg fyrir þoku í samskiptum við aðra glugga notum við svokölluð útflutt viðmót (viðmót þar sem allar aðferðir eru fluttar út).
/**
* Экспортируемый интерфейс контрола 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 (){}Við notuðum Virtual DOM áður en það varð almennt)
Eins og allir verktaki sem fást við flókin vefviðmót, áttuðum við okkur fljótt á því að DOM hentar illa til að vinna með kraftmikið notendaviðmót. Næstum strax var hliðstæða Virtual DOM innleidd til að hámarka vinnu við HÍ. Við atburðavinnslu eru allar DOM breytingar geymdar í minni og aðeins þegar öllum aðgerðum er lokið eru uppsafnaðar breytingar settar á DOM tréð.
Fínstilling á vefþjóninum
Til að vefþjónninn okkar virki hraðar reynum við að nota staðlaða vaframöguleika (CSS, osfrv.) að hámarki. Þannig er stjórnborð eyðublaðsins (staðsett á næstum öllum gerðum forritsins) eingöngu birt með vafraverkfærum, með kraftmiklu skipulagi byggt á CSS.
Prófun
Fyrir virkni- og frammistöðuprófun notum við sérstakt tól (skrifað í Java og C++), sem og pakka af prófum sem eru byggð ofan á .
Tólið okkar er alhliða - það gerir þér kleift að prófa nánast hvaða gluggaforrit sem er og hentar því til að prófa bæði þunnan biðlara og vefbiðlara. Tólið skráir aðgerðir notandans sem setti 1C forritalausnina af stað í handritaskrá. Á sama tíma eru myndir af vinnusvæði skjásins - staðlar - teknar upp. Þegar fylgst er með nýjum útgáfum af vefþjóninum eru forskriftir spilaðar án þátttöku notenda. Í þeim tilfellum þar sem skjáskotið passar ekki við tilvísunina í hvaða skrefi sem er, telst prófið misheppnað, eftir það framkvæmir gæðasérfræðingur rannsókn til að ákvarða hvort um villu eða fyrirhugaða breytingu á hegðun kerfisins sé að ræða. Ef um fyrirhugaða hegðun er að ræða er stöðlunum sjálfkrafa skipt út fyrir nýja.
Tólið mælir einnig frammistöðu forrita með allt að 25 millisekúndum nákvæmni. Í sumum tilfellum tökum við hluta af handritinu í lykkju (til dæmis, endurtekum pöntunarfærsluna nokkrum sinnum) til að greina hnignun framkvæmdartímans með tímanum. Niðurstöður allra mælinga eru skráðar í dagbók til greiningar.
Prófunartæki okkar og forrit í prófun
Verkfæri okkar og Selen bæta hvert annað upp; til dæmis, ef einhver hnappur á einum af skjánum hefur breytt staðsetningu sinni, gæti Selen ekki rekið þetta, en tólið okkar mun taka eftir því, vegna þess að gerir pixla-fyrir-pixla samanburð á skjámyndinni við staðalinn. Tólið er einnig fær um að fylgjast með vandamálum við vinnslu inntaks frá lyklaborðinu eða músinni, þar sem þetta er nákvæmlega það sem það endurskapar.
Próf á báðum verkfærum (okkar og Selenium) keyra dæmigerðar vinnusviðsmyndir frá forritalausnum okkar. Próf eru sjálfkrafa sett af stað eftir daglega byggingu 1C:Enterprise pallsins. Ef forskriftir eru hægari (samanborið við fyrri smíði) rannsökum við og leysum orsök hægfara. Viðmiðið okkar er einfalt - nýja smíðin ætti ekki að virka hægar en sú fyrri.
Hönnuðir nota mismunandi verkfæri til að rannsaka atvik sem hægja á; aðallega notað framleiðslufyrirtæki . Skrár yfir framkvæmd erfiðu aðgerðarinnar á fyrri og nýjum byggingum eru skráðar, síðan eru annálarnir greindir. Á sama tíma getur framkvæmdartími stakra aðgerða (í millisekúndum) ekki verið afgerandi þáttur - þjónustuferli eins og sorphirðu eru reglulega sett í vafranum, þau geta skarast við framkvæmdartíma aðgerða og brenglað myndina. Meira viðeigandi færibreytur í þessu tilfelli væru fjöldi JavaScript leiðbeininga sem framkvæmdar eru, fjöldi atómaðgerða á DOM osfrv. Ef leiðbeiningum/aðgerðum í sama handriti hefur fjölgað í nýrri útgáfu þýðir það næstum alltaf lækkun á frammistöðu sem þarf að leiðrétta.
Ein af ástæðunum fyrir lækkun á frammistöðu gæti einnig verið sú að Google Closure Compiler gat af einhverjum ástæðum ekki framkvæmt innbyggða skiptingu á aðgerðinni (til dæmis vegna þess að aðgerðin er endurkvæm eða sýndarmynd). Í þessu tilfelli reynum við að leiðrétta ástandið með því að endurskrifa frumkóðann.
Vafraviðbætur
Þegar forritalausn þarfnast virkni sem er ekki tiltæk í JavaScript notum við vafraviðbætur:
- til að vinna með skrár
- fyrir að vinna með dulmál
- vinna með
Viðbætur okkar samanstanda af tveimur hlutum. Fyrri hlutinn er það sem kallast vafraviðbót (venjulega viðbætur fyrir Chrome og Firefox skrifaðar í JavaScript), sem hafa samskipti við seinni hlutann - tvöfalda viðbót sem útfærir þá virkni sem við þurfum. Þess má geta að við skrifum 3 útgáfur af tvöfaldri viðbótum - fyrir Windows, Linux og MacOS. Tvöfaldur viðbótin er til staðar sem hluti af 1C:Enterprise pallinum og er staðsett á 1C forritaþjóninum. Þegar hringt er í fyrsta skipti frá vefbiðlara er honum hlaðið niður á biðlaratölvuna og sett upp í vafranum.
Þegar viðbætur eru keyrðar í Safari nota þær NPAPI; þegar þær keyra í Internet Explorer nota þær ActiveX tækni. styður ekki enn viðbætur, svo vefþjónninn í honum vinnur með takmörkunum.
Frekari þróun
Eitt af verkefnum þróunarteymi vefbiðlara er frekari þróun virkni. Virkni vefþjónsins ætti að vera eins og virkni þunna biðlarans; öll ný virkni er innleidd samtímis í bæði þunnum og vefþjóninum.
Önnur verkefni fela í sér að þróa arkitektúrinn, endurbyggja, bæta frammistöðu og áreiðanleika. Til dæmis er ein áttin frekari hreyfing í átt að ósamstilltu vinnulíkani. Sum virkni vefþjónsins er sem stendur byggð á samstilltu líkani af samskiptum við netþjóninn. Ósamstillta líkanið er nú að verða meira viðeigandi í vöfrum (og ekki aðeins í vöfrum), og þetta neyðir okkur til að breyta vefþjóninum með því að skipta út samstilltum símtölum fyrir ósamstillta (og endurstilla kóðann í samræmi við það). Smám saman umskipti yfir í ósamstillt líkan skýrist af nauðsyn þess að styðja útgefnar lausnir og hægfara aðlögun þeirra.
Heimild: www.habr.com