1c 8.3 distributed infobases. Building an RDB from scratch. Basic principles of the RIB

October 25th, 2016

There is no big difference between configuring and maintaining the RIB for 2 nodes and for 10, but when the number of remote points exceeds a hundred, completely different issues have to be solved.

Initial data:

Configuration: Retail 2.2
Platform 1C: 8.3.7.1970



Project term: year.



Architecture:

First, we decided on the RIB scheme. It was decided to focus on the star scheme for as long as possible; upon reaching technological limits - a snowflake.





Limitations:
- 2 GB RAM
- 1 physical processor


Of all of the above, the limitation on the maximum volume of the database is basically annoying.

But this only means that it is necessary to organize the procedure for cleaning it from obsolete data in the field.

A separate physical server is allocated for the 1C and MS SQL server. He will bear the main burden of exchanges and long-term operations.
End client computers are not replaced, because they will work with a thin client and the load on them will be minimal.
.


basic settings

Since the days of UT 10.3, on which I had my first project of introducing an RIB for 60 knots, of course, "a lot of water has flowed under the bridge."

1C did not stand still. Retail 2.2 now takes into account the need for selective data upload.
Only the information that is relevant to the store will be uploaded to the store's database:
- All reference books (except specialized ones)
- Documents for this store

Another question is that, in one way or another, adding a node to the base means adding one more record to the registration table for each common element when it is recorded.





1) It should be divided into separate sync scripts for upload and download
The point is that the upload takes a long time and with locks, and the download is quite hassle-free. At the same time, it often happens that we need to quickly receive data from retail outlets, while giving it back only a few times a day.

2) Select problem stores and remove them from the general synchronization scenario. They can have large unloading - in this case, the entire exchange, including other nodes, will be slowed down. After solving problems, they are returned back.

3) Create several scenarios for sending and receiving data. But the main thing here is to catch the correct balance of their number.
(since version 8.1).
Consequently, the parallelism in unloading the RIB is limited. In practice, it turns out to run 2-3 scripts in parallel.


What had to be finalized

The most important jamb in the standard logic of 1C RIB is updates

Information registers are another problem of exchange. Dumping each information register record into XML creates a separate XML node with service elements, etc. In addition, the "SelectChanges ()" function for an information register in which 100 records will receive a result table of 100 rows, at the same time, if this a directory with 100 rows in the tabular section, only one record will be selected. And this is the time of exclusive blocking. So if there are many records in the PC that are regularly registered for exchange in other stores, then it is certainly correct to present it in the form of a reference book with a tabular section, which, in extreme cases, when recording, can form rows of the same register. Anyway, .

Another important detail is What for? Discount cards have already accumulated close to 3 million. An external online system is used to work with them. If you continue to transfer discount cards to all stores, this will significantly increase exchanges, in addition, it can lead to an excess of the base volume of 10 GB.

Some of the mechanisms are implemented online by contacting the central database: balances in other stores, returning a check from another store, checking the validity of a gift certificate.


Duplication


Creation of the initial RIB node in a regular way would make replication impossible in principle.
Therefore, a new node is created as follows:


2) This database exchanges all general data in the RIB but does not receive specialized (documents)


5) The base for the store is ready.

A ready-made software package is deployed to the server, so it doesn't take much time. Then the newly created database is uploaded to the server and it is ready to be sent to the store.


Thin client benefits

Two significant advantages of Retail 2.2 (Thin Client) that "warmed the soul":








Support & Updates




1) Update with the hands of stores (not very correct, they may not receive changes, there will be calls and problems) - as it was before

3) Write a * .cmd or 1C script for updating or take a ready-made one. As practice shows, such a solution is always half-hearted (unstable), and it will be possible to lay a little functionality in it.

What tasks we had:


2) When updating, interactive interaction with the user is possible (messages, confirmation, progress bar).








Main functions:




4) Checking the status of agents
5) Update reports
6) backup

















For example, this is how the error message looks after an update:

Thus, the project has a good chance of being completed successfully. At least in the middle of the way "normal flight".

If we come to any other solutions that may seem interesting, I will write separately

P.S. and most importantly: Correct planning of further support is one of the key factors for the further success of such projects. :)

