Интеграция двух крупных учетных систем, таких как 1С:Управление производственным предприятием (УПП) и 1С:ERP Управление предприятием — это всегда сложный архитектурный проект. Ситуация усложняется в разы, если одна из баз (чаще всего УПП) является сильно доработанной, а сам обмен должен быть двусторонним и работать в режиме реального времени или по частому расписанию. В такой ситуации перед разработчиком встает множество вопросов: какую технологию передачи данных выбрать, как регистрировать изменения, как не допустить бесконечного зацикливания («петель» обмена) и как корректно разрешать коллизии, когда один и тот же объект изменяется одновременно в обеих базах.
В этой статье мы подробно разберем все этапы построения надежной системы двустороннего обмена данными, проанализируем сильные и слабые стороны различных подходов и выработаем оптимальную стратегию реализации.
---
При организации обмена между УПП и ERP разработчики чаще всего выбирают между тремя технологиями: COM-соединение, файловый обмен (через каталог, FTP или почту) и современные WEB/HTTP-сервисы. Рассмотрим каждый вариант подробнее.
1. COM-соединение (V83.COMConnector)
Исторически это самый популярный способ «быстрого» обмена, когда одна база напрямую подключается к другой и выполняет чтение/запись данных. Однако для связки УПП и ERP в современных реалиях этот метод имеет критические недостатки:
2. Файловый обмен (каталог, FTP, Email)
Классический и наиболее отказоустойчивый транспорт, используемый в типовых конфигурациях 1С. База-источник выгружает XML- или JSON-пакет в общий ресурс, а база-приемник забирает его по расписанию. Этот вариант хорош тем, что базы полностью изолированы друг от друга: сбой в ERP никак не повлияет на работоспособность УПП во время выгрузки пакета.
3. WEB и HTTP-сервисы (Рекомендуемый подход)
Для создания быстрого обмена с возможностью оперативного получения подтверждений HTTP-сервисы являются лучшим выбором. База-приемник разворачивает у себя HTTP-сервис, а база-источник отправляет POST-запрос с телом пакета данных. Это исключает зависимость от версий платформ, позволяет настроить гибкое логирование на веб-сервере (IIS или Apache) и обеспечивает моментальную обработку пакетов.
---
Для отслеживания измененных объектов в 1С нет ничего лучше и надежнее, чем объект метаданных План обмена. Попытки реализовать отслеживание изменений через самописные регистры сведений, куда при записи объектов пишутся ссылки на них, неизбежно приводят к падению производительности и блокировкам СУБД.
Выясним, как правильно использовать планы обмена в нашей задаче. В УПП есть предопределенный план обмена УПП-УПП (или аналогичный типовой план обмена для распределенных информационных баз). Его ключевой плюс — он уже содержит в своем составе практически все документы, справочники и регистры конфигурации. Мы можем использовать его в качестве «донора» для регистрации изменений для нашей ERP.
Критически важный нюанс настройки плана обмена:
Если вы просто включите авторегистрацию для всех объектов в составе плана обмена, это вызовет серьезные блокировки таблиц СУБД при транзакциях записи документов пользователями. Чтобы избежать этого, выполните следующие шаги:
ПриЗаписи для необходимых документов и справочников.Пример кода для программной регистрации изменений в подписке на событие:
Процедура ПриЗаписиОбъектаДляОбмена(Источник, Отказ) Экспорт
Если Отказ Тогда
Возврат;
КонецЕсли;
// Получаем узел нашей ERP-системы из плана обмена
УзелERP = ПланыОбмена.УдаленныйСклад.НайтиПоКоду("ERP");
Если ЗначениеЗаполнено(УзелERP) Тогда
// Регистрируем изменение конкретного объекта для узла ERP
ПланыОбмена.ЗарегистрироватьИзменения(УзелERP, Источник.Ссылка);
КонецЕсли;
КонецПроцедуры
---
При двустороннем обмене возникает классическая проблема: База А отправляет измененный объект в Базу Б. База Б принимает объект, записывает его у себя и... автоматически регистрирует это изменение на своем плане обмена для отправки обратно в Базу А. В результате объект начинает бесконечно циркулировать между системами, перегружая серверы.
Разберем по шагам, как решить эту проблему с помощью отключения регистрации изменений при загрузке:
Шаг 1. Отключение регистрации изменений при загрузке данных
В платформе 1С реализован механизм, позволяющий временно отключить регистрацию изменений для текущего сеанса или конкретной транзакции записи. При загрузке данных из файла или HTTP-запроса перед записью объекта необходимо вызвать метод ОбменДанными.Загрузка = Истина.
// Пример записи объекта при загрузке без вызова обработчиков и регистрации изменений
НовыйДокумент = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
// ... Заполнение реквизитов документа ...
НовыйДокумент.ОбменДанными.Загрузка = Истина;
НовыйДокумент.Записать(РежимЗаписиДокумента.Запись);
Использование свойства ОбменДанными.Загрузка = Истина гарантирует, что платформа не будет регистрировать данный объект на планах обмена для обратной отправки. Также это отключает стандартные прикладные проверки при записи (что ускоряет загрузку), поэтому контролировать корректность данных нужно на этапе подготовки пакета.
Шаг 2. Квитирование (подтверждение) приема сообщений
Для надежного удаления зарегистрированных изменений используйте механизм номеров сообщений, заложенный в платформу 1С. Каждому отправляемому пакету присваивается уникальный номер (счетчик отправленных сообщений на узле плана обмена). База-приемник, успешно обработав пакет, в ответном сообщении присылает номер этого пакета обратно. База-отправитель при получении подтверждения вызывает метод:
// Удаляем регистрацию изменений, подтвержденную базой-получателем
ПланыОбмена.УдалитьРегистрациюИзменений(УзелERP, НомерПринятогоСообщения);
---
Коллизия возникает тогда, когда один и тот же объект (например, карточка контрагента или спецификация номенклатуры) был изменен в обеих базах в период между сеансами обмена. Какая версия должна победить?
Рассмотрим два подхода к решению этой проблемы.
Это самый простой в реализации подход, при котором одна из баз объявляется «главной» для определенных типов данных. Например:
Реализуется этот подход в модуле Плана обмена через обработчики событий приема данных. Проанализируем пример логики в процедуре ПриПолученииДанныхОтПодчиненного:
Процедура ПриПолученииДанныхОтПодчиненного(ЭлементДанных, Отправитель, ВыбратьЭлемент)
// Если пришел документ "ЗаказКлиента" и мы находимся в главной базе (ERP)
Если ТипЗнч(ЭлементДанных) = Тип("ДокументОбъект.ЗаказКлиента") Тогда
// Проверяем, изменялся ли этот документ локально в ERP
Если ЕстьЛокальныеИзменения(ЭлементДанных.Ссылка) Тогда
// Игнорируем изменения подчиненного узла, оставляем локальную версию
ВыбратьЭлемент = ПолучениеЭлементаДанных.Игнорировать;
Возврат;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Если базы равноправны, автоматическое затирание данных недопустимо. В этом случае необходимо использовать подсистемы Библиотеки стандартных подсистем (БСП), которая встроена в 1С:ERP. В БСП есть стандартный регистр сведений КонфликтыПриСинхронизацииДанных.
При обнаружении конфликта система записывает обе версии объекта и выводит предупреждение для администратора обмена в специализированном интерфейсе «Предупреждения при синхронизации данных». Пользователь может нажать кнопку «Показать отличия», увидеть, какие именно реквизиты расходятся, и вручную выбрать, какую версию объекта сохранить.
---
Обсуждая обмен с современными конфигурациями (к которым относится ERP), нельзя обойти стороной выбор технологии описания правил обмена.
Конвертация данных 2.0 (КД 2.0)
Работает напрямую с метаданными двух конкретных конфигураций.
Плюсы: У вас уже есть готовые правила, написанные под вашу структуру. Легко сопоставлять специфичные, сильно доработанные реквизиты УПП и ERP.
Минусы: Крайне высокая чувствительность к обновлениям. Если фирма 1С обновит ERP, изменив имя какого-то реквизита или структуру проведения документа, обмен мгновенно «упадет». Вам придется вручную открывать конфигуратор КД 2.0, перевыгружать метаданные ERP, обновлять правила и загружать их обратно.
Конвертация данных 3.0 (КД 3.0 и формат EnterpriseData)
Обмен строится через промежуточный универсальный формат XML/JSON — EnterpriseData (ED). Каждая база отвечает только за конвертацию своих данных в этот универсальный формат и обратно.
Плюсы: Полная независимость от обновлений ERP. Если ERP обновится, она продолжит поддерживать старые версии формата ED (например, 1.7 или 1.8), и ваш обмен не сломается.
Минусы: КД 3.0 требует полного переписывания логики обмена с нуля (ваши старые КД2-правила использовать не получится). Если в вашей УПП много нетиповых реквизитов, вам придется расширять схему XDTO-пакета EnterpriseData в ERP с помощью механизма расширений и прописывать обработчики в общем модуле ОбменДаннымиПереопределяемый в процедуре ПриПолученииДоступныхРасширенийФормата.
Рекомендация: Если проект долгосрочный и ERP планируется регулярно обновлять на новые релизы — стратегически выгоднее потратить время на изучение КД 3.0 и переписать обмен на формат EnterpriseData. Если нужно запуститься быстро «здесь и сейчас», а ERP не будет часто обновляться — используйте имеющиеся правила КД 2.0, но автоматизируйте транспорт через регламентные задания и HTTP-сервисы.