Custom Node get wires information?

Could custom node get wires information in runtime? i.e. Node 2a7d48a8.86e4f8 wires to Node 9b7e69f6.78c268 in the following flow

[
{
"id": "2a7d48a8.86e4f8",
"wires": [
[
"9b7e69f6.78c268"
]
]
}
]

It might be possible (by interrogating the flows file if nothing else) but it goes against the node red philosophy. Why do you want to do it? There are usually better ways.

a node has the wires property (try this.wires). But, as Colin said, it is not recommended to use this

I'm using node-red to execute a DAG representation from other workflow engine (argo), each custom node acts as a function with input/outputs by remote call service. The DAG dependency works perfectly with node-red's data driven characteristic, but when coming to arguments passing, I found it hard to pass previous node's outputs to corresponding named parameters of downstream node for 2 reasons:

  1. Downstream node needs to merge its inputs from different upstream nodes;
  2. Downstream node needs to build its input parameters from corresponding output of upstream nodes, i.e. Node C requires 2 parameters: msg.param1 = msg.output1 (of upstream node A), msg.param2 = msg.output2 (of upstream node B).

I consider is it possible to get the wires dependency ahead, and each node claims its own inputs/outputs, then parameter passing could be done by using the "change" node.

Is there any workaround to solve this issue gracefully?

Would it work if you used named parms from the upstream nodes? So A might send a message with msg.payload.param1 set and B might send msg.payload.param2 set and then C can combine them?

and indeed use other msg properties like msg.from (to identify the sending node) etc... so the following node just needs to combine the .from and .outputx to create it's input param

It's a solution if the parameters mapping has been determined, like: (A)output1 -> (C)param1, (B)output2 -> (C) param2. And "join" node could work for the combination.

The side effect is we have to process the mapping inside the custom node, which should not be coupled with node original logic, and further more, if one node outputs for multiple other nodes with different parameter names, it could be a problem.

sounds nice. will give it a try.