In this post I will describe how to obtain a BPEL process model out of the history log of a proprietary workflow application. This post is related to the â€˜Workflow net to BPEL 1.1 manualâ€™ of Kristian Bisgaard Lassen M. sc. (march 2007).
Point of departure
The following picture illustrates the process model of the proprietary workflow application.
- Process Control
Selections menu for selecting the next process activity (customer communication, registration, wait or end).
- Customer communication
Sub process for sending a letter to a customer
Sub process for registering customer information
Wait service to set the process on-hold e.g. because there has to be waited for a customer reaction.
The used history log contains the complete status of all finished activities. This means that the history log of a specific ended instance always starts and ends with ‘completed Process Control’. An instance can contain multiple loops. The log does not give a decisive answer if the instance is ended. For this post the assumption is made that instances are ended when ‘completed Process Control’ is the last log entry.
Loading the history log in ProM
After starting ProM, the history log is loaded via the menu option: Mining –> Open new log
A description of the format of this log is outside the scope of this post. As illustrated in the picture below, the log contains more than 80k activities/events spread over 20k+ cases. The average number of activities in an instance/case is 4.
Obtain a BPEL process model
To obtain a BPEL process model out of the history log we need to close the gap between them. The BPEL conversion plug-in requires a petri net as input. So we need a mining plug-in that discovers a petri net model. For this purpose I have used the alpha mining plug-in, available throw the menu option:
Mining –> Raw <filename> (unfiltered) –> Alpha algorithm plugin
After selection, the following settings window appears.
Mining with all the default settings results in the following petri net model.
To my opinion it is very difficult to see the actual process model in the petri net model. Question: is this caused by the fact that the discovered relations are incorrect? As can be seen when clicking the â€™edit log relationsâ€™ button.
In the original application it is not possible to execute activities in parallel. The alpha algorithm suggest this is possible and the follow relations are not filled (because of the assumed parallelism).
These settings could be edited in order that the match the real relations (see the picture below). After trying I came to the conclusion that changing them does not have any effect on the output results. I have not figured out yet in what situation the do make sense.
To get the BPEL model, select the required conversion plug-in through the menu: Conversion –> Selected Petri net –> BPEL 1.1.
If I leave the ‘Include log in result’ toggle on the plug-in seams not to work for any reason and gives a blank result. Switching if off makes it work fine but abstains some valuable information. Is there something I’m missing? After switching of the ‘Include log in result’ toggle, select ‘Begin conversion’. The following window appears.
When this window appears, there is one or more irreducible component. In this case the irreducible component is the complete petri net model. Selecting ‘Next’ makes that the full BPEL process model must be specified with a manual translation, which makes the usefulness of this plug-in questionable. Is it possible to split the model into multiple (irreducible) components?, is a question I can’t answer yet.
After some trying it comes true that it is possible to generate a BPEL process model out of the history log. But because of all the manual work and the existence of only one (irreducible) component the conversion plug in seams to have limited added value in this case. Designing directly in a process modeler like Oracle Jdeveloper is easier.
In my next post I will describe the export of the BPEL model in ProM and getting it running in the Oracle SOA suite.