A feladat a windowsba épített IIS webszerver felemelése és az 1c alap 8.3-as platformon való közzététele. Ebben nincs semmi nehéz.

Virtuáliska 2008 r2 vállalati szerveren forogva elérhető. Helyi rendszergazdai jogok hozzá. 1C platform, 2041.6.8.3. Hozzunk létre egy üres információs bázist. És hát kezdjük is. Csatlakozz VK csoportunkhoz! Javítás alatt! Okos műhely!

A webkiszolgálói szerepkör (IIS) telepítése

Először telepítenie kell a webszerver szerepkört. Nyitunk Szerverkezelő, válassza ki a bal oldali ágat Szerepek, Jobb klikk Szerep hozzáadása.

Elérkezünk a kiszolgálói szerepkör kiválasztásához, és bejelöljük a Web Server (IIS) melletti négyzetet. Kattintson a tovább gombra. Most helyesen kell kiválasztania a telepíteni kívánt szerepkör szolgáltatásait. Helyezze be a jelölőnégyzeteket pontosan az alábbi képernyőképen látható módon.

Befejezzük a telepítést. A Szerepkörök hozzáadása varázslónak bizonyos idő elteltével közölnie kell velünk, hogy a szerepkör és az összes szerepkör-szolgáltatás sikeresen telepítésre került:

Most meg kell vizsgálnunk, hogy minden jól sikerült-e nekünk. Nyissa meg bármelyik böngészőt, és lépjen a címre http://localhost. Ilyen örömteli képet kellene látnunk:

a platform és az alkatrészek felszerelése 1s

Ez azt jelenti, hogy a webszerver megfelelően emelkedett, és minden jól működik. Tehát menjünk tovább az 1-ekre. Be kell állítani egy platformot. Az egyetlen figyelmeztetés a platform telepítésekor a következő választás:

• 1C: Vállalati

• Webszerver-bővítmények

hozzáférési jogok beállítása

Első lépésként beállítjuk annak a mappának a jogait, ahol a webszerver gyökérkönyvtárát találjuk. Ha semmi nem változott, akkor alapértelmezés szerint igen C:\inetpub\wwwroot. Menjen a mappába C:\inetpub\ válasszon mappát wwwroot, kattintson rá jobb gombbal, és lépjen a tulajdonságokhoz. Ugrás a lapra Biztonság. A módosítás gombra kattintva közvetlenül az engedélyek beállításához lépünk. Keresse meg a listában Csoportok és felhasználók, csoport Felhasználók, és rákattintva az alábbi oszlopba helyezzük Csoportengedélyek, hiányzó pipák az oszlopban Lehetővé teszi.

Most engedélyeket kell adnia azoknak a mappáknak, amelyeken az 1s telepítve van. Térjünk rájuk, alapértelmezés szerint a 32 bites verziónál az 1c van a mappában C:\Program Files (x86)\1cv8 64 biteshez egy mappában C:\Program Files\1cv8. Válasszon mappát is 1cv8 lépjen a tulajdonságaira, lépjen a lapra Biztonság -> Szerkesztés. De ahelyett, hogy kiválasztunk egy csoportot a listából, először hozzá kell adnunk. Ehhez kattintson a gombra Hozzáadás, a megjelenő ablakban nyomja meg a gombot Továbbá.

Ezután kattintson a gombra Keresésés a keresett találati listában IIS_IUSRS, dupla kattintással hozzáadva visszatérünk az ablakhoz Válassza a "Felhasználók" vagy a "Csoportok" lehetőséget de a listában már megjelölt csoporttal. Kattintson az OK gombra, és térjen vissza az ablakhoz Csoportengedélyek jelölje be az összes pipát az újonnan hozzáadott csoport engedélyezési mezőjébe.

Miután beállítottuk az engedélyeket az 1c fájlokat tartalmazó mappákhoz, az utolsó marad. Adjon jogokat egy csoportnak IIS_IUSRS azon a mappán, ahol maga az alap 1c van.

A szükséges előkészületek megtörténtek. Most pedig térjünk át a publikálásra.

1. publikáció webszerveren

Konfigurátor módban kell elindítani az 1-eket a közzétenni kívánt adatbázis kiválasztásával. Az én esetemben ez egy üres alap, és csak egy van.

Az 1s konfigurátor módban lépjen a menübe Adminisztráció -> Közzététel webszerveren.

Miután megnéztük a paramétereket és meggyőződtünk arról, hogy lényegében minden megfelel nekünk, nyomunk Közzététel. Ha a kiadvány hibátlanul sikerült, folytassa az utolsó lépéssel.

az IIS konfigurálása 32 bites 1C webszerver-bővítmény modullal való együttműködésre

