Re: NiFi code re-use

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

Re: NiFi code re-use

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

Re: NiFi code re-use

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

Re: NiFi code re-use

So I think we have a lot of different concepts going on here. I’ll try to provide my thoughts on each one as I’ve spent a good bit of timing thinking about each of them over the last year or two :) Wormhole connections: these would be very nice to have because it would allow us to avoid having

Re: NiFi code re-use

IMO the concept of "functions" is different enough to warrant its own set of components, rather than trying to shoehorn them into a wormhole / PG discussion. Perhaps a Function component which may feel like a PG (but with UI distinction such as rounded corners?), but would be referred to by name

Re: NiFi code re-use

Joe, Aldrin, Wormholes is pretty interesting thing. I played around with that and could make it working. Though, this approach has downsides. I'll create an article for this, but you can take a look at it now (attaching template for root canvas). So, what I've found while playing around this

Re: NiFi code re-use

I think what you highlighted is kind of how I had it worked out in my mind. Although maybe I read too much into the description of the proposal about the framework managing context. In terms of what we have now, I think I pictured this to be "Tag this data as from this source" and then when

Re: NiFi code re-use

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

Re: NiFi code re-use

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,

Re: NiFi code re-use

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

Re: NiFi code re-use

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 wrote: > Hi Devs, > > I've got a question about an observation I've had while working with > NiFi.

NiFi code re-use

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