October 25th, 2016

There is no big difference between configuring and maintaining RIB for 2 nodes and for 10, but when the number of remote points exceeds a hundred, completely different issues have to be resolved.

So, the initial data:

Configuration: Retail 2.2
Platform 1C: 8.3.7.1970
Estimated number of nodes at the end of the project: 200
Equipment resources in the center: no significant restrictions
Equipment at the point: the issue under discussion.
Project term: year.

Architecture:

First, we decided on the RIB scheme. It was decided to focus on the "star" scheme, before that
V retail outlets the client-server version of work is used, with a dedicated server, under the control of Windows OS.
Server 1C will be used in the version "Server 1C MINI" https://1c.ru/news/info.jsp?id=17577
DBMS server - MS SQL Express 2008 R2.

SQL Express 2008 R2 is the latest version of this line of SQL Server.
Limitations:

2 GB RAM
- 1 physical processor
- 10 GB maximum database size

Of all of the above, the limitation on the maximum volume of the database is certainly annoying. But in fact, this only means that it will be necessary to organize the procedure for cleaning it from obsolete data in the field.

A separate server is allocated for the 1C and MS SQL server. The main burden of exchanges and operations will fall on him.
End client computers are not replaced, because they will work with a thin client and the load on the bottom will be minimal.
The server in the store is just a powerful PC. But a prerequisite is the presence of an SSD disk - on which the MS SQL databases are located.
Also, the server will provide the ability to carry out routine operations at night and access to the store database without interrupting work.

basic settings

Since the time of UT 10.3, on which I had my first project of introducing an RIB for 60 knots, of course "a lot of water has flowed under the bridge." 1C did not stand still. Retail 2.2 now takes into account the need for selective data upload.
Only the information that is related to nemiu will be uploaded to the store's database:
- All directories (except for some)
- Documents on this magnazin
Data registration takes place according to the registration rules, everything that can be cached. Significant delays are not observed precisely at registration.
Another question is that one way or another, adding a node to the base means adding one more record for each common element for all bases.

There is nothing specific in setting up the unloading itself. There are some nuances when setting up synchronization scenarios:

1) It is necessary to separate upload and download into separate synchronization scripts.
The point is that the upload takes a long time and with locks, and the download is quite problem-free. At the same time, it often happens that we need to quickly receive data from retail outlets, while giving it back only a few times a day.

2) Select problem stores and remove them from the general synchronization scenario. They can have large unloading - in this case, the entire exchange will be slowed down, including other nodes

3) Create several send and receive scripts for sending and receiving data. But the main thing here is balance.
Some things in 1C do not change. The same "SelectChanges" method can only be performed sequentially(since version 8.1).
Consequently, the parallelism in unloading the RIB is limited. In practice, it is possible to unload 2-3 scenarios at a time.
As for the receiving scenario, much more parallelism is possible, if needed, of course.

What had to be finalized

Of course it’s sad and sad, but I had to get into the BSP thoroughly. The most important jamb in the standard 1C logic is updates... After the update, something like this window appears:

This all happens in a monopoly mode. Among other things, the system will still try to make an exchange after the upgrade in exclusive mode. What all this leads to is not difficult to guess.
During this entire period of time, the store cannot work, customers are at the checkout, the company loses money.

Information registers are another problem of exchange. Unloading each information register record in XML creates a separate XML node with service elements and everything that flows from here. In addition, the function "select changes" for a register of information in which 100 records, the resulting table will contain 100 rows, at the same time, if this is a directory in which 100 rows in the tabular section, only one record will be selected. So if there are many records in the PC that are regularly registered for exchange in other stores, then it is certainly correct to present it in the form of a reference book with a tabular section, which, in extreme cases, when recording, can form records of the same register. Anyway, information registers in exchanges are evil.

Another important detail is discount cards are completely excluded from the exchange, and individuals - only employees of a particular store. What for? Discount cards have already accumulated close to 3 million. An external online system is used to work with them. If you continue to transfer discount cards to all stores, this will significantly increase exchanges, in addition, it can lead to an excess of the base volume of 3GB.

Some of the mechanisms are implemented online by contacting the central database: balances in other stores, returning a check from another store, checking the validity of a gift certificate.

