Относно 1C уеб клиент

Една от хубавите характеристики на технологията 1C:Enterprise е, че приложното решение, разработено с помощта на технологията за управлявани формуляри, може да бъде стартирано както в тънък (изпълним) клиент за Windows, Linux, MacOS X, така и като уеб клиент за 5 браузъра - Chrome, Internet Explorer, Firefox, Safari, Edge и всичко това без промяна на изходния код на приложението. Освен това външно приложението в тънкия клиент и в браузъра функционира и изглежда почти идентично.
Намерете 10 разлики (2 картинки под разреза):

Прозорец на тънък клиент на Linux:

Същият прозорец в уеб клиента (в браузъра Chrome):

Защо направихме уеб клиент? Малко патетично казано, времето ни постави такава задача. Работата през интернет отдавна е предпоставка за бизнес приложения. Първо, добавихме възможност за работа през интернет за нашия тънък клиент (някои от нашите конкуренти, между другото, спряха дотук; други, напротив, изоставиха тънкия клиент и се ограничиха до внедряване на уеб клиент). Решихме да дадем възможност на нашите потребители да изберат клиентската опция, която им подхожда най-добре.

Добавянето на уеб базирани възможности към тънкия клиент беше голям проект с пълна промяна в архитектурата клиент-сървър. Създаването на уеб клиент е изцяло нов проект, който започва от нулата.

Проблем изявление

И така, изискванията на проекта: уеб клиентът трябва да прави същото като тънкия клиент, а именно:

1. Показване на потребителски интерфейс
2. Изпълнете клиентски код, написан на езика 1C

Потребителският интерфейс в 1C е описан във визуален редактор, но декларативно, без подреждане на елементите пиксел по пиксел; Използват се около три дузини вида интерфейсни елементи - бутони, полета за въвеждане (текст, число, дата/час), списъци, таблици, графики и др.

Клиентският код на езика 1C може да съдържа извиквания на сървъра, работа с локални ресурси (файлове и т.н.), печат и много други.

Както тънкият клиент (когато работи чрез уеб), така и уеб клиентът използват един и същ набор от уеб услуги за комуникация със сървъра на приложения 1C. Клиентските имплементации, разбира се, са различни - тънкият клиент е написан на C++, уеб клиентът е написан на JavaScript.

Малко история

Проектът за уеб клиент стартира през 2006 г. с екип от (средно) 5 души. На определени етапи от проекта бяха включени разработчици за внедряване на специфична функционалност (документ с електронна таблица, диаграми и др.); като правило това бяха същите разработчици, които направиха тази функционалност в тънкия клиент. Тези. разработчиците пренаписаха компоненти в JavaScript, които преди това бяха създали в C++.

От самото начало отхвърлихме идеята за автоматично (дори частично) преобразуване на C++ тънък клиентски код в JavaScript уеб клиент поради силните концептуални разлики между двата езика; уеб клиентът е написан на JavaScript от нулата.

В първите итерации на проекта уеб клиентът конвертира клиентския код на вградения 1C език директно в JavaScript. Тънкият клиент действа по различен начин - кодът на вградения 1C език се компилира в байткод и след това този байткод се интерпретира на клиента. Впоследствие уеб клиентът започна да прави същото - първо, даде увеличение на производителността, и второ, направи възможно унифицирането на архитектурата на тънкия и уеб клиента.

Първата версия на платформата 1C:Enterprise с поддръжка на уеб клиент беше пусната през 2009 г. Уеб клиентът по това време поддържаше 2 браузъра - Internet Explorer и Firefox. Първоначалните планове включваха поддръжка за Opera, но поради непреодолими проблеми по това време с манипулаторите за затваряне на приложения в Opera (не беше възможно да се проследи със 100% сигурност, че приложението се затваря, и в този момент да се извърши процедурата за прекъсване на връзката от сървърът на приложения 1C) от тези планове трябваше да бъде изоставен.

Структура на проекта

Общо платформата 1C:Enterprise има 4 проекта, написани на JavaScript:

1. WebTools – споделени библиотеки, използвани от други проекти (ние също включваме Google Closure Library).
2. Контролен елемент FormattedDocument (имплементиран в JavaScript както в тънкия клиент, така и в уеб клиента)
3. Контролен елемент Планировчик (имплементиран в JavaScript както в тънкия клиент, така и в уеб клиента)
4. Уеб клиент

Структурата на всеки проект наподобява структурата на Java проекти (или .NET проекти - което е по-близо); Имаме пространства от имена и всяко пространство от имена е в отделна папка. Вътре в папката има файлове и класове за пространство от имена. В проекта на уеб клиента има около 1000 файла.

В структурно отношение уеб клиентът се разделя основно на следните подсистеми:

