Merger Node (Order of Objects)

[damica51]

I'm using a merger node to merge several msg.payloads, BUT here is my problem. It will merge all of the msg.payloads but I really need them to be in the order they are read. How should I handle this?

[ralphwetzel]

Searching for "merge" in Manage Palette spits out 13 hits.

Thus: Which node do you use? Please provide an example of the data coming in, the data currently as merged ... and the result you expect.

Then I'm convinced, people can support here...

[Colin]

Also please show us some sample data so we can make sure we understand. If you are talking about the order of objects within an object then that should not make any difference. If you are talking about elements in an array then that is different.

[damica51]

Here is a picture, Each Http request creates an object (I have to do it this way because of the server I am reading from makes me do it this way)
Then I "JOIN" them to create an Object(Array) This is where they may become sometimes out of order and I need them to stay in the order they are read.

I'm sorry I said in my first post "Merge" node as it is the "JOIN" node that come embedded with Node-Red.

[marcus-j-davies]

This can be optimised somewhat!!

• I wouldn't use delay nodes
• No need for json nodes
• Put your HTTP requests in series.

Have your requests execute after each other - and set the request nodes to return a Parsed JSON object and finally, set the join node to return after the nth one.

Might be worth setting the request node to ignore the incoming payload also - so the last result, doesnt taint it and such.

funny thing, my image example can be further optimised - but you need to plan that carefully.
mine not even be the best way - but should be much better than using delays and all that jazz

[Colin]

In fact you can use a message property to build the array into as you go. If you start at the beginning of that by setting msg.result = [] then that property should be passed down the chain, and you can just push the next one each time. Then you don't need the Join node.

[marcus-j-davies]

You have done this before

[marcus-j-davies]

@damica51
To build on the approach by Colin,

Your first function node will have

msg.result = [];
msg.result.push(msg.payload)
return msg

Then subsequent function nodes will have

msg.result.push(msg.payload)
return msg

I'm sure the change node with JSONata can sit here also.

[TotallyInformation]

I would push to something other than msg.payload since that might get overwritten by subsequent requests.

I would also put the request and process on a separate flow using a link-in and a link-out at the end set to return to a link-call node which is how you start the flow.

For the main process, start with an input of all of the URL's you need to request, then a split node to create multiple messages, each of which triggers the link-call.