Перейти к основному содержимому

Принципы работы расширения

В первую очередь стоит прочитать пользовательское описание расширения

Здесь постараюсь описать принципы работы расширения изнутри.

Причины​

Сервис, представляемый расширением, может работать как самостоятельно, так и в связке с Vanessa Automation. Основное назначение сервиса - работа с базой при выполнении различных тестовых сценариев, где база 1С является внешней по отношению к тестируемой системе. Сервис позволяет посредством REST API работать с базой 1С извне.

В сервис заложены следующие принципы.

  1. Сервис построен по принципам REST API
  2. Сериализация в JSON. Использование примитивных типов при обмене данными (DTO). Отказ от стандартного сериализатора 1С
  3. Описание API в формате OpenAPI
  4. Максимально дружелюбно для пользователя (тестировщика)
  5. Простота расширяемости
  6. Простая возможность кастомизации в конечной базе

Есть различные подходы к организации подобных сервисов:

  1. OData - работает из коробки и предоставляет обширные возможности для CRUD операций.
  2. Web-сервис или http-сервис с использованием стандартного сериализатора 1С.
  3. Прочие варианты.

Но при разработке расширения было принято решение создать свой велосипед по следующим причинам.

  • Удобство написания и чтения сценариев. При использовании OData или стандартного сериализатора 1С необходимо указывать уникальные идентификаторы, а это затрудняет разработку и чтение сценариев. Поэтому используется свой формат сериализации/десериализации ссылок.
  • В OData отсутствует возможность переопределить поведение при изменении объекта, не редко необходимо выполнить дополнительные действия при записи объекта, связано это с тем, что часть логики не редко находится на клиенте (в форме).
  • При использовании стандартного сериализатора 1С необходимо передавать объект полностью, нельзя его пропатчить, изменить только часть свойств, это также относится к OData, при изменении табличных частей.
  • Отсутствует возможность передавать дополнительные параметры.
  • Отсутствует работа с "другими" данными, регламентными заданиями, пользователями ИБ, планами обмена и т.д.

Схема обработки запроса​

Сервис принимает запросы через универсальный шаблон и сам определяет какой метод вызывать, на основании шаблонов, зарегистрированных в модулях обработчиках.

На основании шаблона извлекаются подстановочные данные из запроса. Например, для шаблона /АктивныеПользователи/{НомерСеанса} будет извлечено значение номера сеанса. Также десериализуется тело запроса.

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

Обработка ошибок​

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

Для обработки ошибок имеется пара методов расширения в модуле РатОбщий.

  • ЗафиксироватьОшибку - Сохраняет ошибку в структуру СтатусОбработкиЗапрос
  • КлассыОшибок - возвращает описание классов, классы характеризуются кодом ответа, идентификатором и описанием

При грамотной организации обработки ошибок будет легко разбираться в возникающих проблемах.

Преобразование данных и DTO​

Для передачи данных между клиентом и сервером используются примитивные объекты (DTO), которые вы должны преобразовать в сущности 1С. Часть таких преобразований реализована в модуле РатПреобразования.