Scott, Besides the documentation available in NiFi and in NiFi Registry [1], there are also Videos available on the Registry web site [2] that might be helpful to you.
Also, a Getting Started guide [3] has been written that didn’t make the 0.1.0 Registry release, but can be seen if you build off Master. -Drew [1] https://nifi.apache.org/docs/nifi-registry-docs/index.html [2] https://nifi.apache.org/registry.html [3] https://issues.apache.org/jira/browse/NIFIREG-93 > On May 14, 2018, at 6:10 AM, Ed B <bdes...@gmail.com> wrote: > > Scott, > No versioned PGs aren't getting updated when Registry version getting > updated. But NIFI UI will show you the PGs that aren't up to date. And it > is easy to update them to current version. > As discussed in one of the emails in this thread, there could be feature > implemented to have autoupdate capabilities, but it's not there yet. > There is really good doc on this topic: > https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#versioning_dataflow > > > > On Mon, May 14, 2018 at 12:07 AM scott <tcots8...@gmail.com> wrote: > >> 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 >>>>> >>>>> >> >>
