Hi - wanted to get input on what the ideal implementation should look like for a flow that:
Will make an initial request to get some data from and endpoint (get what’s in the queue)
Using the data from the previous request, make further subsequent API calls with parameters coming from the response data
The way I’m accomplishing this is by storing the data I need into a flow level variable and building each msg object dynamically before each http request node. I.e. setting msg.url, headers (where the JWT goes), payload for HTTPPost body.. etc.
Is this the most efficient way to accomplish this?
I also want to add some re-try logic if these API calls return a non successful status code (retry three times). How could I create a (subflow?) that can be called after each http request node so I don’t have to copy/paste a bunch of nodes after each http request node?
You might like to look at @colinl/node-red-contrib-guaranteed-delivery which will queue messages for you, releasing them one at a time, and automatically retry on failure. You would have to add the logic to detect three failures and take alternative action then.
[Conflict of interest declaration: I am the author.]
Can you not use just one http node and associated logic? Perhaps you can use Link/Return nodes which allow you to go off to a flow and return when the operation is completed.
Thanks- the module looks nice. However I am behind a work NPM registry and I’d have to procure the package which isn’t always guaranteed the team in charge of it will approve it (I work in a pretty strict environment).
Can you not use just one http node and associated logic? Perhaps you can use Link/Return nodes which allow you to go off to a flow and return when the operation is completed.
Thank you for the responses.
Can you please elaborate on what you mean? When you say use a single http request node, what would that look like? They have to execute in sequence and the previous API call has to succeed before the next request.
And your second point about using link/return nodes- what exactly is this “flow” going to be performing when you say “allow you to go off to a flow?” I am not clear on your suggestion.
So you have a number of http request nodes with logic before it setting up the parameters, then after each one you will have to have error checking, retry logic and so on. If you have just one instance of that logic and call it as required from your main flow, using link/return nodes, then you do not need to have multiple copies of that logic.
It is a very simple node that I am sure would get through an audit ok, should you decide that it would be useful.
So you have a number of http request nodes with logic before it setting up the parameters, then after each one you will have to have error checking, retry logic and so on. If you have just one instance of that logic and call it as required from your main flow, using link/return nodes, then you do not need to have multiple copies of that logic.
Got it thank you I will look into link/return nodes - I’m just geting up to speed on node-red.
It is a very simple node that I am sure would get through an audit ok, should you decide that it would be useful.
I’m in a little bit of time constraint. Perhapslater I can refactor, thanks!
I have recently done some of this for maintainx api calls.
can share an example tomorrow when I get to work. Not sure if it’s what you are looking for but it’s relatively simple.
general scheme is:
synchronize flow variable with last reported value on maintainx on flow start > manipulate that value with input data from machines > post the flow value to api on some time interval
I have recently done some of this for maintainx api calls.
can share an example tomorrow when I get to work. Not sure if it’s what you are looking for but it’s relatively simple.
general scheme is:
synchronize flow variable with last reported value on maintainx on flow start > manipulate that value with input data from machines > post the flow value to api on some time interval
Thanks I think posting your solution would also help. I didn’t have time to spend on this project yesterday but in parallel have someone on my team looking at the link/return node solution proposed by Colin (for re-try logic I presume).
