I have a JSON object as payload, which contains a dot (".") in one of the identifier names and I want to map this object to another JSON object using the datamapper mediator.
The problem I am facing is that the JSON evaluation uses the dot notation for nested elements. The field "example":
{ "a": { "b": "example"} }
is evaluated by asking for a.b
My object however looks like:
{ "a": { "b.c": "example"} }
I cannot evaluate a.b.c, because it thinks b and c are two seperate nested elements.
Escaping this identifier name in the datamapper.dmc javascript code does not seem to work. No matter what I try ('', "", [''], [""]) I get the error:
Error while reading input stream. Script engine unable to execute the script javax.script.ScriptException: <eval>:8:43 Expected ident but found [
This may not be exact solution as I did not specifically tried it for Data Mapper, but I had similar problem in WSO2 Property Mediator while parsing incoming JSON to get a value and set it to property. I was able to parse such JSON using following syntax
json-eval($.A.['b.c'])
Where 'A' is JSON object containing 'b.c' JSON element.
I saw you mentioned that you already tried something similar, but just wanted to give my working example in case it helps.
Related
There are many articles about BizTalk JSON encoder...
I am trying to produce JSON for 3rd party software wanting root level array, like so:
[
{
"property" : "value"
},
{
"property" : "value"
}
]
I am trying to control the output using schema, but I am not able to specify minOccurs and maxOccurs on the root node. I have also tried "Group Max/Min Occurs", with no difference.
Is it not possible to do this?
What about the old newtonsoft hack for adding Array attribute to the output XML? (I have tried this as well, but failed...)
This is similar to BizTalk 2013 - decode JSON array
As per the answers on the other question, you can't have an array at the root node of an XML schema. That one is for receiving a JSON payload with an array at the root, rather then sending one. But your options are similar, you would need to either have a custom pipeline component after the JSON encoder that removes the root or a custom pipeline component that produces the JSON the way you want.
I'm using a Microsoft REST API to query a Azure application, oauth and request goes without problem.
The response from InvokeHTTP has this format
{"#odata.context":"https://****.dynamics.com/api/data/v9.1/$metadata#endpoint","value":[ here comes the actual JSON result in format {
"#odata_etag" : "W/\"555598\"", "field":"value...},...]
,"#odata.nextLink":"https://****.dynamics.com/api/data/v9.1/endpoint?$skiptoken.....}
I need to extract the nextLink for pagination and Value to continue the flow and store the result.
When I try to parse with inferAvroSchema so I can start working with it throws this error "Illegal initial character: #odata.etag"
My Idea was to inferAvroSchema, then EvaluateJsonPath to extract the odata tags and then extract the values.
I tried using EvaluateJsonPath on the result asking to create an attribute for $.#odata.context but it doesn't find the item either, I'm sure is something about the #.
I can also replace all the # of the incoming flow for another char, but don't know if that makes sense.
I'm feeling that i'm not using a correct approach, but NIFI + odata doesn't give me results on google or here.
I'm open to any suggestions!
thank you!
Schema fields cannot contain #. You could replace the #, however you must be sure not to replace it in actual content like email addresses. Another solution is to transform the API response using JoltTransformJSON processor, such that your flow can work with it:
GenerateFlowFile:
For the JoltTransformJSON processor provide following Jolt specification:
[
{
"operation": "shift",
"spec": {
"\\#odata.nextLink": "next"
}
}
]
Leave the default values for the other properties. You can play around with Jolt here: http://jolt-demo.appspot.com/
EvaluateJsonPath:
Result:
Notice that the url is now part of the flowfile attributes.
Your hunch is correct, you can only have valid characters for the field names on the schema type you are using, avro or JSON.
You could get NiFi to remove illegal characters with the replacetext proceasor, have a read here on what is valid: http://avro.apache.org/docs/current/spec.html#names
The json data structure for jstree is define in https://github.com/vakata/jstree, here is an example
[ { "text" : "Root node", "children" : [ "Child node 1", "Child node 2" ] } ]
Notably it says
The children key can be used to add children to the branch, it should
be an array
However later on in section Populating the tree using AJAX and lazy loading nodes it shows to use set children to false to indicate when a child has not be processed
[{
"id":1,"text":"Root node","children":[
{"id":2,"text":"Child node 1","children":true},
{"id":3,"text":"Child node 2"}
]
}]
So here we see children used as both as an array and as a boolean
I am using jstree as an example because this is where I encountered the issue, but my question is really a general json question. My question is this, is it valid JSON for the same element in json to be two different types (an array and a boolean)
Structure wise, both are valid JSON packets. This is okay, as JSON is somewhat less stricter than XML(with a XSD or a DTD). As per: https://www.w3schools.com/js/js_json_objects.asp,
JSON objects are surrounded by curly braces {}.
JSON objects are written in key/value pairs.
Keys must be strings, and values must be a valid JSON data type (string, number, object, array, boolean or null).
Keys and values are separated by a colon.
Each key/value pair is separated by a comma.
Having said that, if the sender is allowed to send such JSONs, only caveat is that server side will have to handle this discrepancy upon receiving such different packets. This is a bad-looking-contract, and hence server might need to do extra work to manage it. Server side handling of such incoming JSON packets can become tricky.
See: How do I create JSON data structure when element can be different types in for use by
You could validate whether a JSON is okay or not at https://jsonlint.com/
See more about JSON in this answer: https://stackoverflow.com/a/4862511/945214
It is valid Json. JSON RFC 8259 defines a general syntax but it contains nothing that would allow a tool to identify that two equally named entries are meant to describe the same conceptual thing.
The need to have a criteria to check two JSON structures for instance equality has been one motivation to create something like Json Schema.
I also think it is not too unusual for javascript to provide this kind of mixed data. Sometimes it might help to explicitly convert the javascript object to JSON. Like in JSON.stringify(testObject)
A thing for json validation
https://www.npmjs.com/package/json-validation
https://davidwalsh.name/json-validation.
This question already has answers here:
Is this simple string considered valid JSON?
(5 answers)
Closed 5 years ago.
Is a plain string valid JSON or does there have to be an object?
For example:
"morpheus"
versus:
{
"name": "morpheus"
}
It is valid in Javascript.
You might get confused at first trying to test this:
JSON.parse("bob");
This would fail with the error: "Unexpected token b". However, that's the equivalent of passing just plain bob as the text in the response, not "bob". If you add the quotes:
JSON.parse('"bob"')
You get the simple string "bob" back as you should.
Important
This answer once said No, the first character of the JSON must be a { or a [.
At the time I wrote that, I was testing it with Python. In Python (2.7.x at least), json.loads("a") gives an error, which means that a plain string is not valid JSON there.
It has been rightfully pointed out by others that it cannot be said that a plain string is not valid JSON. See this question for a more appropriate answer.
At this time all I can say is that it depends on your environment. In javascript it may be valid, in python it may not be, etc, etc.
JSON stands for JavaScript Object Notation
Here is a quote from the official site
JSON is built on two structures:
A collection of name/value pairs. In various languages, this is
realized as an object, record, struct, dictionary, hash table, keyed
list, or associative array. An ordered list of values. In most
languages, this is realized as an array, vector, list, or sequence.
These are universal data structures. Virtually all modern programming
languages support them in one form or another. It makes sense that a
data format that is interchangeable with programming languages also be
based on these structures.
In JSON, they take on these forms:
An object is an unordered set of name/value pairs. An object begins
with { (left brace) and ends with } (right brace). Each name is
followed by : (colon) and the name/value pairs are separated by ,
(comma).
Take note of the text I bolded.
Because of that, and JSON being JS Object Notation, it is implied that a JSON representation of a name:value pair must always be in the form of
{
"name": "value"
}
Note that you can also make the 'root object' a list
[
{
"name1": "value1"
},
{
"name2": "value2"
}
]
This basically means that the JSON contains more than one object.
As Sunny R Gupta pointed out, this is also valid JSON
[
"this",
"is",
"valid"
]
Note that this works because the strings are not in the form "name":"value" but just strings. Taking that into consideration valid options for your example would be
{
"name": "Morpheus"
}
or
[
"morpheus"
]
The first character of the JSON must be a { or a [
UPDATE: 2018:
It has been 4 years since I originally answered this question. Back then plain strings in quotes were not valid JSON. As of today, it is being accepted as a valid JSON.
The following is kept for people to see what the error used to be earlier:
Parsing a simple string gives:
Parse error on line 1:
"morpheus"
^
Expecting '{', '['
indicating that it needs to be an object or an array.
TIP: To validate JSON strings and see what works and what does not, try using http://jsonlint.com
This could be the most basic json question ever. I'm creating a WCF REST service and have a HelloWorld test function that just returns a string. I'm testing the service in fiddler and the reponse body I'm getting back is:
"HelloWorld"
I also created a function that would just return a number (double) and the response body is:
1.0
Are those valid json responses? Are simple return types just returned in plain text like that (no markup with the brackets)?
Valid JSON responses start with either a { for an object or [ for a list of objects.
Native types are not valid JSON if not encapsulated. Try JSONlint to check validity.
RFC 4672, says no. Which doesn't mean it can't work, but it isn't strictly standards compliant. (Of course, neither are all the JSON readers...)
To quote from Section 2, "JSON Grammar":
A JSON text is a sequence of tokens. The set of tokens includes six
structural characters, strings, numbers, and three literal names.
A JSON text is a serialized object or array.
JSON-text = object / array
Only objects / maps, and arrays, at the top level.
According to the official website, you need to use a syntax like this:
You need to declare what you want beetween {}, like this:
{
"test": "HelloWorld"
}
No. The following is, for example:
{
"Foo": "HelloWorld"
}
You can try JSONLint to see what validates and what does not.