1s 8 borda és hozzáadott objektumok. Elosztott információs bázis. Lépésről lépésre szóló utasítások és buktatók. Elosztott infobázis cserebeállítások

A RIB egy elosztott információs bázis, amely egy faszerű struktúra, amelynek ágai egyedi telepített 1C Enterprise adatbázisok. Ezeket az alapokat elosztott csomópontoknak nevezzük információs bázis(a továbbiakban egyszerűen csomópontok). A csomópontok között információcsere jön létre az összes csomópont (konfiguráció és adatbázis) szinkronizálása érdekében.

A fő mechanizmus egy cseremechanizmus, amely néhány jellegzetes és univerzális képességgel rendelkezik. A fő különbség az, hogy a RIB cseremechanizmus speciálisabb és szűkebb, míg az univerzális cserék szélesebb lehetőségeket biztosítanak a felhasználónak.

A RIB alapvető működési elvei

A konfigurációs struktúra megváltoztatása csak az elosztott információs bázis fő gyökércsomópontjában lehetséges. Ezek a változások ezután hierarchikusan továbbadódnak az alárendelt csomópontoknak. Így ez egyetlen konfigurációs szerkezeti teret biztosít az összes RIB csomóponton.

Az adatok bármelyik csomópontban módosíthatók, ami viszont az összes többi csomóponthoz kerül. Ezen túlmenően ezeket az adatokat nem feltétlenül kell továbbítani a rendszer többi résztvevőjének, és előfordulhat, hogy teljes személyazonosságuk nem marad fenn. A fejlesztő tetszés szerint testreszabhatja a többi RIB résztvevővel való cserében részt vevő adatok összetételét. Sőt, a beállítások nem csak a konfigurációs metaadatok szintjén, hanem szinten is elvégezhetők egyedi elemek, amelyen speciális kiválasztások alkalmazhatók.

Mint fentebb említettük, a RIB mechanizmus cseretervek használatával érhető el. de azért, hogy ezt vagy azt a tervet felhasználják ebben hierarchikus struktúra, akkor aktiválva kell lennie az „Elosztott információbázis” tulajdonságnak.

Minden adat üzenetben kerül továbbításra a RIB-hez. Ezeknek az üzeneteknek a tartalma egyértelműen szabályozott, és nem lehet önkényes, mint az univerzális cseremechanizmusban. Az adatok az XML szerializációs elv alapján kerülnek egy üzenetbe. Ezeken az adatmódosításokon kívül az üzenet a konfigurációs változásokra vonatkozó információkat, valamint bizonyos mennyiségű szolgáltatási információt is tartalmaz. A változtatásokat a rendszer teljesen automatikusan regisztrálja és a csereüzenetbe helyezi. Ezt sem a felhasználó, sem a fejlesztő nem tudja befolyásolni.

A csereüzenetek fogadása és generálása a RIB-ben egyetlen paranccsal állítható be

Csere tervek. Változások írása (Üzenetek írása, 0)

A tartalom beolvasása a paranccsal történik

Következtetés

Nyugodtan kijelenthetjük, hogy a RIB mechanizmus főként a mechanizmusból áll univerzális csere néhány jellegzetes tulajdonsággal, amelyek csak a RIB szerkezetében vannak jelen.

Feladat: az információs bázist úgy kell beállítani, hogy három olyan felhasználó dolgozhasson egy működő adatbázisban, akik nem ugyanabban a működő adatbázisban vannak. helyi hálózat, de csatlakozik az internethez.

Végezzük el ezt a feladatot egy elosztott információs bázis létrehozásával. Információs bázis konfigurációja – „Vállalati számvitel 2.0”.

FTP-erőforrás beállítása.

