Счетоводство на предприятието 1c 8.3 как да създадете ребро. Разпределена информационна база: Основи. Основни принципи на работа на RIB

25 октомври 2016 г

Няма голяма разлика между настройката и поддръжката на RIB за 2 възли и за 10, но когато броят на отдалечените точки надхвърли сто, трябва да се решат напълно различни проблеми

Първоначални данни:

Конфигурация: Retail 2.2
Платформа 1C: 8.3.7.1970 г

Продължителност на проекта: една година.

Архитектура:

Първо, решихме схемата RIB. Беше решено да се съсредоточи върху схемата „звезда“ възможно най-дълго; при достигане на технологични ограничения - снежинка.

Ограничения:
- 2 GB RAM
- 1 брой физически процесор

От всичко по-горе, основното досадно нещо е ограничението на максималния размер на базата данни.

Но това просто означава, че трябва внимателно да организирате процедура за почистването му от остарели данни на място.

За сървъра 1C и MS SQL е разпределен отделен физически сървър. Той ще понесе основната тежест на борсите и дългосрочните операции.
Крайните клиентски компютри не се сменят, защото ще работят с тънкия клиент и натоварването върху тях ще е минимално.
.

основни настройки

От времето на UT 10.3, по време на което имах първия си проект за внедряване на RIB за 60 възела, разбира се, „много вода премина под моста“.

1C не стоеше неподвижно. Retail 2.2 вече взема предвид необходимостта от селективно качване на данни.
В базата данни на магазина ще бъде качена само информация, която е подходяща за него:
- Всички справочници (с изключение на специализираните)
- Документи за този магазин

Друг въпрос е, че по един или друг начин добавянето на възел към базата данни означава добавяне на друг запис към регистрационната таблица за всеки общ елемент, когато е написан.

1) Необходимо е да се разделят на отделни сценарии за синхронизация за качване и изтегляне
Въпросът е, че разтоварването отнема много време и включва блокиране, докато зареждането е доста безпроблемно. В същото време често се случва да имаме нужда бързо да получим данни от търговски обекти, като ги даваме само няколко пъти на ден.

2) Идентифицирайте проблемните хранилища и ги премахнете от общия сценарий за синхронизация. Може да има големи разтоварвания върху тях - това ще забави целия обмен, включително други възли. След като проблемите бъдат разрешени, те се добавят обратно.

3) Създайте няколко скрипта за изпращане и получаване на данни. Но основното тук е да се улови правилният баланс на тяхното количество.
(от версия 8.1).
Следователно паралелизмът при разтоварването на RIB е ограничен. На практика се оказва, че се изпълняват 2-3 скрипта паралелно.

Какво трябваше да се подобри

Най-важният проблем в стандартната логика на 1C RIB са актуализациите

Друг проблем на обмена са информационните регистри. Качването на всеки запис на информационния регистър в XML създава отделен XML възел със сервизни елементи и т.н. Освен това функцията "SelectChanges()" за информационен регистър, в който има 100 записа, ще получи резултатна таблица от 100 реда, на в същото време, ако тази директория със 100 реда ще има само един избран запис в нейната таблична секция. И това е времето на изключителното блокиране. Така че, ако има много записи в компютъра, които редовно се регистрират за обмен в други магазини, тогава, разбира се, е по-правилно това да се представи под формата на директория с таблична част, която в краен случай при запис , могат да образуват редове от същия регистър. Така или иначе, .

Друг важен детайл - За какво? Картите за отстъпки вече са близо 3 млн. За работата с тях се използва външна онлайн система. Ако продължите да прехвърляте карти за отстъпка във всички магазини, това значително ще увеличи обмена и може също така да доведе до надвишаване на обема на базата от 10 GB.

Част от механизмите се реализират онлайн чрез контакт с централната база данни: салда в други магазини, връщане на касова бележка от друг магазин, проверка на валидност на ваучер за подарък.

Репликация

Създаването на първоначален RIB възел по нормален начин би направило репликацията невъзможна по принцип.
Следователно се създава нов възел, както следва:

2) Тази база данни обменя всички общи данни в RIB, но не получава специализирани (документи)

5) Основата за магазина е готова.

На сървъра се инсталира готов софтуерен пакет, така че не отнема много време. След това новосъздадената база данни се качва на сървъра и е готова за изпращане до магазина.

Предимства на тънък клиент

