Before start > read the basic post about Novulo processes.
What are data processes?
Data processes can perform actions whenever a record is inserted, updated, deleted, or committed on a certain page. Each data process is executed on the data level without context (and no user interaction). A data process must return a boolean (success). If success is false the event is canceled. They can be used for data automation. For example, when a school deletes the “Advanced Statistics IV” course from its list of available classes this semester, the Teaching Schedule page or Student Enrollment page can also automatically get an update.
Technically speaking the process in the above example could have been modeled with an advanced process under the Delete button, however, if the process is purely on a data level and happens consistently, then it is more efficient to model these actions as a data process. So you have to ask yourself “If I add/delete/modify data here, what should automatically change elsewhere on a different page?”.
No User Interaction
It is important to understand that you must never use user interaction actions in data processes. Data processes are a form of automation executed by the application in the background.
Creating a data process
Data processes can be added by clicking on the root of your application. The following screen appears:
A new data process can be added by double-clicking on the process you want to add. An existing data process is identified by a pencil on the icon of your data process.
Flow
To determine which data process you want to use have a look at the image below.
The Before Commit process will resolve before the Before Insert and Before Update processes.
The After Commit process will resolve after the After Insert and After Update process.
The old() function can be used to refer to the value that is in the database. Before committing the record, this value can differ from the new value.
Example You on the product record, you change the name from “Wrong” to “Right” in the Update Record.
Before committing, trigger.record.old().name = “Wrong”, whereas trigger.record.name = “Right”. After committing, both are “Right”.
Editing data with processes
There is a quick way to edit data with a “Edit record” action and a more thorough way using lock, update, commit and unlock operators. In many cases, the “Edit record” action will suffice, however, the thorough way is necessary when there has to be more control over the locking, updating, committing and unlocking steps of editing data.
Edit record
This action does the entire database interaction for editing data by itself and can be used to quickly do some edits. In this scenario, we add an “Execute” button to a grid. We make sure in the properties of this “Execute” button that we allow selection and allow selection of multiple record items from the grid.
Tip: The “allow empty selection” is for very specific scenarios so in most cases not relevant, by default just toggle it on.
Then we create a small process:
The For each action expects a list, so in its properties we tell it that it is getting a list of records via trigger.records:
Next, the Edit record action needs to know it is getting an item from a for each action, so we add a for_each.item as record type:
After pressing enter, the fields will appear in the dialog and new values can be set.
Tip: To let the user see the updated data on the page, add a LoadPage operator to the process, let it open the same page, set it to “View” mode, set Record to view to “trigger.record” and set Navigation to Replace. This will refresh the page with the new data in the user interface elements.
lock, update, commit and unlock
For a more thorough data manipulation process, we can use lock, update, commit and unlock to edit a record. This sequence is useful when the locking, updating, committing or unlocking stage require data actions. This sequence is always the same:
First a record gets locked in the user session, in the update record, new values are set for the elements from the user interface. The commit record writes the data to the database and unlock record unlocks the record from the user session again. So the above Edit record example is the same in detailed steps as follows (where for_each.item is specified as record in each action):