Példaként állítsuk be az FTP-t a HCube használatával: Nyissa meg a hcube.ru webhelyet. Tárhely lap, FTP-tárhely (http://www.hcube.ru/hosting/ftp/). Válassza a minimumot díjcsomag FTP -10, ez elegendő lesz az elosztott információbázis csomópontjai közötti cseréhez. 15 napos próbaidőszakot rendelhet, kattintson a „Próba” gombra. Ezután regisztrálnunk kell:

Adja meg a felhasználónevet és a jelszót a személyes fiókjához való hozzáféréshez. A jelentkezés elfogadása után a megadott e-mailre várunk egy levelet FTP hozzáférési adatokkal. Információk a tárhelyszolgáltatás konfigurációjáról: ********************************************* ********* *************************
Hosting bejelentkezés: user725
Tárhely jelszó: ffUXP3CDU
Tárhely IP-címe: 85.10.207.234

****************************************************************
Vezérlőpult FTP-tárhelyhez https://cp.hcube.ru/manager/ispmgr

Várjuk az állam „aktívvá válását”.

Csereterv összeállítása.

Meg kell határozni az adatbázis központi csomópontját. Válasszunk központi csomópontnak munkahely az irodában található. A másik kettő a központi csomóponttal fog kommunikálni. Állítsuk be a központi csomópontot. Ehhez teljes jogú felhasználóként be kell jelentkeznie az információbiztonsági rendszerbe. A program főmenüjében válassza ki a kívánt elemet "Műveleti/cseretervek...". Az „Enterprise Accounting 8” standard konfiguráció csereterveiben már 7 szabványos csereterv készült: A terv megnyitása "Teljes". Egy előre meghatározott üres bejegyzést tartalmaz. Ez a bejegyzés az aktuális csomópontot írja le. Előre meghatározott, azaz. A konfigurációs szinten hozzáadott bejegyzés nem törölhető, de javítható. Kattintson a szerkesztés: mezőre "Név" tetszőleges lehet például "Központi csomópont". "Kód" tetszőleges is lehet például "01", kattintson "RENDBEN". Az aktuális csomópont leírása megtörtént, most szükséges a slave csomópontok leírása. Adjon hozzá új elemeket a névvel "1. csomópont"és kódot "02"És "2. csomópont" kóddal "03". Három csomópontot kapunk:
A RIB-ben sok szolga csomópont lehet, és a csere egy központi csomópont és az egyes szolga csomópontok között történik. Most hozzunk létre egy szolga csomópontot (egy új adatbázist). Ehhez a csomóvonalra kell állnia "1. csomópont"és kattintson az ikonra "Kezdőkép létrehozása..." vagy válassza ki ezt a műveletet a menüből:
A rendszer kérni fogja, hogy válassza ki az információs bázis (IS) típusát. Ki kell választani "Tovább ez a számítógép…» . Ezután adja meg azt a könyvtárat, amelyben az új információbiztonság létrejön. Ezt követően egy új adatbázis jön létre a megadott könyvtárban, és a fő adatbázis összes adata átkerül ebbe az adatbázisba. Érdemes rögtön megjegyezni, hogy az új információbiztonság nem pontos másolata eredeti. Saját beállításai vannak (saját felhasználók listája stb.), csak az adatok és a módosított cseretervek kerülnek átvitelre, pl. az új információbiztonságban csak két csomópont lesz "Központi csomópont"És "1. csomópont". Ha a forrásadatbázis nagy és felhasználók dolgoznak benne, akkor a kezdeti kép létrehozása során ütközések adódhatnak, ezért javasolt az új kép létrehozásának műveletét a monopólium mód. Ha több szolga csomópontot írtunk le a központi csomópontban, akkor minden csomópontra el kell végezni a kezdeti információbiztonsági kép létrehozásának műveletét, azaz annyi új információbiztonsági rendszer jön létre, ahány csomópont az eredeti adatbázisban leírtak. Ugyanezt fogjuk tenni "2. csomópont". A kezdeti kép létrehozásakor a fő adatbázisban egy tábla jön létre a fő adatbázis objektumainak ezzel a csomóponttal való szinkronizálására. Általában az ilyen táblákat a szolga csomópontok száma szerint hozzák létre. A csomópont kezdeti képének létrehozásakor a szinkronizálási zászló a csomóponttal be van állítva. Most a szolga csomópontok adatbázisait át kell másolni munkaállomásokra "1. csomópont"És "2. csomópont". Ezt követően a három számítógép azonos (adatbázisú) információs bázissal rendelkezik.

Elosztott infobázis cserebeállítások.

Ebben a feladatban van egy általános eset, amikor mindhárom adatbázis működik, azaz. a dokumentumokat három adatbázisba kell bevinni és módosítani. Menjünk a menühöz "Szolgáltatás / Elosztott információs bázis (RIB) / RIB csomópontok konfigurálása". Készítsünk cserét között Központi csomópontÉs 1. csomópont. Az „Elosztott információs bázisok” lapon hozzáadjuk új elem, nevezzük "Iroda – 1. csomópont"(ahol az "Office" a központi csomópontunk). Válasszon a kellékek közül "Csomó" – "1. csomópont". A terepen "Csere típusa" választ "Cseréljetek FTP erőforrás". Az e-mailben elküldött adatokat kitöltjük: "Cím", "Felhasználó", "Jelszó". Tabs "Interaktív csere"És "Automatikus csere" Még nem töltjük ki, minden csomópontban az alapvető cserebeállítások után tesszük meg. Ezután analógia útján létrehozunk egy új elemet a központi csomópont és a 2. csomópont közötti adatcsere beállításához.
Menjünk a korábban létrehozott kezdőképre (információs bázis) 1. csomópontés hozzon létre beállításokat "1. csomópont – Iroda". Tegyük ugyanezt a 2. csomópontban is. A lapon "Interaktív csere" meghatározhatjuk, hogy egyszerre kell-e fel- és letöltenünk adatokat, vagy csak egy dolgot. A lapon "Automatikus csere"új elemet adhat hozzá az automatikus csere konfigurálásához. Itt beállíthatunk egy ütemezést egy adott cseréhez, pl "Iroda – 1. csomópont"és/vagy eseményalapú csere.

Amikor kiválaszt egy felhasználót az eseménymegosztási beállításokban, akkor is meg kell adnia adott felhasználó V "Programbeállítások" a lapon "Adatcsere".
Példánkban a csere csak akkor valósul meg, ha az adatbázisba a beállításokban megadottak szerint van bejelentkezve "Csere eseményenként" felhasználó. Azt is jelezni kell "Csomópont előtag az elosztott információs bázishoz" a dokumentumok helyes számozása érdekében. Az előtag használatával láthatjuk, hogy melyik csomópont hozta létre a dokumentumot, és elkerülhető a bizonylatszámok megkettőzése. Mert kényelmes munkavégzés egy elosztott információs bázisban gondosan mérlegelni kell a csomópontok egymás közötti cseréjének ciklusát, a csere ütemezését és/vagy az események szerinti cserét egy adott feladathoz.

Létrehozás és konfiguráció elosztott bázis adatok (RIB) az 1C 8.3 Könyvelésben (és egyéb konfigurációkban) olyan esetekben szükségesek, amikor nem lehetséges, hogy több felhasználó dolgozzon, miközben egyidejűleg csatlakozik egy adatbázishoz. Manapság ez meglehetősen ritka eset, mivel a szabványos távoli asztal jól működik, és vannak más programok, amelyek távoli kapcsolatot biztosítanak az adatbázist tartalmazó központi számítógéphez.

Ennek ellenére vannak olyan helyzetek, amikor egyszerűen nincs internet. És az adatoknak végül egyetlen információs bázisba kell kerülniük. Ezért jön létre egy elosztott adatbázis.

Általában a fő bázist központinak, a többit perifériásnak nevezik. A lényeg az, hogy akár manuálisan, akár automatikusan (beállításoktól függően) az adatbázisokat egyesítik egybe. Annak biztosítása érdekében, hogy az újonnan bevitt dokumentumok és hivatkozási kódok száma ne duplikálódjon, minden adatbázishoz egy előtag van hozzárendelve.

Ebben az utasításban egy példa segítségével létrehozunk egy központi és perifériás adatbázist, és ellenőrizzük a köztük lévő adatcserét. Ez a kézikönyv az 1C 8.3 Accounting és az 1C Trade Management (UT) és egyéb konfigurációkhoz egyaránt alkalmas.

A fő (központi) elosztott RIB adatbázis beállítása

Lépjünk az 1C „Adminisztráció” menüjébe, majd kattintsunk az „Adatszinkronizálási beállítások” hivatkozásra. A megnyíló ablakban be kell jelölnie az „Adatszinkronizálás” jelölőnégyzetet. Az „Adatszinkronizálás” hivatkozás aktívvá válik. Itt beállítunk egy előtagot a fő információs bázishoz - például „CB”:

Kattintson az „Adatszinkronizálás” hivatkozásra, és megnyílik egy ablak az „Adatszinkronizálás beállítása” gombbal. Amikor erre a gombra kattint, megnyílik egy legördülő lista, ahol ki kell választania a „Teljes” módot. Ha a szinkronizálás csak egy szervezetnél szükséges, válassza ki a „Szervezet szerint...” lehetőséget.

A következő ablakban a program felkér minket, hogy készítsünk biztonsági másolatot. Erősen javaslom ezt, mivel a következő beállítási lépések visszafordíthatatlanok lehetnek.

A teremtés után biztonsági másolat kattintson a „Tovább” gombra. A következő lépésben el kell döntenünk, hogyan fog megtörténni a szinkronizálás:

• helyi címtáron vagy a helyi hálózaton található könyvtáron keresztül;
• interneten keresztül FTP-n keresztül.

A példa egyszerűsége és érthetősége érdekében egy helyi könyvtárat választunk. A következő elérési utat adtam meg: „D:\1C Databases\Synchronization”. Jó ötlet lenne ellenőrizni a bejegyzéseket ebben a könyvtárban, erre van egy speciális gomb:

Szerezzen ingyen 267 videóleckét 1C-n:

Következő lépések az FTP szinkronizálás beállításával és email kihagyjuk. Nézzük meg a fő és a periféria adatbázisok nevének beállításait. Itt beállítjuk a periféria adatbázis előtagját:

Ne felejtse el, hogy az egyes adatbázisok előtagjainak egyedinek kell lenniük. Ellenkező esetben a következő hibaüzenet jelenik meg: „Az első információs bázis előtag értéke nem egyedi”.

Kattintson a „Tovább” gombra, ellenőrizze a beírt adatokat, majd kattintson ismét a „Tovább” gombra, majd a „Befejezés” gombra. A „Teljes név” mezőben fájl adatbázis"Jelölje meg az 1Cv8.1CD fájlt a szinkronizáláshoz létrehozott könyvtárban. Elkészítjük az elosztott 1C adatbázis kezdeti képét:

Miután létrehozta a RIB kezdeti képét az 1C-ben, beállíthat egy szinkronizálási ütemezést, vagy manuálisan szinkronizálhat:

A szinkronizálás után csatlakozhat az új adatbázishoz, és megbizonyosodhat arról, hogy a központi adatbázis információi felkerültek oda:

Csak azonnal hozzon létre legalább egy felhasználót rendszergazdai jogokkal az új periféria adatbázisban.

Szinkronizálás beállítása a perifériás adatbázisban

Az 1C perifériás adatbázisban a konfiguráció sokkal egyszerűbb. Csak jelölje be az „Adatszinkronizálás” jelölőnégyzetet, és kövesse az azonos nevű hivatkozást. És szinte azonnal egy ablakban találjuk magunkat a „Szinkronizálás” gombbal. Próbáljunk meg létrehozni egy tesztelemet a perifériás adatbázisban, és feltölteni a főbe a RIB segítségével:

2016. október 25

Nincs nagy különbség a RIB beállítása és támogatása között 2 és 10 csomópont esetén, de amikor a távoli pontok száma meghaladja a százat, teljesen más problémákat kell megoldani.

Kiinduló adatok:

Konfiguráció: Kiskereskedelem 2.2
1C platform: 1970.7.8.3



A projekt időtartama: egy év.



Építészet:

Először a RIB konstrukció mellett döntöttünk. Úgy döntöttek, hogy a lehető leghosszabb ideig a „sztár” rendszerre összpontosítanak; a technológiai korlátok elérésekor - hópehely.





Korlátozások:
- 2 GB RAM
- 1 fizikai processzor


A fentiek közül a fő bosszantó dolog az adatbázis maximális méretének korlátozása.

De ez csak azt jelenti, hogy gondosan meg kell szerveznie egy eljárást az elavult adatoktól való megtisztítására a helyszínen.

Az 1C és az MS SQL szerverhez külön fizikai szerver van kijelölve. Ez viseli majd a csere és a hosszú távú műveletek fő terhét.
A végkliens számítógépeket nem cserélik le, mert működni fognak vékony kliensés minimális lesz a terhelésük.
.


alapbeállítások

Az UT 10.3 óta, amikor az első projektem volt a 60 csomós RIB megvalósítása, természetesen „sok víz elment a híd alatt”.

1C nem állt meg. A Retail 2.2 mostantól figyelembe veszi a szelektív adatfeltöltés szükségességét.
Csak a számára releváns információ kerül fel az üzlet adatbázisába:
- Minden referenciakönyv (kivéve a speciális könyveket)
- Dokumentumok ehhez az üzlethez

Más kérdés, hogy így vagy úgy, egy csomópont hozzáadása az adatbázishoz azt jelenti, hogy minden egyes regisztrációs táblához egy újabb bejegyzést kell hozzáadni. közös elem rögzítésekor.





1) Külön szinkronizálási forgatókönyvekre kell osztani a feltöltést és a letöltést
A lényeg az, hogy a kirakodás sokáig tart és blokkolással jár, míg a berakodás meglehetősen problémamentes. Ugyanakkor gyakran előfordul, hogy gyorsan kell adatokat fogadnunk a kiskereskedelmi egységekből, miközben naponta csak néhány alkalommal adjuk át.

