1с риб создать начальный образ. Инструкция по настройке Распределенной информационной базы (РИБ) через FTP ресурс. Базовые принципы работы РИБ

В 1с 8.3 или в 1С 8.2? Настройка распределенной информационной базы. Пошаговая инструкция.

Распределение информационной базы применяется при необходимости ведения совместного учета в базах данных, которые не могут, в силу различных причин, иметь физического соединения. Примером может служить ведение учета в одной фирме, имеющей подразделение в большом городе и маленьком поселке без возможности подключения сети интернет. Или в некоторых частных случаях периодической необходимости одновременной работы с одной базой данных в офисе и вне офиса, например дома. В таких и им подобных случаях применение распределенной информационной базы (РИБ) оправдано и необходимо.

В данной статье мы рассмотрим организацию распределения одной информационной БД в конфигурации 1С Бухгалтерия для России версии 8.3 через локальный или сетевой каталог. В версии 8.2 1С данная инструкция также будет полезна, т.к. описывает по сути один процесс с существенно малыми отличиями.

==== Настройка для главной базы ====

Открыв 1С 8.3 в режиме «Предприятие» перейдем в раздел «Администрирование». В версии 1С 8.2 для начала работы нужно перейти в главном меню «Сервис» — «Распределенная информационная база (РИБ)» — «Настроить узлы РИБ».

Далее будем рассматривать процесс в контексте ИБ версии 8.3. Итак, перейдя в раздел «Администрирование», выберем «Настройка программы». В настройках зайдем в раздел «Синхронизация данных». Здесь ставим галочку «Использовать синхронизацию данных» и указываем префикс базы данных. Укажем «ЦБ», подразумевающий центральную базу.

После этого в правом меню появляется пункт «Синхронизация данных». Выберем его. В открывшемся дочернем окне нажимаем кнопку «Настроить синхронизацию данных». В выпадающем меню можно выбрать варианты настроек под различные случаи использования синхронизации. Мы выбираем «Распределенная информационная база…».

Для общего развития знакомимся содержимым следующего окна и нажимаем «Далее».

В следующем окне заполняем каталог, через который будет проходить . Укажем сжатие данных для сокращения размеров выгрузки и тут же можно указывать пароль на архив с данными. Важно его не забыть. Подтверждаем заполнение кнопкой «Далее».

Следующие два окна предназначены для указания параметров настроек для случаев обмена через сервер FTP и через электронную почту. Как указывалось ранее, мы рассматриваем способ обмена через каталог, поэтому настройки для FTP и email пропускаем.

Следующее окно предназначено для указания параметров обмена в части периферийной базы данных. Укажем ее название и префикс. Далее — кнопка «Далее».

Проверим сформированные нами параметры обмена и подтвердим их правильность традиционной кнопкой «Далее».

Автоматически будет создан необходимый набор настроек для обмена. Это займет некоторое время.

Важно! Создание начального образа для подчиненного узла занимает значительное время. Размер этой значительности зависит от ресурсов компьютера и объемов учета в главной базе данных.

Предположим, что мы решили создать образ. После нажатия на кнопку «Готово» в предыдущем окне, введем настройки для создания образа подчиненной ИБ. Мы рассмотрим простейший случай для локальных операций. Для этого укажем нужные реквизиты в открывшемся окне. Особо обратим внимание на параметр «Полное имя файловой базы». Его необходимо указывать в полном формате UNC, который предполагает формирование и локального пути в «сетевом» формате. Например — «\\Server1C\Databases\RIB». К указанному пути добавим наименование файла БД — 1Cv8.1CD.

После нажатия на кнопку «Создать начальный образ» стартует процесс генерации образа для подчиненной базы.

После окончания процесса в указанном каталоге будет создан файл БД. Эту, вновьсозданную базу перед полноценным использованием нужно настроить.

==== Настройка для периферийной базы ====

Для этого ее нужно подключить к 1С. Как это сделать вы найдете в инструкции в нашей статье — После подключения, новую базу нужно запустить в режиме конфигуратора и создать пользователей. Далее ИБ нужно запустить в режиме 1С «Предприятие».

Если, по какой-либо причине, создание пользователей нужно перенести на более позднее время, можно после подключения просто запускать базу в режиме 1С «Предприятие». Будет предложено создание пользователя «Администратор», согласитесь с ним, и будет выполнено начальное заполнение.

