1C վեբ հաճախորդի մասին

1C:Enterprise տեխնոլոգիայի հաճելի առանձնահատկություններից մեկն այն է, որ կիրառական լուծումը, որը մշակվել է կառավարվող ձևերի տեխնոլոգիայի միջոցով, կարող է գործարկվել ինչպես բարակ (գործարկվող) հաճախորդում Windows-ի, Linux-ի, MacOS X-ի համար, այնպես էլ որպես վեբ-հաճախորդ 5 բրաուզերի համար. Chrome, Internet Explorer, Firefox, Safari, Edge և այս ամենը առանց հավելվածի սկզբնական կոդը փոխելու։ Ավելին, արտաքինից հավելվածը thin client-ում և բրաուզերում գործում է և գրեթե նույնական տեսք ունի:
Գտեք 10 տարբերություն (2 նկար կտրվածքի տակ).

Բարակ հաճախորդի պատուհան Linux-ում.

Նույն պատուհանը վեբ հաճախորդում (Chrome դիտարկիչում).

Ինչու՞ մենք ստեղծել ենք վեբ հաճախորդ: Ինչ-որ չափով պաթետիկ ասած՝ ժամանակը մեզ նման խնդիր է դրել։ Ինտերնետում աշխատելը վաղուց դարձել է բիզնես հավելվածների նախապայման: Նախ, մենք ավելացրինք ինտերնետի միջոցով աշխատելու հնարավորությունը մեր նիհար հաճախորդի համար (մեր որոշ մրցակիցներ, ի դեպ, կանգ առան այնտեղ, մյուսները, ընդհակառակը, լքեցին thin հաճախորդը և սահմանափակվեցին վեբ հաճախորդի ներդրմամբ): Մենք որոշեցինք մեր օգտատերերին հնարավորություն տալ ընտրել հաճախորդի այն տարբերակը, որն իրենց լավագույնս համապատասխանում է:

Վեբ վրա հիմնված հնարավորություններ thin client-ին ավելացնելը մեծ նախագիծ էր՝ հաճախորդ-սերվեր ճարտարապետության ամբողջական փոփոխությամբ: Վեբ հաճախորդի ստեղծումը բոլորովին նոր նախագիծ է՝ սկսած զրոյից։

Խնդրի ձևակերպում

Այսպիսով, նախագծի պահանջները. վեբ հաճախորդը պետք է անի նույնը, ինչ բարակ հաճախորդը, մասնավորապես.

1. Ցուցադրել օգտվողի միջերեսը
2. Կատարեք հաճախորդի կոդը՝ գրված 1C լեզվով

1C-ում օգտագործողի միջերեսը նկարագրված է վիզուալ խմբագրիչում, բայց դեկլարատիվ, առանց տարրերի պիքսել առ պիքսել դասավորության. Օգտագործվում են ինտերֆեյսի տարրերի մոտ երեք տասնյակ տեսակներ՝ կոճակներ, մուտքագրման դաշտեր (տեքստ, թվային, ամսաթիվ/ժամ), ցուցակներ, աղյուսակներ, գրաֆիկներ և այլն։

Հաճախորդի կոդը 1C լեզվով կարող է պարունակել սերվերի զանգեր, աշխատել տեղական ռեսուրսների հետ (ֆայլեր և այլն), տպագրություն և շատ ավելին:

Թե՛ բարակ հաճախորդը (ոստայնի միջոցով աշխատելիս), և թե՛ վեբ-հաճախորդը օգտագործում են վեբ ծառայությունների նույն փաթեթը՝ 1C հավելվածի սերվերի հետ շփվելու համար: Հաճախորդների իրականացումները, իհարկե, տարբեր են՝ thin client-ը գրված է C++-ով, վեբ հաճախորդը՝ JavaScript-ով:

Մի քիչ պատմություն