Две значителни предимства на Retail 2.2 (Thin Client), които „стопляха душата“:

Поддръжка и актуализации

1) Актуализирайте ръчно от магазините (не е много правилно, промените може да не бъдат получени, ще има обаждания и проблеми) - това беше случаят преди

3) Напишете *.cmd или 1C скрипт за актуализиране или вземете готов. Както показва практиката, такова решение винаги е половинчато (нестабилно) и ще бъде възможно да се вгради малка функционалност в него.

Какви бяха нашите задачи:

2) При актуализиране е възможно интерактивно взаимодействие с потребителя (съобщения, потвърждение, лента за напредък).

Основни функции:

4) Проверка на статуса на агентите
5) Актуализиране на отчети
6) резервно копие

Например, ето как изглежда съобщението за грешка след актуализация:

Така проектът имаше добри шансове да бъде завършен успешно. Поне по средата на полета полетът е нормален.

Ако стигнем до други решения, които може да изглеждат интересни, ще пиша отделно

P.S. и най-важното: Правилното планиране на по-нататъшната подкрепа е един от ключовите фактори за по-нататъшния успех на такива проекти. :)

25 октомври 2016 г

Няма голяма разлика между настройката и поддръжката на RIB за 2 възли и за 10, но когато броят на отдалечените точки надхвърли сто, трябва да се решат съвсем различни проблеми.

И така, първоначалните данни:

Конфигурация: Retail 2.2
Платформа 1C: 8.3.7.1970 г
Очакван брой възли в края на проекта: 200
Ресурси на оборудването в центъра: без съществени ограничения
Оборудване на пункта: дискутиран въпрос.
Продължителност на проекта: една година.

Архитектура:

Първо, решихме схемата RIB. Преди това беше решено да се съсредоточи върху схемата „звезда“.
В търговските обекти се използва клиент-сървърна версия на работа със специален сървър, работещ под Windows OS.
Сървър 1C ще се използва във версията "Server 1C MINI" https://1c.ru/news/info.jsp?id=17577
СУБД сървър - MS SQL Express 2008 R2.

SQL Express 2008 R2 е най-новата версия на тази линия SQL Server.
Ограничения:

2 GB RAM
- 1 брой физически процесор
- 10 GB максимален размер на базата данни

От всичко по-горе, най-досадното нещо, разбира се, е ограничението за максималния размер на базата данни. Но всъщност това просто означава, че ще е необходимо внимателно да се организира процедурата за почистването му от остарели данни на място.

Отделен сървър е разпределен за 1C и MS SQL сървър. Той ще понесе основната тежест на обмена и транзакциите.
Крайните клиентски компютри не се сменят, защото ще работят с тънък клиент и натоварването на дъното ще е минимално.
Сървърът в магазина е просто мощен компютър. Но задължително условие е наличието на SSD диск - на който се намират MS SQL базите данни.
Сървърът също така ще предоставя възможност за извършване на рутинни операции през нощта и достъп до базата данни на магазина без прекъсване на работата.

основни настройки

От времето на UT 10.3, по време на което имах първия си проект за внедряване на RIB за 60 възела, разбира се, „много вода е изтекла под моста“. 1C не стоеше неподвижно. Retail 2.2 вече взема предвид необходимостта от селективно качване на данни.
Само информация, която е от значение за магазина, ще бъде качена в базата данни на магазина:
- Всички директории (с изключение на някои)
- Документи за този магазин
Регистрацията на данни се извършва съгласно правилата за регистрация, всичко, което може да се кешира. Няма значително забавяне по време на регистрацията.
Друг въпрос е, че по един или друг начин добавянето на възел към базата данни означава добавяне на друг запис за всеки общ елемент за всички бази данни.

Няма нищо конкретно в настройването на самото качване. Има някои нюанси при настройване на сценарии за синхронизация:

1) Необходимо е да се разделят качването и зареждането в отделни сценарии за синхронизация
Въпросът е, че разтоварването отнема много време и включва блокиране, докато зареждането е доста безпроблемно. В същото време често се случва да имаме нужда бързо да получим данни от търговски обекти, като ги даваме само няколко пъти на ден.

2) Идентифицирайте проблемните хранилища и ги премахнете от общия сценарий за синхронизация. Може да има големи разтоварвания върху тях - това ще забави целия обмен, включително други възли

