Распределенная информационная база. Пошаговая инструкция и подводные камни. Распределенная информационная база: Основы Формирование пакетов обновлений
Инструкция по созданию и настройке распределенных баз с помощью компоненты УРБД (УРИБ)
Компонента УРБД (Управление распределенными базами данных) применяется для обмена информацией между двумя идентичными базами 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 другой базы.
Изменение конфигурации производится только в центральной базе. При изменении конфигурации необходимо проведение обмена в периферийных базах в монопольном режиме. Для успешной обработки пакетов из периферийных баз в центральной базе конфигурация должна быть загружена в периферийные базы. Если вы запутались - ничего страшного, отвергнутый центральной базой пакет выгрузится повторно.
Создание и настройка распределенной базы данных (РИБ) в 1С 8.3 Бухгалтерия (и других конфигурациях) необходимы в случаях, когда нет возможности работать нескольким пользователям, одновременно подключаясь к одной базе данных. В настоящее время это довольно редкое явление, так как прекрасно работает стандартный удаленный рабочий стол и есть другие программы, которые обеспечивают удаленное подключение к центральному компьютеру, где расположена база данных.
Но тем не менее бывают ситуации, когда просто-напросто нет интернета. А данные должны в итоге оказаться в одной информационной базе. Для этого и создается распределенная база данных.
Обычно главную базу называют центральной, а остальные — периферийными. Суть в том, что либо в ручном, либо в автоматическом режиме (зависит от настройки) базы данных объединяются в одну. Чтобы номера вновь введенных документов и коды справочников не дублировались, каждой базе данных назначается префикс.
В этой инструкции мы на примере создадим центральную и периферийную базы данных, проверим обмен между ними. Это пособие подойдет как для 1С 8.3 Бухгалтерия, так и для 1С Управление торговлей (УТ) и других конфигураций.
Настройка главной (центральной) распределенной базы РИБ
Зайдем в меню 1С «Администрирование», далее по ссылке «Настройки синхронизации данных». В открывшемся окне нужно установить флажок «Синхронизация данных». Станет активной ссылка «Синхронизация данных». Сразу здесь же установим префикс для главной информационной базы – например, «ЦБ»:
Заходим по ссылке «Синхронизация данных», откроется окно с кнопкой «Настроить синхронизацию данных». При нажатии на эту кнопку откроется выпадающий список, где нужно выбрать режим «Полный». Если требуется синхронизация только по одной организации, нужно выбрать «По организации…».
В следующем окне нам программа предложит сделать резервную копию. Настоятельно рекомендую сделать это, так как следующие шаги настройки могут быть необратимы.
После создания резервной копии нажимаем кнопку «Далее». На следующем шаге нам следует определиться, как будет происходить синхронизация:
- через локальный каталог или каталог в локальной сети;
- по интернету посредством FTP.
Для простоты и наглядности примера выберем локальный каталог. Я указал следующий путь: «D:\Базы 1С\Синхронизация». Не лишней будет проверка записи в данный каталог, для этого есть специальная кнопка:
Получите 267 видеоуроков по 1С бесплатно:
Следующие шаги с настройкой синхронизации по FTP и электронной почте пропускаем. Останавливаемся на настройках названий главной и периферийной баз данных. Здесь же зададим префикс для периферийной базы:
Не забывайте, что префиксы каждой базы должны быть уникальны. В противном случае Вы получите ошибку «Значение префикса первой информационной базы не уникально».
Жмем «Далее», проверяем введенную информацию и опять нажимаем «Далее», затем — «Готово». В поле «Полное имя файловой базы» указываем файл 1Cv8.1CD в каталоге, который создали для синхронизации. Создаем начальный образ распределенной базы 1С:
После создания начального образа РИБ в 1С можно задать расписание синхронизации или синхронизировать вручную:
После синхронизации можно подключиться к новой базе данных и убедиться, что туда выгрузилась информация из центральной базы:
Только сразу в новой периферийной базе заведите хотя бы одного пользователя с правами Администратора.
Настройка синхронизации в периферийной базе данных
В периферийной базе 1С настройка намного проще. Достаточно установить флажок «Синхронизация данных» и перейти по одноименной ссылке. И мы почти сразу попадаем в окно с кнопкой «Синхронизировать». Попробуем создать тестовую номенклатуру в периферийной базе и выгрузить ее в основную с помощью РИБ:
Компоненту УРБД (Управление распределенными базами данных) применяют, когда необходимо обмениваться информацией между двумя или более идентичными информационными базами (далее – ИБ) по узкому каналу связи (например, модем, электронная почта). Ниже приведена пошаговая инструкция и практические советы по настройке УРБД в 1С:Предприятие 7.7. Пример приведен для двух ИБ, хотя настроить его на большее количество баз по аналогии с двумя базами не составляет большого труда. | Автор статьи: romix | Редакторы: evGenius Последняя редакция №7 от 22.02.08 | История URL: |
Ключевые слова: УРБД, скрипт для автообмена, обмен между филиалами, почта, rom-mail.dll, DialMail.dll, CDO, дозвон, УРИБ
Компоненту УРБД (Управление распределенными базами данных) применяют, когда необходимо обмениваться информацией между двумя идентичными информационными базами (далее – ИБ) по узкому каналу связи (например, модем, электронная почта). Ниже приведена пошаговая инструкция и практические советы по настройке УРБД в 1С:Предприятие 7.7. Пример приведен для двух ИБ, хотя настроить его на большее количество баз по аналогии с двумя базами не представляет большого труда.
1) За работу компоненты УРБД отвечает библиотека DistrDB.dll в папке BIN программы 1С:Предприятие. Эта компонента приобретается и устанавливается отдельно.
2) Для примера автообмена мы создадим две информационные базы, разместив их в папках с именами c:\1c_base1 и c:\1c_base2. Создайте эти папки, а в каждой из них – вложенные папки с именами CP и PC (латинскими буквами)
3) В папке c:\1c_base1 разместите уже готовую конфигурацию (скажем, «Торговля и Склад»). Но тренироваться лучше на самой простой информационной базе (содержащей, к примеру, всего один справочник с несколькими записями). Нам важно убедиться, что данные действительно мигрируют из одной ИБ в другую в результате автообмена УРБД, а это можно показать как на сложном, так и на самом простом тестовом примере.
4) Закройте все окна в Конфигураторе и активизируйте пункт меню «Администрирование – Распределенная ИБ – Управление». Этот пункт меню доступен, если в папке BIN программы 1С:Предприятие имеется компонента DistrDB.dll. Если библиотека имеет неправильную версию или повреждена, просто переустановите 1С:Предприятие поверх текущей установки – библиотека DistrDB.dll будет замещена ее правильной версией.
5) В открывшемся окне нажмите кнопку «Центральная ИБ». В окне запроса укажите код новой информационной базы (укажите цифру 1) и ее описание (например, «Центральная ИБ»).
6) Появившееся предупреждение о необратимости изменений загасите нажатием «ОК» (ниже описан недокументированный способ, как при необходимости вернуть базу в ее первоначальное состояние).
7) Нажмите кнопку «Новая периф. ИБ». В окне запроса укажите для нее код 2 и описание – «Периферийная ИБ».
8) Выделите однократным щелчком периферийную базу и нажмите кнопку «Настр. автообмена». В открывшемся окне установкой переключателя поменяйте «Ручной» режим автообмена на «Автоматический» и нажмите кнопку «ОК».
9) Нажмите кнопку «Выгрузить данные». Запомните (в буфер обмена) имя файла с выгрузкой «c:\1c_base1\CP\20.zip» - он нам еще пригодится. Нажмите ОК. По окончании выгрузки 1С напишет «Выгрузка успешно завершена».
10) Закройте Конфигуратор и войдите (также в режиме Конфигуратора) в папку (пока еще пустую), где должна лежать вторая ИБ (в нашем примере – c:\1c_base2). Укажите, что база должна быть в формате DBF/CDX и нажмите «ОК».
11) Зайдите в пункт меню Администрирование – Распределенная ИБ – Управление. В ответ на вопрос «Информационная база не обнаружена. Выполнить загрузку данных?» нажмите «Да» и укажите имя файла выгрузки (в нашем примере, «c:\1c_base1\CP\20.zip») и нажмите кнопку «ОК». По окончании загрузки 1С напишет «Загрузка успешно завершена». Мы успешно создали Периферийную ИБ, выгрузив данные из Центральной ИБ.
12) Измените что-нибудь (например, добавьте новый элемент справочника) в одной из информационных баз. Наша цель – добиться, чтобы изменения в одной (любой) ИБ попали в другую ИБ через автообмен. Используйте пункт меню «Администрирование» – «Распределенная ИБ» – «Автообмен» попеременно в каждой из баз. Вновь появляющиеся файлы выгрузок с расширением ZIP в папках CP и PC надо перемещать (копировать) между информационными базами по принципу CP->CP, PC->PC (в реальных «полевых» условиях обычно это делают при помощи электронной почты).
Советы и рецепты
1) Чтобы превратить распределенную базу в обычную, удалите файлы 1SDBSET.DBF, 1SDWNLDS.DBF, 1SUPDTS.DBF и соответствующие им файлы *.CDX, а также 1SSYSTEM.DBF. В принципе, достаточно удалить 1SSYSTEM.DBF. После этого необходимо восстановить точку актуальности, запустив программу в монопольном режиме. Этот трюк недокументирован (угадайте, почему), но, тем не менее, он работает.
2) Вы можете изменять конфигурацию 1С, но только в Центральной ИБ. Это очень удобно – изменения в периферийных ИБ «накатываются» автоматически.
3) Если у вас пропала (например, в результате ошибки почты) одна или несколько выгрузок – не огорчайтесь, т.к. УРБД умеет отслеживать такие ситуации, и повторять отправку потерянных данных при следующем сеансе автообмена.
4) Штатная возможность отправки почты в 1С реализована через интерфейс MAPI, когда взаимодействие происходит с почтовым клиентом (таким, как Outlook). Мой совет – не тратьте зря времени - с MAPI и разного рода Оутлюками на практике постоянно возникают заморочки, требующие «быстрой езды» разработчика между филиалами. Использовать прямое модемное соединение или FTP я не советую по этой же причине. Посылать почту лучше внешними компонентами, такими как rom-mail.dll или DialMail.dll.
Другой вариант - использовать CDO
http://avb1c.narod.ru/?=a9
(c) avb, Рупор абсурда
5) Программу, которая умеет автоматически выполнять автообмен и пересылать файлы выгрузки по электронной почте, вы можете взять здесь:
Если вы правильно настроите несколько констант (почтовые адреса, пароли, явки и т.д.), пользователю остается лишь дважды кликнуть на ярлык, чтобы запустить Автообмен.
Программа реализована как конфигурация 1С:Предприятие. Подробное описание содержится в приложенном файле DOC.
6) Если нужно автоматически выполнять дозвон до провайдера, используйте программу E-Type Dialer. Она умеет запускать внешние приложения при успешном соединении. Другой вариант – использовать внешнюю компоненту DialMail, которая имеет средства работы с модемом (совет – префикс «p» латинское перед номером дает импульсный набор, 9W перед номером – звонок через «девятку» и ожидание гудка в линии т.д.).
Замечание: в Windows XP есть встроенная звонилка rasdial.exe. Ключи командной строки:
rasdial.exe Элемент Пользователь Пароль
rasdial.exe Элемент /DISCONNECT
7) Приоритет отдается изменениям, выполненным в Центральной ИБ. Обратите внимание, что в типовых конфигурациях 1С применяются префиксы информационной базы (см. эту настройку в Константах), чтобы коды элементов справочников и номера документов, созданных в разных базах, не совпадали, и не нарушалась их уникальность.
ОЛЕГ ФИЛИППОВ , АНТ-Информ, заместитель начальника отдела разработки, [email protected]
РИБ в 1С. Границы возможностей
Технология распределенных информационных баз (РИБ) в платформе 1С:Предприятие вызывает много споров. Постараемся разобраться, когда ее целесообразно использовать, а когда лучше предпочесть альтернативные решения
Часто, читая форумы или статьи online-авторов по поводу РИБ в 1С, можно встретить противоречивые мнения от «это лучшее и единственное, что можно использовать» до «оно безнадежно устарело». Давайте постараемся разобраться, какобстоят дела на самом деле.
В ноябрьском номере за 2016 год я уже писал о некоторых особенностях РИБ применительно к конкретной практической задаче, поэтому об основах буквально пару слов, и несколько углубимся в технологические детали.
РИБ – технология распределенных информационных баз 1С:Предприятия – не путать с универсальным обменом, с схожей технологией, но принципиально отличающейся поддержкой централизованного обновления конфигураций информационных баз. Он состоит из следующих функциональных частей (которые могут использоваться и отдельно):
- Служба регистрации изменений – при включении начинает автоматически регистрировать изменения объектов или записей для обмена (или других целей). В режиме РИБ используется также для регистрации изменений конфигурации информационной базы.
- Сериализация объектов/записей в XML. Практически любой объект 1С:Предприятия штатным образом сериализуется в XML.
- Механизм поддержки одинаковой конфигурации всех узлов распределенной информационной базы. В режиме РИБ обмен данными между различными узлами возможен только в случае если у них одинаковая конфигурация. Переносится она при обмене автоматически. В конечном узле нужно только принять изменения.
- Инфраструктура сообщений при обмене в распределенной информационной системе – гарантированная доставка. Зарегистрированные изменения упаковываются в сообщения и отправляются на конечный узел в пакетах. Удаляются изрегистрации только после подтверждения доставки пакета.
- Инфраструктура уровня прикладных решений. Конечно, все вышеперечисленное не будет работать без развитых механизмов на уровне прикладных решений, часть из которых уже включена в БСП. В решениях реализована возможность выгружать данные по определенным правилам, изменять принципы их регистрации, определять способ доставки пакета.
Как видим, РИБ в 1С может достаточно много. В большинстве случаев данной функциональности более чем достаточно. К примеру, на рис. 1 приведена форма узла информационной базы в 1С, где можно видеть и возможность загрузить правила регистрации, и указать параметры подключения, и посмотреть список зарегистрированных к обмену объектов.
Из описания выше можно сделать вывод о возможностях РИБ 1С как распределенной системы:
- Поддержка единой конфигурации информационной базы (полуавтоматизированная).
- Поддержка отслеживания изменений.
- Гарантированная доставка.
- Возможность схемы master-master.
- Возможность схемы «звезда».
- Возможность выборочной фильтрации изменений.
Достаточно неплохо – потребности небольшой сети вполне удовлетворит. Но у РИБ есть определенные ограничения, во многом связанные с архитектурными особенностями платформы 1С, которые накладывают определенные ограничения на использование данной технологии:
- Необходимость обновления конфигурации информационной базы в ручном режиме с завершением работы пользователей. Остановка обменов до обновления конфигурации.
- Транзакционное ограничение инфраструктуры сообщений на выборку данных. При выборке изменений для выгрузки происходит блокировка таблицы базы на запись новых изменений, при больших объемах выгрузки это может занимать длительное время, останавливая работу.
- Накладные расходы на поддержание большого количества узлов синхронизации (количество служебных записей равно количеству узлов).
- Проблемы загрузки больших объемов данных.
Постараемся теперь сравнить это с какой-либо «продвинутой» системой, которая имеет механизм репликации.
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С-ные, но с достаточно приличным набором интерфейсных возможностей. Вот так, к примеру, выглядит отбор по дате:
Теперь к дальнейшему тиражированию готовы. Правльное планирование дальнейшей поддержки - один из ключевых факторов дальнейшего успеха подобных проектов.