@Saraali  NiFi on contains components for reading XLXS files and converting them to CSV.  There are no native components included with NiFi that can convert the other direction. That being said, NiFi offers numerous processors that allow you to execute your own scripts or external commands against the content of a NiFi FlowFile. Here is an example where someone converted from CSV to Excel by passing the FlowFile content to an externally executed python script: https://stackoverflow.com/questions/68937735/how-to-convert-csv-to-excel-using-python-with-pandas-in-apache-nifi   If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@Eristocrat  @Eristocrat  Logging varies by class.  Some classes don't produce anything beyond INFO level, while others will produce even TRACE level logging.  With TRACE level being the highest level, you will get all possible logging by using it. Do you have a screenshot of the exception you are seeing?  At time of exception, did you find anything logged in the NiFi user and/or app logs? Thanks, Matt ... View more

@Eristocrat    The "nifi.web.https.host" value on each node should be set to the unique hostname assigned to each of your NiFi nodes.  Or are you saying that all the three instances of NiFi in your cluster are all installed on the same server/host?   You should not have all your NiFi cluster nodes trying to bind to the same host unless they are all installed on sam host which would be extremely unusual and not recommended. is useful when the client to NiFi presents a different hostname than what was specified in the browser URL. For example, you enter https://nifi-proxy:443/nifi and that directs to a proxy that then routes to one of the NiFi cluster host urls https://nifi-node1:443/nifi.  What happens here is NiFi receives a request for connecting to nifi-proxy, but nifi-node1 is not nifi-proxy so it fails.  That is because it looks like someone made a request to access server nifi-proxy, but that request landed on nifi-node1.  So adding nifi-proxy to the nifi.web.proxy.host list tells NiFi to accept request on nifi-node1 that were destined for nifi-proxy. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@IAJ    Specific to your case we see the following difference: Local Fingerprint (This is fingerprint of flow from node trying to join cluster): s.email.ConsumeIMAPNO_VALUEorg.apache.nifinifi-email-nar1.13.210 sec30 sec1 secWARNfalseTIMER_DRIVENPRIMARY0Mark Messages as Read=truefolder=Inboxhost=outlook.office365.commail.imap.socketFactory.clas Cluster Fingerprint (This is fingerprint of flow currently being used by the cluster): s.email.ConsumeIMAPNO_VALUEorg.apache.nifinifi-email-nar1.13.210 sec30 sec1 secWARNfalseTIMER_DRIVENALL0Mark Messages as Read=truefolder=Inboxhost=outlook.office365.commail.imap.socketFactory.clas If we look closely we see that you have a consumeIMAP processor in your cluster flow configured to execute on "ALL" nodes.  On the node trying to connect the same consumeIMAP processor is configured to execute on "Primary" node only.   A common scenario where this can happen is if the node was "Disconnected" from the cluster and a user edited the configuration of this processor at that time.  Now that node can not rejoin the cluster because of the mismatch.   As other have said the flow loaded from the flow.xml.gz in to NiFi JVM Heap memory must match across all nodes.  Since all nodes run the same flow.xml.gz, you can copy the this file form any node connected to the cluster to the node failing to connect. NOTE:  Understand that by this, you will lose those local changes made while that node was disconnected. Another scenario is the configuration change was made while both nodes were connected, which means that changed was replicated to all nodes in the cluster.  If in your 2 node cluster only one node responded to that replicated request that the change was made, the node(s) that did not would get disconnected.  Failure to respond to a replication request can happen most often because of server resource issues and/or network issues. Thank you, Matt ... View more

@TN08  The InvokeHTTP processor supports HTTP methods for connecting to a target server.  The InvokeHTTP processor does not establish a listener for inbound http connections. The properties for Basic Authentication Username and Password on this processor are used when the target endpoint supports basic auth and the username and password would need to provided by that target endpoint.  If basic auth is not supported by target endpoint, TLS is also supported. If you want to setup a listener in NiFi for inbound HTTP you would use either ListenHTTP processor or the newer HandleHttpRequest/HandleHttpResponse processors.   NiFi processors do not support basic auth for inbound connections.  So to connect with these processors the source systems would need to pass a client/user certificate in a mutual TLS handshake as a way to identify the client.  This means the processor would need to have a StandardRestrictedSSLContextService controller service that is configured with a keystore (containing a serverAuth certificate the client system can trust) and truststore (containing the complete trust chain for the clientAuth certificate presented by your client). If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@dontiffjr  The exception in your browser ERR_CERT_AUTHORITY_INVALID typically means that the trust chain for your NiFi's serverAuth certificate is not trusted by your browser.  You should see an option in the browser to "proceed to ...".  If you click on that, can you get to the NiFi UI? You can also use openssl command to inspect the server hello coming from your NiFi and obtain the public cert for your NiFi server's certificate.  You can load those public certificates into you browser trust. openssl s_client -connect <nifi-hostname>:<nifi-port> -showcerts Next thing to look at would be the contents of your certificate. <path to java>/bin/keytool -v -list -keystore <path to>/keystore.jks You'll want to make sure it contains: 1. A DN that does not contain wildcards 2. ExtendedKeyUsage (EKU) with both clientAuth and serverAuth 3. SubjectAlternativeName (SAN) with entry that matches the hostname of the server on which it is being used. 4. verify issue and expiration dates for certificate and that server clock and your local client machine where you are using browser has same date and time. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt   ... View more

@Griggsy  If you can share a source json, it may help with more specific guidance in the community. Thanks, Matt ... View more

@Neil_1992    The stack trace indicated your NiFi is running out of heap memory while loading your flow.xml.gz during startup? What version of NiFi are you using?  (Have you tried upgrading?) What version of Java is being used? (Have you tried upgrading?) Does your flow.xml.gz contain a lot of NiFi templates? Have you tried increasing the xms and xmx setting in the NiFi bootstrap.conf file? I suspect if you renamed your flow.xml.gz file that your NiFi would startup just fine.  Since i am guessing you do not want to lose your flow, I would increase the heap memory allocation for your NiFi.  Once up, I would look for way to reduce the heap usage of your dataflow(s) by removing old unused dataflows, and downloading templates so they are preserved outside of NiFi, and then delete templates inside of NiFi. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@Ilaya    This is not an issue with NiFi service itself.  Chrome for some reason does not like the new certificates being used. I would start by comparing your old certificate with the new and make sure things like ExtendedKeyUsage (EKU) (needs clientAuth and serverAuth) and SubjectAlternativeName (SAN) entries are compete and accurate.  Make sure that the complete authority trust chain for your new certificate is present in you browser. Perhaps this resource maybe helpful as well: https://thegeekpage.com/bad-ssl-client-auth-cert/   If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more