Тестирование API 1C Postman

18.08.21

Интеграция - WEB-интеграция

Тестирование вашего API, который вы сделали на 1С.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Тестирование API 1C Postman:
.dt 185,15Kb
7
7 Скачать (1 SM) Купить за 1 850 руб.
Тестирование API 1C Postman:
.json 4,42Kb
7
7 Скачать (1 SM) Купить за 1 850 руб.

Введен ие

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

Поехали

Чтобы установить postman, достаточно перейти по ссылке https://www.postman.com/downloads/, нажать кнопку download и кликнуть на полученный exe файл, если, конечно, вы работаете на ОС windows.

 

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

 

 

Первый запрос

Думаю, вы справились с публикацией информационной базы на веб-сервере и собрали адресную строку по статье на ИТС, в моем примере она выглядит так «http://localhost/conf83/hs/orders-api/». Теперь пора выполнить первый запрос. Обратимся к первому методу (в простонародье endpoint), который отвечает за работоспособность нашего API под названием status, открыв новую закладку.

 

 

Можете заметить, что в типовых решениях есть метод ping, даже можете найти стандарт, но на мой субъективный взгляд, лучше использовать нейминг status и по-честному отвечать json'ом. Тут мне хотелось бы понимать, что вы знаете о протоколе http и работали с ним, если нет - то прошу в эту статью.

Коллекции, переменные

Для дальнейшего использования нашего запроса сохраним его, добавив и создав новую коллекцию запросов. Коллекция – список нескольких запросов.

 

 

Чтобы не копипастить постоянно адрес, добавим его в переменную «baseUrl». Переменные в postman выделяются двойными фигурными скобками.

 

 

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

 

 

Для редактирования конкретного значение используйте колонку Current value.

Параметры запроса

Перед тем как начать работать с параметрами запроса, добавим новый запрос, методом копипаста. Можно заметить, что postman не находит переменную, все верно, потому область видимости переменной – коллекция. Сохраним запрос в коллекцию, ошибка исчезнет, запрос отработает корректно.

 

 

Параметры запроса могут быть обязательными и не обязательными. В нашем API тип (он же вид) номенклатуры не обязательный параметр, но может принять 2 значения: Товар, Услуга. Ключ параметра и его значение сами будут добавляться к тексту запроса. Попробуем добавить параметр и указать несуществующий тип

 

 

Вернулся статус 400, который обозначает ошибку. В ответе можно попытаться проанализировать причину. Нет особых правил, какие параметры использовать в запросе, какие из них обязательные и какие значения могут принимать, эти тонкости стоит отражать в документации к вашему API. Но настоятельно рекомендовал бы возвращать коды ошибок 4хх при ее наличии с указанием причины ошибки в ответе. Исправим ошибку?

 

 

 

Обратите внимание, что ключи параметров регистрозависимые.

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

 

 

Идентификатор ручки мы взяли из метода List sku. На самом деле не очень важно, что вы укажете в качестве ключа «skuid» или «sku», так как на самом деле postman отправит запрос на адрес http://localhost/conf83/hs/orders-api/sku/ee9ad060-20ef-11e7-ba56-94de806096e9, подменив ключ на его значение.

Если отправить запрос с несуществующей номенклатурой, то метод должен вернуть статус 404 и текст ошибки

 

 

POST запросы

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

 

 

Получили ошибку 401 и текст ошибки "Отсутствует заголовок аутентификации". Дело в том, что часть ваших методов api могут быть доступны всем без авторизации, остальная - требовать ее наличие. Опять же нет жестких ограничений, все зависит от ваших требований к безопасности и процедуре регистрации клиентов в вашей системе. Так как требования у всех разные, рассмотрим самый простой способ авторизации с предварительной регистрацией через api и получением токена (token).

Регистрация клиента (без смс)

Для регистрации у нас есть метод api-clients, куда следует передать имя пользователя и электронную почту пользователя в формате json на закладке Body. В ответ получим токен, который будем использовать для остальных методов api. Используя данный токен, мы будем понимать, кто (какой пользователь) выполняет данный метод.

 

 

Итак, мы отправили запрос на регистрацию, получили успешный код (он же статус) ответа (201), в теле сообщения - токен для входа.

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

 

 

Вернемся к нашему методу создания нового заказа, который требовал аутентификации. Обычно токен передается в заголовке запроса. Мы можем указать его на закладке Headers, а можем - на соответствующей закладке аутентификации. Тут огромный список вариантов типов, один из самых распространённых Bearer Token.

 

 

Как вы могли заметить, postman сам добавил соответствующий заголовок Authorization. Выполнив запрос, мы по-прежнему получили ошибку, но уже 400ую, значит аутентификация выполнена, осталось передать информацию для формирования нового заказа.

 

 

Метод вернул 201 статус, значит, заказ создан. В теле ответа видим идентификатор нового заказа. Помните, что в методе sku было поле, которое указывает, доступна ли номенклатура или нет?

 

 

Тестирование api

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

Вся суть тестирования api заключается в анализе ответов каждого метода. К примеру, метод status должен вернуть код 200, а тело сообщения должно содержать поле status со значением OK. Перейдем к закладке Test и напишем первый простой тест, который пишется на javascript.

 

 

Справа есть небольшой генератор кода, а также ссылка на документацию тестов.

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Код выше очень простой и легок в понимании. Статус ответа данного метода должен быть равен значению 200.

Для проверки сообщения добавим строку анализа json, так как api может вернуть html в случае ошибки сервиса, который не удастся распарсить, и проверим значение строкой кода.

pm.expect(pm.response.status).to.eql("OK");

 

Если попытаться обратиться к несуществующему адресу или сравнить поле со значением “NOT OK”, тест упадет.

