Az 1C 8.3 platform verziójától kezdve lehetővé vált az infobázisok webszervereken való közzététele. Ez a megoldás nagyon kényelmes, mert a böngészőben található hivatkozásra kattintva teljes mértékben dolgozhat az 1C-ben. Kérjük, vegye figyelembe, hogy a munka csak "Vállalati" módban lehetséges. A konfigurátort csak vastag klienseken használhatja.

Természetesen az 1C bejelentette a követelmények listáját operációs rendszerés böngészők, amelyekről a webszerveren keresztül létrejön a kapcsolat az 1C-vel. De a gyakorlatban sokkal több lehetőség van. Például 1C-ben dolgozhat normál böngészőn keresztül mobiltelefonról.

Ebben a cikkben lépésről lépésre megvizsgáljuk az 1C 8.3 információs bázis közzétételét egy webszerveren Apache használatával. Az alább leírt beállítások, amelyeket magában az 1C-ben fogunk elvégezni, nem különböznek az IIS webszerveren történő közzétételtől.

A különbség csak annyi, hogy az IIS-t futtató szerver beállításokat tekintve „finomabb”, így legtöbbször az Apache-ra esik a választás.

Az Apache 2.4 telepítése és konfigurálása

Először is le kell töltenie magát az Apache-t például a hivatalos webhelyről. Aktuális be Ebben a pillanatban verzió 2.4. A telepítési folyamatban nincs semmi bonyolult, csak kövesse az asszisztenst.

Ha a telepítés során megjelenik egy ablak a szerverrel kapcsolatos információkkal, írja be az első két mezőbe a „localhost” szót. Ez azt jelenti, hogy a mi számítógépünk lesz az a szerver, amelyen az 1C található.

Vegye figyelembe azt is, hogy a 80-as portot fogjuk használni (az űrlap alján található kapcsoló). Fontos, hogy más alkalmazások ne foglalják el.

A program sikeres telepítése után egy speciális Apache ikon jelenik meg a tálcán. Ezzel elindíthatja és leállíthatja a webszervert.

Az információs bázis közzététele 1C 8.3

Után Apache telepítések közvetlenül folytathatja az információs bázis közzétételét a webszerveren. Ehhez lépjen ide: kívánt alapot konfigurációs módban. Itt minden szükséges műveletet végrehajtanak. Ebben az esetben, ahogy fentebb említettük, ezt az utasítást az IIS használata esetén használhatja.

Az „Adminisztráció” menüben válassza a „Közzététel webkiszolgálón” lehetőséget. A megnyíló ablakban az összes alapértelmezett beállítást meghagyjuk, csak egy kis részét módosítjuk.

Webszerverként az Apache 2.2-t választjuk, amelyet korábban telepítettünk. A név tetszőleges érték lehet. Kiadjuk az 1C: Dokumentumkezelést, ezért csak "doc"-nak nevezzük. A könyvtár mezőben kijelöljük az általunk létrehozott üres mappát is, amely bárhol elhelyezhető.

Az összes szükséges adat megadása után kattintson a „Közzététel” gombra, és indítsa újra az Apache webszervert.

Most címsor böngészőben írja be a „localhost/doc” kifejezést. Van egy engedélyezési ablakunk az 1C-ben.

Jelszóval és hitelesítéssel történő bejelentkezés után megnyílik előttünk az ismerős 1C.

31/05/2016

A Microsoft Internet Information Services (IIS) webszerverének konfigurálása az 1C:Enterprise platformokkal való együttműködésre

Általános információk a kiadványokról

Mint tudják, az 1C adatbázisok közzététele mind a konfigurátorból, mind a webinst segédprogram segítségével elvégezhető. A közzétételi algoritmus részletesebb leírása az ITS-en található, például ezen a linken.

Érdemes megjegyezni, hogy egy 64 bites szerveren csak a konfigurátorból vagy a webinst segédprogram használatával lehetséges a közzététel. Egyes terhelési tesztjeink során a 64 bites IIS webszerverek enyhén mutattak jobb teljesítmény, ezért egyéb korlátozások hiányában ezek használatát javasoljuk.

Ha 32 bites IIS webszervert kíván használni, ne felejtse el engedélyezni a 32 bites alkalmazások futtatását: az "Alkalmazáskészletek" listában minden egyes készlethez kattintson a jobb gombbal, helyi menü választ " Extra lehetőségek…” („Speciális beállítások”), majd állítsa a „32 bites alkalmazások engedélyezése” paramétert „Igaz” értékre.

A dokumentáció több fontos pontot is leír az IIS webszerverrel való munkával kapcsolatban. Idézéshez, amikor IIS webszerveren tesz közzé, ne feledje, hogy:

• A közzététel mindig az alapértelmezett webhelyen történik.
• A közzététel mindig az alapértelmezett alkalmazáskészletben (DefaultAppPool) történik.
• A .NET támogatást le kell tiltani az 1C:Enterprise művelethez használt alkalmazáskészletben. Ehhez állítsa be az "Environment Versions" alkalmazáskészlet tulajdonságot. NET Framework” (.NET-keretrendszer verzió) a „Nincs felügyelt kód” értékre.