Duplication

Of course, replication is being carried out at an accelerated pace.
Creation of the initial RIB node in a regular manner would of course make replication impossible.
Therefore, a new node is created as follows:

1) There is a separate base with a fake store
2) This base exchanges all general data in the RIB, but does not receive specialized
3) When we want to create new base- just copy this
4) Then we set the settings - store, prefix, etc.
5) The base for the store is ready.

A ready-made software package is deployed to the server, so it doesn't take much time. Then the newly created store database is uploaded to the server and it is ready to be sent to the store.

Thin client benefits

two significant benefits that "warmed the soul".

1) There is no need to change the entire computer park in retail outlets. 90% of operations are performed on the server, and the server is brought there "a relatively powerful computer"

2) The technique has the ability to refuse to work, especially often this happens with newly installed or already worn out equipment.
In this case, the actions are now extremely simple - the store switches to work in the central base.
This process takes no more than 5-10 minutes, so trading is not interrupted even with significant problems with equipment.

Support & Updates

Finally we got to the most interesting point - how to maintain and update all this?
For us, updates have also been a problem for a long time:

1) Update with the hands of stores (not very correct, they may not receive changes, there will be calls and problems)
2) Renew by forces technical support(not so many resources)
3) Write * .cmd for updating or take a ready one. As practice shows, such a solution is always half-hearted (unstable), and there is little functionality in it.

What tasks we had:

1) The update should take place in several modes and be managed centrally
2) When updating, interactive interaction with the user is possible.
3) Be sure to receive status reports and update errors
4) There must be a backup
5) The update system should be able to update itself without any problems.
6) The system should be expandable without any problems.

Of course, the tasks went far beyond the list of solvable simple methods... Since automation with so many endpoints is indispensable, and we did not find anything more or less ready with similar functionality
I had to start developing software, which eventually acquired the name MU (MagicUpdater).

Main functions:

1) Dynamic database update (command or schedule)
2) Static base update (command or schedule)
3) automatic agents on target computers when they are modified
4) Checking the status of agents
5) Update reports
6) backup
7) Administrative actions with server 1C and MS SQL
8) Closing all 1C client applications on network computers
9) Static update with acceptance at the main checkout
10) Displaying the description of modifications after the update
11) Configuring the order of actions
12) Performing all these actions on a schedule

Approximate interaction schemes:

Where MU Agent is a service installed and configured in the store. Actually, she receives a command from the center to perform certain tasks.
MU Server - The server that accepts all requests to the system.
MU monitor - what ordinary technical support employees see - is used to view logs and set tasks for updating, or others.

It turned out pretty good, in my opinion. Now updates are taking place almost in automatic mode.
This is how, for example, the error message looks after the update remained in the center, everything is waiting.

This is how we send commands to client computers.

The applications are certainly not 1C, but with a fairly decent set of interface capabilities. For example, this is how a selection by date looks like:

Now we are ready for further replication. Correct planning of further support is one of the key factors for the further success of such projects.

Creation and configuration of a distributed database (RIB) in 1C 8.3 Accounting (and other configurations) are necessary in cases where it is not possible to work for several users while simultaneously connecting to one database. This is quite rare nowadays, as standard remote desktop works fine and there are other programs that provide a remote connection to the central computer where the database is located.

But nevertheless, there are situations when there is simply no Internet. And the data should end up in one infobase. For this, a distributed database is created.

Usually the main base is called central, and the rest are called peripheral. The bottom line is that either in manual or in automatic mode (depending on the setting), the databases are combined into one. To prevent the numbers of newly entered documents and directory codes from being duplicated, a prefix is ​​assigned to each database.

In this tutorial, we will use an example to create a central and peripheral databases, check the exchange between them. This manual is suitable for both 1C 8.3 Accounting and 1C Trade Management (UT) and other configurations.

Setting up the main (central) distributed RIB database

Let's go to the 1C Administration menu, then follow the link “Data synchronization settings”. In the window that opens, select the "Data synchronization" checkbox. The link "Data Synchronization" will become active. Immediately here we will set the prefix for the main infobase - for example, "Central Bank":

