a3x is best compared to a python .pyc file or a java .class file. It is basically a “compiled” autoit script. The only difference to an .exe file is that it needs an “autoit” (current programming language of ffastrans) environment to run. Luckily, ffastrans.exe and exe_manager.exe have such an environment included, so no need to install Autoit itself.
In the past, all a3x files were actually delivered as .exe files with FFAStrans but it turned out that different antivirus softwares did not like it this way, so FFAStrans was changed to deliver a3x files.
Note that there is no difference between running on a standalone host or in a farm. The processes are the same on each and every member of the farm. All nodes look for new Job tickets in the same folders and compete against each other getting a job assigned (depending on CPU settings, “farm host exceptions” etc.)
ffastrans.exe can fulfill multiple purposes, depending on if ffastrans is installed as windows service:
In this picture, we see ffastrans.exe on a standalone host, not installed as service. ffastrans.exe took care about starting exe_manager which again started different sub-processes, e.g. def_runner.a3x and processors.a3x
In this picutre, we see that rest_service.exe took care about starting exe_manager.
Exe_manager watches for new tickes created by various methods supported by FFAStrans. Because of FFAStrans design all hosts will (compete and) try to pick up new tickets. When new tickets are validated exe_manager will start the processor and refer to the new ticket file, and thus create a (sub)job. FFAStrans has 3 types of tickets:
So exe_manager has the following tasks:
def_runner.a3x is started by exe_manager in case there are any active workflows that need watching for new files.
In this picture, we see that exe_manager started a sub-process that is also called exe_manager but when looking at the “command line”, we see that one of the exe_manager sub-processes takes care about def_runner.a3x
Whenever exe_manager found a new job ticket that needs to be processed on the current host, it will actually execute the “processor” that is described by the job ticket using processors.a3x.
This picture shows how the different processes work with Job Tickets.
TOOD: processors.a3x checks for status pause or abort of a job split, exe_manager for “.start~%workflow_id%” to see if def_runner needs to be started