За веб-клиентот 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).
2. Контролен елемент Форматиран документ (имплементирано во JavaScript и кај тенок клиент и кај веб-клиент)
3. Контролен елемент Распоредувач (имплементирано во JavaScript и кај тенок клиент и кај веб-клиент)
4. Веб клиент

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

Структурно, веб-клиентот е во голема мера поделен на следните потсистеми:

• Управуван интерфејс со клиентска апликација
  • Општ интерфејс за апликација (системски менија, панели)
  • Интерфејс на управувани форми, вклучувајќи, меѓу другото, околу 30 контроли (копчиња, различни видови полиња за внесување - текст, нумерички, датум/време, итн., табели, списоци, графикони итн.)

• Модел на објект достапен за развивачите на клиентот (вкупно над 400 типови: управуван модел на објект на интерфејс, поставки за распоред на податоци, условен стил итн.)
• Преведувач на вградениот јазик 1C
• Екстензии на прелистувачот (се користи за функционалност што не е поддржана во JavaScript)
  • Работа со криптографија
  • Работа со датотеки
  • Технологија на надворешни компоненти, овозможувајќи им да се користат и кај тенки и кај веб-клиенти

Карактеристики на развој

Спроведувањето на сето горенаведено во JavaScript не е лесно. Можеби веб-клиентот 1C е една од најголемите апликации од страна на клиентот напишани во JavaScript - околу 450.000 линии. Активно користиме објектно-ориентиран пристап во кодот на веб-клиентот, што ја поедноставува работата со толку голем проект.

За да ја минимизираме големината на кодот на клиентот, прво користевме сопствен замаглувач и почнувајќи од верзијата на платформата 8.3.6 (октомври 2014 година) почнавме да користиме Компајлер за затворање на Google. Ефектот на употреба во бројки - големината на рамката на веб-клиентот по заматување:

• Сопствен замаглувач – 1556 kb
• Компајлер за затворање на Google – 1073 kb

Користењето на Google Closure Compiler ни помогна да ги подобриме перформансите на веб-клиентот за 30% во споредба со нашиот сопствен замаглувач. Покрај тоа, количината на меморија потрошена од апликацијата е намалена за 15-25% (во зависност од прелистувачот).

Google Closure Compiler работи многу добро со објектно-ориентиран код, така што неговата ефикасност за веб-клиентот е што е можно поголема. Компајлерот за затворање прави неколку добри работи за нас:

• Проверка на статички тип во фазата на изградба на проектот (осигурува дека го покриваме кодот со прибелешки за JSDoc). Резултатот е статичко пишување, многу блиску по ниво до пишувањето во C++. Ова помага да се фатат прилично голем процент на грешки во фазата на компилација на проектот.
• Намалување на големината на кодот преку заматување
• Голем број на оптимизации на извршениот код, на пример, како што се:
  • замена на инлајн функции. Повикувањето функција во JavaScript е прилично скапа операција, а вградената замена на често користените мали методи значително го забрзува кодот.
  • Броење на константи во времето на компајлирање. Ако изразот зависи од константа, вистинската вредност на константата ќе биде заменета во неа

Ние користиме WebStorm како наша околина за развој на веб-клиент.

За анализа на кодот користиме soundQube, каде што интегрираме анализатори на статички кодови. Со помош на анализатори, го следиме деградирањето на квалитетот на изворниот код на 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 пред да стане мејнстрим)

Како и сите програмери кои се занимаваат со сложени веб-интерфејси, брзо сфативме дека DOM е слабо прилагоден за работа со динамични кориснички интерфејси. Речиси веднаш, беше имплементиран аналог на Virtual DOM за да се оптимизира работата со UI. За време на обработката на настаните, сите промени на DOM се зачувуваат во меморијата и само кога ќе се завршат сите операции, акумулираните промени се применуваат на дрвото DOM.

Оптимизирање на веб-клиентот

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

Тестирање

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

Нашата алатка е универзална - ви овозможува да тестирате речиси секоја програма со прозорци, и затоа е погодна за тестирање и на тенок клиент и на веб-клиент. Алатката ги снима дејствата на корисникот кој го лансираше апликациското решение 1C во датотека со скрипта. Во исто време, се снимаат слики од работната површина на екранот - стандарди. При следење на новите верзии на веб-клиентот, скриптите се репродуцираат без учество на корисникот. Во случаи кога скриншот не се совпаѓа со референтниот во ниту еден чекор, тестот се смета за неуспешен, по што специјалист за квалитет спроведува истрага за да утврди дали станува збор за грешка или планирана промена во однесувањето на системот. Во случај на планирано однесување, стандардите автоматски се заменуваат со нови.

Алатката исто така ги мери перформансите на апликацијата со точност до 25 милисекунди. Во некои случаи, превртуваме делови од скриптата (на пример, повторување на внесот на нарачката неколку пати) за да се анализира деградацијата на времето на извршување со текот на времето. Резултатите од сите мерења се запишуваат во дневник за анализа.

Нашата алатка за тестирање и апликација се тестираат

Нашата алатка и селенот се надополнуваат еден со друг; на пример, ако некое копче на еден од екраните ја сменило својата локација, Selenium можеби нема да го следи ова, но нашата алатка ќе забележи, бидејќи прави споредба пиксел по пиксел на скриншот со стандардот. Алатката исто така може да ги следи проблемите со обработката на влезот од тастатурата или глувчето, бидејќи тоа е токму она што го репродуцира.

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

Програмерите користат различни алатки за да ги истражат инцидентите со забавување; главно се користи Dynatrace AJAX издание производствена компанија DynaTrace. Се снимаат дневници за извршување на проблематичната операција на претходните и новите изданија, а потоа се анализираат дневниците. Во исто време, времето на извршување на поединечни операции (во милисекунди) можеби не е одлучувачки фактор - процесите на услуги, како што е собирањето ѓубре, периодично се стартуваат во прелистувачот, тие можат да се преклопуваат со времето на извршување на функциите и да ја нарушат сликата. Порелевантни параметри во овој случај би биле бројот на извршени JavaScript инструкции, бројот на атомски операции на DOM, итн. Ако бројот на инструкции/операции во истата скрипта е зголемен во нова верзија, тоа скоро секогаш значи пад на перформансите што треба да се коригира.

Исто така, една од причините за падот на перформансите може да биде тоа што Google Closure Compiler поради некоја причина не можеше да изврши внатрешна замена на функцијата (на пример, затоа што функцијата е рекурзивна или виртуелна). Во овој случај, се обидуваме да ја поправиме ситуацијата со препишување на изворниот код.

Екстензии на прелистувачот

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

• за работа со датотеки
• за работа со криптографија
• работи со надворешни компоненти

Нашите екстензии се состојат од два дела. Првиот дел е она што се нарекува екстензија на прелистувачот (обично екстензии за Chrome и Firefox напишани во JavaScript), кои комуницираат со вториот дел - бинарна екстензија што ја имплементира функционалноста што ни е потребна. Треба да се спомене дека пишуваме 3 верзии на бинарни екстензии - за Windows, Linux и MacOS. Бинарната екстензија се испорачува како дел од платформата 1C:Enterprise и се наоѓа на серверот за апликации 1C. Кога се повикува за прв пат од веб-клиент, тој се презема на клиентскиот компјутер и се инсталира во прелистувачот.

Кога работи во Safari, нашите екстензии користат NPAPI; кога работат во Internet Explorer, користат технологија ActiveX. Мајкрософт Еџ сè уште не поддржува екстензии, така што веб-клиентот во него работи со ограничувања.

Понатамошно развивање

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

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

Извор: www.habr.com