In this paper, we present a prototype of a module of the Petri ow application engine that stores process nets for each single case of a Petri ow model, whose underlying process model is a place/transitions net. It enables to lter cases according to search queries and to export the process runs for the ltered cases within a compressed form, containing each process net in a separate le. The process nets can be used for further analysis or as an input of process mining methods. Each process net can be opened in the application builder and simulated. As parameters in the search, we chose fact transitions that are used to identify the set of markings of the instance of the business model.
Using place/transition Petri nets [
The Netgrif Application Engine, a part of the Netgrif platform, is built to interpret programs of the Petri ow language. Petri ow is a high level programming language for process-driven application development. Petri ow follows the programming paradigm called process-driven programming (PDP). A comparison of Petri ow's concept with other well-known programming paradigms is essential to understand the meaning of the PDP paradigm. In this section, we discuss how process-driven programming extends and combines advantages of object-oriented programming (OOP), the business process modeling (BPM), event-driven programming (EDP) the and relational databases (RDB).
While binding methods with data in classes was one of the main features of OOP that helped to create more modular programs, PDP adds processes to classes to describe a life-cycle of objects of a class. In this way, by adding processes that de ne when methods of a class can be called and who can call these methods, applications can be programmed easier, faster, and therefore cheaper.
The main building blocks of object-oriented programs are classes and their objects. In comparison, the main building blocks of process-driven programs in Petri ow language are processes and their instances called cases. A class is a blueprint of an object and a Petri ow process is a blueprint of a Petri ow process instance. Simply, a Petri ow process is a class enriched by a work ow process that de nes a life-cycle of the objects of that class.
More accurately, a Petri ow process consists of data, tasks and actions, roles, and a work ow process. The Petri ow processes can be deployed to any compatible work ow engine, such as the Netgrif Application Engine to create rich, process-driven applications as seen in the illustrative overview in gure n. 1.
In the same way as classes in OOP, data variables in the Petri ow processes represent all attributes of a Petri ow process instance. The change of the value of a data variable can be triggered by a so-called set-event. Reading a value of a data variable can be triggered by a so-called get-event.
Tasks are the active parts of the Petri ow processes. Data variables can be associated with work ow tasks to de ne data elds and create task forms. A data eld, which is an association of a data variable to a task, is given as a rich relation, that states { whether a get-event and/or a set-event can trigger the data variable, i.e.
whether its value is readable and/or editable, { whether the value of the data variable is required, { what are the valid values of the data variable within the data eld.
Tasks have a simple life cycle: a task can be enabled, disabled or executed. Change of the state of a task can be triggered as follows: { if a task is enabled, its change to the state executed can be triggered by a so-called assign-event { if a task is enabled, its readable data elds are accessible for reading by get-events { if a task is executed, its readable data elds are accessible for reading by get-events { if a task is executed, its editable data elds can be changed to valid values by set-events { if a task is executed and all its required data elds have valid values, its change to the state enabled or disabled can be triggered by a so-called nishevent.
Using the principles of event-driven programming, each data variable and each task has an associated event listener: whenever an event triggers a change of the value of a data variable, or whenever an event triggers a change of the state of a task, then a reaction can be de ned by pieces of code called actions in the event listener. Whenever an event occurs, the actions in its event listener are executed. In actions, as a part of the code, events for tasks and events for data variables can be emitted. In this way, events and their reactions can create chains.
Roles or lists of users can be associated with events of tasks, de ning for each task which users are authorized to emit events on that task. Similar to data elds, the association of users with events is a rich relation. For example, a user authorized to emit an assign-event of a task can emit the assign-event. By emitting the assign-event, this user has to choose one of the users that are authorized to possibly emit nish-event of this task and only this user is then authorized to emit set-events of editable data elds of this task and to emit the nish-event of this task. In other words, by emitting the assign-event, the authorized user is assigning that task to a user (possibly himself), that is authorized to perform the task, i.e. to ll editable data elds and nish the task.
As a work ow process, Petri ow language uses place/transition Petri nets enriched by reset arcs, inhibitor arcs, and read arcs to de ne the life cycle of the Petri ow process. Places of the Petri net represent the control variables. Transitions of the Petri net represent tasks of the work ow process. A task is enabled, whenever the corresponding transition in the underlying Petri net is enabled. An assign-event occurring on this task consumes tokens from the input places of the corresponding transition and moves the state of the task to being executed. A nish-event on the task be executed produces tokens to the output places of the corresponding transition. In this way, the work ow process de nes when a task is enabled, executed, or disabled. The life-cycle of the Petri ow process is given as a ow of assign/get/set/ nish events on tasks and data variables respecting the restrictions on events given by the underlying Petri net.
When drawing a parallel between relational databases and process-driven programming, the Petri ow processes correspond to database tables, while instances (cases) of the Petri ow processes correspond to single records (rows) of these tables. In a similar way to foreign keys in RDBs and in a similar way to attributes of objects containing references to other objects in OOP, data variables of Petri ow processes can store references to instances of Petri ow processes, references to a single task, and references to a list of tasks of Petri ow process instances. These stored references to Petri ow tasks allow for a simple way of sharing the forms associated with them as subforms within other tasks and to implement a single source of truth architecture. 3
The Netgrif Application Engine (NAE) is a tool for deploying and running process-driven applications written in the Petri ow language. NAE is composed of several building blocks. The core of the NAE is the Process Engine Server, which enables to: { Upload, run and delete Petri ow processes { Create, run and delete instances of processes { Assign, nish and cancel tasks of process instances { Read and save data variables { Execute actions Sometimes you do not want to change the process to react with an action to an event. It usually happens if you want to react with the same action to more than one event in di erent processes. The Rule Engine allows you to specify if-then decision rules written in the MVFLEX expression language (MVEL). Whenever an event is triggered, then the Process Engine Server checks the Rule Engine, whether there is a rule such that its if condition is valid for the event. In such a case, the Rule Engine executes the then statement of the rule. In the then statements of rules, you can trigger events of the Process Engine Server. The Rule Engine is based on Drools.
The Process Engine Client provides a user interface in the form of Angular components for displaying task lists, task forms, and data elds. The Process Engine Client communicates via a REST API with the Process Engine Server. Using the web address of the Process Engine Client followed by the ID of a process instance, the list of enabled tasks of the created process instance, the so-called case view, is displayed by the Process Engine Client. If the name of a process is used instead of the ID of an instance, the create event is triggered and the Process Engine Server creates a new process instance. You can see the architecture of the Process Engine stack in gure n. 3.
In the task list, you can expand a task to display the task form, triggering get events for all the referenced data elds. Once a task form with all its data elds is displayed, the assign event of the task can be triggered. Once a task is assigned, the cancel event can be triggered, the set event can be triggered for editable data elds and when each of the required data elds has a valid value, the nish event of the task can be triggered.
The Process Engine Server, the Rule Engine, and the Process Engine Client together with a set of prede ned processes for managing roles, users, authentication, and authorization of the users, deploying Petri ow processes is provided as a Default Process Driven Application. The Default Process Driven Application allows you to administrate the processes by deploying and deleting the processes, to invite users, and to add/remove roles to/from users. It o ers the functionality of registering users. For registered users, it o ers the functionality of a task list, where you can assign and perform the tasks associated with one of the roles of the registered user lling the task forms by editing the data elds. For anonymous users, it o ers the ability to ll public task forms of public processes and to access the instances of the public processes via the ID of the process instance.
Even if the rich functionality of the NAE and the Petri ow language is not enough, you can go beyond its functionality by overriding the prede ned components. In this way, you can, for example, add new menu items associated with Petri ow lters, add connectors to your own systems, or customize the Angular components to be displayed according to your own design manual. 3.1
Search in the NAE As mentioned before, the Process Engine Client comes with a prede ned library of Angular components. One of these components is the search component. The purpose of this component is to allow users to lter the cases or tasks that are displayed in the client. The search component can operate in two modes. The rst, also called the full-text mode, is a familiar input eld that allows users to search for substring matches in case or process attributes prede ned by the developers.
The second mode is a more recent addition to the Process Engine Client component library and the goal for its creation was to allow the users of the application to have ner control over the created lter. This second search mode is more commonly called the advanced search mode. The lters it can create have a prede ned structure, which is a conjunction of disjunctive clauses. The users can add as many clauses as they desire and each clause can also have an unlimited number of literals. The literals that can be used are the basic building blocks of the search component and are called search categories. The set of search categories, available when searching cases, is di erent from the categories, available when searching tasks. Each category represents a query on some attribute of the ltered objects. The way a certain attribute is queried is determined by a search operator. Each search category de nes a set of operators that can be used with it. For most categories, this set is relatively straightforward. The only exception is the case data category, which queries a subset of the case's data set. The developers must mark data variables as available for searching, which determines the extent of this subset. It is the most complex category available as the queried data variable must be selected rst, which in turn, based on the variable type, determines the set of available operators.
This design allows for a relatively high degree of freedom when creating a search query, without the need to write the underlying lters by hand. When even more complex lters are required, the developers can write them freely by hand as the underlying query language does not impose any structural limitations on the queries. The Netgrif Application Builder (NAB) is a tool for building process-driven applications using Petri ow language. NAB is composed of several modules that help you in di erent stages of application development.
In Process Modeler you can model business processes by de ning tasks and their routing and simulate modeled processes by executing sequences of tasks. As a modeling formalism for processes Petri ow language uses Petri nets that consist of state variables, tasks, and their interconnections. It supports the import of processes in BPMN 2.0 and its automatic translation into Petri nets. In gure n. 5 the Process modeler with an example net is shown, which we use in our case study later.
In the Role Editor, you can de ne roles and specify which roles can perform tasks in the process.
In the Data Editor, you can de ne data variables used in the processes. Petri ow supports all types of data variables you will need for your application, including text, numbers, date, date-time, enumerations and choices, les, images, and many others. Validation and initial values of the data variables can be easily speci ed in Petri ow. Petri ow supports reference to a list of tasks as a data type.
In Form Builder, you can build the forms for single tasks by drag and drop either existing data variables or adding new data variables. For data variables on forms, called data elds, you can specify di erent attributes, such as placement in the form grid layout, choose the appropriate view such as di erent types of checkboxes, and determine, whether the data elds are editable, visible, required, or hidden. Using reference to a list of tasks as a data eld, you can embed subforms to forms.
In Action Editor you can program reactions on events of process instances, its tasks, and data elds. Actions use Groovy as a programming language. Types of events that you can catch include construction of the process instance, assignment of a task to a user, cancellation of a task, nish a task, and change of a data eld value. In actions that react on events, you can trigger events in di erent process instances and in this way for example create a new instance when you nish a task, assign a new task a user when you nish the current task, to recalculate a value of a data eld whenever you change another data eld, or hide/show data elds when you change another data eld. Also, in actions, you can use prede ned search functions to nd speci c process instances or tasks based on values of process attributes, process instance attributes, task attributes, and data variables. In actions, you can also call external functions as well as send and receive data from external systems via REST or SOAP web services.
Figure n. 6 show us a source code of implementation roles in Petri ow language. Roles consist of two parts declaration and de nition on assigned transition. The role declaration de nes the name and unique identi er of the role in the process. De nition on the assigned transition identi es what action a given role can perform on a given task.
Figure n. 7 show us a declaration of data and also how we can bind data
references with the transition. Using data references we can de ne which data
variable we want to show at a given transition with given behavior. Possible
behaviors are described in this paper [
On data variables, data references, and the transition we can de ned actions or events that can change behavior or change the value of data variables. Using these actions, we can create dynamic forms and processes that respond to the user interaction. Simple source code of this events/actions is show on the g. 8.
Using NAB you can generate and download the source code in Petri ow language that includes all the necessary information about processes, their tasks, roles, data variables, forms, and actions. 5
In this case study, we chose to examine the Petri Net model shown in gure 5. It represents a simpli ed work ow of applying for a mortgage. The model starts with an application form (transition Apply for mortgage) which is executed by a user with the client role.
After the mortgage application form is sent, the model splits into three parallel branches. The purpose of the upper and lower branches is to make some of the data variables accessible by the users of the application (transitions Case info and Status). The model continues with the middle branch (transitions Approve and Reject), where the loan o cer either approves or rejects the mortgage application based on some internal criteria. This splits the process into two alternate branches.
The lower branch represents the possible deletion of the rejected application by the client. Note that this does not delete the model instance, as the bank still needs to keep the information, about the rejected mortgage application, and can still access the information, made available through the Case info transition in the top-most branch. If the application was approved a Property appraiser must write an Appraisal report (transition Appraisal report). After the submission of the Appraisal report, the bank system approves or rejects the application (transitions Approve and Reject) based on some prede ned business rules. In the simpli ed work ow, the application is automatically approved if the amount of money, asked in the mortgage application form, is smaller than the appraised value of the property. Should the application be rejected, it continues down the already described path, which leads to the deletion of the application by the client.
If the system approves the application, we consider the mortgage to be approved and the model continues with the signing of the contract by the client (transition Sign loan contract). After the contract was signed, the model is once again split into two parallel branches. In the upper branch, the Loan o cer < document ... > ... < data type =" text " > <id > client_name </ id > < title > Client 's name </ title > <desc > Please enter your name </ desc > </ data > ... < transition > <id >1 </ id > <x >240 </x > <y >190 </y > <label > Apply for mortgage </ label > <dataRef > <id > client_name </ id > <logic > < behavior > editable </ behavior > < behavior > required </ behavior > </ logic > </ dataRef > ... </ transition > ... </ document > must con rm the lien inscription (transition Con rm lien inscription). In the lower branch, the client signs an insurance contract for the mortgage with an insurance company (transition Sign insurance contract). When both of these tasks were completed, the Account clerk can send the money to the client (transition Send money).
We want to demonstrate with the help of this Petri net model, how our tool
creates process nets for the instances of the model running in the application
engine. Log les rarely record information about states. Here, we record the
full information about conditions in the process net. We want to use the search
capabilities described in section 3.1 to lter only instances in speci c states. For
this purpose, we want to use fact transitions, as the search tool allows us to nd
instances that have a marking that allows a speci ed transition to be executed.
For more information about fact transitions and their use for veri cation see.
[
In order to demonstrate how the tool can generate processes for running instances, we have created an instance of the mortgage application model with fact transitions. We executed the transitions that lead to the undesired state. The transitions that were executed in the instance can be seen in gures 10. IN Apply for mortgage p1
Approve p3
Appraisal report p12
Reject p2 p9 Delete p14
Once the instance reaches its nal state, we can use the fact transitions to nd it in the application engine. We can use the search query to download the process net of the run. The algorithm that we use to generate the process runs is described in section 6. Once we download the process net from our application we can open it in NAB. While the algorithm does place the elements of the process in such a way that they do not overlap each other, it does not attempt to replicate the layout of the executed net. Therefore we changed the layout of the output by hand to resemble the original net more closely. No other changes were made to the generated process net. We can see the process net of the instance in gure 11. As we can see our tool exports only the IDs of places and transitions from the original net. This is desired, as the original net contained two transitions named Approve and two transitions named Reject.
The process net distinguishes between them by labeling all transitions and places with their IDs.
As we can see this tool allows us to generate process nets for running instances of any model running in the application engine. We can then use the search interface to select a subset of all the available cases and download the generated process nets. We can use other tools to analyze the generated process nets, or we can examine them by hand to check if the deployed model behaves as expected.
Apply
Approve 1 p3
Report p12 p16
Reject 2 p2
Delete p14 If we want to generate runs for the instances that are present in the system, we need to represent them. Since our tool already has a working representation of Petri nets, we can reuse it. Because of this, we have decided to represent the runs as Petri nets. We have created a new collection in MongoDB, a database in which we store every run as a document, we then created a mapping of running model instances to their corresponding runs.
When a new case is created a new Petri net representing its run is generated alongside it. This net initially contains only a set of places, where each place represents one token in the initial marking of the original net.
When the system or a user nishes any of the tasks, the run of the
corresponding case must be updated. A new transition, that represents the executed
task must be added to the run of the a ected case. This new transition must
consume and produce tokens according to the ring rule in the original net [
In order to nd the places that represent the tokens that have not yet been consumed we iterate over the arcs in the net, that represent the run. If the arc we are currently iterating over connects a place and a transition, we know that the token represented by the place has already been consumed. We collect the identi ers of such places. Once we have all the identi ers of the places that represent the consumed tokens, we can iterate over all the places and lter the consumed places out, which leaves us only with the places that represent tokens that have not yet been consumed.
If a transition in the original net produces multiple tokens into a single place,
each token will be represented by a single place in the run [
Updating the run is simple, we add a new transition, connect it to the existing
unconsumed places based on the tokens it consumes in the original net and
we add new places based on the tokens it produces. Since we have the places
grouped we have access to the required objects in the required quantities. Since
the original net enforces the ring rule [
The order in which we choose which of the yet unconsumed token are
consumed is important because it creates dependencies between transitions red in
the past and the new transition in the run [
An example of a Petri net that can generate di erent causal dependencies depending on the choice of places can be seen in gure n. 12. The two possible runs that can be generated from this net when all of its transitions are red can be seen in gure n. 13. The current implementation will always result in the rst process net to be generated regardless of the ordering of the executed transitions. The ring order of the transitions does not matter for this speci c net, in some nets a di erent ordering will create a di erent process nets, but in general, the same ordering will always yield the same net in the current implementation.
Since we reused the existing Petri net representation to represent the runs, for export we would use the same structure as for import into NAE or NAB. We declared the structure using JAXB Annotations and using JAXB Marshaller we created and exported it for a given individual run. Since we want to export multiple instances at once, we need to add ltering of instances. The search tool that is a part of NAE and, which we used to lter the instances is described in section 3.1. One of the available search categories lters cases based on the executable tasks in them. With the help of this search category, we can lter the instances based on the fact transitions, as described in section 5. The created search query must be sent to the exporter service, for this reason, we declare a new REST controller. The controller uses the query to nd the running instances and by extension their runs. Afterward we call the service that exports each run instance, the exported les are then added to a ZIP archive, which is uploaded as a blob object that the browser automatically downloads. 7
When using the formal de nition of the Petri ow Language to design business processes and the subsequent generation of individual runs for a given process, it is appropriate to think about generating not only the basic elements of the Petri nets into runs but also extending parts used by the Petri ow language. We must consider which parts have a business or analytical bene t for us. Using every element of Petri ow can be confusing. Individual runs are used to describe the run of a given business model, we would like to describe any step or action that happens in an instance of business models using its valid representation. Petri ow language uses not only the basic arcs but also read and inhibitor arcs, which we describe in section 2. Using the read arcs in the business model, we can re a given transition multiple times and each ring is generated into an individual run as a separate instance of the task. But if we use valid representation for ring a read arc we can simplify the generated individual runs and make them more usable.
In the future, we want to export the individual runs to the structure that
can be taken as an input to the appropriate process mining tools such as Prime
Miner [
Petri ow language includes the structure of the data that can be changed on some tasks. For future implementation, we want to implement a recording of each change of the data in the individual runs. Recorded data must be bound to the transition where the change was applied, for the reverse analysis.
Currently we only record the executed transitions of the model in the process net. In the future, we would like to expand the logging capabilities to include additional information, such as execution of various events in the system (assignment/cancellation of tasks, setting of new data values) enriched with information about the actors (user and role information). These enriched logs could then be used for a more in-depth analysis of the deployed models. 8
In this paper, we presented an extension of the Netgrif Application Engine, an interpreter of the Petri ow language. For Petri ow processes built on place/transition Petri nets this module stores the history of individual cases in the form of process nets. The module also enables to lter existing cases according to queries and to export produced process nets to separate XML les. These process nets can be used for further analysis of the deployed processes or for process mining of ltered behavior. The builder for Petri ow processes is freely available at https://builder.netgrif.com/modeler and the NAE together with the new module presented in this paper can be freely used after registration at https://academy.netgrif.com/.