2) Azonosítsa a problématárolókat, és távolítsa el őket az általános szinkronizálási forgatókönyvből. Nagy kirakodások lehetnek rajtuk - ez lelassítja a teljes cserét, beleértve a többi csomópontot is. A problémák megoldása után a rendszer visszaadja őket.

3) Hozzon létre több szkriptet az adatok küldéséhez és fogadásához. De itt a legfontosabb dolog mennyiségük megfelelő egyensúlyának megtalálása.
(8.1-es verzió óta).
Következésképpen a párhuzamosság a RIB kirakodásában korlátozott. A gyakorlatban kiderül, hogy 2-3 szkriptet futtat párhuzamosan.


Amit javítani kellett

Az 1C RIB szabványos logikájában a legfontosabb probléma a frissítések

A csere másik problémája az információs nyilvántartások. Az információs regiszter minden rekordjának XML-be való feltöltése külön XML-csomópontot hoz létre szolgáltatáselemekkel stb. Ezen túlmenően a „SelectChanges()” függvény egy 100 rekordot tartalmazó információs regiszterhez egy 100 soros táblázatot kap. ugyanakkor, ha ennek a 100 soros A-könyvtárnak csak egy bejegyzése lesz kiválasztva a táblázatos részében. És ez az exkluzív blokkolás ideje. Tehát ha sok olyan rekord van a PC-ben, amit rendszeresen regisztrálnak cserére más üzletekbe, akkor természetesen helyesebb lenne ezt egy könyvtár formájában bemutatni táblázatos rész, amely extrém esetekben, ha leírjuk, egyazon regiszter sztringjeit képezheti. Akárhogyan is, .

