За уеб клиента 1С

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

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

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

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

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

Формулиране на задачата

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

1. Да показва потребителския интерфейс
2. Да изпълнява клиентския код, написан на езика 1С

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

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

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

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

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

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

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

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

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

В платформата 1С:Предприятие има общо 4 проекта, написани на JavaScript:

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

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

Структурно уеб клиентът грубо се разделя на следните подсистеми:

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

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

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

Реализацията на всичко по-горе на JavaScript е сложно дело. Може би, уеб клиентът 1С е едно от най-големите клиентски приложения, написани на JavaScript – около 450 000 реда. Активно използваме обектно-ориентиран подход в кода на уеб клиента, който улеснява работата с такъв голям проект.

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

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

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

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

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

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

За анализ на кода използваме SonarQube, където интегрираме статични анализатори на кода. С помощта на анализаторите следим деградацията на качеството на изходния код на 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 преди да стане основен)

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

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

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

Тестване

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

Нашият инструмент е универсален – той позволява тестване на почти всякакви десктоп приложения, и затова е подходящ както за тестване на тънки клиенти, така и за уеб клиенти. Инструментът записва действията на потребителя, който стартира бизнес решението „1С“, в сценарен файл. В същото време се записват изображения на работната област на екрана – еталоните. При контрола на нови версии на уеб клиента, сценарите се изпълняват без участието на потребителя. В случай на несъответствие на скрийншота с еталонния на някой етап, тестът се счита за провален, след което специалист по качеството провежда разследване – дали е грешка или планирано изменение в поведението на системата. В случай на планирано поведение, еталоните автоматично се заменят с нови.

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

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

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

Тестове и с двата инструмента (нашия и Selenium) стартират стандартни сценарии на работа от нашите бизнес решения. Тестовете автоматично се стартират след ежедневната компилация на платформата „1С:Предприятие“. В случай на забавяне в работата на сценария (в сравнение с предишната компилация), провеждаме разследване и отстраняваме причината за забавянето. Нашият критерий е прост – новата компилация трябва да работи не по-бавно от предходната.

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

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

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

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

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

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

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

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

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

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

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