When a function node is executed, does it have access to read an object that contains all flows and their configuration (the same object that you would use to export all flows)?
I would like to be able to determine whether a node exists with a particular configuration.
Hello .. You could use an http-request node, doing a GET request to http://<ip>:1880/flows
and set it to return a parsed JSON object .. but why do this .. i mean .. you created the flow so you must know if a node exists right ?
The reason for the request is that I have many different types of requests coming in from a web service, and due to an external system, they have to all come in on the same endpoint, and I wanted to avoid lots of wires and links by having the original request come into one flow, and then it would scan the flows to see if an appropriate handler exists for that type of request. If yes, it would pass the msg to that flow, otherwise it would send an error back to the service.
Right now my initial flow (with the http in node) has a link out node, then for each of my individual request types, I start with a link in node (connected to above), and then use a sub flow to determine if the current flow is a suitable handler. There are some problems with this. One is that I find the link nodes a bit messy. Second, there is no way to detect if there is no handler for a specific request type, or if I've accidentally added two handlers for a specific request type.
Sounds like a good place to use MQTT topics... you could set up a single input node that derives a topic string from the incoming data, and pushes that msg out to MQTT under that topic.
Every possible handler for that topic will receive the "routed" msg, without having a giant switch node with 100 output ports. You could even set up a catch-all topic listener to keep a global context list of all incoming topics, with an incrementing counter to show the numbers received for each topic.
I like (was about to suggest) this approach. The other "requirement"
may need a bit of a hack. MQTT does not provide a way to determine if anyone is subscribed to a given topic, but you could read the flow.json file, find the mqtt in nodes, compile a list of their topics, and do your checking. Doing this only once when the flow starts is probably enough.
Your mentioning of flows.json reminded me that I can just read in that file to do what I originally wanted. I could set an inject node to read in that file once each time a change is saved and keep it in a context variable.
That means I can scan through the nodes to find out if there's one I want to call...
Now once I have the id of the node I want to use, is there a way to call that node by it's id from a function node? Sort of like a link in/link out pair? I thought I had this part solved a few weeks ago but can't find in my notes...
Another way to make your flow look better and if you didn't want to use MQTT would be to use my event nodes. These act a little like MQTT but without the broker. Though it would only really work as long as each inbound msg type had a unique msg.topic.
The unofficial line would be you can get ahold of the node with RED.nodes.getNode(id) and then call it's receive function.... But that bypasses a bunch of core runtime code so isn't ideal.
Thanks. I don't really want to go rogue, but I would like to experiment with this option. When I put var target = RED.nodes.getNode('ba4050f1.a2d428'); in a function node I get TypeError: Cannot read property 'getNode' of undefined
I haven't rejected MQTT. I just don't know anything about it but I will look into it.
And @TotallyInformation, where would I go to learn more about your event nodes?
This is not only the "official line," it reflects a central part of the NR design philosophy. Nevertheless, several of us have developed nodes that break this rule, and @knolleary has shown you how to do it if you really want to. My advice FWIW would be to look carefully at using MQTT. It also breaks the rule, but it has major advantages for the readability and maintainability of your flows. It also has additional features in the protocol that you may not use at first but could turn out to be very helpful.