• Интерфейс на управлявано клиентско приложение
  • Общ интерфейс на приложението (системни менюта, панели)
  • Интерфейс на управлявани форми, включващ, между другото, около 30 контроли (бутони, различни видове полета за въвеждане - текстови, цифрови, дата/час и др., таблици, списъци, графики и др.)

• Обектен модел, достъпен за разработчиците на клиента (общо над 400 типа: обектен модел на управляван интерфейс, настройки за оформление на данни, условен стил и др.)
• Интерпретатор на вградения език 1C
• Разширения на браузъра (използвани за функционалност, която не се поддържа в JavaScript)
  • Работа с криптография
  • Работете с файлове
  • Технология на външни компоненти, позволяваща използването им както в тънки, така и в уеб клиенти

Характеристики на разработката

Имплементирането на всичко по-горе в JavaScript не е лесно. Може би уеб клиентът 1C е едно от най-големите клиентски приложения, написани на JavaScript - около 450.000 XNUMX реда. Ние активно използваме обектно-ориентиран подход в кода на уеб клиента, което улеснява работата с такъв голям проект.

За да минимизираме размера на клиентския код, първо използвахме нашия собствен обфускатор и започвайки с платформа версия 8.3.6 (октомври 2014 г.) започнахме да използваме Google Closure Compiler. Ефектът от използването в числа – размерът на рамката на уеб клиента след обфускация:

• Собствен обфускатор – 1556 kb
• Google Closure Compiler – 1073 kb

Използването на Google Closure Compiler ни помогна да подобрим производителността на уеб клиента с 30% в сравнение с нашия собствен обфускатор. Освен това количеството памет, консумирано от приложението, е намаляло с 15-25% (в зависимост от браузъра).

Google Closure Compiler работи много добре с обектно-ориентиран код, така че неговата ефективност за уеб клиента е възможно най-висока. Closure Compiler прави няколко добри неща за нас:

• Статична проверка на типа на етапа на изграждане на проекта (гарантира, че покриваме кода с JSDoc анотации). Резултатът е статично писане, много близко по ниво до писането на C++. Това помага да се уловят доста голям процент грешки на етапа на компилация на проекта.
• Намаляване на размера на кода чрез обфускация
• Редица оптимизации на изпълнения код, например, като:
  • замествания на вградени функции. Извикването на функция в JavaScript е доста скъпа операция и вградените замествания на често използвани малки методи значително ускоряват кода.
  • Преброяване на константи по време на компилиране. Ако даден израз зависи от константа, действителната стойност на константата ще бъде заменена в него

Ние използваме WebStorm като наша среда за разработка на уеб клиенти.

За анализ на кода използваме soundQube, където интегрираме статични кодови анализатори. Използвайки анализатори, ние наблюдаваме влошаването на качеството на изходния код на JavaScript и се опитваме да го предотвратим.

Какви проблеми решихме/решаваме?

По време на изпълнението на проекта се натъкнахме на редица интересни проблеми, които трябваше да решим.

Обмен на данни със сървъра и между windows

Има ситуации, при които обфускацията на изходния код може да попречи на работата на системата. Кодът, външен за изпълнимия код на уеб клиента, поради обфускация, може да има имена на функции и параметри, които се различават от тези, които нашият изпълним код очаква. Външният код за нас е:

• Код, идващ от сървъра под формата на структури от данни
• Код за прозорец на друго приложение

За да избегнем объркване при взаимодействие със сървъра, използваме етикета @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, преди да стане масов)

Като всички разработчици, работещи със сложни уеб интерфейси, ние бързо осъзнахме, че DOM не е подходящ за работа с динамични потребителски интерфейси. Почти веднага беше внедрен аналог на Virtual DOM за оптимизиране на работата с потребителския интерфейс. По време на обработката на събитието всички DOM промени се съхраняват в паметта и само когато всички операции са завършени, натрупаните промени се прилагат към DOM дървото.

Оптимизиране на уеб клиента

За да направим нашия уеб клиент да работи по-бързо, ние се опитваме да използваме максимално стандартните възможности на браузъра (CSS и др.). По този начин командният панел на формуляра (разположен в почти всяка форма на приложението) се изобразява изключително с помощта на инструменти на браузъра, използвайки динамично оформление, базирано на CSS.

Тестване

За функционално тестване и тестване на производителността ние използваме патентован инструмент (написан на Java и C++), както и набор от тестове, изграден върху Селен.