Egy másik fontos részlet - Miért? Már közel 3 millió kedvezménykártya létezik, amelyekkel külső online rendszer működik. Ha továbbra is az összes üzletbe utalja át a diszkontkártyákat, az jelentősen megnöveli a cseréket, és azt is eredményezheti, hogy az alap meghaladja a 10 GB-ot.

A mechanizmusok egy része online valósul meg a központi adatbázis kapcsolatfelvételével: egyenleg más üzletekben, nyugta visszaküldése egy másik üzletből, ajándékutalvány érvényességének ellenőrzése.


Replikáció


Egy kezdeti RIB csomópont szabályos létrehozása elvben lehetetlenné tenné a replikációt.
Ezért a következőképpen jön létre egy új csomópont:


2) Ez az adatbázis az összes általános adatot kicseréli a RIB-ben, de nem kap speciális (dokumentumokat)


5) Elkészült a bolt alapja.

Egy kész szoftvercsomag kerül a szerverre, így nem sok időt vesz igénybe. Ezután az újonnan létrehozott adatbázis feltöltődik a szerverre, és készen áll az áruházba való elküldésre.


A vékony kliens előnyei

A Retail 2.2 (Vékony kliens) két jelentős előnye, amelyek „melengették a lelket”:








Támogatás és frissítések




