@Malrashed Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. If you are still experiencing the issue, can you provide the information @jagarwal has requested? Thanks. ... View more

@Alexm__  While i have never done anything myself with Azure DevOps pipelines, I don't see why this would not be possible.  Dev, test, prod environments would likely have slight variations in NiFi configurations (source and target service URLs, passwords/usernames, etc).  So when designing your Process Group dataflows you'll want to take that into account and utilize NiFi's Parameter contexts to define such variable value configuration properties.  Sensitive properties (passwords) are never passed to NiFi-Registry.  So any version controlled PG imported to another NiFi will not have the passwords set. Once you version control that PG, you can deploy it through rest-api calls to other NiFi deployments.  First time it is deployed it will simply import the parameter context used in source (dev) environment.  You would need to modify that parameter context in test, and prod environments to set passwords and alter any other parameters as needed by each unique env.   Once the modified parameter context of same name exists in the other environments, promoting new versions of dataflows that use that parameter context becomes very easy.  The updated dataflows will continue to use the local env parameter context values rather then those used in dev.  If a new parameter is introduced to the parameter context, is simply gets added to the existing parameter context of the same name in test and prod envs.   So there will be some consideration in your automated promotion of version controlled dataflows between environments to consider. Versioning a DataFlow Parameters in Versioned Flows Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@venkatsambath @abdulpasithali @upadhyayk04 Hi! Do you have some insights here? Thanks! ... View more

hi @huimin, perfect! if you could describe the solution you implemented, it will help others who encounter the same issue. hugs. ... View more

@Virt_Apatt  I don't know enough about your use case to make any other suggestions. All I know is that your user(s) supply some custom date that you have NiFi add 10 days to before running a Oracle query to get some result set returned to NiFi. NiFi is typically used to build dataflows that are always in the running state, so users do not need to continuously stop, modify component(s), and start a dataflow/component. What is the significance of this "custom date" that starts your dataflow? Is there any pattern to these custom dates? Can the next custom date be derived from the response from the previous Oracle query? How often does this dataflow get executed? Just some examples (there are many NiFi processor components that can fetch content from external sources): You could start your dataflow with a getSFTP or getFile processor that is checks a specific source SFTP server or local directory for a specific filename. In that file is your custom date.  You then build your dataflow to extract that custom date from the consumed file to then execute your oracle query.  This way your NiFi is always running and just waiting for the next file to show up on the SFTP server or in that local directory it keeps checking. Or maybe setup an http lister (ListenHTTP or HandleHTTPRequest) that listens for an http post that contains the custom date needed for your running dataflow.   Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

Hello dear support team, I’m experiencing the same issue as the original poster and others in the thread. Could you please assist me in updating the email address associated with my account? Thank you very much ! ... View more

@GKHN_  As I described in my first response, Authentication and Authorization are two different processes.   So it sounds like from your comment that authentication is working fine for both your users and authorization is failing for your non admin user.  So issue is within the authorization phase. I assume both of your users are authenticating via ldap? In your ldap-provider in the login-identity-providers.xml you have the "Identity Strategy" set to  "USE_DN".   With this setting you the users full ldap DN will be used as the user identity string after successful authentication.  This means that entire DN is being passed to the authorizer to lookup if that full dn has been authorized to the requested end-point NiFi policy. I see you have your initial admin identity manually defined in the file-user-group-provider and the file-access-policy provider: CN=NIFIUSER,OU=Userpro,OU=CUsers,OU=Company,DC=company,DC=entp So when you login via ldap with this user's ldap username and ldap password, the user's entire DN is being passed to the authorizer and the file-access-policy provider has setup all admin related NiFi policies for this initial admin user identity. I also see from the shared authorizers.xml that the only user-group-provider the "file-access-policy provider" is configured to use is the "file-user-group-provider".  The file-user-group-provider requires the admin user to manually add additional user identities manually from the with the NiFi UI (Remember that with your current ldap-provider login provider, all your ldap user identities are going to be full DNs). As the admin user, go to the NiFi global menu and select "USERS": From the NiFi Users UI, select the "+" to add a new user: Then enter the full DN for your second user (Case sensitive). unless you have added any groups, your list of groups will be blank. Now that you have added this second user identity, you'll need to start authorizing that user identities for the various policy they need.  In order to access the NiFi UI, all users must be authorized to "view the user interface".  From the same NiFi Global menu mentioned above, select "Policies" this time.  Then from the "Access Policies" UI that appears, select "view the user interface" from the policy list pull-down. Then click on the icon to the right that looks like a person with a "+".  Find the user identity you just added and check the box and click the "Add" button. Now this user can access the NIFi UI. There are other policies this user will need before they can start building dataflows on the UI.  NiFi allows for very granular authorizations.   But at the minimum the user will need to be authorized on the process group in which they will build their dataflows.  Not all policies are defined from  the "Access Policies" UI in the global menu. the component level policies are define directly via the individual component (keep an eye out for the "key" icon)  From the "Operation" panel directly on the NiFi canvas you can set policies on the currently selected component: Above I have selected my root Process Group (PG). If you click the key icon you will see all the access policies that users can be authorized for.  You'll need to select each one by one your user will need and add the user to them. Above will allow you to setup access for your additional users using the file-user-group-provider you have configured in your authorizers.xml. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more