This is response of the Login request that i need to extract data from.
As you can see first line is not JSON format and Insomnia is complaining about it as "Invalid JSON: Unexpected token ) in JSON at position 0"
Is there any way to ignore/remove first line then extract data? May be custom query?
)]}',
{
"userid": "USER1",
"email": "user1#email.com",
"name": "John Jones"
}
If this is a one-off, just delete the first line with a text editor.
If it's happening systematically, then (a) you really ought to get it fixed at source rather than repairing it after the event, and (b) you need to know what the general pattern of bad data is, rather than working from one example.
Related
I am working on a Power Automate flow to get a JSON file from SharePoint and Parse it. On one of my previous questions I received a solution that worked with a testing JSON file. However when I ran a couple of tests with some JSON files that I need to use, the Parse JSON step gives out errors regarding "missing" required properties.
Basically, the JSON file's arrays do not always have exactly the same elements (properties). For example (below) the element "minimun_version" does not always appear under the element "link", like the image below
and because of this syntax I get the errors below
How can I Parse such a JSON file successfully?
Any idea or suggestion will help me get unstuck.
Thank you
You can allow null values in your Parse Json schema by simply adding that to the schema. April Dunnam has a nice article about this approach:
https://www.sharepointsiren.com/2018/10/flow-parse-json-null-error-fix/
I assume you have something like below in your schema?
"minimum_version": {
"type": "number"
}
You can change that to this to allow null values
"minimum_version": {
"type": [
"number",
"null"
]
}
I am trying to create multiple users using the AWS CLI. This is just an exercise in learning.
I get different errors depending on what changes I make. After a bit of searching, I changed the encoding and used file:// which elimated the Invalid JSON received errors.
I've tried this with a json file that is ASCII encoded and only one user.
aws iam create-user --cli-input-json file://aws-ec2.json --profile MyProf
I get:
Parameter validation failed: Invalid length for parameter Path, value:
0, valid range: 1-inf Invalid length for parameter
PermissionsBoundary, value: 0, valid range: 20-inf Invalid length for
parameter Tags[0].Key, value: 0, valid range: 1-inf
If I add another user, so change the UserName line to "MyEC2","SecondEC2", it just gives me Invalid JSON received.
Here's the JSON I am using:
{
"Path": "",
"UserName": "MyEC2",
"PermissionsBoundary": "",
"Tags": [
{
"Key": "",
"Value": ""
}
]
}
I know I'm doing something wrong, I just can't figure out what it is!
Thank you John. No one had anything to add. A friend of mine, networking person, suggested that I copy the command into Excel, concatenate the columns and then copy and paste the commands into the CLI.
I was hoping for a different response, but as I wrote in my question, this was just an exercise in learning. Your answer is an answer, and apparently a correct answer.
Thanks again for your time.
I have a JSON response from a REST API call. I am testing this in Postman, but the "Raw" View shows the value as a decimal while the "Pretty" view shows it as an integer. Why is this?
I am interested in {"number":100.0000} below.
Postman "Raw" View of REST Call response:
"units" {"number":100.0000,"numberUpdatedOn":"2018-11-21T00:00:00Z","priceUpdatedOn":"2018-11-21T00:00:00Z","price":{"currency":"GBP","amount":"1000.0000"}}
Postman "Pretty" View of REST Call response:
"units": {
"number": 100,
"numberUpdatedOn": "2018-11-21T00:00:00Z",
"priceUpdatedOn": "2018-11-21T00:00:00Z",
"price": {
"currency": "GBP",
"amount": "1000.0000"
}
I just find this really confusing and could not understand why I was get type convertion errors when feeding this "100" into an "int" type. No wonder, it seems it was always a decimal under the bonnet.
Pretty shows you your data in a human readable way. There are always choices the linter must make on how to show you the data. Apparently, it chooses to show you the most readable datatype possible and in the case of 100.0, this is 100 and you as human interpreted this as an integer. If this behavior frustrates you, try to make a habit to always debug with raw data, and use test data that is not "the easy way around". Numbers like 100 and 1000.0000 are convenient, but never realistic.
Type conversion is not only diffrence between pretty and row.
Pretty request's body cut off non-json data like notices.
i.e.
Pretty:
{
"error": "no-valid-data",
"message": "Invalid data"
}
Raw:
<br />
<b>Notice</b>: getimagesize(): Read error! in <b>XXX/zend-validator/src/File/ImageSize.php</b> on line <b>360</b><br />
{"error":"no-valid-data","message":"Invalid data"}
I would like to know if the following message is well parsed according to json format, I think it is but the application that needs to process it complains about it with the following error
[ERR]tx data JSON file error
The code in the file is this one
{"tx":
{
"moteeui":"fa789f0000000000",
"txmsgid":"000000000152",
"trycount":"5",
"txsynch" : "false",
"ackreq" : "true",
"userdata":
{
"port":"10",
"payload":"ABCABC"
}
}
}
Thanks in advance,
regards!
I have tried also the following snippet
[{
"mote": "202020",
"payload": "ABCB",
"port": 2,
"trycount": 5,
"txmsgid": ""
}]
I have validated with JSONLint and I get an error saying
[ERR]tx data JSON parsing error: 3 object item(s) left unpacked
Does it ring a bell?
Thanks again
Yes, it is correct.
For your info, JSONLint is a good site for checking the validity of JSON.
However, you may want to rethink setting numeric values as strings. ie, it is a better idea to say:
"trycount":5
rather than
"trycount":"5"
As the former indicates to whatever application is consuming the JSON that the value should be parsed as a number.
Similarly with the boolean values, it's better practise to use:
"txsynch" : false
rather than
"txsynch" : "false"
It won't cause an error in your JSON parser to pass these as strings, it is just better practise.
The error in the parser could be for many different reasons.
In JMeter, I need to extract some fields (City, Classification, and Chain) from a JSON response:
{
"StoreCode": "111243",
"StoreName": "Spencer - Sec 14 Gurgaon",
"Address1": "Gurgaon-Sector-14",
"Address2": "NCR",
"Pin": "110000",
"City": "NCR",
"Classification": "Vol 4",
"Chain": "Spencers",
"Version": "20281",
"VisitType": "Weekly"
}
Can it be done using the regular expression extractor? Is there another option?
If this piece of JSON is the all the response - it makes sense to use Regular Expression Extractor.
If you receive larger or more complicated structure - it's better to use special JSON Path Extractor available through plugin. JSON Path expressions for your JSON response would be something like $.City, $.Chain, etc.
See "Parsing JSON" chapter of Using the XPath Extractor in JMeter guide for more details on JSON Path language and on how to install the plugin.
Very easy with the plugin mentioned. See this for example. Here is link to plugin.
My biggest thing to understand was the flow. In your jmeter test you need to have an httprequest that returns data (in this case json data). So running your test you'd see json in the Response Data tab if you have a View Results Tree listener going. If you have this right click on the HttpRequest you want data from. ADD => Post Processors => jp#gc - JSON Path Extractor. Inside that extractor, you can name it anything you want.
The variable name should be one you already have defined in a User Defined Variables config element. The JSON Path would start with a dollar sign, then a dot, then the name of the key you want the value for from your json. So for me: $.logId the value from ... "logId": 4, ... in my json. It will store the number 4 in my userdefined variable. The default value can be set to something you'd never see like -1 or null or false etc...
BTW you reference your variable in your tests with ${variablename}. If putting into json and its a string do "${variablename}". Hope it helps.
Lots of the way to find out with the help of regular expression. Sharing one of them.
"City": "(.*)",
"Classification": "(.*)",
"Chain": "(.*)",