1) Manuális frissítés az üzletekből (nem túl helyes, előfordulhat, hogy a módosítások nem érkeznek meg, hívások és problémák lesznek) - ez korábban is így volt

3) Írjon egy *.cmd vagy 1C szkriptet a frissítéshez, vagy készítsen egy kész szkriptet. A gyakorlat azt mutatja, hogy egy ilyen megoldás mindig félszeg (instabil), és kevés funkcionalitást lehet majd beleépíteni.

Mik voltak a feladataink:


2) Frissítéskor interaktív interakció lehetséges a felhasználóval (üzenetek, megerősítés, folyamatjelző).








Főbb funkciók:




4) Ügynökök állapotának ellenőrzése
5) Frissítse a jelentéseket
6) biztonsági mentés

















Például így néz ki a hibaüzenet frissítés után:

Így a projektnek jó esélye volt a sikeres befejezésre. Legalább a repülés felénél a repülés normális.

Ha más, érdekesnek tűnő megoldáshoz jutunk, külön írok

P.S. és ami a legfontosabb: A további támogatás megfelelő tervezése az egyik kulcstényező az ilyen projektek további sikeréhez. :)

2016. október 25

Nincs nagy különbség a RIB beállítása és támogatása között 2 és 10 csomópont esetén, de amikor a távoli pontok száma meghaladja a százat, teljesen más problémákat kell megoldani.

