Ien fan 'e moaie skaaimerken fan 1C: Enterprise technology is dat de applikaasje-oplossing, ûntwikkele mei technology foar beheare formulieren, kin wurde lansearre sawol yn in tinne (útfierbere) client foar Windows, Linux, MacOS X, en as in webklient foar 5 browsers - Chrome, Internet Explorer, Firefox, Safari, Edge, en dit alles sûnder de boarnekoade fan 'e applikaasje te feroarjen. Boppedat, ekstern funksjonearret en sjocht de applikaasje yn 'e tinne client en yn' e browser hast identyk.
Fyn 10 ferskillen (2 ôfbyldings ûnder de besuniging):
Thin client-finster op Linux:
Itselde finster yn 'e webclient (yn' e Chrome-blêder):
Wêrom hawwe wy in webkliïnt makke? Om it wat jammerdearlik te sizzen, de tiid hat ús sa'n taak steld. Wurkje oer it ynternet is al lang in betingst west foar bedriuwsapplikaasjes. Earst hawwe wy de mooglikheid tafoege om fia it ynternet te wurkjen foar ús tinne kliïnt (guon fan ús konkurrinten, trouwens, stoppe dêr; oaren, krekt oarsom, ferlitte de tinne kliïnt en beheine har ta it ymplementearjen fan in webkliïnt). Wy besletten om ús brûkers de kâns te jaan om de klantopsje te kiezen dy't by harren past.
It tafoegjen fan web-basearre mooglikheden oan 'e tinne kliïnt wie in grut projekt mei in folsleine feroaring yn client-server-arsjitektuer. It meitsjen fan in webkliïnt is in folslein nij projekt, begjinnend fanôf it begjin.
Probleemintwurding
Dat, de projekteasken: de webkliïnt moat itselde dwaan as de tinne kliïnt, nammentlik:
- Display brûkersynterface
- Klantkoade útfiere skreaun yn 1C-taal
De brûkersynterface yn 1C wurdt beskreaun yn in fisuele bewurker, mar declaratively, sûnder pixel-by-pixel arrangement fan eleminten; Sawat trije dozen soarten ynterface-eleminten wurde brûkt - knoppen, ynfierfjilden (tekst, numerike, datum / tiid), listen, tabellen, grafiken, ensfh.
Kliïntkoade yn 'e 1C-taal kin serveroproppen befetsje, wurkje mei lokale boarnen (bestannen, ensfh.), Ofdrukke, en folle mear.
Sawol de tinne client (by it wurkjen fia it web) en de webclient brûke deselde set webtsjinsten om te kommunisearjen mei de 1C-applikaasjetsjinner. Client-ymplemintaasjes binne fansels oars - de tinne kliïnt is skreaun yn C ++, de webkliïnt is skreaun yn JavaScript.
In bytsje skiednis
It webkliïntprojekt begûn yn 2006, mei in team fan (gemiddeld) 5 minsken. Op bepaalde stadia fan it projekt waarden ûntwikkelders belutsen by it útfieren fan spesifike funksjonaliteit (spreadsheetdokumint, diagrammen, ensfh.); yn 'e regel wiene dit deselde ûntwikkelders dy't dizze funksjonaliteit diene yn' e tinne client. Dy. ûntwikkelders skreaunen komponinten opnij yn JavaSkript dy't se earder makke hiene yn C ++.
Fan it begjin ôf wegere wy it idee fan elke automatyske (sels foar in part) konverzje fan C ++ tinne client-koade yn JavaScript-webkliïnt fanwegen de sterke konseptuele ferskillen tusken de twa talen; de webkliïnt is fanôf it begjin yn JavaScript skreaun.
Yn 'e earste iteraasjes fan it projekt konvertearre de webkliïnt kliïntkoade yn' e ynboude 1C-taal direkt yn JavaScript. De tinne kliïnt wurket oars - de koade yn 'e ynboude 1C-taal wurdt kompilearre yn bytekoade, en dan wurdt dizze bytekoade ynterpretearre op' e kliïnt. Dêrnei begon de webkliïnt itselde te dwaan - as earste joech it in prestaasjeswinst, en twadde makke it it mooglik om de arsjitektuer fan 'e tinne en webkliïnten te ferienigjen.
De earste ferzje fan it 1C: Enterprise-platfoarm mei stipe foar webkliïnten waard yn 2009 frijlitten. De webclient op dat stuit stipe 2 browsers - Internet Explorer en Firefox. De orizjinele plannen omfette stipe foar Opera, mar fanwegen ûnoerkombere problemen op dat stuit mei de ôfsluting fan 'e applikaasje yn Opera (it wie net mooglik om mei 100% wissichheid te folgjen dat de applikaasje slute, en op dat stuit de ferbiningsproseduere út te fieren fan de 1C-applikaasjetsjinner) fan dizze plannen moasten wurde ferlitten.
Projektstruktuer
Yn totaal hat it 1C: Enterprise platfoarm 4 projekten skreaun yn JavaScript:
- WebTools - dielde bibleteken brûkt troch oare projekten (wy omfetsje ek ).
- Kontrôle elemint (Ymplementearre yn JavaScript yn sawol de tinne client as de webclient)
- Kontrôle elemint (Ymplementearre yn JavaScript yn sawol de tinne client as de webclient)
- Web client
De struktuer fan elk projekt liket op de struktuer fan Java-projekten (of .NET-projekten - wat it tichtste is); Wy hawwe nammeromten, en elke nammeromte is yn in aparte map. Binnen de map binne d'r bestannen en nammeromteklassen. D'r binne sawat 1000 bestannen yn it webkliïntprojekt.
Struktureel is de webclient foar in grut part ferdield yn de folgjende subsystemen:
- Beheare client applikaasje ynterface
- Algemiene applikaasje-ynterface (systeemmenu's, panielen)
- Ynterface fan beheare formulieren, ynklusyf, ûnder oaren, sawat 30 kontrôles (knoppen, ferskate soarten ynfierfjilden - tekst, numerike, datum / tiid, ensfh., Tabellen, listen, grafiken, ensfh.)
- Objektmodel beskikber foar ûntwikkelders op 'e kliïnt (mear dan 400 soarten yn totaal: managed ynterface-objektmodel, ynstellings foar gegevenslayout, betingsten styling, ensfh.)
- Interpreter fan 'e ynboude 1C-taal
- Browser-tafoegings (brûkt foar funksjonaliteit net stipe yn JavaScript)
- Wurkje mei kryptografy
- Wurkje mei triemmen
- Technology fan eksterne komponinten, wêrtroch't se kinne wurde brûkt yn sawol tinne as webkliïnten
Untwikkelingsfunksjes
It útfieren fan al it boppesteande yn JavaScript is net maklik. Miskien is de 1C-webkliïnt ien fan 'e grutste applikaasjes oan' e kant fan 'e kliïnt skreaun yn JavaScript - sawat 450.000 rigels. Wy brûke aktyf in objekt-rjochte oanpak yn 'e webklientkoade, wat it wurkjen mei sa'n grut projekt simplifies makket.
Om de grutte fan 'e kliïntkoade te minimalisearjen, brûkten wy earst ús eigen obfuscator, en begjinnend mei platfoarmferzje 8.3.6 (oktober 2014) begûnen wy te brûken . It effekt fan gebrûk yn sifers - de grutte fan it ramt foar webkliïnt nei obfuscation:
- Eigen obfuscator - 1556 kb
- Google Closure Compiler - 1073 kb
It brûken fan Google Closure Compiler holp ús de prestaasjes fan 'e webklient mei 30% te ferbetterjen yn ferliking mei ús eigen obfuscator. Derneist is de hoemannichte ûnthâld konsumeare troch de applikaasje mei 15-25% ôfnommen (ôfhinklik fan 'e browser).
Google Closure Compiler wurket hiel goed mei objekt-rjochte koade, sadat syn effisjinsje foar de web client is sa heech mooglik. Closure Compiler docht in pear goede dingen foar ús:
- Statyske typekontrôle yn 'e projektboufaze (soarget derfoar dat wy de koade dekke mei JSDoc-annotaasjes). It resultaat is statysk typen, heul ticht yn nivo fan typen yn C ++. Dit helpt om in frij grut persintaazje flaters te fangen yn 'e projektkompilaasjestadium.
- Koadegrutte ferminderje troch obfuscaasje
- In oantal optimisaasjes fan 'e útfierde koade, bygelyks, lykas:
- inline funksje substitúsjes. In funksje oproppe yn JavaSkript is in frij djoere operaasje, en ynline ferfangings fan faak brûkte lytse metoaden fersnelle de koade signifikant.
- Konstanten telle op kompilaasjetiid. As in útdrukking ôfhinklik is fan in konstante, sil de eigentlike wearde fan 'e konstante dêryn wurde ferfongen
Wy brûke WebStorm as ús ûntwikkelingsomjouwing foar webkliïnten.
Foar koade-analyze brûke wy , dêr't wy yntegrearje statyske koade analyzers. Mei help fan analysatoren kontrolearje wy de degradaasje fan 'e kwaliteit fan JavaScript-boarnekoade en besykje it te foarkommen.
Hokker problemen hawwe/binne wy oplost?
By de útfiering fan it projekt kamen wy in oantal nijsgjirrige problemen tsjin dy't wy oplosse moasten.
Gegevens útwikselje mei de tsjinner en tusken finsters
D'r binne situaasjes wêrby't obfuscaasje fan 'e boarnekoade kin ynterferearje mei de wurking fan it systeem. Koade ekstern foar de útfierbere koade fan 'e webkliïnt, fanwegen obfuscaasje, kin funksje- en parameternammen hawwe dy't ferskille fan dyjingen dy't ús útfierbere koade ferwachtet. De eksterne koade foar ús is:
- Koade dy't komt fan 'e tsjinner yn' e foarm fan gegevensstruktueren
- Koade foar in oar applikaasjefinster
Om obfuscation te foarkommen by ynteraksje mei de tsjinner, brûke wy de @expose tag:
/**
* @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;
}En om obfuscation te foarkommen by ynteraksje mei oare finsters, brûke wy saneamde eksportearre ynterfaces (ynterfaces wêryn alle metoaden wurde eksportearre).
/**
* Экспортируемый интерфейс контрола 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 (){}Wy brûkten Virtual DOM foardat it mainstream waard)
Lykas alle ûntwikkelders dy't mei komplekse web-UI's dwaande binne, realisearren wy fluch dat de DOM min geskikt is om te wurkjen mei dynamyske brûkersynterfaces. Hast fuortendaliks waard in analoog fan Virtual DOM ymplementearre om wurk mei de UI te optimalisearjen. Tidens it ferwurkjen fan eveneminten wurde alle DOM-wizigingen opslein yn it ûnthâld en allinich as alle operaasjes foltôge binne, wurde de opboude wizigingen tapast op 'e DOM-beam.
Optimalisearje de webklient
Om ús webkliïnt flugger te meitsjen, besykje wy de standert browsermooglikheden (CSS, ensfh.) Maksimaal te brûken. Sa, it formulier kommando paniel (leit op hast elke foarm fan de applikaasje) wurdt werjûn eksklusyf mei help fan blêder ark, mei help fan dynamyske yndieling basearre op CSS.
Testing
Foar funksjonele en prestaasjestesten brûke wy in proprietêr ark (skreaun yn Java en C++), lykas ek in suite fan tests boud boppe op .
Us ark is universeel - it lit jo hast alle finsterprogramma's testen, en is dêrom geskikt foar it testen fan sawol in tinne kliïnt as in webkliïnt. It ark registrearret de aksjes fan 'e brûker dy't de 1C-applikaasje-oplossing lansearre yn in skriptbestân. Tagelyk wurde ôfbyldings fan it wurkgebiet fan it skerm - noarmen - opnommen. By it kontrolearjen fan nije ferzjes fan 'e webclient, wurde skripts spile sûnder dielname fan brûkers. Yn gefallen dêr't it skermôfbylding net oerienkomt mei de referinsje op elke stap, wurdt de test beskôge as mislearre, wêrnei't in kwaliteitsspesjalist in ûndersyk docht om te bepalen oft dit in flater is of in plande feroaring yn it gedrach fan it systeem. Yn gefal fan pland gedrach wurde de noarmen automatysk ferfongen troch nije.
It ark mjit ek applikaasjeprestaasjes mei in krektens fan maksimaal 25 millisekonden. Yn guon gefallen lûke wy dielen fan it skript (bygelyks, it werheljen fan de oarderynfier ferskate kearen) om de degradaasje fan útfieringstiid oer de tiid te analysearjen. De resultaten fan alle mjittingen wurde opnommen yn in logboek foar analyse.
Us testynstrumint en applikaasje ûnder test
Us ark en Selenium komplementearje inoar; Bygelyks, as guon knop op ien fan 'e skermen syn lokaasje feroare hat, kin Selenium dit miskien net folgje, mar ús ark sil fernimme, om't makket in piksel-by-piksel ferliking fan de skermprint mei de standert. It ark is ek yn steat om problemen te folgjen mei it ferwurkjen fan ynfier fan it toetseboerd of de mûs, om't dit krekt is wat it reprodusearret.
Tests op beide ark (ús en Selenium) rinne typyske wurksenario's út fan ús applikaasje-oplossingen. Tests wurde automatysk lansearre nei de deistige bou fan it 1C: Enterprise platfoarm. As skripts stadiger binne (yn ferliking mei de foarige build), ûndersiikje en oplosse wy de oarsaak fan 'e fertraging. Us kritearium is ienfâldich - de nije bou moat net stadiger wurkje as de foarige.
Untwikkelders brûke ferskate ark om ynsidinten fan fertraging te ûndersykjen; benammen brûkt produksje bedriuw . Logs fan 'e útfiering fan' e problematyske operaasje op 'e foarige en nije builds wurde opnommen, dan wurde de logs analysearre. Tagelyk kin de útfieringstiid fan inkele operaasjes (yn millisekonden) net in beslissende faktor wêze - tsjinstprosessen lykas garbage collection wurde periodyk yn 'e browser lansearre, se kinne oerlaapje mei de útfieringstiid fan funksjes en it byld fersteure. Mear relevante parameters yn dit gefal soe it oantal útfierde JavaScript-ynstruksjes wêze, it oantal atomêre operaasjes op 'e DOM, ensfh. As it oantal ynstruksjes/operaasjes yn itselde skript yn in nije ferzje tanommen is, betsjut dit hast altyd in drop yn prestaasjes dy't korrizjearre wurde moat.
Ek kin ien fan 'e redenen foar de drop yn prestaasjes wêze dat Google Closure Compiler om ien of oare reden net yn steat wie om inline-ferfanging fan' e funksje út te fieren (bygelyks om't de funksje rekursyf of firtueel is). Yn dit gefal besykje wy de situaasje te korrigearjen troch de boarnekoade opnij te skriuwen.
Browser tafoegings
As in applikaasje-oplossing funksjonaliteit nedich hat dy't net beskikber is yn JavaScript, brûke wy browser-útwreidingen:
- foar wurkjen mei triemmen
- foar wurkjen mei kryptografy
- wurkje mei
Us útwreidings besteane út twa dielen. It earste diel is wat in browser-útwreiding neamd wurdt (meastentiids tafoegings foar Chrome en Firefox skreaun yn JavaScript), dy't ynteraksje mei it twadde diel - in binêre tafoeging dy't de funksjonaliteit ymplementearret dy't wy nedich binne. It moat neamd wurde dat wy 3 ferzjes fan binêre tafoegings skriuwe - foar Windows, Linux en MacOS. De binêre tafoeging wurdt levere as ûnderdiel fan it 1C: Enterprise platfoarm en leit op de 1C applikaasje tsjinner. As it foar de earste kear fan in webkliïnt wurdt neamd, wurdt it ynladen nei de kliïntkompjûter en ynstalleare yn 'e browser.
As jo rinne yn Safari, brûke ús tafoegings NPAPI; as se rinne yn Internet Explorer, brûke se ActiveX-technology. stipet noch gjin tafoegings, sadat de webclient dêryn wurket mei beheiningen.
Fierdere ûntwikkeling
Ien fan 'e taken foar it ûntwikkelteam fan webkliïnten is de fierdere ûntwikkeling fan funksjonaliteit. De funksjonaliteit fan 'e webkliïnt moat identyk wêze oan' e funksjonaliteit fan 'e tinne kliïnt; alle nije funksjonaliteit wurdt tagelyk ymplementearre yn sawol de tinne as webkliïnten.
Oare taken omfetsje it ûntwikkeljen fan de arsjitektuer, refactoring, ferbetterjen fan prestaasjes en betrouberens. Bygelyks, ien fan 'e rjochtingen is fierdere beweging nei in asynchrone wurkmodel. Guon fan 'e funksjonaliteit fan' e webkliïnt is op it stuit boud op in syngroane model fan ynteraksje mei de tsjinner. It asynchrone model wurdt no relevanter yn browsers (en net allinich yn browsers), en dit twingt ús om de webkliïnt te wizigjen troch syngroane oproppen te ferfangen mei asynchrone (en de koade dêrop te refaktorearjen). De stadige oergong nei in asynchrone model wurdt ferklearre troch de needsaak om frijjûn oplossingen te stypjen en har graduele oanpassing.
Boarne: www.habr.com