Назад

Логическая репликация 1C:Предприятие 8

Исходный код

Подсистема “Механизм репликации” реализует логическую репликацию изменений данных для произвольных конфигураций 1С:Предприятие 8.

Концептуально подсистема опирается на функциональность логической репликации PostgreSQL. Реализация средствами 1С основана на подписках на события “ПередЗаписью”, “ПриЗаписи” и “ПередУдалением”. Сериализация изменений данных осуществляется при помощи формата JDTO (JSON data transfer object). Фиксация изменений выполняется в виде сообщений репликации в соответствующем регистре сведений подсистемы.

Основным назначением подсистемы “Механизм репликации” является интеграция с внешними по отношению к 1С:Предприятие 8 системами. Дальнейшее развитие подсистемы предполагает реализацию загрузки сообщений в формате JDTO в базы данных 1С. Для этого необходимо реализовать код десериализатора JDTO.

Для удобства интеграции с внешними системами планируется реализовать генератор JSON Schema для соответствующих объектов реплицируемой базы данных. Соответствующие документы в формате JSON Schema будут отдаваться внешней системе при помощи HTTP-сервиса.

Ключевые моменты:

  1. Репликация включается константой “МеханизмРепликацииИспользовать”.
  2. Настроить в плане обмена “МеханизмРепликации” код предопределённого узла (ЭтотУзел).
  3. Добавить хотя бы одного подписчика в план обмена “МеханизмРепликации” и назначить ему код, например “РИБ”.
  4. Добавление реплицируемых объектов в состав каких-либо планов обмена не требуется!
  5. Настроить состав подписок на события именно теми объектами, которые будут реплицироваться. Ненужные подписки - удалить.
  6. По желанию настроить формат сообщений для узлов-получателей в плане обмена “МеханизмРепликации”. По умолчанию используется формат JDTO.
  7. Доработка функциональности конфигурации может осуществляться в общем модуле “МеханизмРепликацииЭкспорт”.
  8. Конфигурация легко трансформируется в расширение и может быть использована именно так. Для настройки подписок на события при этом необходимо заимствовать соответствующие объекты основной конфигурации, к которой подключается расширение.
  9. Исходный код сериализатора JDTO обособлен в общем модуле “СериализаторJDTO” и может быть использован независимо от конфигурации.
  10. Фильтрация данных в текущей версии 1.0 не реализована. Реплицируется всё, что указано в подписках на события! Тем не менее фильтрация может быть реализована самостоятельно путём доработки экспортной процедуры “СформироватьМассивПолучателей” общего модуля “МеханизмРепликацииЭкспорт”.
  11. Любые ошибки выполнения перехватываются и фиксируются в журнале регистрации 1С. Основной код конфигурации при этом продолжает выполняться, но могут быть потерянные изменения. Следует это учитывать при доработках кода подсистемы под свои нужды!
  12. При импорте данных в реплицируемую конфигурацию предусмотрено программное отключение механизма репликации при помощи установки дополнительного свойства загружаемого объекта “НеИспользоватьМеханизмРепликации”. Проверка наличия этого флага выполняется в подписках на события “ПередЗаписью”.
ПрочитатьИмпортируемыеДанныеВОбъект(Данные, Объект);
Объект.ДополнительныеСвойства.Вставить("НеИспользоватьМеханизмРепликации");
Объект.Записать();

Заметки на будущее:

  1. Механизм отслеживания модифицированности объекта пока что не реализован. Он нужен в тех случаях, когда объект фактически не изменился с точки зрения данных, и по этой причине его репликация нежелательна, чтобы не увеличивать нагрузку на систему приёмника. Этот типовой механизм дедупликации данных можно интегрировать самостоятельно, изменив процедуру “ПроверитьМодифицированностьОбъекта” общего модуля “МеханизмРепликацииЭкспорт”. Типовой алгоритм можно найти в библиотеке стандартных подсистем (БСП) от 1С. Например его можно подсмотреть в функции “ОбъектМодифицированДляПланаОбмена” общего модуля “ОбменДаннымиРегистрацияСервер”.
  2. Для снижения нагрузки на базу-источник репликации возможно реализовать регистрацию изменений объектов по ссылкам. Это позволяет уменьшить продолжительность транзакции записи объекта за счёт того, что не выполняется сериализация данных объекта в формат JSON. Эта методика аналогична типовой реализации обменов данными 1С, основанной на планах обмена. Зарегистрированные ссылки в последствии используются при выгрузке сообщений обмена для получения текущих данных объекта (актуального снимка). При этом теряется история изменений, но в большинстве случаев она и не требуется.

Код десериализации для 1С пока что не реализован!

Регистр сведений “МеханизмРепликацииИсходящаяОчередь”

Свойство Назначение Тип данных Описание
МоментВремени Измерение Число(15,0) Время в миллисекундах для упорядочивания очереди по FIFO
Идентификатор Измерение УникальныйИдентификатор Ссылка на объект, регистратор или произвольный UUID (для независимых регистров сведений). Значение измерения генерируется в процедуре “СформироватьИдентификаторСообщения” общего модуля “МеханизмРепликацииЭкспорт”.
Отправитель Ресурс Строка(36) Код или идентификатор отправителя, реплицируемой базы данных. Код берётся из предопределённого узла плана обмена “МеханизмРепликации”.
Получатели Ресурс Строка(0) Коды получателей в формате CSV. Коды берутся из плана обмена “МеханизмРепликации”.
ТипСообщения Ресурс Строка(1024) Тип сообщения репликации. По умолчанию равно значению, которое возвращает вызов метода “ПолноеИмя” объекта метаданных. Например, “Справочник.Номенклатура”.
ТелоСообщения Ресурс Строка(0) Тело сообщения в указанном в плане обмена “МеханизмРепликации” формате. По умолчанию это формат JDTO.
Заголовки Реквизит Строка(0) Заголовки (метаданные) сообщения в формате JSON. По умолчанию это структура, имеющая следующие значения: версия схемы данных (конфигурации), тип операции DML базы данных 1С и формат тела сообщения. За формирование заголовков отвечает процедура “СформироватьЗаголовкиСообщения” общего модуля “МеханизмРепликацииЭкспорт”.
ДатаВремя Реквизит Дата и время Время формирования сообщения репликации. Используется текущее время сервера кластера 1С.

Наверх