Нагрузочное тестирование SOAP-сервисов в Perfscale — WSDL, envelope и настоящие фолты

SOAP не умер — он просто ушёл в enterprise. Банковские шлюзы, госсервисы, страховые, ERP и биллинги по-прежнему отдают WSDL и ждут конверт с Envelope/Body. И когда такой сервис нужно нагрузить, выясняется неприятное: современные инструменты либо не знают SOAP вовсе, либо сводят всё к «POST с XML-строкой» — без разбора фолтов и без понимания операций. Теперь SOAP работает по всему стеку Perfscale.

SOAP — премиум-возможность, доступная на планах Scale и Enterprise. Тесты с действиями pro/soap* ограничены по плану; всё ниже работает одинаково, гоняете ли вы один вызов из CLI или тысячи с парка машин.

Первый вызов

SOAP-шаг — это POST с корректным конвертом и заголовками. Payload вы пишете сами (движок не генерирует XML из XSD — об этом ниже), ${{ }}-интерполяция работает как везде:

# test.yaml
steps:
  - name: add two numbers
    uses: pro/soap@v1
    with:
      url: http://www.dneonline.com/calculator.asmx
      soap_action: "http://tempuri.org/Add"
      payload: |
        <Add xmlns="http://tempuri.org/">
          <intA>2</intA>
          <intB>2</intB>
        </Add>
    check:
      status: 200
      body_contains: "<AddResult>4</AddResult>"

perfscale run -f test.yaml -c load.yaml

Заголовки выставляются по версии протокола: для SOAP 1.1 — Content-Type: text/xml и SOAPAction, для 1.2 — application/soap+xml с action= внутри. Латентность каждого вызова ложится в ту же гистограмму http_req_duration, что и остальной HTTP-трафик, — перцентили SOAP стоят рядом со всем остальным, что вы меряете.

WSDL читается один раз, а не в каждом шаге

Endpoint, версия SOAP и soapAction каждой операции уже написаны в WSDL сервиса. pro/soap-config@v1 парсит её один раз в блоке before: конфиг-файла и отдаёт переиспользуемый профиль:

# config.yaml
vus: 50
duration: 5m
before:
  - uses: pro/soap-config@v1
    with: { wsdl_url: http://www.dneonline.com/calculator.asmx?WSDL }
    outputs: calc

# test.yaml
steps:
  - uses: pro/soap@v1
    with:
      connection: "${{ config.calc }}"   # endpoint/version/operations — из профиля
      operation: Add                     # soapAction подставляется из WSDL
      payload: |
        <Add xmlns="http://tempuri.org/"><intA>2</intA><intB>2</intB></Add>

В шаге не остаётся ни URL, ни action-литералов: operation: Add резолвится в soapAction из WSDL, а явные параметры при необходимости перекрывают профиль. Парсинг namespace-толерантный — префиксы soap:/soap12: не хардкодятся, так что чужие WSDL с экзотическими префиксами не ломают разбор. Если в WSDL несколько сервисов — выберите нужный через service/port.

Fault — это не успех, даже если HTTP 200

Главная ловушка SOAP-нагрузки: сервер отвечает 200 OK с <Fault> в теле, а инструмент на базе сырого HTTP честно считает это успехом. Perfscale разбирает тело ответа: фолт делает шаг неуспешным на любом статусе, а faultcode/faultstring (1.1) или Code/Reason (1.2) попадают в вывод шага и в лог:

check:
  status: 200
  # а вот так можно убедиться, что фолтов нет вообще:
  # (шаг с Fault и так упадёт — check тут для явности)

Отдельно считаются метрики рана: soap_requests, soap_faults, soap_errors (транспортные ошибки и не-2xx без фолта) — в сводке видно и темп вызовов, и долю фолтов.

Что осознанно не входит

Генерация envelope из XSD — payload пишете вы; движок не выводит XML из схемы типов.
WS-Security — подписи и шифрование конвертов не поддерживаются.
MTOM/attachments — бинарные вложения вне скоупа.

Если ваш сервис упирается в одно из этих ограничений — напишите нам, это определит приоритеты.

Дальше