3) Създайте някои скриптове за изпращане и получаване, за да изпращате и получавате данни. Но основното тук е балансът.
Някои неща в 1C не се променят. Същият метод "SelectChanges" може да се изпълнява само последователно(от версия 8.1).
Следователно паралелизмът при разтоварването на RIB е ограничен. На практика в крайна сметка качвате 2-3 скрипта наведнъж.
Що се отнася до сценария на получаване, тук е възможен много по-голям паралелизъм, ако е необходимо, разбира се.

Какво трябваше да се подобри

Разбира се, че е тъжно и тъжно, но трябваше да намеся щателно на БСП. Най-важният проблем в стандартната логика на 1C са актуализациите. След актуализацията се появява прозорец, подобен на този:

Всичко това се случва в монополен режим. Наред с други неща, системата все още ще се опитва да направи обмен след актуализиране в изключителен режим. Не е трудно да се досетите докъде води всичко това.
През целия този период от време магазинът не може да работи, има клиенти на касата, а фирмата е на загуба.

Друг проблем на обмена са информационните регистри. Качването на всеки запис в информационен регистър в XML създава отделен XML възел с сервизни елементи и всичко, което следва. В допълнение, функцията „избор на промени“ за информационен регистър, в който има 100 записа, получената таблица ще съдържа 100 реда, в същото време, ако това е директория със 100 реда, само един запис ще бъде избран в раздел таблица. Така че, ако има много записи в компютъра, които редовно се регистрират за обмен в други магазини, тогава, разбира се, е по-правилно това да се представи под формата на директория с таблична част, която в краен случай при запис , може да генерира записи на същия регистър. Така или иначе, информационните регистри в борсите са зло.

Друг важен детайл - Картите за отстъпка са напълно изключени от обмена, а само служителите на конкретен магазин са изключени от обмена.За какво? Картите за отстъпки вече са близо 3 млн. За работата с тях се използва външна онлайн система. Ако продължите да прехвърляте карти за отстъпка във всички магазини, това значително ще увеличи обмена и освен това може да доведе до надвишаване на базата от обем от 3GB.

Част от механизмите се реализират онлайн чрез контакт с централната база данни: салда в други магазини, връщане на касова бележка от друг магазин, проверка на валидност на ваучер за подарък.

Репликация

Разбира се, репликацията се извършва с ускорени темпове.
Създаването на първоначалния RIB възел по стандартен начин, разбира се, би направило репликацията невъзможна.
Следователно се създава нов възел, както следва:

1) Има отделна база данни с фалшив магазин
2) Тази база данни обменя всички общи данни в RIB, но не получава специализирани
3) Когато искаме да създадем нова база данни, просто копираме тази
4) След това задаваме настройките - магазин, префикс и т.н.
5) Основата за магазина е готова.

На сървъра се инсталира готов софтуерен пакет, така че не отнема много време. След това новосъздадената база данни от магазини се качва на сървъра и е готова за изпращане до магазина.

Предимства на тънък клиент

две значителни предимства, които „стопляха душата“.

1) Няма нужда да сменяте целия компютърен парк в търговските обекти. 90% от операциите се извършват на сървъра, а сървърът се пренася там с „сравнително мощен компютър“

2) Оборудването има способността да отказва да работи, особено често се случва с новоинсталирано или вече износено оборудване.
В този случай действията вече са изключително прости - магазинът преминава към работа в централната база данни.
Този процес отнема не повече от 5-10 минути, така че търговията не се прекъсва дори ако има значителни проблеми с оборудването.

Поддръжка и актуализации

Най-накрая стигнахме до най-интересния момент - как да поддържаме и актуализираме всичко това?
За нас актуализациите също са дилема от дълго време:

1) Актуализирайте ръчно от магазините (не е много правилно, промените може да не бъдат получени, ще има обаждания и проблеми)
2) Актуализирайте с помощта на техническа поддръжка (няма толкова много ресурси)
3) Напишете *.cmd за обновяване или вземете готов. Както показва практиката, такова решение винаги е половинчато (нестабилно) и в него има малко функционалност.

Какви бяха нашите задачи:

1) Актуализацията трябва да се извършва в няколко режима и да се управлява централно
2) При актуализиране е възможно интерактивно взаимодействие с потребителя.
3) Трябва да се получават отчети за статус на актуализация и грешки
4) Трябва да има резервно копие
5) Системата за актуализиране трябва да може да се актуализира без проблеми.
6) Системата трябва да може да се разширява без никакви проблеми.

