Задача по настройке синхронизации данных между различными конфигурациями 1С, особенно между типовой, такой как 1С ЗУП, и нетиповой (самописной) конфигурацией, является одной из наиболее распространенных и вместе с тем комплексных задач в сфере автоматизации бизнеса. Давайте рассмотрим подробный алгоритм действий для настройки одностороннего обмена данными, фокусируясь на передаче информации из базы-источника (1С ЗУП) в базу-приемник (нетиповая конфигурация), с учетом использования планов обмена и конфигурации "Конвертация данных 2.1".
Прежде чем приступать к любым изменениям, мы настоятельно рекомендуем сделать резервные копии обеих информационных баз. Это критически важный шаг, который поможет избежать потери данных в случае непредвиденных ошибок в процессе настройки или отладки.
Также важно убедиться, что ваша нетиповая конфигурация-приемник уже имеет подключенную Библиотеку Стандартных Подсистем (БСП) в необходимом объеме для работы с механизмами планов обмена. Наличие БСП значительно упрощает интеграцию, предоставляя готовые механизмы для работы с узлами обмена, регистрацией изменений и загрузкой правил.
Первым шагом нам необходимо создать планы обмена в обеих конфигурациях: как в источнике (1С ЗУП), так и в приемнике (нетиповая база). Ключевое требование — названия планов обмена должны быть идентичными в обеих базах. Это позволяет системе корректно идентифицировать узлы обмена, относящиеся к одному и тому же сценарию синхронизации.
В ЗУП вы можете взять за основу один из существующих типовых планов обмена, например, предназначенный для обмена с 1С:Бухгалтерией предприятия, скопировав его структуру или создав новый с нуля. В нетиповой конфигурации вам нужно будет создать аналогичный план обмена, также обеспечив идентичность названия.
Для создания плана обмена, перейдем в конфигураторе в ветку ПланыОбмена и создадим новый объект.
В каждый из созданных планов обмена, как в базе-источнике, так и в базе-приемнике, нам потребуется добавить пустой макет. Этот макет должен иметь строго определенное имя: ПравилаОбмена. Этот макет играет роль контейнера для правил обмена, которые мы впоследствии создадим в "Конвертации данных". Его наличие предотвращает частую ошибку "неправильный формат файла обмена" на ранних этапах, когда система пытается найти этот макет для хранения правил.
Далее мы определяем, какие объекты метаданных будут участвовать в синхронизации. Этот шаг выполняется в конфигураторе для каждого плана обмена:
Авторегистрация объектов: Обратите внимание на свойство Авторегистрация у объектов метаданных, включенных в план обмена. Если оно установлено в Истина, система автоматически регистрирует изменения объекта при его записи. Если же вы хотите более тонко управлять регистрацией (например, регистрировать только проведенные документы или объекты по определенным условиям), свойство Авторегистрация можно установить в Ложь, а затем программно регистрировать изменения, используя метод менеджера планов обмена ЗарегистрироватьИзменения() в обработчиках событий объекта, например, ПередЗаписью или ПриЗаписи.
// Пример программной регистрации изменений
МенеджерПланаОбмена.ЗарегистрироватьИзменения(УзелОбмена, СсылкаНаОбъект);
Если в вашей нетиповой базе подключена БСП, она предоставляет унифицированный механизм для работы с обменами данными, включая формы настройки и команды. Нам необходимо "сообщить" БСП о существовании нашего нового плана обмена. Для этого мы интегрируем наш план обмена в состав типов команд БСП, которые отвечают за операции, такие как "Загрузить правила", "Запустить обмен" и другие. Обычно это достигается путем поиска ссылок на существующие планы обмена, интегрированные в БСП, и добавления туда ссылки на наш новый план обмена. Это позволит нам использовать стандартные формы и обработки БСП для управления обменом.
После создания планов обмена в конфигураторе нам необходимо создать их экземпляры (узлы) в режиме "Предприятие" для каждой из баз. Узел плана обмена — это конкретное представление обмена в данной информационной базе. Для ЗУП, как правило, узлы обмена создаются через стандартные подсистемы настройки обмена (например, "Настройки синхронизации данных"). В нетиповой конфигурации, если интегрированы стандартные подсистемы БСП, создание узла также будет доступно через специализированную форму настройки обменов.
Каждый узел обмена будет иметь свой уникальный код и наименование, а также указывать на корреспондента (т.е. на другой узел обмена, с которым он взаимодействует).
Для того чтобы система БСП разрешила запускать обмен через свои стандартные формы, необходимо проставить признак завершения настройки для вновь созданных узлов в регистре сведений ОбщиеНастройкиУзловИнформационныхБаз. Это подтверждает, что первоначальная настройка узла выполнена и он готов к работе. Без этого признака БСП может блокировать запуск обмена, считая, что узел находится в процессе настройки.
Конфигурация "Конвертация данных 2.1" (КД 2.1) является основным инструментом для создания правил обмена между различными конфигурациями. Перед тем как начать создавать правила, нам необходимо загрузить описания метаданных обеих конфигураций в КД 2.1. Это делается при помощи специализированных обработок, которые поставляются вместе с КД 2.1. Эти обработки позволяют выгрузить структуру всех объектов метаданных (справочники, документы, регистры, реквизиты и т.д.) из рабочей базы в XML-файл, который затем загружается в КД 2.1.
Мы загружаем метаданные как из ЗУП (конфигурации-источника), так и из нетиповой базы (конфигурации-приемника).
Этот этап является одним из наиболее трудоемких и ответственных. В КД 2.1 мы создаем правила обмена, которые определяют, как данные будут преобразовываться при переходе из одной конфигурации в другую.
Для базы-источника (ЗУП) мы создаем полноценные правила обмена, включающие ПВД, ПРО и ПКО. Для базы-приемника (нетиповой) правила конвертации (ПКО) могут быть пустыми или минимальными, поскольку она только принимает данные и не конвертирует их для отправки обратно в этом сценарии одностороннего обмена.
После создания и отладки правил в КД 2.1, мы выгружаем их в виде комплектов файлов XML. Обычно создаются два комплекта: один для загрузки в конфигурацию-источник, другой – для загрузки в конфигурацию-приемник. Эти комплекты будут содержать все наши ПКО, ПРО и ПВД.
Выгруженные комплекты правил (XML-файлы) необходимо загрузить в соответствующие базы. Это делается через формы настройки синхронизации, предоставляемые БСП, или специализированные обработки. Каждый узел обмена получает свой набор правил.
После загрузки правил, мы должны убедиться, что изменения объектов, включенных в состав плана обмена источника, действительно регистрируются для обмена. Это можно проверить в регистре сведений ИзмененияДляОбмена или через стандартные средства отладки БСП. Если регистрация происходит корректно, мы можем запускать обмен. Запуск обмена обычно осуществляется через форму "Настройка синхронизации данных" в пользовательском режиме, выбирая соответствующий узел и команду "Выполнить обмен".
Если при загрузке данных в приемнике вы столкнетесь с ошибкой "неправильный формат файла обмена", прежде всего, перепроверьте, что в обоих планах обмена присутствует пустой макет с названием ПравилаОбмена. Если проблема сохраняется, возможно, причина кроется в различиях версий БСП между конфигурациями. В этом случае, приемник может некорректно обрабатывать специфические теги в фигурных скобках, такие как {ДанныеПоФоновомуОбмену}. Решением может быть модификация обработки КонвертацияОбъектовИнформационныхБаз в приемнике для пропуска чтения проблемных тегов.
Ваш запрос на получение подтверждения от базы-приемника ("Данные получила/Изменения сохранены") в рамках одностороннего обмена является логичным для контроля процесса. В условиях чисто одностороннего обмена, когда приемник не инициирует отправку своих изменений, стандартные механизмы двусторонней синхронизации здесь не применимы. Однако мы можем реализовать это нестандартными путями:
ЖурналПринятыхОбменов, где будет фиксироваться информация о каждом успешно принятом файле обмена: дата и время приема, номер сообщения, количество принятых объектов.В процессе настройки и эксплуатации обменов данными мы часто сталкиваемся с различными сложностями. Разберем наиболее распространенные:
ПравилаОбмена отсутствует или если есть сильные различия в версиях БСП, обработка КонвертацияОбъектовИнформационныхБаз может сталкиваться с проблемами при чтении специфических тегов. Отладка этой обработки может помочь выявить конкретный проблемный тег и, возможно, решить проблему его пропуском.Авторегистрация у объектов метаданных в составе плана обмена.Правила регистрации объектов (ПРО).ЗарегистрироватьИзменения().Для обеспечения регулярного и надежного обмена данными, особенно при большом объеме или высокой частоте изменений, необходимо продумать автоматизацию и оптимизацию:
Настройка синхронизации — это итеративный процесс. Мы начинаем с минимального набора данных, тщательно отлаживаем его, а затем постепенно расширяем состав обмениваемых объектов. Использование отладчика и документации (ИТС) будет вашими верными помощниками на всех этапах.