Verteilte Informationsbasis: Grundlagen. Erstellen einer RDB von Grund auf Programmatische Ausführung des Datenaustauschs Rib 1s 8.3

Dies ist mein erster Artikel, konstruktive Kritik ist willkommen.

Die Zielgruppe sind diejenigen, die zum ersten Mal mit RBD in Berührung kommen.

RDB-Aufgaben

Als Erstes müssen Sie die Frage beantworten: „Warum brauchen wir eine RDB?“ Es gibt viele mögliche Antworten, insbesondere:

Wir haben Zweige, die in getrennten Datenbanken ausgeführt werden. Jetzt möchten wir, dass die Informationen zwischen ihnen synchronisiert werden.
Wir haben Filialen, aber die Belastung der Datenbank ist zu hoch (das bedeutet Transaktionsblockierung, nicht das Volumen der Datenbank) und die Online-Relevanz (nicht zu verwechseln mit Relevanz in wenigen Minuten, online ist, wenn nach jeder Transaktion die Daten verfügbar sind). an den zweiten Knoten übertragen) werden keine Daten für Zweige benötigt;
Wir haben Filialen, in denen nur die Dateneingabe erfolgt (z. B. Einzelhandelsgeschäfte), sodass wir die Belastung der zentralen Datenbank erheblich reduzieren können;
Aus Sicherheitsgründen möchten wir, dass die Filialen auch theoretisch (mit Admin-Passwort) keinen Zugriff auf wichtige Daten, wie beispielsweise die Bilanz des Unternehmens, haben.

In einem Fall waren die Fragen 2 und 4 für mich relevant, in einem anderen Fall 2 und 3. Der erste Punkt ist zu umfangreich und wird im Rahmen dieses Artikels nicht berücksichtigt.

Es ist auch besser, sich sofort mit dem Problem des Transports von Austauschdateien zu befassen, da dies in einigen Fällen zu erheblichen Einschränkungen bei der Durchführung des Datenaustauschs führen kann. Zunächst müssen Sie bestimmen, in welchen Zweigen genau die RDB-Knoten angezeigt werden (normalerweise handelt es sich dabei um regionale Zweige). Als nächstes überlegen wir, wo wir sonst noch RDB-Knoten installieren möchten und ob sie Online-Relevanz benötigen. Beispielsweise ist es in Einzelhandelsgeschäften nicht immer möglich, auch nur ein Modem zu installieren, und die Installation einer drahtlosen Verbindung wäre zu teuer. Hier müssen Sie eine Entscheidung treffen – vielleicht kann dieser Laden offline betrieben werden und über ein physisches Medium, beispielsweise ein Flash-Laufwerk, regelmäßig (einmal am Tag/einmal in der Woche) mit dem Zentrum austauschen.

In einigen Fällen ist der Austausch über physische Medien nicht möglich, beispielsweise handelt es sich um eine sehr abgelegene Zweigstelle, in der es erhebliche Probleme beim Aufbau einer Hgibt. Hier lohnt es sich, die Menge der ausgetauschten Informationen grob zu berechnen. Wenn es einmal pro Stunde oder mehrmals am Tag relevant ist, reicht oft ein 32k-Modem aus. Beachten Sie jedoch, dass Sie neben Datenaktualisierungen manchmal auch Aktualisierungen an die Konfiguration selbst oder an externe Dateien (gedruckte Formulare, Warenfotos) senden müssen, sodass es von Zeit zu Zeit zu einer Situation kommen kann, in der die Austauschdatei erheblich zunimmt zu solchen Updates.

Topologie

Insgesamt erreichten uns folgende Fragen, die es zu beantworten gilt:

In welchen Abteilungen installieren wir garantiert RDB-Knoten und ist es möglich, dort einen Hochgeschwindigkeitskanal zu installieren?
In welchen Abteilungen ist die Installation einer RBD-Einheit nicht erforderlich?
Welche Abteilungen können in mehreren Stunden relevant arbeiten?
Welche Abteilungen können offline arbeiten (Datenaustausch weniger als 3-4 Mal am Tag).

Nachdem wir diese Fragen beantwortet haben, erhalten wir ein ungefähres Diagramm unserer RDB. Bei großen Unternehmen sieht es in der Regel so aus:

Abb. 1. Typisches Diagramm der RDB eines großen Unternehmens

Wenn bei den „Branch“-Knoten alles relativ klar ist – das sind große Zentren, die Automatisierung erfordern, dann bedeuten die „Store“-Knoten einen Knoten mit einer starken Belastung der Datenbank bei der Dateneingabe, der zur Reduzierung der Belastung getrennt werden sollte. Zum Beispiel ein Markt mit 50 Kassen und einem Tagesumsatz von mehr als 10.000 Einheiten.

Filialen – Geben Sie Daten zu Ihrem eigenen Umsatz und Cashflow ein. Die Analysen sind oberflächlich, nur für Ihren eigenen Shop.
Branchen – Dateneingabe von nicht automatisierten Punkten, Buchhaltung, Gehälter und Personal, Produktion usw. Analytics innerhalb Ihrer eigenen Branche.
Zentrum - Dateneingabe nicht automatisierter Filialen. Analyse des gesamten Unternehmens.

