[ Вопрос дня ] Как лучше проверить работоспособность расширений после обновления основной конфигурации?

Доброго дня, коллеги!

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

Вопрос

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

  • Для каждого расширения в конфигураторе выполняю команду  Конфигурация -> Проверка возможности применения. Все замечания отрабатываю.
  • Определяю перечень объектов метаданных, по которым были изменения в основной конфигурации по отношению к конфигурации поставщика или были изменения в новой конфигурации поставщика по отношению к старой конфигурации поставщика.
  • По каждому объекту, определенного в пункте выше, вручную проверяю, есть ли он в расширениях. Если есть, то пытаюсь понять, что было доработано в расширении – проверяю все модифицированные свойства и доработанные процедуры и функции и при необходимости вношу изменения в расширение. Если в расширении из выявленных объектов присутствует заимствованная форма, то для каждой такой формы выполняю команду “Обновить расширение формы“. Далее по данным объектам проверяю работоспособность и логику работы в режиме 1С Предприятие.

Вопрос – правильно ли я описал последовательность действий при проверке работоспособности расширений? Какими средствами можно пользоваться для ускорения и упрощения процесса проверки работоспособности расширений?

Ответ

Да, логика действий описана правильная. Получается, нужно вручную выполнить что-то вроде поиска дважды измененных объектов. Если обновляемая конфигурация знакома, известно, что именно делает конкретное расширение, то можно немного сократить работу по проверке корректности расширения. Проверяем, что расширение подключается, затем в пользовательском режиме проверяем, как оно работает. Например, если это печатная форма, формируем ее, проверяем корректность формы, не возникают ли ошибки во время исполнения программного кода. Если при помощи расширения изменялись роли и права доступа, проверяем, что в пользовательском режиме нужные объекты доступны (или наоборот – недоступны) конкретным пользователям и т.д. То есть здесь исходим из того, что есть описание функционала расширения, не нужно разбираться в этом “от программного кода”. Это поможет сэкономить время при обновлении.

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

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

Комментарии / обсуждение (6):

  1. Алексей

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

    В одном из обновлений меняется БСП и теперь в процедуре два параметра: ОбщегоНазначения.СообщитьПользователю(Параметр1, Параметр2)

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

    • Василий Ханевич

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

    • Nail2012

      Я нашел универсальный способ: Всегда при доработке типовых модулей в расширении использовать конструкцию:

      &ИзменениеИКонтроль(“ОбработкаПроведения”)

      Тогда при выполнении команды:
      Действия – проверка возможности применения всех расширений

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вход на сайт

Зарегистрироваться

Подтверждение регистрации будет отправлено на указанный e-mail.

Я подтверждаю, что ознакомлен(а) с Пользовательским соглашением, принимаю его условия и даю свое согласие на обработку моих персональных данных.

Восстановить доступ

E-mail или логин

Ссылка на создание нового пароля будет отправлена на указанный e-mail.