This chapter is about the processing principles behind a kenaflow workflow.
Such a kenaflow workflow is - as already told - a bunch of PowerShell scripts.
And also already told we offer workflows for different purposes, especially SharePoint, E-Mail and PowerShell.
Workflow must perform their work on a regular basis. However, not every system reports when there is work to be done.
SharePoint, for example, is able to report a change to a list item to other software. This is called an "Remote Event Receiver".
kenaflow is such a "Remote Event Receiver" for SharePoint. It registers a kind of web hook in SharePoint - Online as well as 2013, 2016 and *2019.
Furthermore kenaflow workflows can act as webhooks: They can receive for example "unstructed data" as we call it.
Please read this article for details: Remote Event
Other systems like E-Mail mailbox servers do not inform a third party system about incoming mails.
Therefore kenaflow executes workflows on a reguar basis.
Every workflow has a setting called "TBE" = "Time Between Execution". This is the amount of time (seconds) > 0 that must elapse between two starts of a workflow.
A "TBE" < 0 means that a workflow is not executed on a regular basis. This is useful for SharePoint workflows that use "Remove Events".
A "TBE" of 0 means that a workflow will start as soon as possible after it is finished.
"TBE" is not guaranteed. Because ALL workflows are queued it can take much longer to be executed. Or much more time between two starts elapses. Because of the queue.
"TBE" an be combined with "CRON" to schedule workflows on a time pattern basis.
Regular execution ("TBE" >= 0) can be combined with "Remove Event" based execution.
Starting with kenaflow 4.0 we offer "permanent executing" workflows: There each "permanent" workflow runs in a separate process in the operating system.
All non-permanent workflows are queued for execution. If you have lots of workflows only some of them will run in parallel. You can configure the amount of parallel workflows.
A workflow can have a priority. This can be used to influence the workflow position in the queue. Normally, an executed workflow is added to the back of the queue and takes some time to run again. As already told the "TBE" - time between executions - can be much larger than executed with lots of workflows are in the queue... BUT with "priority" you can control it's position. Based on it's "TBE" and priority relative to the "TBE" and priority of all other queued workflows the next execution of a workflow gets re-calculated / re-scheduled permanently.
Details: Workflow Priority
For more flexibility it is possible to define several queues for workflows. We call it "slots". The workflows that are assigned to a "slot" share the same queue.
Per slot the amount of parallel workflows can be configured.
Details: Execution Slots