Синхронизация данных между типовыми конфигурациями, такими как Управление торговлей 11 и Бухгалтерия предприятия 3.0, работающими на базе Библиотеки стандартных подсистем (БСП), — это сложный процесс. Часто после завершения обмена возникает необходимость увидеть не просто статус «Успешно», а конкретный список документов, которые были созданы или обновлены в базе. В типовом функционале «из коробки» такой детальный отчет по каждому объекту зачастую отсутствует, а использование Журнала регистрации для этих целей крайне неудобно из-за огромного объема лишней информации и низкой производительности при выборке.
В этой статье мы подробно разберем, как решить задачу получения списка синхронизированных документов, проанализируем внутренние механизмы 1С и предложим варианты реализации собственного инструмента мониторинга.
Прежде чем переходить к разработке своего решения, давайте проанализируем, какие данные система уже собирает в процессе работы через Универсальный формат (EnterpriseData). Нам важно понимать, где фиксируются связи между объектами разных информационных баз.
Одним из ключевых объектов является регистр сведений СоответствияОбъектовИнформационныхУзлов. Рассмотрим подробнее его назначение. В этом регистре система хранит пары соответствий: ссылку на объект в текущей базе и уникальный идентификатор (GUID) этого же объекта во внешней базе. При первой загрузке документа запись в этом регистре создается автоматически.
Однако у этого метода есть существенное ограничение: регистр фиксирует только факт «знакомства» систем с объектом. Если документ будет изменен в базе-источнике и повторно загружен, дата записи в регистре соответствий может не обновиться, так как связь уже установлена. Таким образом, использовать этот регистр для получения списка документов, загруженных именно в последнем сеансе, без дополнительных доработок не получится.
Также проанализируем регистр ПубличныеИдентификаторыОбъектов. Он используется при обмене через EnterpriseData для сопоставления объектов по полям поиска. Информация в нем также может быть полезна для технического анализа, но она не дает истории загрузок.
Самым эффективным и «чистым» способом получения точного списка загруженных документов является использование механизма расширений конфигурации. Нам необходимо перехватить момент окончания загрузки каждого объекта и зафиксировать этот факт в своем регистре.
Разберем по шагам, как это реализовать:
ЛогЗагрузкиОбъектов. В нем нам понадобятся следующие измерения и ресурсы:
МенеджерОбменаЧерезУниверсальныйФормат.Нам нужно найти или использовать процедуру ПослеЗагрузкиОбъекта. В расширении мы можем применить аннотацию &После. Посмотрим на пример программного кода:
&После("ПослеЗагрузкиОбъекта")
Процедура ИмяПрефикс_ПослеЗагрузкиОбъекта(Объект, ДанныеXDTO, КомпонентыОбмена)
// Проверяем, является ли объект документом
Если Документы.ТипВсеСсылки().СодержитТип(ТипЗнч(Объект)) Тогда
МенеджерЗаписи = РегистрыСведений.ЛогЗагрузкиОбъектов.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Объект = Объект.Ссылка;
МенеджерЗаписи.ДатаЗагрузки = ТекущаяДата();
МенеджерЗаписи.УзелИнформационнойБазы = КомпонентыОбмена.УзелИнформационнойБазы;
// Определяем, был ли это новый объект
// (Для этого можно проверить версию объекта или использовать дополнительные свойства)
МенеджерЗаписи.ЭтоНовыйОбъект = Объект.ЭтоНовый();
МенеджерЗаписи.Записать();
КонецЕсли;
КонецПроцедуры
Этот метод позволяет фиксировать абсолютно все успешные загрузки в режиме реального времени. После чего построение отчета станет тривиальной задачей — достаточно будет сделать запрос к созданному регистру сведений за определенный период.
Если задача стоит разово или вы не хотите вносить изменения в структуру базы, проанализируем ситуацию с XDTO-логами. В настройках синхронизации данных или через параметры запуска можно включить режим отладки обмена.
При включенной отладке система сохраняет входящие XML-файлы сообщений обмена. Выясним причину, почему это может быть полезно: в файле Message_..._...xml содержатся все данные в формате EnterpriseData. Мы можем программно или вручную разобрать этот файл, чтобы увидеть перечень всех GUID и типов объектов, которые были переданы.
Для программного разбора файла сообщения можно использовать следующий подход:
ЧтениеXML.ФабрикаXDTO для чтения данных.Этот способ сложнее в реализации, но он позволяет получить данные даже за прошлые периоды, если файлы обмена сохранились в каталоге обмена или во временных папках сервера.
Не стоит забывать и о встроенных возможностях. В разделе Администрирование — Синхронизация данных — Настройки синхронизации выберите нужный узел и посмотрите меню «Отчеты». Там присутствует отчет Анализ синхронизации данных.
Рассмотрим подробнее его функционал. В основном он предназначен для отображения конфликтов и коллизий (когда объект был изменен одновременно в двух базах). Однако, если настроить варианты отчета, в некоторых релизах можно увидеть статистику по успешно принятым данным. К сожалению, детализация до конкретного документа там реализована не всегда удобно, но как быстрый способ первичного анализа этот вариант стоит рассмотреть.
Рассмотрим еще один вариант, предложенный участниками обсуждения: создание внешнего отчета с подключением к другой базе через COM-соединение. Этот метод будет полезен, если вам нужно не просто знать, что документ загрузился, а сравнить его состояние в двух базах.
Алгоритм работы такого отчета:
V83.COMConnector.СоответствияОбъектовИнформационныхУзлов ищем соответствующие ссылки по идентификаторам базы-источника.Этот метод не требует изменения конфигурации, но требует наличия прав доступа к обеим базам и может работать медленно на больших объемах данных.
Проанализировав все доступные способы, можно сделать следующие выводы:
ПослеЗагрузкиОбъекта.СоответствияОбъектовИнформационныхУзлов по дате изменения (если она фиксируется).Выбор конкретного метода зависит от ваших технических возможностей и того, насколько часто требуется получать подобную отчетность. Внедрение собственного лога загрузки в расширении — самый надежный путь для системного контроля качества синхронизации данных.