Затем нужно продолжить настройку сопряжения с главной базой. Эта настройка подобна рассмотренной выше для главной базы.

Будет создана настройка для связи с главной базой.

============================================

Итак, теперь у нас созданы главная и периферийная базы. Также созданы настройки синхронизации в каждой из этих баз данных. Теперь можно перейти к редактированию этих настроек и приведению их в подходящий вид. Можно создать правила автоматического обмена или выполнять обмен вручную.

Сделаем это в главной базе данных. Периферийная база настраивается аналогично.

Редактирование можно применить к правилам и расписанию синхронизации данных.

По кнопке «Настроить» в разделе «Расписание синхронизации данных», нужно отредактировать сценарии для автоматического распорядка работы по выгрузке/загрузке данных для выбранной базы. Можно и не редактировать, просто согласившись с предложенными по умолчанию вариантами.

Для редактирования параметров достаточно кликнуть по ссылке с данными автоматического расписания. И далее редактируем временные параметры запуска заданий. Переходя по закладкам можно изменять как время, так и даты и дни недели запуска.

По кнопке «Выполнить задание» главного окна сценариев можно выполнить ручной запуск задания.

По кнопке «Настроить» раздела «Правила синхронизации данных» можно выполнять операции по изменению сценариев запуска заданий, а также просматривать журнал выполнения выгрузок/загрузок. Последнее достаточно важно для администрирования доступов и отслеживания регулярности обменов.

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

На этом, в основном, настройка распределенной базы банных для центрального и периферийного узла окончены.

Скачать иллюстрированную инструкцию

Распределенная информационная база. Пошаговая инструкция
Распределенная Информационная База (РИБ) 1С:Преприятие
Создание распределенной информационной базы и ее настройка
как настроить риб в 1с 8.2
Как настроить распределенную информационную базу в 1С
Как настроить в 1С
Как настроить в 1С
Настройка распределенной информационной базы (РИБ) в 1С
Пример настройки РИБ для 1С:Бухгалтерии 8
Создание распределенной информационной базы и настройка

Технология распределенных информационных баз (РИБ) позволяет создать территориально распределенную систему на базе конфигураций 1С Предприятие. Это позволяет иметь общее информационное пространство даже с теми подразделениями, которые не имеют надежного канала связи, сочетая высокую автономность узлов с возможностью оперативного обмена информацией. В наших статьях мы рассмотрим особенности и практическую реализацию этого механизма на платформе 8.2

Прежде всего зададимся вопросом: почему именно автообмен? Современные технологии, в сочетании с недорогим и быстрым интернетом, позволяют организовать удаленную работу без каких либо затруднений. Выбор способов как никогда широк: RDP, тонкий и веб-клиенты, объединение сетей при помощи VPN - есть над чем задуматься. Однако все эти способы имеют один существенный недостаток - сильная зависимость от качества канала связи.

Даже при идеальной работе местного провайдера гарантировать 100% доступность канала связи невозможно. Проблемы у магистрального провайдера, отсутствие электроснабжения, физическое повреждение линии связи и многие другие факторы делают эту задачу неразрешимой. В тоже время недоступность информационной базы на удаленном складе или в розничном магазине приводит к вполне ощутимым убыткам. Ну и наконец не будем забывать, что есть места (например промзоны на окраине городов) в которые подвести качественный канал связи дорого и/или проблематично.

Механизм РИБ позволяет избавиться от указанных недостатков, каждое подразделение имеет собственный экземпляр информационной базы с которой можно работать автономно даже при полном отсутствии связи с внешним миром. А небольшой объем передаваемой информации позволяет использовать для обмена любой канал связи, в том числе мобильный интернет.

РИБ на платформе 8.2 не является чем-то принципиально новым, представляя собой дальнейшее развитие УРИБ платформы 7.7, только теперь эта технология стала доступней и проще. В отличии от компоненты УРИБ, которую нужно было приобретать отдельно, РИБ является неотъемлемой частью многих типовых конфигураций и работает полностью в пользовательском режиме, позволяя обойтись без Конфигуратора даже на этапе настройки.

