Workflows and Digitalization
Since several years our enterprise and its coworkers are consulting in the field of Microsoft SharePoint and related technologies. Our tasks are the conception, introduction, installation, support and extension of all SharePoint related issues.
We are often involved in the creation of digitized workflows for our customers. The data and information are stored in SharePoint. The workflows should be implemented on this basis. In most cases, it is necessary to include different people in the process at different times, for example, "decision makers", "deputies", "information procurers", "purchasers", and so on. This is because, the data usually remains in a (virtual) location, but they "move" due to their assignment to specific people through the company.
Workflows are the work processes, in which information is processed by man and machine
In order to realize workflows with SharePoint, additional solutions such as kenaflow are not necessarily needed. However, the built-in options are usually not convenient or adequate. Therefore, it makes sense to rely on specialized tools as soon as digitalization is to be advanced across the board.
There are some workflow software publishers for SharePoint, but they all take the same approach of putting workflows in the hands of "Power Users". "Power Users" are employees of the company who are not necessarily members of the IT department. These workflow software publishers suggest, that implementing and modelling workflows is so easy that every employee can do it. To create workflows there are designed tools: Applications with a graphical interface with which workflows can be "clicked together".
At first glance, that may seem like a good thing. You drag a "box" from the menu onto the desktop and connect it to other "boxes". But then comes the moment when the tide turns: the "box" must be clicked to configure the workflow action. In face of what the "Power User" sees at this point, they are usually overwhelmed: fields with setting options, selection lists, fields for URLs, fields for IDs or even configuration texts in XML and so on. At this point, it becomes clear that the complexity of a workflow cannot be brought into a simple, clicked structure by means of a magic tool.
Developing workflows is more the job of professionals/programmers than the task of employees from purchasing, personnel management or controlling.
The mentioned tools and software are expensive, because the development of graphical applications is complex and complicated, which is why they can only be configured up to a certain degree.
However, we have chosen a different approach which, in our view, is better suited for reality and better supports those who, in reality, are capable of implementing the workflows from the technical aspect:
We developed kenaflow.
A workflow platform aimed at administrators and developers.
The basis for this is PowerShell, a scripting language that is explicitly aimed at administrators who should be able to manage the server landscapes automated.
PowerShell is an established factor in the SharePoint context because SharePoint is configured via PowerShell. A professional SharePoint consultant will do almost all of the configuration through PowerShell and just open the "Central Administration" to check the progress.
PowerShell is also becoming more important in other areas of everyday IT, and without PowerShell, SharePoint can hardly be adapted to the real needs of a business.
So we thought it would be practical and logical to develop SharePoint workflows based on PowerShell.
What is missing, however, is the software component that handles the execution of the PowerShell scripts: executing the right script in the right context at the right time.
Translating a single workflow into a single script is not difficult. However, implementing many workflows in many scripts and managing them is difficult. So a way has to be found to deal with this problem. Furthermore, it must also be easy to maintain.
kenaflow defines a "Workflow Folder", each containing all the files necessary for a workflow. These workflow folders are located in the workflow root.
One of the strengths of kenaflow is the ability to version workflows: any workflow folder or the workflow root can be easily linked to GIT or any other source code management-, synchronization software or backup solution, and it can be retracted at any time how workflows are changing.
Finally, when it comes to running several or even a lot of workflows, the topic of "parallelization" is important.
kenaflow offers the possibility to run many workflows simultaneously. The degree of parallelization can be controlled by the kenaflow administrator.
In terms of scaling, kenaflow also offers the possibility of running the software on several computers at the same time. The kenaflow instances synchronize workflow processing among each other.
Another advantage is that kenaflow can be executed on a single computer in multiple instances, e.g. to realize workflow development and workflow productive operations on the same server. The kenaflow instances do not interfere with each other.
Since workflow development comes close to the programming of software, it is natural that known procedures from software development have been implemented in kenaflow.
Versionability has already been mentioned. Another aspect is the "debugging", i.e. the examination of program code during execution, to check the execution itself or to control the contents of variables. - Debugging is an essential tool. kenaflow implements two options and both allow you to go into the PowerShell scripts. For this purpose "PowerShell ISE" and/or "Visual Studio Code" are/is used. The PowerShell ISE has the advantage of being part of the Windows operating system and is available everywhere. - Details can be found in the chapter "Debugging".