eclipse - Workday Studio - 向供应商 API 发出的 HTTP 请求接收错误 : No bean named 'http-token-auth' is defined

Question

我有一个 Workday 工作室集成，可以使用 HTTP 组件向供应商的 API 发送 GET 请求，但我收到以下错误。供应商没有用于连接的用户名/密码。我必须使用 token 进行连接。有谁知道如何从 Studio 获取数据？

原因:org.springframework.beans.factory.NoSuchBeanDefinitionException:没有定义名为“http-token-auth”的 bean

我以多种不同的方式发送了请求:使用 token 对 URL 进行硬编码，使用 token 设置 header 。以下是我的不同尝试。

我不确定这应该使用什么 Http 授权。没有用户名/密码，只有一个 token 和一个使用 CURL 发布的 URL。下面是 studio 使用 HTTP 属性的样子。

下面是Header上的设置。

此外，我还可以使用 SoapUI 获取数据。下面是 SoapUI 中请求的片段。

下面是成功从 API 获取数据的 SoapUI 中的 JSON 原始请求。

非常感谢任何帮助!!

谢谢你，-Remo

Answer 1

前言；我对 Workday Studio 不熟悉，而且似乎没有任何公共(public)文档，因此此答案可能遗漏了一些细微差别。

总结

Workday、您的代码或可能正在使用的某些库正在引用一个不存在或无法找到的 bean(请参阅 Spring 文档:Core Technologies)。

如果您没有在此处编写任何 Java 代码，则几乎可以肯定是配置问题或 Workday Studio 中的错误。以下是根据您提供的信息得出的一些看法。但首先，一个大胆的猜测。

疯狂的猜测

Workday 处理此问题的方式似乎与 cURL 或 SoapUI 略有不同。 cURL 和 SoapUI 正在做类似以下的事情:

• 使用参数向 URL 发送 GET 请求，并在 header 中包含 API key
• 服务器发送期望的响应

但是，听起来 Workday 正在做的事情更像是:

• 假设预授权场景发送 GET 请求，使用 challenge-type: 'token'
• 服务器以其框架(可能是 Rails)用于 token 的正确身份验证类型进行响应； 'http-token-auth'
• Workday(错误地)假定服务器正在使用 Spring 框架，并尝试根据该响应加载正确的 auth 类型 bean
• Spring 框架 barfs 因为没有这样的 bean

我想有一些方法可以让 Workday 与标准 REST API 很好地配合使用，并且只需按预期向供应商的服务器提供 API key ，而不是尝试进行质询/响应。

如果不是这样，下面还有一些更杂草的可能性。

奇怪的 Bean 名称

错误中指定的bean名称是http-token-auth，是kebab-case。命名 bean 的约定是(小)驼峰式命名，因此无论在哪里指定，都可能只是使用了错误的大小写。

这可能在 Workday Studio 配置、XML 配置文件或您编写的一些自定义代码中(如果有)。

配置

如果 bean 名称正确，则可能存在其他一些配置问题。 Spring 可以通过扫描类路径(参见 Spring 文档:Classpath scanning and managed components)或从项目 XML 加载它来隐式检测候选组件。问题可能是:

• 构建路径错误(不熟悉请参见this answer by esaj)
• 类路径错误，所以 Spring 看不到它。在这种情况下，这似乎是特定于 Workday 的配置。
• bean 在项目 XML 中，但是是嵌套的。在那种情况下，它只能由封闭的 bean 访问。一种解决方案是激活相应的配置文件。
• 包装问题；如果 bean 没有包含在生成的部署 jar 中，那么就会出现问题。 This solution by dawrutowicz应适用于多种情况。
• 项目配置；您屏幕截图中的所有设置看起来都完全正确并且应该可以正常工作，因此您的项目设置中可能隐藏了一些内容

Workday Studio 中的错误

这似乎不太可能，但总是有可能。如果您还没有编写任何 Java 代码，那么 Workday 代码中可能会提供这种意外的“http-token-auth”，或者不恰本地从其他地方接受它并尝试使用它加载一个 bean。

最后的想法

由于您正在尝试使用供应商的 API，我强烈建议您尝试与那里的一位工程师合作。保证，他们至少有一个工程师，以前处理过复杂的集成问题。他们将提供有关其 API 的更多详细信息，并且可能能够就您能够共享的任何配置/代码向您提供更直接的输入。