На этом месте пора бы было перейти к практической части, но придется сделать еще одно отступление. Дело в том, что переход на платформу 8.2, который вроде бы уже произошел, по факту привел к появлению двух типов конфигураций: на основе управляемого приложения, "родные" для платформы 8.2, и адаптированные с 8.1, продолжая использовать устаревшие технологии и механизмы. Так как существенная часть конфигураций (Бухгалтерия предприятия, Зарплата и управление персоналом) являются адаптированными или переходными, то сбрасывать их со счетов нельзя, поэтому первая часть нашей статьи будет посвящена этим конфигурациям (по сути платформе 8.1), в то время как во второй мы разберем настройку автообмена для конфигураций на основе управляемого приложения (платформе 8.2).

Рассмотрим практическую задачу: настроить автообмен через FTP для конфигурации Бухгалтерия предприятия 2.0. Несмотря на то, что РИБ позволяет производить обмен с использованием электронной почты или общих файловых ресурсов, мы рекомендуем использовать именно FTP, как наиболее простой и надежный способ связи. Как настроить собственный FTP-сервер вы можете прочитать в , либо можно использовать FTP сервис любого хостинг провайдера.

В первую очередь нам нужно настроить узлы обмена. Для этого запустим конфигурацию с правами администратора и выберем Операции - Планы обмена.

В появившемся списке выберем Полный план или По организации , если в одной базе ведется учет по нескольким фирмам и обмен нужно производить только для одной из них. В открывшемся окне уже существует один узел - центральный, нам нужно его отредактировать, указав код и название.

После чего создадим еще один узел для филиала, заполнив его аналогичным образом (для добавления нажмите зеленый кружок с плюсом). Следующим шагом будет создание начального образа для данного узла, который представляет собой готовую информационную базу в файловом режиме. Для этого кликните правой кнопкой мыши на нужном узле и в выпадающем списке выберите Создать начальный образ .

Теперь перейдем Сервис - Распределенная информационная база (РИБ) - Настроить узлы РИБ .

В открывшемся окне нажмите кнопку Добавить и настройте новый обмен, указав удаленный узел, тип обмена (через FTP) и параметры подключения к серверу.

Закладка Автоматический обмен позволяет настроить расписание обменов, обмен по событиям (начало и завершение работы и т.п.), данные настройки производятся для пользователя от чьего имени будет выполняться обмен, поэтому убедитесь в наличии у него прав для обмена данными.

Не забудьте указать префикс узла для нумерации документов (иначе вы получите разные документы с одинаковыми номерами) в Сервис - Настройки программы, здесь же можно настроить и некоторые другие параметры обмена. На этой же закладке следует выбрать пользователя для выполнения заданий обмена, если вы этого не сделаете расписание работать не будет. Помните, что обмен будет производиться только в том случае, если данный пользователь выполнил вход в программу.

На этом настройка центрального узла закончена, теперь нужно произвести аналогичные настройки для периферийного узла, подключив начальный образ как существующую ИБ. После чего можно приступать к обмену данными. Для контроля следует воспользоваться Монитором обмена данными , он позволяет не только контролировать успешность прохождения выгрузки/загрузки, но и показывает возникшие коллизии или отложенные движения (если пользователю производившему обмен не хватает прав для совершения каких либо действий в базе). Наличие данного инструмента позволяет быстро и эффективно решать различного рода проблемы, возникающие при автообмене.

На этом настройку обмена можно считать законченной и приступать к работе в распределенном режиме. Отдельно стоит остановиться на обновлении или внесении изменений в конфигурацию. Эти действия доступны только на центральном узле, все внесенные изменения будут автоматически распространены на периферийные узлы при следующем обмене. Для автоматического внесения изменений требуется чтобы периферийная база находилась в монопольном режиме, в противном случае нужно будет запустить Конфигуратор и выполнить Обновление конфигурации базы данных вручную.

Создание и настройка распределенной базы данных (РИБ) в 1С 8.3 Бухгалтерия (и других конфигурациях) необходимы в случаях, когда нет возможности работать нескольким пользователям, одновременно подключаясь к одной базе данных. В настоящее время это довольно редкое явление, так как прекрасно работает стандартный удаленный рабочий стол и есть другие программы, которые обеспечивают удаленное подключение к центральному компьютеру, где расположена база данных.

