I have a Workday studio integration to send a GET request to a vendor's API using an HTTP component, but I'm receiving the error below. The vendor doesn't have a username/password to connect. I have to connect using a token. Does anyone know how to make this work from Studio to GET data?
Reason: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'http-token-auth' is defined
I have sent the request in many different ways: hard coding the URL with the token, setting headers with the token. Below are my different attempts.
I’m not sure what Http authorization this is supposed to use. There is no username/password, just a token and a URL to post using CURL. Below is what studio looks like with the HTTP properties.
Below is what is set on the Header.
Also, I'm able to GET data using SoapUI. Below is a snip of the request in SoapUI.
Below is the JSON raw request in SoapUI that is successful in getting data from the API.
Any help is much appreciated!!
Thank you, -Remo
To preface; I'm not familiar with Workday Studio, and there don't seem to be any public docs, so there may be some nuance here that this answer misses.
Workday, your code, or possibly some library being used is referencing a bean (see Spring docs: Core Technologies) that does not exist or can not be found.
If you're not writing any Java code whatsoever here, it's almost certainly either a configuration issue or bug in Workday Studio. Below are some observations based on the information you've provided. But first, a wild guess.
It seems likely that Workday is handling this a little differently than cURL or SoapUI. cURL and SoapUI are doing something like the following:
However, it sounds like Workday is doing something more like:
I imagine there's some way to get Workday to play nicely with a standard REST API, and just supply the API key to the vendor's server as it expects, rather than trying to do a challenge/response.
If this isn't it, there are some more weedy possibilities below.
The bean name specified in the error is http-token-auth
, which is in kebab-case. The convention for naming beans is (lower-) camelCase, so wherever that's specified may have just used the wrong casing.
This could be in the Workday Studio configuration, the XML config file, or some custom code you've written, if any.
If the bean name is correct, then there's likely some other configuration issue. Spring can implicitly detect candidate components by scanning the classpath (see Spring docs: Classpath scanning and managed components) or loading it from the project XML. The issue could be:
This seems somewhat less likely, but is always a possibility. If you haven't written any Java code whatsoever, then there's something either in the Workday code that's serving up this unexpected 'http-token-auth' or inappropriately accepting it from somewhere else and trying to load up a bean using it.
Since you're trying to work with a vendor's API, I'd strongly recommend you try to collaborate with one of the engineers there. Guaranteed, they have at least one engineer who has dealt with complicated integration issues before. They'll have more details about their API, and might be able to give you more direct input on any configuration/code you'd be able to share.