Calling a Flow from a Node

[Jean-Philippe Encausse]

Hi,

May be a n00b question, is there a node that can dispatch it's message to an other flow ?

I see in previous post something about "subflow" ?

[Nicholas O'Leary]

A node sends its messages to the nodes it is wired to - it cannot pick where to send things.

In 0.14 we added the 'link nodes' that let you create virtual wires between flows (possibly between tabs). That would be one option available to you.

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

[Julian Knight]

Subflows are a convenient way to be able to call the same bit of flow logic from many places. For example, if you always wanted to update a global variable or write to a database when posting to MQTT for example, a subflow that does that might be a good way to go.

[Jean-Philippe Encausse]

Thanks that's the missing piece I was looking for : the link node :-)

--

http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---

You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/7WwDOEwD7yc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+unsubscribe@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

--

Jean-Philippe Encausse - R&D / IoT / Innovations http://www.encausse.net - http://arm-avocats.fr Twitter: @JpEncausse - Mob: +33 6 82 12 56 99  Do it Once, Use it Twice ~ Do it Twice, Make It Once

[Tony Gilkerson]

I understand a node cannot pick where to send things, however it can publish a message with a specific topic.  Therefore, I am thinking of creating a dispatching node that “calles” a subflow by publishing a message with the target subflow name as the topic.  The subflows would all start with an AMQP subscription.   This approach is acceptable to me but I don’t like the fact that the message would need to leave the node-red process boundary when it is publishes to RabbitMQ. 

Is there a way to do a pub/sub pattern on node-red without leaving the node-red process boundary?

-Tony

On Wednesday, August 31, 2016 at 4:29:40 PM UTC-4, Nick O'Leary wrote:

A node sends its messages to the nodes it is wired to - it cannot pick where to send things.

In 0.14 we added the 'link nodes' that let you create virtual wires between flows (possibly between tabs). That would be one option available to you.

Nick

On 31 August 2016 at 21:27, Jean-Philippe Encausse <jp.en...@gmail.com> wrote:

Hi,

May be a n00b question, is there a node that can dispatch it's message to an other flow ?

I see in previous post something about "subflow" ?

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.

[Colin Law]

On 12 February 2017 at 16:23, 'Tony Gilkerson' via Node-RED

<node...@googlegroups.com> wrote:
> I understand a node cannot pick where to send things, however it can publish
> a message with a specific topic. Therefore, I am thinking of creating a
> dispatching node that “calles” a subflow by publishing a message with the
> target subflow name as the topic. The subflows would all start with an AMQP
> subscription. This approach is acceptable to me but I don’t like the fact
> that the message would need to leave the node-red process boundary when it
> is publishes to RabbitMQ.
>
> Is there a way to do a pub/sub pattern on node-red without leaving the
> node-red process boundary?

Not sure exactly what you are trying to do, but you can pass messages
between flows using the Link node. So that would let you wire your
despatch node direct to the receiver on another flow. What else are
you trying to achieve, if anything?

Colin

> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/node-red/7a0a98db-d3e4-4379-827d-767a69a55243%40googlegroups.com.

[Tony Gilkerson]

Maybe there is something about links that I don’t understand.  Let me describe better what I am trying to do and you tell me if I can use links.

I want to create an app can generate a subflow based on user input and then push that subflow out to my node-red instance. I would use the node-red API to automate the import of this subflow.  Let’s call this user-subflow.

On my backend node-red instance I have a dispatcher-node that receives messages from RabbitMQ.  The Rabbit message contains within it the name of the target subflow to execute.  The dispatcher-node must apply common business logic and then call the appropriate user-subflow based on the subflow name contained within the message.     

The challenge I see with Links is that links are created at development time, I want to create a node that can call a subflow created at runtime.   

An alternate approach would be to create a script that can import the subflows and update a switch node dynamically.  However, I don’t like this approach as well because the dispatcher node IS created at development time and is managed in git and I don’t really want the master copy in git to be different from the runtime copy.

Your help and ideas are appreciated. 

[Julian Knight]

I think that you are really pushing the outer edges of Node-RED here. I am wondering why it is that you want to create effectively dynamic flows? I suspect that, if we saw your overall aims, there might be better ways to approach it.

[Tony Gilkerson]

The need for late binding has many valid use cases.  In my case I think it boils down to the fact that I can’t wire things up at development time because the user-subflows don’t exist yet.  The user-subflows are created at runtime in the app.  I don’t want to give my user an empty node-red pallet, rather I need to ask them questions in the context of the business domain and generate the flow for them.  I guess I want to use node-red as dynamic rules engine. 

I will rethink my approach but I do believe the ability to either dynamically call a subflow from a node or the ability to do pub/sub within node-red’s process boundary which in effect would be a way to call a subflow would be useful.

Thanks,

[Nick O'Leary]

Hi,

If you are dynamically adding subflows, you should also be dynamically generating the necessary wiring and logic to invoke the subflows. We will not be introducing other mechanisms for one node to invoke another - that goes against the flow-based programming model node-red provides.

Nick

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/cfe40143-bfa3-41fa-a9bf-9a8e1f58db41%40googlegroups.com.

[steve rickus]

Tony, I think what you are describing is doable, but would not utilize subflows, which are expected to have a single input node wired into one or more nodes within other flows. Sounds like you just need each new (dynamically created) rule flow to listen on a new MQTT topic that is specific to that flow logic (the "target" from your RabbitMQ example). That way you can deploy a "framework" for dispatching messages to user flows that don't exist until after deployment.

For instance, the first "user-defined" business rule flow that you generate would start with an MQTT listener for topic "businessrule/scenario1". After that generated flow is deployed, any messages published with that topic would effectively be "sent" to that new flow. The main dispatcher flow could even have listeners on the "businessrule/#" topic, in order to monitor all the targets in use -- say for generating stats/logging info, or even persistence in a file or database.

Do I understand your requirements correctly? Personally, I love this idea of generating flows to encapsulate some business logic, based on what the end user needs, and deploying them as needed. Last year I spent quite a bit of time doing something similar based on queries to an existing application database. It has the potential to replace a pile of custom ETL code that the application is currently using.

If you manage to get it working, I would love to see your dispatcher flow and maybe a generated business rule flow (if there are no intellectual property restrictions, of course). Good luck!

--

Steve

[Tony Gilkerson]

Steve, you describe it well.... I understand node-RED will not be adding this functionality. If I build this using pub/sub I will try to remember to post back here to let you know. Thanks for all the input.