@Aiiyer  What ERROR?  All I see are a bunch of normal INFO log lines form the nifi-app.log snippet you shared. Please share the ERROR log line and stack trace if present.   Or share screenshots of what you are doing and observing. Thank you, Matt ... View more

@midee    You are using an InvokeHTTP processor to hit the rest-api endpoint of some authentication service to obtain a JWT Token, correct? The invokeHTTP processor gives you only two options for handling the response from the endpoint.  Placed it in the content of the FlowFile or in to an attribute of the FlowFile.  This means that any user who has been granted authorization to view the data of any component that this FlowFile will traverse can see the attributes and content of this FlowFile. There is no capability for the invokeHTTP to encrypt/mask the endpoint response in either options.  Even if there was, this now masked/encrypted data would no longer be usable by downstream components.  I suspect your plan is to then use this token to make additional requests to other endpoints later in your flow?  Also keep in mind that a token generally has a limited lifespan.  You should also have the ability to invalidate the token via another endpoint when you are done with it.    So your options here are: 1. Limit user's access so they can not view the data in the dataflows that utilize this token so that they can't see the token in the content or attributes.  If you are building the flow, then you know how to get the token so does not matter that you can see the token via the attributes or content. 2. Invalidate the token once done with it. Token can't be used anymore even if a user gained access to it later via looking at the content or attributes of a FlowFile.  So you may consider building yoru flow to get a token --> use that token for other actions --> invalidate token (Using NiFi login authentication as a JWT token example, you hit the logout endpoint to invalidate the token on the server side. This means the client token will no longer work even if you have it still).  Of course this means you flow needs to obtain a new token every time it runs.  Issue here is if your flow utilizes same token for multiple FlowFiles.  First FlowFile that hist logout will invalidate token other FlowFiles may try to still use.   Note that the default life of a token issued by NiFi is 12 hours.  After that the client token can't be used anymore and a new token would need to be obtained anyway (of course this age can be adjusted via the NiFi login provider configuration) If you found this answered your query, please take a moment to login and click "Accept" on the solutions that assisted you. Thank you, Matt ... View more

@chams221  NiFi's UI will not be available immediately after you start the service. The UI will not be available until the child process has finished loading. You can monitor teh progress by tailing the nfii-app.log.  Once you see the log line that states: 2021-07-13 19:46:43,855 INFO [main] org.apache.nifi.web.server.JettyServer NiFi has started. The UI is available at the following URLs: 2021-07-13 19:46:43,855 INFO [main] org.apache.nifi.web.server.JettyServer http://127.0.0.1:9090/nifi 2021-07-13 19:46:43,858 INFO [main] org.apache.nifi.BootstrapListener Successfully initiated communication with Bootstrap 2021-07-13 19:46:43,858 INFO [main] org.apache.nifi.NiFi Controller initialization took 44494103250 nanoseconds (44 seconds). then you should be able to access the NiFi UI provided you can reach that address from your client browser. Thank you, Matt ... View more

@Ash1  Not clear from yoru query how files are getting into or out of your NiFi. Assuming you have already received a set fo FlowFiles for the day in to your NiFi dataflow, the best approach may be to notify if any fails to be written out /transferred at the end of your dataflow.  In this manor not only would you know that not all Files transferred, but would know exact what file failed to transfer. There are numerous processors that handle writing out FlowFile content (transfer) to another source or local file system.  Those processing components typically have relationships for handling various types of failures.  These relationships could be sent through a retry loop via the RetryFlowFile [1] processor back to the same transfer processor that failed.  You define in the RetryFlowFile processor how many times you want a FlowFile to traverse this loop.  After X number of loop it would get routed out of the loop to your PutEmail [2] processor where you could dynamically set the email content to include attributes from that FlowFile like filename, hostname of NiFi that failed to transfer it, etc... From the PutEmail processor you could send that FlowFile to somewhere else for holding until manual intervention was taken in response to that email. [`1] https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.13.2/org.apache.nifi.processors.standard.RetryFlowFile/index.html [2] https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.13.2/org.apache.nifi.processors.standard.PutEmail/index.html   If you found any of the response given here assisted with your query, please take a moment to login and click "Accept" on each of those solutions. Thank you, Matt ... View more

@Indhu  The more detail you provide the better community members can assist with your query. Can you share an example input and the desired output date string? What format is your source date in? How are you ingesting that data in to NiFi? Thank you, Matt ... View more