При разработке интеграций между системами часто возникает задача выгрузки данных во внешние форматы, такие как DBF, Excel или TXT. Традиционный подход с отбором документов по периоду или вручную часто оказывается неэффективным: можно пропустить изменения или выгрузить лишние данные. В этой статье мы разберем, как адаптировать мощный механизм Планов обмена 1С для работы с форматом DBF, обеспечив надежную регистрацию изменений и автоматизацию процесса.
Рассмотрим ситуацию: у нас есть настроенная выгрузка в DBF, но мы хотим, чтобы система сама "знала", какие объекты изменились с момента прошлой выгрузки. План обмена в 1С — это не просто средство для XML-синхронизации. Это прежде всего таблица регистрации изменений. Используя её, мы получаем:
Проанализируем шаги, необходимые для реализации такой схемы.
Для начала создадим в конфигураторе новый объект метаданных ПланОбмена. Назовем его, например, ОбменСВнешнейСистемойDBF. В свойствах плана обмена на закладке Состав необходимо указать все объекты (справочники, документы), которые должны попадать в выгрузку. Для каждого объекта установим режим Авторегистрация в значение Разрешить.
Важный нюанс: как было отмечено в обсуждении, "фиктивная" синхронизация — это просто термин. На самом деле мы используем только механизм регистрации. Нам не нужно настраивать стандартные узлы обмена через интерфейс БСП, если мы планируем писать код выгрузки самостоятельно. Достаточно создать один узел (приемник), для которого будут копиться изменения.
В коде обработки выгрузки нам нужно получить список всех объектов, которые были изменены. Разберем, как это сделать правильно. Мы будем использовать метод ВыбратьИзменения. Рассмотрим пример кода:
// Определяем узел-приемник, для которого зарегистрированы изменения
УзелПриемник = ПланыОбмена.ОбменСВнешнейСистемойDBF.НайтиПоКоду("001");
// Начинаем выборку изменений
ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(УзелПриемник, НомерСообщения);
Пока ВыборкаИзменений.Следующий() Цикл
ДанныеОбъекта = ВыборкаИзменений.Получить();
// Проверяем тип данных
Если ТипЗнч(ДанныеОбъекта) = Тип("УдалениеОбъекта") Тогда
// Обработка удаления (например, запись в DBF признака удаления)
Продолжить;
КонецЕсли;
// Выполняем запись данных в DBF
ЗаписатьОбъектВDBF(ДанныеОбъекта);
КонецЦикла;
Обратите внимание на НомерСообщения. Это критически важный параметр для обеспечения целостности данных. Метод ВыбратьИзменения помечает выбранные записи этим номером, что позволяет нам позже подтвердить их успешную обработку.
Одной из главных трудностей при работе с DBF является передача информации об удалении объектов в 1С. Поскольку DBF — это плоская таблица, принимающая сторона не узнает об удалении документа в источнике, если мы просто перестанем его присылать. Выясним причину, почему это важно: план обмена регистрирует факт удаления объекта как объект типа УдалениеОбъекта, содержащий только ссылку (УИД).
Проанализируем решение: при обходе выборки изменений, если мы встречаем УдалениеОбъекта, мы должны записать в файл DBF специальную строку, где в поле DELETED (его нужно создать заранее) будет стоять истина, а в поле ID — идентификатор удаленного объекта. Это позволит принимающей базе корректно обработать ситуацию.
Теперь рассмотрим самый важный момент — когда снимать регистрацию с объектов? В сообщениях форума предлагалось делать это сразу после записи. Однако, это рискованный путь. Если файл DBF не удастся отправить по сети или принимающая сторона не сможет его прочитать из-за ошибки формата, данные в источнике уже не будут помечены как измененные, и при следующем запуске они не выгрузятся.
Разберем более надежный алгоритм:
НомерСообщения.НомерСообщения в лог или отправляем его вместе с файлом.Код для подтверждения получения (снятия регистрации):
// Снимаем регистрацию изменений по номеру сообщения, который был успешно обработан
ПланыОбмена.УдалитьРегистрациюИзменений(УзелПриемник, НомерУспешногоСообщения);
Чтобы синхронизация в DBF работала корректно, нам необходимо гарантировать уникальность записей. Мы рекомендуем добавить в структуру DBF-файла текстовое поле длиной 36 символов для хранения GUID (Уникального Идентификатора) ссылки 1С. Посмотрим на пример получения GUID:
СтрокаGUID = Строка(ДанныеОбъекта.Ссылка.УникальныйИдентификатор());
// Записываем СтрокаGUID в соответствующую колонку DBF
Это позволит избежать дублей, если пользователь изменит номер документа или код справочника — GUID останется неизменным, и запись в принимающей базе будет просто обновлена, а не создана заново.
Выясним, как ускорить процесс, если изменений очень много. Работа с DBF через XBase или COM-объекты может быть медленной при построчной записи. Рассмотрим вариант оптимизации:
выгружайте данные сначала в таблицу значений или массив в памяти, и только затем записывайте весь объем данных в файл одной транзакцией (если используется ADO) или в одном цикле с редким сохранением на диск. Также важно помнить про длинные транзакции в 1С: старайтесь не держать транзакцию открытой на всё время формирования огромного файла, чтобы не блокировать работу других пользователей с планом обмена.
Использование плана обмена для выгрузки в DBF — это профессиональный подход, который избавляет от необходимости вручную следить за актуальностью данных. Мы рассмотрели, как настроить авторегистрацию, правильно выбрать изменения и обеспечить надежное снятие регистрации только после успешной обработки. Такая архитектура делает ваш обмен устойчивым к сбоям и легким в сопровождении.