We go to the link "Data synchronization", a window with the button "Configure data synchronization" will open. When you click on this button, a drop-down list will open, where you need to select the "Full" mode. If you need to synchronize only one organization, you need to select "By organization ...".

In the next window, the program will offer us to make a backup. I highly recommend doing this, as the following configuration steps may not be reversible.

After creation backup press the "Next" button. In the next step, we need to decide how the synchronization will take place:

• through a local directory or a directory on a local network;
• over the Internet via FTP.

For simplicity and clarity of the example, we will select the local directory. I indicated the following path: "D: \ Base 1C \ Synchronization". It will not be superfluous to check the entry to this directory, for this there is a special button:

Get 267 1C video tutorials for free:

Skip the next steps for configuring FTP and email sync. We dwell on the settings for the names of the main and peripheral databases. Here we will set the prefix for the peripheral base:

Do not forget that the prefixes for each database must be unique. Otherwise, you will receive the error "The value of the prefix of the first infobase is not unique."

Click "Next", check the entered information and again click "Next", then - "Finish". In the "Full name of the file base" field, specify the 1Cv8.1CD file in the directory that was created for synchronization. We create an initial image of a distributed 1C database:

After creating the initial RIB image in 1C, you can set a synchronization schedule or manually synchronize:

After synchronization, you can connect to the new database and make sure that information from the central database has been uploaded there:

Just start at least one user with Administrator rights in the new peripheral base right away.

Setting up synchronization in the peripheral database

In the 1C peripheral base, the setup is much easier. It is enough to check the box "Data synchronization" and follow the link of the same name. And we almost immediately find ourselves in the window with the "Synchronize" button. Let's try to create a test nomenclature in the peripheral database and upload it to the main one using the RIB:

The URBD (Distributed Database Management) component is used when it is necessary to exchange information between two or more identical information bases (hereinafter - IB) over a narrow communication channel (for example, a modem, e-mail). Below is a step by step instruction and practical advice on setting up URBD in 1C: Enterprise 7.7. An example is given for two information security, although it is not difficult to configure it for a larger number of databases by analogy with two databases.

Article author: romix | Editors: evGenius Last revision №7 from 22.02.08 | History Url:

Keywords: URBD, script for auto-exchange, exchange between branches, mail, rom-mail.dll, DialMail.dll, CDO, dial-up, URIB

The URBD (Distributed Database Management) component is used when it is necessary to exchange information between two identical information bases (hereinafter - IB) over a narrow communication channel (for example, a modem, e-mail). Below is a step-by-step instruction and practical advice on setting up a URBD in 1C: Enterprise 7.7. An example is given for two information security, although it is not difficult to configure it for a larger number of databases by analogy with two databases.

1) The DistrDB.dll library in the BIN folder of the 1C: Enterprise program is responsible for the operation of the URBD component. This component is purchased and installed separately.

2) For the example of auto-exchange, we will create two infobases, placing them in folders named c: \ 1c_base1 and c: \ 1c_base2. Create these folders, and in each of them - subfolders with the names CP and PC (in Latin letters)

3) In the c: \ 1c_base1 folder, place a ready-made configuration (for example, "Trade and Warehouse"). But it is better to train on the simplest information base (containing, for example, just one reference book with several entries). It is important for us to make sure that data really migrates from one information security to another as a result of URBD auto-exchange, and this can be shown both in a complex and in the simplest test case.

4) Close all windows in the Configurator and activate the "Administration - Distributed IS - Management" menu item. This menu item is available if the BIN folder of the 1C: Enterprise program contains the DistrDB.dll component. If the library has the wrong version or is damaged, simply reinstall 1C: Enterprise over the current installation - the DistrDB.dll library will be replaced by its correct version.

5) In the window that opens, click the "Central IB" button. In the request window, specify the code of the new infobase (enter the number 1) and its description (for example, "Central IB").

6) Extinguish the appeared warning about the irreversibility of changes by clicking "OK" (below is described an undocumented method, how, if necessary, to return the base to its original state).

7) Click the New Peripheral button. IB ". In the request window, specify the code 2 for it and the description - "Peripheral IB".

8) Select the peripheral base with a single click and press the “Configure” button. auto-exchange ". In the window that opens, by setting the switch, change the "Manual" auto-exchange mode to "Automatic" and click the "OK" button.