Az első két pontra vonatkozó információk önmagukban is fontosak, és különösen a vizsgált kérdéssel összefüggésben, mivel a jövőben hasznosak lesznek számunkra. A harmadik javaslat tapasztalataink szerint nem kötelező, és az IIS webszerver sikeresen működik verzióhasználati módban, például .NET Framework v4.

Az IIS beállítása az 1C platform különböző verzióihoz

Több webszerver-bővítmény használatához, amelyek csak a verzió harmadik és negyedik számjegyében különböznek egymástól, különböző alkalmazáskészleteket kell használnia (ez ugyanazon alkalmazáskészleten belül nem lehetséges). Ennek megfelelően annyi alkalmazáskészletet kell létrehozni a webszerveren, ahány különböző verziójú beépülő modult terveznek használni, majd minden virtuális alkalmazást manuálisan hozzá kell rendelni a kívánt alkalmazáskészlethez.

Így például hozzunk létre például két további alkalmazáskészletet (általános esetben több is lehet), a kényelem kedvéért a készlet nevében tüntesse fel a platform verzióját, amellyel használni kívánjuk (jeleztük a verzió rövidített formában - "8.3.6", de ez kényelmesebb lehet az Ön számára teljes verzió, például "8.3.6.2237", vagy általában az alkalmazáskészleteket alkalmazásonként osztja fel, például "tesztfürtkészlet"). Állítsa be az ajánlott paramétereket (környezeti verzió, 32 bites alkalmazások használatának jele). Ennek eredményeként a következő listát kell látnia az IIS webszerver alkalmazáskészleteiről:

Ezután futtassa a konfigurátort (ne felejtse el végrehajtani ezt a műveletet a rendszergazda nevében), és hajtsa végre a közzétételt. Ahogy a dokumentációban is jeleztük, az "Alapértelmezett webhely" csoportban található (vagy frissítik, ha a közzététel már megtörtént) az új oldalról. A kiadvány speciális beállításai között megjelenik az alapértelmezett alkalmazáskészlet, a „DefaultAppPool”. A módosításhoz hívja a "Speciális beállítások..." vagy az "Alapbeállítások..." párbeszédpanelt. A főbbeket nevezzük:

Az alapértelmezett alkalmazáskészletet („DefaultAppPool”) a közzétett alap 1C platformjának verziójának („AppPool 1C 8.3.6” vagy „AppPool 1C 8.3.7”) megfelelő alkalmazáskészletre cseréljük.

Ha módosítania kell a webszerver bővítménykezelőjét (például a konfigurátorból való közzététel után 32 bitesről 64 bites verzióra), itt megteheti:

Ugyanezt tesszük egy másik információs bázissal és az 1C platform másik verziójával.

Ez minden szükséges beállításokat elkészült! Ellenőrizzük és élvezzük az egyidejű munkát az 1C webalkalmazásokkal különböző verziók egy webszerveren belül:

Következtetés

Ebben a cikkben egy olyan módszert ismertetünk, amely lehetővé teszi több információsbázis-kiadvány használatát egyetlen IIS-webkiszolgálón belül a különböző verziójú 1C:Enterprise információs bázisokhoz. Erre akkor van szükség, ha több működő vagy tesztadatbázissal rendelkező szerveren dolgozik, amelyeknél az 1C platform használt verziói eltérnek.

Reméljük, hogy könnyedén elvégezheti a szükséges feladatot, és továbbra is örömmel használja az 1C termékeket. Nos, ha valami nem sikerül, vagy nehézségekbe ütközik, mi biztosan segítünk!

Az 1C:Enterprise technológia egyik kedves tulajdonsága, hogy a technológia segítségével fejlesztett alkalmazási megoldást kezelt űrlapok, futtatható vékony (futtatható) kliensben Windows, Linux, MacOS X alatt, és webes kliensként 5 böngészőhöz - Chrome, internet böngésző, 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):

Ablak vékony kliens 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ába ( 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ügyelt űrlapok felülete, 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 felületeket használjuk (olyan felületek, amelyeken minden metódus exportálható).

/** * 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.

Web 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 egy szabadalmaztatott (Java és C++ nyelven írt) eszközt és a Selenium tetejére épített tesztcsomagot 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 dolgozik, bővítményeink NPAPI-t használnak, ha pedig Internet Explorer - ActiveX technológiát használnak. A Microsoft Edge még nem támogatja a bővítményeket, így a webes kliens korlátozottan működik.

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 manapság 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 webklienst ú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

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) Leírás Nyelv: Fájl: /var/lib/apt/lists/mirror.yandex.ru_wheeibianage8 /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n_Translation-en MD5: Leírás Nyelv: ru Fájl: /var/lib/apt/lists/mirror.yandex.ru_debian_dists_wheezy_main_i18n-en_MD5:ation

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áson keresztül lehet menni szöveg szerkesztő csináld. 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 mappából telepített fájlokat 1C ( /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ában másban linux disztribúciók minden ugyanúgy történik, a különbségek csak a telepítési módokban vannak régi verzió apache.