Получение кода или тела ответа для использования в качестве условия для отправки другого запроса в tryMax

У меня есть этот запрос, который запрашивает мою службу, которая находится внутри tryMax.

Токен доступа для аутентификации запроса истекает каждые пять минут и генерируется в начале запуска моделирования как ${token}

Есть ли способ в tryMax отправить другой запрос генерации токена, который обновит истекший ${token} (значение заголовка авторизации), если код ответа 401 или тело ответа содержит информацию о запросе, который не аутентифицируется. Затем повторите запрос, прежде чем tryMax перейдет к следующей итерации?

Я пробовал установить код состояния в качестве атрибута сеанса, однако запрос не отправляется и токен не обновляется, я пробовал выполнить .doIf после запроса exec, поместив doIf внутри своего собственного exec и даже поигрался с transformResponse, все безуспешно.

Есть предложения, как подойти к этому?


gatling scala-gatling
person Przemek Hendel    schedule 06.06.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

вы можете сделать что-то вроде того, что описано в Gatling (тест производительности): как выполнять задачу в фоновом режиме каждые x минут

Однако - действительно ли это тот сценарий, который вы хотите смоделировать? Каким образом клиент, который вы моделируете, обрабатывает ошибку 401? Предлагаемый вами сценарий работает только в том случае, если клиент отвечает за ручную обработку собственных обновлений.

person James Warr    schedule 06.06.2019
comment
проблема была немного сложнее, чем я, но мне как-то удалось ее решить. Я упустил из виду, что, когда status проверка отсутствует, выполняется еще одна проверка на 200 или 304. Мне удалось обработать авторизацию: я отправляю тихий запрос, который сохраняет только код состояния запроса, затем я перехожу к .doIf(session => session("status").as[Int] == 401 || (session("tokenGenerationTime").as[Long] - System.currentTimeMillis()) > 180000L) , если выражение истинно, он генерирует новый токен и переходит ко второму doIf после этого, который отправляет запрос - person Przemek Hendel; 08.06.2019