1C: Enterprise texnologiyasının gözəl xüsusiyyətlərindən biri idarə olunan formalar texnologiyasından istifadə etməklə hazırlanmış proqram həllinin həm Windows, Linux, MacOS X üçün nazik (icra edilə bilən) müştəridə, həm də 5 brauzer üçün veb müştəri kimi işə salınmasıdır - Chrome, Internet Explorer, Firefox, Safari, Edge və bütün bunlar tətbiqin mənbə kodunu dəyişmədən. Üstəlik, xaricdən nazik müştəri və brauzerdəki proqramlar işləyir və demək olar ki, eyni görünür.
10 fərqi tapın (kəsik altında 2 şəkil):
Linux-da nazik müştəri pəncərəsi:
Veb müştəridə eyni pəncərə (Chrome brauzerində):
Nə üçün veb müştəri yaratdıq? Bir qədər pafoslu desək, zaman bizim qarşımıza belə bir vəzifə qoyub. İnternet üzərindən işləmək çoxdan biznes proqramları üçün ilkin şərt olmuşdur. Birincisi, biz nazik müştərimiz üçün İnternet vasitəsilə işləmək qabiliyyətini əlavə etdik (bəzi rəqiblərimiz, yeri gəlmişkən, orada dayandılar; digərləri, əksinə, nazik müştəridən imtina etdilər və veb müştəri tətbiq etməklə məhdudlaşdılar). Biz istifadəçilərimizə onlara ən uyğun olan müştəri seçimini seçmək imkanı vermək qərarına gəldik.
İncə müştəriyə veb-əsaslı imkanların əlavə edilməsi müştəri-server arxitekturasında tam dəyişikliklə böyük bir layihə idi. Veb müştəri yaratmaq sıfırdan başlayaraq tamamilə yeni bir layihədir.
Problem problemi
Beləliklə, layihə tələbləri: veb müştəri nazik müştəri ilə eyni şeyi etməlidir, yəni:
- İstifadəçi interfeysini göstərin
- 1C dilində yazılmış müştəri kodunu icra edin
1C-də istifadəçi interfeysi vizual redaktorda təsvir edilmişdir, lakin deklarativ olaraq, elementlərin piksel-piksel təşkili olmadan; Təxminən üç tip interfeys elementlərindən istifadə olunur - düymələr, giriş sahələri (mətn, rəqəm, tarix/saat), siyahılar, cədvəllər, qrafiklər və s.
1C dilində müştəri kodu server zənglərini, yerli resurslarla işləməyi (fayllar və s.), çapı və daha çoxunu ehtiva edə bilər.
Həm nazik müştəri (veb vasitəsilə işləyərkən), həm də veb müştəri 1C proqram serveri ilə əlaqə yaratmaq üçün eyni veb xidmətlərindən istifadə edirlər. Müştəri tətbiqləri, əlbəttə ki, fərqlidir - nazik müştəri C++ dilində, veb müştəri JavaScript-də yazılmışdır.
Bir az tarixi
Veb müştəri layihəsi 2006-cı ildə (orta hesabla) 5 nəfərdən ibarət komanda ilə başlamışdır. Layihənin müəyyən mərhələlərində xüsusi funksionallığı (elektron cədvəl sənədi, diaqramlar və s.) həyata keçirmək üçün tərtibatçılar cəlb edilmişdir; bir qayda olaraq, bunlar nazik müştəridə bu funksiyanı yerinə yetirən eyni tərtibatçılar idi. Bunlar. tərtibatçılar əvvəllər C++-da yaratdıqları komponentləri JavaScript-də yenidən yazdılar.
İki dil arasındakı güclü konseptual fərqlərə görə biz əvvəldən C++ nazik müştəri kodunun JavaScript veb müştərisinə avtomatik (hətta qismən) çevrilməsi ideyasını rədd etdik; veb müştəri sıfırdan JavaScript-də yazılmışdır.
Layihənin ilk iterasiyalarında veb müştəri daxili 1C dilində müştəri kodunu birbaşa JavaScript-ə çevirdi. İncə müştəri fərqli şəkildə hərəkət edir - daxili 1C dilində kod bayt koduna yığılır və sonra bu bayt kodu müştəridə şərh olunur. Sonradan veb müştəri də eyni şeyi etməyə başladı - birincisi, performans artımı verdi, ikincisi, nazik və veb müştərilərin arxitekturasını birləşdirməyə imkan verdi.
Veb müştəri dəstəyi ilə 1C: Enterprise platformasının ilk versiyası 2009-cu ildə buraxıldı. O zaman veb müştəri 2 brauzeri - Internet Explorer və Firefox-u dəstəkləyirdi. İlkin planlara Opera dəstəyi daxil idi, lakin o zaman Opera-da proqramların bağlanması ilə bağlı həlledilməz problemlərə görə (tətbiqin bağlandığını 100% əminliklə izləmək mümkün deyildi və həmin anda əlaqəni kəsmə prosedurunu həyata keçirmək mümkün deyildi. 1C proqram serveri) bu planlardan imtina edilməli idi.
Layihə strukturu
Ümumilikdə, 1C: Enterprise platformasında JavaScript-də yazılmış 4 layihə var:
- WebTools – digər layihələr tərəfindən istifadə olunan paylaşılan kitabxanalar (biz də daxil edirik ).
- Nəzarət elementi (həm nazik müştəridə, həm də veb müştəridə JavaScript-də həyata keçirilir)
- Nəzarət elementi (həm nazik müştəridə, həm də veb müştəridə JavaScript-də həyata keçirilir)
- Veb müştəri
Hər bir layihənin strukturu Java layihələrinin strukturuna bənzəyir (və ya .NET layihələri - hansı daha yaxındırsa); Bizim ad boşluqlarımız var və hər bir ad sahəsi ayrıca qovluqdadır. Qovluğun içərisində fayllar və ad sahəsi sinifləri var. Veb müştəri layihəsində təxminən 1000 fayl var.
Struktur olaraq, veb müştəri əsasən aşağıdakı alt sistemlərə bölünür:
- İdarə olunan müştəri tətbiqi interfeysi
- Ümumi proqram interfeysi (sistem menyuları, panellər)
- İdarə olunan formaların interfeysi, o cümlədən 30-a yaxın idarəetmə (düymələr, müxtəlif növ daxiletmə sahələri - mətn, rəqəm, tarix/saat və s., cədvəllər, siyahılar, qrafiklər və s.)
- Müştəridə tərtibatçılar üçün mövcud olan obyekt modeli (ümumilikdə 400-dən çox növ: idarə olunan interfeys obyekt modeli, verilənlərin düzülüşü parametrləri, şərti üslub və s.)
- Daxili 1C dilinin tərcüməçisi
- Brauzer genişləndirmələri (JavaScript-də dəstəklənməyən funksionallıq üçün istifadə olunur)
- Kriptoqrafiya ilə işləmək
- Fayllarla işləmək
- Xarici komponentlərin texnologiyası, onları həm nazik, həm də veb müştərilərdə istifadə etməyə imkan verir
İnkişaf xüsusiyyətləri
Yuxarıda göstərilənlərin hamısını JavaScript-də həyata keçirmək asan deyil. Bəlkə də 1C veb müştərisi JavaScript-də yazılmış ən böyük müştəri proqramlarından biridir - təxminən 450.000 sətir. Biz veb müştəri kodunda obyekt yönümlü yanaşmadan fəal şəkildə istifadə edirik ki, bu da belə böyük layihə ilə işi asanlaşdırır.
Müştəri kodunun ölçüsünü minimuma endirmək üçün biz əvvəlcə öz obfuscatorumuzdan istifadə etdik və 8.3.6 platforma versiyasından (oktyabr 2014) başlayaraq istifadə etməyə başladıq. . Rəqəmlərdə istifadənin təsiri – çaşqınlıqdan sonra veb müştəri çərçivəsinin ölçüsü:
- Öz obfuscator – 1556 kb
- Google Closure Compiler – 1073 kb
Google Closure Compiler-dən istifadə bizim öz obfuscatorumuzla müqayisədə veb müştərinin performansını 30% yaxşılaşdırmağa kömək etdi. Bundan əlavə, tətbiqin istehlak etdiyi yaddaşın həcmi 15-25% azalıb (brauzerdən asılı olaraq).
Google Closure Compiler obyekt yönümlü kodla çox yaxşı işləyir, ona görə də veb müştəri üçün onun səmərəliliyi mümkün qədər yüksəkdir. Closure Compiler bizim üçün bir neçə yaxşı şey edir:
- Layihənin qurulması mərhələsində statik növün yoxlanılması (kodu JSDoc annotasiyaları ilə əhatə etməyimizi təmin edir). Nəticə C++ dilində yazmağa çox yaxın olan statik yazmadır. Bu, layihənin tərtibi mərhələsində səhvlərin kifayət qədər böyük faizini tutmağa kömək edir.
- Qarışıqlıq yolu ilə kodun ölçüsünü azaltmaq
- İcra olunan kodun bir sıra optimallaşdırılması, məsələn:
- daxili funksiya əvəzetmələri. JavaScript-də funksiyaya zəng etmək kifayət qədər bahalı əməliyyatdır və tez-tez istifadə olunan kiçik metodların daxili əvəzlənməsi kodu əhəmiyyətli dərəcədə sürətləndirir.
- Kompilyasiya zamanı sabitlərin sayılması. İfadə sabitdən asılıdırsa, sabitin faktiki dəyəri ona əvəz olunacaq
Biz veb müştəri inkişaf mühitimiz kimi WebStorm-dan istifadə edirik.
Kod təhlili üçün istifadə edirik , burada biz statik kod analizatorlarını birləşdiririk. Analizatorlardan istifadə edərək, biz JavaScript mənbə kodunun keyfiyyətinin aşağı düşməsinə nəzarət edirik və bunun qarşısını almağa çalışırıq.
Hansı problemləri həll etdik/həll edirik?
Layihənin icrası zamanı biz həll etməli olduğumuz bir sıra maraqlı problemlərlə qarşılaşdıq.
Server ilə və pəncərələr arasında məlumat mübadiləsi
Mənbə kodunun qarışmasının sistemin işinə mane ola biləcəyi vəziyyətlər var. Veb müştərinin icra oluna bilən kodundan kənar kod, çaşqınlığa görə, icra edilə bilən kodun gözlədiyindən fərqli funksiya və parametr adlarına malik ola bilər. Bizim üçün xarici kod:
- Məlumat strukturları şəklində serverdən gələn kod
- Başqa bir proqram pəncərəsi üçün kod
Server ilə əlaqə qurarkən qarışıqlığın qarşısını almaq üçün @expose etiketindən istifadə edirik:
/**
* @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;
}Digər pəncərələrlə əlaqə qurarkən qarışıqlığın qarşısını almaq üçün biz sözdə ixrac edilmiş interfeyslərdən istifadə edirik (bütün metodların ixrac edildiyi interfeyslər).
/**
* Экспортируемый интерфейс контрола 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-dan istifadə etdik ki, o, əsas cərəyana çevrilməzdən əvvəl)
Mürəkkəb Web UI ilə məşğul olan bütün tərtibatçılar kimi, biz də tez başa düşdük ki, DOM dinamik istifadəçi interfeysləri ilə işləmək üçün zəif uyğundur. Demək olar ki, dərhal UI ilə işi optimallaşdırmaq üçün Virtual DOM-un analoqu tətbiq olundu. Hadisənin işlənməsi zamanı bütün DOM dəyişiklikləri yaddaşda saxlanılır və yalnız bütün əməliyyatlar tamamlandıqdan sonra yığılmış dəyişikliklər DOM ağacına tətbiq edilir.
Veb müştərinin optimallaşdırılması
Veb müştərimizin daha sürətli işləməsi üçün standart brauzer imkanlarından (CSS və s.) maksimum istifadə etməyə çalışırıq. Beləliklə, forma əmr paneli (tətbiqin demək olar ki, hər bir formasında yerləşir) yalnız CSS-ə əsaslanan dinamik tərtibatdan istifadə edərək brauzer alətlərindən istifadə etməklə təqdim olunur.
Test
Funksional və performans testi üçün biz xüsusi alətdən (Java və C++ dillərində yazılmışdır), eləcə də onun üzərində qurulmuş testlər dəstindən istifadə edirik. .
Alətimiz universaldır - o, demək olar ki, hər hansı bir pəncərəli proqramı sınamağa imkan verir və buna görə də həm nazik müştəri, həm də veb müştərini yoxlamaq üçün uyğundur. Alət skript faylına 1C tətbiq həllini işə salmış istifadəçinin hərəkətlərini qeyd edir. Eyni zamanda, ekranın iş sahəsinin təsvirləri - standartlar - qeyd olunur. Veb müştərinin yeni versiyalarını izləyərkən skriptlər istifadəçinin iştirakı olmadan oynanılır. Ekran görüntüsü hər hansı bir addımda istinad ilə uyğun gəlmirsə, test uğursuz sayılır, bundan sonra keyfiyyət mütəxəssisi bunun səhv və ya sistemin davranışında planlaşdırılan dəyişiklik olub olmadığını müəyyən etmək üçün araşdırma aparır. Planlaşdırılmış davranış halında, standartlar avtomatik olaraq yeniləri ilə əvəz olunur.
Alət həmçinin tətbiqin performansını 25 millisaniyə qədər dəqiqliklə ölçür. Bəzi hallarda biz skriptin hissələrini dövrələyirik (məsələn, sifariş girişinin bir neçə dəfə təkrarlanması) zamanla icra müddətinin deqradasiyasını təhlil etmək üçün. Bütün ölçmələrin nəticələri təhlil üçün jurnalda qeyd olunur.
Test alətimiz və tətbiqimiz sınaqdan keçirilir
Bizim alətimiz və Selenium bir-birini tamamlayır; məsələn, ekranlardan birində hansısa düymə yerini dəyişibsə, Selenium bunu izləməyə bilər, lakin alətimiz bunu fərq edəcək, çünki ekran görüntüsünü standartla piksel-piksel müqayisə edir. Alət, həmçinin klaviatura və ya siçandan daxil olanların işlənməsi ilə bağlı problemləri izləyə bilir, çünki bu, məhz onun əks etdirdiyi şeydir.
Hər iki alət üzrə testlər (bizim və Selenium) bizim tətbiq həllərimizdən tipik iş ssenarilərini həyata keçirir. Testlər 1C: Enterprise platformasının gündəlik qurulmasından sonra avtomatik olaraq işə salınır. Skriptlər daha yavaşdırsa (əvvəlki quruluşla müqayisədə), biz yavaşlamanın səbəbini araşdırıb həll edirik. Bizim meyarımız sadədir - yeni quruluş əvvəlkindən daha yavaş işləməməlidir.
Tərtibatçılar yavaşlama hadisələrini araşdırmaq üçün müxtəlif vasitələrdən istifadə edirlər; əsasən istifadə olunur istehsal şirkəti . Əvvəlki və yeni qurulmalar üzrə problemli əməliyyatın icrası qeydləri qeyd olunur, sonra qeydlər təhlil edilir. Eyni zamanda, tək əməliyyatların icra müddəti (millisaniyələrlə) həlledici amil olmaya bilər - zibil toplama kimi xidmət prosesləri vaxtaşırı brauzerdə işə salınır, onlar funksiyaların icra müddəti ilə üst-üstə düşə və şəkli təhrif edə bilər. Bu halda daha uyğun parametrlər yerinə yetirilən JavaScript təlimatlarının sayı, DOM-da atom əməliyyatlarının sayı və s. Eyni skriptdəki təlimatların/əməliyyatların sayı yeni versiyada artıbsa, bu, demək olar ki, həmişə düzəldilməli olan performansın azalması deməkdir.
Həmçinin, performansın aşağı düşməsinin səbəblərindən biri ola bilər ki, Google Closure Compiler nədənsə funksiyanın daxili əvəzlənməsini həyata keçirə bilmədi (məsələn, funksiya rekursiv və ya virtual olduğundan). Bu halda mənbə kodunu yenidən yazaraq vəziyyəti düzəltməyə çalışırıq.
Brauzer uzantıları
Tətbiq həllinə JavaScript-də mövcud olmayan funksionallıq lazım olduqda, biz brauzer genişləndirmələrindən istifadə edirik:
- fayllarla işləmək üçün
- kriptoqrafiya ilə işləmək üçün
- ilə işləmək
Bizim uzantılarımız iki hissədən ibarətdir. Birinci hissə brauzer genişləndirilməsi adlanan şeydir (adətən JavaScript-də yazılmış Chrome və Firefox üçün genişlənmələr), ikinci hissə ilə qarşılıqlı əlaqədə olur - bizə lazım olan funksionallığı həyata keçirən ikili genişləndirmə. Qeyd etmək lazımdır ki, biz ikili genişləndirmələrin 3 versiyasını yazırıq - Windows, Linux və MacOS üçün. Binar genişləndirmə 1C: Enterprise platformasının bir hissəsi kimi təqdim olunur və 1C proqram serverində yerləşir. Veb müştəridən ilk dəfə çağırıldıqda o, müştəri kompüterinə endirilir və brauzerdə quraşdırılır.
Safari-də işləyərkən genişlənmələrimiz NPAPI-dən istifadə edir; Internet Explorer-də işləyərkən ActiveX texnologiyasından istifadə edirlər. hələ uzantıları dəstəkləmir, ona görə də içindəki veb müştəri məhdudiyyətlərlə işləyir.
Əlavə inkişaf
Veb müştəri inkişaf komandası üçün vəzifələrdən biri funksionallığın gələcək inkişafıdır. Veb müştərinin funksionallığı nazik müştərinin funksionallığı ilə eyni olmalıdır; bütün yeni funksiyalar eyni vaxtda həm nazik, həm də veb müştərilərdə həyata keçirilir.
Digər vəzifələrə arxitekturanın inkişafı, refaktorinq, performansın və etibarlılığın artırılması daxildir. Məsələn, istiqamətlərdən biri asinxron iş modelinə doğru irəliləmədir. Veb müştərinin bəzi funksionallığı hazırda serverlə qarşılıqlı əlaqənin sinxron modelində qurulub. Asinxron model indi brauzerlərdə (və təkcə brauzerlərdə deyil) daha aktuallaşır və bu, bizi sinxron zəngləri asinxronlarla əvəz etməklə (və kodu müvafiq olaraq refaktor etməklə) veb müştərini dəyişdirməyə məcbur edir. Asinxron modelə tədricən keçid buraxılmış həllərin dəstəklənməsi və onların tədricən uyğunlaşması ehtiyacı ilə izah olunur.
Mənbə: www.habr.com