Разбира се, проблемите далеч надхвърляха списъка на разрешимите с прости методи. Защото не можем без автоматизация с толкова много крайни точки и не сме намерили нещо повече или по-малко готово с подобна функционалност
Трябваше да започна да разработвам софтуер, който в крайна сметка придоби името MU (MagicUpdater).

Основни функции:

1) Динамична актуализация на база данни (команда или по график)
2) Актуализация на статична база данни (команда или по график)
3) автоматични агенти на крайните компютри, когато са модифицирани
4) Проверка на статуса на агентите
5) Актуализиране на отчети
6) резервно копие
7) Административни действия с 1C сървър и MS SQL
8) Затваряне на всички клиентски приложения на 1C на мрежови компютри
9) Статична актуализация с приемане на основната каса
10) Показване на описания на модификациите след актуализиране
11) Настройка на реда на действията
12) Изпълнете всички тези действия по график

Приблизителни схеми на взаимодействие:

Където MU Agent е услуга, която се инсталира и конфигурира в магазина. Всъщност тя получава команда от центъра да изпълнява определени задачи.
MU сървър - Сървърът, който получава всички заявки към системата.
Мониторът на MU - това, което виждат обикновените служители на техническата поддръжка - се използва за преглед на регистрационни файлове и задаване на задачи за актуализиране или други.

Получи се доста добре според мен. Сега актуализациите се извършват почти автоматично.
Така например изглежда съобщението за грешка след актуализацията; всичко остава в центъра и чака.

Ето как изпращаме команди към клиентските компютри

Приложенията със сигурност не са 1C, но с доста приличен набор от интерфейсни възможности. Например, ето как изглежда изборът по дата:

Сега те са готови за по-нататъшно копиране. Правилното планиране на по-нататъшната подкрепа е един от ключовите фактори за по-нататъшния успех на подобни проекти.

Създаването и конфигурирането на разпределена база данни (RDB) в 1C 8.3 Accounting (и други конфигурации) е необходимо в случаите, когато не е възможно няколко потребители да работят, докато се свързват едновременно с една база данни. В наши дни това е доста рядко явление, тъй като стандартният отдалечен работен плот работи добре и има други програми, които осигуряват отдалечена връзка с централния компютър, където се намира базата данни.

Но въпреки това има ситуации, когато просто няма интернет. И данните в крайна сметка трябва да попаднат в една информационна база. Ето защо се създава разпределена база данни.

Обикновено основната база се нарича централна, а останалите се наричат периферни. Основното е, че ръчно или автоматично (в зависимост от настройките) базите данни се обединяват в една. За да се гарантира, че номерата на нововъведените документи и кодовете на указателите не се дублират, на всяка база данни се присвоява префикс.

В тази инструкция ще използваме пример за създаване на централна и периферна база данни и ще проверим обмена между тях. Това ръководство е подходящо както за 1C 8.3 Accounting, така и за 1C Trade Management (UT) и други конфигурации.

Настройка на основната (централна) разпределена RIB база данни

Нека отидем в менюто „Администриране“ на 1C, след което щракнете върху връзката „Настройки за синхронизиране на данни“. В прозореца, който се отваря, трябва да поставите отметка в квадратчето „Синхронизиране на данни“. Връзката „Синхронизиране на данни“ ще стане активна. Точно тук ще зададем префикс за основната информационна база - например „CB“:

Щракнете върху връзката „Синхронизиране на данни“ и ще се отвори прозорец с бутон „Настройване на синхронизиране на данни“. Когато щракнете върху този бутон, ще се отвори падащ списък, където трябва да изберете режим „Пълен“. Ако се изисква синхронизация само за една организация, трябва да изберете „По организация...“.

В следващия прозорец програмата ще ни подкани да направим резервно копие. Горещо препоръчвам да направите това, тъй като следните стъпки за настройка може да са необратими.

След като създадете резервно копие, щракнете върху бутона „Напред“. На следващата стъпка трябва да решим как ще се извърши синхронизирането:

чрез локална директория или директория в локалната мрежа;
през интернет чрез FTP.

За простота и яснота на примера ще изберем локална директория. Посочих следния път: “D:\1C Databases\Synchronization”. Би било добра идея да проверите записите в тази директория; има специален бутон за това:

Вземете безплатно 267 видео урока за 1C:

