OS-Robot stands for “Operating System Robot” and is a free, open-source, and cross-platform software for performing monitoring, integration, and automation tasks on your servers or personal PC, using a graphical user interface.
The architecture
OS-Robot is composed of the following components:
- JobEngine: a C#-based service responsible for executing jobs on the machine where it is installed.
- JobEditor: a web client developed using HTML / Vue.js / JavaScript that allows users to visually create jobs. The JobEditor communicates with the JobEngine via HTTP endpoints exposed by the JobEngine itself.
OS-Robot is cross-platform: the JobEditor can run on any operating system that supports the .NET runtime. Since the JobEditor is a web client, it can be used through any standard web browser.
OS-Robot is an open system: as mentioned, the communication between JobEditor and JobEngine occurs through the standard HTTP protocol, and jobs are saved in JSON format. This makes it possible to develop “alternative” clients using other technologies (such as .NET MAUI, Avalonia, Windows Forms…), as long as the expected format required by the JobEngine is respected.
The JobEditor
The image below shows what the JobEditor looks like after logging in.
The page is divided into the following sections:
- The title bar (1): aligned to the right, it contains the following buttons, which allow you to perform these actions:
View folder logs 
Force job configuration reload
Save jobs
Open the “User Profile” menu
- The workspace tree (2): jobs can be grouped into folders, and in this section, you can view and navigate the folder tree structure.
- The object library (3): contains events and tasks that can be added to jobs via drag and drop.
- Workspace area (4): this section displays the jobs contained in the currently selected folder.
- Event/Task configuration form (5): this section allows you to enter the configuration of the element selected in the workspace area. It is a collapsible section, and its content changes depending on the currently selected object.
Job Execution
To understand how jobs are executed by the JobEngine, let’s start with a very simple job, which you can see below.
The purpose of the job is to run a query every hour, write the result to disk, and send the result as an email attachment.
Let’s go through each step:
- Every hour: this is a “Date Time Event” configured to trigger every hour.
- Query database: this is a “SQL Server Command Task” configured to execute a query on a database.
- Write query result: this is a “Write Text File Task” configured to write the result of the query (received from the previous task) to a file.
- Send result via e-mail: this is a “Send Email Task” configured to send the file generated by the previous task via e-mail.
Each event and task, during execution, generates a set of data (called “dynamic data”), which can be used by the subsequent tasks.
This is why the “Write Query Result” task can write to disk the output of the “Query Database” task, and the “Send Result via Email” task can send the file generated by the “Write Query Result” task.
To find out which dynamic data a specific task publishes, you can use the “Dynamic Data Browser”, which you can access by clicking the button with the lightning bolt icon (outlined in red in the image below).
By clicking this button, the following window will appear, allowing you to browse the dynamic data published by each event and task in the current folder. When you select the desired dynamic data, a reference string will automatically be generated for use in the object’s configuration.
Here is how a field looks like when it reference a dynamic data:
Dynamic data syntax
This is the general syntax to reference a dynamic data in a task configuration:
{object[<objectID>].<fieldName>[<rowIndex>]['<subFieldName>']}The strings enclosed in <> ara variables to which you can assign a value:
- <objectID>: it is the ID of the object whose dynamic data you want to reference.
- <fieldName>: it is the name of the dynamic data referenced by the object identified by objectID.
- <rowIndex>: if the dynamic data is a recordset, this identifies the row you want to read.
Valid values are:- an integer value to get a specific row
- ‘{iterationIndex}’ or ‘{subInstanceIndex}’ as placeholders to specify the iteration number or the subinstance index of the running task (more on this in the next paragraph)
- <subFieldName>: if the dynamic data is a recordset, this identifies the field name whose value you want to rereference.
All variables are mandatory, except:
- <rowIndex> is not mandatory, but if the dynamic data is a recordset and the variable is not specified, it is assumed ‘{iterationIndex}’ by default
- <subFieldName> is mandatory only if the dynamic data is a recordset
Below are some examples of syntax for referencing dynamic data.
| Dynamic data string | Description |
|---|---|
| {object[28].ExecutionStartDate} | Retrieves the value of the “Execution start date” dynamic data from the object with ID 28. |
| {object[27].DefaultRecordset[‘StockName’]} | Retrieves the value from the recordset “DefaultRecordset”, row = {iterationIndex} and column name = ‘Stock name’. |
| {object[27].DefaultRecordset[{iterationIndex}][‘StockName’]} | Same as previous line. |
| {object[27].DefaultRecordset[2][‘StockName’]} | Retrieves the value from the recordset “DefaultRecordset”, row = 2 and column name = ‘Stock name’. |
Iterations and task instances
Let’s start by providing some definitions:
- Iteration: a repetition of the ‘work’ within the execution of a task instance.
Depending on its configuration and type, a task can perform from one to N iterations. - Task instance: a task instance that can execute one or more iterations within itself.
You can configure the number of iterations for a task through the “Iterations” section available in the configuration form of every task:
Let’s go through a couple of examples, where we won’t go into the details of each task’s configuration, but instead we will take a higher-level approach.
So suppose you have a job like this:
These are a “Read Text File Task” and a “File System Task” connected to each other. With a default configuration, if the first task returns a recordset containing a list of ten files, the second task will perform ten iterations—one for each row in the recordset—and in each iteration it will delete the file corresponding to that row.
Let’s see another example:
In this case, we have two “Read text file task” and one “Sql Server bulk copy task”.
The first task “Read file list” is configured to read a list of files from a text file, thus producing a recordset that will be processed by the next task.
The “Read each file content” task, in each iteration, will read the content of the file corresponding to the current row and will produce a distinct set of dynamic data for each iteration.
The generation of these multiple and separate dynamic data sets will trigger the execution of multiple instances of the final task, “Write to database”.