Allan,
The current approach would be to define the values as system or environment
variables and then reference them in NiFi expression language. Be careful
when choosing variable names as flow file attributes will take precedence
when there is a conflict. For instance, if you reference something called
${post.uri} it will first check the attributes of the current flow file. If
that attribute doesn't exist it will check system environment variables. If
that doesn't exist, it will check JVM system properties. One option for
setting these that would work well for different instances of NiFi would be
in the conf/bootstrap.conf. An example would look like
java.arg.5=-Dpost.uri=http://host:8080/path
where 5 is an integer unused within bootstrap.conf. There will be other
java.arg.X properties in that file.
This should provide the behavior your looking for. However, it's not great
as it requires access to the box to set variables and requires a restart if
changing any of the values. Because of this, I've created a new ticket for
being able to manage variables within the UI [1].
Matt
[1] https://issues.apache.org/jira/browse/NIFI-764
On Tue, Jul 14, 2015 at 10:49 AM, Beharry, Allan D <
[email protected]> wrote:
> Classification: UNCLASSIFIED
>
> Hello,
>
> I am running Nifi on one environment and would like to be able to take
> that flow.xml.gz and put it in a different environment (e.g. from staging
> to production). Problem is that currently we have processors that have
> configurations that are environment specific. As an example, we could use
> the InvokeHTTP processor and the remote URL property is specific to the
> environment. This means that if I take the flow.xml.gz from one
> environment to the other, I have to manually go in and change the remote
> URL property. This is less than ideal.
>
> I would like to minimize the amount of manual work required in moving a
> flow configuration from one environment to the next.
>
> How would I achieve this?
>
>
> Thanks,
> Allan
>