9) Click the Upload Data button. Remember (to the clipboard) the name of the downloaded file "c: \ 1c_base1 \ CP \ 20.zip" - it will still be useful to us. Click OK. At the end of the upload, 1C will write "Upload successfully completed".

10) Close the Configurator and enter (also in the Configurator mode) the folder (still empty) where the second IB should be located (in our example - c: \ 1c_base2). Indicate that the database should be in DBF / CDX format and click "OK".

11) Go to the Administration - Distributed IS - Management menu item. In response to the question “The infobase was not found. Do you want to download data? " click "Yes" and specify the name of the upload file (in our example, "c: \ 1c_base1 \ CP \ 20.zip") and click "OK". At the end of the download, 1C will write “Download completed successfully”. We have successfully created the Peripheral IS by downloading data from the Central IS.

12) Change anything (for example add new item reference book) in one of the information bases. Our goal is to ensure that changes in one (any) information security get into another information security through auto-exchange. Use the menu item "Administration" - "Distributed information security" - "Auto exchange" alternately in each of the bases. Newly appearing unload files with the ZIP extension in the CP and PC folders must be moved (copied) between infobases according to the CP-> CP, PC-> PC principle (in real "field" conditions, this is usually done using Email).

Tips and recipes

1) To turn a distributed database into a regular one, delete the files 1SDBSET.DBF, 1SDWNLDS.DBF, 1SUPDTS.DBF and their corresponding * .CDX files, as well as 1SSYSTEM.DBF. Basically, it is enough to remove 1SSYSTEM.DBF. After that, you need to restore the point of relevance by running the program in exclusive mode. This trick is undocumented (guess why), but it works nonetheless.

2) You can change the 1C configuration, but only in the Central IB. This is very convenient - changes in peripheral information security are "rolled" automatically.

3) If you have lost (for example, as a result of a mail error) one or more uploads - do not worry, because URBD is able to track such situations, and retry sending lost data at the next auto-exchange session.

4) The standard ability to send mail to 1C is implemented through the MAPI interface, when interaction occurs with an email client (such as Outlook). My advice - do not waste your time - with MAPI and all sorts of Outlucks, in practice, problems constantly arise that require a developer to "drive quickly" between branches. I do not recommend using a direct dial up connection or FTP for the same reason. It is better to send mail with external components such as rom-mail.dll or DialMail.dll.

Another option is to use CDO
http://avb1c.narod.ru/?=a9
(c) avb, Mouthpiece of the absurd

5) You can take a program that can automatically perform auto-exchange and send upload files by e-mail here:

If you set up a few constants correctly ( postal addresses, passwords, attendance, etc.), the user only needs to double-click on the shortcut to start Auto-exchange.

The program is implemented as a 1C: Enterprise configuration. Detailed description contained in the attached DOC file.

6) If you need to automatically dial to your ISP, use the E-Type Dialer program. She knows how to launch external applications upon successful connection. Another option is to use an external component DialMail, which has the means of working with a modem (advice - the prefix "p" in Latin before the number gives pulse dialing, 9W in front of the number - calling through the "nine" and waiting for a dial tone, etc.).

Note: Windows XP has a built-in dialer called rasdial.exe. Keys command line:
rasdial.exe Item User Password
rasdial.exe Element / DISCONNECT

7) Priority is given to changes made in the Central IS. Please note that infobase prefixes are used in typical 1C configurations (see this setting in Constants) so that the codes of catalog items and document numbers created in different databases do not match, and their uniqueness is not violated.

a brief description of
Number of installations	not limited	Use with Accounting Component 7.7	Yes
Number of peripheral databases	not limited	Use with the Operational Accounting component 7.7	Yes
Standalone program	No	Use with Calculation Component 7.7	Yes
Security key type	USB	Delivery within Russia is included in the price	Yes
Distribution kit	Yes	Purchase features	on application
Installation manual included	Yes

Why do you need 1C: Enterprise 7.7. Management of distributed information bases (1C URBD, 1C URIB)

Abbreviations and abbreviations: 1C URBD- Management of distributed databases; 1C URIB- Management of distributed information bases.