Теперь можно добавить проверку статуса в каждый метод, кстати ключевое слово function является устаревшим. Методы, которые, что-то создают, как правило, возвращают код 201, а не 200.

 

 

Передача результата между методами api

У нас есть 2 связанных метода sku и sku/:skuid. В первом мы получаем общий список номенклатур, во втором - детальную информацию о номенклатуре с ее ценами и остатками. По сути сейчас нужно скопипастить идентификатор из первого запроса и перенести во второй. Как это сделать автоматически? Итак, наша задача из метода sku получить идентификатор первой доступной номенклатуры и сохранить его в переменную. Метод возвращает поле sku, в котором находится массив всех элементов, доступных и не доступных, см поле available. Чтобы найти необходимый элемент в массиве можно воспользоваться функцией filter(). Из полученного массива обратиться к первому элементу, из которого получить поле id. Все делается в 3 строки кода.

 

 

const response = pm.response.json();
const availableSkus = response.sku.filter((availableSku) => availableSku.available === true);
console.log(availableSkus[0].id);

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

 

 

pm.collectionVariables.set("skuId", availableSkus[0].id);

Отлично, но что если сервис не вернет ни одной доступной к заказу номенклатуры? Мы получим ошибку компиляции, так как обращаемся к первому элементу массива, который может быть пустым. Лучше это поправить, сохранять идентификатор только если первый элемент существует и написать скрипт, который проверяет что, хотя бы одна номенклатура найдена.

 

 

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

 

 

Runner

Теперь все готово, чтобы проверить api в один клик. Закроем все запросы, сохранив их в коллекцию, и откроем Runner.

 

 

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

Приложена доработанная каркасная конфигурация с экзамена 1С:Специалист по платформе на версии платформы 8.3.17.1851.

См. также

WEB-интеграция Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Функциональное решение для торговли на всех популярных маркетплейсах. Работает со схемами FBO и FBS. Простое в использовании и установке, не вносит изменения в код программы. Существенно упрощает работу с товарным ассортиментом, обработку заказов с площадок, работу с поставками, а также ведение аналитики по продажам и остаткам.

72000 руб.

19.07.2024    1429    52    0    

3

WEB-интеграция Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    17782    49    50    

29

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021    14165    41    8    

16

Обмен с ГосИС Мастера заполнения WEB-интеграция Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет Оперативный учет Управляемые формы 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Универсальное расширение конфигурации для автоматической загрузки и заполнения реквизитов контрагентов (партнеров) из ОГРН для 1С:ERP Управление предприятием 2 (1С:ERP Управление предприятием 2, редакция 2.4), 1С:ERP Управление предприятием 2 (1С:ERP Управление предприятием 2, редакция 2.2), 1С:Управление торговлей 8 (Управление торговлей, редакция 11.5), 1С:Управление торговлей 8 (Управление торговлей, редакция 11.4), 1С:Управление торговлей 8 (Управление торговлей, редакция 11.3), 1С:Управление торговлей 8 (Управление торговлей, редакция 11.2), 1С:Комплексная автоматизация 8 (1С:Комплексная автоматизация, редакция 2.4), 1С:Комплексная автоматизация 8 (1С:Комплексная автоматизация, редакция 2.2), 1С:Комплексная автоматизация 8 (1С:Комплексная автоматизация, редакция 2.0) и 1С:Бухгалтерия 8 (Бухгалтерия предприятия, редакция 3.0).

3900 руб.

08.11.2017    63115    404    295    

72

ККМ WEB-интеграция Программист Пользователь Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Универсальный драйвер для фискализации чеков для сервиса Бизнес.РУ. Чеки (https://online-check.business.ru/). Работает с любой кассой, подключенной к сервису, в том числе и без физической кассы (Аренда облачной ККТ в датацентре). Принцип работы аналогичен наличию физической кассы, подключенной к рабочему месту 1С. Фискализация выполняется с любого рабочего места через интернет. Нет ограничений на количество рабочих мест, касс, компьютеров. Поддерживает печать с нескольких рабочих мест на одну кассу. Работает в любой операционной системе (Windows, Linux) и в любом клиенте (Тонкий, Толстый, Web, Мобильный клиент).

6000 руб.

03.06.2021    13864    12    0    

8
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. uno-c 238 21.08.21 15:33 Сейчас в теме
Postman синхронизируется с облаком, поэтому токены и прочие критичные секреты лучше сохранять в переменные как на картинке в статье. Имею в виду картинку про токен.
3. kolya_tlt 87 21.08.21 21:10 Сейчас в теме
(1) для секретов лучше использовать current value, он не передаётся даже если коллекцию кому-то передать
5. uno-c 238 21.08.21 22:50 Сейчас в теме
(3) Да, выше в (1) я написал: как на картинке про токен из Вашей статьи.
2. RustIG 1729 21.08.21 18:04 Сейчас в теме
(0) а чем отличаются файлы, приложенные к публикации?
4. kolya_tlt 87 21.08.21 21:11 Сейчас в теме
(2) первый файл выгрузка dt каркасной конфигурации. Второй - коллекция postman которая получилась в результате статьи.
6. VVi3ard 52 08.09.21 02:00 Сейчас в теме
Поделитесь как валидируетее структуру json? Используете json схему ?
7. kolya_tlt 87 10.09.21 10:55 Сейчас в теме
(6) мне не известен другой способ, кроме как кодом проверять наличие необходимых полей, их типы и размерности. Если в полях гуиды приходится ещё проверять существует ли ссылка с полученным значением.
Отсутствие схемы - плюс и диаметральный минус по сравнению с xml
8. avbolshakov 26.09.23 11:07 Сейчас в теме
работать самому удобнее в темной, но в публикациях лучше выглядит светлая тема ( и на стримах)
Оставьте свое сообщение