You do know you can pass whatever you wish to the subroutine in the msg right?
What "parameters" do you believe are stopping you employing link-calls?
Yes. Issue is not with passing in msg. See below.
The way we have written subflows is the end user - connects the subflows to the inject and then double clicks that instance of the subflow and chooses parameters (subflow properties - env variables) to decide the "input" to the flow per se. Now what it means is all those calls need to be changed and assessed - how to ensure the flexibility continues to be available - to allow user to select his parameters. This is one of the best features of subflow - where it allows the user to select via. drop down or such mechanisms the env params.
I know we can still do it by keeping subflow definition skeletal and then calling the link call flow from within the subflow (dont remember if linkcall is allowed from subflow - else i will need to link in - link in calls)
It may not be the deploy that is taking the time, the problem is that because the processor is maxed out it is not able to get round to talking to the browser, so from the user's point of view it looks as if the deploy has not completed.
If you wait till it has settled down and is back to a stable state, look at the node-red process usage in task manager. Is that still running at the same high level or has it dropped back? Remember that the max that node red can consume is one core, so for a 4 core processor 25% is a full core. If it does drop back to a low level then it is indeed the deploy that is the problem.
Sure Colin - will check this again.
But wouldnt the CPU max out be related to number of subflow calls ? Cos if NR needs to instantiate each call and then i would expect it to max out CPU. I may be wrong here.
Once i went on the path suggested by Zen - its evident the issue is subflow calls
I have 2 flows which i have disabled now . And i finish the deploy in few seconds (from 30 mins).
And those 2 flows have among them probably 100 calls of subflows. And some of those subflows are extensive and call other subflows.
While not quite as nice and rather more limited, but could you not do this with a group? Groups can have environment variables as can subflows.
A possible alternative might be combining links with subflows so that you minimise the number of subflow instances.
Another thought might be to use some essentially empty sub-flows just to get the parameters but using those to send on to singular flows so that you are not constantly duplicating nodes.
Hard to know if any of those will work with your configuration of course but at least worth thinking about.
I need to check this. Will come back. Never used it before.
These 2 options for sure i am exploring.
-
Replace subflow call via. link call.
-
Replace contents of heavy subflows with link calls to allow parameterization.So subflow itself will be 1-2 nodes max.
(I still need to check if link call is allowed inside subflow or it would be the older link out - link in flows. -
Replace contents of heavy subflows with action node calls to allow parameterization. So subflow itself will be 1-2 nodes max.
During the deploy, yes, but once it is deployed all that is going on is passing the messages along and doing whatever is necessary with them. nodes that are not doing anything with a message do not consume any processor, unless they have asynchronous code in them.
It is, so long as there is only one link-in with the name specified.
but then you could just create a subflow that takes the UI params, adds them to the msg (e.g. msg._params), returns the msg, feed that to the link-call.
1 Like
What do you mean ? Isnt it like this irrespective of subflows ?
This is exactly my thought process. Hence i needed to know if "link call" node is allowed inside subflows.
I anyways do get to params only once . So very much possible. Plus the biggest advantage is the current flows don't need to be changed. User will not even come to know that the subflow was modified.
Keep it pure - only use the subflow to take the users UI input, add it to the msg, return the msg, send THAT to the link call.
MAINFLOW
inject -> subflow(Instance) -> link-call -> result
subflow
input -> function (get all the subflow parameters, put them in msg._params, return the msg) -> output
No need to call from inside the subflow
BUT - if you must, then do it - it works - so long as the LINK-IN name it targets is only declared once.
i.e. If you have TAB1 Link-in named "fred" AND you have TAB2 Link-in named "fred" - it will fail.
All clear. Will check what works for us.
Thank You all for helping with this issue of ours. At least we are clear why we have 50 mins of deploy time. And how subflows impact all this.
Thanks again.
1 Like
Ever since groups & link-calls have been introduced, I stopped using subflows (which act like assembler macros - each subflow instance creates a full replica of all its internal nodes).
If the need is just for UI to configure parameters for reusable groups, it can be achieved by preceding them with lean "entry points" (empty subflows, or better still, custom pass-through nodes). These entry points can provide UI for configuring per-instance parameters and add them to the passing-through messages.
Hi - Quick one - i did this - and in link call inside subflow - none of the Link Ins show up. My NR version is a bit jaded on my test env . Its 2.2.2 . Not sure if this has anything to do with it.
Out of curiosity, how do you run this with the âuserâ? Why would you have user (users?) change parameters in your flow? Wouldnât it be better to have users use the dashboard or some more fixed UI?
And another question regarding your original issue. So far Iâve had very long deployment times only when testing large loads with multiple thousands of messages floating through flows or when I made mistakes in function nodes and had very long lasting calculations or complex JSONata. Youâre doing such stuff?
Yes it is supported but it was added to a later NR version than what you are running
EDIT: I think it was added around April 20, 2022
We have 2 set of users - ones to whom we provide "pre built" sub-flows using which they can build their own flows. They connect to editor . And ones who work with Dashboards.
So the above impact is for users (including myself) - if i change a subflow interface - and then there are 80 places to change .
We have big flows. But in this context - messages etc. has no relevance. The issue was not around execution. The issue was we had fairly large subflows - couple of 100 nodes. And those subflows are used in multiple places more than 20-30 instances.
Had it been execution then it makes sense to check messages etc. But our issue was at deployment when we dont have any messages running.
Thanks. We will upgrade. And check.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
