You use flowFileIn to get some attributes but don't use it later and don't transfer it either. The former means you'll break the provenance chain and the latter means you'll get an error since flowFileIn exists in the session. For the former, I recommend passing it into session.create(flowFileIn), such that the child flow file will inherit from the parent (keeping the provenance chain). For the latter, since you are transferring the child flow file, you can remove the incoming flow file with session.remove(flowFileIn) at the end of the script. I am just eyeballing the code so if that doesn't fix the errors please let me know and I'll edit my answer after running with your script and looking more at it. ... View more

You don't need to specify that parameter, in curl the -o lets you pick the destination of the output. In InvokeHttp the response will be in the content of the outgoing flow file. If you want to put that content into a file, you can use PutFile after InvokeHttp. ... View more

I think you should be able to provide "Authorization" in Attributes to Send, and have an attribute "Authorization" with value "Bearer [OAUTH2_TOKEN]", with that value replaced with the token (you can use UpdateAttribute with Expression Language to set all that up). Then you should be able to use the URL that works with curl. If that doesn't work, try an attribute with any name (say, "auth") with value "Authorization: Bearer [OAUTH2_TOKEN]" and include "auth" in the Attributes to Send property. ... View more

I used Groovy's findAll method for filtering/iterating in my example, you'd just have to use the Javascript idiom, maybe something like: for(var pdMap in context.getProperties()) { if(pd.getKey().isDynamic()) { // This is a user-defined "dynamic" property, the ExecuteScript properties won't show up here } } Having said that, if you are only using Javascript in order to parse JSON, you can keep Groovy and use JsonSlurper and JsonOutput and other handy classes for manipulating JSON objects. ... View more

You might be able to use jvm-npm as a bridge to load that module, but see the documentation on the jvm-npm site for restrictions (such as needing to be a "pure" NPM module that does not depend on the Node.js API) ... View more

Did you get the client configs from Ambari, or just change your existing site files to use the public FQDN? If the latter, perhaps those ports are not exposed via the public FQDN, or perhaps are mapped to different ports for external access? ... View more

If you use Ambari to download the HDFS client configs, the site files you get should be correct for use in NiFi. I'm not sure where you got your site files, but they may have been server-side configs (to use private IPs/names) rather than client configs. ... View more