An additional component "Management of distributed information bases" - 1C URBD - 1C URIB - is used to organize a unified automated accounting system at enterprises that have geographically remote divisions (for example, head office, store, warehouse, etc.) not connected by local network... The capabilities provided by this component make it possible to organize the operation of a distributed information system with an unlimited number of autonomous peripheral information bases.

A distributed infobase consists of one central and unlimited number of peripheral infobases. In each of the infobases, new data are entered and the existing ones are modified independently. The system configuration can be modified or updated exclusively in the central information base. To synchronize data between the central and peripheral infobases, the changed data must be transferred periodically. Transfer files can be transported by any available ways(on a floppy disk, by e-mail, etc.). The system tracks all data changes automatically and transmits them in accordance with the described synchronization rules.

The 1C URBD component can only be used with professional versions of the 1C: Enterprise 7.7 system programs.

How many pieces of "1C: Enterprise 7.7. Distributed infobase management" do you need to buy, for example, for the head office and two remote warehouses?

Component "1C: Enterprise 7.7. Management of distributed information bases" - 1C URBD - is installed for central information base. One component allows you to synchronize an unlimited number of peripheral infobases. Thus, for example, to synchronize the head office and two remote warehouses, one copy of "1C: Enterprise 7.7. Distributed infobase management" is required.

Often, in practice, there are situations when different divisions or branches are geographically located in different places. At the same time, the data entered into the program in remote divisions must somehow get to the head office so that general accounting is kept.

Currently this problem often solved by providing geographically remote employees with remote access to a common database. It can be done by publishing the database on a web server, via a remote desktop, etc.

However, such situations are not uncommon when there is simply no Internet in a geographically remote office, or it is not stable enough to work in a common information base. To do this, 1C has a mechanism for configuring a distributed database.

Simply put, the main base is located in the head office. The remote department uses a subordinate. There may be several such subordinate bases. As a result, such a distributed base is combined into one through synchronization. It can be performed both in automatic mode according to a schedule and manually.

In this article we will consider setting up a distributed database for 1C: Accounting 3.0. Despite this, the instructions are suitable for most other 1C 8.3 configurations.

note that all necessary configuration modifications should be made only in the main RIB database. During synchronization, these changes will be transferred to all subordinate bases and will take effect.

Main information base

When using a distributed database, the main settings fall on the main database. They need to be produced in the "Administration" section, as shown in the image below.

In the window that opens, immediately check the "Data synchronization" checkbox. In the lower part, specify the prefix of the main (current base). It can be up to two characters long. In our case, the prefix will be "BG", since we mean that this RIB 1C "Accounts department".

Now you can start setting up the synchronization itself, namely, specifying with which database (or databases) the data will be exchanged. To do this, follow the "Data Synchronization Settings" hyperlink. It will be available for transition only when the checkbox on the left is checked.

In the window that opens, from the menu, select the item "Full ...". It will allow us to specify any 1C information base for synchronization.

In the first window for connecting a subordinate base located in a geographically remote office, select the flag that the connection will be made through a local or network directory. In our case, this is "D: \ DB \ InfoBase". We will also check the possibility of writing to it in advance.

Be sure to specify different prefixes for different bases. The fact is that when synchronizing data, a different prefix is ​​set for the data overloaded from each database. If they are duplicated, the work will be incorrect, so the program will not give you this opportunity.

When the program prompts you to create an initial image, select this option. This procedure will take some time, then save it to your computer with the name "1Cv8.1CD".

The synchronization itself can be performed both automatically according to the schedule, which you can configure yourself, or manually. In the second case, just click on the "Synchronize" button at a convenient time for you.

RIB slave node

The number of settings made in the subordinate base is much less. In the same section set the "Data synchronization" flag and by clicking on the corresponding link the "Synchronize" button will be available.

In the framework of our example, two nomenclature items were added to the main database: "Beam" and "Board". After synchronization, they ended up in a subordinate base. As you can see in the picture below, they have been assigned the prefix "BG". The other two positions ("Lathe" and "Pallet") were assigned the prefix "BP", since they were entered directly in the subordinate base.

note that the numbering of elements in our case is end-to-end, but only within the same prefix.