При работе в облачном сервисе 1С:Фреш (1C:Fresh) разработчики часто сталкиваются с ситуацией, когда типовые правила обмена (например, между «1С:Бухгалтерия государственного учреждения» и «1С:Комбинат питания») устаревают, а стандартные механизмы их обновления через расширение не приносят результата. Попытка заменить макеты ПравилаОбмена, ПравилаОбменаКорреспондента и ПравилаРегистрации в расширении часто игнорируется системой, даже если расширение успешно прошло аудит. Рассмотрим подробно, почему это происходит и какими способами можно решить эту задачу.
Для начала проанализируем ситуацию и выясним причину такого поведения платформы. В современных конфигурациях, построенных на Библиотеке стандартных подсистем (БСП), механизм загрузки правил обмена работает по определенному приоритету. Система ищет правила в следующем порядке:
В облаке 1С:Фреш регистр правил обмена часто является неразделенным. Это означает, что данные в нем общие для всех областей (арендаторов) в рамках одного информационного узла. Обычный пользователь или администратор области не может перезаписать данные в таком регистре, так как это затронуло бы всех остальных пользователей облака. Кроме того, программный код в модулях типа ОбменДаннымиСервер может быть написан таким образом, что он обращается напрямую к метаданным основной конфигурации, игнорируя объекты, добавленные или измененные через расширение в режиме «Дополнение».
Если система упорно читает правила из регистра или макета основной конфигурации, мы можем применить механизм перехвата вызова функций в серверных модулях. Разберем по шагам, как это реализовать в расширении:
Найдем в модуле ОбменДаннымиСервер или ОбменДаннымиПереопределяемый функцию, отвечающую за извлечение правил. Обычно это методы, возвращающие ДвоичныеДанные или путь к макету. Нам нужно переопределить логику получения этих данных.
Пример программного кода для вставки в расширение:
&Вместо("ПолучитьПравилаИзМакэта")
Функция Расш1_ПолучитьПравилаИзМакэта(ИмяПланаОбмена, ИмяМакет)
// Если это наш план обмена, подсовываем макет из расширения
Если ИмяПланаОбмена = "ОбменПитаниеБГУВерсия2" Тогда
Возвратить УправлениеСвойствами.ПолучитьМакетРасширения("Расш1_НовыеПравилаОбмена");
КонецЕсли;
// В остальных случаях вызываем стандартную логику
Возврат ПродолжитьВызов(ИмяПланаОбмена, ИмяМакет);
КонецФункции
Важный момент: при использовании этого метода необходимо убедиться, что макет в расширении назван уникально (например, с префиксом), чтобы избежать конфликтов имен.
Если типовой план обмена ОбменПитаниеБГУВерсия2 слишком жестко завязан на неразделенные ресурсы, проанализируем возможность создания его копии внутри расширения. Это радикальный, но надежный путь для Фреша.
Этот способ позволяет полностью изолировать логику обмена внутри вашей области данных, не вступая в конфликт с глобальными настройками сервиса.
Рассмотрим ситуацию, когда API и планы обмена кажутся слишком сложными. Можно использовать адаптированную версию обработки «Универсальный обмен данными в формате XML». Во Фреше она должна быть загружена как дополнительная обработка и пройти аудит.
Главный вопрос здесь: как определить, какие именно документы нужно передать, чтобы не выгружать всю базу? Для этого воспользуемся механизмом службы регистрации изменений. Посмотрим на пример кода, который позволяет выбрать только измененные объекты по конкретному узлу:
Процедура ВыгрузитьИзмененияНаСервере(УзелСсылка)
ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(УзелСсылка, НомерСообщения);
Пока ВыборкаИзменений.Следующий() Цикл
ОбъектДанных = ВыборкаИзменений.Получить();
// Здесь вызываем логику выгрузки через наши правила XML
ВыгрузитьОбъектПоПравилам(ОбъектДанных, ПравилаИзМакэта);
КонецЦикла;
// После успешной отправки фиксируем получение
ПланыОбмена.УдалитьРегистрациюИзменений(УзелСсылка, НомерСообщения);
КонецПроцедуры
Используя этот подход, мы сохраняем все преимущества штатного механизма регистрации (объекты попадают в обмен при записи), но саму выгрузку делаем по своим правилам, хранящимся внутри обработки или расширения в виде двоичных данных.
Если прямой обмен между БГУ во Фреше и локальным «Комбинатом питания» настроить не удается из-за специфических правил конвертации 2.0, проанализируем вариант с промежуточным звеном.
Создадим локальную информационную базу БГУ (АРМ), которая будет синхронизироваться с облаком Фреш стандартными средствами (EnterpriseData). Поскольку локальная база находится под вашим полным контролем, в ней можно без ограничений настроить обмен с «Комбинатом питания» по любым правилам конвертации. АРМ будет выступать в роли «шлюза», передавая данные из локального софта в облако. При необходимости можно воспользоваться расширением для возврата возможности загрузки комплектов правил обмена XML в локальной базе.
При реализации любого из этих решений для 1С:Фреш, помните о правилах безопасности сервиса. Рассмотрим основные ограничения:
C:\Temp\...). Всегда работайте через ПоместитьВоВременноеХранилище и ПолучитьИмяВременногоФайла.ДвоичныеДанные, а не как текст, чтобы избежать проблем с кодировками при прохождении автоматических проверок.Подводя итог, наиболее перспективным методом для Фреша является программный перехват функции получения правил в модулях БСП через расширение. Это позволяет оставить инфраструктуру обмена типовой, но подменить «содержимое» правил на актуальное из вашего расширения.