Репликация средствами 1с распределенные базы данных как настроить
Обмен данными между прикладными решениями 1С 8 — это то, без чего не возможно построение полноценного информационного пространства предприятия.
- Зачем нужны обмены данных и как их использовать?
- Виды обменов между 1С.
- Как произвести настройку обмена данными между базами 1С?
Ответы на эти вопросы Вы узнаете ниже.
Если Вас интересуют услуги по настройке обмена данными между 1С и не только, подробности на странице Услуги 1С программиста.
Зачем нужны обмены данных между 1С?
Причин для внедрения обменов, как правило, две:
Организация имеет филиальную сеть
В этом случае Вам просто необходимо настраивать обмен между различными филиалами. Для этого в системе 1С 8.3 предприятие существует механизм Распределенных информационных баз (РИБ). С помощью которого можно гибко настроить обмен информацией. Например, для филиалов можно отключить видимость документов по другим филиалам и в тоже время центральный офис будет видеть документы всех филиалов. Другой пример — настройка обмена между базами 1С Розница офиса и магазинов.
Разделение по видам учета
Как правило, это означает, что в организации разный учет ведется в различных информационных базах. Такое разделение позволяет фильтровать «ненужную» для другого вида учета информацию для различных информационных баз. Пример: т.н. «управленческий учет» введется в базе «Управление торговлей», где отражаются все операции, и руководство видит полную картину событий, а в базу регламентированного учета «Бухгалтерия предприятия» выгружаются лишь нужные для ведения бухгалтерского и налогового учета документы.
Какие бывают механизмы обмена между базами 1С?
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Обмены данных можно классифицировать по двум направлениям: используемые механизмы и используемый транспорт для обмена.
Механизмы обмена данными 1С
Как правило, при обмене используется два механизма:
- Распределенная информационная база (РИБ) — механизм, позволяющий настроить обмен данными между филиалами. Механизм подразумевает, что обмениваются абсолютно идентичные конфигурации БД. Механизм умеет передавать изменения конфигурации баз данных. Механизм реализован на уровне технологической платформы.
- Универсальный механизм обмена между конфигурациями — механизм является разработкой фирмы 1С для прикладных решения. Он универсален и основан на планах обмена. Обмен данными осуществляется с помощью правил xml, которые создаются в специальной конфигурации — Конвертация данных. С помощью данного механизма можно реализовать как одноразовый обмен, так и постоянный обмен между 1С конфигурациями. Механизм реализован на уровне конфигурации, встроить в свою конфигурацию можно из технологической конфигурации БСП.
Транспорт для обмена данными
Транспортом может выступать достаточно широкий спектр технологий. Рассмотрим основные, реализованные в универсальном механизме обмена 1С:
Как настроить обмен данными между базами 1С?
Рассмотрим настройку 1С для обмена данными между типовыми конфигурациями 1С — Бухгалтерия и Управление торговлей.
Первым делом необходимо создать узлы информационных баз:
Синхронизация происходит по коду, пиктограмма с кругом — обозначение текущей информационной базы. Т.е. настраивая обмен в бухгалтерии — присваиваем текущему узлу код «БП», настраивая обмен в торговле — код «УТ».
Следующий шаг — создание справочника «Настройки обмена данных»:
Если обмен настраивается через каталог, электронную почту или FTP, настройки необходимо настраивать в двух базах данных.
Если обмен происходит прямым подключением или через веб-сервис, достаточно настройки с одной стороны (важно не забыть указать правила загрузки в базу обмена).
Тут важно обратить внимание на следующие моменты:
Всё, настройка закончена. Теперь для запуска обмена достаточно лишь нажать на кнопку выполнения обмена.
Азы настройки обмена данными в 1С с помощью конфигурации «1С Конвертации данных» на примере смотрите в видео:
Обмен данными 1С по расписанию в 1С
Если необходимо настроить автоматическую выгрузку по расписанию, достаточно настроить регламентные задания.
Для клиент-серверного варианта
В справочнике «Настройки обмена данными», на вкладке «Автоматический обмен» необходимо создать новое регламентное задание, где указать расписание:
Для файлового варианта
В справочнике «Настройки обмена данными», на вкладке «Автоматический обмен» необходимо создать новое регламентное задание, где на вкладке «Обмен по событиям» указать события, по котором будет выполняться запуск обмена. Например, при старте определенного пользователя:
Статьи для программиста по обмену данными в 1С
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
Отчетность, закрытие месяца, сбор данных для аудиторов, срочный отчет для директора, и так далее и тому подобное. Для этого и предназначены информационные системы, ведь практически всегда конечный результат всех процессов в них - это предоставление бизнесу какой-либо информации в виде отчетов или около того.
Сами отчеты бывают разные. От простых оборотно-сальдовых ведомостей по счету, до замудренных отчетов с анализом данных за предыдущие года, при этом с применением различных формул и параметров расчета.
Не удивительно, что в периоды отчетности или закрытия месяца многие компании сталкиваются с замедлением работы своих систем на базе 1С или НЕ 1С. Ведь один тяжелый отчет при формировании может "съесть" больше ресурсов, чем работа всей системы за неделю и даже больше.
В мире энтерпрайза за пределами экосистемы 1С принято разделять базы на две категории:
- Операционные (OLTP), где ведется основная работа бизнеса. Работа этих систем критична для бизнеса, а остановка в случае нештатных ситуаций может стоить компании значительных средств.
- Отчетные (OLAP), предназначены для сбора различных видов отчетов. За счет изолирования от операционной базы, формирование тяжелой аналитической отчетности не повлияет на производительность и стабильность ее работы. Обычно остановка этих баз не так сильно отзывается на работе компании.
Создать отдельную базу для отчетов можно несколькими путями:
- Сделать копию операционной базы данных.
- Организовать хранилище данных.
Из названия статьи наверное уже понятно, что хранилище данных мы сейчас строить не будем. Если Вам интересно, то в эту тему можно начать погружаться с интересного видео от Алексея Лустина.
Мы же сегодня рассмотрим несколько подходов по созданию копии базы 1С для отчетов. Начнем с простого, а закончим чем-нибудь хардкорным.
Внимание!!
Размещать отчетную базу лучше на отдельном сервере, чтобы снизить до минимума влияние ее работы на операционную деятельность. Это актуально для всех способов, что будут описаны ниже.
Ах да, все примеры для клиент-серверных баз в контексте работы со SQL Server. Что-то будет актуально и для PostgreSQL.
Классический подход
Самый простой способ, который используется для создания копии базы - это разворачивание ее через бэкап. Обычно его используют для создания или актуализации тестовых баз, но и для создания отчетной базы тоже иногда может быть применимо.
Формирование и последующее разворачивание бэкапа делается через SQL Server Managment Studio в несколько простых шагов.
Здесь простой пример как вручную создать бэкап, а потом развернуть его и при этом не сломать основную стратегию бэкапирования на сервере. Вы же делаете регулярные бэкапы, не так ли?!
Сделать бэкап можно через удобный интерфейс с помощью SQL Managment Studio (SSMS), который также поставляется с некоторыми дистрибутивами SQL Server в комплекте, но можно использовать и последнюю версию с сайта Microsoft.
Для этого нужно иметь соответствующие права доступа на инстансе SQL Server, зайти в SSMS и перейти к настройкам резервного копирования.
Откроется окно настроек резервного копирования в разделе "Общие". Поскольку пример у нас простейший, то тут достаточно указать путь сохранения файла бэкапа и опцию "Архивная копия только для копирования". Последняя настройка нужна для того, чтобы SQL Server не учитывал этот бэкап в последовательности резервных копий при работе основной стратегии бэкапирования. Подробнее здесь.
Далее запускам и ждем завершения операции создания резервной копии.
Когда увидим заветное окно о завершении, то можно говорить о грандиозном успехе! Все получилось!
Теперь у нас есть резервная копия, из которой мы можем развернуть отчетную базу на отдельном сервере.
С помощью SQL Managment Studio (SSMS) также развернем копию базы. Для этого перейдем к разделу "Базы данных" в SQL Managment Studio (SSMS).
Далее укажем основные параметры: путь к файлу резервной копии и имя базы данных. Если база данных уже существует и ее нужно полностью обновить, то на вкладке "Параметры" установите "Перезаписать существующую базу данных (WITH REPLACE)".
Ожидаем процесс восстановления базы.
Отлично, копия базы готова!
Вот и все! У нас есть актуальная (пока что!) база, для которой можно создать новую информационную базу на сервере 1С и использовать изолированно от рабочего окружения.
Мы не рассматриваем все настройки для работы с бэкапированием, т.к. цели такой и не было. При такой схеме работы Вам еще может понадобиться указывать путь к файлам базы данных да диске, изменить модель восстановления отчетной базы с "Полный" на "Простой" и другое. Подробнее обо всем этом можете прочитать по ссылке.
Мы акцентируем внимание на клиент-серверном режиме работы, но фактически такой подход можно использовать и для файловых баз. Вот только о какой производительности может идти речь в последнем случае - загадка. То есть для файловых баз это неактуально.
- Копия базы быстро теряет актуальность.
- Подходит только для формирования отчетов в закрытом периоде, где данные уже не изменяются. В открытом периоде данные могут быть некорректные / неактуальные.
- Актуализация только по требованию, когда нужны свежие данные "еще вчера".
Просто, эффективно, но медленно!
Скриптуем все!
Но что, если нужно обновлять отчетную базу чаще? Например, раз в сутки?
В этом случае мы можем заскриптовать процесс формирования бэкапа для отчетной базы, а после ее обновление.
Например, так мы сформируем бэкап.
А потом обновим отчетную базу.
Чтобы этот процесс выполнялся автоматически раз в сутки создадим задание на SQL Server.
Просто добавим задание, которое автоматически будет создавать резервную копию и разворачивать вне рабочее время.
Скрипты для работы с резервными копиями были использованы те же, что и в предыдущих примерах.
- Простота настройки, хоть и чуть сложнее предыдущего примера.
- Копия базы актуальна на предыдущий день.
- Не подходит для формирования оперативных отчетов.
- Не подходит для формирования отчетности по прошлым периодам, если там интенсивно выполняется корректировка данных. Ну никто же так не делает! :)
Быстро, чуть сложнее предыдущего способа, но все еще медленно актуализируются данные.
Реплицируем через репликацию
Другой способ - это репликация стандартными средствами SQL Server. На самом деле, это не самый подходящий вариант передачи изменений баз 1С в их копию, потому что для его эффективной работы необходимо было бы добавить первичные ключи во все таблицы. Платформа 1С этого не делает. Конечно, можно было бы добавить ключи самостоятельно и, о боже, поддерживать при реструктуризации. Но, даже это бы не помогло, потому что для некоторых таблиц ключ просто невозможно добавить. Например, для таблицы "DBSchema", в которой только одно поле с типом "varbinary(max)".
Вообще, есть несколько основных видов репликации:
-
- реплицируются все данные целиком, отслеживание изменений не выполняется. - передача изменения из базы источника выполняется порциями в виде пакетов транзакций, т.е. при этом ведется отслеживание изменений. - репликация с несколькими источниками. Источник отправляет пакеты транзакций всем узлам. Каждый узел может получать и отправлять изменения. - как и репликация транзакций, данные синхронизируются пакетами транзакций. При этом изменения могут вноситься во все базы в репликации.
Из-за отсутствия первичных ключей в таблице может использоваться только публикация моментальных снимков. Но есть ли в этом смысл? Проще использовать актуализацию базы данных через формирование и разворачивание бэкапа.
Мне удавалось запустить репликацию базы данных 1С через метод "Репликация транзакций", который был бы идеальным, если бы платформа корректно создавала первичные ключи для таблиц. Но мир не идеален, поэтому пришлось выполнять несколько дополнительных действий:
- Добавляем первичные ключи во все таблицы где есть кластерный индекс.
- После добавляем ключи в таблицы "кучи", если это возможно.
- Для таблиц, где первичный ключ добавить нельзя (например, та же таблица "DBSchema") добавляем свое числовое поле "ID" с автоинкрементом, которое и будет первичным ключом. Платформа 1С ничего об этом поле знать не будет.
Да, репликация работала, но это такая лютая схема, что лучше ее никогда не использовать и не продвигать дальше этапа экспериментов. К тому же, нужно позаботиться о том, чтобы в базе приемнике не изменялись данные. Но Вы можете попробовать :). Результаты моих экспериментов постепенно выкладываются здесь.
И так, что имеем.
- Быстрая синхронизация при использовании репликации транзакций.
- Отлаженные механизмы обмена как для хороших каналов связи, так и с низким качеством соединения.
- Большие сложности применения для информационных баз 1С.
- Сопровождение на столько сложное, что для простых обновлений баз 1С может потребоваться администратор БД или эксперт 1С!
- Нарушение лицензионного соглашения фирмы 1С в части использования недокументированных возможностей.
Таким образом, это для лютых извращенцев, которые не ищут легких путей! :)
Копия в реальном времени
И последний способ создания копии базы для отчетов - это использование групп высокой доступности AlwaysOn. Это очень мощная технология, которая позволяет создавать копию базы данных практически в реальном времени. С ее помощью можно настроить репликацию данных базы на другой инстанс SQL Server, при этом вторая база данных будет только для чтения.
Репликация при AlwaysOn может быть двух типов:
- Синхронная - когда транзакция фиксируется сразу же на двух узлах базы данных.
- Асинхронная - когда транзакции фиксируются на основной реплике и изменения асинхронно передаются на второй узел с некоторой задержкой.
Синхронная репликация используется в основном для решения задач отказоустойчивости и надежности, т.к. позволяет в случае отказа основной реплики автоматически переключиться на второй узел. Существенным минусом синхронных реплик является потенциальное снижение производительности, т.к. транзакция должна быть зафиксирована на обоих узлах. Таким образом, самый медленный узел будет узким местом производительности. Это может использоваться и для баз 1С, вот только сегодня мы ведем речь о создании копии базы для отчетов, поэтому нам больше подходит асинхронная реплика.
При асинхронной репликации автоматическое переключение узлов в случае аварий не предусмотрено, нужно это действие выполнять вручную.Так сделано потому что есть риск потери данных. т.к. синхронизация выполняется в фоновом режиме с задержкой и не все данные могут быть переданы на момент нештатной ситуации.
Настройка AlwaysOn сама по себе не очень сложная, но вот подготовительные работы могут занять время. Для работы групп доступности необходимо следующее:
- SQL Server 2012 и выше редакции Enterprise Edition. Также функционал доступен для Standard Edition, но с ограничениями:
- Максимум 2 реплики (первичная и вторичная)
- Нет доступа на чтение для второй реплики
- Только одна база в каждой группе доступности.
Таким образом, нужен квалифицированный администратор, лицензии на Windows Server и SQL Server редакции Enterprise. Цена может подходить не для всех. Процесс настройки рассматривать в статье не будем, но ознакомиться с самой простой конфигурацией по шагам Вы можете по следующим ссылкам:
Сейчас же остановимся на некоторых особенностях работы баз 1С с репликами AlwaysOn. Допустим, у нас сделана настройка асинхронной реплики. База данных на втором узле практически всегда находится в актуальном состоянии. Но находится она в режиме только для чтения! Мы развернули отдельный сервер 1С, добавили эту базу и попытались зайти в нее в режиме 1С:Предприятие. Первое, что мы увидим будет.
Платформа 1С не поддерживает работу с базой в режиме "Только для чтения", т.к. пытается сохранять различные настройки форм, отчетов, историю работы в служебные таблицы. В этом случае есть несколько решений:
Готовые решения тут отсутствуют, т.к. случаи очень разные, но общий подход должен быть понятен. Есть и другие нюансы при работе с AlwaysOn, не только в контексте 1С. Подробнее Вы можете прочитать здесь.
Если Вас интересует технология AlwaysOn, то в репозитории есть специальный раздел о нем со скриптами, мануалами и прочим.
Мысли напоследок
Вы дочитали до конца и задались вопросом: "Почему не использовать стандартные возможности платформы?". Например, создать базу и наполнять ее через обмены или вообще сделать узел УРБД. Справедливый вопрос! Но и ответ простой - скорость и производительность!
Стандартными обменами никогда не достичь передачи данных в реальном времени. Ни конвертация данных, ни даже организация событийного обмена через RabbitMQ никогда не достигнут скорости передачи данных по сравнению с AlwaysOn или репликацией транзакций. С другой стороны, они дешевле. И точно быстрее, чем актуализация отчетной базы через бэкапы.
Еще вопрос - почему не формировать тяжелые отчеты в основной базе? Тут все просто - аналитические отчеты обычно требуют обработки большого массива данных. В этом случае может быть не важно на сколько оптимально вы написали запрос, ведь если данные анализируются за несколько лет, то никакой индекс или статистика могут не помочь. СУБД просто выберет сканирование таблиц в запросе и придется с этим жить. Все, конечно, зависит от запроса.
Эта тема более актуальна для больших баз, т.к. там формирование тяжелой аналитической отчетности могут не просто замедлить основную работу, а просто ее остановить.
На мой взгляд, самым продвинутым способом создания базы для отчетности остается AlwaysOn, но он требует дополнительной квалификации, расходов на лицензии и некоторую адаптацию конфигураций 1С.
Хорошим и дешевым был бы способ репликации транзакций, но из-за особенностей баз 1С его сложно применять.
Самым доступным и распространенным остается способ через бэкапирование и разворачивание резервных копий со всеми вытекающими недостатками и ограничениями.
Имеется центральный офис и очень удаленный филиал. Между собой территории связаны медленным каналом. В центральном офисе хотят иметь актуальную копию базы данных филиала. Реализовано с помощью механизма РИБ.
РЕПЛИКАЦИЯ БП8 С ПОМОЩЬЮ МЕХАНИЗМА РИБ
Постановка задачи: имеется центральный офис и удаленный филиал (в разных городах). Между собой территории связаны медленным каналом. В центральном офисе хотят иметь актуальную копию информационной базы (ИБ) филиала.
Филиал использует конфигурацию 1С «Бухгалтерия предприятия» 8 (БП8) в файловом варианте.
Самый простой вариант - ежедневно копировать всю папку с ИБ по каналу из филиала в офис, делать это не позволяет делать медленный канал и большой объем ИБ.
Предлагается решение выполнять ежедневные репликации с помощью механизма Распределенной Информационной Базы (РИБ).
В терминах РИБ у нас имеется 2 узла главный (БП8 в филиале) и подчиненный (копия БП8 в центральном офисе).
1. Настройка главного узла
Вначале необходимо настроить главный узел. Для этого в ИБ филиала необходимо зарегистрироваться с административными правами. В основном меню программы выбрать пункт «Операции / Планы обмена. ». В планах обмена стандартной конфигурации БП8 уже созданы 4 стандартных плана обмена:
Текущий узел описан, теперь необходимо описать узел-приемник. Жмем F9>, добавляем новый узел с именем «Копия БП» и кодом «Б02». Получаем два узла:
В РИБ может быть много подчиненных узлов и обмен будет производиться между одним главным узлом и каждым из подчиненных узлов, но для нашей «узкой» цели достаточно двух «Источник» (главный узел) и «Приемник» (подчиненный узел - копия БП).
Теперь физически создадим подчиненный узел (новую базу данных). Для этого необходимо встать на строчку узла «Копия БП» и нажать на значок «Создать начальный образ. » или выбрать это действие из меню:
Система предложит выбрать тип ИБ. Необходимо выбрать «На данном компьютере. ». Затем необходимо указать каталог, в котором будет создана новая ИБ. Лучше создать новую папку и там будет создана новая ИБ:
После этого в указанном каталоге будет создана новая ИБ 1С и в эту базу будут перенесены все данные из главной базы. Сразу стоит отметить, что новая ИБ не является точной копией исходной. В ней свои настройки (свой список пользователей и т.д.), переносятся только данные и модифицированные планы обмена, т.е. в новой ИБ останутся только два узла «Главный узел» и «Копия БП». Второй узел в новой ИБ будет предопределенным.
Если исходная ИБ большая и в ней работают пользователи, при создании начального образа возможны коллизии, поэтому операцию создания нового образа рекомендуется проводить на ИБ в монопольном режиме.
Если в главном узле было описано несколько подчиненных узлов, операцию по созданию начального образа ИБ необходимо провести для каждого узла, т.е. будет создано столько новых ИБ, сколько было описано узлов в исходной базе. Для наших целей достаточно одного подчиненного узла.
В момент создания начального образа, в главной базе будет создана таблица синхронизации объектов главной базы с этим узлом. В общем случае таких таблиц создается по количеству подчиненных узлов. При создании начального образа узла устанавливается признак синхронизации с узлом.
Теперь новую ИБ необходимо скопировать в центральный офис. После этого на обоих территориях будут одинаковые (в смысле данных) ИБ.
Созданную ИБ необходимо настроить как любую новую базу: ввести пользователей и т.д.
2. Порядок обмена данными
В общем случае обе базы данных являются рабочими, т.е. документы вводятся, изменяются в обеих базах. В нашем случае рабочая база только одна и данные двигаются только в одном направлении.
Полный цикл обмена состоит из следующих этапов:
- a) Выгрузка в главной ИБ данных, измененных после последнего обмена данных.
- b) Передача выгруженных данных в центральный офис;
- c) Загрузка данных в копию ИБ;
- d) Выгрузка данных из копии ИБ (выгружаются подтверждения о приеме данных);
- e) Передача результата обмена в филиал;
- f) Загрузка файла обмена в главную базу для подтверждения приема изменений в копии ИБ.
Для проверки обмена выполним цикл обмена вручную. Зарегистрируемся в исходной ИБ. Сделаем изменение в ИБ, например введем новую запись в справочник «Номенклатура»:
Откроем план обмена «Полный». Встанем на строку «Копия БП». Нажмем на значок «Записать изменения». Появится окно для выбора папки, в которую будут сохраняться файлы выгрузки и загрузки. Лучше создать для этого отдельную папку с понятным именем, например «Обмен». Автоматически сформируется имя файла выгрузки «Message_Б01_Б02.zip». По имени можно понять, что этот файл предназначен для передачи из узла «Б01» в узел «Б02». Жмем «ОК».
В центральном офисе заходим в ИБ, открываем план обмена «Полный», встаем на строчку «Главный узел». Жмем на значок «Прочитать изменения», указываем путь к файлу обмена. Жмем «ОК»:
Можно проверить, что новая переданная запись попала в справочник «Номенклатура».
Для того, чтобы рабочая ИБ «знала», что обмен произведен успешно, необходимо послать подтверждение успешного обмена. Если этого не сделать, то при следующем обмене из филиала произойдет повторная выгрузка неподтвержденных объектов.
В центральном офисе делаем выгрузку ИБ. Жмем на значок «Записать изменения». В указанную ранее папку запишется файл с автоматически созданным именем «Message_Б02_Б01.zip». Название говорит, что этот файл предназначен для главного узла «Б01» от подчиненного узла «Б02». Жмем «ОК». Происходит выгрузка указанного файла. В этом файле содержится подтверждение успешного приема изменений основной ИБ.
Таким образом, вручную был проверен механизм обмена между двумя удаленными ИБ.
3. Настройка регулярного обмена
Такой обмен очень трудоемок, поэтому в 1С имеются средства для автоматизации процедур обмена. Для упрощения обмена необходимо на каждом узле зайти в основном меню программы «Сервис / Распределенная информационная база (РИБ) / Настроить узлы РИБ».
В появившемся окне добавить строку и заполнить ее. Например, заполним строку в главном узле:
Теперь при нажатии на значок «Выполнить обмен по текущей настройке» произойдет загрузка и выгрузка данных для подчиненного узла.
Для автоматического запуска заданий обмена необходимо настроить расписание на закладке «Автообмен». Расписание автообмена следует хорошо продумать, т.к. с выгрузками из базы данных нужно синхронизировать файловый обмен между территориями. Кроме того, в нашем случае филиал и центральный офис находятся в разных часовых поясах, что накладывает дополнительные сложности в синхронизации.
Для автоматического запуска заданий необходима дополнительная настройка в меню «Предприятие / Настройка параметров учета / Обмен данными». Необходимо заполнить эту закладку.
Префикс необходим, если в подчиненном узле происходит ввод документов. Документам при обмене будет присваиваться префикс. Для автоматического запуска заданий обязательно необходимо ввести пользователя и интервал опроса. Обмен будет происходить в сеансе указанного пользователя, т.е. необходимо запустить программу с авторизацией. Пример настроек для файловой ИБ:
Аналогично нужно настроить все подчиненные узлы. В нашем случае это узел «Копия БП» в центральном офисе.
4. Выполнение регулярного обмена
Для выполнения регулярного обмена необходимо выполнить следующую последовательность действий:
- a) Войти на главном узле (в филиале) в программу под именем пользователя, указанного в настройках параметров учета (Любимов). После успешного входа процедура обмена будет запускаться через указанный интервал. В тестовом примере - через 600 секунд. При обмене вначале происходит чтение входного файла обмена от подчиненного узла, а затем запись новых изменений ИБ в выходной файл обмена. Если входной файл обработан успешно, он удаляется из папки обмена.
- b) Затем необходимо произвести файловый обмен между центральным офисом и филиалом. Новый выходной файл будет передан в центральный офис. Файловый обмен необходимо синхронизировать с интервалом регламентных заданий в программе. Если в программе интервал составляет 1 час, то файловый обмен должен происходить чаще, например каждые 30 минут.
- c) В центральном офисе запущенная программа также будет пытаться выполнить регламентное задание через указанный интервал. Здесь также вначале происходит чтение полученного файла, а затем запись в выходной файл. Т.к. ввод данных идет только в филиале, то в выходной файл заносятся квитанции о получении данных. При удачном чтении входной файл, полученный из филиала, будет удален.
- d) При очередном сеансе связи происходит обмен файлами между обменными папками.
- e) Т.к. программа в филиале уже открыта, то при очередном автоматическом запуске регламентного задания произойдет очередной обмен, т.е. повторение пункта а).
Специальные предложения
Много очень важного не было сказано, на пример, что делать если нужно внести в основную базу изменения и как потом обновлять удаленные базы, а так же про права на обмен. Если автору интересно то могу поделиться опытом.
(1) Думаю автор в курсе )
Для тех, кто первый раз делает РИБ - пригодится.
зы. ставлю + за много буков и картинки.Автор - чайник, который должен читать и учиться, а не писать статьи. ЕЩЕ ОЧЕНЬ РАНО Вам браться за перо. Цицата:" . В центральном офисе хотят иметь актуальную копию базы данных филиала". Обращаю Ваше внимание, что при распределенке нет копии баз данных филиала (их обычно называют информационными базами), а все работают в одной (единой ИБ). Комментировать остальное просто нет времени и желания.
(3) я думаю, что на данном уровне изложения - такая терминология впролне допустима. особенно если для пользователя периферийной базы эта РАСПРЕДЕЛЕННАЯ БАЗА выглядит как отдельная база, связанная с ДРУГОЙ (ЦЕНТРАЛЬНОЙ) БАЗОЙ только посредством автообменов..
(0) Автор старался писал - плюс заслужил
(3) Ну все были чайниками. НО согласен что формулировка должна быть максимально точной дабы не вводить в заблуждение.(0) Картинки у меня почему-то отсутствуют. :(
"В нашем случае рабочая база только одна и данные двигаются только в одном направлении." - Не увидел в описании где это настраивается.
Неясно причем тут медленные каналы связи?
Попробуйте в базе с 16000 доков за месяц сделать групповое перепроведение за месяц и потом запустите типовой обмен РИБ.
Я думал будет описание реализации обмена только документами БЕЗ ДВИЖЕНИЙ, и в дальнейшем в каждой БД фоновое допроведение/удаление/распроведение документов.УРБД в 4 шага. Уже классическая статья. Не надо велописедов изобретать. Тем более так плохо их описывать.
Даже с выходом 8.2 продолжаю всем советовать терминальный доступ.
РИБ требует очень прямых рук каждый день и имеет ряд минусов.Хм. А чем это отличается от статьи на ИТСе, которая еще на 8.0 начала выходить? Там то же самое с картинками и примерами. В 2006м году видел ее на ИТСе.
Автору плюс авансом. Ждём описания того, какие действия надо предпринять, если была изменена структура конфигурации. Как заметил
Cyberboy в первом посту, это важно !(12) При работе с распределенной информационной базой (РИБ) иногда возникает ошибка: «Конфигурация узла распределенной ИБ не соответствует ожидаемой!»
На диске ИТС есть статья «Обработка ошибок, возникающих при обмене данными в РИБ». В этой статье перечислены ошибки, их источники.
> Начат обмен данными по настройке "Ежедневный" (9:02:11).
!! Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфигурация узла распределенной ИБ не соответствует ожидаемой!
!! Чтение данных из файла обмена завершено с ошибками!
> Запись изменений текущей информационной базы в файл обмена завершилась успешно.
> Обмен данными по настройке "Ежедневный" завершен (9:06:50).При этом главный узел «понимает», что нужно обновить конфигурацию подчиненного узла и добавит в файл обмена изменения в конфигурации.
> Начат обмен данными по настройке "Дневной" (9:17:07).
!! Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Из главного узла распределенной информационной базы получены изменения конфигурации.
Необходимо выполнить обновление конфигурации базы данных.
Обновление может быть выполнено в режиме Конфигуратор.
!! Чтение данных из файла обмена завершено с ошибками!
> Запись изменений текущей информационной базы в файл обмена завершилась успешно.
> Обмен данными по настройке "Дневной" завершен (9:32:46).> Начат обмен данными по настройке "Дневной" (9:58:37).
> Чтение данных из файла обмена успешно завершено.
> Запись изменений текущей информационной базы в файл обмена завершилась успешно.
> Обмен данными по настройке "Дневной" завершен (10:12:56).> Начат обмен данными по настройке "Ежедневный" (10:26:27).
> Чтение данных из файла обмена успешно завершено.
> Запись изменений текущей информационной базы в файл обмена завершилась успешно.
> Обмен данными по настройке "Ежедневный" завершен (10:26:52).Такие операции необходимо проделать для каждого подчиненного узла.
Механизм РИБ — механизм распределенных информационных баз - это когда у вас есть главная база и подчиненная(ые). Главная база может быть только одна, подчиненных может быть много. Каждая подчиненная база может иметь свои подчиненные базы, для которых она будет главной.
Вот посмотрим на картинку из первой ссылки по запросу в Яндексе:
РИБ используется для обмена данными. Причем не только теми данными, с которыми работает пользователь, но и данными изменения конфигурации. То есть РИБ позволяет передавать изменения конфигурации. Но изменить конфигурацию можно только в главной базе!
Визуализируем:
У нас большая компания и много филиалов. Есть доработанная УНФ, которую мы гордо называем УБФ(Управление Большой Фирмой). Но мы решили, что хватит терпеть то, что все филиалы имеют доступ к документам всех филиалов и каждому филиалу решили сделать отдельную базу, которую синхронизировать с нашей основной базой для передачи данных. Что ж, можно. Сделали.
И внезапно мы решили изменить картинку, которая появляется при входе в базу, захотели поместить туда логотип нашей фирмы, а почему бы и нет?
Как запилить картинку во все базы всех филиалов? Ну при текущем варианте, что у всех филиалов отдельная база, только руками. Руками специалистов, которые умеют заходить в конфигуратор и знают что нужно там нажать.
А вот если бы мы сделали подчиненные базы для филиалов, то есть использовали РИБ, то и данными бы обменивались, как при обычной синхронизации, и картинка бы сама добавилась во все "базы-дочки". Однако, в конфигуратор зайти бы все-таки пришлось, но только чтобы нажать кнопочку "Обновить конфигурацию базы данных", вот картинка:
Как создать подчиненную базу, на пальцах:
я буду использовать Управление торговлей, редакция 11 (11.4.13.275), но способ, в целом, одинаковый во всех типовых конфигурациях.
1) Сначала проделаем шаги, как при настройке обычной синхронизации:
2) . поставим галочку, нажмем.
4) тут ознакомимся с описанием. Я выберу обычную настройку, но если бы мы следовали примеру выше, то нужно было бы выбрать "с фильтром" и там одним кликом выбрать нужный филиал.
6) Указываем префикс - он будет подставляться к номерам документов, чтобы можно было отличить документы дочки и основной базы.
7) в общем случае, тут ничего не надо нажимать, кроме "Записать и закрыть".
8) А вот теперь создаем нашу новую подчиненную базу:
9) указываем место, куда ее покладем.
10) Зайдем в нашу новую подчиненную базу и закончим настройки синхронизации(синхронизация уже создалась, так как использовали РИБ, но нужно указать каталог для обмена выбрав "Настройки подключения")
(обратите внимание на верхний левый угол окна программы, там название базы, он отличается от предыдущих, так как это "дочка")
Кстати, в новой базе все пользователи будут выключены, пароли сброшены, нужно включить руками:
В общем-то ВСЕ.
Подчиненная база создана!
Теперь, когда наши программисты что-нибудь улучшат, эти улучшения прилетят в подчиненные базы сами.
Вот что-то изменили в основной базе:
нам нужно перенести изменения в базы-дочки.
Для этого запускаем главную базу в режиме 1С:Предприятие, то есть в пользовательском интерфейсе, заходим в настройки синхронизации, жмем выделенную кнопку:
После того, как синхронизация закончится, заходим в базу дочку и так же жмем "Синхронизировать", база загрузит данные и напишет:
После нажатия на Далее база закроется и начнет устанавливать обновления.
Когда обновы установятся, база начнет запускаться и сообщит нам следующее:
Это означает, что не обновлена конфигурация базы данных. Та самая маленькая кнопка в конфигураторе и это именно та причина, почему придется ОДИН раз зайти в конфигуратор. Что ж, зайдем в конфигуратор базы-дочки и нажмем эту кнопку, заодно вообще посмотрим что-да-как там, мы ж там еще не были.
Откроем конфигурацию и вот что увидим
Нажмем на "Обновить конфигурацию базы данных".
Увидим список изменений, которые прилетели с обновлениями:
И вот эти обновления появились в подчиненной базе.
Теперь необходимо запустить базу в пользовательском режиме, чтобы выполнились обработчики обновления.
Несколько правил:
1) Все узлы, кроме одного, должны иметь по одному главному узлу и один узел не будет иметь главного узла - это корневой узел.
2) Конфигурация может быть изменена только в узле, не имеющем главного узла (то есть в корневом).
3) Изменения конфигурации будут передаваться от главного к подчиненным узлам.
4) Разрешение коллизий так же будет производиться исходя из отношений "главный - подчиненный" - если изменения сделаны одновременно и в главном и в подчиненном узлах, то приняты будут изменения главного узла.
5) Сделать подчиненный узел в распределенной базе можно разными способами, но создание начального образа является рекомендуемым.
А теперь то, ради чего все писалось.
Как подчиненную базу сделать обычной(нормальной, отдельной, как хотите).
Я опишу только тот способ, которым пользуюсь. Это моя шпаргалка. Но он не единственный.
1) Заходим в свойства ярлыка запуска окна 1С:Предприятие:
2) В поле "Объект" дописываем:
DESIGNER /F"Путь до базы" /N"Имя Пользователя в базе" /P"Пароль пользователя" /ResetMasterNode
В итоге у меня получится:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F"C:\Users\79119\Desktop\РИБ" /N"" /P"" /ResetMasterNode
Создание и настройка распределенной базы данных (РИБ) в 1С 8.3 Бухгалтерия (и других конфигурациях) необходимы в случаях, когда нет возможности работать нескольким пользователям, одновременно подключаясь к одной базе данных. В настоящее время это довольно редкое явление, так как прекрасно работает стандартный удаленный рабочий стол и есть другие программы, которые обеспечивают удаленное подключение к центральному компьютеру, где расположена база данных.
Но тем не менее бывают ситуации, когда просто-напросто нет интернета. А данные должны в итоге оказаться в одной информационной базе. Для этого и создается распределенная база данных.
Обычно главную базу называют центральной, а остальные — периферийными. Суть в том, что либо в ручном, либо в автоматическом режиме (зависит от настройки) базы данных объединяются в одну. Чтобы номера вновь введенных документов и коды справочников не дублировались, каждой базе данных назначается префикс.
В этой инструкции мы на примере создадим центральную и периферийную базы данных, проверим обмен между ними. Это пособие подойдет как для 1С 8.3 Бухгалтерия, так и для 1С Управление торговлей (УТ) и других конфигураций.
Настройка главной (центральной) распределенной базы РИБ
Зайдем в меню 1С «Администрирование», далее по ссылке «Настройки синхронизации данных». В открывшемся окне нужно установить флажок «Синхронизация данных». Станет активной ссылка «Синхронизация данных». Сразу здесь же установим префикс для главной информационной базы – например, «ЦБ»:
Заходим по ссылке «Синхронизация данных», откроется окно с кнопкой «Настроить синхронизацию данных». При нажатии на эту кнопку откроется выпадающий список, где нужно выбрать режим «Полный». Если требуется синхронизация только по одной организации, нужно выбрать «По организации…».
В следующем окне нам программа предложит сделать резервную копию. Настоятельно рекомендую сделать это, так как следующие шаги настройки могут быть необратимы.
После создания резервной копии нажимаем кнопку «Далее». На следующем шаге нам следует определиться, как будет происходить синхронизация:
- через локальный каталог или каталог в локальной сети;
- по интернету посредством FTP.
Для простоты и наглядности примера выберем локальный каталог. Я указал следующий путь: «D:\Базы 1С\Синхронизация». Не лишней будет проверка записи в данный каталог, для этого есть специальная кнопка:
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>Получите понятные самоучители по 1С бесплатно:
Следующие шаги с настройкой синхронизации по FTP и электронной почте пропускаем. Останавливаемся на настройках названий главной и периферийной баз данных. Здесь же зададим префикс для периферийной базы:
Не забывайте, что префиксы каждой базы должны быть уникальны. В противном случае Вы получите ошибку «Значение префикса первой информационной базы не уникально».
Жмем «Далее», проверяем введенную информацию и опять нажимаем «Далее», затем — «Готово». В поле «Полное имя файловой базы» указываем файл 1Cv8.1CD в каталоге, который создали для синхронизации. Создаем начальный образ распределенной базы 1С:
После создания начального образа РИБ в 1С можно задать расписание синхронизации или синхронизировать вручную:
После синхронизации можно подключиться к новой базе данных и убедиться, что туда выгрузилась информация из центральной базы:
Только сразу в новой периферийной базе заведите хотя бы одного пользователя с правами Администратора.
Настройка синхронизации в периферийной базе данных
В периферийной базе 1С настройка намного проще. Достаточно установить флажок «Синхронизация данных» и перейти по одноименной ссылке. И мы почти сразу попадаем в окно с кнопкой «Синхронизировать». Попробуем создать тестовую номенклатуру в периферийной базе и выгрузить ее в основную с помощью РИБ:
Как видно, идет полноценный двухсторонний обмен информации с префиксами информационных баз.
В заключение хочется добавить важное замечание. Изменения в конфигурации можно производить только в центральной базе данных. Эти изменения потом автоматически будут транслированы в периферийные базы.
В заключение рекомендуем видеоинструкцию по настройке РИБ в 1С на примере Управление Торговлей:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
Читайте также: