Jednou z pekných vlastností technológie 1C:Enterprise je, že aplikačné riešenie vyvinuté pomocou technológie spravovaných formulárov je možné spustiť v tenkom (spustiteľnom) klientovi pre Windows, Linux, MacOS X a ako webový klient pre 5 prehliadačov – Chrome, Internet Explorer, Firefox, Safari, Edge a to všetko bez zmeny zdrojového kódu aplikácie. Navyše navonok aplikácia v tenkom klientovi a v prehliadači funguje a vyzerá takmer identicky.
Nájdite 10 rozdielov (2 obrázky pod strihom):
Okno tenkého klienta v systéme Linux:
Rovnaké okno vo webovom klientovi (v prehliadači Chrome):
Prečo sme vytvorili webového klienta? Trochu pateticky povedané, čas nám dal takúto úlohu. Práca cez internet je už dlho nevyhnutnou podmienkou pre obchodné aplikácie. Najprv sme pre nášho tenkého klienta pridali možnosť pracovať cez internet (niektorí naši konkurenti sa nad tým mimochodom zastavili, iní naopak tenkého klienta opustili a obmedzili sa na implementáciu webového klienta). Rozhodli sme sa dať našim používateľom možnosť vybrať si klientsku možnosť, ktorá im najviac vyhovuje.
Pridanie webových možností do tenkého klienta bol veľký projekt s úplnou zmenou v architektúre klient-server. Vytvorenie webového klienta je úplne nový projekt, ktorý začína od nuly.
Vyhlásenie o probléme
Takže požiadavky projektu: webový klient musí urobiť to isté ako tenký klient, a to:
- Zobraziť používateľské rozhranie
- Spustite klientsky kód napísaný v jazyku 1C
Používateľské rozhranie v 1C je opísané vo vizuálnom editore, ale deklaratívne, bez usporiadania prvkov pixel po pixeli; Používajú sa asi tri desiatky typov prvkov rozhrania – tlačidlá, vstupné polia (textové, číselné, dátum/čas), zoznamy, tabuľky, grafy atď.
Klientsky kód v jazyku 1C môže obsahovať serverové volania, prácu s lokálnymi zdrojmi (súbory atď.), tlač a oveľa viac.
Tenký klient (pri práci cez web) aj webový klient používajú na komunikáciu s aplikačným serverom 1C rovnakú sadu webových služieb. Klientske implementácie sú samozrejme rôzne – tenký klient je napísaný v C++, webový klient je napísaný v JavaScripte.
Trocha histórie
Projekt webového klienta začal v roku 2006, s tímom (v priemere) 5 ľudí. V určitých fázach projektu boli vývojári zapojení do implementácie špecifických funkcií (tabuľkový dokument, diagramy atď.); spravidla to boli tí istí vývojári, ktorí túto funkcionalitu robili v tenkom klientovi. Tie. vývojári prepísali komponenty v JavaScripte, ktoré predtým vytvorili v C++.
Od samého začiatku sme odmietali myšlienku akejkoľvek automatickej (aj čiastočnej) konverzie kódu tenkého klienta C++ na webového klienta JavaScript z dôvodu veľkých koncepčných rozdielov medzi týmito dvoma jazykmi; webový klient bol napísaný v JavaScripte od začiatku.
V prvých iteráciách projektu webový klient konvertoval klientsky kód v zabudovanom jazyku 1C priamo do JavaScriptu. Tenký klient sa správa inak – kód v zabudovanom jazyku 1C sa skompiluje do bajtkódu a následne sa tento bajtkód interpretuje na klientovi. Následne to začal robiť aj webový klient – po prvé zvýšil výkon a po druhé umožnil zjednotiť architektúru tenkého a webového klienta.
Prvá verzia platformy 1C:Enterprise s podporou webového klienta bola vydaná v roku 2009. Webový klient v tom čase podporoval 2 prehliadače – Internet Explorer a Firefox. Pôvodné plány zahŕňali podporu pre Operu, ale kvôli neprekonateľným problémom v tom čase s obsluhou zatvárania aplikácií v Opere (nebolo možné so 100% istotou sledovať, že sa aplikácia zatvára, a v tom momente vykonať procedúru odpojenia od aplikačný server 1C) z týchto plánov sa muselo opustiť.
Štruktúra projektu
Celkovo má platforma 1C:Enterprise 4 projekty napísané v JavaScripte:
- WebTools – zdieľané knižnice používané inými projektmi (vrátane ).
- Ovládací prvok (implementované v JavaScripte v tenkom aj webovom klientovi)
- Ovládací prvok (implementované v JavaScripte v tenkom aj webovom klientovi)
- Webový klient
Štruktúra každého projektu sa podobá štruktúre Java projektov (alebo .NET projektov – podľa toho, čo je bližšie); Máme menné priestory a každý menný priestor je v samostatnom priečinku. V priečinku sú súbory a triedy názvov. V projekte webového klienta je asi 1000 súborov.
Štrukturálne je webový klient z veľkej časti rozdelený do nasledujúcich podsystémov:
- Rozhranie spravovanej klientskej aplikácie
- Všeobecné aplikačné rozhranie (systémové menu, panely)
- Rozhranie spravovaných formulárov zahŕňajúce okrem iného cca 30 ovládacích prvkov (tlačidlá, rôzne typy vstupných polí - textové, číselné, dátum/čas atď., tabuľky, zoznamy, grafy atď.)
- Objektový model dostupný vývojárom na klientovi (celkom viac ako 400 typov: objektový model spravovaného rozhrania, nastavenia rozloženia údajov, podmienený štýl atď.)
- Tlmočník vstavaného jazyka 1C
- Rozšírenia prehliadača (používajú sa pre funkcie, ktoré nie sú podporované v JavaScripte)
- Práca s kryptografiou
- Práca so súbormi
- Technológia externých komponentov umožňujúca ich použitie v tenkých aj webových klientoch
Funkcie vývoja
Implementácia všetkého vyššie uvedeného v JavaScripte nie je jednoduchá. Možno je webový klient 1C jednou z najväčších aplikácií na strane klienta napísaných v JavaScripte - asi 450.000 XNUMX riadkov. V kóde webového klienta aktívne využívame objektovo orientovaný prístup, ktorý zjednodušuje prácu s takým veľkým projektom.
Aby sme minimalizovali veľkosť klientskeho kódu, najprv sme použili vlastný obfuskátor a od verzie platformy 8.3.6 (október 2014) sme začali používať . Efekt použitia v číslach – veľkosť rámca webového klienta po zahmlení:
- Vlastný obfuskátor – 1556 kb
- Google Closure Compiler – 1073 kb
Použitie Google Closure Compiler nám pomohlo zlepšiť výkon webového klienta o 30 % v porovnaní s naším vlastným obfuskátorom. Okrem toho sa množstvo pamäte spotrebovanej aplikáciou znížilo o 15 – 25 % (v závislosti od prehliadača).
Google Closure Compiler veľmi dobre pracuje s objektovo orientovaným kódom, takže jeho efektivita pre webového klienta je čo najvyššia. Closure Compiler pre nás robí niekoľko dobrých vecí:
- Statická kontrola typu vo fáze zostavovania projektu (zabezpečuje, že kód pokryjeme anotáciami JSDoc). Výsledkom je statické písanie, ktoré je svojou úrovňou veľmi blízke písanie v C++. Pomáha to zachytiť pomerne veľké percento chýb vo fáze zostavovania projektu.
- Zmenšenie veľkosti kódu prostredníctvom zahmlievania
- Množstvo optimalizácií vykonávaného kódu, napríklad:
- inline náhrady funkcií. Volanie funkcie v JavaScripte je pomerne nákladná operácia a inline substitúcie často používaných malých metód výrazne zrýchľujú kód.
- Počítanie konštánt v čase kompilácie. Ak výraz závisí od konštanty, dosadí sa do nej skutočná hodnota konštanty
WebStorm používame ako naše vývojové prostredie pre webového klienta.
Na analýzu kódu používame , kde integrujeme analyzátory statického kódu. Pomocou analyzátorov sledujeme zhoršovanie kvality zdrojového kódu JavaScriptu a snažíme sa mu predchádzať.
Aké problémy riešime/riešime?
Počas realizácie projektu sme sa stretli s množstvom zaujímavých problémov, ktoré sme museli riešiť.
Vymieňajte si údaje so serverom a medzi oknami
Existujú situácie, keď zahmlievanie zdrojového kódu môže narušiť fungovanie systému. Kód, ktorý je mimo spustiteľného kódu webového klienta, môže mať z dôvodu zahmlenia názvy funkcií a parametrov, ktoré sa líšia od tých, ktoré očakáva náš spustiteľný kód. Externý kód pre nás je:
- Kód prichádzajúci zo servera vo forme dátových štruktúr
- Kód pre ďalšie okno aplikácie
Aby sme sa vyhli zmätku pri interakcii so serverom, používame značku @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;
}A aby sme sa vyhli zahmlievaniu pri interakcii s inými oknami, používame takzvané exportované rozhrania (rozhrania, v ktorých sa exportujú všetky metódy).
/**
* Экспортируемый интерфейс контрола 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 (){}Virtual DOM sme používali skôr, ako sa stal hlavným prúdom)
Ako všetci vývojári, ktorí sa zaoberajú zložitými webovými používateľskými rozhraniami, rýchlo sme si uvedomili, že DOM nie je vhodný na prácu s dynamickými používateľskými rozhraniami. Takmer okamžite bol implementovaný analóg virtuálneho DOM na optimalizáciu práce s používateľským rozhraním. Počas spracovania udalostí sú všetky zmeny DOM uložené v pamäti a až po dokončení všetkých operácií sa nahromadené zmeny aplikujú na strom DOM.
Optimalizácia webového klienta
Aby náš webový klient fungoval rýchlejšie, snažíme sa maximálne využívať možnosti štandardného prehliadača (CSS a pod.). Panel príkazov formulára (nachádza sa takmer na každej forme aplikácie) sa teda vykresľuje výlučne pomocou nástrojov prehliadača s použitím dynamického rozloženia založeného na CSS.
Testovanie
Na testovanie funkčnosti a výkonu používame vlastný nástroj (napísaný v jazyku Java a C++), ako aj sadu testov postavených na .
Náš nástroj je univerzálny – umožňuje testovať takmer akýkoľvek okenný program, a preto je vhodný na testovanie tenkého aj webového klienta. Nástroj zaznamenáva akcie používateľa, ktorý spustil riešenie aplikácie 1C, do súboru skriptu. Súčasne sa zaznamenávajú obrazy pracovnej oblasti obrazovky - štandardy. Pri monitorovaní nových verzií webového klienta sa skripty prehrávajú bez účasti používateľa. V prípadoch, keď sa snímka obrazovky v žiadnom kroku nezhoduje s referenčnou, test sa považuje za neúspešný, po ktorom odborník na kvalitu vykoná vyšetrovanie, aby zistil, či ide o chybu alebo plánovanú zmenu v správaní systému. V prípade plánovaného správania sa normy automaticky nahrádzajú novými.
Nástroj tiež meria výkon aplikácie s presnosťou až 25 milisekúnd. V niektorých prípadoch zacyklíme časti skriptu (napríklad niekoľkokrát zopakujeme zadanie objednávky), aby sme analyzovali degradáciu času vykonávania v priebehu času. Výsledky všetkých meraní sa zaznamenávajú do denníka na analýzu.
Náš testovací nástroj a testovaná aplikácia
Náš nástroj a Selén sa navzájom dopĺňajú; ak napríklad niektoré tlačidlo na jednej z obrazoviek zmenilo svoje umiestnenie, Selenium to nemusí sledovať, ale náš nástroj si to všimne, pretože vykoná porovnanie snímky obrazovky po jednotlivých pixeloch so štandardom. Nástroj je tiež schopný sledovať problémy so spracovaním vstupu z klávesnice alebo myši, pretože presne to reprodukuje.
Testy na oboch nástrojoch (našom a Selenium) spúšťajú typické pracovné scenáre z našich aplikačných riešení. Testy sa spúšťajú automaticky po každodennom zostavovaní platformy 1C:Enterprise. Ak sú skripty pomalšie (v porovnaní s predchádzajúcou zostavou), skúmame a riešime príčinu spomalenia. Naše kritérium je jednoduché – nová zostava by nemala fungovať pomalšie ako predchádzajúca.
Vývojári používajú rôzne nástroje na vyšetrovanie incidentov spomalenia; hlavne používané výrobná spoločnosť . Zaznamenávajú sa protokoly o vykonaní problematickej operácie na predchádzajúcich a nových zostavách a následne sa protokoly analyzujú. Čas vykonávania jednotlivých operácií (v milisekundách) zároveň nemusí byť rozhodujúcim faktorom - servisné procesy ako garbage collection sa v prehliadači spúšťajú pravidelne, môžu sa prekrývať s časom vykonávania funkcií a skresľovať obraz. Relevantnejšími parametrami by v tomto prípade bol počet vykonaných inštrukcií JavaScriptu, počet atómových operácií na DOM atď. Ak sa v novej verzii zvýšil počet inštrukcií/operácií v rovnakom skripte, takmer vždy to znamená pokles výkonu, ktorý je potrebné opraviť.
Jedným z dôvodov poklesu výkonu môže byť aj to, že kompilátor Google Closure Compiler z nejakého dôvodu nedokázal vykonať inline substitúciu funkcie (napríklad preto, že funkcia je rekurzívna alebo virtuálna). V tomto prípade sa snažíme situáciu napraviť prepísaním zdrojového kódu.
Rozšírenia prehliadača
Keď aplikačné riešenie vyžaduje funkčnosť, ktorá nie je dostupná v JavaScripte, používame rozšírenia prehliadača:
- pre prácu so súbormi
- pre prácu s kryptografiou
- pracovať s
Naše rozšírenia pozostávajú z dvoch častí. Prvá časť je to, čo sa nazýva rozšírenie prehliadača (zvyčajne rozšírenia pre Chrome a Firefox napísané v JavaScripte), ktoré interagujú s druhou časťou - binárnym rozšírením, ktoré implementuje funkcie, ktoré potrebujeme. Treba spomenúť, že píšeme 3 verzie binárnych rozšírení – pre Windows, Linux a MacOS. Binárne rozšírenie je dodávané ako súčasť platformy 1C:Enterprise a nachádza sa na aplikačnom serveri 1C. Pri prvom volaní z webového klienta sa stiahne do klientskeho počítača a nainštaluje sa do prehliadača.
Pri spustení v Safari používajú naše rozšírenia NPAPI, pri spustení v Internet Exploreri využívajú technológiu ActiveX. zatiaľ nepodporuje rozšírenia, takže webový klient v ňom funguje s obmedzeniami.
Ďalší vývoj
Jednou z úloh vývojového tímu webového klienta je ďalší rozvoj funkcionality. Funkcionalita webového klienta by mala byť totožná s funkcionalitou tenkého klienta, všetky nové funkcionality sú implementované súčasne do tenkého aj webového klienta.
Medzi ďalšie úlohy patrí vývoj architektúry, refaktorovanie, zlepšovanie výkonu a spoľahlivosti. Jedným zo smerov je napríklad ďalší pohyb smerom k asynchrónnemu pracovnému modelu. Niektoré funkcie webového klienta sú v súčasnosti postavené na synchrónnom modeli interakcie so serverom. Asynchrónny model je teraz v prehliadačoch (a nielen v prehliadačoch) relevantnejší a to nás núti upravovať webového klienta nahradením synchrónnych volaní asynchrónnymi (a podľa toho refaktorovať kód). Postupný prechod na asynchrónny model sa vysvetľuje potrebou podpory uvoľnených riešení a ich postupným prispôsobovaním.
Zdroj: hab.com