Hadd emlékeztessem önöket, hogy 32 bites platformot és webszerver-bővítő modult használtunk az 1c-ből. Ezért ebben az esetben továbbra is engedélyeznünk kell az alapértelmezett alkalmazáskészlet végrehajtását - DefaultAppPool futtasson 32 bites alkalmazásokat. Ezt nem nehéz megtenni. Gyerünk Szerverkezelő -> Szerepek -> Webszerver (IIS) -> Szolgáltatásmenedzser (IIS) -> Alkalmazási készletek -> DefaultAppPool. Jobb egérgomb bekapcsolva DefaultAppPool hívás helyi menüés válassz benne Extra lehetőségek.

vonalat keresünk 32 bites alkalmazások engedélyezettekés tedd szemben IGAZ

AZ IIS KONFIGURÁLÁSA 64 BITES 1C WEBSZERVER BŐVÍTÉSI MODULHOZ

Ha 64 bites platformot és webbővítő modult használtunk, akkor a következő manipulációkat kell végrehajtanunk:

Gyerünk Szerverkezelő -> Szerepek -> Webszerver (IIS) -> Szolgáltatásmenedzser (IIS)-> És válassza ki a virtuális könyvtárból konvertált alkalmazást azzal a névvel, amelyet az adatbázis közzétételekor beállítottunk. A jobb oldali mezőben lépjen a szakaszra Handler Mappings. 1s 8.3 közzététele az iis webszerveren 1s 8.3 közzététele az iis webszerveren

Csatlakozz VK csoportunkhoz!

06.04.2014

Elérhető:

Windows 8.1 Professional.

1C vállalat, 8.3.4.465 verzió.

Adatbázis ZUP 3.0.

A megadott RAM-adatbázishoz való hozzáférést internetböngészőn vagy vékony kliensen keresztül kell létrehozni.

A könnyebb érthetőség érdekében az összes műveletet a vezérlőpulton ismertetjük.

2. Adatbázis közzététele az 1C vállalattól.

Az IIS telepítése után helyi rendszergazdaként kell futtatnia a konfigurátort, és közzé kell tennie az adatbázist.

1. A konfigurátor maga konfigurálja az IIS-t.

Hozzájárulunk az IIS-kiszolgáló újraindításához egy új adatbázis közzététele után.

7. Nyissa meg a portot a tűzfalban.

Kezelőpanel - Windows tűzfal- Extra lehetőségek.

Hozzon létre egy szabályt a bejövő kapcsolatokhoz a kiválasztott porthoz.

8. Munkaszervezés az interneten keresztül.

Ahhoz, hogy a „nyílt internetről” bejusson az adatbázisba, meg kell vásárolnia egy „fehér IP-címet” a szolgáltatótól. Képletesen szólva, ez lesz az Ön digitális azonosítója, amely alapján minden internetes számítógép felismeri Önt. Ha a webszerver ezzel a címmel fog működni, akkor semmi mást nem kell tenni. Ha az Internet terjeszt egy útválasztót vagy egy másik számítógépet proxyszerverrel (azaz átjáróval), akkor ezen az átjárón meg kell nyitnia az egyik portot, és át kell irányítania a webszerver IIS működő portjára. Az átjáró beállításainál meg kell adni a bejövő portot, és a forgalom átirányítási helyét - a webszerver IP-címét és portját.

2. 9. Indítsa el a böngészőt.

   Az én esetemben a böngésző indítósora így fog kinézni:

http - protokoll jelzés.

i7 - a webszerver DNS-számítógépének neve vagy IP-címe.

180 - IIS port (kihagyható, ha a port az alapértelmezett)

hrm30 - könyvtár közzététele (c:\inetpub\wwwroot\HRM30)

Mert vékony kliens a karakterlánc a kapcsolat beállításaiban van megadva.

Mindenki tud dolgozni!

A jövőben ne felejtse el frissíteni a kiadványt az 1C vállalati platform frissítése után.

2016. január 9. 13:08

1C adatbázis közzététele harmadik fél webszerverén

• Linux beállítás

Van egy Windows szerver 1C 8.3-mal (DB - MSSQL).
A feladat az adatbázis közzétételének beállítása Linux webszerveren.
Finomságok - az Apache 1C modulja csak 2.0 és 2.2 verziókkal működik, és Jelenlegi verzió a legtöbb disztribúcióban - 2,4+
Inkább magamnak írok, nehogy elfelejtsem. Nos, soha nem tudhatod, hirtelen valaki más jól jön – nem kell a fórumokon rohangálni a megfelelő parancsok után.

Vas - egy gigabájt RAM-ot, egy magot és 20 gigabájt lemezt adott. Soha nem késő terjeszkedni.
OS: Debian Stable, megszoktam.

