Hello @okanergun,  According to https://issues.apache.org/jira/browse/NIFI-8630 the PutEmail processor was updated as mentioned here:  "Upgraded javax.mail 1.4.7 to jakarta.mail 2.0.1 for PutEmail" That was on 1.14.0, so in your case, you were using the old javax.mail and not the new jakarta.mail.  There is a difference on the environment to take in consideration.  The log you shared shows this:  Couldn't connect to host, port: smtp.office365.com, 587; timeout -1 This means you do not have a socket timeout defines, which could case the processor to hang and report those timeouts when OS tells so.  You can try to add these setting:  -Dmail.smtp.connectiontimeout=30000 -Dmail.smtp.timeout=30000 -Dmail.smtp.writetimeout=30000 https://eclipse-ee4j.github.io/angus-mail/docs/api/org.eclipse.angus.mail/org/eclipse/angus/mail/smtp/package-summary.html  Also, make sure you have "Concurrent Tasks" under the PutEmail processor set to 1.  This kind of SMTP for Microsoft may block parallel connections.  ... View more

Hello ,  That error is not normal, and the mount should exist.  So this points to be some external issues that may be identified by Cloudera Support on case.  What risks you may face, the first is considering that deployments are handled by Cloudera, so in future updates of it may get overwritten.  Your steps are fine, should work, but still a support case would be a safer option.  If you still want to proceed, do that, rollout the pods and then check status:  kubectl exec -it deploy/api -- ls -lah /projects kubectl exec -it deploy/api -- touch /projects/test.txt ... View more

Hello @Sid17,  This looks very similar to what we see here:  https://community.cloudera.com/t5/Support-Questions/Jolt-spec-to-flatten-the-nested-JSON/m-p/399054#M250380  Can you take a look on that and see if it helps?  ... View more

Hello @hckorkmaz01,  I was testing one way that in CFM didn't worked, but in your case, in NiFi directly, it may work, you can test.  Under NiFi settings, create a reporting task like this:  You will need to use this QueryNiFiReportingTask.  This query should work for what you need:  SELECT QUEUE_ID, QUEUE_NAME, FLOWFILE_COUNT, CONTENT_SIZE FROM FLOWFILE_QUEUE_STATS Then save the output to either log or any other method you prefer.    Another option I was thinking is to use InvokeHTTP processor.  To get the information you need.  That will be in NiFi but using the REST API:  GET http://localhost:8080/nifi-api/flow/process-groups/<PG_ID>/connections That could be an option for you.  Maybe test this and let us know if that worked.  ... View more

Hello @aaaver,  Just wanted to see if you can share little bit more details, for example, the NiFi version and if your using the CFM provided by Cloudera.  Have you followed these steps from the documentation?  https://docs.cloudera.com/cfm-operator/2.11.0/configure-nifi-cr/topics/cfm-op-configure-nifi-cr-oidc-auth.html ... View more

Hello @Hasib1971,  Are you still facing an issue or that was what solved your error?  If you still have an issue, please open a new thread so we can help you there.  ... View more

Hello @IgorSpryzhkov,  Let me see if I can help with your questions:  1. How to get list of Process Groups in the root and in Each PG? For this, you may be able to get the information with this API:  GET /process-groups/{id}/process-groups https://nifi.apache.org/docs/nifi-docs/rest-api/index.html    2. How to get list of Processors in Each PG?   For this one, this other API request may get you the info:  GET /process-groups/{id}/processors   3. How to organize in Groovy cycles for scan PGs? In NiFi ExecuteScript (Groovy), you can call the API recursively.  So you should be able order the logic there to fit what you need.    4. How to save / read data in/from Groovy dictionary /  NiFi cache? You can use any of these options: - DistributedMapCache (preferred if cluster, can use processors such as PutDistributedMapCache and FetchDistributedMapCache). - File-based persistence (write JSON file to disk). - FlowFile attributes (if just passing data). ... View more

Hello @FGhidotti,  You should be able to update it under the Cloudera SSO.  That is accesible from any Cloudera page, under your user icon.  If that does not work, you may need to open an administrative case to get the user updated.  ... View more

Hello @HoangNguyen,  The difference I see is that your queries does not match.  During all the queries I see this:  ,e.tsn as ticketserialnumber But on the SQL after the "/* Start Here */" it is different:  ,e.tsn as tsn On this type of queries you should always match the order and types.  ... View more

Hello @Chetan_mn,  I was checking and the entrypoint for this kind of scenarios should be start.sh, that should call everything you need to start it.  https://hub.docker.com/layers/apache/nifi/2.4.0/images/sha256-e8ca069f1533e6ee52d706fa3395ea16fe6f29468c7c6234a3f1c6232b912704 Do you have any error log that can give us more clues here?  ... View more