Но тем не менее бывают ситуации, когда просто-напросто нет интернета. А данные должны в итоге оказаться в одной информационной базе. Для этого и создается распределенная база данных.

Обычно главную базу называют центральной, а остальные — периферийными. Суть в том, что либо в ручном, либо в автоматическом режиме (зависит от настройки) базы данных объединяются в одну. Чтобы номера вновь введенных документов и коды справочников не дублировались, каждой базе данных назначается префикс.

В этой инструкции мы на примере создадим центральную и периферийную базы данных, проверим обмен между ними. Это пособие подойдет как для 1С 8.3 Бухгалтерия, так и для 1С Управление торговлей (УТ) и других конфигураций.

Настройка главной (центральной) распределенной базы РИБ

Зайдем в меню 1С «Администрирование», далее по ссылке «Настройки синхронизации данных». В открывшемся окне нужно установить флажок «Синхронизация данных». Станет активной ссылка «Синхронизация данных». Сразу здесь же установим префикс для главной информационной базы – например, «ЦБ»:

Заходим по ссылке «Синхронизация данных», откроется окно с кнопкой «Настроить синхронизацию данных». При нажатии на эту кнопку откроется выпадающий список, где нужно выбрать режим «Полный». Если требуется синхронизация только по одной организации, нужно выбрать «По организации…».

В следующем окне нам программа предложит сделать резервную копию. Настоятельно рекомендую сделать это, так как следующие шаги настройки могут быть необратимы.

После создания резервной копии нажимаем кнопку «Далее». На следующем шаге нам следует определиться, как будет происходить синхронизация:

• через локальный каталог или каталог в локальной сети;
• по интернету посредством FTP.

Для простоты и наглядности примера выберем локальный каталог. Я указал следующий путь: «D:\Базы 1С\Синхронизация». Не лишней будет проверка записи в данный каталог, для этого есть специальная кнопка:

Получите 267 видеоуроков по 1С бесплатно:

Следующие шаги с настройкой синхронизации по FTP и электронной почте пропускаем. Останавливаемся на настройках названий главной и периферийной баз данных. Здесь же зададим префикс для периферийной базы:

Не забывайте, что префиксы каждой базы должны быть уникальны. В противном случае Вы получите ошибку «Значение префикса первой информационной базы не уникально».

Жмем «Далее», проверяем введенную информацию и опять нажимаем «Далее», затем — «Готово». В поле «Полное имя файловой базы» указываем файл 1Cv8.1CD в каталоге, который создали для синхронизации. Создаем начальный образ распределенной базы 1С:

После создания начального образа РИБ в 1С можно задать расписание синхронизации или синхронизировать вручную:

После синхронизации можно подключиться к новой базе данных и убедиться, что туда выгрузилась информация из центральной базы:

Только сразу в новой периферийной базе заведите хотя бы одного пользователя с правами Администратора.

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

В периферийной базе 1С настройка намного проще. Достаточно установить флажок «Синхронизация данных» и перейти по одноименной ссылке. И мы почти сразу попадаем в окно с кнопкой «Синхронизировать». Попробуем создать тестовую номенклатуру в периферийной базе и выгрузить ее в основную с помощью РИБ:

Инструкция по созданию и настройке распределенных баз с помощью компоненты УРБД (УРИБ)

Компонента УРБД (Управление распределенными базами данных) применяется для обмена информацией между двумя идентичными базами 1С. Если конфигурации разные, то применять ее также можно, об этом написано в другой . Для работы компоненты необходимо наличие файла DistrDB.dll в папке BIN программы 1С: Предприятие.

Рассмотрим действия по созданию распределенных баз данных. Например, у нас есть рабочая база в каталоге D:\base1. Требуется сделать ее центральной и создать периферийную базу.

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

2. В каталогах D:\base1 и D:\base2 создаем папки CP и PC (используем латинские буквы).

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

4. Нажимаем кнопку "Центральная ИБ", в появившемся окне вводим код и наименование базы. Для кода лучше использовать цифры или латинские буквы. Вводим, например, 001 и "Центральная база", подтверждаем нажатием кнопки "ОК".

5. Нажимаем кнопку "Новая периф. ИБ" для того чтобы создать периферийную базу. Вводим для нее параметры: 002 и "Периферийная база 1".

