Indranil Roy, For Apache NiFi 1.0.0 the REST API was completely refactored to promote multi-tenancy. Specifically, the endpoints have been reorganized to align with the resources being authorized and component specific revisions have been introduced. I would highly recommend using the Developer Tools in your browser to see the APIs in action. Here is an example curl commend for starting a processor. curl 'http://localhost:8080/nifi-api/processors/2a817541-0158-1000-771e-93ca6d670429' -X PUT -H 'Content-Type: application/json' -H 'Accept: application/json, text/javascript, */*; q=0.01' --data-binary '{"revision":{"clientId":"2a81087c-0158-1000-1362-5452a699615c","version":3},"component":{"id":"2a817541-0158-1000-771e-93ca6d670429","state":"RUNNING"}}' In order to get the revision details for this component it would be available in the flow returned for a given process group. Here's an example of that curl commend. curl 'http://localhost:8080/nifi-api/flow/process-groups/<process-group-id>' ... View more

What browser are you using? Is the browser you're using also on the Windows Server? In your browser, are you able to open up the Developer Tools and look at the network traffic? It would help to narrow down where the 'slowless' is being introduced. It could be due to client side (browser) performance specifically if your flow has many components. It could be introduced simply by network latency. It could also be introduced server side while NiFi is handling the request and generating a response (particularly if clustered). ... View more

James, Sorry for the delay response here. The issue your describing was a bug and it has been addressed in the upcoming NiFi 0.7.0 release. Here's the JIRA in question [1]. Sorry for the inconvenience. Matt [1] https://issues.apache.org/jira/browse/NIFI-1564 ... View more

The bulletins are available through the Rest Api. They are accessed primarily through two different endpoints. /controller/status Return controller level status. This will include status and bulletins for cluster/node issues, reporting tasks, and controller services. /controller/process-groups/{id}/status Return process group specific status. This will include status and bulletins for all components in the specified process group. This endpoint supports a recursive flag to indicate whether status for all descendent components is included. ... View more

Requests to NiFi's REST API to change the data flow (mutable requests) require a revision to be included. Since multiple users may be working with the same NiFi instance at the same time, this is used as a simple check to verify the user who submitted the request acknowledges they have the most current version of the data flow before applying their change. The revision is comprised of two pieces. The first is the version. The version is a one-up number that is updated by NiFi during a mutable request and is included in the response. The next mutable request should include that updated version. This works well until a user wants to submit multiple requests concurrently. To support this case the revision also includes a clientId. If the clientId in the revision of the current request matches the clientId of the last successful mutable request, the version does not need to match. It is up to the client to manage the revision version and check with http://{host}:{port}/nifi-api/controller/revision in order to see if another client has updated the flow. The clientId can be any string. It's accepted in most endpoints so it could be added to requests in $.ajaxSetup for instance. If the clientId is not specified one will be generated. There is no session, it's simply generates a UUID. You could use any string you may want to represent your client. In the NiFi UI, we GET the flow http://{host}:{port}/nifi-api/controller/process-groups/root?verbose=true and use the clientId that it generates for all subsequent requests. ... View more