Tehát a kezdeti adatok:

Konfiguráció: Kiskereskedelem 2.2
1C platform: 1970.7.8.3
A csomópontok becsült száma a projekt végén: 200
Berendezési erőforrások a központban: jelentős korlátozások nélkül
Felszereltség a ponton: megvitatott kérdés.
A projekt időtartama: egy év.

Építészet:

Először a RIB konstrukció mellett döntöttünk. Korábban úgy döntöttek, hogy a „sztár” sémára összpontosítanak
Kiskereskedelmi üzletekben használják kliens-szerver opció Windows operációs rendszert futtató dedikált szerverrel dolgozhat.
Az 1C szervert a „Server 1C MINI” verzióban fogják használni https://1c.ru/news/info.jsp?id=17577
DBMS szerver - MS SQL Express 2008 R2.

Az SQL Express 2008 R2 ennek az SQL Server-sorozatnak a legújabb verziója.
Korlátozások:

2 GB RAM
- 1 fizikai processzor
- Maximális adatbázisméret 10 GB

A fentiek közül a legbosszantóbb természetesen az adatbázis maximális méretének korlátozása. De valójában ez csak azt jelenti, hogy gondosan meg kell szervezni az elavult adatoktól való helyszíni tisztítási eljárást.

Az 1C és az MS SQL szerver számára külön szerver van kijelölve. Ez viseli majd a cserék és tranzakciók fő terhét.
A végkliens számítógépeket nem cserélik le, mert vékony klienssel működnek, és az alsó terhelés minimális lesz.
A boltban található szerver egyszerűen egy nagy teljesítményű számítógép. De előfeltétel a jelenlét SSD meghajtó- amelyen MS SQL adatbázisok találhatók.
A szerver emellett lehetővé teszi a rutinműveletek éjszakai végrehajtását és a munka megszakítása nélkül történő hozzáférést az áruház adatbázisához.

alapbeállítások

Az UT 10.3 óta, amikor az első projektem volt a 60 csomós RIB megvalósítása, természetesen „sok víz elfolyt a híd alatt”. 1C nem állt meg. A Retail 2.2 mostantól figyelembe veszi a szelektív adatfeltöltés szükségességét.
Az áruház adatbázisába csak az üzlet szempontjából releváns információk kerülnek feltöltésre:
- Minden könyvtár (néhány kivételével)
- Dokumentumok ehhez az üzlethez
Az adatrögzítés a regisztrációs szabályok szerint történik, minden, ami gyorsítótárazható. A regisztráció során nincs jelentős lassulás.
Egy másik kérdés, hogy így vagy úgy, egy csomópont hozzáadása az adatbázishoz azt jelenti, hogy minden adatbázis minden közös eleméhez egy újabb rekordot kell hozzáadni.

Magában a feltöltés beállításában nincs semmi konkrét. Van néhány árnyalat a szinkronizálási forgatókönyvek beállításakor:

