@Naveen_Sagar  I am not sure if this is the right solution, but if you are using NiFI itself to communicate with its own NiFi API,  you can skip the authorization token completely as NiFi is already authorized to execute its own API calls. ... View more

@alan18080   It seems this may be related to Process Group within a Process Group ( a known bug), but its hard to know based only on this error.   You may find more verbose information in the nifi log which will help better resolve.   Here is one solution for the same:   https://community.cloudera.com/t5/Support-Questions/quot-No-Flow-Exists-quot-When-Importing-Process-Groups-with/m-p/241006   ... View more

Excellent work here Oleksandr!!   ... View more

@dan_lucas  Not much to go on here, but it seems like you are having some issues resolving the networking for host/hostnames and ports.  Particularly:  myip3/<unresolved>:11443   You may want to work on providing true host names and ips and trying nifi again. ... View more

@bou7miiiz are you setting the mime type in the post HEADERS from nifi to the api? The 415 error seems to be expecting "application/json".   Add this property the same way you added Authorization. ... View more

@ehehtenandayo You should be looking at nifi's record based processors.   NiFi includes the following RecordReader and RecordWriter Processors: ConsumeKafkaRecord_0_10 1.2.0 ConvertRecord PublishKafkaRecord_0_10 PutDatabaseRecord QueryRecord SplitRecord   These processor use record reader and record writer, which can define or infer the schema of the json.   Then, you are able to write a SQL statement for the results you want.   Additionally this will help with taking those flowfiles of json and feeding them to a putHive processor. Here is an older post that will help with some of the fundamentals: https://community.cloudera.com/t5/Community-Articles/Using-HiveQL-Processors-in-Apache-NiFi-1-2/ta-p/246803         ... View more

@ZorteK This is certainly an interesting scenario.   First thing i would wonder is why there is 1 out 10000 that is different.  If that is not something you can remove, then you will not able able to apply the same schema to all parts.   Its possible this is a bug with the CHOICE, but im not sure or familiar with that.   Few solutions here:  1 check for and handle the exception in a separate flow branch able to parse that second schema.   Or you can run the entire flow where the GEO value is a full string.  Do not try to parse it down to finite schema within that string.   ... View more

@Alfies Thanks for posting.   I cant see anything that jumps as far as why this would not work in 1.21.   I would wonder if it works in 1.24.    If it does, then for sure that compatiblity was added since 1.21.   If you are required to use 1.21,  i would recommend opening a Jira to report the bug you are describing.  ... View more

Ofcourse we can help.  Just make a new post.  Try to include as much detail as possible, screenshots, how you have invokeHttp configured, errors, etc.   In your new post tag me using the @ with my username "steven-matison". ... View more