Beállítottam a minimumot, beleértve az ssh szervert is, de a webet nem. Térjünk vissza erre.

Telepítés után alapbeállításízlés szerint általában utf8-ra állítom a locale-t, rakok sudo-t, mc-t és vim-et, a többit szükség szerint.
Ezután telepítenie kell az apache 2.2-t. És csináld a helyes út ahelyett, hogy egyszerűen letöltené a deb csomagot. :)

Először adjon hozzá sorokat az /etc/apt/sources.list fájlhoz egy hivatkozással előző verzió terjesztés.
deb http://mirror.yandex.ru/debian/ wheezy main deb-src http://mirror.yandex.ru/debian/ wheezy main
Természetesen lehet írni régi istálló- jelen pillanatban is helyes lesz. De csak az igaziban, mert előbb-utóbb megjelenik egy új stabil verzió és be is régi istállóés akkor az apache 2.2 helyett 2.4 lesz. Bár remélem, addigra az 1C frissül, és az Apache újabb verzióival fog működni. De ki tudja? :)
Ahol mirror.yandex.ru- oda van írva a kedvenc szervered neve a tárolóval.

Ezután frissítjük az indexeket - apt-get frissítés- és nézd meg, mi van itt az apache-nak a paranccsal apt-cache showpkg apache2
Sok a kimenet, de minket csak a kimenet eleje érdekel:
Csomag: apache2 Verziók: 2.4.10-10+deb8u3 (/var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_binary-i386_Packages) i386_Packages MD5: Leírás Nyelv///en Fájl: /tor/lists yandex.ru_debian_dists_stable_main_i18n_transzlation-en md5: Leírás Nyelv: en fájl: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_transzlation-en md5: 2.4.10-10+deb8u1 (/var/lib/ly. debian.org_dists_stable_updates_main_binary-i386_Packages) Nyelv: hu Fájl: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_stable_main_i18n_Translation-en MD5: Leírás Nyelv: hu Fájl: /var/libany/smirrrutor_ _i18n_Translation- hu MD5: 2.2.22 -13+deb7u6 (/var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_binary-i386_Packages) : /var/lib/apt/lists/mirror.yandex.ru_debianl_dismains1 Language : ru Fájl: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n_Translation-en MD5:

Látjuk, hogy a 2.4.10 mellett van a 2.2.22-13+deb7u6 verzió is – amire szüksége van.
Rakjuk: apt-get install apache2=2.2.22-13+deb7u6
Vagy pontosabban: apt-get install apache2=2.2.22-13+deb7u6 apache2-mpm-worker=2.2.22-13+deb7u6 apache2.2-common=2.2.22-13+deb7u6 apache2.2-bin=2.2.22-13 +deb7u6, és a többi függőséget a rendszer automatikusan felhúzza.

Ezek után az Apache-t tartásba helyeztük, hogy véletlenül se frissítsük.

Apt-mark hold apache2 apache2-mpm-worker apache2.2-common apache2.2-bin Az apache2 elkötelezettként van megjelölve. Az apache2-mpm-worker elkötelezettként van megjelölve. Az apache2.2-common elkötelezettként van megjelölve. Az apache2.2-bin elkötelezettként van megjelölve.
Futtathatja az apache2 start szolgáltatást és a telnetet a 80-as portra, hogy ellenőrizze, nem lusta-e a böngésző elindításához.

telnet localhost 80
Próbálkozás::1... Csatlakozva a localhosthoz. Az Escape karakter "^]". 1

A módszer nincs végrehajtva

1 - /index.html nem támogatott.

---

Apache/2.2.22 (Debian) kiszolgáló 1cweb 80-as porton

A kapcsolatot külföldi gazdagép zárta le.

Esküszik – ez azt jelenti, hogy működik.

Most teszünk 1C-t.
Csak 1C webszolgáltatások szükségesek (csomag 1c-enterprise83-ws). ÉS 1c-enterprise83-common, amely a függőségekben van regisztrálva. ÉS 1c-enterprise83-szerver, ami a függőségekben nincs megadva, de enélkül a kiadó segédprogram "Segmentation error"-t ír ki.
Elvileg csak az Apache modulra van szükség wsap22.so a csomagból 1c-enterprise83-ws, és minden mást megtehetsz egy szövegszerkesztőn keresztül. De lusta ember vagyok, és szívesebben költök pár megabájtot 1C-re, mintsem kézzel behajtani a vonalakat a konfigurációkba. :)

Ezután létre kell hoznia egy mappát a közzétett 1C adatbázis beállításainak tárolására. A webszerver fában lehetséges, de jobb, ha külön teszem, közvetlenül a gyökérnél, / 1s.
Ezt követően a telepített 1C fájlokat tartalmazó mappából ( /opt/1C/v8.3/i386) futtassa a közzétételi segédprogramot webinst a következő paraméterekkel (tesztadatbázisunkat közzéteszem):
./webinst -apache22 -wsdir testlitupp -dir /1c/testlitupp -connstr "Srvr=10.0.0.4;Ref=testlitupp;" -confPath /etc/apache2/apache2.conf Megjelent

