Here we descibe who a kenaflow instance works on the kenaflow server.
If there are multiple kenaflow instances on the server they all behave on their own in the same was as described here.
In FREE and DEVELOPER edition of kenaflow you can only run 1 instance of kenaflow on 1 machine.
As described in article Architecture kenaflow has three important folders on the file system:
- Program folder
- Program Data folder
- Workflow Root folder
In the "program folder" is a file named "kenaflow.conf". That contains the so called global configuration. The file is encrypted with a server specific key that is provided by Microsoft Windows. The file cannot be transfered to other machines. - To decrypt it you can use program switch
The global configuration can be edited with this command:
kenaflow.exe --editconfig. (Details:
To execute kenaflow for automatic workflow execution the program is started with this program switch:
kenaflow.exe --run. This executes the so called "main mode" of kenaflow.
If it is started e.g. by the Windows Scheduler (Automatic Execution) the additional switch
--norestart is used. It prevents kenaflow the "main mode" to restart automatically, e.g. in case of changes to the global configuration.
The "main mode" is runs in its own process in Windows. It controls the execution of workflows, starts sub processes and monitors them.
During automatic workflow execution different process types ("modes" of
kenaflow.exe) are required:
- The "main mode" as described. (
- The "rer global mode" (
kenaflow.exe --rer): This registers several http endpoints to receive remote events. There is only one such process for a kenaflow instance.
- The "rer runner mode" (e.g.
kenaflow.exe --rerrunnersp2019): For every platformat that supports remote events with kenaflow (all types of SharePoint workflows and PowerShell workflows) there by default at least 1 such "rer runner mode" process. It monitors the remote event queue (see below) and processes incoming remote events that are specific to the platform of the "rer runner mode". E.g. the "rer runner mode" process started with
kenaflow.exe --rerrunnersp2019does only process remote events for workflows that have specified
SP2019as their platform in
It is possible disable a certain "rer runner mode" process for a platform. E.g. if you do not connect to SharePoint Online you can disable the "SharePoint Online rer runner mode". This is done in global configuration.
It is also possible to configure more than 1 "rer runner mode" per platform. E.g. if you have much remote events coming from "SharePoint 2019" you can configure 2 or more "rer runner mode" processes to execute in parallel. Each of them will process remote events from the queue. But every remote event is processed by exactly on "rer runner mode" process at a time. If a remote event gets postponed it's maybe executed by another "rer runner mode" process next time.
- The "exectution mode" (e.g.
kenaflow.exe --exec --workflow "<workflow-forlder>"): For every workflow execution a separate, new and fresh process is started. For security reasons. If such a process fails it gets terminated by the "main mode" process
There can be multiple "execution mode" processes at one time. How much is decided by the main mode. But the maximum of parallel running "execution mode" processes is configured in global configuration. Default is 5. We call this "execution lane".
In FREE and DEVELOPER you can have only one "rer runner mode" per platform!
The main mode process starts the sub processes. It monitors that they are running.
The sub processes of all types monitor the main mode process. If it gets terminated they terminate itself ASAP.
The sub processes communicate with the main mode process using "inter process communication".
The sub processes send heartbeat messages to the main mode process to tell their "owner" that they are alive. If they do not send such a message they get terminated by the main mode process.
If a subprocess was terminated the main mode starts them again. E.g. if you configured 5 "rer runner modes" for SharePoint Online and one is terminated for some reasons the main mode process will start 1 new "rer runner mode" for SharePoint Online.
All enabled workflows - they have a setting of
Enabled = $true in their
_wfconfig.ps1 - are queued for execution. This queue is maintained by the main mode process. The first workflow in the queue is executed by a new "execution mode" process started by the main mode. It gets started if:
- an "execution lane" is available and
- the workflow configuration "TBE" and its last run timestamp allow the workflow to run. As described before there are a number of parallel "execution lanes". If they are full (e.g. 5 workflows already running in parallel) the next workflow must wait. If a workflow (it's execution mode process) end the next waiting workflow will take the free lane.
Because the engine cannot tell how long the execution of a certain workflow will take it's not possible to exactly schedule a workflow to run.
To control the workflow execution each workflow has a "TBE" setting. This means: "Time Between Execution". Its an amount of seconds that must elapse between two starts of the workflow before it runs again. - If TBE is 0 it will be queues to "run again ASAP". If TBE is < 0 it will never run by time.
The workflow queue is operated by a simple "first in first out" mechanism. By no means! The order of the workflows is permanently recalculated, as soon as there is a free "execution lane".
First: Execution lanes can be grouped into "slots". This is an advanced topic, described here: Execution Slots. Each slot has its own calculated queue. By default there is just 1 such "slot" with id 0. If not configured otherwise all workflows are executed in this slot.
Second: Each workflow can have a "priority" setting, to be configured in
_wfconfig.ps1. By default each workflow has a priority of 0 which means that all have the same priority. (Read this: Workflow Priority.)
Each time an execution lane (of a "slot") is free for a new workflow from the queue, the waiting workflows are sorted by:
- Their priority
- Their time in the queue since their last run.
There is some maths behinde the scene. It takes care that also low priorized workflows get executed some times also if high priorized workflows with a low "TBE" are waiting.
In the Windows Task Manager you can see the running processes. Make sure you enable the column "Commandline" in Task Manager: Switch to tab "Details". Right-Click the headline of the process list, e.g. on "PID". Click "Select Column". In the upcoming dialog check "Command line".
Some more things:
- If the global configuration "kenaflow.conf" changes all processes recognize this and try to stop ASAP.
- If the Windows OS is shutting down all kenaflow processes try to stop ASAP.
- If a file named ".update-pending" is created in the program folder this indicates the kenflow processes that an update is pending. They all try to stop ASAP.