Обработка с интеграцией под различные конфигурации (Реализация паттерна Стратегия обработками в макетах)

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

Взаимодействие с базой при этом реализуется через вызов кусочков кода методом Выполнить(), что нарушает стандарт #std669. Сам код при этом хранится в текстовом макете обработки с разбивкой по областям под каждый метод интеграции соответствующей конфигурации. Это хорошее решение, потому что оно работает. Все методы интеграции находятся в одном месте, в основном коде реализован механизм обращения к ним. Но! Для разработки или отладки каждого такого метода интеграции приходится копировать код из макета в место его выполнения и потом не забыть вернуть обратно. Можно, конечно, что-то доработать и непосредственно в макете, но там не будет подсказок и других прелестей редактора кода. Хотя бы подсветку синтаксиса можно включить :)


Необходимость постоянного переноса кода туда-сюда приносит множество неудобств. Что будет, если забыть убрать код, написанный для УТ10 из основного кода обработки, и запустить её не под УТ11? Ошибка! А что если забудешь перенести в макет всё, что сделал за день, а в месте вызова уже код удален? Потеря-потерь...

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


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

Далее попадаем отладчиком в модуль обработки интеграции, где можем убедиться, что ГлавныйКонтекст содержит объект основной обработки со всеми реквизитами и табличными частями, а главное, с доступом к интерфейсу модуля нашего контекста.

Потом мы возвращаемся в модуль основной обработки и, в конечном счете, снова в форму.

Если в Конфигураторе были внесены изменения в обработки и требуется продолжить разработку в EDT, то нужно импортировать изменения в соответствующие проекты.

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

Затем добавляем проекты внешних обработок. Для всех устанавливаем флаг Включить автоматическую генерацию выгрузок (*.epf или *.erf) и указываем путь к общему каталогу. У меня эти обработки сохраняются в каталоге локального git-репозитория, добавленном в проекте обработки СозданиеЗаказов как папка epf. Модули интеграции добавлены в отдельные проекты, чтобы можно было для каждого из них указать в качестве базового проект соответствующей конфигурации.

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

Для проекта основной обработки базовый проект выбирать не нужно, так что проблемы быть не должно. Для сборки будет использоваться платформа, указанная в проекте СозданиеЗаказов.

Однако, для отладки нужно настроить варианты запуска.

Отладка интеграции для обычных форм возможна только в Конфигураторе, потому что у конфигурации ЗаказыКлиентовОбычныеФормы установлен режим совместимости ниже поддерживаемых платформ текущей версии EDT. Но при этом разрабатывать модуль интеграции можно и в EDT. Доступен как контекст конфигурации через базовый проект, так и все возможности среды, включая 1С:Напарник.

Проекты под более свежие платформы можно отлаживать в EDT. Открываем модули и расставляем точки останова, где нам нужно. Открываем нужную конфигурацию запуска отладки. Например, в методе интеграции ЗаполнитьТипыДанныхДляРеквизитов(). После остановки выполнения кода в отладчике видно содержание переменной модуля интеграции ГлавныйКонтекст.

Нужно всего лишь добавить копированием новый макет двоичных данных. Затем добавить строку в табличный макет МанифестОбъектов, указав ИмяМакета (на скриншоте ИнтеграцияНовойКонффигурации), которое будет использоваться при выгрузке обработки и для поиска макета, а также ТипМакета="Обработка". Наконец, обязательно заполнить ИмяКонфигурацииИнтеграции = Имя конфигурации. По нему будет определяться из какого макета брать обработку.

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

• В модуле обработки нельзя использовать конструкторы некоторых объектов в безопасном режиме (5.5.4.3. Безопасный режим работы Руководства разработчика). Например, нельзя использовать Новый Файл(). Решить эту проблему можно, переписав код без использования этого объекта либо отключив безопасный режим. Отключить его  можно в настройках пользователя или для всей платформы. В конфигурациях на базе БСП есть ещё возможность отключить безопасный режим или настроить нужные разрешения при добавлении обработки в Дополнительные отчеты и обработки. Подробнее в документации.
• Обработки в макеты сейчас я собираю вручную, но этот процесс можно автоматизировать. Например, в проекте EDT нужно просто заменить файл "\СозданиеЗаказов\Templates\ИнтеграцияДемоБСП\Template.bin" на файл соответствующей обработки "\ИнтеграцияДемоБСП.epf" и все остальные по аналогии. Нужно только переименовать их в Template.bin, а затем пересобрать основную обработку. Если делать это из EDT, то сначала нужно обновить проект обработки СозданиеЗаказов.
• Приходится учитывать, что основная обработка может выполняться под различными платформами и с разными режимами совместимости. Поэтому нужно использовать платформенные методы, доступные в различном окружении и разрабатывать свои методы вместо типовых (из БСП или конфигураций). Но, благодаря переносу ответственности за взаимодействие с базой в модули интеграции, это становится делать проще.
• Не реализован вызов клиентских методов управляемых форм. В данном примере это не совсем проблема, потому что всё выполняется на сервере. Но я могу предложить, как решить и её. Можно добавить в модули интеграции управляемые формы, разместить в них экспортные клиентские методы (нельзя, но если надо, то можно), создавать форму нужной обработки и дёргать её методы на клиенте. Тут нужно избежать появления новых окон, но с справиться не сложно, я думаю.