1) A fel- és betöltést külön szinkronizálási forgatókönyvbe kell elkülöníteni
A lényeg, hogy a kirakodás sokáig tart és blokkolással jár, míg a berakodás meglehetősen problémamentes. Ugyanakkor gyakran előfordul, hogy gyorsan kell adatokat fogadnunk a kiskereskedelmi egységekből, miközben naponta csak néhány alkalommal adjuk át.

2) Azonosítsa a problématárolókat, és távolítsa el őket az általános szinkronizálási forgatókönyvből. Nagy terhelések lehetnek rajtuk - ez lelassítja a teljes cserét, beleértve a többi csomópontot is

3) Hozzon létre néhány küldési és fogadási szkriptet az adatok küldéséhez és fogadásához. De itt a legfontosabb az egyensúly.
Néhány dolog az 1C-ben nem változik. Ugyanaz a "SelectChanges" metódus csak szekvenciálisan hajtható végre(8.1-es verzió óta).
Következésképpen a párhuzamosság a RIB kirakodásában korlátozott. A gyakorlatban 2-3 szkriptet tölt fel egyszerre.
Ami a befogadási forgatókönyvet illeti, itt természetesen sokkal nagyobb párhuzamosság lehetséges, ha szükséges.

Amit javítani kellett

Természetesen szomorú és szomorú, de alaposan be kellett avatkoznom a BSP-be. A szabványos 1C logikában a legfontosabb probléma a frissítések. A frissítés után egy ehhez hasonló ablak jelenik meg:

Mindez monopólium módban történik. Többek között a rendszer exkluzív módban történő frissítés után is megpróbál cserét végrehajtani. Nem nehéz kitalálni, hová vezet mindez.
A teljes időtartam alatt az üzlet nem működhet, vásárlók vannak a pénztárnál, és a cég veszteséges.

A csere másik problémája az információs nyilvántartások. Az egyes információs regiszterbejegyzések XML-be való feltöltése külön XML-csomópontot hoz létre szolgáltatáselemekkel és minden további elemmel. Ezen túlmenően egy 100 rekordot tartalmazó információs regiszternél a „módosítások kiválasztása” funkcióval az eredményül kapott táblázat 100 sort fog tartalmazni, ugyanakkor, ha ez egy 100 soros könyvtár, akkor csak egy rekord kerül kiválasztásra a táblázat szakasz. Tehát ha sok olyan rekord van a PC-ben, amit rendszeresen regisztrálnak cserére más üzletekbe, akkor természetesen helyesebb ezt egy táblázatos résszel ellátott könyvtár formájában bemutatni, ami extrém esetben rögzítéskor , képes ugyanannak a regiszternek a rekordjait generálni. Akárhogyan is, az információs nyilvántartások a cserékben gonoszak.

Egy másik fontos részlet - A kedvezménykártyák teljes mértékben ki vannak zárva a cseréből, és csak egy adott üzlet alkalmazottai záródnak ki a cseréből. Miért? Már közel 3 millió kedvezménykártya létezik, amelyekkel külső online rendszer működik. Ha továbbra is az összes üzletbe utalja át a diszkontkártyákat, az jelentősen megnöveli a cseréket, ráadásul az alap 3 GB-ot is meghaladó mennyiségéhez vezethet.

A mechanizmusok egy része online valósul meg a központi adatbázis kapcsolatfelvételével: egyenleg más üzletekben, nyugta visszaküldése egy másik üzletből, ajándékutalvány érvényességének ellenőrzése.

Replikáció

Természetesen a replikáció gyorsított ütemben történik.
A kezdeti RIB csomópont szabványos módon történő létrehozása természetesen lehetetlenné tenné a replikációt.
Ezért egy új csomópont jön létre a következőképpen:

1) Van egy külön adatbázis hamis bolttal
2) Ez az adatbázis az összes általános adatot kicseréli a RIB-ben, de nem kap speciális adatokat
3) Ha új adatbázist akarunk létrehozni, egyszerűen másoljuk ezt
4) Ezután megadjuk a beállításokat - tároló, előtag stb.
5) Elkészült a bolt alapja.

