25 oktober 2016
Det är ingen stor skillnad mellan att ställa in och stödja RIB för 2 noder och för 10, men när antalet fjärrpunkter överstiger hundra måste helt andra problem lösas
Initial data:
Konfiguration: Detaljhandel 2.2
Plattform 1C: 8.3.7.1970
Projektets varaktighet: ett år.
Arkitektur:
Först bestämde vi oss för RIB-schemat. Det beslutades att fokusera på "stjärnan" så länge som möjligt; när tekniska begränsningar nås - en snöflinga.
Begränsningar:
- 2 GB RAM
- 1 fysisk processor
Av allt ovanstående är det främsta irriterande begränsningen av den maximala databasstorleken.
Men detta betyder bara att du måste noggrant organisera en procedur för att rengöra den från föråldrade data på plats.
En separat fysisk server tilldelas för 1C- och MS SQL-servern. Den kommer att bära den största bördan av utbyten och långsiktig verksamhet.
Slutklientdatorerna ersätts inte, eftersom de kommer att fungera med den tunna klienten och belastningen på dem blir minimal.
.
Grundinställningar
Sedan tiden för UT 10.3, då jag hade mitt första projekt med att implementera RIB i 60 knop, har naturligtvis "mycket vatten passerat under bron."
1C stod inte stilla. Retail 2.2 tar nu hänsyn till behovet av selektiv datauppladdning.
Endast information som är relevant för den kommer att laddas upp till butiksdatabasen:
- Alla referensböcker (utom specialiserade)
- Dokument för den här butiken
En annan fråga är att på ett eller annat sätt innebär att lägga till en nod i databasen att lägga till ytterligare en post i registreringstabellen för varje gemensamt element när det skrivs.
1) Det är nödvändigt att dela upp i separata synkroniseringsscenarier för upp- och nedladdning
Poängen är att lossningen tar lång tid och innebär blockering, samtidigt som lastningen är ganska problemfri. Samtidigt händer det ofta att vi snabbt behöver ta emot data från butiker, samtidigt som vi bara ger bort det några gånger om dagen.
2) Identifiera problematiska butiker och ta bort dem från det allmänna synkroniseringsscenariot. Det kan finnas stora lossningar på dem - detta kommer att sakta ner hela utbytet, inklusive andra noder. När problemen är lösta läggs de till igen.
3) Skapa flera skript för att skicka och ta emot data. Men det viktigaste här är att fånga den rätta balansen av deras kvantitet.
(sedan version 8.1).
Följaktligen är parallelliteten vid lossning av RIB begränsad. I praktiken visar det sig köra 2-3 skript parallellt.
Vad behövde förbättras
Det viktigaste problemet i standardlogiken för 1C RIB är uppdateringar
Ett annat problem med utbyte är informationsregister. Genom att ladda upp varje post av informationsregistret till XML skapas en separat XML-nod med serviceelement etc. Dessutom kommer funktionen "SelectChanges()" för ett informationsregister i vilket det finns 100 poster att få en resulterande tabell med 100 rader, kl. samtidigt, om detta En katalog med 100 rader har endast en post vald i dess tabellsektion. Och detta är tiden för exklusiv blockering. Så om det finns många poster i PC:n som regelbundet registreras för utbyte till andra butiker, så är det naturligtvis mer korrekt att presentera detta i form av en katalog med en tabelldel, vilket i extrema fall vid inspelning , kan bilda rader av samma register. I alla fall, .
En annan viktig detalj - För vad? Det finns redan närmare 3 miljoner rabattkort Ett externt onlinesystem används för att arbeta med dem. Om du fortsätter att överföra rabattkort till alla butiker kommer detta att öka utbytet avsevärt och kan även leda till att basen överstiger volymen på 10 GB.
Några av mekanismerna implementeras online genom att kontakta den centrala databasen: saldon i andra butiker, returnera ett kvitto från en annan butik, kontrollera giltigheten av ett presentkort.
Replikering
Att skapa en initial RIB-nod på ett regelbundet sätt skulle göra replikering omöjlig i princip.
Därför skapas en ny nod enligt följande:
2) Denna databas utbyter alla allmänna data i RIB men tar inte emot specialiserade (dokument)
5) Basen för butiken är klar.
Ett färdigt mjukvarupaket distribueras på servern, så det tar inte mycket tid. Sedan laddas den nyskapade databasen upp på servern och den är redo att skickas till butiken.
Fördelarna med en tunn klient
Två betydande fördelar med Retail 2.2 (tunn klient) som "värmde själen":
Support och uppdateringar
1) Uppdatera manuellt från butiker (inte särskilt korrekt, ändringar kanske inte tas emot, det kommer att bli samtal och problem) - så var fallet tidigare
3) Skriv ett *.cmd- eller 1C-skript för uppdatering eller ta ett färdigt. Som praktiken visar är en sådan lösning alltid halvhjärtad (instabil), och det kommer att vara möjligt att bygga in lite funktionalitet i den.
Vilka var våra uppgifter:
2) Vid uppdatering är interaktiv interaktion med användaren möjlig (meddelanden, bekräftelse, förloppsindikator).
Huvudfunktioner:
4) Kontrollera agenternas status
5) Uppdatera rapporter
6) backup
Så här ser till exempel felmeddelandet ut efter en uppdatering:
Därmed hade projektet goda chanser att slutföras framgångsrikt. Åtminstone halvvägs genom flygningen är flygningen normal.
Om vi kommer fram till några andra lösningar som kan tyckas intressanta kommer jag att skriva separat
P.S. och viktigast av allt: Korrekt planering av ytterligare stöd är en av nyckelfaktorerna för att sådana projekt ska bli framgångsrika. :)
25 oktober 2016
Det är ingen stor skillnad mellan att sätta upp och stödja RIB för 2 noder och för 10, men när antalet fjärrpunkter överstiger hundra måste helt andra problem lösas.
Så, de första uppgifterna:
Konfiguration: Detaljhandel 2.2
Plattform 1C: 8.3.7.1970
Uppskattat antal noder i slutet av projektet: 200
Utrustningsresurser i centrum: utan betydande restriktioner
Utrustning vid punkten: en diskuterad fråga.
Projektets varaktighet: ett år.
Arkitektur:
Först bestämde vi oss för RIB-schemat. Det beslutades att fokusera på "stjärnan"-schemat, tidigare
På återförsäljare används en klient-serverversion av arbetet, med en dedikerad server som kör Windows OS.
Server 1C kommer att användas i versionen "Server 1C MINI" https://1c.ru/news/info.jsp?id=17577
DBMS-server - MS SQL Express 2008 R2.
SQL Express 2008 R2 är den senaste versionen av denna SQL Server-linje.
Begränsningar:
2 GB RAM
- 1 fysisk processor
- 10 GB maximal databasstorlek
Av allt ovanstående är det mest irriterande naturligtvis begränsningen av den maximala databasstorleken. Men i själva verket betyder detta bara att det kommer att vara nödvändigt att noggrant organisera proceduren för att rengöra den från föråldrade data på plats.
En separat server är tilldelad för 1C och MS SQL server. Det kommer att bära den största bördan av utbyten och transaktioner.
Slutklientdatorerna ersätts inte, eftersom de kommer att fungera med en tunn klient och belastningen på botten blir minimal.
Servern i butiken är helt enkelt en kraftfull PC. Men en förutsättning är närvaron av en SSD-disk - på vilken MS SQL-databaserna finns.
Servern kommer också att ge möjlighet att utföra rutinoperationer på natten och tillgång till butikens databas utan avbrott från arbetet.
Grundinställningar
Sedan tiden för UT 10.3, då jag hade mitt första projekt med att implementera RIB i 60 knop, har naturligtvis "mycket vatten passerat under bron." 1C stod inte stilla. Retail 2.2 tar nu hänsyn till behovet av selektiv datauppladdning.
Endast information som är relevant för butiken kommer att laddas upp till butiksdatabasen:
- Alla kataloger (utom några)
- Dokument för den här butiken
Dataregistrering sker enligt registreringsregler, allt som kan cachas. Det finns inga betydande nedgångar under registreringen.
En annan fråga är att på ett eller annat sätt innebär att lägga till en nod i databasen att lägga till ytterligare en post för varje gemensamt element för alla databaser.
Det finns inget specifikt i att ställa in själva uppladdningen. Det finns några nyanser när du ställer in synkroniseringsscenarier:
1) Det är nödvändigt att separera uppladdning och laddning i separata synkroniseringsscenarier
Poängen är att lossningen tar lång tid och innebär blockering, men lastningen är ganska problemfri. Samtidigt händer det ofta att vi snabbt behöver ta emot data från butiker, samtidigt som vi bara ger bort det några gånger om dagen.
2) Identifiera problemlager och ta bort dem från det allmänna synkroniseringsscenariot. Det kan finnas stora lossningar på dem - detta kommer att sakta ner hela utbytet, inklusive andra noder
3) Skapa några skicka och ta emot skript för att skicka och ta emot data. Men det viktigaste här är balansen.
Vissa saker i 1C förändras inte. Samma "SelectChanges"-metod kan endast köras sekventiellt(sedan version 8.1).
Följaktligen är parallelliteten vid lossning av RIB begränsad. I praktiken slutar du med att du laddar upp 2-3 skript åt gången.
När det gäller mottagningsscenariot är mycket större parallellitet möjlig här, om nödvändigt, naturligtvis.
Vad behövde förbättras
Naturligtvis är det tråkigt och sorgligt, men jag var tvungen att ingripa ordentligt i BSP. Det viktigaste problemet i standard 1C-logiken är uppdateringar. Efter uppdateringen visas ett fönster som liknar detta:
Allt detta sker i monopolläge. Bland annat kommer systemet fortfarande att försöka göra ett utbyte efter uppdatering i exklusivt läge. Det är inte svårt att gissa vart allt detta leder.
Under hela den här tidsperioden kan butiken inte fungera, det finns kunder i kassan och företaget förlorar pengar.
Ett annat problem med utbyte är informationsregister. Genom att ladda upp varje informationsregisterpost i XML skapas en separat XML-nod med serviceelement och allt som följer. Dessutom, funktionen "välj ändringar" för ett informationsregister där det finns 100 poster, den resulterande tabellen kommer att innehålla 100 rader, samtidigt, om detta är en katalog med 100 rader, kommer endast en post att väljas i tabellsektion. Så om det finns många poster i PC:n som regelbundet registreras för utbyte till andra butiker, så är det naturligtvis mer korrekt att presentera detta i form av en katalog med en tabelldel, vilket i extrema fall vid inspelning , kan generera poster i samma register. I alla fall, informationsregister i utbyten är onda.
En annan viktig detalj - Rabattkort är helt uteslutna från bytet, och endast anställda i en specifik butik är uteslutna från bytet. För vad? Det finns redan närmare 3 miljoner rabattkort Ett externt onlinesystem används för att arbeta med dem. Om du fortsätter att överföra rabattkort till alla butiker kommer detta att öka byten flera gånger, dessutom kan det leda till att basen överstiger volymen på 3GB.
Några av mekanismerna implementeras online genom att kontakta den centrala databasen: saldon i andra butiker, returnera ett kvitto från en annan butik, kontrollera giltigheten av ett presentkort.
Replikering
Naturligtvis utförs replikering i snabbare takt.
Att skapa den initiala RIB-noden på ett standardsätt skulle naturligtvis göra replikering omöjlig.
Därför skapas en ny nod enligt följande:
1) Det finns en separat databas med en falsk butik
2) Denna databas utbyter all allmän data i RIB men tar inte emot specialiserad
3) När vi vill skapa en ny databas kopierar vi helt enkelt denna
4) Sedan ställer vi in inställningarna - butik, prefix osv.
5) Basen för butiken är klar.
Ett färdigt mjukvarupaket distribueras på servern, så det tar inte mycket tid. Sedan laddas den nyskapade databasen med butiker upp till servern och den är redo att skickas till butiken.
Fördelarna med en tunn klient
två betydande fördelar som "värmde själen."
1) Det finns ingen anledning att byta ut hela datorparken i butiker. 90 % av operationerna utförs på servern och servern förs dit med en "relativt kraftfull dator"
2) Utrustning har förmågan att vägra arbeta, detta händer särskilt ofta med nyinstallerad eller redan utsliten utrustning.
I det här fallet är åtgärderna nu extremt enkla - butiken går över till att arbeta i den centrala databasen.
Denna process tar inte mer än 5-10 minuter, så handeln avbryts inte även om det finns betydande problem med utrustningen.
Support och uppdateringar
Till slut nådde vi den mest intressanta punkten - hur underhåller och uppdaterar man allt detta?
För oss har uppdateringar också varit ett dilemma länge:
1) Uppdatera manuellt från butiker (inte särskilt korrekt, ändringar kanske inte tas emot, det kommer att bli samtal och problem)
2) Uppdatera med hjälp av teknisk support (det finns inte så många resurser)
3) Skriv *.cmd för uppdatering eller ta en färdig. Som praktiken visar är en sådan lösning alltid halvhjärtad (instabil), och det finns lite funktionalitet i den.
Vilka var våra uppgifter:
1) Uppdateringen ska ske i flera lägen och hanteras centralt
2) Vid uppdatering är interaktiv interaktion med användaren möjlig.
3) Rapporter om uppdateringsstatus och fel måste tas emot
4) Det måste finnas en backup
5) Uppdateringssystemet ska kunna uppdatera sig själv utan problem.
6) Systemet ska vara utbyggbart utan problem.
Naturligtvis gick problemen långt utöver listan över de som kunde lösas med enkla metoder. Eftersom vi inte kan klara oss utan automatisering med så många slutpunkter, och vi har inte hittat något mer eller mindre färdigt med liknande funktionalitet
Jag var tvungen att börja utveckla mjukvara, som så småningom fick namnet MU (MagicUpdater).
Huvudfunktioner:
1) Dynamisk databasuppdatering (kommando eller schemalagd)
2) Statisk databasuppdatering (kommando eller schemalagd)
3) automatiska agenter på slutdatorer när de modifieras
4) Kontrollera agenternas status
5) Uppdatera rapporter
6) backup
7) Administrativa åtgärder med 1C-server och MS SQL
8) Stänga alla 1C-klientapplikationer på nätverksdatorer
9) Statisk uppdatering med acceptans vid huvudkassan
10) Visar beskrivningar av ändringar efter uppdatering
11) Ställa in ordningen för åtgärder
12) Utför alla dessa åtgärder enligt ett schema
Ungefärliga interaktionsscheman:
Där MU Agent är en tjänst som installeras och konfigureras i butiken. Egentligen får hon ett kommando från centralen att utföra vissa uppgifter.
MU Server - Servern som tar emot alla förfrågningar till systemet.
MU-monitorn - vad vanliga tekniska supportanställda ser - används för att se loggar och ställa in uppgifter för uppdatering, eller andra.
Det blev ganska bra, enligt mig. Nu sker uppdateringar nästan automatiskt.
Så här ser till exempel felmeddelandet ut efter uppdateringen allt väntar fortfarande i centrum.
Och det är så här vi skickar kommandon till klientdatorer
Applikationerna är verkligen inte 1C, men med en ganska anständig uppsättning gränssnittsmöjligheter. Så här ser till exempel urval efter datum ut:
Nu är de redo för ytterligare replikering. Korrekt planering av ytterligare stöd är en av nyckelfaktorerna för att sådana projekt ska bli framgångsrika.
Instruktioner för att skapa och konfigurera distribuerade databaser med URDB (URIB)-komponenten
Komponenten URDB (Distributed Database Management) används för att utbyta information mellan två identiska 1C-databaser. Om konfigurationerna är olika kan du också använda den, detta skrivs i en annan. För att komponenten ska fungera måste du ha filen DistrDB.dll i BIN-mappen i 1C: Enterprise-programmet.
Låt oss titta på stegen för att skapa distribuerade databaser. Till exempel har vi en arbetsbas i katalogen D:\base1. Det krävs för att göra det centralt och skapa en perifer bas.
1. Skapa en katalog D:\base2 för den perifera databasen.
2. Skapa mapparna CP och PC i katalogerna D:\base1 och D:\base2 (använd latinska bokstäver).
3. Starta den centrala databaskonfiguratorn (D:\base1) och välj Meny - Administration - Distributed Information Security - Management.
4. Klicka på knappen "Central informationssäkerhet", i fönstret som visas, ange koden och namnet på databasen. Det är bättre att använda siffror eller latinska bokstäver för koden. Ange till exempel 001 och "Central bas", bekräfta genom att trycka på knappen "OK".
5. Klicka på knappen "Ny perifer informationssäkerhet" för att skapa en perifer databas. Vi anger parametrarna för det: 002 och "Perifer bas 1".
6. Använd markören för att välja "Peripheral Base 1"-basen och tryck på "Setup"-knappen. automatisk byte". I inställningarna ändrar du manuellt läge till automatiskt. Var försiktig, det här är viktigt.
7. Använd markören, välj databasen "Peripheral databas 1" och tryck på knappen "Ladda upp data" och sedan på knappen "OK". Som ett resultat av uppladdningen kommer filen D:\base1\CP\020.zip att visas.
8. Starta 1C i konfiguratorläge, lägg till en ny databas "Peripheral databas 1" i 1C-startfönstret, ange den tidigare skapade katalogen D:\base2 för den.
9. Välj Meny - Administration - Distribuerad informationssäkerhet - Hantering. På frågan som ställdes ”Informationsbasen hittades inte. Vill du ladda data?" Klicka på knappen "Ja" och ange filnamnet "D:\base1\CP\020.zip", klicka på knappen "OK". När nedladdningen är klar kan processen att skapa en perifer databas anses vara avslutad.
I och även i metoderna för att skapa en perifer databas genom att återställa en kopia av den centrala databasen från en säkerhetskopia eller bifoga filer av en kopia av den centrala databasen för SQL-format och exekvera skriptet. Detta kommer att vara användbart för stora datamängder, när uppladdningar och nedladdningar tar timmar eller är helt orealistiska.
Instruktioner för utbyte mellan distribuerade databaser med URDB (URIB)-komponenten
Låt oss överväga ett förenklat exempel vi kommer att utföra utbytet manuellt genom att starta konfiguratorn. Du kan använda konfiguratorns batchläge. Du kan använda e-post, ftp och automatisk filkopiering för att leverera utbytespaket.
För att utföra utbytet måste du välja Meny - Administration - Distribuerad informationssäkerhet - Autoutbyte. Om bytet är automatiskt (se punkt 6 i de tidigare instruktionerna), kommer allt att lösa sig.
1. Så vi ändrar eller skapar några objekt som migrerar till den perifera databasen. Objektmigreringsregler ställs in på fliken "Migration" i objektegenskaperna (se objektträdet i konfiguratorn).
2. Starta den centrala databaskonfiguratorn, välj Meny - Administration - Distribuerad informationssäkerhet - Autoutbyte, klicka på knappen "Kör".
3. Flytta den resulterande filen D:\base1\CP\020.zip till mappen D:\base2\CP\
4. Vi ändrar några objekt i den perifera databasen. Helst inte de som ändrats tidigare i den centrala databasen, eftersom den centrala databasen har prioritet för objektändringar under utbyte.
5. Starta den perifera databaskonfiguratorn, välj Meny - Administration - Distribuerad informationssäkerhet - Autoutbyte, klicka på knappen "Kör".
6. Som ett resultat av det automatiska utbytet bör vi ha ändringar som kommer från den centrala databasen. Vi bör också ha en fil att överföra till den centrala databasen D:\base2\PC\021.zip
7. Kopiera filen D:\base2\PC\021.zip till mappen D:\base1\PC
8. Upprepa punkt 2. Som ett resultat kommer ändringar som tas emot från den perifera databasen att visas i den centrala databasen.
Så, den allmänna principen för utbyte: alternativt körning av automatiskt utbyte med samtidig förflyttning av filer (utbytespaket) från PC-mappen i en databas till PC-mappen i en annan databas och från CP-mappen i en databas till CP-mappen på annan databas.
Konfigurationsändringar görs endast i den centrala databasen. När du ändrar konfigurationen är det nödvändigt att utföra utbytet i perifera databaser i exklusivt läge. För att framgångsrikt bearbeta paket från perifera databaser i den centrala databasen måste konfigurationen laddas in i de perifera databaserna. Om du blir förvirrad är det okej, paketet som avvisats av den centrala databasen kommer att laddas ner igen.
En situation uppstår ofta när en organisation har flera filialer eller butiker geografiskt avlägsna från varandra. Det finns dock fortfarande ett behov av att upprätthålla konsekventa register i hela organisationen. Ett av alternativen för att lösa detta problem är att skapa ett enhetligt nätverk, som kommer att inkludera automatiserade arbetsstationer för alla grenar, och vara värd för 1C-informationsbasen på en offentlig server. Denna metod kan vara tekniskt komplex och dyr. Dessutom uppstår en rad frågor som rör informationssäkerhet.
Det andra alternativet är att skapa en distribuerad informationsbas (RIB). En distribuerad informationsbas är en hierarkisk struktur som består av separata informationsbaser på plattformen 1C:Enterprise, mellan vilka datautbytet organiseras i syfte att synkronisera konfiguration och data. Dessa individuella informationsbaser kallas RIB-noder.
En distribuerad informationsbas kan skapas baserat på olika konfigurationer av 1C:Enterprise-systemet. Låt oss överväga dess skapelse med hjälp av exemplet med 1C: Trade Management 10.3.
Låt oss säga att en ytterligare butik öppnas i en handelsorganisation, där det är nödvändigt att ha tillgång till organisationens allmänna handelssystem. För att skapa en RIB måste du utföra följande steg:
Detta slutför skapandet av en distribuerad informationsbas. För att utbyta information måste du starta datautbyte i den centrala databasen (ändringar som har skett i den kommer att laddas ner), sedan i butiken (ändringar från den centrala databasen kommer att laddas ner och ändringar som har skett i butiken kommer att laddas ner ), och igen i den centrala databasen (ändringar kommer att laddas ner till den , inträffade i butiken).
Distribuerade informationsbaser har sin egen kollisionsupplösningsmekanism. Så om det under ett utbyte visar sig att något objekt (dokument, katalog, etc.) har ändrats i både huvud- och underordnade databaser, kommer ändringen som görs i huvuddatabasen att ha prioritet.
Om det är nödvändigt att ändra konfigurationen av en distribuerad infobas måste detta göras i rotnoden (se första figuren i artikeln), konfigurationerna för de återstående noderna är låsta. Efter att ha gjort de nödvändiga ändringarna kan de överföras till slavnoder med standardproceduren för utbyte av data mellan RIB-noder. Efter att utbytet har utförts i slavnodens konfigurator är det nödvändigt att uppdatera infobaskonfigurationen.
Om du har problem med att skapa en distribuerad informationsbas hjälper våra specialister dig att sätta upp datautbyte och förklarar i detalj hur du använder det.
Att skapa och konfigurera en distribuerad databas (RDB) i 1C 8.3 Redovisning (och andra konfigurationer) är nödvändigt i de fall där det inte är möjligt för flera användare att arbeta samtidigt som de ansluter till en databas. Nuförtiden är detta ganska sällsynt, eftersom det vanliga fjärrskrivbordet fungerar bra och det finns andra program som ger en fjärranslutning till den centrala datorn där databasen finns.
Men ändå finns det situationer när det helt enkelt inte finns något internet. Och uppgifterna ska i slutändan hamna i en informationsbas. Det är därför en distribuerad databas skapas.
Vanligtvis kallas huvudbasen central, och resten kallas perifer. Summan av kardemumman är att databaserna antingen manuellt eller automatiskt (beroende på inställningarna) kombineras till en. För att säkerställa att antalet nyinmatade dokument och katalogkoder inte dupliceras, tilldelas ett prefix till varje databas.
I den här instruktionen kommer vi att använda ett exempel för att skapa en central och perifer databas och kontrollera utbytet mellan dem. Denna manual är lämplig för både 1C 8.3 Accounting och 1C Trade Management (UT) och andra konfigurationer.
Låt oss gå till 1C "Administration"-menyn och klicka sedan på länken "Datasynkroniseringsinställningar". I fönstret som öppnas måste du markera kryssrutan "Datasynkronisering". Länken "Datasynkronisering" blir aktiv. Här ställer vi in ett prefix för huvudinformationsbasen - till exempel "CB":
Klicka på länken "Datasynkronisering" så öppnas ett fönster med knappen "Ställ in datasynkronisering". När du klickar på den här knappen öppnas en rullgardinslista där du måste välja läget "Fullständigt". Om synkronisering krävs för endast en organisation måste du välja "Efter organisation...".
I nästa fönster kommer programmet att uppmana oss att göra en säkerhetskopia. Jag rekommenderar starkt att du gör detta, eftersom följande installationssteg kan vara oåterkalleliga.
När du har skapat en säkerhetskopia klickar du på knappen "Nästa". I nästa steg måste vi bestämma hur synkronisering ska ske:
För enkelhetens och tydlighetens skull kommer vi att välja en lokal katalog. Jag angav följande sökväg: "D:\1C Databases\Synchronization". Det skulle vara en bra idé att kontrollera poster i den här katalogen, det finns en speciell knapp för detta:
Få 267 videolektioner på 1C gratis:
Vi hoppar över nästa steg med att ställa in synkronisering via FTP och e-post. Låt oss titta på inställningarna för namnen på huvud- och perifera databaser. Här kommer vi att ställa in prefixet för den perifera databasen:
Glöm inte att prefixen för varje databas måste vara unika. Annars kommer du att få felet "Prefixvärdet för den första infobasen är inte unikt."
Klicka på "Nästa", kontrollera den angivna informationen och klicka på "Nästa" igen, sedan på "Slutför". I fältet "Fullständigt namn på filbasen" anger du filen 1Cv8.1CD i katalogen som skapades för synkronisering. Vi skapar den första bilden av den distribuerade 1C-databasen:
Efter att ha skapat den första bilden av RIB i 1C kan du ställa in ett synkroniseringsschema eller synkronisera manuellt:
Efter synkroniseringen kan du ansluta till den nya databasen och se till att information från den centrala databasen har laddats upp dit:
Skapa bara omedelbart minst en användare med administratörsrättigheter i den nya kringutrustningsdatabasen.
I 1C kringutrustningsdatabasen är installationen mycket enklare. Markera bara kryssrutan "Datasynkronisering" och följ länken med samma namn. Och vi befinner oss nästan omedelbart i ett fönster med knappen "Synkronisera". Låt oss försöka skapa ett testobjekt i den perifera databasen och ladda upp det till huvudet med RIB:
För att skapa en distribuerad informationsbas måste du gå in i programmet i 1C: Enterprise-läge. För att skapa distribuerade databasnoder, välj från menyn: Operations - Exchange plans. Fönstret "Välj objekt: Utbytesplan" öppnas.
1. Överväg alternativet med "Fullständig" utbytesplan.
Utbytet kommer att genomföras mellan alla organisationer som finns i den distribuerade informationsbasen.
Låt oss välja den "fullständiga" utbytesplanen. Fönstret "Fullständig utbytesplan" öppnas.
Vi fyller i två poster:
Låt oss kalla den första posten "Huvudnod", ange koden "GU",
Låt oss kalla den andra posten "Underordnad nod", ange koden "PU".
Som vi kan se från figuren har den första posten en ikon med en grön cirkel, detta är ikonen "Huvudnoden".
För att skapa en kopia av informationsbasen "Huvudnod", klicka på "Slavnod" och klicka på ikonen "Skapa initial bild". Detta kommer att vara informationsbasen "Underställd nod".
Fönstret "Skapa en första informationssäkerhetsbild" öppnas, välj "På den här datorn eller på en dator i det lokala nätverket", klicka på "Nästa".
I fältet "Infobase Directory" väljer du platsen där kopian av "Main Node" ska installeras och klickar på "Slutför".
Efter att ha skapat informationsbasen "Underordnad nod" kommer följande meddelande att visas:
Klicka på "Ok".
Lägg till informationsbasen "Underordnad nod" till "1C: Enterprise". Vi går till den underordnade databasen i läget "1C: Enterprise". Låt oss öppna: Operations - Exchange Plans. Fönstret "Välj objekt: Utbytesplan" öppnas. Låt oss välja den "fullständiga" utbytesplanen. Fönstret "Fullständig utbytesplan" öppnas. Vi ser att ikonen "Huvudnod" är orange, vilket betyder att denna nod är huvudnoden för den informationsbas vi befinner oss i.
Vi gör följande inställningar i både master- och slavnoderna:
1.
Lägg till ett prefix för den distribuerade infobasen.
Detta görs för att det inte ska uppstå konflikter i nummer och koder för dokument och kataloger skapade i två databaser, så i varje databas anger vi ett prefix som kommer att läggas till dokumentnumren och katalogkoderna. Öppna: Verktyg - Programinställningar - Fliken "Datautbyte". I fältet "Nodprefix för en distribuerad infobas:" anger du "PU" i den underordnade databasen och "GU" i huvuddatabasen.
2.
Lägg till en inställning för datautbyte mellan noder:
Öppna: Service - Distributed Information Base (DIB) - Konfigurera RIB-noder. Fönstret "Inställningar för datautbyte" öppnas.
Klicka på "Lägg till" och fönstret "Inställningar för datautbyte" öppnas. Ange "Namn" för din inställning.
En nod kommer automatiskt att dyka upp i fältet "Node", för "Masternod" kommer det att finnas en "Slavnod", för en "Slavnod" kommer det att finnas en "Masternod".
I fältet "Katalog" väljer du mappen till vilken utbytesdata ska skickas. Det är bäst att ange en katalog för huvud- och slavdatabaserna.
I fältet "Exchange Type" konfigurerar vi överföringen av data mellan databaser: via en fil eller FTP-resurs. Låt oss välja, till exempel, "dela genom en filresurs."
Vi ändrar ingenting i de återstående fälten.
Klicka på "Ok". Vi ser att en inställning har dykt upp.
3.
För att utbyta data gör vi följande:
Först, i databasen där ändringarna gjordes, klicka på ikonen "Byt enligt aktuell inställning", som visas i bilden.
Efter uppladdningen visas uppladdningsresultatfönstret.
Sedan, i databasen som du vill överföra ändringarna till, klicka på ikonen "Byt enligt aktuell inställning" och data kommer att gå till den databas du vill ha.
2. Överväg alternativet med utbytesplanen "Efter organisation".
Utbytet kommer att genomföras bland utvalda organisationer placerade i en distribuerad informationsbas.
För att skapa noder för en distribuerad databas, välj från menyn: Operations - Exchange plans. Fönstret "Välj objekt: Utbytesplan" öppnas.
Låt oss välja utbytesplanen "Efter organisation". Fönstret "Utbytesplan efter organisation" öppnas.
Vi fyller i två poster:
Låt oss kalla den första posten "Huvudnod", ange koden "GU", vi ser skillnaden från "Utbytesplanen: Full", en tabell har dykt upp där vi anger de organisationer för vilka utbytet kommer att äga rum.
Låt oss kalla den andra posten "Underordnad nod", ange koden "PU", ange organisationen.
I alla andra avseenden är upplägget absolut detsamma som med "Exchange Plan: Full".
