JMeter: Body & File content - jmeter

The WebAPI request has a POST method which expects Content body. I've tried to use both Parameters and Body options but I receive error responses - 'Invalid Request' with 400 Status code, etc.
JMeter request Sample Content Body:
{
"ParamA": 111,
"ParamB": "Char String",
"ParamC": "VarType"
}
OR
{ "ParamA": 111, "ParamB": "Char String", "ParamC": "VarType"}
Listener Request:
POST data:
--8vpH3B6WcV4f1La46_wccVi4c25lrLJaGcN--
Listener Response:
{"message":"The request is invalid.","modelState":{"value":["An error
has occurred."]}}
Any insight into viable options? Eventually, I'm planning on reading the Body string from a .csv file so I can parameterize the request. Reading from a .CSV file only reads the first line of the request body - for example: '{'
Any help would be greatly appreciated.
Best,
Ray
HTTP Request
Request

Uncheck in HTTP request the option:
Use multipart/form data for POST
Also check your CSV does not contain some data that contains the CSV separator which is '\t' by default.
Ensure it doesn't by changing separator to '|' for example if you're sure your JSON will never contain it.

Related

Nifi InvokeHTTP processor not triggering response relationship

Consider the following flow which authenticates via HTTP to a service. I'm seeing an HTTP status code of 201 (created) come back, which should trigger the response relationship/flow. However as you can see in the log below, only the original relationship is triggered.
The Flow
Green lines indicate "response" flow. Magenta indicates "original" flow.
POST /token properties
Log
You can see here that the original relationship is triggered, but the response is not -- even though the status code, 201, is in the "success" range.
2023-01-29 15:22:08,341 INFO [Timer-Driven Process Thread-7] o.a.n.processors.standard.LogAttribute LogAttribute[id=fe0ace38-0185-1000-376d-8737d0e020f8] logging for flow file StandardFlowFileRecord[uuid=6b9f010a-f287-449c-8bef-94840c5cfa2f,claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=1674862641879-1, container=default, section=1], offset=13494, length=107],offset=0,name=6b9f010a-f287-449c-8bef-94840c5cfa2f,size=107]
---------------------ORIGINAL---------------------
FlowFile Properties
Key: 'entryDate'
Value: 'Sun Jan 29 15:22:07 UTC 2023'
Key: 'lineageStartDate'
Value: 'Sun Jan 29 15:22:07 UTC 2023'
Key: 'fileSize'
Value: '107'
FlowFile Attribute Map Content
Key: 'filename'
Value: '6b9f010a-f287-449c-8bef-94840c5cfa2f'
Key: 'invokehttp.request.duration'
Value: '738'
Key: 'invokehttp.request.url'
Value: '...'
Key: 'invokehttp.response.url'
Value: '...'
Key: 'invokehttp.status.code'
Value: '201'
Key: 'invokehttp.status.message'
Value: ''
Key: 'invokehttp.tx.id'
Value: 'efca13ac-16a1-4a27-a8e1-d04110d48523'
Key: 'mime.type'
Value: 'application/json'
Key: 'path'
Value: './'
Key: 'responseBody'
Value: '...'
Key: 'uuid'
Value: '6b9f010a-f287-449c-8bef-94840c5cfa2f'
---------------------ORIGINAL---------------------
The only thing I though of which might be causing an issue is that I'm writing the response body to an attribute. I tried to test by setting this attribute name to empty string but that just gives me an error in the log. I assumed that without the attribute name set, the response body would be the FlowFile sent to the response relationship, but that doesn't seem to be working.
Update: I created a second InvokeHTTP processor and replaced the relationships / disabled the old one. The flow worked correctly until I set the Response Body Attribute Name, and then the response relationship stopped triggering. I need to set this attribute though, so I can extract the error message from the response in the case of failure. I think I'll have to enable the Response Generation Required option, and check the status code in the response relationship flow. This is not ideal, though.
When you use Response Body Attribute Name, only original route is triggered. It's InvokeHTTP's behaviour, you can check documentation.
FlowFile attribute name used to write an HTTP response body for FlowFiles transferred to the Original relationship.
You can use this way for your problem,
InvokeHTTP (original route)-> RouteOnAttribute - (Success - ${invokehttp.status.code.ge(200):and(${invokehttp.status.code.le(299)})})
When you set Response Body Attribute Name attribute, it means that you don't want new flowfile, you want just add a new attribute to existing flowfile.

Google Cloud DLP - CSV inspection

I'm trying to inspect a CSV file and there are no findings being returned (I'm using the EMAIL_ADDRESS info type and the addresses I'm using are coming up with positive hits here: https://cloud.google.com/dlp/demo/#!/). I'm sending the CSV file into inspect_content with a byte_item as follows:
byte_item: {
type: :CSV,
data: File.open('/xxxxx/dlptest.csv', 'r').read
}
In looking at the supported file types, it looks like CSV/TSV files are inspected via Structured Parsing.
For CSV/TSV does that mean one can't just sent in the file, and needs to use the table attribute instead of byte_item as per https://cloud.google.com/dlp/docs/inspecting-structured-text?
What about for XSLX files for example? They're an unspecified file type so I tried with a configuration like so, but it still returned no findings:
byte_item: {
type: :BYTES_TYPE_UNSPECIFIED,
data: File.open('/xxxxx/dlptest.xlsx', 'rb').read
}
I'm able to do inspection and redaction with images and text fine, but having a bit of a problem with other file types. Any ideas/suggestions welcome! Thanks!
Edit: The contents of the CSV in question:
$ cat ~/Downloads/dlptest.csv
dylans#gmail.com,anotehu,steve#example.com
blah blah,anoteuh,
aonteuh,
$ file ~/Downloads/dlptest.csv
~/Downloads/dlptest.csv: ASCII text, with CRLF line terminators
The full request:
parent = "projects/xxxxxxxx/global"
inspect_config = {
info_types: [{name: "EMAIL_ADDRESS"}],
min_likelihood: :POSSIBLE,
limits: { max_findings_per_request: 0 },
include_quote: true
}
request = {
parent: parent,
inspect_config: inspect_config,
item: {
byte_item: {
type: :CSV,
data: File.open('/xxxxx/dlptest.csv', 'r').read
}
}
}
dlp = Google::Cloud::Dlp.dlp_service
response = dlp.inspect_content(request)
The CSV file I was testing with was something I created using Google Sheets and exported as a CSV, however, the file showed locally as a "text/plain; charset=us-ascii". I downloaded a CSV off the internet and it had a mime of "text/csv; charset=utf-8". This is the one that worked. So it looks like my issue was specifically due the file being an incorrect mime type.
xlsx is not yet supported. Coming soon. (Maybe that part of the question should be split out from the CSV debugging issue.)

Not able to extract value from the response and use it in next request using JSON extractor

Here is the reponse and i want to extract the id from it
{"status":"success","data":{"name":"chirag","salary":"1000","age":"30","id":82}}
this is how i am trying to extract:
then use it in the next request like this:
Update:
When i use this in this in the next request - api/v1/delete/${id}, I get this error:
Thread Name:Delete Employee 5-1
Sample Start:2020-07-19 11:27:54 WEST
Load time:0
Connect Time:0
Latency:0
Size in bytes:1115
Sent bytes:0
Headers size in bytes:0
Body size in bytes:1115
Sample Count:1
Error Count:1
Data type ("text"|"bin"|""):text
Response code:Non HTTP response code: java.net.URISyntaxException
Response message:Non HTTP response message: Illegal character in path at index 47: http://dummy.restapiexample.com/api/v1/delete/${id}
To Extract... modify the "json path expression" as:
$.data.id OR $..id
Then in subsequent request, correct the path:
/api/v1/update/${id}

illegal characters at line 1 and col 1 in xml response in jmeter

I am trying to validate the xml response from an REST API using JMETER. I am using xml schema assertion to validate the response using xsd.
I am getting the following error on XML Schema Assertion
Assertion error: true
Assertion failure: false
Assertion failure message: fatal: line=1 col=1 Content is not allowed in prolog.
When i see the response that i have received i see there are some illegal characters that is added at the beginning of the response xml.
enter image description here
I have tried to modify jmeter.properties file and changed the following values
jmeter.save.saveservice.output_format=xml
jmeter.save.saveservice.data_type=true
jmeter.save.saveservice.label=true
jmeter.save.saveservice.response_code=true
jmeter.save.saveservice.successful=true
jmeter.save.saveservice.thread_name=true
Please help me in understanding how to remove the illegal characters in the response and allow the xsd validation to pass through.
These characters indicate Byte Order Mark so you can use BOMInputStream from the JSR223 PostProcessor in order to remove them from the response and replace the response data with "sanitized" XML.
Add JSR223 PostProcessor as a child of the HTTP Request sampler where you want to remove this BOM
Put the following code into "Script" area:
def is = new ByteArrayInputStream(prev.getResponseData())
def bOMInputStream = new org.apache.commons.io.input.BOMInputStream(is)
def bom = bOMInputStream.getBOM()
def charsetName = bom == null ? 'UTF-8' : bom.getCharsetName()
def reader = new InputStreamReader(new BufferedInputStream(bOMInputStream), charsetName)
prev.setResponseData(org.apache.commons.io.IOUtils.toByteArray(reader, 'UTF-8'))
That's it, your assertion shouldn't be failing anymore.
More information on Groovy scripting in JMeter: Apache Groovy - Why and How You Should Use It

Getting Illegal character in path at index 53 in POST Request

I am trying to POST HTTP request and request is not going thru. what am I doing wrong or missing?
I think it does not like this part
colonoscopy.jpg/1-1?
Server name: ${hostName}
Path: ${virtualDirectory}/data/media/${location}/colonoscopy.jpg/1-1?&prodName=${prodName}&otherParams=&sid=${authToken}
HTTP Header Manager
Content-Type application/x-www-form-urlencoded
Getting
Thread Name: Thread Group 1-1
Sample Start: 2019-02-01 15:39:06 PST
Load time: 0
Connect Time: 0
Latency: 0
Size in bytes: 1681
Sent bytes:0
Headers size in bytes: 0
Body size in bytes: 1681
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code: Non HTTP response code: java.net.URISyntaxException
Response message: Non HTTP response message: Illegal character in path at index 53: http://10.188.169.185/api/v2/data/media/dc2e83cfe2054
Server:%20Microsoft-IIS/10.0
Set-Cookie:%20ASP.NET_SessionId=5cwq0inclxwvmd0qlnd01yo3;%20path=/;%20HttpOnly
X-AspNet-Version:%204.0.30319
X-Powered-By:%20ASP.NET
Access-Control-Allow-Origin:%20*
Access-Control-Allow-Headers:%20Content-Type,Authorization
Access-Control-Expose-Headers:%20Content-Location,%20Location
Access-Control-Allow-Methods:%20GET,%20POST,%20OPTIONS,%20DELETE
Date:%20Fri,%2001%20Feb%202019%2023:39:05%20GMT
Content-Length:%200
colonoscopy.jpg/1-1?&prodName=test&otherParams=&sid=ca1bc7a576a44d9b8270b7cac2dddab8
HTTPSampleResult fields:
ContentType:
DataEncoding: null
Inspect your URL along with the query string using View Results Tree listener, the error can have only one reason: you're sending a character which requires URL encoding as it is.
The reasons are in:
One of your variables (${location}, ${prodName} or ${authToken}) has the character which requires the URL encoding. If this is the case - you will need to wrap it into __urlencode() function
One of your Variables (${location}, ${prodName} or ${authToken}) is not getting resolved into the value and curly braces characters ({ and }) are not allowed in the URL string without encoding. Use Debug Sampler to make sure that :
all the variables have their values
all the characters which require the encoding are encoded using the __urlencode() function

Resources