Joe/All,

Thank you for the thoughtful answers and great discussion. I have not tried version controlled flows, but it sounds like that would suit my use-case best. So, if it works like a flow class, as you described, how do the many instances of the versioned flow get updated when changes are necessary to the logic? Would changes made to the flow in the registry automatically propagate to the flows using the logic?


Thanks,

Scott


On 05/12/2018 07:19 PM, Joe Witt wrote:
Scott

Youre very right there must be a better way.  The flow registry with
versioned flows is the answer.  You can version control the common logic
and reuse it in as many instances as you need.

This is like having a flow Class in java terms where you can instantiate as
many objects of that type Class you need.

It was definitely a long missing solution that was addressed in nifi 1.5.0
and with the flow registry.

Also, we should just remove the root group remote port limitation.  It was
an implementation choice long before we had multi tenant auth and now it no
longer makes sense to force root group only.  Still though the above
scenario of versioned flows and the flow registry solves the main problem.


thanks

On Sat, May 12, 2018, 9:22 PM Charlie Meyer <
charlie.me...@civitaslearning.com> wrote:

We do this often by leveraging the variable registery and the expression
language to make components be more dynamic and reusable

-Charlie

On Sat, May 12, 2018, 20:01 scott <tcots8...@gmail.com> wrote:

Hi Devs,

I've got a question about an observation I've had while working with
NiFi. Is there a better way to re-use process groups similar to how
programming languages reference functions, libraries, classes, or
pointers. I know about remote process groups and templates, but neither
do exactly what I was thinking. RPGs are great, but I think the output
goes to the root canvas level, and you have to have have connectors all
the way back up your flow hierarchy, and that's not practical.
Ultimately, I'm looking for an easy way to re-use process groups that
contain common logic in many of my flows, so that I reduce the amount of
places I have to change.

Hopefully that made sense. Appreciate your thoughts.

Scott



Reply via email to