Workday Studio - запрос на отправку HTTP-запроса к API-интерфейсу поставщика с: не определен bean-компонент с именем http-token-auth

У меня есть интеграция с Workday studio для отправки запроса GET в API поставщика с использованием HTTP-компонента, но я получаю сообщение об ошибке ниже. У поставщика нет имени пользователя / пароля для подключения. Я должен подключиться с помощью токена. Кто-нибудь знает, как заставить это работать из студии для получения данных?

Причина: org.springframework.beans.factory.NoSuchBeanDefinitionException: не определен bean-компонент с именем http-token-auth.

Я отправил запрос разными способами: жестко запрограммировал URL с помощью токена, установил заголовки с помощью токена. Ниже приведены мои разные попытки. введите описание изображения здесь

Я не уверен, какую авторизацию Http это должно использовать. Там нет имени пользователя / пароля, только токен и URL для публикации с использованием CURL. Ниже показано, как выглядит студия со свойствами HTTP. введите описание изображения здесь

Ниже указано, что установлено в заголовке. введите описание изображения здесь

Кроме того, я могу получить данные с помощью SoapUI. Ниже приведен фрагмент запроса в SoapUI. введите описание изображения здесь

Ниже приведен необработанный запрос JSON в SoapUI, который успешно получает данные из API. введите описание изображения здесь

Любая помощь высоко ценится!!

Спасибо, -Ремо

Источник

2 ответа

Решение

К предисловию; Я не знаком с Workday Studio, и, кажется, нет никаких открытых документов, поэтому здесь может быть какой-то нюанс, который пропускает этот ответ.

Резюме

Рабочий день, ваш код или, возможно, какая-то используемая библиотека ссылаются на bean-компонент (см. Spring docs: Core Technologies), который не существует или не может быть найден.

Если вы не пишете здесь никакого Java-кода, это почти наверняка или проблема конфигурации, или ошибка в Workday Studio. Ниже приведены некоторые наблюдения, основанные на предоставленной вами информации. Но сначала дикая догадка.

Грубое предположение

Вероятно, что Workday обрабатывает это немного иначе, чем cURL или SoapUI. cURL и SoapUI делают что-то вроде следующего:

  • Отправьте запрос GET на URL с параметрами и включите ключ API в заголовок
  • Сервер отправляет желаемый ответ

Тем не менее, похоже, что Workday делает что-то вроде:

  • Отправьте GET-запрос, используя сценарий перед авторизацией, используя тип-запроса: 'token'
  • Сервер отвечает с правильным типом аутентификации, который его структура (предположительно Rails) использует для токенов; 'HTTP-токен-аутентификации'
  • Рабочий день (ошибочно) предполагает, что сервер использует платформу Spring, и пытается загрузить правильный bean-тип, основанный на этом ответе
  • Spring Framework Barfs, потому что нет такого боба

Я полагаю, что есть какой-то способ заставить Workday хорошо играть со стандартным API REST и просто предоставить ключ API на сервер поставщика, как он ожидает, вместо того, чтобы пытаться выполнить вызов / ответ.

Если это не так, то есть несколько более слабых возможностей ниже.

Нечетное Имя Бина

Имя компонента, указанное в ошибке: http-token-auth, который находится в кебаб-кейсе. Соглашение о присвоении имен bean-компонентам - (lower-) camelCase, поэтому там, где это указано, возможно, использовался не тот регистр.

Это может быть конфигурация Workday Studio, файл конфигурации XML или какой-то другой написанный вами код, если таковой имеется.

конфигурация

Если имя бина правильное, то, скорее всего, есть другая проблема конфигурации. Spring может неявно обнаруживать компоненты-кандидаты, сканируя путь к классам (см. Документы Spring: сканирование путей к классам и управляемые компоненты) или загружая его из XML проекта. Проблема может быть:

  • Путь сборки неверен (см. Этот ответ esaj, если вы незнакомы)
  • Путь к классу неправильный, поэтому Spring просто не видит его. В этом случае это похоже на конфигурацию, специфичную для рабочего дня.
  • Бин находится в проекте XML, но вложен. В этом случае он был бы доступен только для включающего компонента. Одним из решений этой проблемы является активация соответствующего профиля.
  • Вопрос упаковки; если бин не будет включен в полученный развернутый jar, то возникнут проблемы. Это решение dawrutowicz следует применять в ряде случаев.
  • Конфигурация проекта; все настройки на ваших скриншотах выглядят абсолютно корректно и должны работать нормально, поэтому в настройках вашего проекта может быть что-то скрытое

Ошибка в Workday Studio

Это кажется несколько менее вероятным, но всегда возможно. Если вы вообще не написали Java-код, то в коде Workday есть что-то, что обслуживает этот неожиданный http-token-auth или неправильно принимает его откуда-то еще и пытается загрузить бин, используя его.

Последние мысли

Поскольку вы пытаетесь работать с API поставщика, я настоятельно рекомендую вам попробовать сотрудничать с одним из инженеров. Гарантированно, у них есть по крайней мере один инженер, который раньше занимался сложными вопросами интеграции. У них будет больше информации об их API и, возможно, они смогут дать вам более непосредственный вклад в любую конфигурацию / код, которым вы сможете поделиться.

Источник

При отправке запроса Rest POST на сторонний веб-сервис из Workday Studio с использованием аутентификации Bearer было получено идентичное сообщение об ошибке.

Было решено установить тип вывода заголовка "message" вместо "rootpart". Это не ошибка в Workday Studio.

Workday Studio устанавливает тип выходного заголовка

С уважением, Шираз

Источник
Другие вопросы по тегам