Продвинутый обмен с 1с
В своих публикациях "Планы обмена 1С" и "Анализ блокировок СУБД: таблица изменений плана обмена 1С" я подробно анализирую архитектуру планов обмена 1С. Этот типовой механизм обмена данными имеет ряд существенных недостатков, которые особенно ярко проявляются при интенсивных обменах в больших информационных системах. Для преодоления этих недостатков возникает вопрос об использовании альтернативных механизмов обмена данными.
На рынке существует достаточное количество известных и зарекомендовавших себя с хорошей стороны решений, в том числе от самой фирмы 1С. Кроме этого постоянно появляются всё новые и новые "самоделки". В данной публикации они обсуждаться не будут.
Целью же данной публикации является желание разобраться каким образом можно реализовать оптимальное решение и предложить свой взгляд на решение проблемы.
Забегая вперёд, я хочу сказать, что методика использования регистров сведений в качестве таблиц регистрации изменений имеет свои недостатки и является, по моему мнению, не полным решением проблемы.
Информационная база (узел обмена) 1С выполняет только три функции:
- регистрация изменений объектов 1С;
Наиболее важным требованием является то, что любые операции по обмену данными должны выполняться без ожиданий на блокировках СУБД!
Кроме этого, хорошо было бы иметь возможность управлять регистрацией изменений, составом объектов 1С, участвующих в обмене данными, без изменения конфигурации узла обмена 1С.
Подробнее о том какие бывают системы отслеживания изменений, а также чем они отличаются друг от друга, можно ознакомиться в моей публикации "Планы обмена 1С" в разделе " Основные техники регистрации изменений ".
Немного подробнее о видах репликации можно узнать из моей публикации " Размышления о регистрации изменений в обмен " в разделе "Способ репликации".
Для ссылочных типов данных код регистрации и публикации изменения разделяется на два обработчика событий "ПередЗаписью" и "ПриЗаписи" потому, что только в обработчике "ПриЗаписи" уже сформированы ссылка, версия данных, код справочника или номер документа.
Кроме этого в обработчике "ПередЗаписью" возможно реализовать логику проверки фактического изменения данных объекта при помощи, например, следующего кода:
Для табличных типов данных (наборов записей) обработчик "ПередУдалением" не используется. Разделение кода на два обработчика "ПередЗаписью" и "ПриЗаписи" не обязательно и можно использовать только обработчик "ПриЗаписи".
Для управления регистрацией и публикацией изменений удобно использовать внешние, по отношению к узлу обмена 1С, средства. Это позволяет менять правила "на лету" без изменения конфигурации 1С. Кроме этого такие настройки позволяют управлять гранулярностью регистрации и публикации изменений до уровня реквизитов объектов.
Более того настройками может управлять любая другая система обмена данными, не зависящая от платформы 1С или кода узла обмена 1С. Таким образом, в том числе, достигается малая связанность информационных систем друг от друга.
Например, это может быть файл настроек в формате JSON следующего содержания:
Другими словами при генерации кода справочника, например, в кластере 1С коды элементов могут совпадать, а второе поле индекса "Ссылка" (_ IDRRef ) не гарантирует правильную последовательность событий в пределах одного кода справочника-очереди .
Таким образом, я считаю, что средствами 1С реализовать абсолютно корректную последовательность публикации изменений объектов 1С, особенно в контексте репликации транзакций, невозможно. Об этом, а также о том, каким образом это можно преодолеть средствами SQL Server наиболее дешёвым способом, я писал в своей публикации "Планы обмена 1С" в разделе " Репликация транзакций, как решение проблемы целостности данных ".
Хотелось бы ещё отметить, что использование справочника позволяет в некоторых случаях использовать его реквизит "ВерсияДанных", о чём я буду писать ниже.
Значение этого поля генерируется СУБД автоматически каждый раз когда выполняется изменение данных . В случае SQL Server это значение всегда увеличивается на единицу и уникально в пределах базы данных СУБД . Данное поле имеет тип данных timestamp или rowversion в более новых версиях SQL Server, однако по сути своей это binary(8). Поэтому при выгрузке значения этого поля в JSON мы получим строковое представление в формате BASE64.
Текущее значение версии данных для конкретной базы данных СУБД можно посмотреть при помощи следующего кода SQL:
Для демонстрации практической пригодности изложенных в данной публикации идей разработана подсистема DaJet Exchange для 1С.
Конфигурация 1C DaJetExchange и все необходимые для её использования материалы опубликованы на GitHub: DaJet Exchange.
Моя позиция заключается в том, что планы обмена 1С плохо работают при интенсивных обменах в больших информационных системах. Альтернативных решений, реализованных исключительно средствами 1С и решающих все проблемы целостного обмена данными, не существует. Практический пример DaJet Exchange является, наверное, самым простым компромиссным решением для платформы 1С:Предприятие 8 и не претендует на универсальность. Я вообще не верю в универсальные решения. Я уверен, что надёжный обмен данными в контексте 1С необходимо реализовывать гибридными средствами, используя в том числе средства СУБД и других программных платформ. Лицензионное соглашение для 1С:Предприятие 8 в части работы с СУБД мешает развитию этих решений. Вполне возможно, что я ошибаюсь, но я всё время учусь, ищу и открыт для конструктивного диалога =)
Читайте также: