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

← На главную

В современной практике разработки на платформе 1С часто возникает задача разделения зон ответственности между различными информационными базами. Традиционный подход с использованием синхронизации данных (через БСП или универсальные обмены) подразумевает полное копирование информации. Однако это ведет к избыточности: одни и те же данные (например, ФИО физических лиц) хранятся и редактируются в разных местах, что может привести к их рассинхронизации. Рассмотрим альтернативный подход — получение данных «по требованию» из мастер-системы.

Архитектурная концепция: Отказ от дублирования

Основная идея заключается в том, чтобы хранить в ведомой базе (где ведутся договоры) не сам справочник ФизическиеЛица со всеми его реквизитами, а лишь уникальный идентификатор (GUID) этого объекта из ведущей базы. Разберем по шагам, как это реализовать и с какими трудностями мы можем столкнуться.

Шаг 1. Организация связи между объектами

Для того чтобы система понимала, к какому физлицу относится договор, нам необходимо хранить ссылку. Поскольку прямой ссылки между базами SQL не существует, мы добавим в документ Договор или в справочник-заглушку реквизит ИдентификаторИсточника с типом Строка (для хранения GUID).

Проанализируем сценарий: при создании договора пользователь выбирает физлицо. В этот момент мы можем либо обращаться к списку во внешней базе через HTTP-сервис, либо хранить в текущей базе минимальный набор данных для поиска.

Шаг 2. Получение данных через HTTP-сервисы

Это наиболее гибкий способ. В базе-источнике создается HTTP-сервис, который по переданному GUID возвращает структуру данных (ФИО, паспортные данные и т.д.) в формате JSON. Рассмотрим пример кода на стороне базы-приемника для получения представления физического лица:


Функция ПолучитьДанныеФизЛица(Идентификатор)
    Запрос = Новый HTTPЗапрос("/hs/PhysicalPersons/v1/getData?id=" + Идентификатор);
    Соединение = Новый HTTPСоединение("server_address", , "user", "password");
    
    Попытка
        Ответ = Соединение.Получить(Запрос);
        Если Ответ.КодСостояния = 200 Тогда
            ЧтениеJSON = Новый ЧтениеJSON;
            ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
            Данные = ПрочитатьJSON(ЧтениеJSON);
            Возврат Данные.Представление;
        КонецЕсли;
    Исключение
        Возврат "Ошибка получения данных";
    КонецПопытки;
КонецФункции

Шаг 3. Использование встроенного интерфейса OData

Если мы не хотим писать собственные HTTP-сервисы, проанализируем возможности платформы по использованию OData (Rest API). В базе-источнике достаточно опубликовать информационную базу на веб-сервере и разрешить доступ к конкретным метаданным. Тогда получение ФИО будет сводиться к простому GET-запросу к стандартному интерфейсу 1С.

Проблема 1: Ссылочная целостность и удаление

Выясним причину, по которой многие опасаются такого подхода. Если в мастер-базе физическое лицо будет удалено, база с договорами об этом «не узнает». Ссылка станет битой. Чтобы этого избежать, рассмотрим два варианта:

Мягкое удаление: В базе-источнике запрещается физическое удаление объектов, имеющих связи, либо используется пометка на удаление.
Оповещения (Webhooks): База-источник при попытке удаления объекта делает запрос в базу-приемник, чтобы проверить наличие связанных договоров. Это сложно в реализации, но гарантирует целостность.

Проблема 2: Производительность и транзакции

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

Решение проблемы скорости: Кэширование и асинхронность

Чтобы пользователь не ждал ответа от сервера при каждом открытии формы, применим гибридную схему:

Создадим в базе договоров справочник-зеркало ФизическиеЛицаКэш.
При обращении система сначала ищет данные в локальном кэше.
Если данных нет или они устарели (например, созданы более суток назад), запускается асинхронное обновление данных из мастер-базы.

Проблема 3: Отчеты и СКД

Разберем ситуацию с построением отчетов. Если данных о ФИО физически нет в SQL-таблицах текущей базы, вы не сможете выполнить запрос типа ВЫБРАТЬ Договоры.ФизЛицо.ФИО. Система компоновки данных (СКД) не умеет «ходить» по HTTP-ссылкам внутри запроса.

Для решения этой проблемы рассмотрим механизм Внешних источников данных. Если обе базы находятся в одном контуре, вы можете подключить таблицу физических лиц напрямую через ODBC. В этом случае 1С будет видеть внешнюю таблицу как родной справочник, и вы сможете использовать ее в любых отчетах без потери производительности.

Итоги и рекомендации

Подход с получением данных без синхронизации — это шаг в сторону сервисно-ориентированной архитектуры (SOA). Рассмотрим краткий чек-лист для реализации:

Используйте GUID в качестве ключа связи.
Реализуйте кэширование данных на стороне приемника для обеспечения работы отчетов и быстрого поиска.
Для массового получения данных (например, для заполнения списка) используйте пакетные запросы к HTTP-сервису, чтобы не плодить сотни мелких соединений.
Помните о юридических рисках: если данные о физлице будут безвозвратно удалены из источника (например, по требованию закона о персональных данных), у вас должен остаться «снимок» информации в договоре на дату его заключения.

Таким образом, идея автора темы вполне жизнеспособна и является профессиональным подходом к проектированию распределенных систем, если учитывать ограничения платформы 1С в части построения запросов и работы транзакций.