Վեբ հաճախորդի նախագիծը մեկնարկել է 2006 թվականին՝ միջինում 5 հոգուց բաղկացած թիմով: Ծրագրի որոշակի փուլերում մշակողները ներգրավված էին հատուկ գործառույթներ իրականացնելու համար (աղյուսակային փաստաթուղթ, դիագրամներ և այլն); որպես կանոն, սրանք նույն մշակողներն էին, ովքեր կատարում էին այս գործառույթը thin client-ում: Նրանք. մշակողները կրկին գրել են JavaScript-ում այն ​​բաղադրիչները, որոնք նախկինում ստեղծել էին C++-ում:

Հենց սկզբից մենք մերժեցինք C++ բարակ հաճախորդի ծածկագրի ցանկացած ավտոմատ (նույնիսկ մասնակի) փոխակերպման գաղափարը JavaScript վեբ հաճախորդի՝ երկու լեզուների միջև խիստ հայեցակարգային տարբերությունների պատճառով. վեբ հաճախորդը գրվել է JavaScript-ով զրոյից:

Նախագծի առաջին կրկնություններում վեբ հաճախորդը ներկառուցված 1C լեզվով հաճախորդի կոդը փոխակերպեց անմիջապես JavaScript-ի: Նիհար հաճախորդը այլ կերպ է գործում. ներկառուցված 1C լեզվով ծածկագիրը կազմվում է բայթկոդի մեջ, այնուհետև այս բայթկոդը մեկնաբանվում է հաճախորդի վրա: Այնուհետև, վեբ հաճախորդը սկսեց անել նույնը, առաջին հերթին, այն տվեց կատարողականի առավելություն, և երկրորդը, հնարավոր եղավ միավորել բարակ և վեբ հաճախորդների ճարտարապետությունը:

Վեբ հաճախորդների աջակցությամբ 1C:Enterprise հարթակի առաջին տարբերակը թողարկվել է 2009 թվականին: Վեբ հաճախորդն այն ժամանակ աջակցում էր 2 բրաուզերի՝ Internet Explorer-ի և Firefox-ի։ Նախնական ծրագրերը ներառում էին աջակցություն Opera-ին, բայց այն ժամանակ անհաղթահարելի խնդիրների պատճառով Օպերայում հավելվածի փակման կառավարիչների հետ (100% վստահությամբ հնարավոր չէր հետևել, որ հավելվածը փակվում է, և այդ պահին իրականացնել անջատման ընթացակարգը. 1C հավելվածի սերվերը) այս պլաններից պետք է հրաժարվել:

Ծրագրի կառուցվածքը

Ընդհանուր առմամբ, 1C:Enterprise հարթակն ունի JavaScript-ով գրված 4 նախագիծ.

1. WebTools – ընդհանուր գրադարաններ, որոնք օգտագործվում են այլ նախագծերի կողմից (մենք ներառում ենք նաև Google-ի փակման գրադարան).
2. Վերահսկիչ տարր FormattedDocument (իրագործվում է JavaScript-ում և՛ thin հաճախորդում, և՛ վեբ հաճախորդում)
3. Վերահսկիչ տարր Ժամանակացույց (իրագործվում է JavaScript-ում և՛ thin հաճախորդում, և՛ վեբ հաճախորդում)
4. Վեբ հաճախորդ

Յուրաքանչյուր նախագծի կառուցվածքը հիշեցնում է Java նախագծերի կառուցվածքը (կամ .NET նախագծերը, որոնք ավելի մոտ են); Մենք ունենք անունների տարածքներ, և յուրաքանչյուր անվանատարածք առանձին թղթապանակում է: Թղթապանակի ներսում կան ֆայլեր և անվանատարածքի դասեր: Վեբ հաճախորդի նախագծում կա մոտ 1000 ֆայլ:

Կառուցվածքային առումով, վեբ հաճախորդը հիմնականում բաժանված է հետևյալ ենթահամակարգերի.

• Կառավարվող հաճախորդի հավելվածի միջերես
  • Ընդհանուր կիրառական միջերես (համակարգի ընտրացանկեր, վահանակներ)
  • Կառավարվող ձևերի միջերես, ներառյալ, ի թիվս այլ բաների, մոտ 30 հսկիչ (կոճակներ, տարբեր տեսակի մուտքագրման դաշտեր՝ տեքստ, թվեր, ամսաթիվ/ժամ և այլն, աղյուսակներ, ցուցակներ, գրաֆիկներ և այլն)