Нашият инструмент е универсален - позволява ви да тествате почти всяка прозоречна програма и следователно е подходящ за тестване както на тънък клиент, така и на уеб клиент. Инструментът записва действията на потребителя, стартирал приложното решение 1C, в скриптов файл. В същото време се записват изображения на работната зона на екрана - стандарти. Когато наблюдавате нови версии на уеб клиента, скриптовете се възпроизвеждат без участие на потребителя. В случаите, когато екранната снимка не съвпада с референтната на нито една стъпка, тестът се счита за неуспешен, след което специалист по качеството извършва проверка, за да установи дали това е грешка или планирана промяна в поведението на системата. В случай на планирано поведение, стандартите автоматично се заменят с нови.

Инструментът също измерва производителността на приложението с точност до 25 милисекунди. В някои случаи зацикляме на части от скрипта (например, повтаряме въвеждането на поръчката няколко пъти), за да анализираме влошаването на времето за изпълнение с течение на времето. Резултатите от всички измервания се записват в дневник за анализ.

Нашият инструмент за тестване и приложение се тестват

Нашият инструмент и Selenium се допълват взаимно; например, ако някой бутон на един от екраните е променил местоположението си, Selenium може да не проследи това, но нашият инструмент ще забележи, защото прави сравнение пиксел по пиксел на екранната снимка със стандарта. Инструментът също така може да проследява проблеми с обработката на въвеждане от клавиатурата или мишката, тъй като възпроизвежда точно това.

Тестовете на двата инструмента (нашия и Selenium) изпълняват типични работни сценарии от нашите приложни решения. Тестовете се стартират автоматично след ежедневното изграждане на платформата 1C:Enterprise. Ако скриптовете са по-бавни (в сравнение с предишната компилация), ние проучваме и отстраняваме причината за забавянето. Нашият критерий е прост - новата версия трябва да работи не по-бавно от предишната.

Разработчиците използват различни инструменти за разследване на инциденти със забавяне; основно използвани Dynatrace AJAX Edition продуцентска компания DynaTrace. Записват се регистрационни файлове за изпълнението на проблемната операция на предишните и новите компилации, след което регистрационните файлове се анализират. В същото време времето за изпълнение на отделни операции (в милисекунди) може да не е решаващ фактор - сервизни процеси като събиране на боклук периодично се стартират в браузъра, те могат да се припокриват с времето за изпълнение на функциите и да изкривят картината. По-подходящи параметри в този случай биха били броят на изпълнените JavaScript инструкции, броят на атомарните операции върху DOM и т.н. Ако броят на инструкциите/операциите в един и същи скрипт се е увеличил в нова версия, това почти винаги означава спад в производителността, който трябва да бъде коригиран.

Освен това една от причините за спада в производителността може да е, че Google Closure Compiler по някаква причина не е успял да извърши вградено заместване на функцията (например защото функцията е рекурсивна или виртуална). В този случай се опитваме да коригираме ситуацията, като пренаписваме изходния код.

Разширения на браузъра

Когато решение за приложение се нуждае от функционалност, която не е налична в JavaScript, ние използваме разширения на браузъра:

• за работа с файлове
• за работа с криптография
• работи с външни компоненти

Нашите разширения се състоят от две части. Първата част е това, което се нарича разширение на браузъра (обикновено разширения за Chrome и Firefox, написани на JavaScript), които взаимодействат с втората част – двоично разширение, което реализира функционалността, от която се нуждаем. Трябва да споменем, че пишем 3 версии на бинарни разширения - за Windows, Linux и MacOS. Двоичното разширение се доставя като част от платформата 1C:Enterprise и се намира на сървъра на приложения 1C. При първото извикване от уеб клиент се изтегля на клиентския компютър и се инсталира в браузъра.

Когато работят в Safari, нашите разширения използват NPAPI; когато работят в Internet Explorer, те използват технологията ActiveX. Microsoft Edge все още не поддържа разширения, така че уеб клиентът в него работи с ограничения.

По-нататъшно развитие

Една от задачите на екипа за разработка на уеб клиенти е по-нататъшното развитие на функционалността. Функционалността на уеб клиента трябва да бъде идентична с функционалността на тънкия клиент; цялата нова функционалност се внедрява едновременно и в тънкия, и в уеб клиента.

Други задачи включват разработване на архитектурата, рефакторинг, подобряване на производителността и надеждността. Например, една от посоките е по-нататъшно движение към асинхронен модел на работа. Част от функционалността на уеб клиента в момента е изградена върху синхронен модел на взаимодействие със сървъра. Асинхронният модел вече става все по-уместен в браузърите (и не само в браузърите) и това ни принуждава да модифицираме уеб клиента, като заменим синхронните извиквания с асинхронни (и съответно рефакторираме кода). Постепенният преход към асинхронен модел се обяснява с необходимостта от поддръжка на пуснати решения и тяхното постепенно адаптиране.

Източник: www.habr.com