Research and development

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.

Check PETRIFLOW documentation website to find out more

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:

In Progress

Is the state where an actor, who executes the activity, does his job defined by the activity.

Assign event

Consumes tokens from input places of the transition in the underlying network.

Cancel event

Cancels the task, i.e. produces the consumed tokens back to the input places of the transition in the underlying network.

Delegate event

Delegates the task to another actor.

Finish event

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.

1993
The history behind Petriflow language started by the research of Prof. Juhás in area of Petri nets
1993
1997
Our research that led to Petriflow continued by investigating the representation of Petri net behaviour at Aarhus University in Denmark in 1997 under the supervision of Prof. Mogens Nielsen
1997
1999
Our research continued at the Project Petri net technology of German Research Council at Technical University of Berlin under the lead of Prof. Hartmut Ehrig
1999
1999
We started to work on synchronization of task between process instances at University of Karlsruhe today Karlsruhe Institute of Technology as a part of Priority Program Integration of Software Specification Techniques for Applications in Engineering of German Research Council, the research continued at Catholic University of Eichstätt Ingolstadt under the lead of Prof. Jörg Desel
1999
2003
We have implemented VIPTOOL, an academic tool for validation of business processes based on Petri nets under the lead of Prof. Jörg Desel at Catholic University of Eichstätt Ingolstadt
2003
2005
Our research continued at Slovak University of Technology with a focus on deadlock analysis of workflow processes with multiple instances and shared resources
2005
2008
We have created the first version of Petriflow language and led the implementation of Petriflow modeller and Petriflow engine, academic tools for creating and deploying Petriflow processes
2008
2015
We have implemented the first online web-based modeller for Petriflow language
2015
2017
The definition and documentation of Petriflow and new academic version of Petriflow engine derived from NAE was launched
2017
2018
We have organized the 39th International Conference on Applications and Theory of Petri Nets and Concurrency, the 18th International Conference on Application of Concurrency to System Design, International Workshop on Petri Nets and Software Engineering and Workshop on Process-Driven Application Development
2018
2020
Academic version of Petriflow builder that includes Form Builder was derived from NAB
2020