Как предотвратить затирание пользовательских правил обмена при обновлении конфигураций 1С?

← На главную

Разработчики, работающие с платформами 1С, часто сталкиваются с ситуацией, когда после очередного обновления типовой конфигурации их тщательно разработанные и настроенные правила обмена данными, созданные с помощью "Конвертации данных 2.0" или 3.0, оказываются затертыми. При этом стандартные, "коробочные" правила остаются на месте и продолжают функционировать. В этой статье мы подробно разберем, почему возникает эта проблема, и предложим несколько проверенных решений, которые помогут сохранить ваши пользовательские правила при обновлении.

Выясняем причину: Почему затираются правила?

Для начала, давайте установим корень проблемы. Почему типовые правила остаются, а ваши — нет? Все дело в механизме обновления типовых конфигураций, особенно тех, что используют Библиотеку стандартных подсистем (БСП). В процессе обновления система выполняет ряд служебных процедур, предназначенных для поддержания актуальности и целостности данных.

Мы сосредоточим наше внимание на процедуре УдалитьНеактуальныеЗаписиВРегистреПравилДляОбменаДанными, расположенной в общем модуле ОбменДаннымиСервер. Именно эта процедура является виновником затирания ваших правил. Что она делает? При каждом обновлении она сканирует регистр сведений ПравилаДляОбменаДанными, который используется для хранения правил конвертации и регистрации объектов. Далее, она удаляет все записи, имена планов обмена которых отсутствуют в списке типовых планов, известных системе БСП. Если ваш пользовательский план обмена не включен в этот "белый список" типовых планов, система автоматически помечает его правила как "неактуальные" и безжалостно удаляет их.


// Пример логики процедуры УдалитьНеактуальныеЗаписиВРегистреПравилДляОбменаДанными (упрощенно)
Процедура УдалитьНеактуальныеЗаписиВРегистреПравилДляОбменаДанными() Экспорт
    Запрос = Новый Запрос(
        "ВЫБРАТЬ РАЗЛИЧНЫЕ
        |    ПравилаДляОбменаДанными.ИмяПланаОбмена КАК ИмяПланаОбмена
        |ИЗ
        |    РегистрСведений.ПравилаДляОбменаДанными КАК ПравилаДляОбменаДанными
        |ГДЕ
        |    НЕ ПравилаДляОбменаДанными.ИмяПланаОбмена В (&ПланыОбменаБСП)");
    
    // Получаем список типовых планов обмена от БСП
    Запрос.УстановитьПараметр("ПланыОбменаБСП", ОбменДаннымиПовтИсп.ПланыОбменаБСП);
    
    Выборка = Запрос.Выполнить().Выбрать();
    Пока Выборка.Следующий() Цикл
        // Для каждого плана обмена, не входящего в список БСП
        // Создаем набор записей для удаления
        НаборЗаписей = ОбменДаннымиСлужебный.СоздатьНаборЗаписейРегистраСведений(
            Новый Структура("ИмяПланаОбмена", Выборка.ИмяПланаОбмена), 
            "ПравилаДляОбменаДанными"
        );
        НаборЗаписей.Очистить(); // Очищаем записи для данного плана
        НаборЗаписей.Записать(); // Записываем пустой набор, фактически удаляя правила
    КонецЦикла;
КонецПроцедуры

Как мы видим, основной механизм здесь — это проверка принадлежности плана обмена к списку ПланыОбменаБСП. Если нашего плана там нет, его правила будут удалены.

Решение 1: Интегрируем пользовательский план обмена в систему БСП

Одним из наиболее "чистых" и рекомендуемых способов решения проблемы является явное указание системе 1С о существовании вашего пользовательского плана обмена. Таким образом, мы включаем наш план в список "актуальных" планов, используемых БСП, и процедура очистки его игнорирует.

Для этого мы модифицируем общий модуль ОбменДаннымиПереопределяемый. Этот модуль специально предназначен для внесения изменений в логику БСП без необходимости полного снятия с поддержки всей конфигурации. Он позволяет нам переопределить или дополнить определенные функции, сохраняя при этом удобство обновлений.

Откроем конфигурацию в режиме разработки.
Найдем общий модуль ОбменДаннымиПереопределяемый в дереве объектов конфигурации.
Внутри этого модуля обнаружим процедуру ПолучитьПланыОбмена(ПланыОбменаПодсистемы) Экспорт. Эта процедура отвечает за наполнение списка планов обмена, которые БСП считает своими и для которых не должна производиться очистка правил.

Добавим в эту процедуру строку, которая включит наш пользовательский план обмена в список ПланыОбменаПодсистемы:


// В общем модуле ОбменДаннымиПереопределяемый
// В процедуре ПолучитьПланыОбмена(ПланыОбменаПодсистемы) Экспорт

// ...существующий код типовых планов обмена...

ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена.ВашПланОбмена);

// ...возможно, другие ваши пользовательские планы...
// ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена.МойВторойПлан);

// ...продолжение существующего кода...