Es ist wichtig zu verstehen, für welche Zwecke die Datenbank in jedem Knoten verwendet wird. Aus den Zielen werden die zur Umsetzung notwendigen Aufgaben aufgebaut, zum Beispiel:

Zweigstellen sehen die Geschichte der gegenseitigen Abrechnungen mit den Gegenparteien des jeweils anderen;
Geschäfte sehen übrig gebliebene Waren im gesamten Unternehmen (oder in Teilen davon);
Analysen zu Einnahmen/Ausgaben, Budgetausführung usw. sind nur innerhalb der Hierarchie Ihrer eigenen Abteilung sichtbar;
Buchhaltung, Lohn- und Gehaltsabrechnung und Personal sind nur innerhalb der Hierarchie Ihrer eigenen Abteilung sichtbar;
Die Nomenklatur, alle ihre Eigenschaften und Merkmale sind in allen Knoten der RDB sichtbar;
Bezogen auf die Abteilungshierarchie fließen alle Daten nach oben, werden aber nach unten gefiltert;
Das Zentrum enthält absolut alle Informationen über das Unternehmen.

Indem Sie sich solche Fragen stellen, können Sie die schwierigste Frage beantworten: Welche Informationen sollen wo und wie zwischen RDB-Knoten fließen? Warum das Schwierigste? Wenn Sie wissen, welche Datensätze zwischen Knoten zirkulieren, können Sie klar verstehen, wie Sie die aktuelle Datenbank „ausschneiden“, damit die Daten logisch konsistent bleiben. Beispielsweise können Daten zu Warenbilanzen nicht von Daten zu aktuellen Reserven getrennt werden.

Lassen Sie uns nun abhängig von den Informationsflüssen das RDB-Diagramm neu zeichnen:

Was sehen wir in Abbildung 2? Entsprechend der Hierarchie der Unternehmensbereiche wurde eine Topologie des Informationsflusses zwischen den Datenbankknoten aufgebaut. Der Knoten „Center 2“ wurde ebenfalls hinzugefügt, warum? Bei der Implementierung der Sterntopologie ist die Belastung des Zentrums immer höher als die Belastung der peripheren Knoten, und oft ist die vom Knoten selbst erzeugte Belastung bereits hoch. Beispiele für die Verwendung der Knoten „Center 1“ und „Center 2“:

„Center 1“ dient lediglich der Konsolidierung von Daten anderer RDB-Knoten. Nur der Administrator hat Zugriff darauf. „Center 2“ dient der Arbeit der Zentrale;
„Center 1“ dient der Arbeit der Zentrale. Im Knoten „Center 2“ werden jedoch umfangreiche Analyse- und Testvorgänge durchgeführt, die eine enorme Belastung für die Datenbank darstellen. zum Beispiel die Reihenfolge wiederherstellen, geschlossene Zeiträume neu planen, zusammenfassende Berichte für das gesamte Unternehmen über einen langen Zeitraum erstellen, Analysen erstellen, die zu Datenänderungen führen;
„Center 1“ dient der Arbeit der Zentrale. „Center 2“ ist ein Backup für unvorhergesehene Situationen zur schnellen Wiederherstellung der gesamten RDB.

Umsetzung des Austausches

Für den RDB-Betrieb gibt es zwei Möglichkeiten:

Automatisch – erfolgt ohne Benutzereingriff. Die Kontrolle über Notfallsituationen wird entweder dem Datenbankadministrator oder einem fortgeschrittenen Benutzer zugewiesen;
Manuell – der Austausch erfolgt nur auf Wunsch des Benutzers.

Meiner Erfahrung nach habe ich bei allen Implementierungen immer auf die automatische Variante umgestellt. Wenn es Probleme mit dem Transport von Austauschdateien gab (das Vorhandensein eines Netzwerks im Knoten ist nicht konstant), konnte der Benutzer höchstens auf die Schaltfläche „Jetzt austauschen“ klicken. In Situationen, in denen neben der Datenaktualisierung auch eine Konfigurationsaktualisierung erfolgt, empfiehlt es sich, diese ebenfalls vollautomatisch durchzuführen (z. B. mithilfe von Software von Drittanbietern).

Generieren von Update-Paketen

Da es eine eindeutige Entscheidung darüber gibt, welchen RDB-Knoten welche Funktionen zugewiesen werden, ist es möglich, nur das Datenpaket zu generieren, das dieser Knoten benötigt. Einerseits muss angegeben werden, welche Objekttypen zwischen Knoten synchronisiert werden sollen. Beispielsweise sollten die Abrechnungsregister für den Knoten „Store 1“ überhaupt nicht synchronisiert werden, weil Daten werden nur auf der Ebene des Zweigknotens eingegeben. Andererseits müssen diejenigen Arten von Daten, die einem Austausch unterliegen, abteilungsbezogen gefiltert werden. Beispielsweise können Daten zum Geldeingang vom Knoten „Filiale 1 Filiale 2“ nur in den Knoten „Filiale 2“, „Center 1“ und „Center 2“ gefunden werden.

