Az 1C:Enterprise technológia egyik kedves tulajdonsága, hogy a menedzselt űrlapok technológiájával kifejlesztett alkalmazásmegoldás Windows, Linux, MacOS X vékony (futtatható) kliensben és 5 böngésző webes kliensként is elindítható - Chrome, Internet Explorer, Firefox, Safari, Edge, és mindez az alkalmazás forráskódjának megváltoztatása nélkül. Sőt, kívülről az alkalmazás a vékonykliensben és a böngészőben szinte azonosan működik és néz ki.
Keress 10 különbséget (2 kép a vágás alatt):
Vékony kliens ablak Linuxon:
Ugyanez az ablak a webkliensben (a Chrome böngészőben):
Miért csináltunk webklienst? Kissé szánalmasan fogalmazva, az idő ilyen feladatot állított elénk. Az internetes munkavégzés régóta előfeltétele az üzleti alkalmazásoknak. Először is hozzáadtuk a vékonykliensünk számára az interneten keresztüli munkavégzés lehetőségét (egyes versenytársaink egyébként megálltak itt, mások éppen ellenkezőleg, elhagyták a vékonyklienst, és webes kliens megvalósítására korlátozódtak). Úgy döntöttünk, hogy lehetőséget adunk felhasználóinknak a számukra legmegfelelőbb ügyféllehetőség kiválasztására.
A webalapú képességek hozzáadása a vékonyklienshez nagy projekt volt, amely teljes mértékben megváltoztatta a kliens-szerver architektúrát. A webes kliens létrehozása egy teljesen új projekt, amely a nulláról indul.
Probléma nyilatkozat
Tehát a projekt követelményei: a webes kliensnek ugyanazt kell tennie, mint a vékony kliensnek, nevezetesen:
- Felhasználói felület megjelenítése
- 1C nyelven írt klienskód végrehajtása
Az 1C felhasználói felületét egy vizuális szerkesztőben írják le, de deklaratív módon, az elemek pixelenkénti elrendezése nélkül; Körülbelül három tucat féle interfész elemet használnak - gombok, beviteli mezők (szöveg, numerikus, dátum/idő), listák, táblázatok, grafikonok stb.
Az 1C nyelvű ügyfélkód tartalmazhat szerverhívásokat, helyi erőforrásokkal (fájlok stb.) való munkát, nyomtatást és még sok mást.
Mind a vékony kliens (ha a weben keresztül dolgozik), mind a webes kliens ugyanazt a webszolgáltatás-készletet használja az 1C alkalmazáskiszolgálóval való kommunikációhoz. A kliens implementációk természetesen eltérőek – a vékony kliens C++-ban, a webes kliens JavaScriptben íródott.
Egy kis történelem
A webes kliens projekt 2006-ban indult, (átlagosan) 5 fős csapattal. A projekt bizonyos szakaszaiban fejlesztőket vontak be meghatározott funkciók megvalósításához (táblázatos dokumentum, diagramok stb.); általában ugyanazok a fejlesztők végezték ezt a funkciót a vékonykliensben. Azok. a fejlesztők JavaScriptben újraírták azokat a komponenseket, amelyeket korábban C++-ban készítettek.
Kezdettől fogva elutasítottuk a C++ vékonykliens kódok bármiféle automatikus (akár részleges) konvertálását JavaScript webklienssé, mivel a két nyelv között erős fogalmi különbségek vannak; a webklienst a semmiből JavaScriptben írták.
A projekt első iterációiban a webkliens a beépített 1C nyelvű klienskódot közvetlenül JavaScript-be konvertálta. A vékony kliens másként működik - a beépített 1C nyelv kódja bájtkódba kerül lefordításra, majd ezt a bájtkódot értelmezi az ügyfélen. Ezt követően a webes kliens is hozzákezdett - egyrészt teljesítménynövekedést adott, másrészt lehetővé tette a vékony és webes kliens architektúrájának egységesítését.
Az 1C:Enterprise platform első verziója webes kliens támogatással 2009-ben jelent meg. A webes kliens akkoriban 2 böngészőt támogatott - Internet Explorer és Firefox. Az eredeti tervekben szerepelt az Opera támogatása is, de az akkori áthidalhatatlan problémák miatt az Opera alkalmazásbezárási kezelőivel (nem lehetett 100%-os biztonsággal nyomon követni, hogy az alkalmazás bezárul, és abban a pillanatban a leválasztási procedúrát elvégezni az 1C alkalmazásszervert) ezekből a tervekből el kellett hagyni.
Projekt szerkezete
Összességében az 1C:Enterprise platform 4 projektet tartalmaz JavaScriptben:
- WebTools – más projektek által használt megosztott könyvtárak (beleértjük ).
- Vezérlőelem (JavaScriptben implementálva vékony kliensben és webes kliensben is)
- Vezérlőelem (JavaScriptben implementálva vékony kliensben és webes kliensben is)
- Web kliens
Az egyes projektek felépítése hasonlít a Java projektek (vagy .NET projektek – attól függően, hogy melyik áll közelebb) szerkezetéhez; Vannak névtereink, és minden névtér külön mappában található. A mappában fájlok és névtér osztályok találhatók. A webes kliens projektben körülbelül 1000 fájl található.
Szerkezetileg a webes kliens nagyrészt a következő alrendszerekre oszlik:
- Felügyelt kliens alkalmazás felület
- Általános alkalmazási felület (rendszermenük, panelek)
- Kezelt űrlapok felülete, amely többek között körülbelül 30 vezérlőt tartalmaz (gombok, különféle típusú beviteli mezők - szöveg, numerikus, dátum/idő stb., táblázatok, listák, grafikonok stb.)
- A fejlesztők számára elérhető objektummodell a kliensen (összesen több mint 400 típus: felügyelt interfész objektummodell, adatelrendezési beállítások, feltételes stílus stb.)
- A beépített 1C nyelv tolmácsa
- Böngészőbővítmények (a JavaScript által nem támogatott funkciókhoz használják)
- Titkosított munka
- Fájlokkal való munka
- Külső komponensek technológiája, amely lehetővé teszi vékony és webes kliensekben egyaránt
Fejlesztési jellemzők
A fentiek megvalósítása JavaScriptben nem egyszerű. Talán az 1C webes kliens az egyik legnagyobb JavaScriptben írt kliensoldali alkalmazás – körülbelül 450.000 XNUMX sor. Aktívan használunk objektum-orientált megközelítést a webes kliens kódban, ami leegyszerűsíti a munkát egy ilyen nagy projekttel.
Az ügyfélkód méretének minimalizálása érdekében először saját obfuszkátort használtunk, és a 8.3.6-os platformverziótól (2014. október) kezdtük el használni. . A számokban való használat hatása – a webes kliens keretrendszer mérete az obfuszkálás után:
- Saját obfuszkátor – 1556 kb
- Google Closure Compiler – 1073 kb
A Google Closure Compiler használatával 30%-kal javíthattuk a webes kliens teljesítményét a saját obfuszkátorunkhoz képest. Ráadásul az alkalmazás által fogyasztott memória mennyisége 15-25%-kal csökkent (böngészőtől függően).
A Google Closure Compiler nagyon jól működik objektumorientált kóddal, így a webes kliens számára a lehető legmagasabb a hatékonysága. A Closure Compiler néhány jót tesz nekünk:
- Statikus típusellenőrzés a projekt összeállítási szakaszában (biztosítja, hogy a kódot JSDoc megjegyzésekkel fedjük le). Az eredmény a statikus gépelés, amely nagyon közel áll a C++ nyelvű gépeléshez. Ez segít a hibák meglehetősen nagy százalékának kiszűrésében a projekt összeállítási szakaszában.
- A kód méretének csökkentése homályosítással
- A végrehajtott kód számos optimalizálása, például:
- soron belüli függvényhelyettesítések. Egy függvény meghívása JavaScriptben meglehetősen költséges művelet, és a gyakran használt kis metódusok soron belüli helyettesítése jelentősen felgyorsítja a kódot.
- Konstansok számolása fordítási időben. Ha egy kifejezés egy konstanstól függ, akkor a konstans tényleges értéke behelyettesítésre kerül
Webkliens fejlesztői környezetünkként a WebStormot használjuk.
Kódelemzéshez használjuk , ahol statikus kódelemzőket integrálunk. Analizátorok segítségével figyeljük a JavaScript forráskód minőségének romlását, és igyekszünk megakadályozni.
Milyen problémákat oldottunk meg/megoldunk?
A projekt megvalósítása során számos érdekes problémával találkoztunk, amelyeket meg kellett oldanunk.
Adatcsere a szerverrel és az ablakok között
Vannak olyan helyzetek, amikor a forráskód zavarása zavarhatja a rendszer működését. A webes kliens futtatható kódján kívüli kódnak az obfuszkáció miatt a függvény- és paraméternevek eltérhetnek a futtatható kódunktól elvárttól. A külső kód számunkra:
- A szerverről adatstruktúrák formájában érkező kód
- Kód egy másik alkalmazás ablakhoz
A szerverrel való interakció során a zavarás elkerülése érdekében az @expose címkét használjuk:
/**
* @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;
}És hogy elkerüljük a zavarást, amikor más ablakokkal kommunikálunk, úgynevezett exportált felületeket használunk (olyan felületeket, amelyeken az összes metódust exportálják).
/**
* Экспортируемый интерфейс контрола 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 (){}Virtuális DOM-ot használtunk, mielőtt általánossá vált)
Mint minden összetett webes felhasználói felülettel foglalkozó fejlesztő, mi is hamar rájöttünk, hogy a DOM nem alkalmas a dinamikus felhasználói felületekkel való együttműködésre. Szinte azonnal bevezetésre került a Virtual DOM analógja a felhasználói felülettel való munka optimalizálása érdekében. Az eseményfeldolgozás során az összes DOM-módosítás a memóriában tárolódik, és csak akkor, ha minden művelet befejeződött, a felhalmozott változtatásokat a rendszer a DOM-fára alkalmazza.
A webkliens optimalizálása
A webes kliensünk gyorsabb működése érdekében igyekszünk maximálisan kihasználni a standard böngésző képességeit (CSS, stb.). Így az űrlapparancspanel (amely az alkalmazás szinte minden formáján található) kizárólag böngészőeszközökkel, CSS-alapú dinamikus elrendezéssel jelenik meg.
tesztelés
A funkcionális és teljesítménytesztekhez egy szabadalmaztatott eszközt (Java és C++ nyelven írva), valamint egy tesztcsomagot használunk, amely a .
Eszközünk univerzális - szinte bármilyen ablakos program tesztelését teszi lehetővé, ezért vékony kliens és webes kliens tesztelésére egyaránt alkalmas. Az eszköz egy szkriptfájlba rögzíti annak a felhasználónak a műveleteit, aki elindította az 1C alkalmazásmegoldást. Ezzel egyidejűleg rögzítik a képernyő munkaterületének képeit - szabványokat. A webes kliens új verzióinak figyelésekor a szkriptek felhasználói részvétel nélkül kerülnek lejátszásra. Abban az esetben, ha a képernyőkép egyik lépésben sem egyezik a referencia képpel, a teszt sikertelennek minősül, majd minőségügyi szakember vizsgálatot végez, hogy megállapítsa, hibáról vagy a rendszer viselkedésében tervezett változásról van-e szó. Tervezett viselkedés esetén a szabványok automatikusan újakra cserélődnek.
Az eszköz az alkalmazások teljesítményét is méri, akár 25 ezredmásodperces pontossággal. Egyes esetekben a szkript egyes részeit hurkoljuk (például többször megismételjük a parancsbejegyzést), hogy elemezzük a végrehajtási idő időbeli romlását. Az összes mérés eredményét naplóban rögzítjük elemzés céljából.
Tesztelőeszközünk és alkalmazásunk tesztelés alatt
Eszközünk és a szelén kiegészítik egymást; ha például az egyik képernyő valamelyik gombja megváltoztatta a helyét, a Selenium ezt nem követheti nyomon, de az eszközünk észreveszi, mert pixelenként összehasonlítja a képernyőképet a standarddal. Az eszköz képes nyomon követni a billentyűzetről vagy az egérről érkező bevitel feldolgozásával kapcsolatos problémákat is, mivel pontosan ezt reprodukálja.
Mindkét eszköz (a miénk és a Selenium) tesztjei tipikus munkaforgatókönyveket futtatnak az alkalmazási megoldásainkból. A tesztek automatikusan elindulnak az 1C:Enterprise platform napi felépítése után. Ha a szkriptek lassabbak (az előző buildhez képest), megvizsgáljuk és megoldjuk a lassulás okát. A mi kritériumunk egyszerű - az új build nem működhet lassabban, mint az előző.
A fejlesztők különböző eszközöket használnak a lassulási események kivizsgálására; főleg használt termelő cég . A problémás művelet végrehajtásának naplóit rögzíti az előző és az új buildeken, majd a naplókat elemzi. Ugyanakkor az egyes műveletek végrehajtási ideje (ezredmásodpercben) nem feltétlenül döntő tényező - a szolgáltatási folyamatok, például a szemétgyűjtés időszakosan elindulnak a böngészőben, átfedhetik a funkciók végrehajtási idejét, és torzíthatják a képet. A relevánsabb paraméterek ebben az esetben a végrehajtott JavaScript utasítások száma, a DOM-on végrehajtott atomi műveletek száma stb. Ha ugyanabban a szkriptben az utasítások/műveletek száma megnőtt egy új verzióban, az szinte mindig teljesítménycsökkenést jelent, amit javítani kell.
A teljesítmény csökkenésének egyik oka az is lehet, hogy a Google Closure Compiler valamilyen okból nem tudta végrehajtani a funkció soron belüli helyettesítését (például azért, mert a függvény rekurzív vagy virtuális). Ebben az esetben a forráskód átírásával próbáljuk korrigálni a helyzetet.
Böngészőbővítmények
Ha egy alkalmazásmegoldásnak olyan funkciókra van szüksége, amelyek nem érhetők el a JavaScriptben, akkor böngészőbővítményeket használunk:
- fájlokkal való munkához
- kriptográfiával való munkához
- dolgozik vele
Bővítéseink két részből állnak. Az első rész az úgynevezett böngészőbővítmény (általában a Chrome-hoz és a Firefoxhoz JavaScriptben írt kiterjesztések), amelyek kölcsönhatásba lépnek a második résszel - egy bináris kiterjesztéssel, amely megvalósítja a szükséges funkciókat. Meg kell említeni, hogy a bináris kiterjesztések 3 verzióját írjuk - Windows, Linux és MacOS számára. A bináris kiterjesztést az 1C:Enterprise platform részeként szállítjuk, és az 1C alkalmazáskiszolgálón található. Amikor először hívják meg egy webes kliensről, a rendszer letölti az ügyfélszámítógépre, és telepíti a böngészőbe.
Ha Safariban fut, bővítményeink NPAPI-t, Internet Explorerben pedig ActiveX technológiát használnak. még nem támogatja a bővítményeket, így a benne lévő webkliens korlátozásokkal működik.
További fejlődés
A webkliens-fejlesztő csapat egyik feladata a funkcionalitás továbbfejlesztése. A webkliens funkcionalitásának meg kell egyeznie a vékonykliens funkcionalitásával, minden új funkcionalitás egyszerre kerül megvalósításra a vékony és webes kliensekben.
A további feladatok közé tartozik az architektúra fejlesztése, az átalakítás, a teljesítmény és a megbízhatóság javítása. Például az egyik irány a további mozgás egy aszinkron munkamodell felé. A webes kliens egyes funkciói jelenleg a szerverrel való interakció szinkron modelljére épülnek. Az aszinkron modell manapság egyre relevánsabb a böngészőkben (és nem csak a böngészőkben), és ez arra kényszerít bennünket, hogy módosítsuk a webklienst úgy, hogy a szinkron hívásokat aszinkronra cseréljük (és ennek megfelelően alakítsuk át a kódot). Az aszinkron modellre való fokozatos átállást a kiadott megoldások támogatásának és fokozatos adaptációjának szükségessége magyarázza.
Forrás: will.com