Once upon a time there was a very nice and useful application called Opalis Robot. It was an application that allowed monitoring and task automation of servers, through the creation of jobs in a graphical fashion.
Around 2009, Opalis Software was acquired by Microsoft and Opalis Robot became part of the Microsoft System Center suite. The old good Opalis Robot, as we remembered it long ago disappeared.
Why Opalis Robot was so useful? Let’s see an example.
During my work, it happens to have the need to create jobs with a certain level of complexity.
For example:
- At 5 o’clock make a backup of a database
- If the backup fails, send an e-mail
- If ok, transfer backup files to a remote server appending a timestamp to the file name
- Log the completion of the backup on a database table
- At the same time, check disk space and send an e-mail if the free space is under a certain threshold
- Read emails and look for certain keywords, if you find the correct keyword respond with another email
With Opalis Robot you were able to build a job like this, and even more complex jobs because you could combine the basic tasks with one another, potentially with limitless possibilities.
So after a few years, I thought about creating a similar product: The Dummy Programmer Robot (from now, for the sake of brevity, we will call it “TDP Robot”). I want to emphasize that, apart from the general idea of creating jobs by linking objects together and a vague resemblance of the job editor to that of Opalis Robot 4, they are two completely different products and they are in no way compatible with each other.
I want to list what, in my opinion, are the strengths of TDP Robot:
- It is fully developed in C#
- It is simple to use and configure
- It has a simple plugin architecture, which allows you to easily build your own events and tasks (of course you need some programming skills!)
- It is distributed under the terms of the GPL 3 license, so you can freely modify and redistribute it (check the following for details: https://www.gnu.org/licenses/gpl-3.0.html)
In this article you will find some useful information to begin using TDP Robot.
The architecture in a nutshell
TDP Robot is basically a software that allows monitoring and task automation on your servers and PCs.
It consists of three main parts:
- TDP Job Editor: is a Windows Forms application which allows creation and editing of jobs in a graphical fashion.
A job starts with an event, which you can connect to one ore more tasks, which in turn can be connected to more tasks. - TDP Job Engine: is a Windows service which loads the job file produced by the Job Editor, and executes the jobs configured.
- TDP Plugin library: all events and tasks available in TDP Robot, even core ones, are packaged as plugins in .NET dynamic link libraries. These DLLs must be placed in a well-defined folder and are used by both Job Editor and Job Engine.
Download
Here you can download the latest version of TDP Robot:
If you need an old version, check the TDP Robot version history page.
The source code of TDP Robot is also available on GitHub at this address.
Installation
First of all you have to install .NET Framework 4.8, which you can download here.
Download TDP Robot installation package and unzip it. The following is the folder structure:
TDP.Robot | |--- Data |--- JobEditor |--- JobEngine |--- JobLogs |--- Lib
Below a brief description of the folders:
- Data: contains job’s definition files. Both JobEditor and JobEngine points by default to this directory.
- JobEditor: contains the JobEditor program (TDP.Robot.JobEditor.exe), which you can use to create your jobs.
- JobEngine: contains the JobEngine service (TDP.Robot.JobEngineService.exe) which takes care of the actual execution of the jobs.
- Lib: is the folder that contains TDP Robot’s plugins. Each plugin has his own subfolder, containing the plugin DLL and its dependencies.
- JobLogs: is the folder that contains the log produced by the execution of the jobs.
You can install TDP Robot with a simple “XCOPY deployment”, with the exception that you have to install the JobEngine as Windows service, but it’s a simple task and we will see how soon.
Copy the folder TDP.Robot wherever you want. Before you start doing anything, since you downloaded the binaries from Internet, you may need to unlock the assemblies blocked by .NET CAS (Code Access Security).
For example, if you show the properties of the file TDP.Robot.Plugins.Core.dll you will see something similar:
To remove the protection set by Windows you just need to check “Unblock” and press “OK”. The only problem is that you need to do this operation for all executable and dll files, one by one.
To complete the job in one shot just open the Windows Power Shell with administrator privileges, in this way:
Suppose you installed TDP.Robot folder under “Program files” run the following command into the Power Shell:
PS C:\Program Files> dir .\TDP.Robot\ -Recurse | Unblock-File
And here is a scrennshot:
This should be enough to solve the .NET CAS security problem.
Remember that if you place it in the “Program files” folder, to execute the Job Editor, you have to use the option “Run as administrator…”.
Remember also that JobEditor and JobEngine configuration files are configured by default with relative paths to refer the folders Data, Lib, and JobLogs. If you decide to put these folders in a different location, you have to modify the configuration files of the two executables (TDP.Robot.JobEditor.exe.config and TDP.Robot.JobEngineService.exe.config).
Now you only have to configure the Job Engine as a Windows service. To to this, follow these steps:
- Open a command prompt with the “Run as administrator…” option:
- Go to the following path:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319- Run the following command:
InstallUtil "[Path to TDP.Robot folder]\JobEngine\TDP.Robot.JobEngineService.exe"
If the installation of the service is successful, you will see something similar:
By default the job engine service runs using the LocalSystem account. You can change this in the service configuration window, which you can reach from Control Panel -> Administrative tools -> Services. Here you can see a screenshot of what I’m talking about:
Remember that, if you want to automatically startup the service at Windows boot, you have to explicitly configure the parameter “Startup type” to “Automatic”. It is worth noting that, in some cases the service didn’t started at Windows boot and I solved the problem using the option “Automatic (Delayed Start)”.
Start creating jobs
Creating jobs is quite simple. If you run the job editor you will see the following window:
Now you just have to drag and drop elements from the “Toolbox” window into the “Workspace” window. Double click an object to show its configuration window. It is important that you correctly configure each object, or you will get errors in the execution phase.
By default, each object execution is logged to a text file, so in case of error you should be able to understand what didn’t work. The logs produced by TDP.Robot are accessible in the “JobLogs” folder and listed in the “Log” window of the job editor.
When you are done, click on the menu Object -> Save to save you work. Remember that you have to restart the job engine service to use the new configuration.
Using object’s dynamic data
Each object (task or event) publishes some dynamic data that can be used by subsequent objects in the job execution chain. A dynamic data is nothing more than a variable whose value is set during the execution of the job. So, for example, if you create a job to backup every month some Sql Server database and you want to put the backups in a different folder each month, you can use dynamic data to accomplish this task.
Look for example at this configuration:
The field “Destination folder” contains the following string (note the bold text):
C:\Bck\{Object[15].ExecutionStartDateYear}_{Object[15].ExecutionStartDateMonth}
The text enclosed between curly brackets tells the job engine something like to “take the value of the dynamic data ExecutionStartDate of object with ID 15 and replace here”. If the task is executed on May 2021, in the execution phase the “Destination folder” will become:
C:\Bck\2021_5
and backups will be placed in that folder!
In general the syntax to use a dynamic data is the following:
{Object[ObjectID].DynamicDataName}
Or if the dynamic data is a recordset you have to pass a field name:
{Object[ObjectID].DynamicDataName[‘FieldName’]}
To know which dynamic data each object publishes you can use the “Dynamic data browser window”, which you can view clicking the button 
.
And this is the “Dynamic data browser” window:
Just double click an item in the Dynamic data list to automatically to see the code appear in the texbox for which you opened the the dynamic data browser window.
Attention: You will get an error during the execution phase, if you reference a dynamic data of an object that is not part of the execution chain of the object you are configuring. I’m sorry but the job editor doesn’t warn you about this.
Object’s iterations
When you create a job you are creating a chain of tasks triggered by an event. A single task can be potentially repeated multiple times, depending on its configuration. You can control this behavior through the following tab that is always present in task’s window configuration:
Here an explanation of the options available:
- Iterate as many times as the records contained in the default recordset of the previous task, or 1 if no default recordset exists: this is the default behavior. As explained above, each object publishes a set of dynamic data and among these dynamic data there could be some of type recordset. A dynamic data of type recordset basically means that it doesn’t contain a scalar value but a table (behind the scene there is actually a .NET DataTable). By selecting this options you are telling the job engine to execute the task a number of times equal to the records contained in the default recordset (a dynamic data called “DefaultRecordset”) of the previous task or 1 if the previous task doesn’t have such a dynamic data.
- Iterates as many times as the records contained here (write in the format {ObjectID.FieldName}: same as the previous option, but you can use a different object ID / dynamic data instead of the default recordset of the previous object.
- Iterates this exact number of times: you can specify an exact number of iterations.
The first option is usually ok in most cases, but sometimes you may want to choose a different option depending on the job you are creating.
Available events and tasks
This is the list of events and tasks available now in TDP Robot, but I will add more …
Events:
- Date / Time event: triggered at a certain date time
- Cpu event: triggered if the CPU exceeds a certain usage threshold
- Disk space event: triggered if disk space is below a certain threshold
- File system event: triggered if something changes in your file system
- Memory event: triggered if system memory exceeds a certain usage threshold
- System events event: triggered when certain system events are fired
- TDP Robot service start event: triggered when TDP Robot’s service starts
Tasks:
- Excel file task: read / write an Excel file
- FTP / SFTP task: file transfer using FTP / SFTP protocols
- Read text file task: read a text file
- Write text file task: write a text file
- REST Api task: consume a web api service
- Run program task: run a generic external program
- Send e-mail task: send an e-mail
- Sql Server backup task: makes backup of your Sql Server databases
- Sql Server command task: executes commands and queries on your Sql Server databases
- Zip task: compress one or more file or folders in a zip file
- Unzip task: uncompress one or more zip files
Future developments
The product is far from complete and, as always, there is a lot of room for improvement. I list some new developments I would like to make:
- A general improvement to the job engine
- Make the job engine service controllable by the job editor application
- Review some technical choices (for example the use of .NET binary serialization)
- Adding more events and tasks: I know there are still few compared to what the old Opalis Robot 4 provided (sorry I developed only the ones I needed immediately…)
- Make the whole product run on other platforms: potentially, the use of the Mono framework should make TDP Robot cross platform. I tried but there are still some problems…
Send me an e-email if you find any error, if you have any suggestions or you need a particular event or a task. I do not guarantee, but I promise that I will do everything possible to satisfy you 🙂
License
TDP Robot is released under the terms of the GPL 3 license (https://www.gnu.org/licenses/gpl-3.0.html).