Allerdings gibt es auch das gegenteilige Problem: Filtert man die Austauschdaten zu stark, verliert das Datenpaket seine logische Integrität. Beispielsweise werden die Warenbestände im Zusammenhang mit Lagern und die Reserven im Kontext des Unternehmens als Ganzes berücksichtigt. Wenn Sie dann die Warenbestände nach Lagern filtern und die Reserven nicht filtern, werden die Die Daten werden falsch sein.

Sie sollten auch entscheiden, in welchem Lebensabschnitt das Objekt ausgetauscht werden soll. Beispielsweise können nur gebuchte Rechnungen ausgetauscht werden, nicht jedoch einfach gespeicherte. Store-Rechnungen werden auch nach der Anpassung nie vom Center-Knoten entladen, es muss jedoch der gegenteilige Effekt berücksichtigt werden – die Daten sind möglicherweise nicht synchron oder einige Änderungen werden möglicherweise überschrieben.

Es ist wichtig zu verstehen, dass beim Austausch zwischen Knoten einer von ihnen Vorrang hat. Betrachten Sie die Situation:

Im Knoten „Shop 1“ wurde ein Dokument erstellt;
Während des Austauschs landete er im Knoten „Branch 1“;
Das Dokument wird in beiden Knoten gleichzeitig korrigiert.

Welches Dokument gilt als wahr? In 1C 8.x ist bei Verwendung des Mechanismus „Exchange Plans“ die Standardpriorität der Hauptknoten, d. h. In diesem Fall gehen die im Knoten „Store 1“ vorgenommenen Änderungen verloren und werden durch Daten vom Knoten „Branch 1“ ersetzt.

Eine weitere, komplexere Situation entsteht, wenn zwei verbundene Objekte gleichzeitig angepasst werden. Beispielsweise werden die Rechnung und der PQR dafür in verschiedenen Knoten angepasst; es besteht die Möglichkeit eines Integritätsverlusts, wenn Preise, Zahlungsbeträge, Kontrahenten usw. geändert werden.

Wichtig ist auch, das Löschen von Objekten zu kontrollieren, da dies sonst dazu führen kann, dass beispielsweise eine Rechnung nicht mehr existiert, Buchhaltungsbewegungen aber bestehen bleiben.

Austauschmechanismen in 1C 8.x

Für die Umsetzung gibt es zwei Ansätze:

„Exchange Plans“-Mechanismus;
Eigene Implementierung der Objektregistrierung.

Betrachten wir beide Optionen.

Der Mechanismus der Austauschpläne ermöglicht es, ohne jegliche Konfiguration in wenigen Minuten eine Datenbank mit vollständigem Datenaustausch zu erstellen. Wenn Sie das Flag „Verteilte Infobase“ setzen, werden beim Erstellen eines Update-Pakets auch Konfigurationsupdates heruntergeladen. In nur wenigen Minuten können Sie Regeln zum Zulassen/Verbieten des Austauschs verschiedener Datentypen festlegen, indem Sie die Zusammensetzung des Austauschplans öffnen. Wenn Sie das Flag „Auto-Registrierung“ auf die Position „Verweigern“ setzen, wird ein solcher Objekttyp niemals ohne zusätzlichen Aufwand ausgetauscht.

Warum ist eine Registrierung erforderlich, warum nicht alles auf einmal hochladen? In jedem Fall ist eine Datei, die nur Änderungen am Datenbankstatus enthält, kleiner als ein vollständiger Snapshot der Datenbank selbst. Daher wird die Möglichkeit einer vollständigen Entladung nicht in Betracht gezogen.

Wie richte ich die Datenfilterung nach Abteilungszugehörigkeit ein? Hier müssen Sie bereits programmieren. In meiner Implementierung wurde für die Aufzeichnung eines beliebigen Objekts ein Abonnement für das Ereignis „Beim Schreiben“ installiert, wobei Sie mithilfe der Eigenschaft „Datenaustausch“ die Liste der Empfänger dieses Objekts festlegen können. Diese. Beim Entladen mit Standardmitteln für einen Knoten, der nicht in der Liste enthalten ist, wird das Objekt nicht entladen. Es gibt eine andere Lösung: Sie können in den Verfahren „Beim Senden von Daten an einen Untergebenen“ und „Beim Senden von Daten an einen Master“ des Austauschplanmoduls auswählen, ob ein Objekt direkt beim Entladen des Objekts entladen werden soll.

Beide Optionen haben ihre Daseinsberechtigung. Allerdings habe ich die erste Option als die beste Option gewählt, da die Berechnung des Vorladefähigkeitsattributs sofort beim Schreiben des Objekts erfolgt, was die Dauer der Objektaufzeichnung um 3-5 % erhöht (kann optimiert werden, in manchen Fällen auch). auf 0,01 % reduziert werden, d. h. im Durchschnitt 0,1-0,3 Sekunden, und wenn die Entladebarkeit eines Objekts direkt beim Senden von Daten berechnet wird, was bereits eine erhebliche Belastung der Datenbank darstellt, beträgt diese Zeit bis zu mehrere Minuten.

