Project 3

Project Name: 
TUFly
Process Model
Modeling Tool: 
Camunda
BPMN 2.0 Model (.bpmn): 
BPMN 2.0 Model (.pdf): 
Workflow Implementation
Execution Tool: 
Camunda BPM
Test Report: 
To test the code we implemented a Test class (ServiceBeanTest.java - see in the repository). This used automatic JUnit tests to check the method calls and outputs. This test is checking the functionality of the service methods with the Help of Mockito to avoid dependencies to DAOs and the process engine. ////// For the functionality of the system we tried several test-cases //// #1 - Everything normal Input data: Look for destinations: Bratislava | Skopje | 17-06-2017 Sort travel list by price: List OK, cheapest on the top Booking: OK, booking entity created Payment confirmation: 0000-0000-0000-0000 Get final ticket: OK, PDF genetated Output: Ticket generated, process finished //// #2 - No date selected Input data: Look for destinations: Bratislava | Skopje | NA Output: no date entered, process halted (user has to re-input) //// #3 - Wrong Card number Input data: Look for destinations: Bratislava | Skopje | 17-06-2017 Sort travel list by price: List OK Booking: OK Payment confirmation: 000 Get final ticket: NA Output: Wrong card number - process terminated /////// Test methods: basically every group member first corrected his own code and fixed the minor bugs. To make things faster there was a constant information flow on our Slack channels about the tricks in Camunda. After the individual parts were done, we cross-tested some of them (for example to find typos and copy-paste errors leading to bugs). The hardest part was the integration into the Camunda system, which was then tested individually by every single group member until the last (known) bug was fixed. //Adaptions of the initial process model The process model as proposed in the section above was not executable in Camunda without some adaptions. For the model used in Camunda we omitted the supplier pools and directly connected the tasks which were previously connected via supplier. This was necessary because implementing the supplier process is not in the scope of this project. In addition the there seems to be a known bug with Camunda concerning sending messages between pools of two running process instances. Sending a start message from one pool to another works as expected but sending a message to a already running pool doesn't work. We tried a couple of differnt approaches but there is no reliable approach. Even the official examples didn't work properly. This bug is also documented in "Camunda BPM Platform Loan Assessment Process Lab" Learning Objective. In order to make our application executable we moved the pools of the customer and the business into one pools but different lanes. So we could keep at least some parts of the original structure and had a workaround for the messaging problem