6. Курсором выделяем базу "Периферийная база 1" и нажимаем кнопку «Настр. автообмена». В настройках меняем ручной режим на автоматический. Будьте внимательны, это важно.

7. Курсором выделяем базу "Периферийная база 1" и нажимаем кнопку «Выгрузить данные», затем кнопку "ОК". В результате выгрузки появится файл D:\base1\CP\020.zip.

8. Запускаем 1С в режиме конфигуратора, добавляем в окне запуска 1С новую базу "Периферийная база 1", указываем для нее ранее созданный каталог D:\base2.

9. Выбираем Меню - Администрирование – Распределенная ИБ – Управление. На заданный вопрос «Информационная база не обнаружена. Выполнить загрузку данных?» нажимаем кнопку "Да" и указываем имя файла "D:\base1\CP\020.zip", нажимаем кнопку "ОК". После окончания загрузки процесс создания периферийной базы можно считать законченным.

В и еще в приведены способы создания периферийной базы путем восстановления из бэкапа копии центральной базы либо приаттачивания файлов копии центральной базы для формата SQL и выполнения скрипта. Это будет полезно при больших объемах данных, когда выгрузки-загрузки растягиваются на часы или вообще нереальны.

Инструкция по обмену между распределенными базами с помощью компоненты УРБД (УРИБ)

Рассмотрим упрощенный пример, выполнять обмен будем вручную, запуская конфигуратор. Можно использовать пакетный режим конфигуратора, для доставки пакетов обмена можно использовать почту, 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 другой базы.

Изменение конфигурации производится только в центральной базе. При изменении конфигурации необходимо проведение обмена в периферийных базах в монопольном режиме. Для успешной обработки пакетов из периферийных баз в центральной базе конфигурация должна быть загружена в периферийные базы. Если вы запутались - ничего страшного, отвергнутый центральной базой пакет выгрузится повторно.

October 25th, 2016

Между настройкой и поддержкой РИБ на 2 узла и на 10 большой разницы нет, а вот когда число удаленных точек переваливает за сотню, приходится решать уже совсем другие вопросы

Исходные данные:

Конфигурация: Розница 2.2
Платформа 1С: 8.3.7.1970



Срок проекта: год.



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

Сперва определились со схемой РИБ. Было принято решение ориентироваться на схему "звезда", пока это будет возможно; при достижении технологических ограничений - снежинка.





Ограничния:
- 2 ГБ ОЗУ
- 1 физический процессор


Из всего вышеперечисленного напрягает в осном ограничение на максимальный объём БД.

Но это всего лишь означает что нужно гработно организовать процедуру её очистки от устаревших данных на местах.

Под сервер 1С и MS SQL выделяется отдельный физичский сервер. На него будет ложиться основная нагрузка по обменам и проведению длительных операций.
Конечные клиентские компьютеры не заменяются, потому как будут работать с тонким клиентом и нагрузка на них будет минимальной.
.


Основные настройки

Со времен УТ 10.3, на которой у меня состоялся первый проект внедрения РИБ на 60 узлов, конечно "утекло много воды".

1С не стояли на месте. Розница 2.2 теперь учитывает необходимость выборочной выгрузки данных.
В базу магазина будет выгружаться только та информация которая имеет к нему отношение:
- Все справочники (кроме специализированных)
- Документы по данному магазину

Другой вопрос что так или иначе добавление узла в базу означает добавление ещё одной записи в таблицу регистрации на каждый общий элемент при его записи.





1) Нужно разделить на отдельные сценарии синхронизации на выгрузку и загрузку
Смысл в том, что выгрузка проходит долго и с блокировками, а загрузка достаточно беспроблемно. При этом часто бывает что данные нам нужно оперативно получать из розничных точек, отдавая при этом только несколько раз в день.

2) Выделить проблемные магазины и убрать их из общего сценария синхронизации. На них могут быть большие выгрузки - тормозиться при этом будет весь обмен, включая другие узлы. После решения проблем они доабвляются обратно

3) Создать несколько сценариев отправки и получения данных. Но тут главное поймать правильный баланс их количества.
(ещё с версии 8.1).
Следовательно параллельность в выгрузке РИБ ограничена. На практике получается запускать параллельно 2-3 сценария.


Что пришлось доработать

Самый главный косяк в штатной логике 1С РИБ - это обновления

Ещё одной проблемой обмена становятся регистры сведений. Выгрузка в XML каждой записи регистра сведений создаёт отдельный узел XML со служебными элементами и т.п.. Кроме того, функция "ВыбратьИзменений()" для регистра сведений в котором 100 записей получит результирующую таблицу в 100 строк, в то же время, есдли это справочник у которого 100 строк в табличной части выберется только одна запись. А это время монопольной блокировки. Так что если в РС много записей, которые регулярно регистрируются к обмену в другие магазины то это конечно правильне представить в виде справочника с табличной частью, который в крайнем случае при записи может формировать строки этого же регистра. В любом случае, .

Ещё одна важная деталь - Зачем? Дисконтных карт скопилось уже близко к 3 млн. Для работы с ними используется внешняя online система. Если продолжать передавать дисконтные карты на все магазины - это в разы увеличит обмены, кроме того может привести к превышению базой объёма в 10 ГБ.

Часть механизмов реализована online обращением в центральную базу: остатки в других магазинах, возврат по чеку из другого магазина, проверка валидности подарочного сертификата.


Тиражирование


Создание начального узла РИБ штатным образом сделало бы невозможным тиражирование в принципе.
Поэтому новый узел создаётся следующим образом :


2) Эта база обменивается в РИБ всеми общими данными но не получает специализированных (документов)


5) База для магазина готова.

На сервер разворачивается уже готовый пакет ПО, поэтому много врмени это не занимает. Потом на сервер заливается вновь созданная база и он готов для отправки в магазин.


Преимущества тонкого клиента

Два существенных преимущества Розницы 2.2 (Тонкого клиента) которые "согрели душу":








Поддержка и обновления




1) Обновлять руками магазинов (не очень правильно, могут не получить изменения, будут звонки и проблемы) -так было ранее

3) Написать *.cmd или 1С скрипт для обновления или взять готовый. Как показывает практика такое решение всегда половинчатое (нестабильное), а функциональности в нём получится заложить немного.

Какие у нас были задачи:


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








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




4) Проверка состояния агентов
5) Отчеты об обновлениях
6) резервное копирование

















Вот так, к примеру, выглядит сообщение об ошибке после обновления:

Таким образом у проекта появились неплохие шансы быть завершенным успешно. По крайней мере на середине пути "полёт нормальный".

Если придём ещё к каким-либо решениям которые могут показаться интересными напишу отдельно

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

October 25th, 2016

Между настройкой и поддержкой РИБ на 2 узла и на 10 большой разницы нет, а вот когда число удаленных точек переваливает за сотню приходится решать уже совсем другие вопросы.

Итак, исходные данные:

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

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

Сперва определились со схемой РИБ. Было принято решение ориентироваться на схему "звезда", до той
В торговых точках используется клиент-серверный вариант работы, с выделенным сервером, под управлением ОС Windows.
Сервер 1С будет использован в варианте "Сервер 1С МИНИ" https://1c.ru/news/info.jsp?id=17577
Сервер СУБД - MS SQL Express 2008 R2.

SQL Express 2008 R2 - последняя на текущий момент времени версия данной линейки SQL Server.
Ограничния:

2 ГБ ОЗУ
- 1 физический процессор
- 10 ГБ максимальный объём базы

Из всего вышеперечисленного напрягает конечно в осном ограничение на максимальный объём БД. Но собственно это всего лишь означает что нужно будет гработно организовать процедуру её очистки от устаревших данных на местах.

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

Основные настройки

Со времен УТ 10.3 на которой у меня состоялся первый проект внедрения РИБ на 60 узлов конечно "утекло много воды". 1С не стояли на месте. Розница 2.2 теперь учитывает необходимость выборочной выгрузки данных.
В базу магазина будет выгружаться только та информация которая к немиу имеет отношение:
- Все справочники (кроме отдельных)
- Документы по данному магназину
Регистрация данных происходит по правилам регистрации, всё что можно кэшируется. Существенных замедлений именно на регистрации не наблюдается.
Другой вопрос что так или иначе добавление узла в базу означает добавление ещё одной записи на каждый общий элемент для всех баз.