Um die Funktionsweise des Mechanismus „Exchange Plans“ vollständig zu verstehen, empfehle ich die Lektüre von Kapitel 15 des Buches „Berufliche Entwicklung im 1C:Enterprise 8-System“, Gabets A.P., Goncharov D.I.

Meiner Meinung nach wird jede eigene Implementierung entweder den „Exchange Plans“-Mechanismus wiederholen oder das Objekt bei Änderungen sofort entladen oder mehr als den „Exchange Plans“-Mechanismus entladen (z. B. alle Änderungen für heute entladen). Aufgrund mangelnder Implementierungserfahrung ziehe ich dieses Problem nicht in Betracht.

Transport

Die Aufgabe, Dateien vom Master- zum Slave-Knoten zu transportieren, wird auf maximale Fehlertoleranz reduziert. Es ist nicht ungewöhnlich, dass Dateien verschlüsselt oder über einen sicheren Kanal übertragen werden. Um Dateien zu übertragen, empfiehlt es sich, mehrere unterschiedliche Dienste zu nutzen oder mehrere unterschiedliche Verbindungsoptionen vorzubereiten. Die Hauptübertragungsmethode ist beispielsweise die Verwendung eines FTP-Servers, der über einen VPN-Tunnel verbunden ist; Der Backup-Server ist ein E-Mail-Server mit einer TLS-Verbindung. Warum benötigen Sie einen Backup-Kanal mit einem anderen Dienst? Wie die Praxis zeigt, ist die Verwendung von zwei verschiedenen FTP-Servern weniger zuverlässig als ein FTP-Server und E-Mail.

Ich empfehle, den Aktualisierungspaket-Erstellungsdienst vom Transportdienst zu trennen, da dies die Fehlertoleranz des gesamten Datenaustauschkomplexes erhöht. Wenn der Dateitransportdienst nicht funktioniert, funktioniert der Dienst zum Erstellen von Update-Paketen normal weiter und startet unter bestimmten Bedingungen den Transportdienst neu und umgekehrt.

Meine RDB-Implementierung

Die Umsetzung erfolgt völlig autonom, daher fungierte als Teilaufgabe maximale Fehlertoleranz. Daraus entstanden zwei Dienste – der Update-Transportdienst und der Datenimport-/Exportdienst. Beide Dienste arbeiten unabhängig voneinander.

Nach jedem erfolgreichen Datenimport-Export-Zyklus wurde der Zeitpunkt des letzten Austauschs mit diesem Knoten gespeichert. Wenn der Austausch sehr lange nicht stattfand, begann der Transportdienst, Dateien auf alle ihm zur Verfügung stehenden Kommunikationskanäle hochzuladen, in der Erwartung, dass der zweite Knoten weiterhin Updates erhalten und seine Dateien hochladen würde. In Ausnahmesituationen sendet das System selbst eine Meldung mit einer detaillierten Fehlerbeschreibung an den Administrator.

Um den Datenverkehr zu reduzieren, wurden XML-Dateien in Zip-Archive gepackt. Das System unterstützt zwei Transportarten: FTP und E-Mail.

Es gibt zwei Tabellen als Einstellungen für den Datenfilter. Einer (der tabellarische Teil von Austauschplänen) speichert Bedingungen für allgemeine Details (für jedes Objekt versucht das System, dieses Detail zu finden), der andere enthält Einstellungen für ein bestimmtes Metadatenobjekt. Bei der Erfassung eines beliebigen Objekts werden Bedingungen zunächst anhand allgemeiner Details (z. B. Abteilung) gesucht. Anschließend versucht das System anhand aller Details festzustellen, ob für diesen Objekttyp eine persönliche Regel vorliegt. Ich empfehle nicht, die Listen zu filtern – die Wahrscheinlichkeit eines Fehlers ist hoch, z. B. verschwinden mehrere Zeilen aus dem tabellarischen Teil der Rechnung und der Restbetrag wird verschoben und umgekehrt.

Es ist wichtig zu verstehen, unter welchem Systembenutzer die Dienste ausgeführt werden, denn Möglicherweise verfügen Sie nicht über ausreichende Rechte, um Dateien zu erstellen, selbst im temporären 1C-Ordner. Zum Debuggen empfehle ich dringend, jeden erfolgreich abgeschlossenen Vorgang in das Registrierungsprotokoll oder in eine TXT-Datei zu schreiben. In 1C 8.1 kann die Ausführung von Servercode nicht debuggt werden.

Um das Debuggen und Einrichten meiner Implementierung zu vereinfachen, füge ich die Verarbeitung „Registrierung von Änderungen“ bei, deren Beschreibung in der Verarbeitung selbst enthalten ist.

