I doing test backend application (also Java and Node JS, communication: WebSocket in NodeJs part and http in Java part) in JMeter
I must parametrize url, to switch between development url, production and prepod
I did it by CSV file. I created folder CSV, in folder where I have Jmeter 5.0. I prepare 3 csv file
1.development are:
protocol, host
http, 10.219.227.66
2.prepod
protocol, host
https, prepod.myprepod.io
3.production
protocol, host
https, production.myproduction.io
I set this that:
CSV Data Set Config
Filename ${_P()/usr/local/Cellar/jmeter/5.0/libexec/CSV/development,development}.csv
variable Names ; protocol,host
WebSocket Open Connection
Server name or IP ${host}
Switch Controller
Switch Value ${protocol}
HTTP Request Default - server name or ip ${host}, protocol http ${protocol}
User defined variables
name value
protocol . ${_P(protocol,)}
host . ${_P(host,)}
Questions are:
What is wrong in my set this? what and how i must improve?
I project test save in desktop,but Jmeter 5.0 i have in others places in my computer - in users is folder jmeter 5 - if this could be a problem?
Does anyone know why it does not work for me and how to fix it?.
Everything is wrong
Given you defined protocol and host variables in the CSV file you don't need to declare them in the CSV Data Set Config, just leave the field blank
JMeter supports CSV files which have a header line defining the column names. To enable this, leave the "Variable Names" field empty. The correct delimiter must be provided.
Don't use full paths to CSV files as most probably it will make running tests on other machines, in distributed mode or in continuous integration server impossible.
so go for something like ${__P(environment,development)}.csv
Double check that protocol and host variables have expected values using Debug Sampler and View Results Tree listener combination
If you don't see them - check jmeter.log file for any suspicious entries, most probably JMeter cannot find .csv file and read variables from it. See How to Debug your Apache JMeter Script article for more details.
I fail to see any WebSocket URL schema (ws or wss) in your CSV files so I doubt your WebSocket Open Connection Server will ever be successfully executed.
Related
I am BRAND new to Quasar Vue3 apps(DevOps helping dev team). We use GitLab for our CICD pipelines and our apps run on OpenShift containers. We also use OpenShift secrets for populating the environment variables for each environment(envFrom) when the container starts. However, we are having a hard time figuring out how to do this with a new Quasar Vue3 app. We've gone through various iterations found on "Google University" and Quasar's documentation, but nothing has helped. We've tried the method of using process.env in the quasar.config.js file:
env: {
myVar: process.env.VUE_APP_VARIABLE
}
However, that seems to be a build-time method and only uses a dummy value we've put into a GitLab CICD variable for testing.
I've also tried the method of using a .js script file defining a function:
export default function getEnv(name) {
return process.env[name];
}
And then importing and calling that function in the MainLayout.vue file:
import getEnv from '../service/env.js'
return {
.
.
myVar: getEnv("VUE_APP_VARIABLE")
}
That works if I return hard-coded string from the script(eg: return "ValueFromScript";), but if I try to return using process.env at all with varied syntaxes, I get blank/null values
return process.env[name];
return process.env."name";
return process.env.VUE_APP_VARIABLE;
return process.env["VUE_APP_VARIABLE"];
etc.
Lastly, we've experemented with the "dotenv" method described here, but that only reads from a .env file.
Can anyone tell me what I'm missing or if this is even possible? I really want to avoid using .env files, it's really not the best practice for production applications.
Thanks.
This is a web application that runs in a browser, you can't access runtime env variables. If you configure FOO: 'test' in quasar.config.js > build > env, then reference it in your app as console.log(process.env.FOO), on build time it will get replaced and turned into console.log('test'). You can check the final code in dist/* to confirm.
You wouldn't need to use a secret management tool here because all the env variables you want to pass to the client application will be seen by users someplace. If you are passing a secret key or similar, then you are probably doing it wrong. You should handle it in the server where it can stay secret instead.
If you are sure the values that will be accessed in the browser are not secret, and all you just want is just them to change on runtime, then you can implement a runtime variable system. It can be done by:
Making an API request on runtime and getting them.
Storing a JSON file somewhere and reading it.
Doing SSR and assigning the variables into ssrContext on the server side. As an example, on the server side, in an SSR middleware, do ssrContext.someVar = process.env.SOME_VAR(env variables are runtime in server-side because they are Node apps that run on a server), then access ssrContext.someVar in the Vue app when the app is rendering on the server side.
If you have some secret things to do, you can do it inside the SSR middleware and return the non-secret result of it to your app using this method as well. So, if this is the case, you can use a secret manager to keep things only available to the Node application which uses the secrets.
Working with our Devs, we came up with a way to setup and use values from OpenShift secrets as environment variables at RUNTIME(should work for K8s in general). I've seen bits and pieces of this in my searches, hopefully I can lay it out in a cohesive format for others that might have the same application requirement.
PreSetup
Create a .sh script file somewhere in your src directory that defines a "getEnv" function as follows. We created a folder for this at src/service:
env.js
export default function getEnv(name) {
return window?.configs?.[name] || process.env[name];
}
Create another .sh script file that writes a json string to another script file to be used later in your code.
This will create another script file dynamically when the container starts up as you will see in later steps.
get-env-vars.sh
JSON_STRING='window.configs = {
"ENV_VAR1": "'"${SECRET_VAR1}"'",
"ENV_VAR2": "'"${SECRET_VAR2}"'"
}'
echo $JSON_STRING >> src/service/config_vars.js
Implementation
In your Dockerfile, add a COPY layer to copy the get-env-vars.sh script to the /docker-entrypoint.d folder.
If you aren't familiar with the docker-entrypoint.d folder; basically, as the container starts up, it will run any .sh file that is located in this folder.
COPY ./get-config-vars.sh /docker-entrypoint.d
Then, in our main index.html file, add the following in the main <head> section to reference/call the script file created by the get-env-vars.sh script at startup:
<script src="/service/config_vars.js"></script>
At this point, we now have a "windows.config" JSON object variable ready for the getEnv() function to pull values from when called.
Wherever you need to be utilizing any of these variables, import the env.js file created earlier to import getEnv() function.
import getEnv from "../service/env.js"
Then simply use the function like you would a variable anywhere else. getEnv("VAR1")
Summary
As an overview here is the workflow the container executes when it is scheduled/started in your K8s environment
Container is scheduled and executes the get-env-vars.sh script, which creates the config_vars.js file
Application starts up. The index.html file executes the config_vars.js file, creating the window.configs JSON object variable
Where needed, the code imports the getEnv() function by importing the env.js file
Calling the getEnv(<variable_name>) function retrieves the value for the specified environment variable from the JSON object variable
When you need to add/update the key-value pairs in your K8s/OpenShift secret, you can delete/restart your POD, which will start the process over, loading in the updated information.
Hopefully this all makes sense.
As you can see in the screenshots, I am setting some user defined variables using 2 byte characters. I'm submitting the HTTP request to create this customer using UTF-8 encoding. The customer is being created with the correct double byte character characters because I can see them in the web app and in the DB. The problem is that I cannot see them in jmeter. It either shows little boxes or ??? question marks instead of the characters in the response data and in the debug sampler. The User defined variables is showing the characters correctly. I've added this to my user.properties file but that did not help:
sampleresult.default.encoding=UTF-8
How can I see these special characters in the response so I can Assert the record was created correctly? Any advice is appreciated. I am using jmeter 3.1 and JSON endpoints.
User Defined variables
DebugSampler
Now you need to ensure that JMeter itself is using UTF-8 encoding.
Configure Debug Sampler to show System Properties
Look for file.endoding property
If you see something different - override the existing property value using one of the following ways:
Permanent: add the next line to system.properties file (in JMeter's "bin" folder)
file.encoding=UTF-8
JMeter restart will be required to pick the property up
Temporary: set the "file.encoding" property via -D command-line argument as
jmeter -Dfile.encoding=UTF-8 -n -t ....
References:
Java - Supported Encodings
Apache JMeter Properties Customization Guide
I want to read a variable from CSV and use that value into another variable.
Example:
I have a variable as:
${url}: wwww.$(value_from_csv}.com
and secondary url ${url}/xyz
In my Jmeter script, ${value_from_csv} is not passed.
What I am missing?
Observed that CSV Dataset Config values are not passed (not available) to any of the Config Elements irrespective of the order of the components (Config Elements) in JMeter Test Plan (checked with User Defined Config & MongoDB Source Config), though passed to Samplers.
so, suggested the OP to define the value in jmeter.properties instead of a CSV file, so we can access user.host in MongoDB Source Config.
Steps:
Add user.host=address in jmeter.properties
Restart Jmeter
Add ${__P(user.host,)} in Server Address List field in MongoDB Source Config
Note: In case of running JMeter script from Jenkins, property will be picked by the script, from jmeter.properites file.
MongoDB Source Config is initialized before any JMeter Variables so the only way to make it dynamic is using JMeter Properties instead.
You can set a JMeter Property in 2 ways:
Define it in user.properties file like:
server.address.1=some.ip.or.hostname.1
server.address.2=some.ip.or.hostname.2
Pass the properties via -J command-line arguments like:
jmeter -Jserver.address.1=some.ip.or.hostname.1 -Jserver.address.2=some.ip.or.hostname.2 ....
See Apache JMeter Properties Customization Guide for more information on using JMeter Properties
We're trying to pull files and folders from the locker, but the command (/d2l/api/le/(D2LVERSION: version)/locker/myLocker/(string: path)) doesn't like spaces in the file or folder name. It returns either Bad Request or Invalid Token depending on how we attempt to handle the spaces on our end (i.e. string replace with %20).
How would we retrieve files/folders with spaces in the name?
I can think of some possible problems you're encountering.
When you provide the API path to your D2LUserContext object, you need to pass in only the API path, with internal spaces, not escaped characters. So, a proper route to a file named test file name might look like this:
/d2l/api/le/1.0/locker/myLocker/firstFolderBelowRoot/test file name
to create the authenticated URL for this, you'd invoke
yourD2LUserContext.createAuthenticatedUri('/d2l/api/le/1.0/locker/myLocker/firstFolderBelowRoot/test file name', 'GET')
That would fashion an authenticated URL you can use to fetch that file named test file name from your locker. To fetch its containing folder:
yourD2LUserContext.createAuthenticatedUri('/d2l/api/le/1.0/locker/myLocker/firstFolderBelowRoot/', 'GET')
Note that when you want to identify a folder in the locker, the path parameter must end with a trailing slash. (If you're trying to fetch a folder, and you don't have the trailing slash, that might be a source of your issue.)
Once you have that URL, you'll need to use some sort of HTTP library to actually make the call. Our internal PHP devs have recommended using HttpRequest rather than cURL with PHP. Most notably, the URL you should make the call with should preserve the space in the file or folder name in the path component of the URL.
When I test against a 9.4.1 instance using the Python client to do fetches/puts from the locker, or to generate URLs using the user context object and then feeding those URLs into a browser, things seem to work fine. Testing against a 10.0.0 test instance using the Python client also seems to be working.
Howto reference WSDL files from the registry when defining a new proxy service? I am using WSO2 ESB.
Q1: Can I use the localEntry element to define the WSDL in my proxy service? For example:
localEntry key="my_wsdl" src="file:/wsdl/MyServiceSOAP.wsdl"
Provided that I have previously used Management Console > Add Collection > create "wsdl", and Add Resource > MyServiceSOAP.wsdl.
I have a problem with the "src" value, both
"/wsdl/MyServiceSOAP.wsdl"
and
"wsdl/MyServiceSOAP.wsdl"
do not work. I follow the documentation but they do not show howto upload WSDLs into the registry.
Q2: What if MyServiceSOAP.wsdl imports MyService.wsdl? I need to use Add Resource for MyService.wsdl as well but do I need to do anything else to make the Proxy compile?
I think you are referring to the registry here. The Registry space in each product contains three major partitions.
Local
Configuration
Governance
The configuration registry contains product specific configuration that can be shared across multiple instances of the same product (a cluster of ESB nodes for example). So you can create the WSDL collection inside the Config registry and refer to it like..
"conf:/wsdl/MyServiceSOAP.wsdl"
By uploading the resources to Registry, you can pick them easily when creating the proxy service too.
I think you can refer to resources as "file:/wsdl/MyServiceSOAP.wsdl" only when they are inside a directory named 'wsdl' in the local file system.
BTW, about the error messages.. If you look at ESB server logs you'll see the following error when you try to update the proxy referring to a non existing file.
Caused by: java.io.FileNotFoundException: ./wsdl/MyServiceSOAP.wsdl (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at java.io.FileInputStream.<init>(FileInputStream.java:79)
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
at org.apache.synapse.config.SynapseConfigUtils.getObject(SynapseConfigUtils.java:197)
... 46 more
I found a simple solution for it from a blog:
In my Scenario I had a wsdl, that imported another wsdl that imported a xsd. The actual structures were in the second wsdl.
Import line in the original wsdl:
<wsdl:import namespace="http://www.somedomain.com/interface/v1_0" location="service_interface_1_0.wsdl"/>
Import line in the second wsdl:
<xsd:import namespace="http://www.somedomain.com/data/v1_0" schemaLocation="data_types_1_0.xsd"/>
Required xml on the proxy:
<publishWSDL key="file_required_service_1_0.wsdl">
<resource location="service_interface_1_0.wsdl"
key="file_service_interface_1_0.wsdl"/>
<resource location="data_types_1_0.xsd"
key="file_data_types_1_0.xsd"/>
Where I have local entries for "file_required_service_1_0.wsdl" etc named local entries that contain the original wsdl and xsd files.