Пропускаме следващите стъпки с настройка на синхронизацията чрез FTP и имейл. Нека да разгледаме настройките за имената на основните и периферните бази данни. Тук ще зададем префикса за периферната база данни:

Не забравяйте, че префиксите за всяка база данни трябва да бъдат уникални. В противен случай ще получите грешката „Стойността на префикса на първата информационна база не е уникална“.

Щракнете върху „Напред“, проверете въведената информация и щракнете отново върху „Напред“, след което върху „Край“. В полето „Пълно име на файловата база“ посочете файла 1Cv8.1CD в директорията, която е създадена за синхронизация. Създаваме първоначалното изображение на разпределената база данни 1C:

След като създадете първоначалното изображение на RIB в 1C, можете да зададете график за синхронизиране или да синхронизирате ръчно:

След синхронизацията можете да се свържете с новата база данни и да се уверите, че там е качена информация от централната база данни:

Просто веднага създайте поне един потребител с права на администратор в новата периферна база данни.

Настройка на синхронизация в периферната база данни

В периферната база данни 1C конфигурацията е много по-проста. Просто поставете отметка в квадратчето „Синхронизиране на данни“ и следвайте връзката със същото име. И почти веднага се озоваваме в прозорец с бутона „Синхронизиране“. Нека се опитаме да създадем тестов елемент в периферната база данни и да го качим в основната с помощта на RIB:

Задача: необходимо е да конфигурирате информационната база, така че трима потребители, които не са в локалната мрежа, но са свързани с интернет, да могат да работят в една работеща база данни.

Нека изпълним тази задача, като създадем разпределена информационна база. Конфигурация на информационна база – „Счетоводство на предприятието 2.0”.

Настройка на FTP ресурс.

