JMeter and oAuth bearer token usage
So this came up during the week....
"I need to be able to connect to a Cloud Service that uses authentication and make calls to it to get results. I've used POSTMAN, but now I need to do some load testing, so I want to use JMeter to doing some load testing, but I cannot get it to work. Help."
Putting aside the initial chest puffing "sigh", as this was at 9pm and I had finished work and was back at my hotel, I thought to myself... "hey, why not help out"......
Turns out I had an ancient installation of JMeter from back in 2015, (must have been back in the IBM MobileFirst days), so I didn't bother to upgrade but thought I'd use that setup as-is.
After taking a look at the UI for a bit, it started to come back to me and I also do remember having to setup getting access tokens for authentication way back then. Okay, now I was hooked. Digging through my laptop for old .jmx files and hacking about I finally solved the problem and shared it back with the original seeker of help, who, apparently had spent a week not being successful! Wow. I was going to comment on the lack of Googling skills, but then they reminded me they are working in China. Enough said.
As a reminder to myself, if this comes up again, I'm going to share with myself and the internet how to set this up in a nice and simple way. BTW - the API that I'm calling is the IBM Cloud Discovery Service.
"Add a cognitive search and content analytics engine to applications to identify patterns, trends and actionable insights that drive better decision-making. Securely unify structured and unstructured data with pre-enriched content, and use a simplified query language to eliminate the need for manual filtering of results."
Here goes....start up JMeter and add the entries as shown here:
The 'Flow Results' is actually the OUTPUT, so when you press the [>] run button, this is where you must look for the output of the execution
Here you can set the amount of requests you want to make, how long a gap you wish to make between those requests and how many times you want to loop. For now, we'll just do 1 call, a single time:
Here we shall set the values to connect to the AUTHENTICATION SERVER and set the parameters that we shall pass to this server - this will include the APIKEY of YOUR instance of WDS:
The next we set some of the header values for this HTTPS call:
Here we are setting up some logic so we can extract the "access-token" from the response of the HTTPS call, this extracts the value and places it into a variable named "access-token" that we shall reference later on:
Now we have the "access-token" we can make the actual HTTPS call to the WDS service. To perform this, we enter the HTTPS and server location of the WDS instance, set the METHOD to GET and enter the PATH url to include the environmentId and the collectionId of YOUR WDS instance. Then you can set the parameters one by one as shown below. Now, I have set the parameter "natural_language_query" to have a value of "revenue", which is nice and simple, but if you then choose to insert the more complex values that involve the usage of double-quotes, make sure the [x]Encode? checkbox is selected, so that the parameter is encoded correctly when sent to WDS, otherwise you'll just get an error:
Here we set the header value for "Authorization", we set it to "Bearer " and the variable value that we captured earlier into the variable "access-token":
That's it! Job done.
Now, all we have to do is move to the "Flow results" and press the [>] run button:
If you have everything setup okay, then the following will occur. But, if you do not, you can use this area to diagnose/debug what you've setup wrong and attempt to fix it until you do get a valid green icon steps as shown below. There are 3 tabs on the output steps, the first is the "result", this just let's you know this was successful:
The next tab, shows you exactly what was actually SENT to the URL - this is the HTTP Request:
The final tab, shows you the result that was returned. For us, it shows the access-token that is returned along with some other metadata values:
If we select the next HTTP request, we can see the first tab as shown here:
The next tab shows the actual URL that was called and what the parameters passed were. You'll notice that you can see that the header for "Authorization" has been correctly populated:
The final tab then shows the results that came back from WDS:
There you go, that is how to setup the usage of JMeter to use oAuth/identity tokens to make successful API calls to the IBM Discovery Service.
Remember though, if you plan on performing high-volume stress testing, let the WDS support personnel know first! Just open a support ticket and let them know what you are going to do, when youa re going to do it and for how long. Otherwise, they have automated measures in place that will treat your stress testing as a DDoS attack and you'll get cut off and will not be able to do your work!
(Of course I haven't done such a thing....cough cough....I'm just letting you know, in case you "forget" in the future)
"I need to be able to connect to a Cloud Service that uses authentication and make calls to it to get results. I've used POSTMAN, but now I need to do some load testing, so I want to use JMeter to doing some load testing, but I cannot get it to work. Help."
Putting aside the initial chest puffing "sigh", as this was at 9pm and I had finished work and was back at my hotel, I thought to myself... "hey, why not help out"......
Turns out I had an ancient installation of JMeter from back in 2015, (must have been back in the IBM MobileFirst days), so I didn't bother to upgrade but thought I'd use that setup as-is.
After taking a look at the UI for a bit, it started to come back to me and I also do remember having to setup getting access tokens for authentication way back then. Okay, now I was hooked. Digging through my laptop for old .jmx files and hacking about I finally solved the problem and shared it back with the original seeker of help, who, apparently had spent a week not being successful! Wow. I was going to comment on the lack of Googling skills, but then they reminded me they are working in China. Enough said.
As a reminder to myself, if this comes up again, I'm going to share with myself and the internet how to set this up in a nice and simple way. BTW - the API that I'm calling is the IBM Cloud Discovery Service.
"Add a cognitive search and content analytics engine to applications to identify patterns, trends and actionable insights that drive better decision-making. Securely unify structured and unstructured data with pre-enriched content, and use a simplified query language to eliminate the need for manual filtering of results."
Here goes....start up JMeter and add the entries as shown here:
The 'Flow Results' is actually the OUTPUT, so when you press the [>] run button, this is where you must look for the output of the execution
Here you can set the amount of requests you want to make, how long a gap you wish to make between those requests and how many times you want to loop. For now, we'll just do 1 call, a single time:
Here we shall set the values to connect to the AUTHENTICATION SERVER and set the parameters that we shall pass to this server - this will include the APIKEY of YOUR instance of WDS:
The next we set some of the header values for this HTTPS call:
Here we are setting up some logic so we can extract the "access-token" from the response of the HTTPS call, this extracts the value and places it into a variable named "access-token" that we shall reference later on:
Now we have the "access-token" we can make the actual HTTPS call to the WDS service. To perform this, we enter the HTTPS and server location of the WDS instance, set the METHOD to GET and enter the PATH url to include the environmentId and the collectionId of YOUR WDS instance. Then you can set the parameters one by one as shown below. Now, I have set the parameter "natural_language_query" to have a value of "revenue", which is nice and simple, but if you then choose to insert the more complex values that involve the usage of double-quotes, make sure the [x]Encode? checkbox is selected, so that the parameter is encoded correctly when sent to WDS, otherwise you'll just get an error:
Here we set the header value for "Authorization", we set it to "Bearer " and the variable value that we captured earlier into the variable "access-token":
Now, all we have to do is move to the "Flow results" and press the [>] run button:
If you have everything setup okay, then the following will occur. But, if you do not, you can use this area to diagnose/debug what you've setup wrong and attempt to fix it until you do get a valid green icon steps as shown below. There are 3 tabs on the output steps, the first is the "result", this just let's you know this was successful:
The next tab, shows you exactly what was actually SENT to the URL - this is the HTTP Request:
The final tab, shows you the result that was returned. For us, it shows the access-token that is returned along with some other metadata values:
If we select the next HTTP request, we can see the first tab as shown here:
The next tab shows the actual URL that was called and what the parameters passed were. You'll notice that you can see that the header for "Authorization" has been correctly populated:
The final tab then shows the results that came back from WDS:
There you go, that is how to setup the usage of JMeter to use oAuth/identity tokens to make successful API calls to the IBM Discovery Service.
Remember though, if you plan on performing high-volume stress testing, let the WDS support personnel know first! Just open a support ticket and let them know what you are going to do, when youa re going to do it and for how long. Otherwise, they have automated measures in place that will treat your stress testing as a DDoS attack and you'll get cut off and will not be able to do your work!
(Of course I haven't done such a thing....cough cough....I'm just letting you know, in case you "forget" in the future)
Comments
Post a Comment