The cornerstone of business-driven development evolution
Petri nets are the right tool for modelling of the control flow of workflow processes. For a more accurate reflection of reality, it is necessary to extend Petri nets by more components. For this purpose, modelling language Petriflow was created, that adds roles and data variables to Petri nets and maps roles and data variables to transitions. Development of the language is deeply influenced by real requests incoming from customers or developers modelling complex processes. Every feature of the language is based and abstracted from real-life needs of modelling robust and complex processes. In Petriflow it is possible to model control flow of processes via place/transition Petri nets enriched by reset arcs, inhibitor arcs and read arcs. Petriflow language also introduces a layer of roles and data variables into nets. The roles define who can assign an enabled transition and who can execute a transition of the net. The relations between data variables, process instances and their tasks as well as communication with external systems can be programmed in actions that are associated with events. Actions are pieces of code written in Groovy. Petriflow allows setting visual aspects of data forms associated with tasks.
It is easy to understand the Petriflow process with knowledge of just a few Petri net rules. Petriflow language was created for purpose of taking advantage of the simple but formal nature of Petri nets and extend them to meet any requirements of the real-life business modelling. Every feature is added to the language based on experience and requirements from customers. Petriflow language is developed with rapid development in mind. If a customer requirement to model a feature of a process is out of the scope of the current version of the language, the property is analysed to understand the nature of the requirement.
If the requirement can be generalized, the resulting requirement is abstracted and implemented as a new property of the language. Petriflow language is written in XML format for the most part. Data field actions are the only exception. They are written in a domain-specific language based on Groovy programming language. Models are only the first step in a life cycle of a business process management (BPM). The main advantage of BPM is that the model can be used to control the workflow process according to the designed model using a workflow engine. Using an analogy with object-oriented programming, a Petriflow model can be understood as a class, while single Petriflow process instances can be understood as objects of that class. One of the main advantages of Petriflow processes is that because of their formal semantics, they can be formally analysed and can be mined from logs using Process Mining algorithms based on a synthesis of Petri nets from scenarios.
Whenever someone asks me if we’re using #AI or #GenAI in the NETGRIF platform, I always say, “It’s on the roadmap.” But what I like to point out is that Petriflow, our #LCNC source code, is already way ahead when it comes ...
This blog will be about Netgrif’s compatibility with BPMN. Generally, users of our platform and language don’t care about what workflows they use to create Low-Code process-based applications. But sometimes they do ...
The R&D prototype of the Netgrif platform dates back to 2008. Usually, when people ask me, what is the key difference between us and our competitors, my answer is our Low-code language Petriflow and the wide range of possibili...
In the world of web application development, two new fundamental concepts have emerged: “all layers in one object” and “process-driven programming” resulting in “object-centric processes”. These...
This paper summarizes the capabilities of the Petriflow language – a Petri net-based modelling languagefor the creation of executable process-driven applications. Furthermore, the Netgrif Application Builder a tool for creat...
This paper summarizes the capabilities of the Netgrif Application Engine – a tool for interpreting Petrinet-based models enriched by data, roles and actions reacting to events on process and data Published and presented at B...
In this paper, we present a prototype of a module of the Petriflow application engine that stores process nets for every single case of a Petriflow model, whose underlying process model is a place/transitions net. It enables to fi...
Introduction Netgrif application engine, a part of the Netgrif platform, is built to interpret programs of the language Petriflow. Petriflow is a high-level programming language for process-driven application development. Petriflo...
In this paper, we explain the usage of Petriflow language in a multi-process environment with inter-process communication via process events. We introduce an example that demonstrates the advantages of Petriflow language when sync...
In this paper, we present how to model complex business processes and synchronization between their instances using Petriflow language which extends Petri Nets with other components. Small snippets of code called Actions are intro...
Petri nets are the right tool for modelling of control flow of workflow processes. For more accurate reflection of reality it is necessary to extend Petri nets by more components. For this purpose, modelling language Petriflow was...
Netgrif Workflow Management System (Netgrif WMS) is JVM based application build on Spring framework. Netgrif WMS can be used to import Petriflow workflows in form of xml file. Process roles are then assigned to other users by auth...
From Petri nets to Petriflows
As mentioned before, Petriflow language extends Petri nets with other components. As the underlying model, we use place/transition nets enriched by reset arcs, inhibitor arcs and read arcs. The read arcs appear quite necessary to model the unbounded number of concurrent reading of data in a case. To meet modern business modelling requirements other layers were brought to the language on top of Petri nets. Roles are the first layer to extend Petri nets. Roles layer defines who can fire transitions to which they are bound. Data variables were added as the second layer on top of modelled processes. Data variables represent all properties of an instance of a process during its life cycle. To have more control over process instance data, data field actions were added to Petriflow. Actions can define relations or dependencies between data fields in the model of a process or generate values based on a process instance state. All extensions and layers create the right tool for modelling complex, yet simple to understand models of any process that comes to mind.
Transitions as tasks
In classical Petri nets, firing a transition is one atomic event. During this event, a transition consumes tokens from connected input places and produce tokens to output places. The number of consumed and produced tokens is according to the firing rule in original Petri nets. In Petriflow language execution of a transition represents an activity executed by an actor (a user or a system). In Petriflow language transitions represent tasks consisting of the assigned event, an action which corresponds to the state, during which the activity is executed, a cancelled event, an optional delegate event and a finish event:
Is the state where an actor, who executes the activity, does his job defined by the activity.
Consumes tokens from input places of the transition in the underlying network.
Cancels the task, i.e. produces the consumed tokens back to the input places of the transition in the underlying network.
Delegates the task to another actor.
Produces tokens in the output places of the transition in the underlying network.
Role and user layer in Petriflow
Roles can be defined as Petriflow processes. Events of tasks can have associated roles or user lists, that specify, whether the actor can fire the assigned event, whether the actor can perform the action and fire the cancel event and the finish event or whether the actor (optionally) can delegate the event to be performed by another actor. Assigned or delegated actor has to have a role that authorises to perform the action and to finish the task.
The data layer in Petriflow
In Petriflow language the data layer consists of data variables and their binding to transitions of the model of the process. In Petriflow language a data variable is primarily defined by its type, unique ID and title. The type attribute of the data variable determines the data structure of the variable. For example, if the data type of variable is set to a number, the value is stored as a number of the type double. Petriflow language allows using of primitive data types like number, boolean, as well as standard data types such as date, text as well as more complex types like enumeration, multi-choice, file. The language also introduces domain-specific types: lists of user, case and task references. The list of users stores the reference to the specific users of the system. The list of cases stores the reference to a list of cases. The task list stores the reference to a list of tasks. Visual attributes can be also set in the data variable object to more precisely define the representation and behaviour of the data variable in the graphical user interface. For example, the attribute placeholder sets a text value of a data field element when no user-defined default value is present.
Data forms: Binding data fields to task transitions
A data variable can be bounded to a transition if it is desired to display its values to the user performing the task transition. A data variable associated with a task transition is called the data field of the task transition. Obviously, a data variable can be bounded to several transitions. A data field, i.e. a connection between a data variable and a task transition is implemented as a reference inside of the task transition. The referenced data variable is identified in the reference task transition by its unique ID set in the data variable object. In addition to data variable ID, reference object has attributes to set data field behaviour and logic inside of the transition. Behaviour attribute defines the relation of the data field to the transition. The attribute values can be hidden, visible, editable, and required. When the data field in a transition is the visible user can see the value of the data field but cannot modify it. When one or more data fields in a transition are set as required, this transition cannot be finished until every required data field is filled. Values in the logic attribute are functions. In Petriflow language they are named as Actions. They are executed when the value is changed inside of the referenced data field.
39th International Conference on Applications and Theory of Petri Nets and Concurrency
Petriflow Actions
Actions are functions that can be associated with events of data variables, data fields and events of tasks. An action associated with an event is executed whenever an event is triggered, e.g. when a data field value is changed then the action associated with the state event is executed. Each action contains three parts. Action parameters are defined first. A parameter references to a data variable or a transition in the process model. The second part consists of the executed code. The third part is formed by keywords that specify which attributes of parameters should be updated and what should be the new values of these parameters. Actions implementation is based on Groovy DSL meta language. Groovy allows to define own semantics for domain-specific language and then compiles it to an executable code. All actions are compiled after the successful import of a model to the engine and then saved into a database. Actions enable to modify information stored inside of each case of the model in real-time as transitions are fired and the data forms are filled. An important part of actions are predefined functions that enable to find lists of tasks, list of users and list of cases. The find functions use predicates defining examples for queries as parameters. These predicates use the syntax of „where“ clauses of Querydsl queries.
Filters
An important part of a Petriflow application project are filters, that are separated from Petriflow processes. Petriflow filter can be associated with menu items in Petriflow application to filter tasks and process instances (commonly called cases). Petriflow filters are JSON objects specifying the search queries.