Нека да настроим FTP, използвайки HCube като пример: Отидете на уебсайта hcube.ru. Раздел Хостинг, FTP хостинг (http://www.hcube.ru/hosting/ftp/). Избираме минималния FTP тарифен план -10, това ще бъде достатъчно за обмен между възлите на разпределената информационна база. Можете да поръчате пробен период от 15 дни, щракнете върху „Опитай“. След това трябва да се регистрираме:

Посочете потребителско име и парола за достъп до вашия личен акаунт. След като заявлението бъде прието, чакаме писмо на посочения имейл с данни за FTP достъп. Информация за конфигурацията на вашата хостинг услуга: ***************************************** ********* *********************
Вход в хостинг: user725
Парола за хостинг: ffUXP3CDU
IP адрес на хостинг: 85.10.207.234

****************************************************************
Контролен панел за FTP хостинг https://cp.hcube.ru/manager/ispmgr

Чакаме държавата да стане „Активна“.

Създаване на план за обмен.

Необходимо е да се определи централният възел на базата данни. Нека изберем работна станция, разположена в офиса като централен възел. Другите два ще комуникират с централния възел. Нека настроим централния възел. За да направите това, трябва да влезете в системата за защита на информацията като потребител с пълни права. В главното меню на програмата изберете елемента „Операции/планове за обмен...“. В плановете за обмен на стандартната конфигурация „Счетоводство на предприятието 8“ вече са създадени 7 стандартни плана за обмен: Отваряне на плана "Пълен". Съдържа един предварително дефиниран празен запис. Този запис описва текущия възел. Предопределено, т.е. Запис, добавен на ниво конфигурация, не може да бъде изтрит, но може да бъде коригиран. Щракнете върху редактиране: поле "Име"може да бъде произволно, например "Централен възел". "Код"може да бъде произволно, например "01", щракнете "ДОБРЕ". Текущият възел е описан, сега е необходимо да се опишат подчинените възли. Добавяне на нови елементи с името "възел 1"и код "02"И "Възел 2"с код "03". Получаваме три възела:
Може да има много подчинени възли в RIB и обменът ще се извършва между един централен възел и всеки от подчинените възли. Сега нека физически създадем подчинен възел (нова база данни). За да направите това, трябва да застанете на линията на възела "възел 1"и щракнете върху иконата „Създаване на първоначално изображение...“или изберете това действие от менюто:
Системата ще ви подкани да изберете вида на информационната база (ИС). Трябва да изберете „На този компютър...“. След това посочете директорията, в която ще бъде създадена новата информационна сигурност. След това в посочената директория ще бъде създадена нова база данни и всички данни от основната база данни ще бъдат прехвърлени към тази база данни. Заслужава да се отбележи веднага, че новата информационна сигурност не е точно копие на оригиналната. Има свои собствени настройки (собствен списък с потребители и т.н.), прехвърлят се само данни и модифицирани планове за обмен, т.е. в новата информационна сигурност ще има само два възела "Централен възел"И "възел 1". Ако изходната база данни е голяма и има потребители, работещи в нея, може да има сблъсъци при създаването на първоначалното изображение, така че се препоръчва операцията по създаване на ново изображение да се извърши в монополен режим.Ако в централния възел са описани няколко подчинени възела, операцията за създаване на първоначално изображение за защита на информацията трябва да се извърши за всеки възел, т.е. ще бъдат създадени толкова нови системи за информационна сигурност, колкото е броят на възлите, описани в оригиналната база данни. Ще направим същото за "Възел 2". По време на създаването на първоначалното изображение в основната база данни ще бъде създадена таблица за синхронизиране на обекти от основната база данни с този възел. По принцип такива таблици се създават според броя на подчинените възли. При създаване на първоначалното изображение на възел се задава флагът за синхронизация с възела. Сега базите данни на подчинените възли трябва да бъдат копирани на работни станции "възел 1"И "Възел 2". След това трите компютъра ще имат идентични (по данни) информационни бази.

Настройки за обмен на разпределена информационна база.

В този проблем имаме общ случай, когато и трите бази данни работят, т.е. документи се въвеждат и променят в три бази данни. Да отидем в менюто „Услуга / Разпределена информационна база (RIB) / Конфигуриране на RIB възли“. Нека да създадем обмен между Централен хъбИ Възел 1. В раздела „Разпределени информационни бази“ добавете нов елемент, да го наречем „Офис – възел 1“(където "Офис" е нашият централен център). Изберете от реквизита "възел" – "възел 1". В полето „Тип борса“избирам „Обмяна чрез FTP ресурс". Попълваме данните, които са ни изпратени по имейл: "Адрес", "Потребител", "Парола". Раздели "Интерактивен обмен"И "Автоматичен обмен"Все още не го попълваме, ще го направим след основните настройки за обмен във всички възли. След това, по аналогия, ще създадем нов елемент за настройка на обмена между централния възел и възел 2.
Да преминем към предварително създаденото първоначално изображение (информационна база) Възел 1и създайте настройки "Възел 1 - Офис". Нека направим същото във възел 2. В раздела "Интерактивен обмен"можем да определим дали трябва да качваме и изтегляме данни или само едно нещо. В раздела "Автоматичен обмен"можете да добавите нов елемент, за да конфигурирате автоматичен обмен. Тук можем да зададем график за конкретна борса, например за „Офис – възел 1“и/или обмен на базата на събития.

Когато избирате потребител в настройките за обмен на събития, трябва също да посочите този потребител в "Настройки на програмата"на раздела "Обмен на данни".
Обменът в нашия пример ще се извърши само ако базата данни е влязла, както е посочено в настройките „Обмен по събитие“потребител. Трябва също да посочите „Префикс на възел за разпределена информационна база“за правилно номериране на документите. С помощта на префикса можем да видим кой възел е създал документа и също така да избегнем дублиране на номера на документи. За удобна работа в разпределената информационна база е необходимо внимателно да се обмисли цикълът на обмен на възли помежду си, графикът за обмен и/или обменът по събития за конкретна задача.

Инструкции за създаване и конфигуриране на разпределени бази данни с помощта на компонента URDB (URIB).

Компонентът URDB (Управление на разпределена база данни) се използва за обмен на информация между две идентични бази данни 1C. Ако конфигурациите са различни, тогава можете да го използвате, това е написано в друг. За да работи компонентът, трябва да имате файла DistrDB.dll в папката BIN на програмата 1C: Enterprise.

Нека да разгледаме стъпките за създаване на разпределени бази данни. Например имаме работеща база в директорията D:\base1. Необходимо е да се направи централен и да се създаде периферна основа.

1. Създайте директория D:\base2 за периферната база данни.

2. В директориите D:\base1 и D:\base2 създайте папките CP и PC (използвайте латински букви).

3. Стартирайте конфигуратора на централната база данни (D:\base1) и изберете Меню - Администриране - Разпределена информационна сигурност - Управление.

4. Щракнете върху бутона „Централна информационна сигурност“, в появилия се прозорец въведете кода и името на базата данни. По-добре е да използвате цифри или латински букви за кода. Въведете например 001 и „Централна база“, потвърдете с натискане на бутона „ОК“.

5. Щракнете върху бутона "Нова защита на периферна информация", за да създадете периферна база данни. Въвеждаме параметрите за него: 002 и „Периферна база 1“.

6. Използвайте курсора, за да изберете базата “Peripheral base 1” и натиснете бутона “Setup”. автообмен“. В настройките сменете ръчния режим на автоматичен. Бъдете внимателни, това е важно.

7. С помощта на курсора изберете базата данни „Периферна база 1“ и натиснете бутона „Качване на данни“, след това бутона „ОК“. В резултат на качването ще се появи файлът D:\base1\CP\020.zip.

8. Стартирайте 1C в режим на конфигуратор, добавете нова база данни „Периферна база данни 1“ в прозореца за стартиране на 1C, посочете създадената преди това директория D:\base2 за нея.

9. Изберете Меню - Администриране - Разпределена информационна сигурност - Управление. На зададен въпрос „Информационната база не е открита. Искате ли да заредите данни?" Щракнете върху бутона "Да" и посочете името на файла "D:\base1\CP\020.zip", щракнете върху бутона "OK". След като изтеглянето приключи, процесът на създаване на периферна база данни може да се счита за завършен.

Във и също така са дадени методите за създаване на периферна база данни чрез възстановяване на копие на централната база данни от резервно копие или прикачване на файлове на копие на централната база данни за SQL формат и изпълнение на скрипта. Това ще бъде полезно за големи обеми данни, когато качванията и изтеглянията отнемат часове или са напълно нереалистични.

Инструкции за обмен между разпределени бази данни с помощта на компонента URDB (URIB).

Нека разгледаме опростен пример; ще извършим обмена ръчно, като стартираме конфигуратора. Можете да използвате пакетния режим на конфигуратора; можете да използвате поща, ftp и автоматично копиране на файлове, за да доставяте обменни пакети.

За да извършите обмена, трябва да изберете Меню - Администриране - Сигурност на разпределената информация - Автоматичен обмен. Ако обменът е автоматичен (вижте точка 6 от предишните инструкции), тогава всичко ще се получи.

1. И така, променяме или създаваме някои обекти, които мигрират към периферната база данни. Правилата за миграция на обекти се задават в раздела "Миграция" в свойствата на обекта (вижте дървото на обекта в конфигуратора).

2. Стартирайте конфигуратора на централната база данни, изберете Меню - Администриране - Разпределена информационна сигурност - Автоматичен обмен, щракнете върху бутона "Изпълни".

3. Преместете получения файл D:\base1\CP\020.zip в папката D:\base2\CP\

4. Променяме някои обекти в периферната база данни. За предпочитане не тези, които са били променени преди в централната база данни, т.к централната база данни има приоритет за промени в обекти по време на обмен.

5. Стартирайте конфигуратора на периферната база данни, изберете Меню - Администриране - Сигурност на разпределената информация - Автоматичен обмен, щракнете върху бутона "Изпълни".

6. В резултат на автоматичния обмен трябва да имаме промени, идващи от централната база данни. Трябва също да имаме файл за прехвърляне в централната база данни D:\base2\PC\021.zip

7. Копирайте файла D:\base2\PC\021.zip в папката D:\base1\PC

8. Повторете точка 2. В резултат на това промените, получени от периферната база данни, ще се появят в централната база данни.

И така, общият принцип на обмен: алтернативно изпълнение на автоматичен обмен с едновременно преместване на файлове (пакети за обмен) от папката PC на една база данни в папката PC на друга база данни и от папката CP на една база данни в папката CP на друга база данни.

Промените в конфигурацията се правят само в централната база данни. При промяна на конфигурацията е необходимо да се извърши обменът в периферните бази данни в изключителен режим. За успешна обработка на пакети от периферни бази данни в централната база данни, конфигурацията трябва да бъде заредена в периферните бази данни. Ако се объркате, няма проблем, пакетът, отхвърлен от централната база данни, ще бъде изтеглен отново.

Този материал съдържа подробни инструкции за настройка на обмена на RIB за 1C:Enterprise 8 и проблемите, които авторът е срещнал.

1. Създаване на възли
Създаваме нови възли (главен и подчинен): в потребителски режим „Операции / Планове за обмен / Пълен“
Да изберем плана за обмен "Пълен"
Създаваме два записа:
- нека наречем първия запис "CB" (главен възел), посочете кода "CB",
- нека наречем втория запис „Подчинен възел“, посочете кода „PU“.
Икона със зелен кръг - "CB" (основен възел)

За подчинения възел щракнете върху иконата „Създаване на първоначално изображение“. (Изисква изключителен достъп)
Създайте начално изображение
След това в прозореца, който се отваря, попълнете параметрите на новата база данни. Когато приключите, щракнете върху бутона „Край“.
Създаване на първоначално изображение за защита на информацията
Създаването на първоначалния образ на подчинения възел на разпределената информационна база ще започне и след завършване ще се появи съобщението „Създаването на първоначалния образ е успешно завършено“. Кликнете върху бутона "OK".
Добавяме базата на подчинения възел към списъка с бази и я стартираме.
В тази подчинена база данни отваряме пълния план за обмен - иконата „CB“ е червена, това означава, че този възел е основният възел за информационната база, в която се намираме.

2. Настройване на префикси
За всяка база данни в настройките на счетоводните параметри (в UPP „Услуга / Счетоводни параметри“) в раздела „Обмен на данни“ задаваме префикси. Това се прави, за да няма конфликти в номерата и кодовете на документите и справочниците, създадени в две бази данни.
За автоматичен обмен поставете отметка в квадратчето „Използване на механизъм за автоматичен обмен...“
Раздел „Обмен на данни“

3. Добавяне на настройка за обмен на данни между възлите
Отворете: "Услуга\Разпределена информационна база (RIB)\Конфигуриране на RIB възли"
Щракнете върху „Добавяне“ и ще се отвори прозорецът „Настройки за обмен на данни“.
Настройка на обмен на данни

Кликнете върху иконата "Обмен според текущите настройки".
Извършете обмена според текущата настройка

Сега за клопките
1. Обменът на данни може да се извършва автоматично и може да бъде иницииран в следните случаи:
* При стартиране на програмата. Обменът ще се извърши, когато програмата започне,
* Когато приключите работата с програмата. Обмяната ще се извърши преди потребителят да приключи работата с програмата,
* Когато се появи каталогът. Обменът ще се извърши само ако указаната от потребителя директория е била невидима, но сега е станала видима. Настройката може да се използва за извършване на автоматичен обмен при свързване към локална мрежа или флаш карта. Програмата периодично ще проверява видимостта на директорията, посочена в настройките, и ще отбелязва текущото й състояние,
* Когато файлът се появи. Препоръчително е да използвате режим на данни, когато трябва да обмените, ако се появи входящ файл за обмен на данни. В този случай е достатъчно да посочите пълния път до входящия файл за обмен на данни. Програмата периодично анализира наличието на файла и веднага щом се появи, обменът ще бъде извършен и след обмена този файл ще бъде принудително ИЗТРИТ (това се прави, за да не се извършва процедурата за обмен постоянно),
* Периодичен обмен на данни. Обменът ще се извършва според настройките за периодичен обмен на данни. Ако информационната база работи в режим на файлов сървър, тогава периодичният обмен се извършва само за потребителя, който е посочен в настройките на счетоводната политика като „Потребител за рутинни задачи в режим на файл“. Във версията клиент-сървър обменът се извършва на сървъра на 1C:Enterprise.

Имам опция клиент-сървър - за да работи рутинният автоматичен обмен, трябваше да претоваря сървъра

2. Windows кодиране.
Обменът беше прекъснат от грешка, защото файлът не беше компресиран. Това се дължи на грешка на кирилицата в командния ред по време на компресиране.
Може да се лекува чрез коригиране на кодировките в системния регистър.
Например за Windows Server 2008 -
Код

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. При създаване на копие на базата данни (например за модификация) във версия клиент-сървър е НЕОБХОДИМО РУТИННИТЕ ЗАДАЧИ НА КОПИЕТО НА БАЗАТА ДАННИ да са ИЗКЛЮЧЕНИ. Блокиране на рутинни задачи за копиране ВКЛ

Ако не са блокирани, тогава копието ще извършва обмен по същия график като основната база данни. Това означава, че някои съобщения до отдалечени възли ще бъдат генерирани от работещата база данни, а някои от копие, което ще доведе до десинхронизиране на конфигурациите.