Updating node config on deploy

Developing Nodes
1

Hi Everyone.

I am having a little difficulty with a scenario where we're interfacing with a third party system. The first time we deploy our node it does a considerable amount of setup and configuration that we have to use in subsequent interactions. Its a very manual, and multi-step process, and not something that we can repeat every time we deploy the flow.

The ideal place to store this additional information would be in the config that is passed to the node on initialization when a flow is deployed. We can use it as an indicator on the node editor that setup was previously done successfully and save us from having to do it again the next time the node gets deployed.

The only workaround I can think of at this point is to push a payload to the settings api (RED.settings.set) and use the node id as reference. The next time the node is opened for editing we would retrieve the settings via an ajax call for presentation purposes, and load it from the settings api when the node is deployed. The drawback with this will be that the additional settings will not be seen as part of the node and therefore won't be copied when the node is exported, requiring the setup process to be repeated if the node is copied (either locally or to a new NodeRed instance)

Any obvious workaround we are missing?

2

Perhaps I'm not fully getting your issue - yet what I understand seems be achievable by standard NR features: Have you tried to implement your pattern by using Node properties? Properties need not to be set (only) by UI, but can as well be populated by your node's code. They may as well hold any JS object (as long as they are serializable) allowing to store quite complex data.

3

Apologies. I tend to be very bad at explaining. I used "config" and "properties" interchangeably in my message.

We already have a couple of basic properties set when initializing the node in the backend, but part of the initialization process generates some additional values which we would like to persist as part of the properties.

eg:


function FooSystemConfig(config) {
    let node = this;
    RED.nodes.createNode(node,config);

    if(!config.setup){
        config.setup = doReallyExpensiveSetup(config);
    }

    // config.setup won't be persisted as it wasn't set in the editor.

};
RED.nodes.registerType("FooSystem Config",FooSystemConfig);

I have built another version by wrapping the doReallyExpensiveSetup call in a webhook that gets triggered from the oneditsave() function in the editor. This does fit the bill for packaging setup as part of the properties, but it does mean that doReallyExpensiveSetup is done during the edit phase as opposed to the deploy phase. If you edited the flow but decide to discard changes by not deploying the flow, you have already done doReallyExpensiveSetup which now has to be reversed in the third party system. It also means that the connection between nodered and the third party system is broken for the duration between editing the node and deploying the flow, which is why I discarded this approach.

4

A common method is to do it in two steps:

  1. user adds the node, configures static configs and deploys.
  2. user reopens the node to configure all the new dynamically added configs. What matters here is the redeployment because without it you can't save new configs to NR.

If this method doesn't suit you, the only other solution is to use the Storage API to save your stuff but since it's not very used there aren't many examples.

5

Thanks! This is pretty much the solution for now, with the dynamic properties being merged in from the settings api during oneditprepare

The question was asked in part to make sure I didn't miss an obvious pattern where properties can be dynamically updated on deployment.

6

No need to use settings, you can use your own route with $.getJSON:

Editor:

Runtime:

7

You still need to use settings in order for it to survive restarts.

RED.httpAdmin.post("/fooService/getSettings", RED.auth.needsPermission("inject.write"), function(request,response) {
    response.json(RED.settings.get("FooService_" + request.body.nodeId));
});
8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.