For more than 10 years I have been developing information systems with workflows. We started with the simplest solutions, using various products, and eventually have made the WorkflowEngine and the Low-code platform.
The most common question I am asked is “How to bind Form and Workflow?” This is both a simple and extremely complex architectural issue for information systems, where the user input and approval process and/or data processing are combined. In this article, I consider the most common architectural patterns used in modern software.
What is the meaning of these terms?
The form is a collection of fields that describe a business entity. For example, the “Contract” entity has a number, a date, an author, a name, a business partner, and so on. These fields are displayed to the user and usually are stored in the database separately from other business entities.
Workflow is a process that consists of states and transitions between these states. For example, the “Contract Registration” process includes an initial contract entry, validation of fields, approval, upload to other systems, etc. The process instance has its own parameters, such as Status, Approving Employees, etc.
1. State column
By the state-column architecture, the form data is stored along with the process data, they are not separable. The simplest implementation option is to add a State column to the business entity table.
The state-column architecture is suitable for the simplest systems with a limited workflow of sequential status changes.
For example,
Draft -> State 1 -> State 2 -> Final
If your business process is simple and does not change, you can easily implement the transition logic by yourself or using some entry-level products that allow creating a static workflow in code or SQL procedures directly.
State-column architecture has two disadvantages:
· A change of one field leads to a change of the object status;
· Form logic and workflow logic are mixed
The state-column architecture is not suitable if the workflow of your project can change and consists of more than 5–7 states.
2. Workflow-centric
By the workflow-centric architecture, the form fields are stored in the process parameters. For example, as shown in the picture below, we store the status and some of the fixed fields in the Workflow table. The WorkflowParameter table stores a dynamic set of parameters, including the form fields.
This architecture is rather flexible and easy to implement. It allows you to store an arbitrary set of process parameters and form fields and enables you to add custom fields to the form without changing the program code. You can easily manipulate the form fields inside the workflow, and define a custom form that the user will see.
The disadvantages of this architecture include:
- Difficulties to implement the CRUD (Create-Read-Update-Delete) functions for processing the data
- Deadlocks may occur when actively adding and updating a large number of form fields.
We use the workflow-centric architecture in our WorkflowServer software.
3. Form-centric
By the form-centric architecture, the form fields and the workflow parameters are stored separately. For example, in the Contract table, we store the form fields and status, while the Workflow table stores the workflow parameters. You should store the status and some additional form fields to optimize performance. Roughly speaking, the goal is to get any of the form fields and status with a simple SELECT query, without accessing the workflow subsystem.
Using the form-centric architecture, you can bind multiple workflows with one form and get easy access to the form data. It is also worth noting that this architecture provides high performance of solutions and unlimited optimization possibilities. For example, you can store the form data and the workflow data in different tables, or even in different servers.
Let us also consider the disadvantages. Since the form fields and the workflow are stored in different tables, we should create a process when a new form is created and delete the process when the form is deleted. On changing the process status, we should update the State field in the form. In other words, we must synchronize the form object and the workflow associated with this form.
We use this approach in our Low-code platform. It is difficult to implement, but it is the most flexible solution that can be used in any high-load systems without limitations.
Conclusions
The state-column architecture is the simplest option of the Form-Workflow association that allows you to easily add logic for changing the business entity statuses. It does not require the use of any specialized products. However, this approach is insecure and limited when scaling the application.
The workflow-centric architecture stores the form data in the workflow object. This is a very flexible approach that allows you to simply manipulate the form data within the process and does not require data synchronization between the form and the workflow. However, it has performance limitations; it is not flexible enough to work with data collected in relational databases.
The form-centric architecture is the most difficult approach to implement because it requires constant synchronization between the form and the workflow. Yet, it provides the greatest gain when used in large projects.
