@Green_  Considering the number of deployments, it might make most sense for you to do this using multiple rest-api calls. First to import your version controlled flow (no parameter-context associated with that version controlled flow) Create a new parameter context with parameters required for that new flow. Update imported Process Group with new name and updated association with newly created parameter context. What you have at that point is a new Process group with new unique name and assigned parameter context.  While in NiFi-Registry you still have the dev version controlled PG with no associated parameter-context.  This presents some new challenges.... Back on your dev system where your source Process group was version controlled with no parameter-conext. Since it is version controlled, if you make a change in DEV (add new configuration that references a new parameter context key/value, all your other Process Groups version controlled against that same NiFi-Registry flow definition in prod will reflect a new version available.  If you "Change version" the Process group will get the change in the flow, but will also revert to NO assigned parameter context.  So you will need to re-assign the appropriate parameter context to that Process Group and update the parameter context with newly referenced parameter. Back on your dev system where your source Process group was version controlled with no parameter-context.  If you make a change that does not involve any newly introduced parameters, you will still have issue with parameter context being unassociated in dev if you change version.  So you will need to re-assign the appropriate parameter context to that Process Group upon any version change. On the prod system where you have 1 too many  process groups tied back to this single dev version controlled flow.  If you were to make a change, it would reflect as local change that needs to be committed to version control.  Since the version controlled flow has no parameter-context assigned, if you were to commit that change on dev, the version-controlled flow would get updated to reference the parameter-context assigned in Prod.  So back on dev system a local change will show. Changing version to that new version will show the prod parameter-context now.  And only way to revert this is by changing version on Dev back to an older version where no parameter-context was associated to dev process group.  Then commit the needed change on DEV instead of Prod. This feels like maybe an area for product improvement.  I am thinking along the lines of a checkbox on start version control or commit local that asks if parameter-context should be sent in change request.  (Already parameter context changes are not sent if the version-controlled flow already has a parameter-context associated with it).  This would allow you to choose not to include a parameter context with new version controlled dataflow (default checked) or not include new parameter context on commit local changes (default unchecked).   So you would need to be careful that only dataflow configuration changes to are made on dev to this reusable version controlled flow definition.  If you need to make deployment specific change on Prod, you would need to stop version control first, make the change and commit that as new unique version controlled process group.   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

@MattWho  Server under 1.26.0 and 2.7.2 are behind the firewall. Both servers were in the same subnet.  After we upgraded one of the server from 1.26.0 to 2.6.0 then 2.7.2 having issue using the Proxy Configuration service (Proxy server) to reach the internet ie: cloudera.com. $ curl -x http://proxy.xxxx.ca:8080 sftp://cloudera.com:22 -v * Trying xxx.xx.xx.xxx:8080... * Connected to proxy.xxxx.ca (xxx.xx.xx.xxx) port 8080 (#0) * allocate connect buffer! * Establish HTTP proxy tunnel to cloudera.com:22 > CONNECT cloudera.com:22 HTTP/1.1 > Host: cloudera.com:22 > User-Agent: curl/7.76.1 > Proxy-Connection: Keep-Alive > < HTTP/1.1 403 Forbidden < Cache-Control: no-cache < X-XSS-Protection: 1 < Connection: Keep-Alive < Content-Type: text/html; charset=utf-8 < Content-Length: 729 < Pragma: no-cache < * Received HTTP code 403 from proxy after CONNECT * CONNECT phase completed! * Closing connection 0 curl: (56) Received HTTP code 403 from proxy after CONNECT Disregard the proxy 403 error as it cloudera.com is not listed in the proxy white list. The OS curl connection is working so it is not related to the host file (we cant use it behind the firewall).   In NiFi 1.26.0 works fine.  The server upgraded to 2.6.0/2.7.2 was 1.26.0 previously and didnt have this issue.  Seems to be a bug with 2.x.  If we use IP address in NiFi, the ListSFTP will work but not when using the hostname ie: cloudera.com; seems to be an issue passing the hostname to the proxy. DefaultConnectFuture[A@cloudera.com/<unresolved>:22]: Failed (UnknownHostException) to execute: cloudera.com Please advise. ... View more

Hello @MattWho thanks for the information.  I'm already running the process only on the Primary node.  I will monitor and take a thread dump if it occurs again.  ... View more

I regenterate the keystore with the common server name.  Nifi UI works but I thought I can find the username/password in the nifi-bootstrap.log  I found the username and password encrypted in login-identity-providers.xml how can I decrypt them, or should I generate a new username/password and how? thank you. BN           ... View more

@Pashazadeh  Apache NiFI 2.0.x was a technical milestone/preview releases that underwent many changes before the first GA release with NiFi 2.1.x.  I would not expect a change in behavior going forward, unless some bug is introduced or the community agrees on a change in functionality/behavior.   While I don't have a specific answer to what bug resulted in the difference in behavior you encountered, here are some changes that affected the JsonRecordSetWriter. NIFI-14331 NIFI-13963 / NIFI-13843 NIFI-12670 If you still have your NiFi 2.0.0 running, you could run your flow using a convertRecord with same record readers and writers and then compare the output content with what you see with 2.7.1 output.  Maybe that can help figure out what is happening and if either of those bugs affecting earlier NiFi 2.x versions is related. Thanks, Matt ... View more

@MattWho Thanks for the clarifications. Here's the verbose output of the keystore used in the SSL Context Service for my NiFiFlowRegistryClient   Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: nifi-registry Creation date: Dec 20, 2025 Entry type: PrivateKeyEntry Certificate chain length: 2 Certificate[1]: Owner: O=3SCDemo, CN=nifi-registry Issuer: O=3SCDemo, CN=3SCDemo-CA Serial number:  Valid from: Sat Dec 20 19:51:52 UTC 2025 until: Sun Dec 20 19:51:52 UTC 2026 Certificate fingerprints: SHA1: SHA256:  Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions:  #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [                                        +... ] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[   CA:false   PathLen: undefined ] #3: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [   serverAuth   clientAuth ] #4: ObjectId: 2.5.29.15 Criticality=true KeyUsage [   DigitalSignature   Key_Encipherment ] #5: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [   DNSName: nifi-registry   DNSName: nifi-registry.dev   DNSName: nifi-registry.dev.svc   DNSName: nifi-registry.dev.svc.cluster.local   DNSName: localhost   IPAddress: 127.0.0.1 ] #6: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [                                        .... ] ] Certificate[2]: Owner: O=3SCDemo, CN=3SCDemo-CA Issuer: O=3SCDemo, CN=3SCDemo-CA Serial number:  Valid from: Sat Dec 20 19:51:51 UTC 2025 until: Sun Dec 20 19:51:51 UTC 2026 Certificate fingerprints: SHA1: SHA256:  Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions:  #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [                                         +... ] ] #2: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[   CA:true   PathLen: no limit ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [   DigitalSignature   Key_CertSign   Crl_Sign ] #4: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [                                     +... ] ] ******************************************* ******************************************* Please find the nifi-registry.properties file: # web properties # nifi.registry.web.war.directory=./lib nifi.registry.web.http.host= nifi.registry.web.http.port= nifi.registry.web.https.host=nifi-registry-0 nifi.registry.web.https.port=18443 nifi.registry.web.https.network.interface.default= nifi.registry.web.https.application.protocols=h2 http/1.1 nifi.registry.web.jetty.working.directory=./work/jetty nifi.registry.web.jetty.threads=200 nifi.registry.web.should.send.server.version=true # security properties # nifi.registry.security.keystore=/opt/certs/nifi-registry-keystore.jks nifi.registry.security.keystoreType=JKS nifi.registry.security.keystorePasswd=newps nifi.registry.security.keyPasswd=newps nifi.registry.security.truststore=/opt/certs/nifi-registry-truststore.jks nifi.registry.security.truststoreType=JKS nifi.registry.security.truststorePasswd=newps nifi.registry.security.needClientAuth=false nifi.registry.security.authorizers.configuration.file=./conf/authorizers.xml nifi.registry.security.authorizer=managed-authorizer nifi.registry.security.identity.providers.configuration.file=./conf/identity-providers.xml nifi.registry.security.identity.provider=ldap-identity-provider # providers properties # nifi.registry.providers.configuration.file=./conf/providers.xml # registry alias properties # nifi.registry.registry.alias.configuration.file=./conf/registry-aliases.xml # extensions working dir # nifi.registry.extensions.working.directory=./work/extensions # legacy database properties, used to migrate data from original DB to new DB below # NOTE: Users upgrading from 0.1.0 should leave these populated, but new installs after 0.1.0 should leave these empty nifi.registry.db.directory= nifi.registry.db.url.append= # database properties nifi.registry.db.url=jdbc:h2:./database/nifi-registry-primary;AUTOCOMMIT=OFF;DB_CLOSE_ON_EXIT=FALSE;LOCK_MODE=3;LOCK_TIMEOUT=25000;WRITE_DELAY=0;AUTO_SERVER=FALSE nifi.registry.db.driver.class=org.h2.Driver nifi.registry.db.driver.directory= nifi.registry.db.username=nifireg nifi.registry.db.password=nifireg nifi.registry.db.maxConnections=5 nifi.registry.db.sql.debug=false # extension directories # # Each property beginning with "nifi.registry.extension.dir." will be treated as location for an extension, # and a class loader will be created for each location, with the system class loader as the parent # #nifi.registry.extension.dir.1=/path/to/extension1 #nifi.registry.extension.dir.2=/path/to/extension2 nifi.registry.extension.dir.aws=./ext/aws/lib # Identity Mapping Properties # # These properties allow normalizing user identities such that identities coming from different identity providers # (certificates, LDAP, Kerberos) can be treated the same internally in NiFi. The following example demonstrates normalizing # DNs from certificates and principals from Kerberos into a common identity string: # # nifi.registry.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?), O=(.*?), L=(.*?), ST=(.*?), C=(.*?)$ # nifi.registry.security.identity.mapping.value.dn=$1@$2 # nifi.registry.security.identity.mapping.transform.dn=NONE # nifi.registry.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$ # nifi.registry.security.identity.mapping.value.kerb=$1@$2 # nifi.registry.security.identity.mapping.transform.kerb=UPPER # Group Mapping Properties # # These properties allow normalizing group names coming from external sources like LDAP. The following example # lowercases any group name. # # nifi.registry.security.group.mapping.pattern.anygroup=^(.*)$ # nifi.registry.security.group.mapping.value.anygroup=$1 # nifi.registry.security.group.mapping.transform.anygroup=LOWER # kerberos properties # nifi.registry.kerberos.krb5.file= nifi.registry.kerberos.spnego.principal= nifi.registry.kerberos.spnego.keytab.location= nifi.registry.kerberos.spnego.authentication.expiration=12 hours # OIDC # nifi.registry.security.user.oidc.discovery.url= nifi.registry.security.user.oidc.connect.timeout= nifi.registry.security.user.oidc.read.timeout= nifi.registry.security.user.oidc.client.id= nifi.registry.security.user.oidc.client.secret= nifi.registry.security.user.oidc.preferred.jwsalgorithm= nifi.registry.security.user.oidc.additional.scopes=${nifi.registry.security.user.oidc.additional.scopes} nifi.registry.security.user.oidc.claim.identifying.user=${nifi.registry.security.user.oidc.claim.identifying.user} nifi.registry.security.user.oidc.claim.groups=groups # revision management # # This feature should remain disabled until a future NiFi release that supports the revision API changes nifi.registry.revisions.enabled=false ... View more

@MuruganFinastra  Since you are getting a 403 response, the first thing you should do is see what user identity this 403 is being returned for.  For this you'll want to be tailing the nifi-user.log while you attempt to make this rest-api call. You will see the denied related log lines in the nifi-user.log.  That logging will provide the user identity string and which NiFi authorization policy required for which that user identity did not have the required permissions.   Using this output, we can determine the next steps required here.  Is the expected user identity being logged? What is the logged authorization policy resulting in the 403 response? Also which user authentication and authorization configuration options are you using in your setup? 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 @PepeVo! As this is an older post, you would have a better chance of receiving a resolution by starting a new thread. This will also be an opportunity to provide details specific to your environment that could aid others in assisting you with a more accurate answer to your question. You can link this thread as a reference in your new post. Thanks. ... View more

@MattWho Apologies for the delay here. I could finally try using certificates with the EKU Extensions and I do not see a similar authentication issue anymore.  Thank you for the kind assistance!  ... View more