Адной з прыемных асаблівасцяў тэхналогіі 1С:Прадпрыемства з'яўляецца тое, што прыкладное рашэнне, распрацаванае па тэхналогіі кіраваных формаў, можа запускацца як у тонкім (выкананым) кліенце пад Windows, Linux, MacOS X, так і як вэб-кліент пад 5 браўзэраў – Chrome, Internet Explorer, Firefox, Safari, Edge, і ўсё гэта - без змены зыходнага кода прыкладання. Больш за тое - знешне прыкладанне ў тонкім кліенце і ў браўзэры функцыянуе і выглядае практычна ідэнтычна.
Знайдзіце 10 адрозненняў (пад катом 2 карцінкі):
Акно тонкага кліента на Linux:
Тое ж акно ў вэб кліенце (у браўзэры Chrome):
Навошта мы зрабілі вэб-кліент? Кажучы крыху пафасна, такую задачу перад намі паставіў час. Ужо даўно праца праз Інтэрнэт стала неабходнай умовай для бізнес-прыкладанняў. Спачатку мы дадалі магчымасць працы праз Інтэрнэт для нашага тонкага кліента (некаторыя нашы канкурэнты, дарэчы, на гэтым і спыніліся; іншыя, наадварот, адмовіліся ад тонкага кліента і абмежаваліся рэалізацыяй вэб-кліента). Мы ж вырашылі даць нашым карыстальнікам магчымасць выбраць той варыянт кліента, які ім больш падыходзіць.
Даданне магчымасці працы праз Інтэрнэт для тонкага кліента было вялікім праектам з поўнай зменай архітэктуры кліент-сервернага ўзаемадзеяння. Стварэнне ж вэб-кліента – і зусім новы праект, які пачынаўся з нуля.
Пастаноўка задачы
Такім чынам, патрабаванні да праекту: вэб-кліент павінен рабіць тое ж самае, што і тонкі кліент, а менавіта:
- Адлюстроўваць карыстацкі інтэрфейс
- Выконваць кліенцкі код, напісаны на мове 1С
Карыстацкі інтэрфейс у 1С апісваецца ў візуальным рэдактары, але дэкларатыўна, без папіксэльнай расстаноўкі элементаў; выкарыстоўваецца каля трох дзясяткаў тыпаў элементаў інтэрфейсу - кнопкі, палі ўводу (тэкставыя, лічбавыя, дата/час), спісы, табліцы, графікі і г.д.
Кліенцкі код на мове 1С можа ўтрымоўваць у сабе серверныя выклікі, працу з лакальнымі рэсурсамі (файламі і да т.п.), друк і шматлікае іншае.
І тонкі кліент (пры працы праз вэб), і вэб-кліент карыстаюцца адным і тым жа наборам вэб-сэрвісаў для зносін з серверам прыкладанняў 1С. Рэалізацыя ў кліентаў, вядома, розная - тонкі кліент напісаны на З ++, вэб-кліент - на JavaScript.
Трохі гісторыі
Праект стварэння вэб-кліента стартаваў у 2006 годзе, у ім (у сярэднім) удзельнічала каманда з 5 чалавек. На асобных этапах праекта прыцягваліся распрацоўшчыкі для рэалізацыі спецыфічнай функцыянальнасці (таблічнага дакумента, дыяграм і г.д.); як правіла, гэта былі тыя ж распрацоўшчыкі, што рабілі гэтую функцыянальнасць у тонкім кліенце. Г.зн. распрацоўшчыкі зноўку пісалі на JavaScript кампаненты, раней створаныя імі на C++.
З самага пачатку мы адпрэчылі ідэю які-небудзь аўтаматычнай (хоць бы частковай) канверсіі C++ кода тонкага кліента ў JavaScript вэб-кліента з прычыны моцных канцэптуальных адрозненняў гэтых дзвюх моў; вэб-кліент пісаўся на JavaScript з чыстага ліста.
У першых ітэрацыях праекту вэб-кліент канвертаваў кліенцкі код на ўбудаванай мове 1С непасрэдна ў JavaScript. Тонкі кліент паступае інакш - код на ўбудаванай мове 1С кампілюецца ў байт-код, і затым гэты байт-код інтэрпрэтуецца на кліенце. Пасля гэтак жа стаў рабіць і вэб-кліент - па-першае, гэта дало выйгрыш у прадукцыйнасці, па-другое - дазволіла уніфікаваць архітэктуру тонкага і вэб-кліентаў.
Першая версія платформы 1С:Прадпрыемства з падтрымкай вэб-кліента выйшла ў 2009 годзе. Вэб-кліент на той момант падтрымліваў 2 браўзэра - Internet Explorer і Firefox. У першапачатковых планах была падтрымка Opera, але з-за непераадольных на той момант праблем з апрацоўшчыкамі зачынення прыкладання ў Opera (не атрымоўвалася са 100%-ной упэўненасцю адсачыць, што прыкладанне зачыняецца, і ў гэты момант вырабіць працэдуру адключэння ад сервера прыкладанняў 1С) ад гэтых планаў прыйшлося адмовіцца.
Структура праекту
Усяго ў платформе 1С:Прадпрыемства ёсць 4 праекты, напісаных на JavaScript:
- WebTools – агульныя бібліятэкі, якія выкарыстоўваюцца астатнімі праектамі (сюды ж мы ўключаем ).
- Элемент кіравання (рэалізаваны на JavaScript і ў тонкім кліенце, і ў вэб-кліенце)
- Элемент кіравання (рэалізаваны на JavaScript і ў тонкім кліенце, і ў вэб-кліенце)
- Вэб-кліент
Структура кожнага праекта нагадвае структуру Java-праектаў (або. NET праектаў - каму што бліжэй); у нас ёсць неймспейсы, і кожны неймспейс ляжыць у асобнай тэчцы. Унутры тэчкі ляжаць файлы і класы нэймспейс. У праекце вэб-кліента каля 1000 файлаў.
Структурна вэб-кліент па-буйному падзяляецца на наступныя падсістэмы:
- Кіраваны інтэрфейс кліенцкага прыкладання
- Агульны інтэрфейс прыкладання (сістэмныя меню, панэлі)
- Інтэрфейс кіраваных формаў, улучальны, у тым ліку, каля 30 элементаў кіравання (кнопкі, розныя тыпы палёў уводу – тэкставыя, лічбавыя, дата/час і інш., табліцы, спісы, графікі і т.д.)
- Аб'ектная мадэль, даступная распрацоўнікам на кліенце (усяго больш за 400 тыпаў: аб'ектная мадэль кіраванага інтэрфейсу, налады кампаноўкі дадзеных, умоўнага афармлення і інш.)
- Інтэрпрэтатар убудаванай мовы 1С
- Пашырэння браўзэраў (выкарыстоўваюцца для функцыянальнасці, якая не падтрымліваецца ў JavaScript)
- Праца з крыптаграфіяй
- Праца з файламі
- Тэхналогія знешніх кампанент, якая дазваляе іх выкарыстоўваць як у тонкім, так і вэб-кліенце
Асаблівасці распрацоўкі
Рэалізацыя ўсяго вышэйапісанага на JavaScript - справа няпростая. Магчыма, вэб-кліент 1С - адно з самых вялікіх client-side прыкладанняў, напісаных на JavaScript - каля 450.000 радкоў. Мы актыўна выкарыстоўваем у кодзе вэб-кліента аб'ектна-арыентаваны падыход, які спрашчае працу з такім вялікім праектам.
Для мінімізацыі памеру кліенцкага кода мы спачатку выкарыстоўвалі свой уласны абфускатар, а пачынаючы з версіі платформы 8.3.6 (кастрычнік 2014) сталі выкарыстоўваць . Эфект выкарыстання ў лічбах - памер фрэймворка вэб-кліента пасля абфускацыі:
- Уласны абфускатар - 1556 кб
- Google Closure Compiler - 1073 кб
Выкарыстанне Google Closure Compiler дапамагло нам павысіць хуткадзейнасць вэб-кліента на 30% у параўнанні з нашым уласным абфускатарам. Акрамя таго, на 15-25% (у залежнасці ад браўзэра) знізіўся аб'ём памяці, спажыванай дадаткам.
Google Closure Compiler вельмі добрае працуе з аб'ектна-арыентаваным кодам, таму яго эфектыўнасць менавіта для вэба-кліента максімальна высокая. Closure Compiler робіць для нас некалькі добрых рэчаў:
- Статычная праверка тыпаў на этапе зборкі праекту (забяспечваецца тым, што мы пакрываем код анатацыямі JSDoc). У выніку атрымліваецца статычная тыпізацыя, вельмі блізкая па ўзроўні да тыпізацыі ў З ++. Гэта дапамагае адлавіць дастаткова вялікі працэнт памылак на стадыі кампіляцыі праекта.
- Памяншэнне памеру кода праз абфускацыю
- Шэраг аптымізацый выкананага кода, напрыклад, такія як:
- inline-падстаноўкі функцый. Выклік функцыі ў JavaScript - досыць дарагая аперацыя, і inline-падстаноўкі часта выкарыстоўваных невялікіх метадаў істотна паскараюць працу кода.
- Падлік канстант на этапе кампіляцыі. Калі выраз залежыць ад канстанты, у яго будзе падстаўлена фактычнае значэнне канстанты.
У якасці асяроддзя распрацоўкі вэб-кліента мы выкарыстоўваем WebStorm.
Для аналізу кода мы выкарыстоўваем , куды інтэгруемся статычныя аналізатары кода. З дапамогай аналізатараў мы адсочваем дэградацыю якасці зыходнага кода на JavaScript і імкнемся яе не дапушчаць.
Якія задачы вырашалі/вырашаем
Падчас рэалізацыі праекту мы сутыкнуліся з шэрагам цікавых задач, якія нам прыйшлося вырашаць.
Абмен дадзенымі з серверам і паміж вокнамі
Існуюць сітуацыі, калі абфускаванне зыходнага кода можа перашкодзіць працы сістэмы. Код, вонкавы ў адносінах да выкананага кода вэб-кліента, з прычыны абфускацыі можа мець імёны функцый і параметраў, адрозныя ад тых, якія наш выкананы код чакае. Вонкавым кодам для нас з'яўляецца:
- Код, які прыходзіць з сервера ў выглядзе структур дадзеных
- Код іншага акна прыкладання
Каб пазбегнуць абфускацыі пры ўзаемадзеянні з серверам мы выкарыстоўваем тэг @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;
}А каб пазбегнуць абфускацыі пры ўзаемадзеянні з іншымі вокнамі мы выкарыстоўваем так званыя экспартуемыя інтэрфейсы (інтэрфейсы, у якіх усе метады з'яўляюцца экспартуемымі).
/**
* Экспортируемый интерфейс контрола 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 перад it bebece mainstream)
Як і ўсе распрацоўшчыкі, якія маюць справу са складаным Вэб UI, мы хутка зразумелі, што DOM дрэнна падыходзіць для працы з дынамічным карыстацкім інтэрфейсам. Практычна адразу быў рэалізаваны аналаг Virtual DOM для аптымізацыі працы з UI. У працэсе апрацоўкі падзеі ўсе змены DOM запамінаюцца ў памяці і, толькі пры завяршэнні ўсіх аперацый, назапашаныя змены прымяняюцца да DOM-дрэву.
Аптымізацыя працы вэб-кліента
Каб наш вэб-кліент працаваў хутчэй, мы па максімуме імкнемся задзейнічаць штатныя магчымасці браўзэра (CSS і да т.п.). Так, камандная панэль формы (размешчаная практычна на кожнай форме прыкладання) адмалёўваецца выключна сродкамі браўзэра, дынамічнай вёрсткай на базе CSS.
Тэставанне
Для функцыянальнага тэставання і тэставанні прадукцыйнасці мы выкарыстаем прыладу ўласнай вытворчасці (напісаны на Java і C++), а таксама набор тэстаў, пабудаваных на базе .
Наш інструмент універсальны - ён дазваляе тэсціраваць практычна любыя аконныя праграмы, а таму падыходзіць для тэсціравання як тонкага кліента, так і вэб-кліента. Інструмент запісвае дзеянні карыстальніка, які запусціў прыкладное рашэнне "1С", у файл-сцэнар. У гэты ж час адбываецца запіс малюнкаў працоўнай вобласці экрана - эталонаў. Пры кантролі новых версій вэб-кліента сцэнары прайграюцца без карыстацкага ўдзелу. У выпадках несупадзення скрыншота з эталонным на якім-небудзь кроку тэст лічыцца праваленым, пасля чаго спецыяліст па якасці праводзіць расследаванне – памылка гэта ці запланаваная змена паводзін сістэмы. У выпадку запланаваных паводзінаў эталоны аўтаматычна падмяняюцца на новыя.
Інструмент таксама праводзіць замеры прадукцыйнасці прыкладанняў з дакладнасцю да 25 мілісекунд. У шэрагу выпадкаў мы закальцоўваем часткі сцэнара (напрыклад, некалькі разоў паўтараем увод замовы) для аналізу дэградацыі часу выканання са часам. Вынікі ўсіх замераў запісваюцца ў лог для аналізу.
Наш інструмент тэсціравання і тэстоўваны дадатак
Наш інструмент і Selenium дапаўняюць адзін аднаго; напрыклад, калі нейкая кнопка на адным з экранаў памяняла сваё месцазнаходжанне Selenium гэта можа не адсачыць, але наша прылада заўважыць, т.к. робіць папіксэльнае параўнанне скрыншота з эталонам. Таксама прылада ў стане адсачыць праблемы з апрацоўкай уводу з клавіятуры ці мышы, бо менавіта іх ён і прайгравае.
Тэсты на абодвух інструментах (нашым і Selenium) запускаюць тыпавыя сцэнары працы з нашых прыкладных рашэнняў. Тэсты аўтаматычна запускаюцца пасля штодзённай зборкі платформы "1С:Прадпрыемства". У выпадку запаволення працы сцэнараў (у параўнанні з папярэдняй зборкай) мы праводзім расследаванне і ўхіляем чыннік запаволення. Крытэрый у нас просты - новая зборка павінна працаваць не павольней папярэдняй.
Для расследавання інцыдэнтаў запаволення працы распрацоўшчыкі выкарыстоўваюць розныя інструменты; у асноўным выкарыстоўваецца вытворчасці кампаніі . Праводзіцца запіс логаў выканання праблемнай аперацыі на папярэдняй і на новай зборцы, затым логі аналізуюцца. Пры гэтым час выканання адзінкавых аперацый (у мілісекундах) можа не быць вырашальным фактарам - у браўзэры перыядычна запускаюцца службовыя працэсы тыпу ўборкі смецця, яны могуць накласці на час выканання функцый і сказіць карціну. Больш за рэлевантнымі параметрамі ў гэтым выпадку будзе колькасць выкананых інструкцый JavaScript, колькасць атамарных аперацый над DOM і да т.п. Калі колькасць інструкцый/аперацый у адным і тым жа сцэнары ў новай версіі павялічылася - гэта амаль заўсёды азначае падзенне хуткадзейнасці, якое трэба выпраўляць.
Таксама адной з прычын падзення прадукцыйнасці можа быць тое, што Google Closure Compiler па нейкай прычыне не змог зрабіць inline-падстаноўку функцыі (напрыклад, таму што функцыя рэкурсіўная ці віртуальная). У гэтым выпадку мы імкнемся выправіць сітуацыю, перапісаўшы зыходны код.
Пашырэння браўзэраў
У выпадку, калі прыкладному рашэнню патрэбна функцыянальнасць, якой няма ў JavaScript, мы выкарыстоўваем пашырэнні браўзэраў:
- для працы з файламі
- для працы з крыптаграфіяй
- праца з
Нашы пашырэнні складаюцца з дзвюх частак. Першая частка - тое, што завецца пашырэннем браўзэра (як правіла, напісаныя на JavaScript пашырэнні для Chrome і Firefox), якія ўзаемадзейнічаюць з другой часткай - бінарным пашырэннем, якія рэалізуюць патрэбную нам функцыянальнасць. Трэба згадаць, што мы пішам 3 версіі бінарных пашырэнняў - пад Windows, Linux і MacOS. Бінарнае пашырэнне пастаўляецца ў складзе платформы 1С: Прадпрыемства і знаходзіцца на серверы дадаткаў 1С. Пры першым выкліку з вэб-кліента яно загружаецца на кліенцкі кампутар і ўсталёўваецца ў браўзэры.
Пры працы ў Safari нашы пашырэнні выкарыстоўваюць NPAPI, пры працы ў Internet Explorer – тэхналогію ActiveX. пакуль не падтрымлівае пашырэнні, таму вэб-кліент у ім працуе з абмежаваннямі.
далейшае развіццё
Адна з груп задач для каманды распрацоўкі вэб-кліента - гэта далейшае развіццё функцыянальнасці. Функцыянальнасць вэб-кліента павінна быць ідэнтычная функцыянальнасці тонкага кліента, уся новая функцыянальнасць рэалізуецца адначасова і ў тонкім, і ў вэб-кліенце.
Іншыя задачы - развіццё архітэктуры, рэфактарынг, павышэнне прадукцыйнасці і надзейнасці. Напрыклад, адзін з напрамкаў - далейшы рух у бок асінхроннай мадэлі працы. Частка функцыянальнасці вэб-кліента на сапраўдны момант пабудавана на сінхроннай мадэлі ўзаемадзеяння з серверам. Асінхронная мадэль зараз становіцца ў браўзэрах (і не толькі ў браўзэрах) больш актуальнай, і гэта прымушае нас мадыфікаваць вэб-кліент шляхам замены сінхронных выклікаў на асінхронныя (і адпаведнага рэфактарынгу кода). Паступовы пераход да асінхроннай мадэлі тлумачыцца неабходнасцю падтрымкі выпушчаных рашэнняў і паступовай іх адаптацыі.
Крыніца: habr.com