В настройке самой выгрузки ничего специфичного нет. Есть некоторые нюансы принастройке сценариев синхронизации:

1) Нужно разделить на отдельные сценарии синхронизации выгрузку и загрузку
Смысл в том, что выгрузка проходит долго и с блокировками, а загрузка достаточно безпроблемно. При этом часто бывает что данные нам нужно оперативно получать из розничных точек, отдавая при этом только несколько раз в день.

2) Выделить проблемные магазины и убрать их из общего сценария синхронизации. На них могут быть большие выгрузки - тормозиться при этом будет весь обмен, включая другие узлы

3) Создать несколько сценариев отправки и получения для отправки и получения данных. Но тут главное баланс.
Некоторые вещи в 1С не меняются. Тот самый метод "ВыбратьИзменения" может выполняться только последовательно (ещё с версии 8.1).
Следовательно параллельность в выгрузке РИБ ограничена. На практике получаетсы выгружать единовременно 2-3 сценария.
Что касается сценариве получения - тут возможна куда большая параллельность, если нужна конечно.

Что пришлось доработать

Конечно грустно и печально, но пришлось основательно влазить в БСП. Самый главный косяк в штатной логике 1С - это обновления . После обновления появляется примерно такое окошко:

Это всё происходит в монопольном режиме. Кроме всего прочего, система ещё будет пытаться сделать обмен после обновления в монопольном режиме. К чему это все приводит - не трудно догадаться.
Весь этот период времени магазин не может работать, на кассе стоят покупатели, компания теряет деньги.

Ещё одной проблемой обмена становятся регистры сведений. Выгрузка в XML каждой записи регистра сведений создаёт отдельный узел XML со служебными элементами и всем отсюда вытекущим. Кроме того, функция "выбрать изменения" для регистра сведений в котором 100 записей результирующая таблица будет содержать 100 строк, в то же время, есдли это справочник у которого 100 строк в табличной части выберется только одна запись. Так что если в РС много записей, которые регулярно регистрируются к обмену в другие магазины то это конечно правильне представить в виде справочника с табличной частью, который в крайнем случае при записи может формировать записи этого же регистра. В любом случае, регистры сведений в обменах - это зло .

Ещё одна важная деталь - из обмена польностью исключены дисконтные карты, а физлица - только сотрудники конкретного магазина. Зачем? Дисконтных карт скопилось уже близко к 3 млн. Для работы с ними используется внешняя online система. Если продолжать передавать дисконтные карты на все магазины - это в разы увеличит обмены, кроме того может привести к превышению базой объёма в 3ГБ.

Часть механизмов реализована online обращением в центральную базу: остатки в других магазинах, возврат по чеку из другого магазина, проверка валидности подарочного сертификата.

Тиражирование

Конечно тиражирование ведётся ускоренными темпами.
Создание начального узла РИБ штатным образом конечно сделало бы невозможным тиражирование.
Поэтому новый узел создаётся следующим образом:

1) Существует отдельная база с фейковым магазином
2) Эта база обменивается в РИБ всеми общими данными но не получает специализированных
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) Закрытие всех клиентских приложений 1С на компьютерах сети
9) Статическое обновление с акцептом на главной кассе
10) Отображение описания модификаций после обновления
11) Настройка порядка действий
12) Выполнение всех этих действий по расписанию

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

Где MU Агент - это служба, устанавливается и настраивается в магазине. Собственно она с центра получает команда на выполнение определенных дланных.
MU Сервер - Сервер, который принимает все запросы к системе.
MU монитор - то что видят рядовые сотрудники технической поддержки - используется для просмотра логов и постановки заданий на обновление, либо прочих.

Получилось весьма неплохо, на мой взгляд. Теперь обновления проходят практически в автоматическом режиме.
Вот так, к примеру, выглядит сообщение об ошибке после обновления остались в центром всё ждёт.

А вот таким образом мы осуществляем отправку команд на клиенсткие компьютеры

Приложения конечно не 1С-ные, но с достаточно приличным набором интерфейсных возможностей. Вот так, к примеру, выглядит отбор по дате:

Теперь к дальнейшему тиражированию готовы. Правльное планирование дальнейшей поддержки - один из ключевых факторов дальнейшего успеха подобных проектов.