Egy kész szoftvercsomag kerül a szerverre, így nem sok időt vesz igénybe. Ezután az újonnan létrehozott üzletek adatbázisa feltöltődik a szerverre, és készen áll az üzletbe való elküldésre.

A vékony kliens előnyei

két jelentős előny, amelyek „melengették a lelket”.

1) Nincs szükség a kiskereskedelmi egységek teljes számítógépparkjának cseréjére. A műveletek 90%-a a szerveren történik, és a szerver egy „viszonylag erős számítógéppel” kerül oda.

2) A berendezések képesek megtagadni a munkát, ez különösen gyakran fordul elő újonnan telepített vagy már elhasználódott berendezésekkel.
Ebben az esetben a műveletek rendkívül egyszerűek - az áruház átvált a központi adatbázisban való munkára.
Ez a folyamat nem tart tovább 5-10 percnél, így a kereskedés akkor sem szakad meg, ha a berendezéssel jelentős problémák merülnek fel.

Támogatás és frissítések

Végül elérkeztünk a legérdekesebb ponthoz - hogyan lehet mindezt karbantartani és frissíteni?
Frissítések nekünk is hosszú ideje dilemma volt:

1) Frissítse manuálisan az üzletekből (nem túl helyes, előfordulhat, hogy a módosítások nem érkeznek meg, hívások és problémák lesznek)
2) Frissítés erőkkel technikai támogatás(nem olyan sok forrás)
3) Írjon *.cmd fájlt a frissítéshez, vagy vegyen egy készet. Ahogy a gyakorlat azt mutatja, egy ilyen megoldás mindig félszeg (instabil), és kevés a funkcionalitás.

Mik voltak a feladataink:

1) A frissítésnek több módban kell történnie, és központilag kell kezelni
2) Frissítéskor interaktív interakció lehetséges a felhasználóval.
3) A frissítés állapotáról és a hibákról jelentéseket kell fogadni
4) Kell lennie egy biztonsági másolatnak
5) A frissítési rendszernek képesnek kell lennie arra, hogy probléma nélkül frissítse magát.
6) A rendszernek gond nélkül bővíthetőnek kell lennie.

Természetesen a feladatok messze túlmutattak a megoldhatóak listáján egyszerű módszerek. Mert ennyi végpont mellett nem nélkülözhetjük az automatizálást, és nem találtunk többé-kevésbé készen hasonló funkcionalitással
El kellett kezdenem a szoftver fejlesztését, ami végül megkapta a MU (MagicUpdater) nevet.

Főbb funkciók:

1) Dinamikus adatbázis-frissítés (parancs vagy ütemezett)
2) Statikus adatbázis frissítés (parancs vagy ütemezett)
3) automatikus ügynökök a végszámítógépeken, ha módosulnak
4) Ügynökök állapotának ellenőrzése
5) Frissítse a jelentéseket
6) biztonsági mentés
7) Adminisztratív műveletek 1C szerverrel és MS SQL-lel
8) Zárja be az összes 1C kliens alkalmazást a hálózati számítógépeken
9) Statikus frissítés elfogadással a főpénztárnál
10) A módosítások leírásának megjelenítése frissítés után
11) A műveletek sorrendjének felállítása
12) Hajtsa végre ezeket a műveleteket ütemezetten

Hozzávetőleges interakciós sémák:

Ahol az MU-ügynök az áruházban telepített és konfigurált szolgáltatás. Valójában parancsot kap a központtól bizonyos feladatok elvégzésére.
MU-kiszolgáló – Az a szerver, amely megkapja a rendszerhez intézett összes kérést.
A MU monitor – amit a szokásos technikai támogatási alkalmazottak látnak – a naplók megtekintésére és a frissítési feladatok beállítására vagy egyebekre használják.

Egész jól sikerült, szerintem. Mostantól a frissítések szinte automatikusan megtörténnek.
Így néz ki például a hibaüzenet a frissítés után, minden a központban marad és vár.

És így küldünk parancsokat a kliens számítógépeknek

Az alkalmazások természetesen nem 1C, hanem meglehetősen tisztességes interfész-képességekkel. A dátum szerinti kijelölés például így néz ki:

Most készen állnak a további replikációra. A további támogatás megfelelő tervezése az egyik kulcstényező az ilyen projektek további sikeréhez.