Aldrin Referencable groups would have to work like a single instance of a PG in terms of flow definition but caller specific instances in reality. Otherwise youd have no way to avoid cross contaminating flowfiles from various callers as thered be no caller specific stack (in our case caller specific queues and other resources).
The point about keeping versions of instances up to date with registry based versioned instances is true but can be addressed with auto updating instances of versioned flows which we will need to add anyway. In either case having PG operate like a callable function reusable across flows will likely need to operate as mentioned above. The former being less consistent with the user experience and more work than the latter. Do you see some other way to make referencable groups work. Wormhole connections need to be implemented for sure to help keep flows concise. Thanks Joe On Sun, May 13, 2018, 11:42 AM Aldrin Piri <aldrinp...@gmail.com> wrote: > I think the Registry solves part of the issue but even that would lead to > duplication of units where we are "copying and pasting" the "code." > Versioning would aid in keeping all components in lock step, but will not > remedy manual intervention with n-many instances of them. After one was > altered, there would still be the manual process where the PGs would each > need to be updated when that change was committed and changes were realized > after some time delta. > > I think the previously discussed Reference-able Process Groups [1] are > likely better aligned in conjunction with the Wormhole Connections [2]. > > [1] https://cwiki.apache.org/confluence/display/NIFI/ > Reference-able+Process+Groups > [2] https://cwiki.apache.org/confluence/display/NIFI/Wormhole+Connections > > > > On Sat, May 12, 2018 at 10:19 PM, Joe Witt <joe.w...@gmail.com> 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 > > > > > > > > > > > > > >
