За 10–15 минут на бесплатном SoapUI можно собрать стенд для отдельного прогона REST, в том числе с заглушкой контрагента, и закрепить проверки в конфигурации «Тестирование 3.0» с отчётом по регламенту. РЕСТ-интерфейс 1С удобно отлаживать в SoapUI: Моск-сервер подменяет контур WMS. Когда сценарий перестаёт «плавать», тот же проект подключают к «Тестирование 3.0» и прогоняют через TestRunner. Семь шагов ниже - для разработчика интеграций на ERP, УТ или КА: проверить исходящие НТТР-запросы и воспроизводить входящие вызовы с телом команды от WMS (callback), без стенда партнёра и без повторения одних и тех же запросов вручную после каждой сборки.
Подготовка окружения для РЕСТ-тестов
Чтобы гонять тесты отдельно от продуктивного контура партнёра, понадобятся опубликованная на IIS или Apache информационная база 1С, SoapUI Open Source (SmartBear) и при автоматизации - конфигурация «Тестирование 3.0» в отдельной базе или рядом с регламентными заданиями.
Со стороны 1С нужны НТТР-сервисы: объект «НТТР-сервис», шаблоны URL, методы GET и POST, обработчики в модуле сервиса. Исходящие вызовы к WMS обычно лежат в общем модуле интеграции через НТТРСоединение и НТТРЗапрос; входящие callback принимает опубликованный НТТР-сервис. В учебном контуре вместо живой WMS поднимают REST Mock Service в SoapUI - заглушку с фиксированным телом по методу и пути.
Публикация: конфигуратор, «Администрирование», «Публикация на веб-сервере» (или оснастка кластера). Отмечают сервисы, задают виртуальный каталог; root URL согласуют с шаблоном в метаданных. Адрес базы обычно «сервер/имя_базы/hs/ИмяСервиса/…» - хвост задаёт шаблон URL.
SoapUI на машине разработчика лучше ставить в каталог без пробелов: TestRunner на сервере часто падает изR09;за пробелов и прав. Перед ночным прогоном проверьте учётную запись регламентного задания, права на bin\testrunner.bat, каталог отчётов, файл проекта (.xml) и путь к SoapUI в «Настройках работы пользователя на рабочем месте» в «Тестирование 3.0».
РЕСТ-запросы к 1С и внешним сервисам в SoapUI
РЕСТ-проект создают через File → New REST Project. В URI можно указать учебный тиме-сервис, например , или сразу endpoint опубликованного НТТР-сервиса 1С. SoapUI развернёт Resource и Method; нестандартный путь Resource добавляют вручную.
Контекст: РЕСТ-запросы к 1С и внешним сервисам в SoapUI
Для 1С собирают полный путь: корень публикации плюс сегменты шаблона. Шаблон «/orders/{id}» в Resource даёт «/orders/1», Method - GET. Accept: application/json или text/xml. Для POST в теле запроса выберите Media Type (application/json) и введите JSON - так же, как Content-Type ожидает модуль НТТР-сервиса.
Submit отправляет запрос; на Raw видны статус, заголовки и тело. У тиме-сервиса в ответе ищут фрагмент вроде «datetime» или «time» - его потом зафиксируют в Assertion. Postman и Insomnia тоже подходят; шаги здесь под SoapUI, потому что «Тестирование 3.0» уже знает шаблон «Тест веб-сервисов (Soap UI)».
Типичные сбои при вызове 1С:
- 404 - лишний или пропущенный сегмент пути, сервис не опубликован, другая база в переопределении URL задания;
- 405 - метод в SoapUI не совпадает с объявленным в НТТР-сервисе (POST не добавлен к шаблону, хотя GET уже ходит);
- 401 - схема Auth в SoapUI не совпадает с аутентификацией сайта IIS (разберём в последнем разделе).
Для POST в Request кладут JSON, который WMS прислала бы на endpoint: номер заказа, статус, штрихкод. Content-Type должен совпадать с разбором Запрос.ПолучитьТелоКакСтроку в модуле сервиса.
Несколько НТТР-сервисов не смешивают: у каждого свой сегмент после hs в умолчанию.vrd и в IIS. «Метод не найден» в метаданных часто значит, что POST для шаблона просто не объявлен.
Mock РЕСТ-сервер как заглушка контрагента
REST Mock Service отвечает на заранее описанные запросы так, как ответила бы WMS. В проекте: New REST Mock Service, внутри MockAction с Method GET или POST и Path «/hello-world» (без хоста), к действию - MockResponse.
Контекст: Mock РЕСТ-сервер как заглушка контрагента
В ответе: HTTP 200, Media Type text/xml для ХМЛ-контракта или application/json, если интеграция на JSON (REST 1С чаще на JSON). В Custom Headers - Content-Type выбранного типа. Тело XML:
<response>
<status>OK</status>
<message>hello-world</message>
</response>
Теги в Mock должны совпадать с тем, что парсит код 1С - DOM, XPath или Contains в тесте. Для JSON - объект с полями после ПрочитатьJSON. Groovy в Mock возможен; для автотестов статический ответ надёжнее.
Mock Service Editor → Settings → Port (часто 8080; при конфликте 8088 или 9090). Запуск - зелёная кнопка. Проверка: браузер на localhost:порт/hello-world, затем в 1С временно подменяют базовый URL WMS на localhost и вызывают метод из обработки обмена.
Функция ВыполнитьЗапросКWMS(АдресРесурса, ТелоJSON) Экспорт
Соединение = Новый HTTPСоединение("localhost", 8088,,,, 30);
Запрос = Новый HTTPЗапрос(АдресРесурса);
Запрос.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
Если ЗначениеЗаполнено(ТелоJSON) Тогда
Запрос.УстановитьТелоИзСтроки(ТелоJSON, КодировкаТекста.UTF8);
КонецЕсли;
Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Если Ответ.КодСостояния <> 200 Тогда
ВызватьИсключение "HTTP " + Формат(Ответ.КодСостояния, "ЧГ=0");
КонецЕсли;
Возврат Ответ.ПолучитьТелоКакСтроку(КодировкаТекста.UTF8);
КонецФункции
Порт 8088 совпадает с Mock в примере; на боевом контуре меняют только хост и порт. Для HTTPS у Mock или сервиса укажите защищённое соединение (ЗащищённоеСоединениеOpenSSL) и порт 443 - в примере HTTP на localhost этого не требует. Точку останова ставят на разборе строки ответа.
Исходящий вызов на Mock настраивают как на боевой хост - меняются схема, хост и порт. Входящий callback моделируют РЕСТ-запросом из SoapUI на опубликованный НТТР-сервис 1С с телом, которое ждёт обработчик POST.
Отладка обработчиков HTTP в конфигураторе
Точки останова - в модуле НТТР-сервиса у процедур шаблонов URL. Исходящий REST отлаживают в общем модуле: формирование НТТРЗапрос, заголовки, ОтправитьДляОбработки, ПолучитьТелоКакСтроку, ПрочитатьJSON.
Контекст: Отладка обработчиков HTTP в конфигураторе
Конфигуратор запускают в режиме отладки на сервере приложений (или файловой базе с той же публикацией). Из SoapUI шлют GET на НТТР-сервис 1С или POST с телом callback; для исходящего сценария запускают обработку в 1С, которая бьёт в Mock. Сеанс должен попасть на сервер, где висит отладчик - на файловой базе это проще, на ragent/debug смотрите, что публикация на том же хосте.
Имя экспортной функции в НТТР-сервисе совпадает с метаданными: шаблон URL плюс НТТР-метод, например ordersPOST для шаблона orders и POST (регистр как в конфигураторе). Фрагмент входящего POST с JSON - имена у вас могут отличаться:
Функция ordersPOST(Запрос)
Тело = Запрос.ПолучитьТелоКакСтроку(КодировкаТекста.UTF8);
Чтение = Новый ЧтениеJSON;
Чтение.УстановитьСтроку(Тело);
Данные = ПрочитатьJSON(Чтение);
// здесь разбираем поля JSON
Ответ = Новый HTTPСервисОтвет(200);
Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
Запись = Новый ЗаписьJSON;
Запись.УстановитьСтроку();
ЗаписатьJSON(Запись, Новый Структура("status", "accepted"));
Ответ.УстановитьТелоИзСтроки(Запись.Закрыть(), КодировкаТекста.UTF8);
Возврат Ответ;
КонецФункции
После push результат смотрят в журнале регистрации или в регистре сведений, куда пишет ваш модуль обмена. Имена измерений и реквизитов - только из вашей конфигурации; выборкой перед отладкой убеждаются, что запись появилась:
ВЫБРАТЬ ПЕРВЫЕ 10
ВашРегистр.Период КАК Период,
ВашРегистр.Событие КАК Событие,
ВашРегистр.Комментарий КАК Комментарий
ИЗ
РегистрСведений.ВашРегистрОбмена КАК ВашРегистр
ГДЕ
ВашРегистр.Период >= &НачалоПериода
УПОРЯДОЧИТЬ ПО
Период УБЫВ
Параметр &НачалоПериода задают на начало суток теста. Если регистр периодический - отбор по периоду; у непериодического поля «Период» нет, отбирайте по дате записи или реквизиту из вашей схемы. В результате ищут строку приёма callback после вызова из SoapUI.
Пустая выборка при HTTP 200 чаще всего значит неверное имя регистра в запросе или отбор «уехал» относительно момента теста.
Тестовые сценарии и Assertions в SoapUI
У успешного REST Request в контекстном меню - Add to TestCase. TestSuite «Проверка запроса данных», TestCase «Получить текущее time» или «GET НТТР-сервис статуса». В Steps остаётся копия запроса с тем же endpoint.
Контекст: Тестовые сценарии и Assertions в SoapUI
На шаге запроса: вкладка Assertions → Add Assertion. Хватит двух проверок из базового сценария: Valid HTTP Status Codes (200) и Contains - подстрока «time» или «datetime» для тиме-сервиса, ожидаемое поле JSON для своего сервиса. Для XML подойдёт XPath Match. В OSS для JSON надёжнее Contains или Script Assertion; JsonPath Match - если доступен в вашей сборке SoapUI.
Зелёный play на TestCase прогоняет шаги; в логе - галочки на assertions. Отдельный TestCase «Mock hello-world» проверяет Content-Type и тело заглушки.
СОАР-веб-сервисы 1С заводят через СОАР-проект по WSDL; регистрация в «Тестирование 3.0» та же, но в статье фокус на REST.
Подключение к «Тестирование 3.0» и регламентный запуск
В базе «Тестирование 3.0» открывают подсистему «Тестирование», журнал «Тесты», создают элемент. Заполняют: наименование (например «проверка запроса данных»); тип «юнит-тест» - в значении конфигурации «Тестирование 3.0» это отдельная проверка НТТР-сервиса, а не процедура модуля в xUnit.V8; серьёзность дефекта по вашей шкале; вариант хранения GIT или общий каталог (на сервере задания - UNC или локальный путь для служебной учётной записи); путь к.xml проекта SoapUI. При хранении в GIT путь к.xml часто указывают относительно корня репозитория, если это поддерживает обработчик шаблона в вашей версии «Тестирование 3.0»; иначе - абсолютный путь на агенте.
В планировщике: журнал «Задания», конструктор, шаблон «Тест веб-сервисов (Soap UI)». В задании - ссылка на тест; переопределение URL базы 1С (строка «сервер/имя_базы» без протокола или полный адрес публикации - смотрите подсказку в форме задания и код обработки шаблона). Путь к SoapUI - в «Настройках работы пользователя на рабочем месте» у пользователя, под которым выполняется задание.
Как правило, переопределение подставляет базовый URL в custom properties проекта перед TestRunner - имена свойств смотрите в вашем.xml и в обработчике шаблона задания, чтобы один.xml гоняли против тестовой и предрелизной публикации без правок в GUI SoapUI.
После выполнения результат попадает в журнал тестов; отчёт TestRunner - в каталог из ключей командной строки (-f). Задание падает без GUI, если testrunner.bat не стартует (журнал Windows), нет прав на java, проект ссылается на localhost Mock, а Mock на сервере не поднят - для CI Mock выносят на стенд или отключают соответствующий case в suite.
Vanessa Automation проверяет формы и сценарии UI; здесь только НТТР-контракт и регламентный прогон SoapUI из 1С.
Авторизация, кодировка и запуск из CI
Auth в REST Request: при Wиндоwс-аутентификации IIS - NTLM, доменная учётная запись с правом на базу; при Basic - логин и пароль пользователя 1С по настройкам публикации. Несовпадение схемы даёт 401 до входа в код НТТР-сервиса.
Кириллица: в SoapUI-x.x.x.vmoptions в bin добавляют -Dfile.encoding=UTF-8 (или UTF8 по документации вашей JRE). Иначе Contains по русской подстроке в ответе 1С может ложно падать.
TestRunner - официальный неадлесс-запуск пакета SoapUI OSS (справка SmartBear по testrunner). Однострочный вызов из cmd:
-f- каталог HTML/JУнит-отчётов (создайте заранее, проверьте антивирус и место на диске);-I- ignore ошибки: прогон продолжается после падения шага, но ненулевой exit code при упавших тестах может сохраниться - сверяйте с документацией и политикой CI;-j- export JUnit (Allure, Jenkins);-r- сводка в консоль, удобно если stdout задания пишется в файл;-e- имя Environment с подставляемым base URL.
Тот же bat можно вызвать из внешней CI, если отчёт не нужен в журнале 1С. На сервере без интерактивного сеанса первый прогон лучше выполнить вручную из cmd под учётной записью задания - так видна ошибка java или путь, а не только код возврата регламентного задания.
После отладки блока интеграции имеет смысл зафиксировать автотесты в проекте SoapUI и карточке «Тесты», а не ограничиться разовым прогоном из GUI - иначе регламент не поймает регрессию.
Команды для копирования
cd /d "C:\Program Files\SmartBear\SoapUI-5.7.2\bin"
testrunner.bat -f "D:\Reports\SoapUI" -I -j -r -e "Default" "D:\Tests\Integration-REST-soapui-project.xml"
Перед регламентом подставьте версию каталога SoapUI, путь к.xml и имя Environment. Mock-case на сервере либо поднимают на том же порту, либо исключают из suite, который вызывает планировщик.
Вступайте в нашу телеграмм-группу Инфостарт