1. открываем соап добавляем туда WSDL
2. прокидываем её на Web Service
теперь самое интересное
3. берем из соапа из блока пропертис Endpoit и закидываем его в наш HTTP request (он же может быть SOAP Request) в JMeter. протокол сразу выкидываем из этой сроки на помойку, айпишник идет в поле Server Name or IP, а все остальное, ислючая первый слеш идет в поле чуть пониже - Path.
4. Выставляем в нашем HTTP Request Method POST (не факт что это важно), Body пока не трогаем.
5. возвращаемся в SoapUI - Под запрососм который мы прокидываем есть такая классная кнопочка WS-A она там же где headers и прочие вкладочки. Жмакнув на нее мы увидим поле Action - воруем все из него.
6. В jmeter переходим на уровень ниже от нашего HTTP Request, там у нас HTTP Header Manager (если его нет о добавляем, главное чтобы он был дочерним по отношению к HTTP Request). Заходим в него и нажимаем Add - в столбик Name: добавляем SOAPAction, а в Value добаяем украденные знания на шаге 5, но ОБЯЗАТЕЛЬНО в двойных ковычках (тут было много матных слов).
7. Идем опять в SoapUI, теперь нас интересует поле ответа, там есть вкладка Headers, прям под самим ответом. Тыкнув на нее мы видим поле content-type, его воруем и в Jmeter HTTP Headers Manager делаем еще один параметр тыкая на Add, где Name - Content-Type, а Value, то что мы сперли.
8. Теперь переходим к наполнению Body, его воруем из посылаемого запроса в SOAP, но поле <soapenv:Header/>
заменяем на
<soapenv:Header>
  <UsernameToken xmlns="http://siebel.com/webservices">SADMIN</UsernameToken>
  <PasswordText xmlns="http://siebel.com/webservices">SADMIN</PasswordText>
  <SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType>
</soapenv:Header>
9. Все остальное в тест плане удаляем или дизейблим. У нас должно остаться:
Test Plan
—Tread Group
—--HTTP Request
—-----HTTP Header Manager
—View Results Tree
10. Запускаем, смотрим ответ наслаждаемся

Я уже разные места экранировал, но не один не заработал

подожди неделю мы библиотеку выложим)

Могу потестить

мы щас юнит тесты дописываем, опубликуем тут

ну и доку какую никакую тоже немножко набросаем

https://gist.github.com/polarnik/2483c5fa2dd7380ac0f694a986323913

Вот так попробовать модно ещё. Сейчас только так делаю

С org.aeonbits.owner

Required request part 'file' is not present

а если параметр оставить пустым?

Спасибо, познавательно. Я похожее делал для заглушки - доступов пока что нет, куда будем стучаться - неизвестно, но поиграть с метриками для Prometheus'а (другая больная тема) хотелось уже сейчас. Я смог прокинуть обращения джметра на заглушку, вопрос как раз стоял в том, как означенные переменные должны заполняться в реальных условиях. Сейчас скину свой мини-гайд по заглушке - может, тоже будет полезен кому-то.

Проверка работоспособности нагрузочного скрипта (SOAP-сервис) при отсутствии доступа.

Задача разбивается на 3 этапа:
1) Получение WSDL нагружаемого сервиса.
2) Создание SOAP-проекта с Mock Response'ом.
3) Модифицирование нагрузочного скрипта для обращения к заглушке.

Получение WSDL нагружаемого сервиса.
Простой путь - запрос WSDL - не для нас, потому будем делать этот файл из имеющихся примеров с запросами и ответами. Источник вдохновения: https://crunchify.com/create-sample-wsdl-in-eclipse-and-generate-client/ Нужен Eclipse с Java Enterprise Developer Tools (Eclipse -> Help -> Eclipse Marketplace -> искать по "WSDL"). Создаём проект, добавляем в него WSDL и начинаем рисовать. Элементу Operation даём название нужного нам сервиса, блоки input parameters и output parameters называем по имени верхнеуровневых тегов запроса и ответа (т.е. если сервис называется Login, запрос обрамлён в LoginRq, а ответ - в LoginRs, то соответственно называем Operation, input parameters и output parameters). После переходим во входные параметры и начинаем добавлять теги, присутствующие во входном сообщении.

Создание SOAP-проекта с Mock Response'ом.
Источник вдохновения: https://www.soapui.org/soap-mocking/service-mocking-overview.html Создаём папку проекта, подкладываем WSDL из 1-го этапа, в этом же проекте создаём Mock Service. В Response вставляем пример ответа. Для проверки работы созданного включаем заглушку и отправляем пример запроса. При возникновении ошибки с подключением воспользоваться http://opensource4everyone.blogspot.com/2017/11/soap-ui-error-netsocketexception.html

Модифицирование нагрузочного скрипта для обращения к заглушке.
Дублируем нужный запрос, помечаем словами "With Mock", "GAG" или другим понятным вариантом. В Response Assertion вставляем пример ответа. Заполняем параметры нагрузочного запроса в соответствии с содержимым адресной строки из SoapUI. Например, если там стоит http://localhost:8088/mockDummySOAP, то "Protocol" = HTTP, "Server Name or IP" = localhost, "Port Number" = 8088, "Path" = mockDummySOAP. Активируем Mock Service, запускаем нагрузочный скрипт, проверяем результат в View Results Tree.

Да, пункт с "созданием" WSDL - чудовищное шаманство, но если имеются только XML с примерами запроса/ответа, по-другому никак.

да, тоже с этим мучался помню)

после того как поборол думал - этот кейс достоин хабра))

java.lang.IllegalStateException: Name is blank

не помогает

Required request part 'file' is not present

Mime type должен быть image, text, ... Что-то такое.

А так - прописано верно

так тоже пробовал

Не работает что-то в результате?

image/jpeg вот такое вставлял

Required request part 'file' is not present

вот это

в постомоне такая же ошибка выходит если в key что то кроме

file