Introduction
In this blog, I am going to take a look at how our dynamic data forms solution works. But let’s start from the beginning.
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 then 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.
Parametrisation
Now the task is assigned, the form is built up and instead of values in data fields are placeholders. Here comes the parametrization! The user who chooses a data field clicks on it…nothing happened yet. Then the user types a new value or selects a value …request with (new) value is fired. NAE Backend starts the processing of data with its validation. One of the attributes of data is validations. If data is validated then the new value is saved. As I mentioned before, all data and data references do have set triggers (preprogrammed block of codes). Data-set action is the last thing that happens before the response with the updated form is sent back to NAE Fronted. The data has more attributes than validations: id, title, placeholder, etc. Data reference (field) has e.g. style and behaviour (hidden, visible, editable, required, etc.). Behaviour is a critical attribute in order to finish work with a data form. Only data fields that have one of their behaviours editable can be edited by the user.
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 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 – 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! ?