Apache22 – a webszerver mi verziója
-wsdir testlitupp - mappa a webszerveren, ahol a közzétett adatbázis elérhető lesz (http://yourserver/testlitupp)
-dir /1c/testlitupp - mappa, ahol a default.vrd fájl a közzétételi beállításokkal kerül tárolásra
-connstr "Srvr=10.0.0.4;Ref=testlitupp;" - 1C szerver ip és közzétett adatbázis neve
-confPath /etc/apache2/apache2.conf - az apache konfiguráció elérési útja

Ha azt írja, hogy „Közzétéve”, akkor minden rendben ment. Ha azt írja ki, hogy "Szegmentációs hiba", akkor valószínűleg elfelejtette beírni 1c-enterprise83-szerver.
Az eredmények alapján megvan a default.vrd fájl

És néhány új sor a webszerver konfigurációs fájljában:

LoadModule _1cws_module "/opt/1C/v8.3/i386/wsap22.so" # 1c kiadvány Alias ​​"/testlitupp" "/1c/testlitupp/" AllowOverride All Options Nincs Rendelés engedélyezése, megtagadása Engedélyezés az összes SetHandler 1c-alkalmazásból ManagedApplicationDescriptor "/1c/testlitupp/default.vrd"
Újraindítjuk az Apache-t (szolgáltatás apache2 újraindítása), és megnézzük, mi jelent meg ott.
Megjelent, jelszót kér.

És engedje be a bázisra.

Művek. További közzétételi beállításokat a vrd-fájlok szerkesztésével lehet megadni (például a hibakeresés engedélyezése), és az 1C programozóit be kell vonni a webes kliens felületének befejezésébe.
Ha opciókat ad hozzá, például a szolgáltatások manuális csatlakoztatásakor, akkor ne felejtse el eltávolítani az utolsó perjelet a „base="/testlitupp" ib="Srvr=10.0.0.4;Ref=testlitupp;" sorból alapértelmezésben. vrd fájl / >", sokáig babráltam ezzel. Ha nem törli és nem ad hozzá valamit utána, akkor az „500-as hiba” további információ nélkül kirepül.
Mekkora lesz a webszerver terhelése - még nem tudom, még mindig teszt módban működik számunkra, és van elegendő erőforrás. De memória vagy magok hozzáadása a szükségletek növekedésével nem probléma.

Általánosságban elmondható, hogy a Linux többi disztribúciójában minden hasonló módon történik, a különbségek csak az apache régi verziójának telepítési módjaiban vannak.

Ma hagyok egy kis bejegyzést az 1C 8.3 beállításáról az 1C WEB szerveren és az IIS 8 szolgáltatásokon keresztüli hozzáférés megszervezése szempontjából.

Korábban a régi módon hozzáférést adtam a felhasználóknak az 1C-hez a terminálkiszolgáló segítségével. Aztán volt egy Windows 2003-as szerverem 1C 7-es verzióval a munkahelyemen, volt egy terminálszerver licencem, ahol a terminálszerver volt telepítve. Egyszer írtam is egy cikket ennek a jónak a felállításáról,. Minden rendben volt, de most új hardverünk van (Intel Xeon CPU E3-1220 v3 alapú, 8 GB RAM), új 1C (v 8.3), új operációs rendszerünk (WIndows Server 2012 r2).

A könyvelési részlegünk (8 PC) kezdettől fogva hálózati meghajtón dolgozott, de ebben az esetben a program a hálózaton keresztüli fájlletöltés elvén működik, és ez nagyon lassú. Úgy döntöttek, hogy módot találnak a munka felgyorsítására.

Terminálszerverre gondoltam, de nincs terminálszerverre licencem (nem találtam a neten, de azt mondták, hogy drága megvenni). A kimenet véletlenül szólt, kiderült, hogy az 1C-ben van támogatás a WEB-kiszolgálóhoz. Mivel van tapasztalatom ugyanazzal az Apache-val, és ismerem a működési elvet, úgy döntöttem, hogy elsajátítom az 1C WEB szervert.

Minden alkatrész beszerelése és ellenőrzése

Kezdjük a beállítást az 1C webszerver összetevőinek telepítésével. Ellenőrizzük, hogy telepítve van-e az 1C webszerver-bővítő modul. Ha nincs telepítve, telepítse.

Az adatbázis közzététele a webszerveren

Konfigurátor módban megyünk az 1C adatbázisba. Ezután megyünk a menühöz. "Adminisztráció" - "Közzététel webszerveren"

közzétesszük!

Beállítjuk az 1C mappák jogait

A következő lépés az engedélyek beállítása a következő mappákhoz:

A szemetes mappa 1C-ben.

A jogokat az alábbi képernyőképen látható módon állítjuk be a biztonsági menüben.

Csatlakozás a webszerverhez ügyfélszámítógépekről

Ehhez hozzon létre egy kapcsolatot a DB 1C-vel - Írja be a kapcsolat nevét -> válassza a Webszerveren -> lehetőséget, majd az alábbi képen látható módon:

Ezt követően egy webszerveren keresztül csatlakozhat az 1C-hez.

Hibák:

1C8.3 IIS „Potenciálisan káros kérelem.útvonal-érték észlelve” érkezett az ügyféltől

Az 1C webszerver beállítása után egy problémába ütköztem: IP-n be tudok lépni az 1C-be, bejelentkezek, de nem működött minden menü, egyetlen ablakot sem tudtam megnyitni az 1C asztalon kívül. Sokáig kínlódtam, míg rátaláltam a megoldásra az interneten.

Mit kell tenni:
1. Nyissa meg az IIS-t. Start - Futtatás - keresse meg az "IIS-kezelőt"
2. Nyissa meg "webhelyünket"
3. Lépjen a menübe "Kezelői leképezések"
4. Keresi ISAPI-dll, és válassza a Szerkesztés lehetőséget.
5. Módosítsa a kérés elérési útját "*.dll"-ről "*"-ra, végrehajtható fájl (lehet, hogy az 1C másik verziója van, legyen óvatos) - "C:\Program Files (x86)\1cv8\ 8.3.6.2390 \bin\wsisapi.dll".
6. Mentés.

7. Ellenőrizzük.

Ez minden most. Ha kérdésed van, megpróbálok segíteni.

Az 1C:Enterprise technológia egyik szép tulajdonsága, hogy a menedzselt űrlapok technológiájával kifejlesztett alkalmazásmegoldás vékony (futtatható) kliensben Windows, Linux, MacOS X alatt, illetve webes kliensként 5 böngészőhöz is elindítható - Chrome, Internet Explorer, Firefox, Safari, Edge és mindez az alkalmazás forráskódjának megváltoztatása nélkül. Sőt, kívülről az alkalmazás a vékonykliensben és a böngészőben szinte azonosan működik és néz ki.
Találj 10 különbséget (a kivágás alatt 2 kép):

Vékony kliens ablak Linuxon:

Ugyanez az ablak a webes kliensben (Chrome böngészőben):

Miért csináltunk webklienst? Kissé szánalmasan szólva, az idő ilyen feladatot állított elénk. Az internetes munkavégzés hosszú ideje az üzleti alkalmazások előfeltételévé vált. Először is hozzáadtuk az interneten keresztüli munkavégzés lehetőségét vékony kliensünk számára (egyes versenytársaink egyébként megálltak itt, mások éppen ellenkezőleg, elhagyták a vékonyklienst, és a webes kliens megvalósítására korlátozódtak). Úgy döntöttünk, hogy lehetőséget adunk felhasználóinknak a számukra legmegfelelőbb ügyféllehetőség kiválasztására.

A webes képességek hozzáadása a vékonyklienshez nagy vállalkozás volt a kliens/szerver architektúra teljes megváltoztatásával. A webes kliens létrehozása egy teljesen új projekt, amely a nulláról indult.

A probléma megfogalmazása

Tehát a projekt követelményei: a webes kliensnek ugyanazt kell tennie, mint a vékony kliensnek, nevezetesen:

1. Felhasználói felület megjelenítése
2. 1C nyelven írt klienskód végrehajtása

Az 1C felhasználói felületét vizuális szerkesztőben írják le, de deklaratív módon, az elemek pixelenkénti elrendezése nélkül; körülbelül három tucat típusú interfész elemet használnak - gombok, beviteli mezők (szöveg, digitális, dátum / idő), listák, táblázatok, grafikonok stb.

Az 1C nyelvű ügyfélkód tartalmazhat szerverhívásokat, helyi erőforrásokkal való munkát (fájlok stb.), nyomtatást és még sok mást.

Mind a vékony kliens (ha a weben keresztül dolgozik), mind a webes kliens ugyanazt a webszolgáltatás-készletet használja az 1C alkalmazáskiszolgálóval való kommunikációhoz. A kliensek megvalósítása természetesen más - a vékony kliens C ++-ban, a webes kliens JavaScriptben van írva.

Egy kis történelem

A webes kliens projekt 2006-ban indult (átlagosan) 5 fős csapattal. A projekt bizonyos szakaszaiban fejlesztőket vontak be meghatározott funkciók megvalósításához (táblázatos dokumentum, diagramok stb.); általában ugyanazok a fejlesztők hozták létre ezt a funkciót a vékonykliensben. Azok. a fejlesztők JavaScriptben átírták azokat a komponenseket, amelyeket korábban C++-ban készítettek.

Kezdettől fogva elutasítottuk a vékonykliens C++ kódok bármilyen automatikus (legalább részleges) átalakítását webkliens JavaScriptre, a két nyelv közötti erős fogalmi különbségek miatt; a webklienst a semmiből JavaScriptben írták.

A projekt első iterációiban a webkliens a beépített 1C nyelvű kliens kódot közvetlenül JavaScript-be konvertálta. A vékony kliens másként működik - a beépített 1C nyelv kódja bájtkódba kerül lefordításra, majd ezt a bájtkódot értelmezi az ügyfélen. Ezt követően a webes kliens is hozzákezdett - egyrészt teljesítménynövekedést adott, másrészt lehetővé tette a vékony és webes kliens architektúrájának egységesítését.

Az 1C:Enterprise platform első verziója webes kliens támogatással 2009-ben jelent meg. A webes kliens akkoriban 2 böngészőt támogatott - Internet Explorer és Firefox. Az eredeti tervek az Opera támogatását tartalmazták, de az akkori Opera alkalmazáslezárási kezelőivel kapcsolatos áthidalhatatlan problémák miatt (nem lehetett 100%-os biztonsággal nyomon követni, hogy az alkalmazás bezárul, és abban a pillanatban a leválasztási eljárást elvégezni az 1C alkalmazásszervert) ezekből a tervekből el kellett hagyni.

Projekt felépítése

Összességében az 1C:Enterprise platform 4 projektet tartalmaz JavaScriptben:

1. A WebTools olyan megosztott könyvtárak, amelyeket más projektek használnak (itt szerepel a Google Closure Library is).
2. FormattedDocument vezérlőelem
3. Ütemező vezérlés (JavaScriptben implementálva a vékony kliensben és a webes kliensben is)
4. Web kliens

Az egyes projektek felépítése hasonlít a Java projektek (vagy .NET projektek – attól függően, hogy melyik áll közelebb Önhöz) szerkezetéhez; vannak névtereink, és minden névter ebben rejlik külön mappa. A mappában fájlok és névtér osztályok találhatók. A webes kliens projektben körülbelül 1000 fájl található.

Szerkezetileg a webes kliens nagyrészt a következő alrendszerekre oszlik:

• Felügyelt kliens alkalmazás felület
  • Általános alkalmazási felület (rendszermenük, panelek)
  • Felület kezelt űrlapok, amely többek között körülbelül 30 vezérlőt (gombokat, Különféle típusok beviteli mezők - szöveg, digitális, dátum / idő stb., táblázatok, listák, grafikonok stb.)
• A fejlesztők számára elérhető objektummodell a kliensen (összesen több mint 400 típus: kezelt felület objektummodell, adatösszetételi beállítások, feltételes formázás stb.)
• Beágyazott nyelvi tolmács 1C
• Böngészőbővítmények (a JavaScript által nem támogatott funkciókhoz használják)
  • Titkosított munka
  • Fájlokkal való munka
  • Technológia külső alkatrészek, így vékony és webes kliensekben is használhatók

Fejlesztési jellemzők

A fentiek megvalósítása JavaScriptben nem könnyű feladat. Talán az 1C webes kliens az egyik legnagyobb JavaScriptben írt kliensoldali alkalmazás – körülbelül 450 000 sor. Aktívan alkalmazunk objektum-orientált megközelítést a webes kliens kódban, ami leegyszerűsíti a munkát egy ilyen nagy projektnél.

Az ügyfélkód méretének minimalizálása érdekében először saját obfuszkátorunkat használtuk, majd a 8.3.6-os platformverziótól (2014. október) kezdtük el használni a Google Closure Compilert. A számokban való használat hatása a webes kliens keretrendszer mérete az obfuszkálás után:

• Saját obfuszkátor - 1556 kb
• Google Closure Compiler – 1073 kb

A Google Closure Compiler használatával 30%-kal javíthattuk a webes kliens teljesítményét a saját obfuszkátorunkhoz képest. Ráadásul az alkalmazás által fogyasztott memória mennyisége 15-25%-kal csökkent (böngészőtől függően).

A Google Closure Compiler nagyon jól működik objektum-orientált kóddal, így hatékonysága webes kliens esetén a legmagasabb. A Closure Compiler néhány jót tesz nekünk:

• Statikus típusellenőrzés a projekt összeállítási szakaszában (ezt az a tény biztosítja, hogy a kódot JSDoc megjegyzésekkel fedjük le). Az eredmény a statikus gépelés, amely nagyon közel áll a C++ nyelvű gépeléshez. Ez segít a hibák meglehetősen nagy százalékának kiszűrésében a projekt összeállítási szakaszában.
• A kód méretének csökkentése homályosítással
• A végrehajtható kód számos optimalizálása, például:
  • soron belüli függvényhelyettesítések. Egy függvény meghívása JavaScriptben meglehetősen költséges művelet, és a gyakran használt kis metódusok soron belüli helyettesítése jelentősen felgyorsíthatja a kódot.
  • Konstansok számolása fordítási időben. Ha a kifejezés egy konstanstól függ, akkor azt az állandó tényleges értékével helyettesítjük

Webkliens fejlesztői környezetünkként a WebStormot használjuk.

A kódelemzéshez a SonarQube-ot használjuk, ahol statikus kódelemzőket integrálunk. Analizátorok segítségével figyeljük a JavaScript forráskód minőségromlását és igyekszünk megakadályozni.

Milyen feladatokat végeztünk/oldunk meg

A projekt megvalósítása során számos érdekes feladattal szembesültünk, amelyeket meg kellett oldanunk.

Adatcsere a szerverrel és az ablakok között

Vannak olyan helyzetek, amikor a forráskód zavarása zavarhatja a rendszer működését. A webes kliens futtatható kódján kívüli kódnak az obfuszkáció miatt olyan függvény- és paraméternevek lehetnek, amelyek eltérnek a futtatható kódunk által elvárttól. A külső kód számunkra:

• A szerverről érkező kód adatstruktúraként
• Kód egy másik alkalmazás ablakhoz

A szerverrel való interakció során a zavarás elkerülése érdekében az @expose címkét használjuk:

/** * @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. kódolva ;)
És hogy elkerüljük a zavarást, amikor más ablakokkal kommunikálunk, az úgynevezett exportált interfészeket használjuk (azok az interfészek, amelyeken az összes metódust exportálják).

/** * A DropDownWindow vezérlő exportált felülete * * @interface * @struct */ WebUI.IDropDownWindowExp = function()() /** * A kijelölést 1-gyel előre vagy hátra mozgatja * * @param (boolean) isForward * @ param (boolean ) checkOnly * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarker = függvény (isForward, checkOnly)() /** * A kijelölést elejére vagy végére mozgatja * * @param (logikai érték) ) isFirst * @param (logikai) checkOnly * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly)() /** * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype .selectValue = function()()

Virtuális DOM-ot használtunk, mielőtt általánossá vált)

Mint minden bonyolult webes felhasználói felülettel foglalkozó fejlesztő, mi is hamar rájöttünk, hogy a DOM nem alkalmas a dinamikus felhasználói felületekhez. Szinte azonnal bevezetésre került a Virtual DOM analógja a felhasználói felülettel végzett munka optimalizálása érdekében. Az eseményfeldolgozás során az összes DOM-módosítás a memóriában tárolódik, és csak akkor, ha minden művelet befejeződött, a felhalmozott változtatásokat a rendszer a DOM-fára alkalmazza.

Webes kliens optimalizálás

Webkliensünk gyorsabb működése érdekében igyekszünk maximálisan kihasználni a böngésző szabványos szolgáltatásait (CSS stb.). Tehát az űrlap parancssorát (amely szinte minden jelentkezési űrlapon található) kizárólag a böngésző rajzolja meg, a CSS-en alapuló dinamikus elrendezés.

Tesztelés

A funkcionális és teljesítménytesztekhez saját eszközünket (Java és C++ nyelven írva), valamint egy Seleniumra épített tesztkészletet használunk.

Eszközünk univerzális - szinte bármilyen ablakprogram tesztelését teszi lehetővé, ezért vékony kliens és webkliens tesztelésére egyaránt alkalmas. Az eszköz egy szkriptfájlba rögzíti annak a felhasználónak a műveleteit, aki elindította az 1C alkalmazásmegoldást. Ezzel egyidejűleg rögzítik a képernyő munkaterületének képeit - hivatkozásokat. A webes kliens új verzióinak figyelésekor a forgatókönyvek felhasználói részvétel nélkül kerülnek lejátszásra. Abban az esetben, ha a képernyőkép egyik lépésben sem egyezik a referencia képpel, a teszt sikertelennek minősül, majd a minőségügyi szakember vizsgálatot végez - ez hiba vagy tervezett változás a rendszer viselkedésében. Tervezett magatartás esetén a szabványokat automatikusan újak váltják fel.

Az eszköz az alkalmazások teljesítményét is méri 25 ezredmásodperces pontossággal. Egyes esetekben a szkript egyes részeit hurkoljuk (például többször megismételjük a parancsbejegyzést), hogy elemezzük a végrehajtási idő időbeli romlását. Az összes mérés eredményét naplóban rögzítjük elemzés céljából.

Tesztelőeszközünk és alkalmazásunk tesztelés alatt

Eszközünk és a szelén kiegészítik egymást; ha például az egyik képernyőn valamelyik gomb megváltoztatta a helyét - előfordulhat, hogy a szelén nem követi, de az eszközünk észreveszi, mert pixelenként összehasonlítja a képernyőképet a standarddal. Ezenkívül az eszköz képes nyomon követni a billentyűzetről vagy az egérről érkező bevitel feldolgozásával kapcsolatos problémákat, mivel ezt reprodukálja.

Mindkét eszköz (a miénk és a Selenium) tesztjei tipikus munkaforgatókönyveket futtatnak az alkalmazási megoldásainkból. A tesztek automatikusan elindulnak az 1C:Enterprise platform napi felépítése után. Ha a szkriptek lelassulnak (az előző buildhez képest), kivizsgáljuk és kijavítjuk a lassulás okát. A mi kritériumunk egyszerű - az új összeállítás nem működhet lassabban, mint az előző.

A fejlesztők különböző eszközöket használnak a lassulási események kivizsgálására; főként a DynaTrace Dynatrace AJAX Edition-jét használják. Rögzítésre kerül a problémás művelet végrehajtásának naplója az előző és az új összeállításon, majd a naplókat elemzi. Ugyanakkor az egyes műveletek végrehajtási ideje (ezredmásodpercben) nem biztos, hogy döntő tényező - a szolgáltatási folyamatok, például a szemétszállítás időszakosan elindulnak a böngészőben, átfedhetik a funkciók végrehajtási idejét, és torzíthatják a képet. A relevánsabb paraméterek ebben az esetben a végrehajtott JavaScript utasítások száma, a DOM-on végrehajtott atomi műveletek száma stb. Ha az utasítások/műveletek száma ugyanabban a forgatókönyvben új verzió megnövekedett - ez szinte mindig teljesítménycsökkenést jelent, amelyet korrigálni kell.

A teljesítménycsökkenés egyik oka az is lehet, hogy a Google Closure Compiler valamilyen okból nem tudta behelyettesíteni a függvényt (például azért, mert a függvény rekurzív vagy virtuális). Ebben az esetben a forráskód átírásával próbáljuk orvosolni a helyzetet.

Böngészőbővítmények

Abban az esetben, ha egy alkalmazott megoldáshoz olyan funkciókra van szükség, amelyek nem szerepelnek a JavaScriptben, böngészőbővítményeket használunk:

• fájlokkal dolgozni
• kriptográfiával dolgozni
• külső alkatrészekkel való munkavégzés

Bővítéseink két részből állnak. Az első rész az úgynevezett böngészőbővítmény (általában JavaScript-bővítmények a Chrome-hoz és a Firefoxhoz), amely együttműködik a második résszel, egy bináris kiterjesztéssel, amely megvalósítja a szükséges funkciókat. Meg kell említeni, hogy a bináris kiterjesztések 3 verzióját írjuk - Windows, Linux és MacOS számára. A bináris kiterjesztést az 1C:Enterprise platform részeként szállítjuk, és az 1C alkalmazáskiszolgálón található. Amikor először hívják meg a webkliensből, akkor letöltődik az ügyfélszámítógépre, és telepítve van a böngészőbe.

Ha Safariban fut, bővítményeink NPAPI-t használnak, amikor befut internet böngésző- ActiveX technológia. A Microsoft Edge még nem támogatja a bővítményeket, így a webes kliens korlátozott.

További fejlődés

A webkliens-fejlesztő csapat egyik feladatcsoportja az további fejlődés funkcionalitás. A webkliens funkcionalitásának meg kell egyeznie a vékonykliens funkcionalitásával, minden új funkcionalitás egyszerre valósul meg a vékonykliensben és a webkliensben is.

További feladatok az architektúra fejlesztése, átalakítása, a teljesítmény és a megbízhatóság javítása. Például az egyik irány a további mozgás egy aszinkron munkamodell felé. A webes kliens funkcióinak egy része jelenleg a szerverrel való interakció szinkron modelljére épül. Az aszinkron modell ma már egyre relevánsabb a böngészőkben (és nem csak a böngészőkben), és ez arra kényszerít bennünket, hogy módosítsuk a webes klienst úgy, hogy a szinkron hívásokat aszinkronra cseréljük (és ennek megfelelően alakítsuk át a kódot). Az aszinkron modellre való fokozatos átállást a kiadott megoldások támogatásának és fokozatos adaptálásának szükségessége magyarázza.

Címkék: Címkék hozzáadása