Das allgemeine Betriebsdiagramm des Datenaustauschkomplexes ist in Abb. 3 dargestellt.

Die Datenfilterung erfolgt in einem Abonnement für das Ereignis „BeforeRecording“ jedes Objekts. Vergessen Sie nicht, dass beim Erstellen des anfänglichen Knotenbilds auch die Daten gefiltert werden müssen. Das Verfahren zum Erstellen eines ersten Bildes ist ziemlich langwierig, daher empfehle ich, den Code maximal zu optimieren (z. B. Filtereinstellungen zwischenzuspeichern).

Nachwort

Die Hauptaufgabe besteht darin, eine Liste von Fragen zu beantworten:

Warum brauchen wir RDB?
Was könnte Ihnen an der Arbeit mit einem RDP-Client nicht gefallen?
Wo und warum wollen wir RDB-Knoten installieren?
Wie werden die Updates transportiert?
Welches Maß an Fehlertoleranz wird implementiert?

Abwicklung „Anmeldung von Änderungen“

Durch die Verarbeitung können Sie die Registrierung von Änderungen an Objekten erzwingen. Es gibt mehrere Möglichkeiten, Änderungen zu protokollieren:

Wenn Metadaten überprüft werden und keine Objekte ausgewählt sind und das Flag „Nach allen Werten laden“ NICHT gesetzt ist, wird NUR DIE AUSGEWÄHLTE TABELLE REGISTRIERT;
Wenn das Flag „Für alle Werte hochladen“ gesetzt ist, werden die ausgewählten Metadaten für alle Objekte im Zyklus entladen;
Wenn der Schalter auf den Modus „Nur ausgewählte Objekte hochladen“ eingestellt ist, werden nur ausgewählte Objekte entladen (Beispiel: Das Setzen eines Flags für Metadaten ohne Auswahl von Objekten entspricht dem Aktivieren des Flags „Nach allen Werten hochladen“ und des Schalters in der Position „Nur ausgewählte Objekte entladen“;
Wenn der Schalter auf den Modus „Ausgewählte und direkt verwandte Objekte entladen“ eingestellt ist, werden die ausgewählten Objekte und diejenigen Objekte, deren Existenz von der Existenz des ausgewählten Objekts abhängt, entladen (z. B. für Verzeichnisse – untergeordnete Verzeichnisse);
Wenn der Schalter auf den Modus „Hochladen über alle Links“ eingestellt ist, werden ALLE Objekte entladen, die einen Link zum ausgewählten Objekt enthalten.

Zusätzliche Funktionalität verfügbar:

Zum Debuggen ist häufig eine erneute Registrierung registrierter Objekte erforderlich.
Das Entfernen registrierter Dateien ist häufig zum Debuggen erforderlich.
Änderungen drucken – eine vollständige Liste der Objekte drucken, die als geändert markiert sind;
Das Drucken des Konfigurationsbaums dient lediglich der bequemen Anzeige der gesamten Konfiguration.

Dieses Material enthält detaillierte Anweisungen zum Einrichten des RIB-Austauschs für 1C:Enterprise 8 und die Probleme, auf die der Autor gestoßen ist.

1. Knoten erstellen
Wir erstellen neue Knoten (Master und Slave): im Benutzermodus „Operations / Exchange Plans / Full“
Wählen wir den Umtauschplan „Voll“
Wir erstellen zwei Datensätze:
- Nennen wir den ersten Datensatz „CB“ (Hauptknoten), geben Sie den Code „CB“ an,
- Nennen wir den zweiten Eintrag „Untergeordneter Knoten“ und geben Sie den Code „PU“ an.
Symbol mit grünem Kreis – „CB“ (Hauptknoten)

Klicken Sie für den Slave-Knoten auf das Symbol „Startbild erstellen“. (Erfordert exklusiven Zugriff)
Erstellen Sie ein Startbild
Geben Sie als Nächstes im sich öffnenden Fenster die Parameter der neuen Datenbank ein. Wenn Sie fertig sind, klicken Sie auf die Schaltfläche „Fertig stellen“.
Erstellen eines ersten Informationssicherheitsimages
Die Erstellung des Anfangsbildes des Slave-Knotens der verteilten Infobase beginnt und nach Abschluss erscheint die Meldung „Erstellung des Anfangsbildes wurde erfolgreich abgeschlossen“. Klicken Sie auf die Schaltfläche „OK“.
Wir fügen die Basis des Slave-Knotens zur Liste der Basen hinzu und starten sie.
In dieser untergeordneten Datenbank öffnen wir den vollständigen Austauschplan – das „CB“-Symbol ist rot, das bedeutet, dass dieser Knoten der Hauptknoten für die Informationsbasis ist, in der wir uns befinden.

2. Präfixe einrichten
Für jede Datenbank legen wir in den Einstellungen der Abrechnungsparameter (im UPP „Service / Abrechnungsparameter“) auf der Registerkarte „Datenaustausch“ Präfixe fest. Dies geschieht, damit es zu keinen Konflikten bei den Nummern und Codes von Dokumenten und Verzeichnissen kommt, die in zwei Datenbanken erstellt wurden.
Für den automatischen Austausch aktivieren Sie das Kontrollkästchen „Automatischen Austauschmechanismus verwenden …“
Reiter „Datenaustausch“

3. Fügen Sie eine Einstellung für den Datenaustausch zwischen Knoten hinzu
Öffnen Sie: „Service\Distributed Information Base (RIB)\Configure RIB nodes“
Klicken Sie auf „Hinzufügen“ und das Fenster „Datenaustauscheinstellungen“ öffnet sich.
Datenaustausch einrichten

Klicken Sie auf das Symbol „Austausch gemäß aktuellen Einstellungen“.
Führen Sie den Austausch gemäß der aktuellen Einstellung durch

Nun zu den Fallstricken
1. Der Datenaustausch kann automatisiert erfolgen und in folgenden Fällen initiiert werden:
* Beim Starten des Programms. Der Austausch wird beim Programmstart durchgeführt,
* Wenn Sie mit der Arbeit mit dem Programm fertig sind. Der Austausch wird durchgeführt, bevor der Benutzer die Arbeit mit dem Programm beendet.
* Wenn der Katalog erscheint. Der Austausch wird nur durchgeführt, wenn das vom Benutzer angegebene Verzeichnis unsichtbar war, jetzt aber sichtbar geworden ist. Die Einstellung kann verwendet werden, um einen automatischen Austausch durchzuführen, wenn eine Verbindung zu einem lokalen Netzwerk oder einer Flash-Karte besteht. Das Programm überprüft regelmäßig die Sichtbarkeit des in den Einstellungen angegebenen Verzeichnisses und notiert seinen aktuellen Status.
* Wenn die Datei erscheint. Es wird empfohlen, den Datenmodus zu verwenden, wenn Sie einen Datenaustausch durchführen müssen, wenn eine eingehende Datenaustauschdatei angezeigt wird. In diesem Fall reicht es aus, den vollständigen Pfad zur eingehenden Datenaustauschdatei anzugeben. Das Programm analysiert regelmäßig das Vorhandensein der Datei, und sobald sie erscheint, wird der Austausch durchgeführt, und nach dem Austausch wird diese Datei zwangsweise GELÖSCHT (dies geschieht, damit der Austauschvorgang nicht ständig durchgeführt wird).
* Periodischer Datenaustausch. Der Austausch erfolgt entsprechend den Einstellungen für den periodischen Datenaustausch. Wenn die Infobase im Dateiservermodus arbeitet, erfolgt der periodische Austausch nur für den Benutzer, der in den Einstellungen der Abrechnungsrichtlinie als „Benutzer für Routineaufgaben im Dateimodus“ angegeben ist. In der Client-Server-Version erfolgt der Austausch auf dem 1C:Enterprise-Server.

Ich habe eine Client-Server-Option – damit der routinemäßige automatische Austausch funktioniert, musste ich den Server überlasten

2. Windows-Kodierung.
Der Austausch wurde durch einen Fehler unterbrochen, da die Datei nicht komprimiert war. Dies liegt an einem kyrillischen Fehler in der Befehlszeile während der Komprimierung.
Es kann durch eine Korrektur der Kodierungen in der Registrierung behoben werden.
Zum Beispiel für Windows Server 2008 –
Code

REGEDIT4
"1250"="c_1251.nls"
"1251"="c_1251.nls"
"1252"="c_1251.nls"
"1253"="c_1251.nls"
"1254"="c_1251.nls"
"1255"="c_1251.nls"

3. Beim Erstellen einer Kopie der Datenbank (z. B. zur Änderung) in der Client-Server-Version ist es NOTWENDIG, dass die ROUTINEAUFGABEN DER KOPIE DER DATENBANK AUSGESCHALTET sind. Blockieren von Routineaufgaben für Kopieren EIN

Wenn sie nicht blockiert sind, erfolgt der Austausch der Kopie nach demselben Zeitplan wie die Hauptdatenbank. Dies bedeutet, dass einige Nachrichten an Remote-Knoten aus der Arbeitsdatenbank und andere aus einer Kopie generiert werden, was zu einer Desynchronisierung der Konfigurationen führt.

Das Erstellen und Konfigurieren einer verteilten Datenbank (RDB) in 1C 8.3 Accounting (und anderen Konfigurationen) ist in Fällen erforderlich, in denen es nicht möglich ist, dass mehrere Benutzer arbeiten und gleichzeitig eine Verbindung zu einer Datenbank herstellen. Heutzutage kommt dies eher selten vor, da der Standard-Remote-Desktop einwandfrei funktioniert und es andere Programme gibt, die eine Remote-Verbindung zum zentralen Computer bereitstellen, auf dem sich die Datenbank befindet.

Dennoch gibt es Situationen, in denen es einfach kein Internet gibt. Und die Daten sollen letztendlich in einer Informationsbasis landen. Aus diesem Grund wird eine verteilte Datenbank erstellt.

Normalerweise wird die Hauptbasis als zentral bezeichnet, der Rest als peripher. Im Endeffekt werden die Datenbanken entweder manuell oder automatisch (abhängig von den Einstellungen) zu einer zusammengefasst. Um sicherzustellen, dass Nummern neu eingegebener Dokumente und Referenzcodes nicht dupliziert werden, wird jeder Datenbank ein Präfix zugewiesen.

In dieser Anleitung werden wir anhand eines Beispiels eine zentrale und periphere Datenbank erstellen und den Austausch zwischen diesen überprüfen. Dieses Handbuch eignet sich sowohl für 1C 8.3 Accounting als auch für 1C Trade Management (UT) und andere Konfigurationen.

Einrichten der wichtigsten (zentralen) verteilten RIB-Datenbank

Gehen wir zum 1C-Menü „Administration“ und klicken Sie dann auf den Link „Datensynchronisierungseinstellungen“. Im sich öffnenden Fenster müssen Sie das Kontrollkästchen „Datensynchronisierung“ aktivieren. Der Link „Datensynchronisierung“ wird aktiv. Hier legen wir ein Präfix für die Hauptinformationsbasis fest – zum Beispiel „CB“:

Klicken Sie auf den Link „Datensynchronisierung“. Es öffnet sich ein Fenster mit der Schaltfläche „Datensynchronisierung einrichten“. Wenn Sie auf diese Schaltfläche klicken, öffnet sich eine Dropdown-Liste, in der Sie den Modus „Vollständig“ auswählen müssen. Wenn die Synchronisierung nur für eine Organisation erforderlich ist, müssen Sie „Nach Organisation ...“ auswählen.

Im nächsten Fenster fordert uns das Programm auf, eine Sicherungskopie zu erstellen. Ich empfehle dringend, dies zu tun, da die folgenden Einrichtungsschritte möglicherweise irreversibel sind.

Nachdem Sie ein Backup erstellt haben, klicken Sie auf die Schaltfläche „Weiter“. Im nächsten Schritt müssen wir entscheiden, wie die Synchronisierung erfolgen soll:

über ein lokales Verzeichnis oder ein Verzeichnis im lokalen Netzwerk;
über das Internet per FTP.

Der Einfachheit und Klarheit des Beispiels halber wählen wir ein lokales Verzeichnis. Ich habe folgenden Pfad angegeben: „D:\1C Databases\Synchronization“. Es empfiehlt sich, die Einträge in diesem Verzeichnis zu prüfen; dafür gibt es eine spezielle Schaltfläche:

Holen Sie sich 267 Video-Lektionen zu 1C kostenlos:

Die nächsten Schritte mit der Einrichtung der Synchronisierung per FTP und E-Mail überspringen wir. Schauen wir uns die Einstellungen für die Namen der Haupt- und Peripheriedatenbanken an. Hier legen wir das Präfix für die Peripheriedatenbank fest:

Vergessen Sie nicht, dass die Präfixe für jede Datenbank eindeutig sein müssen. Andernfalls erhalten Sie die Fehlermeldung „Der Präfixwert der ersten Infobase ist nicht eindeutig.“

Klicken Sie auf „Weiter“, überprüfen Sie die eingegebenen Informationen und klicken Sie erneut auf „Weiter“ und dann auf „Fertig stellen“. Geben Sie im Feld „Vollständiger Name der Dateibasis“ die Datei 1Cv8.1CD in dem Verzeichnis an, das für die Synchronisierung erstellt wurde. Wir erstellen das Ausgangsbild der verteilten 1C-Datenbank:

Nachdem Sie das erste Image des RIB in 1C erstellt haben, können Sie einen Synchronisierungszeitplan festlegen oder manuell synchronisieren:

Nach der Synchronisierung können Sie eine Verbindung zur neuen Datenbank herstellen und sicherstellen, dass Informationen aus der zentralen Datenbank dorthin hochgeladen wurden:

Erstellen Sie einfach sofort mindestens einen Benutzer mit Administratorrechten in der neuen Peripheriedatenbank.

Einrichten der Synchronisation in der Peripheriedatenbank

In der 1C-Peripheriedatenbank ist die Einrichtung viel einfacher. Aktivieren Sie einfach das Kontrollkästchen „Datensynchronisierung“ und folgen Sie dem gleichnamigen Link. Und wir befinden uns fast sofort in einem Fenster mit der Schaltfläche „Synchronisieren“. Versuchen wir, ein Testelement in der peripheren Datenbank zu erstellen und es mithilfe von RIB in die Hauptdatenbank hochzuladen:

In der Praxis kommt es häufig vor, dass verschiedene Abteilungen oder Niederlassungen geografisch an unterschiedlichen Orten liegen. Gleichzeitig müssen Daten, die in entfernten Abteilungen in das Programm eingegeben werden, irgendwie in die Zentrale gelangen, damit allgemeine Aufzeichnungen geführt werden.

Derzeit wird dieses Problem häufig dadurch gelöst, dass geografisch entfernten Mitarbeitern Fernzugriff auf eine gemeinsame Datenbank ermöglicht wird. Dies kann durch Veröffentlichung der Datenbank auf einem Webserver, über einen Remote-Desktop usw. erfolgen.

Es kommt jedoch nicht selten vor, dass in einem geografisch entfernten Büro einfach kein Internet vorhanden ist oder es nicht stabil genug ist, um in einer gemeinsamen Informationsbasis zu arbeiten. Zu diesem Zweck verfügt 1C über einen Mechanismus zum Einrichten einer verteilten Datenbank.

Einfach ausgedrückt ist der Hauptsitz der Ort, an dem sich die Hauptbasis befindet. Die Remote-Abteilung verwendet einen Untergebenen. Es kann mehrere solcher Sklavenbasen geben. Dadurch wird eine solche verteilte Datenbank durch Synchronisierung zu einer Einheit vereint. Dies kann entweder automatisch nach einem Zeitplan oder manuell erfolgen.

In diesem Artikel befassen wir uns mit der Einrichtung einer verteilten Datenbank für 1C: Accounting 3.0. Trotzdem ist die Anleitung für die meisten anderen 1C 8.3-Konfigurationen geeignet.

beachten Sie dass alle notwendigen Konfigurationsänderungen nur in der Haupt-RIB-Datenbank vorgenommen werden sollten. Bei der Synchronisierung werden diese Änderungen an alle Slave-Datenbanken übertragen und wirksam.

Hauptinformationsbasis

Bei Verwendung einer verteilten Datenbank liegen die Haupteinstellungen in der Hauptdatenbank. Sie müssen im Abschnitt „Administration“ durchgeführt werden, wie in der Abbildung unten gezeigt.

Aktivieren Sie im sich öffnenden Fenster sofort das Kontrollkästchen „Datensynchronisierung“. Geben Sie unten das Präfix der Hauptdatenbank (aktuelle Datenbank) an. Es darf maximal aus zwei Zeichen bestehen. In unserem Fall lautet das Präfix „BG“, da wir meinen, dass es sich bei diesem RIB 1C um „Hauptbuchhaltung“ handelt.

Jetzt können Sie mit der Einrichtung der eigentlichen Synchronisierung beginnen, d. h. festlegen, mit welcher Datenbank (oder welchen Datenbanken) die Daten ausgetauscht werden sollen. Folgen Sie dazu dem Hyperlink „Datensynchronisierungseinstellungen“. Es ist nur dann für die Navigation verfügbar, wenn das Kontrollkästchen links aktiviert ist.

Wählen Sie im sich öffnenden Fenster im Menü „Vollständig...“ aus. Dadurch können wir jede beliebige 1C-Informationsbasis für die Synchronisierung angeben.

Aktivieren Sie im ersten Fenster zum Anschließen einer untergeordneten Datenbank, die sich in einem geografisch entfernten Büro befindet, das Kontrollkästchen, dass die Verbindung über ein lokales oder Netzwerkverzeichnis hergestellt wird. In unserem Fall ist es „D:\DB\InfoBase“. Wir prüfen auch vorab, ob Sie ihn anschreiben können.

Stellen Sie sicher, dass Sie für verschiedene Datenbanken unterschiedliche Präfixe angeben. Tatsache ist, dass beim Synchronisieren von Daten den aus jeder Datenbank überlasteten Daten ein eigenes Präfix zugewiesen wird. Wenn sie dupliziert werden, ist die Arbeit fehlerhaft, sodass das Programm Ihnen diese Möglichkeit nicht bietet.

Wenn das Programm Sie auffordert, ein Startbild zu erstellen, wählen Sie diese Option. Dieser Vorgang wird einige Zeit dauern. Speichern Sie ihn anschließend unter dem Namen „1Cv8.1CD“ auf Ihrem Computer.

Die Synchronisierung selbst kann entweder automatisch nach einem Zeitplan, den Sie selbst einrichten können, oder manuell erfolgen. Im zweiten Fall klicken Sie einfach zu einem für Sie passenden Zeitpunkt auf die Schaltfläche „Synchronisieren“.

RIB-Slave-Knoten

Die Anzahl der in der Slave-Datenbank vorgenommenen Einstellungen ist deutlich geringer. Setzen Sie im selben Abschnitt das Flag „Datensynchronisierung“ und durch Klicken auf den entsprechenden Link wird die Schaltfläche „Synchronisieren“ verfügbar.

In unserem Beispiel wurden der Hauptdatenbank zwei Artikel hinzugefügt: „Beam“ und „Board“. Nach der Synchronisierung landeten sie in der Slave-Datenbank. Wie Sie im Bild unten sehen können, erhielten sie das Präfix „BG“. Die verbleibenden zwei Positionen („Drehmaschine“ und „Palette“) erhalten das Präfix „BP“, da sie direkt in der untergeordneten Datenbank angelegt wurden.

beachten Sie dass die Nummerierung der Elemente in unserem Fall fortlaufend ist, jedoch nur innerhalb desselben Präfixes.