Forum Discussion
Here's what I've done
- Create a step that goes out and gets your token. Name it "get_token"
- Create the next step as a groovy script, and name it "xfer_bearer_token". In the script area, you can right click>GetData>... then point it at the previous step's response/property. This will prompt you create a variable in the groovy code. Then just return your concatenation like this
- Create a step that calls an endpoint that needs the token. Set up a property in this step called 'Authorization' and set the style to 'HEADER'. Right click inside of the property value>GetData>... then find your groovy script that you just made. Choose the result of the groovy script
This worked for me
Hi dasjestyrm,
Although this is somewhat late, I would like to thank you for the proposed solution.
This was just was I was after! Simple, short and to the point :)
To Smartbear:
Although I have to say that it seems unnecessary difficult to achieve this. Why can't I use get data to the element in another test and extract the fields that way without going through (although rather simple and short) groovy script to define new values and then use Get Data that is somehow able to extract the same information I wanted in the first place...
This makes zero sense from a user perspective, why are headers and ressources excluded or limited with what data can be retrieved? It's obviously there, or it would be impossible even through a groovy script.
- PaulMS9 years agoSuper Contributor
It is possible to concatenate the token_type and access_token without adding a groovy script step.
Using this example add header style parameter
Name: Authorization
Value: ${get_token#Response#$.token_type} ${get_token#Response#$.access_token}
or if the type is always bearer
Value: Bearer ${get_token#Response#$.access_token}
An advantage of using groovy script step is that if you need to use the same authorization header for many requests then property expansion to get data from the response is only processed once and will be consistent.
- Crazy_Chris9 years agoOccasional Contributor
Hi PaulMS and thanks for your examples.
What I really would like is to parameterize the header value and resource path in the same way, but under the Projects structure and not on every single Test under the SoapUI structure.
But I cannot seem to get to any of the data elements that way.
Right now I am building a testsuite that will be included in an automated build pipeline to do a health check of all the services, so it works even though the scope right now is small.
But I see problems when something changes that I have to manually edit every single value on each Test affected as the values are not defined in the Project/Library, but as a reference in each Test to the value extracted.
I might have done this wrong but I cannot for the life of me figure out anyway to accomplish this in Project/Library section or one place in a Test to pass the the rest of the Tests in that TestCase/TestSuite.
- PaulMS9 years agoSuper Contributor
You can create header parameters at the resource level to set a default value for the authentication token. The default value can be a project or test suite property that only needs to be set once for many test steps.
Can you show an example or image of the project structure and the parameters you want to set?