• Օբյեկտի մոդելը հասանելի է ծրագրավորողներին հաճախորդի վրա (ընդհանուր առմամբ ավելի քան 400 տեսակ՝ կառավարվող ինտերֆեյսի օբյեկտի մոդել, տվյալների դասավորության կարգավորումներ, պայմանական ոճավորում և այլն)
• Ներկառուցված 1C լեզվի թարգմանիչ
• Զննարկչի ընդլայնումներ (օգտագործվում է JavaScript-ում չաջակցվող ֆունկցիոնալության համար)
  • Աշխատեք կրիպտոգրաֆիայի հետ
  • Ֆայլերի հետ աշխատելը
  • Արտաքին բաղադրիչների տեխնոլոգիա, որը թույլ է տալիս դրանք օգտագործել ինչպես բարակ, այնպես էլ վեբ հաճախորդների համար

Զարգացման առանձնահատկությունները

JavaScript-ում վերը նշված բոլորի իրագործումը հեշտ չէ: Թերևս 1C վեբ հաճախորդը JavaScript-ով գրված ամենախոշոր հաճախորդի կողմից հավելվածներից մեկն է՝ մոտ 450.000 տող: Մենք ակտիվորեն օգտագործում ենք օբյեկտի վրա հիմնված մոտեցում վեբ հաճախորդի կոդում, ինչը հեշտացնում է նման մեծ նախագծի հետ աշխատանքը։

Հաճախորդի կոդի չափը նվազագույնի հասցնելու համար մենք նախ օգտագործեցինք մեր սեփական խճողիչը, և սկսած պլատֆորմի 8.3.6 տարբերակից (2014թ. հոկտեմբեր) մենք սկսեցինք օգտագործել: Google-ի փակման կոմպիլյատոր. Թվերի օգտագործման ազդեցությունը – վեբ հաճախորդի շրջանակի չափը մշուշումից հետո.

• Սեփական խճողիչ – 1556 կբ
• Google Closure Compiler – 1073 kb

