Re: variable url for remote process group

2018-10-06 Thread Bryan Bende
The RPG URL can be edited after importing to the next environment, and it should be ignored when comparing against the flow in registry so it won’t be seen as a change that needs to be committed. So although you can’t use a variable, you should still be able to version control a flow with an RPG

Re: variable url for remote process group

2018-10-06 Thread mohammed shambakey
Hi Thanks, guys for your help. I ended up with building the whole RPG programmatically every time I need to change the URL, then delete (programmatically) the RPG at the end of the workflow Regards On Sat, Oct 6, 2018 at 4:37 AM Kevin Doran wrote: > Hi, > > Can you put the remote process group

Re: variable url for remote process group

2018-10-05 Thread Kevin Doran
Hi, Can you put the remote process group outside what is versioned to NiFi Registry? For example, if the remote process group is a sink, put everything upstream of it in a process group and version that as the thing that moves between environments, leaving the RPG, and the connection from the v

Re: variable url for remote process group

2018-10-05 Thread evanthx
i saw this and thought I'd reply as I have a similar issue. We have a staging and production cluster. I have a remote process group in them, and have our flow backed up in the registry as that seems to be the approved method for moving flows from staging to production. Since the remote process gr

Re: variable url for remote process group

2017-05-17 Thread Koji Kawamura
Hi Mohammed, As RemoteProcessGroup and underlying Site-to-Site protocol maintains connectivity between client and server, it is not supported to change remote endpoint dynamically. HTTP processors may work but it's not cluster aware so you will need a Load balancer in front of those. If the numbe

variable url for remote process group

2017-05-16 Thread mohammed shambakey
Hi Is it possible to use variables for remote process group, as the remote server IP is not known in advance? If not, the ONLY alternative for remote communication will be HTTP processors (e.g., handlehttprequest/response) instead of site-to-site, right? Regards -- Mohammed