Project 9

Project Name: 
Procure-To-Pay
Process Model
BPMN 2.0 Model (.bpmn): 
BPMN 2.0 Model (.pdf): 
Effort Process Model: 
20hrs
Workflow Implementation
Execution Tool: 
Camunda BPM
Test Report: 
Individual tests for each task can be found on the review of each task. This report refers to the integration test of each task and an end to end test. Each Task is deployed separately either in a cloud system or on the servers provided for this course. Communication between the tasks happens with rest calls. Over an Microsoft Teams call we planned 3 test runs, with the intention to fix all existing communication issues in the first test run, and then having a successful second end-to-end test run. The first two test runs only covers happy paths, in the third test run we tested the other intended paths(eg. decline purchase requisition, failed goods inspection, etc.). In each task responsible colleagues showed the process via screen sharing to faster identify possible issues. Test Run 1: Task1: Tested requisition creation over telegram. Issues with error handling spammed the telegram chat, which led to a kick-out of the telegram system. This has been solved after correction of the code and restart of the server. A problem, where each request has been sent twice also has been discovered and solved. Task2: Issues with reading the JSON received from task1. It seems that the variable name of the JSON has been wrongly written. JSON was received but could not be processed. This was solved and redeployed to the server. Another issue occurred, when trying to send the JSON to task3, where variable „Supervisor“ was declared as int, while in task3 this is a string. Correction was done immediately. Task3 and Task4 went through smoothly. Task4 triggers notification to the customer over the Chatbot in telegram and also triggers processes in Task5. Small issue with missing data in Task5, that also was solved immediately. This concludes the Test run 1, the integration test. On the second test run we did an end-to-end test, starting a requisition over telegram with several items. This went through all tasks smoothly as expected. The third test run consisted of several runs, where we tested all other possible and intended paths of our workflow. Like the declination of the purchase requisition, the creation of a return order, when the good inspection of the received goods failed or payment declination when invoice sum is different than the created purchase order. This worked also as planned. ---------------------------------------------------------------------------- -------- User Testing: Entry point Customer Interface to order office supply(Telegram required): t.me/procurista_bot
Effort Implementation: 
25hrs
30hrs
25hrs
26hrs
30hrs