Anatomy of Nodes
Each node has inputs and outputs and configuration parameters. The terminology is the same for all nodes, but each node may have its own inputs and outputs. In this section, all the features of a node will be discussed via HTTP Request node. The aim is to learn everything about node configuration and how it works.
All nodes have inputs and outputs, which are divided into value and event. Value inputs are the inputs that represent the values a node needs to operate. A node will not execute until all of its value inputs are filled. For example, if a node has 5 value inputs, it requires that all 5 connected outputs have produced a value. When it is the node's turn to execute, it checks whether all value inputs are filled; if they are, it runs, otherwise, it waits. Once a node runs and produces a value, it automatically clears the input values, ensuring that each node works with the most current values. (You can enable or disable this feature from the configuration panel in the "Frozen Handles" section.)
In some situations, you may want a node to be triggered by certain events. For example, you might want a node to trigger another when it starts running, or trigger a different node if it encounters an error. For such scenarios, trigger inputs are used instead of value inputs. This feature is designed for tasks that need to run asynchronously. You do not always need to wait for a node to complete and produce a value; instead, you may need to trigger another node at a specific point in time during its execution. You can use event connections in these situations.
Note: Value outputs can be connected to value inputs, and event outputs can be connected to trigger inputs.
All input and output types will be discussed in detail below:
If we want a node to be triggered by the event output of another node, we must make a connection to this handle.
For example, as shown in the image above, we started a 5-second Delay using a trigger button, and we want the HTTP Request node to be triggered and run as soon as this delay begins. In this case, as seen in the image, we should connect the start event output of the Delay node to the trigger input of the HTTP Request node. As soon as the Delay starts, the HTTP Request node will be triggered and will check if the value inputs are also filled. If they are, the HTTP Request node will start working as configured.
Note: The number of trigger inputs can be increased as desired via the Node Configuration Panel. Because we may need more than one trigger input.
Summary: Trigger inputs are used to trigger a node at any point during the execution of the connected node.
Value inputs are like the parameters of a function; a function cannot work without them. All other nodes connected to the node must complete their work and produce a value. When this happens, all the value inputs of the node are filled. The node gets triggered and checks if all its value inputs are filled; if they are, it starts working, otherwise, it waits. Value inputs, as the name suggests, hold a value. These values can be primitive or reference types, such as numbers, strings, booleans, arrays, objects, or null.
Event Outputs are used to trigger another node according to an event at node's runtime, not the output value of the node. We do not always care about the output value of a node, sometimes in some cases we need to trigger another node as soon as a node starts or when a node fails, or when a node finishes working. For such cases, it is necessary to make a connection from event outputs.
Note: Connections can only be made from Event Outputs to Trigger Inputs.
When a node is triggered, it continues to operate based on its inputs and configuration parameters (covered in the next section). Once it completes its task, it produces output values, similar to functions. (Again, like functions, there may be nodes that do not produce output values.) When these values are produced, if another node is connected, that node is triggered. For example, if node A is connected to node B, node A will trigger node B once it finishes its process. When node B is triggered (whether from trigger inputs or value inputs), it checks if all value inputs are filled. If they are, it proceeds, creating a chain reaction.
For another example, let's say nodes A and C are connected to node B. When node A finishes, it triggers node B. Node B checks if all value inputs are filled; if node C hasn’t finished, node B will not work because its inputs are incomplete. When node C finishes and fills the value outputs, node B is triggered again, checks all value inputs, and starts working if they are all filled.
Each node has its own configuration panel. It is used to make internal settings of the node and to make initial settings. The panel can be opened by double-clicking on the node in the Flow Editor. Each node's own internal settings are made in this panel. In addition, the default behaviors for the inputs and outputs mentioned above are determined.
This is the tab where the initial values for the node are set. It is not possible for the node to work without filling in the required fields. When you drag a node to the editor, the first thing you need to do is to set the node's configuration parameters appropriately. After making the settings, you should save your settings by pressing the Save button. Here is an example for the HTTP Request node:
From this tab, you can make settings regarding events and behaviors during node operation.
You can turn on and off Input and Output events. When you open an event, the connection handle of that event will appear immediately on the node on the panel.
There may be more than one trigger input on the node. You can turn them on or off or add a new one here.
We mentioned that each node can be triggered from another node's event output via trigger inputs. We also mentioned that after being triggered, it will start working if the value ends are full. But what if the node is already working and is triggered by another node and needs to work again because the value ends are full? In such a case, the behavior of the node may change depending on the situation. There is no single correct answer. You should choose the behavior that suits you according to the scenario. You can make this choice from the Trigger Attributes section. The options are as follows:
- Ignore: Ignores the new incoming request.
- Restart Operation: The already ongoing operation is canceled. The operation is restarted according to the new trigger.
- Queue: The new incoming request is added to the queue. When the already ongoing operation is finished, the operations accumulated in the queue start to be performed again in order.
We mentioned that a node deletes all its value inputs after it completes its work. However, in some scenarios we may not want this to happen. Even if the node has worked and finished its work, there may be situations where we do not want some input values to be deleted. For such situations, we need to freeze the value values that we do not want to be deleted from the configuration panel. When we do this, the values of the frozen inputs will not be deleted even if the node has finished its work. To freeze a value, it is enough to click the lock icon next to it. To end the freeze, you can click the lock icon again to return it to its previous state.
In this document, we have discussed the anatomy of a node. We covered how a node works, how to set up the initial settings, and the purpose of its inputs and outputs. Nodes are similar to functions in traditional programming, regardless of the programming language. With the Originzero low-code automation tool, nodes are enhanced with features like asynchronous operation, simultaneous, and parallel processing based on the scenario. Although each node's inputs and outputs may vary, their general structure remains the same. Understanding the basic anatomy of a node is key to understanding low-code automation systems.