Merovingian: “You see, there is only one constant. One universal. It is the only real truth. Causality. Action, reaction. Cause and effect.”
Cause and effect, or action and reaction
Many years ago, my business partner and CEO of Novayre/Jidoka, Victor Ayllón, and I wrote an article about Complex Events Processing (https://www.isa.us.es/downloads/proceedings/0097.pdf) in which we outlined the benefits of this kind of approach for problem solving.
Since the earliest days of Jidoka’s development, also a long time ago, we have included event management with different objectives:
- Show what happens on the platform
- Allow to understand the events preceding a problem
- Enable a mechanism by which users can perform actions in response to an event.
With these objectives in mind we started to include event registration in our RPA platform.
Each event includes fixed information such as its type and the time of generation and variable information depending on the specific event.
Types of events
We can distinguish several types of events depending on their origin.
For the daily management of the platform, some events are especially important, such as those related to the connectivity status of the nodes. If the nodes are not connected to the console, robots cannot be executed, and the platform won’t make sense.
Other important events are those related to the start and end of an execution, especially the end events, as they include information about the results of the processed items and the reason why the robot stopped the execution.
As I mentioned earlier, events include also extra information. This information changes depending on the event type and adds a lot of flexibility in event management. For example, we can associate an action to be executed after the generation of an event, depending on the type of event and, optionally, on one or several specific values included as additional information.
This management approach, combined with the available actions that can be executed in response to events, allows to create automated systems in the Jidoka consoles, helping the platform administration.
If a node is configured in a container, the console can start it when there is a robot waiting for an available node, and then stop it once the execution ends.
We can also define an event to be generated when the RAM memory used exceeds an established threshold. The console will automatically restart when this circumstance occurs and the reboot will take place in a controlled way, for example, when no robot is running.
We can configure an email notification when the execution of a robot ends with a result other than OK, or when an error has been reported in the log.
The list of registrable events in the current version of the Jidoka platform is as follows:
- Related to authentication: login via form, login via “remember me” system, logout, forgotten credentials, forgotten QR code, failed login, change of user configuration, password expiration notification
- Related to integration with other systems: new chat, chat closure, voice command, API REST invocation, API FILE invocation, Amazon IoT button interaction
- Related to nodes: online node, offline node, node enabled, node disabled, node locked, node unlocked, node with limited disk space, node with high RAM consumption.
- Related to nodes in containers: container started, container stopped
- Related to files in nodes: existence of file in node, modification of file in node
- Related to robots and their executions: robot execution planning, execution without available node, started robot execution, finished robot execution, robot event generated by API, disabled executions, cancelled robot execution, no execution required, deletion of old artifacts
- Related to console: backup started, backup finished, backup restored started, backup restored finished, console started/stopped, console with insufficient disk space, console with high RAM consumption, console restarted, console waiting to be restarted
- Related to reports: planned report, completed report
- Other events: action planning.
As you can see, there are many events available and the list grows in each version adding more and more flexibility to the management of the platform.
The list of executable actions is much shorter than the available events, mainly because the actions are aimed at achieving that:
- The management team knows that something is happening (or has happened)
- The auto-healing system can go into action
In the current version of the Jidoka platform the available actions are the following:
- Restart console
- Start compatible container
- Start selected container
- Stop selected container
- Send email
- Enable/disable execution of robots
- Restart node
- Deleting old log files
- Start robot execution
Combining events and actions, we can get the configuration we need to be able to react quickly to any problem that may occur in a Jidoka console.
CTO at Jidoka.