BPEL2oWFN can generate several file formats:
A (low-level) place/transition net as described in [LoLA]. The places and transitions are named using the internal (numeric) name of each node. Furthermore, the first entry of the history of each node is added as a comment.
{ Petri net created by BPEL2oWFN reading filename.bpel } PLACE a comma-separated list of places MARKING the initial marking a comma-separated list of transitions { END OF FILE } |
For more information on the node naming conventions of BPEL2oWFN, see Naming Conventions.
An open workflow net is a Petri net with an interface, i.e. two sets of places: input places and output places. To represent oWFNs the LoLA format was extended to implement this categorization:
{ oWFN created by BPEL2oWFN reading filename.bpel } PLACE INPUT a comma-separated list of input places OUTPUT a comma-separated list of output places INTERNAL a comma-separated list of internal places MARKING the initial marking a comma-separated list of transitions { END OF FILE } |
Additionally an open workflow net has a set of final markings. Since there exist no tools reading oWFNs yet, the representation of final markings is not implemented.
The Info-files are generated when any command-line option is used which imply Petri net-generation. When reading from a file process.bpel a file process.info is generated. This file sums up all places and transitions together with their internal (numeric) name and their complete history:
PLACES: ID TYPE ROLES a list of places TRANSITIONS: ID GUARD ROLES a list of transitions |
These files are generated to document the connection between the generated output file and the chosen Petri net patterns. In future distributions of BPEL2oWFN the Info-files will be used to annotate witness and counter-example paths, resp. and to “re-translate” Petri net properties (e.g. a dead transition) to the input BPEL process.
For more information on the node naming conventions of BPEL2oWFN, see Naming Conventions.
BPEL2oWFN generates the output Petri net by creating and merging parameterized patterns of the Petri net semantics defined in [Sta05]. Due to merging and simplifying the Petri net nodes “belong” to more than one pattern. For example, in a sequence the initial place of the sequence and the initial place of its first activity are merged so that the final Petri net contains one place with two roles.
The roles of each place are collected during the Petri net generation. They form the history of the node. It is used to locate errors of the modeled business process: If, for example, BPEL2oWFN generates a Petri net of a business process and the model checker LoLA finds a dead transition, its history helps to find which BPEL constructs are affected and in this case will never be executed.
The roles are named using the following conventions:
For example, BPEL's activity process has the identifier 1, so that all nodes of the process pattern begin with 1.. To find out the identifiers of a given process use the --xml command-line option which prints the id of each activity as an XML attribute.
The same schema is used for fault handlers (id.internal.faultHandler.), compensation handlers (id.internal.compensationHandler.) and event handlers (id.internal.eventHandler.), resp.
To bugfix1 the implemented Petri net patterns BPEL2oWFN implements a graph representation of the generate Petri net.
[1] The Petri nets usually have a large number of nodes so that the graphical representation of a `real world' process would not be suitable to process, read or understand. That is why the Dot output shall be seen as a means to debug small patterns.