An action is a single task in a workflow. Actions consist of input and output ports. Input ports are used to receive data, while output ports send data via connection to another action. An action is basically a code in the system. Input ports are mapped to input parameters of a function in code when output ports are mapped to the return values. ReBid CDP can be extended by programmers who write code and map it with action, which later on is visible in the workflow editor as nodes.
Action ports
An action node can have only one input port and many output ports. A port that returns no data will not trigger the next node execution.
Action internal state
Each action node has a reference to the following data:
- id - node id
- debug - flag that tells if the node is in the debug mode
- event - currently processed event
- profile - currently processed profile. Profile may be empty if the event that is being processed is a profile-less event.
- session - current user session
- flow - flow diagram
- node - information on the current executing node. With information on the inbound and outbound edges.
- console - the object where you can log errors and warnings.
- metrics - metrics object
Action core methods
An action node has 3 core methods:
- build - asynchronous method for action building
- init - synchronous action constructor
- run - methods that runs the action
Auxiliary functions
An action should also have a set of auxiliary functions that help ReBid CDP with action registration and data validation. Those functions are:
- register - it should return a Plugin object with information on action specification, metadata, etc.
- validate - how to validate the configuration data