Google Closure Compiler-ի օգտագործումն օգնեց մեզ բարելավել վեբ-հաճախորդի աշխատանքը 30%-ով` համեմատած մեր սեփական խճճող սարքի հետ: Բացի այդ, հավելվածի կողմից սպառվող հիշողության ծավալը նվազել է 15-25%-ով (կախված բրաուզերից)։

Google Closure Compiler-ը շատ լավ է աշխատում օբյեկտի վրա հիմնված կոդի հետ, ուստի դրա արդյունավետությունը վեբ հաճախորդի համար հնարավորինս բարձր է: 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 (){}

Մենք օգտագործել ենք վիրտուալ DOM-ը, նախքան այն հիմնական դառնալը)

Ինչպես բոլոր մշակողները, ովքեր գործ ունեն բարդ վեբ միջերեսների հետ, մենք արագ հասկացանք, որ DOM-ը վատ հարմարեցված է դինամիկ օգտատերերի միջերեսների հետ աշխատելու համար: Գրեթե անմիջապես գործարկվեց Virtual DOM-ի անալոգը՝ UI-ի հետ աշխատանքը օպտիմալացնելու համար: Իրադարձությունների մշակման ընթացքում DOM-ի բոլոր փոփոխությունները պահվում են հիշողության մեջ և միայն այն ժամանակ, երբ բոլոր գործողություններն ավարտված են, կուտակված փոփոխությունները կիրառվում են DOM ծառի վրա:

Վեբ հաճախորդի օպտիմիզացում

Որպեսզի մեր վեբ հաճախորդն ավելի արագ աշխատի, մենք փորձում ենք առավելագույնս օգտագործել բրաուզերի ստանդարտ հնարավորությունները (CSS և այլն): Այսպիսով, ձևի հրամանի վահանակը (գտնվում է հավելվածի գրեթե բոլոր ձևերում) ներկայացվում է բացառապես զննարկիչի գործիքների միջոցով՝ օգտագործելով դինամիկ դասավորությունը՝ հիմնված CSS-ի վրա:

Փորձարկում

Ֆունկցիոնալ և կատարողական թեստավորման համար մենք օգտագործում ենք հատուկ գործիք (գրված Java և C++), ինչպես նաև թեստերի հավաքածու՝ կառուցված վերևում։ Selenium.

Մեր գործիքը ունիվերսալ է. այն թույլ է տալիս փորձարկել գրեթե ցանկացած պատուհանավորված ծրագիր և, հետևաբար, հարմար է թե՛ բարակ հաճախորդի, և թե՛ վեբ հաճախորդի փորձարկման համար: Գործիքը գրանցում է այն օգտվողի գործողությունները, ով գործարկել է 1C հավելվածի լուծումը սցենարի ֆայլում: Միևնույն ժամանակ ձայնագրվում են էկրանի աշխատանքային տարածքի պատկերներ՝ ստանդարտներ: Վեբ հաճախորդի նոր տարբերակները վերահսկելիս սկրիպտները նվագարկվում են առանց օգտվողի մասնակցության: Այն դեպքերում, երբ սքրինշոթը որևէ քայլով չի համընկնում հղման հետ, թեստը համարվում է ձախողված, որից հետո որակի մասնագետը հետաքննություն է անցկացնում՝ պարզելու՝ սա սխալ է, թե՞ համակարգի վարքագծի պլանավորված փոփոխություն: Պլանավորված վարքագծի դեպքում ստանդարտները ավտոմատ կերպով փոխարինվում են նորերով։

Գործիքը նաև չափում է հավելվածի կատարումը մինչև 25 միլիվայրկյան ճշգրտությամբ: Որոշ դեպքերում մենք շրջում ենք սկրիպտի մասերը (օրինակ՝ մի քանի անգամ կրկնում ենք պատվերի մուտքագրումը)՝ ժամանակի ընթացքում կատարման ժամանակի դեգրադացիան վերլուծելու համար: Բոլոր չափումների արդյունքները գրանցվում են մատյանում՝ վերլուծության համար:

Մեր փորձարկման գործիքը և հավելվածը փորձարկման փուլում են

Մեր գործիքը և սելենը լրացնում են միմյանց. Օրինակ, եթե էկրաններից մեկի վրա ինչ-որ կոճակ փոխել է իր տեղը, 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 դեռևս չի աջակցում ընդարձակումներ, ուստի դրանում գտնվող վեբ հաճախորդն աշխատում է սահմանափակումներով:

Հետագա զարգացում

Վեբ հաճախորդների մշակման թիմի խնդիրներից մեկը ֆունկցիոնալության հետագա զարգացումն է: Վեբ հաճախորդի ֆունկցիոնալությունը պետք է նույնական լինի thin client-ի ֆունկցիոնալությանը, բոլոր նոր ֆունկցիոնալությունները միաժամանակ ներդրվում են ինչպես thin, այնպես էլ վեբ-հաճախորդներում:

Այլ խնդիրներ ներառում են ճարտարապետության զարգացումը, վերամշակումը, կատարողականի և հուսալիության բարելավումը: Օրինակ, ուղղություններից մեկը հետագա շարժումն է դեպի ասինխրոն աշխատանքի մոդել: Վեբ հաճախորդի որոշ գործառույթներ ներկայումս կառուցված են սերվերի հետ փոխգործակցության համաժամանակյա մոդելի վրա: Ասինխրոն մոդելն այժմ ավելի ակտուալ է դառնում բրաուզերներում (և ոչ միայն բրաուզերներում), և դա մեզ ստիպում է փոփոխել վեբ հաճախորդը՝ համաժամանակյա զանգերը փոխարինելով ասինխրոններով (և համապատասխանաբար վերամշակելով կոդը): Աստիճանական անցումը ասինխրոն մոդելի բացատրվում է թողարկված լուծումներին աջակցելու և դրանց աստիճանական հարմարեցման անհրաժեշտությամբ:

Source: www.habr.com