Где ВашПланОбмена — это точное имя вашего плана обмена (например, Пл_ЗУП_УПП, ПланОбмена_БухгалтерияУправлениеТорговлей, или МойКастомныйПланОбмена). Важно использовать именно метаданные вашего плана обмена.

После этих изменений сохраним конфигурацию. Теперь при обновлении система, формируя список ПланыОбменаБСП, будет включать в него и ваш план обмена, и его записи в регистре ПравилаДляОбменаДанными не будут удалены процедурой очистки.

Важно: этот способ требует внесения изменений непосредственно в конфигурацию. Несмотря на то, что модуль ОбменДаннымиПереопределяемый создан для таких целей, всегда необходимо соблюдать осторожность при модификации типовых объектов. Помним, что расширения в данном случае не помогут, так как критические процедуры, очищающие регистр, выполняются на этапе, когда расширения еще не активны и не могут переопределить это поведение.

Решение 2: Встраиваем правила обмена непосредственно в план обмена через макеты

Другой, очень эффективный и часто применяемый способ — это хранение правил обмена не в виде внешнего XML-файла, который загружается вручную, а в виде макетов, встроенных непосредственно в ваш план обмена. Этот подход позволяет системе "видеть" правила как неотъемлемую часть конфигурации, а не как временные данные, которые можно удалить.

Разберем процесс по шагам:

В вашем пользовательском плане обмена (например, ВашПланОбмена) создадим два новых макета. Тип макетов должен быть "Текстовый документ".
Назовем эти макеты следующим образом:
- ПравилаОбмена: В этот макет мы будем загружать XML-файл с правилами обмена, которые применяются для исходящего обмена данными — из вашей текущей базы в базу-корреспондент.
- ПравилаОбменаКорреспондента: В этот макет мы загрузим XML-файл с правилами обмена, которые предназначены для входящего обмена данными — от корреспондента в вашу текущую базу. В большинстве случаев это могут быть те же самые правила, но разделение их на два макета обеспечивает гибкость и соответствует стандартным подходам в БСП для различных сценариев.
После создания макетов, откроем каждый из них и загрузим в него соответствующий XML-файл с правилами обмена, предварительно экспортированный из "Конвертации Данных 2.0" или 3.0. Если вы используете Конвертацию Данных 3.1, макет может содержать ZIP-архив, включающий CorrespondentExchangeRules.xml и ExchangeRules.xml.

Преимущества этого метода:

Правила становятся частью конфигурации и не затираются при обновлении, так как они воспринимаются системой как метаданные.
Упрощается процесс развертывания новых баз или восстановления из резервных копий, поскольку правила уже "встроены" в конфигурацию.
Снижается риск ошибок, связанных с ручной загрузкой файлов правил после каждого обновления.

Недостатки и важные моменты:

При каждом изменении логики обмена, добавлении новых объектов или обновлении метаданных в конфигурации, вам потребуется вручную актуализировать эти макеты: выгружать правила из базы, редактировать их в "Конвертации Данных", экспортировать обновленные правила и загружать их обратно в макеты.
Если в правилах присутствует какая-либо версия (например, в комментариях XML или специальных полях), она не обновится автоматически. Вам придется вручную контролировать и при необходимости изменять номер версии в макете.

Решение 3: Прямая модификация процедуры удаления правил (не рекомендуется)

Хотя это технически возможно, прямое изменение процедуры УдалитьНеактуальныеЗаписиВРегистреПравилДляОбменаДанными в модуле ОбменДаннымиСервер является наименее рекомендуемым способом. Этот подход сопряжен с максимальными сложностями при последующих обновлениях конфигурации, так как вы напрямую вмешиваетесь в типовой код, который может быть изменен разработчиками 1С в будущих релизах.

Если вы все же решитесь на этот путь, то задача будет заключаться в добавлении условия, которое исключит ваш план обмена из списка удаляемых. Мы можем внести изменения примерно следующего характера:


// В общем модуле ОбменДаннымиСервер
// В процедуре УдалитьНеактуальныеЗаписиВРегистреПравилДляОбменаДанными()

    Запрос = Новый Запрос(
        "ВЫБРАТЬ РАЗЛИЧНЫЕ
        |    ПравилаДляОбменаДанными.ИмяПланаОбмена КАК ИмяПланаОбмена
        |ИЗ
        |    РегистрСведений.ПравилаДляОбменаДанными КАК ПравилаДляОбменаДанными
        |ГДЕ
        |    НЕ ПравилаДляОбменаДанными.ИмяПланаОбмена В (&ПланыОбменаБСП)");
    
    Запрос.УстановитьПараметр("ПланыОбменаБСП", ОбменДаннымиПовтИсп.ПланыОбменаБСП);
    Выборка = Запрос.Выполнить().Выбрать();

    Пока Выборка.Следующий() Цикл
        // Добавляем условие для пропуска нашего плана обмена
        // Используем точное имя вашего плана обмена
        Если Выборка.ИмяПланаОбмена = "ВашПланОбмена" Тогда
            Продолжить; // Пропускаем удаление для нашего плана и переходим к следующей записи
        КонецЕсли;

        // Если это не наш план обмена, продолжаем стандартное удаление
        НаборЗаписей = ОбменДаннымиСлужебный.СоздатьНаборЗаписейРегистраСведений(
            Новый Структура("ИмяПланаОбмена", Выборка.ИмяПланаОбмена), 
            "ПравилаДляОбменаДанными"
        );
        НаборЗаписей.Очистить(); // Очищаем записи для данного плана
        НаборЗаписей.Записать(); // Записываем пустой набор, фактически удаляя правила
    КонецЦикла;

Крайне важно: такой подход требует постоянного и тщательного контроля при каждом обновлении конфигурации. Изменения в типовой процедуре могут быть затерты или привести к конфликтам при слиянии конфигураций, что усложнит процесс поддержки и обновлений. Мы настоятельно рекомендуем использовать первые два подхода, если это возможно.

Почему расширения не помогают в этом случае?

Многие разработчики, знакомые с механизмом расширений в 1С, могут задаться вопросом: "Почему бы не решить эту проблему с помощью расширения?" Мы проанализируем эту ситуацию. Дело в том, что процедура обновления конфигурации, в частности удаление неактуальных правил обмена, происходит на очень ранних этапах запуска информационной базы и обновления метаданных. В этот момент расширения еще не инициализированы и не применены к основной конфигурации.

По этой причине расширения не могут переопределить поведение процедур, которые выполняются на этом критическом этапе. Процедуры очистки регистра сведений с правилами обмена срабатывают до того, как расширения начинают влиять на работу конфигурации. Поэтому для предотвращения затирания правил требуется прямое вмешательство в основную конфигурацию, либо в специально предназначенные для этого переопределяемые модули, либо, в крайнем случае, непосредственно в модуль ОбменДаннымиСервер.

Актуализация и версионирование правил обмена

Независимо от выбранного способа хранения правил (интеграция в БСП или использование макетов), критически важно постоянно следить за их актуальностью. При обновлении конфигурации 1С или при доработке функционала метаданные могут измениться (например, будут добавлены новые реквизиты, документы, справочники), что неизбежно потребует внесения изменений и в правила обмена.

Рассмотрим процесс актуализации правил обмена по шагам:

Выгрузка текущих правил: Если ваши правила хранятся в макетах или ранее были загружены в регистр, их необходимо выгрузить из базы в XML-файл. Это делается через форму настройки обмена, если правила доступны для выгрузки, или напрямую из макета в режиме конфигуратора.
Загрузка в "Конвертацию данных": Полученный XML-файл с правилами необходимо загрузить в соответствующую версию конфигурации "Конвертация данных" (например, КД 2.1 или КД 3.1).
Обновление объектов метаданных конвертации: В самой "Конвертации данных" необходимо обновить объекты метаданных до текущего состояния вашей рабочей конфигурации. Это позволит КД увидеть все изменения, произошедшие в структуре данных.
Внесение необходимых изменений: После обновления метаданных, приступайте к редактированию правил конвертации и регистрации объектов, адаптируя их к новым структурам данных и логике обмена.
Сохранение и загрузка обновленных правил: После внесения всех изменений, сохраните обновленные правила из "Конвертации данных" в XML-файл и загрузите их обратно в информационную базу. Если вы используете подход с макетами, загрузите XML-файл непосредственно в соответствующие макеты плана обмена. Если вы выбрали первый способ (интеграция в БСП без использования макетов), используйте стандартный механизм загрузки правил из файла через форму настройки обмена.

Особенности версионирования: Если вы используете макеты для хранения правил и включаете в них информацию о версии (например, в XML-тегах или в виде комментария), помните, что эта версия не обновляется автоматически при изменении правил. Вам придется вручную контролировать и при необходимости изменять номер версии в макете при каждом обновлении правил. Это важно для корректного отслеживания изменений и совместимости обмена.

Заключение

Мы выяснили, что проблема затирания пользовательских правил обмена при обновлении конфигураций 1С имеет четкую причину, связанную с механизмом очистки "неактуальных" правил в БСП. Однако, существуют эффективные и проверенные пути решения этой задачи. Наиболее предпочтительными являются следующие подходы:

Интеграция вашего пользовательского плана обмена в список известных БСП планов через модификацию модуля ОбменДаннымиПереопределяемый.
Хранение правил обмена непосредственно в макетах вашего плана обмена, делая их частью конфигурации.

Хотя теоретически возможно прямое вмешательство в процедуру удаления правил в модуле ОбменДаннымиСервер, мы не рекомендуем этот метод из-за высоких рисков при последующих обновлениях. Расширения, к сожалению, не могут решить эту проблему из-за специфики этапов выполнения кода при обновлении.

Всегда помните о необходимости регулярной актуализации правил обмена при любых изменениях в конфигурации. Это обеспечит стабильность и корректность ваших обменов данными. Выбрав один из предложенных подходов и следуя рекомендациям по актуализации, вы сможете избежать потери ваших драгоценных правил и обеспечить бесперебойную работу обменов.