В процессе автоматизации розничной сети или филиальной структуры часто возникает задача организации одностороннего обмена данными. Представим типовую ситуацию: у нас есть Центральная база (ЦБ) «1С:Бухгалтерия предприятия 3.0» и несколько десятков периферийных информационных баз (ПБ) на торговых точках. Наша цель — настроить обмен так, чтобы все документы, созданные на торговых точках, беспрепятственно загружались в Центр, но при этом никакие документы из Центра не выгружались обратно в периферийные узлы. На первый взгляд, задача кажется простой, однако при стандартной настройке распределенной информационной базы (РИБ) администраторы сталкиваются с тем, что данные все равно продолжают мигрировать в обе стороны.
Давайте подробно разберем, почему так происходит, проанализируем технические нюансы работы платформы 1С и рассмотрим несколько проверенных способов решения этой проблемы — как без программирования, так и с доработкой конфигурации.
Многие начинающие специалисты пытаются решить задачу «в лоб»: создают сценарий обмена, в котором для Центральной базы устанавливают только «Получение данных», а для периферийных — только «Отправку данных». Однако при такой схеме система быстро дает сбой.
Выясним причину этой проблемы. Механизм РИБ жестко завязан на так называемое квитирование (подтверждение доставки сообщений). Когда база «А» отправляет данные в базу «Б», она ожидает получить в ответном файле техническое подтверждение — номер пакета, который база «Б» успешно приняла. Если Центральная база не будет отправлять ответные файлы сообщений, периферийная база никогда не узнает, что её данные были успешно загружены. В результате при каждом следующем сеансе обмена периферийная база будет повторно выгружать абсолютно все ранее созданные документы. Это приведет к колоссальному росту объема файлов обмена, перегрузке каналов связи и дублированию информации.
Таким образом, полностью заблокировать отправку сообщений из Центра в периферию нельзя. Ответные файлы отправлять необходимо, но они должны быть «пустыми» — содержать только заголовок с номером подтверждения и не нести в себе никаких зарегистрированных объектов (документов или справочников).
Рассмотрим самый простой способ, который не требует изменения конфигурации и позволяет решить задачу штатными средствами платформы 1С.
В конфигурации «1С:Бухгалтерия предприятия 3.0» рядом с кнопкой «Синхронизировать» есть специальная гиперссылка «Состав отправляемых данных». Разберем по шагам, как выполнить настройку:
Этот способ отлично подходит для разовой корректировки или оперативного вмешательства. Однако у него есть существенный минус: при создании новых документов в Центральной базе они снова будут автоматически регистрироваться к отправке. Чтобы этого избежать на постоянной основе, нам потребуется настроить правила регистрации.
Если конфигурация находится на поддержке и вносить изменения в код крайне нежелательно, идеальным решением будет редактирование Правил регистрации объектов (ПРО). Эти правила определяют, при каких условиях изменения того или иного объекта должны записываться на узлы планов обмена.
Проанализируем этот процесс подробнее:
ПередОбработкой.
Если ПланыОбмена.ГлавныйУзел() = Неопределено Тогда
// Мы находимся в Центральной базе, отменяем регистрацию для подчиненных узлов
Отказ = Истина;
КонецЕсли;
После этого сохраните правила, загрузите их обратно в конфигурацию через режим предприятия и выполните очистку текущих зарегистрированных изменений. Теперь документы, созданные в Центральной базе, просто не будут регистрироваться к отправке, а файлы обмена будут уходить пустыми, неся только технические номера квитанций.
Если ваша конфигурация снята с поддержки или находится в режиме доработки, наиболее надежным и «чистым» программным решением будет использование предопределенной процедуры модуля плана обмена.
Посмотрим на пример реализации. В модуле вашего плана обмена найдите или создайте предопределенный обработчик ПриОтправкеДанныхПодчиненному. Этот метод вызывается платформой непосредственно в момент записи объекта в файл обмена. Мы можем перехватить этот момент и принудительно запретить выгрузку данных.
Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента)
// Блокируем отправку документов и справочников из Центральной базы
ТипОбъекта = ТипЗнч(ЭлементДанных);
// Разрешаем отправку только системной информации и идентификаторов метаданных
Если ТипОбъекта = Тип("СправочникСсылка.ИдентификаторыОбъектовМетаданных") Тогда
// Системные данные пропускаем
Иначе
ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
КонецЕсли;
КонецПроцедуры
При использовании этого метода платформа 1С сформирует файл обмена, автоматически очистит зарегистрированные изменения в Центральной базе, отправит периферийному узлу подтверждение о получении его пакета, но сами данные Центра в файл записаны не будут. Это гарантирует абсолютную чистоту периферийных баз от документов Центра.
Внедряя односторонний обмен через РИБ, обязательно помните о критически важном техническом нюансе: обновлении конфигурации. В распределенных базах изменения структуры метаданных могут передаваться только сверху вниз — из Центральной базы в периферийные.
Если вы полностью заблокируете отправку любых данных, включая системные справочники и конфигурационные файлы, периферийные базы не смогут получить признак изменения конфигурации. При первой же попытке обмена после обновления Центра вы получите фатальную ошибку: Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Чтобы успешно обновлять конфигурацию в условиях жесткого одностороннего обмена, используйте один из двух подходов:
ПриОтправкеДанныхПодчиненному или временно отключите правила регистрации. Выполните один цикл обмена, обновите конфигурации в периферийных базах, после чего верните блокировку в исходное состояние./ResetMasterNode. После этого вручную загрузите в базу файл обновленной конфигурации (.cf), полученный из Центра. Затем с помощью встроенных обработок или кода восстановите связь с главным узлом.Если описанные выше сложности с квитированием и обновлением конфигурации кажутся вам слишком трудоемкими, настоятельно рекомендуем рассмотреть альтернативу технологии РИБ. Вы можете настроить обмен данными через универсальный формат EnterpriseData.
В отличие от жестких механизмов РИБ, синхронизация через универсальный формат изначально проектировалась для систем, живущих независимой жизнью. В настройках такой синхронизации в Центральной базе вы можете физически указать в правилах отправки: «Не выгружать данные». При этом в периферийных базах будет настроена полноценная выгрузка. Проблема квитирования здесь успешно решается на уровне Библиотеки стандартных подсистем (БСП) автоматически, без риска повторной отправки одних и тех же документов, а конфигурации баз при этом могут обновляться независимо друг от друга в любое удобное время.