@naga_satish If you NiFi is running secured (HTTPS), then every action must be authenticated and authorized and this includes calls made to the NiFi rest API. NiFi by default will always support a client/user certificate for authentication as the first attempted method of authentication. Using a valid client/user certificate is the most common method used when interacting with NiFi via the rest-api because it does not require the client to acquire a bearer token like other methods such as the ldap-provider. Also Bearer tokens are only valid on the node from which it was acquired (Can't use token issued by node 1 on node 2, 3, 4, etc...). The best way to to see how these commands are executed is using the developer tools in your browser while executing the actions via the NiFI Ui directly. You can even copy the curl command from the developer tools. For example, in Chrome browser click on the settings --> more tools --> Developer tools From UI that opens click the "Network" tab. Now you can see the calls being made as you perform them via the UI and can right click on any call and select copy as curl. Now if you still want to use Tokens, here is one example based off using a login provider: To get a token for a user: curl 'https://<nifi-hostname>:<nifi-port>/nifi-api/access/token' --data-raw 'username=<username>&password=<password>' --compressed --insecure The return from the above is your bearer token for the user. This bearer token is only valid for the duration of the configured expiration in the login-identity-providers.xml file. The following command then can be used to fetch the current state on a processor (<TOKEN> is the string returned from above): curl 'https://<nifi-hostname>:<nifi-port>/nifi-api/processors/<processor-UUID>/state' -H 'Authorization: Bearer <TOKEN>' --compressed --insecure The following command then can be used to clear the state on a processor: curl 'https://<nifi-hostname>:<nifi-port>/nifi-api/processors/<processor-UUID>/state/clear-requests' -X 'POST' -H 'Authorization: Bearer <TOKEN>' --compressed --insecure Since you setup may be totally different in how it is setup to authenticate your users, it is best to use the browser's developer tools to to see the rest-api action in progress to understand the interactions. Hope this helps, Matt
... View more
The problem is that you need something to store the dynamic schemas in. That is where the Schema Registry comes in as it provides a UI and api to add/update/delete schemas. These can then be refrenced from NiFi. It looks like AvroSchemaRegistry allows you to do the similar, minus the ui/api. So you would need to create your schema in your flow, as attribute, and send that to AvroRecorderReader configured against AvroSchemaRegistry. You could use some other data store to store these schemas, but you would need to pull them out into an attribute of the same name configured in the Reader and Registry. https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-registry-nar/1.12.1/org.apache.nifi.schemaregistry.services.AvroSchemaRegistry/index.html The latter method does not give you a way to manage all the schemas, which is why I reference the Hortonworks Schema Registry which does include ability to manage, version actual schemas.
... View more