Как реализовать синхронизацию баз 1С и мультиязычность данных без применения распределенных транзакций?

← На главную

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

Почему синхронная запись в 10 баз 1С в одной транзакции невозможна

Попытка реализовать распределенную онлайн-транзакцию для 10 баз 1С (через COM-соединения, SOAP или HTTP-сервисы) сталкивается с несколькими фундаментальными ограничениями:

Отсутствие двухфазного коммита (2PC / XA-транзакций): В платформе 1С:Предприятие нет встроенного координатора распределенных транзакций. Если при записи документа или справочника происходит вызов сервисов 9 других баз, и хотя бы в одной из них произойдет ошибка (блокировка, сбой сети, отказ СУБД), платформа не сможет автоматически откатить изменения в тех базах, где транзакция уже была завершена.
Взаимные блокировки и каскадное падение производительности: При синхронном вызове время фиксации транзакции в исходной базе складывается из времени обработки во всех остальных 9 базах-приемниках. Таблицы СУБД остаются заблокированными на всё время выполнения сетевых запросов. В условиях активной работы пользователей это мгновенно приводит к массовым таймаутам и взаимным блокировкам (Deadlocks).
Неприменимость репликации на уровне СУБД: Настройка транзакционной репликации средствами MS SQL Server или PostgreSQL непосредственно между таблицами баз 1С категорически запрещена. Кластер серверов 1С кэширует метаданные, структуры сеансов и внутренние идентификаторы в своей памяти. Прямая запись данных в СУБД в обход сервера 1С приводит к рассинхронизации кэша, повреждению ссылочной целостности (GUID) и сбоям в нумерации.

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

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

Подход 1. Хранение переводов в независимом регистре сведений (стандарт БСП)

Наиболее надежный и производительный подход, применяемый в типовых конфигурациях (1С:ERP, 1С:Комплексная автоматизация). Основные реквизиты объекта хранятся на базовом языке, а все переводы выносятся в отдельный регистр сведений.

Создадим независимый регистр сведений ЗначенияМультиязычныхРеквизитов со следующей структурой:

Измерение Объект (Тип: ЛюбаяСсылка) — ссылка на элемент справочника или документ.
Измерение ИмяРеквизита (Тип: Строка) — имя переводимого реквизита (например, "Наименование").
Измерение Язык (Тип: СправочникСсылка.Языки) — целевой язык.
Ресурс Значение (Тип: Строка) — переведенный текст.

Подмена представлений на лету через события модуля менеджера

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


// Модуль менеджера справочника Номенклатура

Процедура ОбработкаПолученияПолейПредставления(Поля, СтандартнаяОбработка)
    
    Поля.Добавить("Ссылка");
    Поля.Добавить("Наименование");
    СтандартнаяОбработка = Ложь;
    
КонецПроцедуры

Процедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка)
    
    ТекущийЯзык = ПараметрыСеанса.ТекущийЯзыкПользователя;
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |	ЗначенияМультиязычныхРеквизитов.Значение КАК Перевод
        |ИЗ
        |	РегистрСведений.ЗначенияМультиязычныхРеквизитов КАК ЗначенияМультиязычныхРеквизитов
        |ГДЕ
        |	ЗначенияМультиязычныхРеквизитов.Объект = &Ссылка
        |	И ЗначенияМультиязычныхРеквизитов.ИмяРеквизита = ""Наименование""
        |	И ЗначенияМультиязычныхРеквизитов.Язык = &Язык";
        
    Запрос.УстановитьПараметр("Ссылка", Данные.Ссылка);
    Запрос.УстановитьПараметр("Язык", ТекущийЯзык);
    
    Выборка = Запрос.Выполнить().Выбрать();
    Если Выборка.Следующий() И НЕ ПустаяСтрока(Выборка.Перевод) Тогда
        Представление = Выборка.Перевод;
    Иначе
        Представление = Данные.Наименование; // Базовое наименование
    КонецЕсли;
    
    СтандартнаяОбработка = Ложь;
    
КонецПроцедуры

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

Подход 2. Разделение данных через общие реквизиты

Платформа 1С:Предприятие поддерживает механизм разделения данных. Разберем, как его использовать для изоляции объектов по языкам:

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

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

Асинхронный обмен для распределенных систем (Event-Driven Architecture)

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

Настраивается объект конфигурации ПланОбмена без использования режима РИБ. В состав плана обмена включаются только необходимые объекты.
Для передачи данных используются HTTP-сервисы и формат JSON или брокеры сообщений (RabbitMQ, Apache Kafka, 1С:Шина).
При изменении объекта в исходной базе зарегистрированные изменения отправляются в очередь сообщений. База-приемник обрабатывает входящий пакет в своей локальной транзакции.
В случае сбоя или ошибки блокировки в базе-приемнике сообщение отправляется в очередь повторной обработки (DLQ), не препятствуя работе пользователей в других базах.

Таким образом, отказ от распределенных транзакций в пользу консолидации баз или асинхронной событийно-ориентированной архитектуры гарантирует высокую скорость работы и стабильность системы.