Adapt BP based on new Data Model

[mwageneder]

• Registration Process needs adaption based on User <--> Company Relation
• ProcessValidation should be extended with ProcessModel Upload into the ProcessStore and renamed to "Processupload and Validation"
• ProcessPurchase needs adaption especially for the DEV Team to set the structure, how the procedure should be handled when a company buys a process from the Store

[tortmann]

Registration Process Process and description are already looking good. Please read through the description again as it needs a bit of proofreading.

Furthermore, please don't forget to inform the other project members about the new information and its importance for the dev team which was and is going to be added through this issue.

[mwageneder]

Please read through the description again as it needs a bit of proofreading. --> DONE ! Thanks for the very fast feedback .. I did not proofread it and this was however quite obvious :D

I will inform all the project members when I am finished with updating all processes and creating the overview we discussed!

[mwageneder]

UPDATE (22.04.2018)

• revision of all internal BPMN processes was done in order to fit the newly discussed data model

  • Processes 1-4 were changed and revised under a new version number available on the Sharepoint

• As discussed, I created an Overview of the most important procedures and how they should be implemented according to the data model

  • File was published on the SharePoint under the following name & directory
  • Filename: Prozesse/Overview of EasyBiz Processes.pdf
  • File should, in my opinion, grow with the project (all procedures and tasks should be discussed there) - so it`s not final yet

ToDo

• review needed from @tortmann
  • just a check needed if everything is included what has been discussed!

[tortmann]

ad Process 1

Added changes to the description of how the user registration works (currently marked in yellow). In my opinion it makes much more sense to check the user data in the frontend before sending everything to the backend and use async validation in case of specific form fields that could cause a duplicate error (username, email.)

Please also add a connection between choosing usertype and the database in the process model since all the information will be sent in one http request, after submitting the registration form, and not separately.

Please reupload as v3.1 - other reviews will follow shortly

ad Process 2

I have highlighted two sections of the document which did not seem correct or precise enough to me. "automated portal" - I was not aware that we have an automated portal that automatically checks wheter or not a process model is correct / sound or not and gives feedback about the result.

"if the model is OK and matches our criteria it will be stored in the system /database" - by uploading the model in the first place, before any checks happen, the model is already in the system /database (technically speaking); What does however happen after all the checks are done and the model is approved is that it becomes visible in the store, it's however stored in the DB long before that.

A third point I wanted to mention was that as far as I know and read in the BP documents models will be reviewed and approved by a team of human experts and the communication during this review process happens via the comment functionality. If i rememeber correctly this is explicitely mentioned in the PlatformFunctionality document by @Graf-Carello and in the Sketch by @deKilla.

Overall I want to mention that I might have missed these issues during the first review since we did not have such a close connection between the actual implementation and the processes from the beginning. It should however be fixed quite easily with a few changes in wording in most of the cases mentioned above. If you wish to discuss this tomorrow we shall reserve a 3-5 min timeslot for that.

ad Process 3

"when the customer wants to buy a process, the system checks if the customer is logged in" - This is fine, but I think we should add the following:

- check if the user (after logged in) has already purchased this process model

ad Process 4

Approved - please explicitely mention the checks (is user logged in?, does user already own the process model?) in process 3 since they are required in process 4 too.

ad Process 5

I know that this process what not up for review but I just thought of a slight change while reading through it, that makes a lot of sense in my opinion.

If a process model is modified, all organizations should by informed about this change in the store - e.g.: via E-Mail and/or flagging this process in the store with a "recently changed" tag or something similar.

@amarbajric I would appreciate a very short comment in case you do not agree with my suggestions since it also concerns the dev-team. Thank you!

[amarbajric]

Thank you for your review @tortmann. I will include some of the comments @tortmann has made in the above comments and give my own opinion about them.

In my opinion it makes much more sense to check the user data in the frontend before sending everything to the backend and use async validation in case of specific form fields that could cause a duplicate error (username, email.)

Although this is not a must have, we should and can easily make use of Angular's async validation in the frontend to at least validate an email while registering to not POST a register form and then get the error message every time the registration failed. However, for the Login we do not need the async validation for security purposes.

I have highlighted two sections of the document which did not seem correct or precise enough to me. "automated portal" - I was not aware that we have an automated portal that automatically checks whether or not a process model is correct / sound or not and gives feedback about the result.

No we have not discussed such a feature like an "automated portal". We will only have the feature available to upload processes, which then will be reviewed and hopefully approved by a human being (approver).

"if the model is OK and matches our criteria it will be stored in the system /database" - by uploading the model in the first place, before any checks happen, the model is already in the system /database (technically speaking); What does however happen after all the checks are done and the model is approved is that it becomes visible in the store, it's however stored in the DB long before that.

Yes this is very important! EVERY process uploaded will be stored in the ProcessStore table and will have an attribute like isApproved which is set to false at first. Then, an approver can pick the process and review it. If the review is approved, the process will be flagged with isApproved=true and is then also displayed in the process store.

A third point I wanted to mention was that as far as I know and read in the BP documents models will be reviewed and approved by a team of human experts and the communication during this review process happens via the comment functionality. If i rememeber correctly this is explicitely mentioned in the PlatformFunctionality document by @Graf-Carello and in the Sketch by @deKilla.

Yes this is absolutely correct. Approvers will have their own view, where they will get a list with all processes where the attribute isApproved is set to false.

"when the customer wants to buy a process, the system checks if the customer is logged in" - This is fine, but I think we should add the following:

• check if the user (after logged in) has already purchased this process model

We have to always be careful with the naming conventions. By design, only orgs. can buy processes. Of course a user, who is part of an organization and is eligible to buy processes, will buy the process. At the end however, the organization owns all processes.

If a process model is modified, all organizations should by informed about this change in the store - e.g.: via E-Mail and/or flagging this process in the store with a "recently changed" tag or something similar.

This is a very good point as @tortmann already mentioned. Could be very helpful for the organization. As long as the org. has not configured > instantiated the process, the should be able to use the updated process as it is only a mapping between a process and the org. However, if the process was already instantiated, the would need to stop the running instance, configure the updated process again and then instantiate it again.

[tortmann]

ad Overview of EasyBiz Processes

What is necessary to use our Platform

"once logged in, a user can upload processed to our platform"

I slightly changed the definition in the second sentence since being logged in theoretically enables all below mentioned features not just the upload.

Upload

"checked automatically" - additional (short) explanation or references would be required to define how this automatic check is supposed to work but our case I think that we should leave this out completely as suggested in comment ad Process 2 and by @amarbajric since the review only includes human approvers that review via comments.

In this overview you explained the approval process correctly and in the way I commented in the comment ad Process 2, (besides the automatic check of course) ;)

Buying Processes

Here you correctly referred to the list of purchased processes which need to be included /used (see ad Process 3 comment )

We have to always be careful with the naming conventions. By design, only orgs. can buy processes. Of course a user, who is part of an organization and is eligible to buy processes, will buy the process. At the end however, the organization owns all processes.

@amarbajric - correction - of course I was referring to the processes an organization owns, you are right we need to be careful with naming conventions in this case

Although this is not a must have, we should and can easily make use of Angular's async validation in the frontend to at least validate an email while registering

@amarbajric - Yes, that's definitely a nice to have

Please make the adjustments mentioned above

[I summarized all of my comments into one for better readability - no changes made - 24.04.2018 - 12:24pm]

[mwageneder]

First of all thank you very much for your very helpful and very detailed feedback @tortmann & @amarbajric ! Much appreciated !

I took all of the comments into consideration and adapted the processes 1-5 and the Overview according to them. Short overview given below:

	ADDED	CHANGED
Process-1	- some conections to the database within the process model	- refined description to check the email asynchronously and POST the whole registration from at once if everything is fine
Process-2	- added task to set isApproved flag	- changed the name from „automated portal“ to syntactical check and the approver later on handles the semantical check (as already discussed and planned with and by @Graf-Garello and @deKilla. (Very nice sketches by the way!)
Process-3	- Purchase Check	- adapted Login Check
Process-4	- Purchase Check + Login Check	-
Process-5	- Information to other Buyers, that there was a change	-
Process-Overview	-	more precise description about the isApproved flag

For a clarification for all team members reading through these comments:

I have highlighted two sections of the document which did not seem correct or precise enough to me. "automated portal" - I was not aware that we have an automated portal that automatically checks wheter or not a process model is correct / sound or not and gives feedback about the result.

With this "automated portal" the syntactical check of the uploaded process model (like the xml validation - just some semantic web stuff) was meant. I (as already mentioned) eliminated this naming error and now everything should be clear.

For all other Team members (Dev Team as well as Business Team):

The following Descriptions and graphical processes are available at the SP with the latest version number (of course!) within the folder Prozesse!

Everyone should have a look at them and should know, how the processes and procedures correlate with the desired version of EasyBiz in order have a understanding, how we planned to implement the different features.

The documents and processes are approved by our Project Manager @tortmann and our Developer-Teamlead @amarbajric!

Preferably you go for following versions of the documents:

• BPMN_Processname.pdf
• Prozessbeschreibung_Processname.docx)

These are growing documents, so you should at best have a look at them from time to time.

Best, Max

[tortmann]

Approved