Dynamic data forms as part of low-code language application platform
A typical data form is a document with fields (placeholders) in which a user can write or select specific elements. Forms were historically created with the purpose to simplify usage during legal processes. And that is what the Netgrif platform does, simplifies processes. There is no better usage for dynamic forms than to use them in the Business Process Modelling solutions.
Process modelling and form building
Journey with our platform always starts in Netgrif Application Builder (NAB). There, you can create a process that suits the solution to your problem the best. Processes are composed of event-driven transitions/tasks and state-holding places (transition and places are connected via directional arcs). With tasks come the data forms fun. All you need to do is in Form builder (place a transition, right-click and select “Create/Edit form”) where you can use a drag’n’drop tool that will allow you to use existing data fields or add new data fields of your choice. Here is a simple demo of NAB, where you find how to work with Form builder (video).
Process instance
The output/result of the modelling in NAB is the Petriflow XML file. This XML file can be easily uploaded into the running Netgrif Application Engine (NAE) application on the fly or during the engine’s startup. Once the model is uploaded into the NAE, it is transformed into objects and users can start work with it.
NAE applications are role-based and group-based. Typically there is more than one model in a running application. This is where the first interaction between NAE Backend (Spring boot) and NAE Frontend (Angular) happens. Form — a user interface or front-end — can be easily customized for the needs of any customer but by default, users have to choose from the list of processes. After a user chooses a specific process, a request to create a new instance of the process is fired (with its title and other metadata). Try the Demo of NAE where you can try to upload and work with your own process model. Here is a simple demo of NAE, where you find how to work with data forms (video).
At this point, NAE Backend builds up an instance of a selected process. An instance is some kind of clone of the original process. It has all attributes (transitions, places, data, roles, etc.) of the original process. The original process can be used this way multiple times (restriction of the number of instances is the capacity of storage space or it can be preprogrammed). An instance is a functional representation of a modelled process.
Tasks, events and triggers
The instance is a representation of the modelled process and the same logic applies to tasks with transitions too. A task is a representation of transitions in the process. User can assign only those tasks that are executable (also role-based access takes its place in it). NAE Backend sends to NAE Frontend only a list of tasks that logged user can execute. I explain this approach in a blog about loose coupling.
Netgrif platform and Petriflow language contain four different events that are associated with transition/task. Those events are: assign, cancel, delegate and finish. The name of each event describes when it is fired.
In the phase immediately, after instance initialization and task expansion, the user can execute only one event — assign. What comes next is a series of preprogrammed event-based and trigger-based actions that the NAE Backend executes in exact order. Now you are likely asking yourself: “What are those actions?”.
Events consist of two types of actions: pre actions (a set of preprogrammed blocks of code, that is executed before the actual task is assigned) and post actions (a set of preprogrammed blocks of code, that is executed after the actual task is assigned). During the phase between pre and post actions is the task assigned to the user, metadata is set and dynamic data form/web UI is built up. But one piece of this puzzle is still missing…
Form build-up
(Here comes a missing piece 😉) Tasks are associated with events in order to fire actions. Data do have triggers. Triggers are fired after a data or reference of a data fulfils any trigger condition. Trigger conditions are two: set (preprogrammed block of code is fired when the value of data is changed) and get (preprogrammed block of code is fired when data is build up into GUI). As I mentioned, in Petriflow processes there are also data references (fields). Their purpose is simple, data is global for the whole process instance and data reference represents referenced data in any task and form of the instance. Data get trigger actions on all data and data references that are present in the assigned task are fired between pre and post assign actions, right after the data form is built up.
Cancel or finish?
The parameterization is in the hands of the user individually. After parameterization, in order to finish work with the data form, the user has to press any event button or collapse the task. But whether finish, delegate or cancel an event is called depends on the user. Two event-actions and completion of chosen action will happen. Let’s look at the happy path scenario — the finish event. Pre-finish actions, task finish operation and post-finish actions finalize the path of data form that was easily prepared in the Form builder.
Summary
The data form solution that we implemented in our platform is not about forms as a standalone part of an application. Dynamic data forms were meant to be used in BPM processes. Roles, data, actions, model, etc. together create the Netgrif application platform. The next article about other features will be coming soon. Stay tuned! 😊